매트의 개발 블로그

[test tool 2-2] Jest+React+TypeScript - 이미 개발된 코드에 unit test를 적용해보자 (+코드 리팩토링은 덤)

kkangdda — Tue, 7 Nov 2023 18:09:38 +0900

이전 글에서 사용자 시나리오 & 테스트 코드 작성에 대해 이야기하였다,
이 글에서는 3번 테스트 코드를 활용하여 코드 리팩토링을 한 경험에 대해 써보고자 한다!

기존 코드 & 기획서를 참고하여 사용자 시나리오를 작성한다.
테스트 코드를 작성한다.
테스트를 돌려보며 안전하게 코드 리팩토링를 한다.

총 3개의 테스트 파일이 있고, 이는 시나리오대로 나눈 것이다.
모든 파일에 대한 테스트를 돌려보면 아래와 같이 나온다 (all passed!)

2개 이상에서 똑같이 쓰이고 있는 코드가 있는데, 이를 공통 컴포넌트로 빼서 코드 리팩토링을 하려고 한다.
원래 같았으면 코드수정을 한 뒤, 하나하나 눌러보며 UI 테스트를 했었는데,
간단한 화면이면 테스트도 금방 끝나겠지만 이번엔 유저 이벤트에 따라 체크해야 하는 사항이 워낙 많은 화면이라서 테스트가 꽤 오래 걸린다..
그러므로! 이번에는 열심히 짠 테스트 코드를 믿고 코드 리팩토링을 했다!

1. 코드 리팩토링 하기

약 100줄에 달하는 코드를 공통 컴포넌트로 빼버리기 완료☑️

2. 테스트 코드 돌려보기

유저 이벤트에 대한 테스트 코드를 작성했기 때문에, 'jest test' 한 번으로 리팩토링한 코드를 점검할 수 있다.

역시.. 테스트 코드가 빛을 발했다 ✨
에러 내용을 살펴보면, disabled 되어야 하는 element가 disabled 되지 않았다고 말해주고 있다.

3. 테스트 결과를 토대로 코드 수정

disabledConditions={{
	...
	az: !isSubnetAdvanced || azList.length === 1 
}}

테스트 description을 시나리오에 맞춰서 작성했기 때문에, 어떤 상황인지 금방 파악이 가능하다.
디버깅 시간도 줄고, 바로 코드 수정 완료☑️

4. 다시 테스트!

5. 기분 좋게 소스 커밋

이미 개발된 코드에 대해 테스트 코드를 짜는 건 처음이기에 시간이 좀 걸렸지만,
코드 수정을 할 때마다 느꼈던 손으로 하는 테스트에 대한 부담감 + 귀찮음이 테스트 코드로 싹 사라졌다.
또한 테스트를 해야 하는 내용이 늘어날수록 사람이 테스트하는 것에 한계가 있는데, 이것 또한 해결해 주었다.
실제로 여러 컴포넌트들이 엮어있는 화면을 개발하고 있어서 예상치 못한 사이드 이팩트가 나오는 경우가 많다.
하지만 이제는 태스트 코드가 1차적으로 검수를 해주기 때문에 테스트 코드를 수시로 돌려보며 버그를 잡아냈고 코드 안정성을 높일 수 있었다.

[test tool 2-1] Jest+React+TypeScript - 이미 개발된 코드에 unit test를 적용해보자 (+코드 리팩토링은 덤)

kkangdda — Sun, 5 Nov 2023 20:31:23 +0900

계기

개발하고 있는 화면에서 유저의 이벤트에 따라 체크를 해야 하는 케이스들이 점점 늘어남에 따라 테스트 코드에 대한 필요성을 느꼈다.

화면 내부는 위처럼 크게 4개 컴포넌트로 구성되어 있다.
그리고 컴포넌트 내부에서 발생하는 유저의 이벤트에 따라 다른 컴포넌트에 영향이 간다.
예를 들어, component 1에 있는 내용에 따라 component 3에 있는 셀렉박스 선택지가 바뀌는 등..
유저의 시나리오가 많아지면서 코드를 수정할 때마다 직접 일일이 테스트해야하는 케이스들이 늘어났다.
(하나하나 눌러보느라 아픈 내 손가락..)
테스트 코드 작성에 대한 필요성을 느껴질 때쯤, 아래의 글을 보게 되었다.
https://techblog.woowahan.com/8942/

단위 테스트로 복잡한 도메인의 프론트 프로젝트 정복하기(feat. Jest) | 우아한형제들 기술블로그

최근 저는 복잡한 도메인의 서비스를 개발하는 개발자라면 공감할 만한 문제를 겪고 있었습니다. 찬호 님, 서비스가 비마트일 때, 공급사 반품 상세페이지에서 공급사 계정으로 로그인한 사용

techblog.woowahan.com

이미 만들어진 코드를 기반으로 테스트 코드를 작성하는 점
사용자 ↔️ 어플리케이션 간의 상호작용에 대한 테스트를 한다는 점
테스트 코드를 활용하여 컴포넌트 내 코드 리팩토링을 한다는 점

위 세가지가 나의 상황에 딱 맞아떨어졌고.. 글을 참고하여 테스트 코드를 구축하였다!

test 종류

먼저 테스트 종류에 대해 간단하게 알아보자.

1. Unit = 단위테스트

코드의 작은 부분을 테스트 하는 것 (ex. 함수)
일반적으로는 Class나 Method 범위를 테스트

2. Integration = 통합테스트

서로 다른 시스템들의 상호작용이 잘 이뤄지는지 테스트하는 것
Unit test와 달리 개발자가 변경할 수 없는 부분까지 묶어서 검증할 때 사용되는 테스트 (ex. 외부 라이브러리, db)

3. e2e = 종단 간 테스트

사용자와 어플리케이션의 상호작용이 잘 이뤄지는지 테스트하는 것
소프트웨어의 내부 구조 보다는 비즈니스 쪽에 초점을 두어 실제 시나리오대로 잘 동작하는지 테스트

4. TDD

Test-driven development
테스트가 주가 되어 개발하는 방법

적용 방식

보통은 개발하기 전 테스트 코드 작성 후 테스트가 동작하는 코드를 작성한다.(=TDD 방식)
하지만 나는 이미 개발된 코드를 바탕으로 단위 테스트를 추가하는 방식을 채택하였다.

기존 코드 & 기획서를 참고하여 사용자 시나리오를 작성한다.
테스트 코드를 작성한다.
테스트를 돌려보며 안전하게 코드 리팩토링를 한다.

1. 시나리오 작성

사용자 이벤트를 if문처럼 구분을 하여 각 이벤트에 발생하는 동작들을 작성하였다.
시나리오 내용은 크게 2가지로 나누어 볼 수 있다 :
이벤트가 발생한 컴포넌트 내부에서 일어나는 동작들 + 이로 인해 다른 컴포넌트에서 일어나는 동작들
앞서 말한 것처럼, 4개의 구분되어있는 컴포넌트끼리 사용자의 이벤트 동작에 따라 엮어있어서 시나리오가 꽤 복잡하게 나왔다.
초록색으로 하이라이트된 부분이 다른 컴포넌트에 끼치는 영향들이며, 이 동작들에 대해 테스트 코드를 작성할 예정이다.

2. 테스트 코드 작성

개발 환경

1. react-testing-library
- create-react-app 하면 기본으로 설치됨
- 테스트를 위해 실제 dom을 랜더링 하고 wrapper에 감싸여 있음
- DOM API 사용 가능
- 컴포넌트 내부에 있는 상태변경 로직에 따라 랜더링이 여러 번 되기 때문에 waitFor() 사용하여 화면이 랜더링 될 때까지 기다려야 함
- 랜더링 된 결과를 테스트하고 싶을 때 유용함

설치

npm install -d @testing-library/[원하는 패키지]

"devDependencies": {
    "@testing-library/dom": "^9.3.3",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10"
}

2. jest
- react-testing-library는 jest를 기본세팅으로 사용함
- 다양한 api 제공 (https://jestjs.io/docs/api)
- @testing-library/jest-dom 으로 dom 객체를 활용 가능

설치

"devDependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "jest-environment-jsdom": "^27.0.6",
    "ts-jest": "^29.0.0"
}

Jest config 설정

프로젝트 루트 > jest.config.js

module.exports = {
  verbose: true,
  testPathIgnorePatterns: ['<rootDir>/node_modules/(?!@custom-lib-name)'],
  rootDir: '/Users/me/Documents/my-project',
  testEnvironment: 'jsdom',
  coveragePathIgnorePatterns: ['src/components/index.ts']
};

- verbose : 개별 테스트 결과를 hierarchy로 보여줌
- testPathIgnorePatterns : 변환하지 않는 경로 (regex 가능)
- rootDir : 루트 디렉토리
- testEnvironment : 테스트 환경
- coveragePathIgnorePatterns : skip 할 테스트 적용 범위 (regex 가능)

Babel config 설정

yarn add --dev @babel/preset-typescript @types/jest

프로젝트 루트 > babel.config.js

module.exports = {
  presets: [
    ['@babel/preset-env', { targets: { node: 'current' } }],
    ['@babel/preset-react', { runtime: 'automatic' }],
    '@babel/preset-typescript'
  ]
};

테스트 파일 기본 구조

TestComponent.tsx

import React from "react";

const TestComponent = () => {
  return (
    <div>TestComponent</div>
  );
};

export { TestComponent };

TestComponent.test.js

1. 테스트하고자 하는 컴포넌트 랜더링

const RenderTestComponet = () => {
	return (<TestComponent />);
};

let container = null;
beforeEach(() => {
  container = document.createElement('div');
  document.body.appendChild(container);
  act(() => {
    render(<RenderTestComponet />, container);
  });
});
afterEach(() => {
  unmountComponentAtNode(container);
  container.remove();
  container = null;
});

1) react-dom/test-utils : act()

state가 변경되는 비동기 작업을 외부에서 하는 경우 act()를 사용하여 re-render 횟수를 줄인다.

2) jest lifecycle : beforeEach(), afterEach()

jest lifecycle 함수를 사용하여 여러 개 테스트 함수에서 같은 컴포넌트를 사용해야 할 때 같은 환경을 render 하여 테스트할 수 있다.
예시에서는 beforeEach & afterEach를 사용하여 매 테스트마다 같은 환경을 세팅하여 테스트하도록 하고 있다.

한 컴포넌트를 렌더링 하고 여러 테스트를 해당 컴포넌트 내에서 순차적으로 실행해야 한다면 beforeAll(), afterAll()를 사용하면 된다.
나는 아래와 같이 동일한 컴포넌트 내에서 실행되어야 하는 테스트 함수들을 describe()으로 묶어주었고,
테스트 실행 전 beforeAll(), afterAll()를 사용하여 컴포넌트를 render 해주었다.

describe('동일한 컴포넌트를 사용하는 테스트들 묶음', () => {
	let container = null;
        beforeAll(() => {
          container = document.createElement('div');
          document.body.appendChild(container);
          act(() => {
            render(<RenderTestComponet />, container);
          });
        });
        afterAll(() => {
          unmountComponentAtNode(container);
          container.remove();
          container = null;
        });
        describe('조건 1일 때,', () => {
            it('~~해야한다.', () => { ... 테스트 내용 })
        });
        describe('조건 2일 때,', () => {
            it('~~해야한다.', () => { ... 테스트 내용 })
        });
});

조건 1,2에 대한 테스트가 총 2가지가 있다.
먼저 TestComponent를 render 한 후, 조건 1 테스트 진행, 그리고 조건 2 테스트가 진행된다.

2. mocking

1) 모듈 mocking

jest.mock('react-router-dom', () => ({
    useLocation: jest.fn().mockReturnValue({
      pathname: '/another-route',
      search: '',
      hash: '',
      state: null,
      key: 'abcdefghi',
    }),
}));

React Router의 useLocation hook을 사용할 때 아래와 같은 에러 발생하였다.

"TypeError: Cannot read property 'location' of undefined"
이럴 땐, jest의 mock() 함수를 사용하여 모듈을 통째로 mock 할 수 있다.
이렇게 하면 useLocation()을 호출 시 내가 미리 세팅한 값이 반환된다.

2) 함수 mocking

import fetchUserData from '@remotes/fetchUserData';
const { data: userData = {} as IUserData } = fetchUserData();

위처럼, 테스트에서 render 된 컴포넌트 내부에서 fetchUserData()라는 함수로 외부 데이터를 불러오고 있다.
하지만 실제 데이터가 아닌 mock 데이터를 사용하도록 하고 싶다.

jest.mock('@remotes/fetchUserData', () => {
  return jest.fn(() => ({
    data: {
      name: 'test-user',
      id: 'test-user-id',
      age: 0
    }
  }));
});

TestComponent.test.js 에서 jest의 mock()를 사용해서 fetch 함수의 위치를 명시해 준 다음,
해당 함수를 jest.fn()으로 mocking 하여 원하는 값을 사용하게 할 수 있다.

3. 테스트 함수

describe('테스트 1', () => {
  describe('1. ~~ 했을 때', () => {
    describe('1-1. ~~ 인 경우', () => {
      it('~~~ 해준다.', async () => {
        await act(async () => {
          const element = await screen.getByTestId('info-div');
          const input = element.querySelector('input');

          await userEvent.clear(input);
          await userEvent.type(input, '입력 값');

          await waitFor(() => {
            expect(screen.getByDisplayValue('입력 값')).toBeInTheDocument();
          });
        });
      });
    });
  });
});

1) describe(), it()

describe에서는 조건문을, it에서는 테스트 내용을 작성한다.
참고로 describe 대신 xdescribe를 사용하면 해당 범위 내부의 테스트는 실행되지 않는다.

2) @testing-library/dom : getByTestId()

되도록이면 테스트할 때 필요한 element들에는 test-id를 주어 좀 더 쉽고 정확하게 해당 element를 찾을 수 있도록 한다.

3) @testing-library/user-event : userEvent

clear, type 등 화면 동작을 발생시킬 수 있다.
type 하기 전에 먼저 자동입력된 값이 있다면 이 값을 clear 한 후 type 해야 한다.

3) @testing-library/dom : waitFor()

컴포넌트 내부에서 발생하는 이벤트에 따라 랜더링이 바뀌는 경우,
waitFor()를 사용하여 화면이 랜더링 된 후 다음 동작을 실행해야 한다.

4) jest : expect()

조건에 만족하는지 최종적으로 확인하는 함수이다.

4. script 설정

package.json

{
  "scripts": {
	"test" : "jest",
	"coverage": "jest --coverage"
  }
}

그 외

1. tsconfig에서 설정한 path alias에 대한 경로 세팅

import 경로가 길 경우, '@path' 형식으로 alias를 설정해 주는 경우가 많은데,
테스트 설정 파일에서 경로에 alias로 설정한 경로가 어느 경로를 가리키는 건지 설정해줘야 한다.

tsconfig

"paths": {
      "@vip-app/*": ["./vip/app/*"],
      "@vip-pages/*": ["./vip/pages/*"]
    }

jest.config.js

moduleNameMapper: {
    '^@vip-app/(.*)$': '<rootDir>/src/base/vip/app/$1',
    '^@vip-pages/(.*)$': '<rootDir>/src/base/vip/pages/$1'
  }

moduleNameMapper에서 path 경로를 지정해 주었다.

2. 특정 라이브러리 global로 설정

테스트하고자 하는 컴포넌트 내에서 uuid를 계산하는 로직에서 crypto 라이브러리를 사용하고 있었다.
그러나 jest 테스트 중에서는 해당 라이브러리를 찾지 못해 아래와 같은 에러가 났다.

"ReferenceError: crypto is not defined"

이를 해결하기 위해선 jest.config.js에서 해당 라이브러리를 global로 설정해 주면 된다.

globals: {
    crypto: require('crypto')
}

3. jest test

1) jest --clearCache : 테스트 실행 전 캐쉬를 삭제한다.

2) jest --slient : 각종 warning 메세지를 skip하여 테스트 결과에 표시되지 않도록 한다.

3) jest test/{특정 파일 이름} : 테스트 파일이 여러개 있을 때 특정 파일만 테스트 돌릴 수 있다.

3. 테스트 코드를 활용하여 코드 리팩토링

힘들게 짠 테스트코드가 제일로 기특하게 느껴졌던 코드 리팩토링 과정..

https://kkangdda.tistory.com/131

[test tool 2-2] Jest+React+TypeScript - 이미 개발된 코드에 e2e test를 적용해보자 (+코드 리팩토링은 덤)

이전 글에서 사용자 시나리오 & 테스트 코드 작성에 대해 이야기하였다, 이 글에서는 3번 테스트 코드를 활용하여 코드 리팩토링을 한 경험에 대해 써보고자 한다! 기존 코드 & 기획서를 참고하

kkangdda.tistory.com

isFallback으로 로딩바 보여주기

kkangdda — Wed, 4 Oct 2023 19:18:41 +0900

https://nextjs.org/docs/pages/api-reference/functions/get-static-paths#fallback-pages

Functions: getStaticPaths | Next.js

Using Pages Router Features available in /pages

nextjs.org

next/router → router.isFallback으로 렌더링 인지 가능

const router = useRouter()

  if (router.isFallback) {
    return <div>Loading...</div>
  }

화면 처음 진입 시, getStaticProps 함수가 끝날 때까지 isFallback=true이기 때문에 이때 로딩바를 보여준다.

새 로고침해서 화면 진입 시 router.isFallback을 로그 찍어보면 true -> false 찍히고,
true일 때 로딩바가 표시되는 것을 확인할 수 있다.

error 페이지 커스텀

kkangdda — Tue, 3 Oct 2023 22:27:30 +0900

에러페이지를 서버에서 제공하는 경우 비용이 증가되고, 서버에서 가져오기 때문에 느리다.
next.js에서는 static 파일로 에러페이지를 제공하고 있고 커스텀도 가능하다.

next.js에서 기본적으로 제공해주는 에러페이지 모습

404 에러 페이지 커스텀

pages 하위에 404.tsx 생성 :

export default () => {
    return <div> 404에러 </div>
}

빌드를 하면 404 페이지가 정적으로 생성된다.

커스텀한 에러 페이지

server 에러 페이지 커스텀

404와 같은 client 에러는 static으로 만들어서 불필요한 서버 호출 막는 게 좋다.
하지만, 500에러와 같은 server 에러는 보통 정적으로 제공하지 않는다.
에러가 났을 때 서버에 로그를 찍는 등 서버로 에러를 보내는 경우가 많기 때문이다.

이에 맞춰 error 컴포넌트로 server 에러 페이지를 커스텀하는 게 좋다.

pages 하위에 _error.tsx 생성 :

export default function Error({ statusCode }: { statusCode: any})  {
    return (
        <p>
            {statusCode
                ? `An error ${statusCode} occurred on server`
                : 'An error occurred on client'}
        </p>
    )
}

Error.getInitialProps = ({ res, err }: { res: any, err: any }) => {
    const statusCode = res ? res.statusCode : err ? err.statusCode : 404
    return { statusCode }
}

앞서 만들어 두었던 404.tsx 파일을 남겨두었기 때문에 404 에러일 때는 해당 페이지로 넘어가고,
그 외 에러는 error 컴포넌트를 보여주는 방식으로 구성하였다.

참고로 서버에러 같은 경우는 개발모드일 때는 에러로그를 보여주기 때문에,
커스텀한 에러페이지를 확인하고 싶으면 빌드 후 확인해야 한다.

npm run build & npm run start

pages-router에서의 pre-rendering 적용 (정적 생성, SSR)

kkangdda — Tue, 3 Oct 2023 22:03:36 +0900

pre-rendering

Next.js의 모든 페이지는 기본적으로 사전 렌더링을 한다.
더 좋은 퍼포먼스
검색 엔진 최적화 (SEO)

pre-rendering의 2가지 렌더링 방식
둘의 차이는 = 언제 html 파일을 생성하는가?

1) 정적 생성 (static generation)
- 프로젝트 빌드하는 시점에 html 파일 생성
- 모든 요청에 파일들을 재사용함
- 퍼포먼스 이유로 next.js는 정적 생성을 권고함
- 정적 생성된 페이지들은 CDN에 캐시 됨
- 주요 함수 : getStaticProps, getStaticPath

2) server side rendering (SSR, dynamic rendering)
- 매 요청마다 html 생성
- 항상 최신 상태 유지
- 주요 함수 : getServerSideProps

초기에는 아무것도 없는 상태 -> JavaScript가 로드된 이후 -> 페이지 안 요소들을 채움

초기에는 사전에 만든 HTML요소들이 있음 (+meta) -> JavaScript가 로드된 이후 -> Link와 같이 interactive한 컴포넌트들이 채워짐 (=hydration)

server side rendering 적용 전

api 호출 후 → 페이지에 데이터를 넣어주는 방식

페이지 소스 보기

껍데기만 pre-rendering 된 상태이며, api 호출해서 얻은 데이터 정보는 들어가 있지 않다.

1-1. getStaticProps > 정적 생성 방식 사용 (목록 페이지)

<before>

export default function Page() {

    const [list, setList] = useState([]);

    const API_URL = process.env.NEXT_PUBLIC_API_URL as string;
    const getData = () => {
        Axios.get(API_URL).then((res: any) => setList(res.data));
    }

    useEffect(() => {
        getData();
    }, []);

 return (
     <div>
      <Head>
       <title>@제목제목@</title>
      </Head>
      <h1>This is Page Router Homepage!</h1>
         <ItemList list={list} />
     </div>
 )
}

useEffect()를 써서 페이지 진입 시, api 호출 후 데이터를 useState에 넣어주고 화면에 표시해 주었다.

JavaScript 차단한 상태에서는 목록 데이터가 표시되지 않는다.

<after>

export default function Page({list}: { list: any }) {
    return (
        <div>
            <Head>
                <title>@제목제목@</title>
            </Head>
            <h1>This is Page Router Homepage!</h1>
            {list && (<ItemList list={list}/>)}
        </div>
    )
};

export const getStaticProps = async () => {
    const API_URL = process.env.apiUrl as string;
    const res = await Axios.get(API_URL);
    const data = res.data;

    // 응답 값을 Post에게 props로 넘겨줄 수 있음
    return {
        props: {
            list: data,
            name: process.env.name
        }
    }
}

'getStaticProps' 사용하여 응답 값을 props로 넘겨주어 화면에 데이터를 표시해 주었다.

JavaScript가 차단된 상태에서도 데이터가 정상적으로 표시되는 것 확인 가능하다.
또한, 페이지 소스 보기를 해보면 데이터들이 들어가 있다. 이는 미리 만들어진 static 한 html를 제공하고 있기 때문이다.

빌드해서 정적 생성된 파일 확인해 보기 :

npm run build

build 후, index.html이 생성되어 있는 것을 확인할 수 있다.

npm run start // 빌드된 파일 실행

index.html은 미리 만들어진 html이고, 캐싱되기 때문에 새로고침 할수록 로딩시간이 점점 짧아진다.

1-2. getStaticProps + getStaticPath > 정적 생성 방식 사용 (상세 페이지)

getStaticPath를 사용해서 dynamic path를 사용할 수도 있다.

export default ({item, name} : {item: any, name: string}) => {
    return (
        <>
            {item && (
                <>
                    <Head>
                        <title>{item.name}</title>
                        <meta name="desc" content={item.description} />
                    </Head>
                    {name} 환경임!
                    <Item item={item} />
                </>
            )}
        </>
    );
}

// dynamic paths
export const getStaticPaths = async () => {
    return {
        paths: [
            {params: {id: '495'}},
            {params: {id: '477'}}
        ],
        fallback: false
    };
}

export const getStaticProps = async(context: any  ) => {
    const id = context.params.id;
    const API_URL = `http://makeup-api.herokuapp.com/api/v1/products/${id}.json`;
    const res = await Axios.get(API_URL);
    const data = res.data;
    return {
        props: {
            item: data,
            name: process.env.name
        }
    }
}

id = 495, 477로 path를 미리 지정해 주면 아래와 같이 해당하는 정적페이지가 build시 미리 생성된다.

npm run buld

지정해준 id에 대한 html, json 파일이 미리 만들어져있음

+ fallback 속성

fallback: false

getStaticPaths 함수 내에서 fallback을 false로 주었는데, 이렇게 하면 495, 477 외 다른 아이템을 눌렀을 시 404 에러가 뜬다.

fallback: true

true로 지정할 경우, 미리 지정한 id 외 다른 id의 상세페이지로 들어가면 pre-rendering 목록에 해당 상세페이지를 만들어놔서 그 후부터는 정적으로 생성된 페이지를 사용한다.

ex. path에 미리 지정한 477, 495 id 외에 488에 대한 상세페이지도 정적 파일로 생성되었다.

https://kkangdda.tistory.com/129

isFallback으로 로딩바 보여주기

https://nextjs.org/docs/pages/api-reference/functions/get-static-paths#fallback-pages Functions: getStaticPaths | Next.js Using Pages Router Features available in /pages nextjs.org next/router → router.isFallback으로 렌더링 인지 가능 const route

kkangdda.tistory.com

2. getServerSideProps > server side rendering 방식 사용 (상세 페이지)

title, meta에 api 호출 데이터의 name, description을 넣어서 SSR 전, 후를 비교하고자 한다.

<>
  <Head>
     <title>{item.name}</title>
     <meta name="desc" content={item.description} />
  </Head>
     <Item item={item} />
</>

<before>

export default () => {
    const router = useRouter();
    const {id} = router.query;

    const [item, setItem] = useState({});

    const API_URL = `http://makeup-api.herokuapp.com/api/v1/products/${id}.json`;

    const getData = () => {
        Axios.get(API_URL).then((res: any) => setItem(res.data));
    }

    useEffect(() => {
        if (id) {
            getData();
        }
    }, [id]);

    return <Item item={item} />;
}

예전과 같이, useEffect를 써서 api 호출 후 받은 데이터를 화면에 표시해 준다.

페이지 소스 보기

<title></title><meta name="desc" content=""/>

title, meta 모두 비어있는 상태이다.

<after>

export default ({item} : {item: any}) => {
    return (
        <>
            <Head>
                <title>{item.name}</title>
                <meta name="desc" content={item.description} />
            </Head>
            <Item item={item} />
        </>
    );
}

export const getServerSideProps = async(context: any  ) => {
    const id = context.params.id;
    const API_URL = `http://makeup-api.herokuapp.com/api/v1/products/${id}.json`;
    const res = await Axios.get(API_URL);
    const data = res.data;

    // 응답 값을 Post에게 props로 넘겨줄 수 있음
    return {
        props: {
            item: data
        }
    }
}

'getServerSideProps' 사용하여 응답 값을 props로 넘겨주어 화면에 데이터를 표시해 주었다.

페이지 소스 보기

<title>Maybelline Face Studio Master Hi-Light Light Booster Bronzer</title>
<meta name="desc" content="Maybelline Face Studio Master Hi-Light Light Boosting bronzer formula has an expert 
balance of shade + shimmer illuminator for natural glow. Skin goes 
soft-lit with zero glitz.
		For Best Results: Brush over all shades in palette and gently sweep over 
cheekbones, brow bones, and temples, or anywhere light naturally touches
 the face."/>

요청 시 서버에서 데이터를 가져온 후 html을 생성해서 페이지를 보여주기 때문에,
title과 meta에 api 호출하여 받은 데이터값이 들어가 있다.

추가로 JavaScript를 꺼보고 상세화면에 들어가 봤는데, 데이터가 여전히 제대로 표시되고 있다.

3. next/link의 prefetch

<Link href="/dashboard" prefetch={true}>
      Dashboard
</Link>

아이템에 링크를 걸기 위해 next/link의 Link 태그를 사용하였는데, 여기에는 prefetch라는 속성이 있다.
(default=true, production모드에서만 사용 가능)
이 기능 덕분에, 사용자가 보는 화면 영역(viewport) 안에 들어오는 link에 걸려있는 내용들은 모두 preload 된다.

예를 들어, 사용자가 스크롤하면 화면에 들어오는 link들에 대한 페이지들은 사진과 같이 정적파일로 생성된다.
미리 pre-fetch 하여 정적파일로 생성하기 때문에 사용자가 실제로 클릭 시 빠른 화면 전환이 가능해진다.

참고 :

https://www.youtube.com/playlist?list=PLZKTXPmaJk8Lx3TqPlcEAzTL8zcpBz7NP

https://nextjs.org/learn/foundations/about-nextjs

https://nextjs.org/

[CI/CD적용기3] 프로젝트 build - 로컬 vs Dockerfile vs Github Actions

kkangdda — Thu, 7 Sep 2023 23:04:45 +0900

Github Actions를 사용하기 앞서 세팅해줘야하는 내용은 이전 포스트 참고

2023.09.07 - [ ETC/CICD] - [CI/CD적용기2] Docker + Github Actions으로 배포 자동화

[CI/CD적용기2] Docker + Github Actions으로 배포 자동화

목표 : - Github Actions를 사용하여 CI/CD를 구축한다 - workflow : - build my project -> login to my Docker hub -> build and push my Image - 즉, 빌드한 결과물을 Docker Image로 만들어서 내 Docker Hub으로 push 하는 일련의 작

kkangdda.tistory.com

Github Action 코드를 짜다 보니, 프로젝트 빌드하는 과정을 어떤 식으로 해야지 효율적인지 궁금해졌다.
빌드하는 부분을 총 3번의 다른 방식으로 구성해 보았고, Github Action의 걸린 시간을 살펴보았다.

첫 번째 방식, 로컬 pc에서 내가 직접 프로젝트 build -> Github Action에서 나머지 작업 자동화

Dockerfile

# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.
FROM nginx

# root 에 app 폴더를 생성
RUN mkdir /app

# work dir 고정
WORKDIR /app

# work dir 에 build 폴더 생성 /app/build
RUN mkdir ./build

# host pc의 현재경로의 build 폴더를 workdir 의 build 폴더로 복사
ADD ./build ./build

# nginx 의 default.conf 를 삭제
RUN rm /etc/nginx/conf.d/default.conf

# host pc 의 nginx.conf 를 아래 경로에 복사
COPY ./nginx.conf /etc/nginx/conf.d

# 80 포트 오픈
EXPOSE 80

# container 실행 시 자동으로 실행할 command. nginx 시작함
CMD ["nginx", "-g", "daemon off;"]

github-action.yml

name: WORKFLOW_FOR_DOCKER

on:
  push:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  # 1. 빌드 머신 준비
  build:
    runs-on: ubuntu-latest

    steps:
      # 2. 빌드 머신에 Repository Check Out
      - uses: actions/checkout@v3

      - name: Start Actions
        run: echo Start Actions!

      # 3. Docker Meta를 이용하여 생성할 이미지의 이름과 버전 정보 태깅 
      - name: Docker meta
        id: docker_meta
        uses: crazy-max/ghaction-docker-meta@v1
        with:
          images: iDaeun/daeun-portfolio-app
          tag-semver: |
            {{version}}
            {{major}}.{{minor}}

      # 4. 빌드 머신에 Docker 빌드에 필요한 사항 준비
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
        
      # 5. 이미지를 업로드 할 내 도커허브 로그인
      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
          
      # 6. 도커 이미지 빌드하고 허브로 푸쉬
      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          platforms: linux/amd64
          push: true
          tags: ${{ steps.docker_meta.outputs.tags }}
          labels: ${{ steps.docker_meta.outputs.labels }}

      - name: Finish Git Actions
        run: |
          echo Finished All Actions  
          echo Please Check Your Docker Hub!

on > push > branch ["main"] : main 브랜치에 코드를 푸쉬하면 Github Action이 yml 파일에 정의한 작업내용에 따라 실행된다.
먼저 프로젝트를 빌드해 놓을 뒤 main 브랜치에 강제로 test 코드를 푸쉬하여 Github Action이 시작되도록 하였다.

그 결과, 걸린 시간 : 22초

두 번째 방식, Dockerfile 내부에서 프로젝트 build 자동화 -> Github Action에서 나머지 작업 자동화

Dockerfile

## builder
FROM node:17-alpine AS builder

# work dir 고정
WORKDIR /app

COPY package-lock.json ./
COPY package.json ./
RUN npm ci

COPY . ./
RUN npm run build

# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.
FROM nginx

# host pc의 현재경로의 build 폴더를 workdir 의 build 폴더로 복사
COPY --from=builder /app/build /app/build

CMD ["ls", "-al"]

# nginx 의 default.conf 를 삭제
RUN rm /etc/nginx/conf.d/default.conf
# host pc 의 nginx.conf 를 아래 경로에 복사
COPY ./nginx.conf /etc/nginx/conf.d

# 80 포트 오픈
EXPOSE 80

# container 실행 시 자동으로 실행할 command. nginx 시작함
CMD ["nginx", "-g", "daemon off;"]

--from : 새로운 빌드 스테이지를 뜻한다.
'builder'라고 정해준 스테이지에서 node를 사용해 주었고, 그 아래 새로운 스테이지에서 nginx를 사용하였다.

이렇게 해서 아래와 같은 순서로 실행되도록 하였다 :
1. 첫 번째 스테이지 (builder) : node사용하여 npm으로 프로젝트 빌드 (이전에는 내가 직접 로컬 pc에서 빌드했던 과정)
2. 두 번째 스테이지 : builder 스테이지에서 빌드한 결과물을 COPY 하여 가져오고, nginx로 Docker Image 빌드

github-action.yml > 첫 번째 방식과 동일함

그 결과, 걸린 시간 : 1분 23초

세 번째 방식, Github Action에서 프로젝트 build + Docker 작업 모두 자동화

Dockerfile

# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.
FROM nginx

# work dir 고정
WORKDIR /app

# host pc의 현재경로의 build 폴더를 workdir 의 build 폴더로 복사
ADD ./build ./build

# nginx 의 default.conf 를 삭제
RUN rm /etc/nginx/conf.d/default.conf

# host pc 의 nginx.conf 를 아래 경로에 복사
COPY ./nginx.conf /etc/nginx/conf.d

# 80 포트 오픈
EXPOSE 80

# container 실행 시 자동으로 실행할 command. nginx 시작함
CMD ["nginx", "-g", "daemon off;"]

두 번째 방식에서 추가해 줬던 프로젝트 빌드 과정을 삭제했다.

github-action.yml

name: WORKFLOW_FOR_DOCKER

on:
  push:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  # 1. 빌드 머신 준비
  build:
    runs-on: ubuntu-latest

    steps:
      # 2. 빌드 머신에 Repository Check Out
      - uses: actions/checkout@v3

      - name: Start Actions
        run: echo Start Actions!

      ## 개선 ##
      - uses: actions/setup-node@v3
        with:
          node-version: 16.14.2
      - run: npm ci
      # - run : npm test (build 보다 먼저 test 실행)
      - run: npm run build

      - name: Log Test
        run: ls -al
        shell: bash
      #########

      # 3. Docker Meta를 이용하여 생성할 이미지의 이름과 버전 정보 태깅 
      - name: Docker meta
        id: docker_meta
        uses: crazy-max/ghaction-docker-meta@v1
        with:
          images: iDaeun/daeun-portfolio-app
          tag-semver: |
            {{version}}
            {{major}}.{{minor}}
      # 4. 빌드 머신에 Docker 빌드에 필요한 사항 준비
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
        
      # 5. 이미지를 업로드 할 내 도커허브 로그인
      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
          
      # 6. 도커 이미지 빌드하고 허브로 푸쉬
      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          platforms: linux/amd64
          push: true
          tags: ${{ steps.docker_meta.outputs.tags }}
          labels: ${{ steps.docker_meta.outputs.labels }}

      - name: Finish Git Actions
        run: |
          echo Finished All Actions  
          echo Please Check Your Docker Hub!

Github Action workflow에는 아래의 코드만 추가해 주었다 :

      ## 개선 ##
      - uses: actions/setup-node@v3
        with:
          node-version: 16.14.2
      - run: npm ci
      # - run : npm test (build 보다 먼저 test 실행)
      - run: npm run build

      - name: Log Test
        run: ls -al
        shell: bash
      #########

이는 node를 사용하여 npm install & build를 해주는 과정이다.
두 번째 방식에서는 Dockerfile에 해당 과정을 넣어주었다면, 이번에는 Github Action에 넣어준 것이다.

그 결과, 걸린 시간 : 1분

Github Actions에서 걸린 시간만 보면 첫 번째 방식이 제일 짧았지만, 이는 로컬에서 프로젝트를 빌드하는 시간을 뺀 시간이다.
그리고 나는 프로젝트 빌드하는 과정 또한 자동화하고 싶었기 때문에, 두 번째와 세 번째 방식이 내가 원하는 방향이다.

두 방식은 프로젝트 빌드를 하는 주체만 다른데, 하나는 Dockerfile에서, 다른 하나는 Github Actions에서 실행한다.
두 방식의 시간차는 약 23초로, Github Actions workflow에서 프로젝트 빌드를 해주는 게 더 빨랐다.

생각해 보면 Dockerfile에서 프로젝트 빌드를 하기 위해서는 프로젝트의 모든 소스를 COPY 한 뒤에 이를 빌드하는 방식이다.
그에 반해 Github Actions에는 소스를 COPY 할 필요 없이 바로 npm install & build를 할 수 있다.

물론 더 추가해야 하는 부분은 많지만, 프로젝트 빌드 자동화를 생각으로만 해보다가 직접 구성해 보고 개선시켜 보니 Github Actions를 이해할 수 있는 좋은 기회였다.

[CI/CD적용기2] Docker + Github Actions으로 배포 자동화

kkangdda — Thu, 7 Sep 2023 22:19:38 +0900

목표 :
- Github Actions를 사용하여 CI/CD를 구축한다
- workflow :
- build my project -> login to my Docker hub -> build and push my Image
- 즉, 빌드한 결과물을 Docker Image로 만들어서 내 Docker Hub으로 push 하는 일련의 작업을 자동화한다.
(https://kkangdda.tistory.com/121 > 기존에 직접 손으로 했던 내용을 Github Action으로 자동화)

1. Github Action workflow yml파일 생성

자신의 repository > Actions > set up a workflow yourself 를 누르면 .github/workflow 하위에 yml 파일을 작성할 수 있다.

- workflow : 가장 상위 개념 = 자동화 작업 과정
- job : 독립된 환경에서 실행되는 작업들의 묶음
- 하나의 workflow 안에서 job 단위로 완전히 격리된 환경(가상머신 또는 컨테이너)에서 실행됨
- 병렬처리 가능해짐 -> 성능 올라감
- 여러 실행환경에서 실행할 수 있음 (ex. 리눅스, 윈도우즈)
(job을 설정하는 부분은 이 포스트 참고 : https://www.daleseo.com/github-actions-jobs/)
- step : 하나의 job 안에서 순차적으로 실행되는 단계
- action : 작업 공유 메커니즘, Github Marketplace에서 다양한 action을 사용할 수 있음

내가 작성한 github-action.yml

name: WORKFLOW_FOR_DOCKER

on:
  push:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  # 1. 빌드 머신 준비
  build:
    runs-on: ubuntu-latest

    steps:
      # 2. 빌드 머신에 Repository Check Out
      - uses: actions/checkout@v3

      - name: Start Actions
        run: echo Start Actions!

      # 3. Docker Meta를 이용하여 생성할 이미지의 이름과 버전 정보 태깅 
      - name: Docker meta
        id: docker_meta
        uses: crazy-max/ghaction-docker-meta@v1
        with:
          images: iDaeun/daeun-portfolio-app
          tag-semver: |
            {{version}}
            {{major}}.{{minor}}

      # 4. 빌드 머신에 Docker 빌드에 필요한 사항 준비
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
        
      # 5. 이미지를 업로드 할 내 도커허브 로그인
      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
          
      # 6. 도커 이미지 빌드하고 허브로 푸쉬
      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          platforms: linux/amd64
          push: true
          tags: ${{ steps.docker_meta.outputs.tags }}
          labels: ${{ steps.docker_meta.outputs.labels }}

      - name: Finish Git Actions
        run: |
          echo Finished All Actions  
          echo Please Check Your Docker Hub!

2. 필요한 Secret 등록

Docker Hub에 이미지를 push 해야 하기 때문에 로그인할 때 필요한 내용을 아래와 같이 Secret으로 등록해줘야 한다.

등록된 Secret Key로 Github Action workflow yml 내에서 참조하여 사용한다.

username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}

3. Docker에 관련된 파일은 이전 포스트 참고

2023.09.07 - [ ETC/CICD] - [CI/CD적용기1] React앱을 Docker Image으로 생성 후 Docker hub에 업로드

[CI/CD적용기1] React앱을 Docker Image으로 생성 후 Docker hub에 업로드

목표: - 어플리케이션을 빌드한 결과물을 Docker Image로 만든다. - Docker Image를 내 Docker Hub repository에 올린다. - 로컬 pc에서 Docker Hub에 올린 Image를 pull 받아서 실행한다. 1. React 앱 생성 (create-react-app)

kkangdda.tistory.com

4. Run Github Actions !

main 브랜치에 코드를 푸쉬하면 Github Action이 yml 파일에 정의한 작업내용에 따라 실행된다.
먼저 프로젝트를 빌드해 놓은 뒤 main 브랜치에 강제로 test 코드를 푸쉬하여 Github Action이 시작되도록 하였다.

steps 내에서 내가 정의한 작업 name들을 확인할 수 있다.
작업들이 끝난 뒤, docker hub으로 가면 내가 빌드한 프로젝트가 Docker Image로 빌드되어 올라간 걸 확인할 수 있다.
로컬에서 해당 Docker Image를 pull 받아 띄워보는 것까지 끝!

[CI/CD적용기1] React앱을 Docker Image으로 생성 후 Docker hub에 업로드

kkangdda — Thu, 7 Sep 2023 22:17:43 +0900

목표:
- 어플리케이션을 빌드한 결과물을 Docker Image로 만든다.
- Docker Image를 내 Docker Hub repository에 올린다.
- 로컬 pc에서 Docker Hub에 올린 Image를 pull 받아서 실행한다.

1. React 앱 생성 (create-react-app)

2. 빌드

npm build

3. Docker를 사용하기 위해 프로젝트 루트에 Dockerfile, nginx.conf 파일 생성

Dockerfile

# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.
FROM nginx

# root 에 app 폴더를 생성
RUN mkdir /app

# work dir 고정
WORKDIR /app

# work dir 에 build 폴더 생성 /app/build
RUN mkdir ./build

# host pc의 현재경로의 build 폴더를 workdir 의 build 폴더로 복사
ADD ./build ./build

# nginx 의 default.conf 를 삭제
RUN rm /etc/nginx/conf.d/default.conf

# host pc 의 nginx.conf 를 아래 경로에 복사
COPY ./nginx.conf /etc/nginx/conf.d

# 80 포트 오픈
EXPOSE 80

# container 실행 시 자동으로 실행할 command. nginx 시작함
CMD ["nginx", "-g", "daemon off;"]

nginx.conf

server {
    listen 80;
    location / {
        root    /app/build;
        index   index.html;
        try_files $uri $uri/ /index.html;
    }
}

80 포트에 / 경로로 들어오면 /app/build 폴더에서 index.html 을 찾음

4. Docker Image로 빌드

# 이미지 이름 = 식별자 / 이름
sudo docker build --tag idaeun/daeun-portfolio-app .

주의!
Docker Hub에 이미지를 올리기 위해서는 이미지 이름에 식별자로 도커허브 ID를 추가해야한다!
(예제에서는 'idaeun')

# 이미지 확인
docker images

번외 ) [error] credential

Dockerfile:1
--------------------
   1 | >>> FROM nginx
   2 |
   3 |     # root 에 app 폴더를 생성
--------------------
ERROR: failed to solve: nginx: error getting credentials - err: exit status 1, out: ``

[해결] Docker config 삭제 뒤 다시 로그인

cat ~/.docker/config.json
{
	"auths": {
		"https://index.docker.io/v1/": {}
	},
	"credsStore": "desktop",
	"currentContext": "desktop-linux"
}%

rm ~/.docker/config.json
docker login
docker build

5. Docker Hub에 내 Image push

sudo docker push idaeun/daeun-portfolio-app

Docker Hub에 올라간 모습

번외 ) [error] denied

denied: requested access to the resource is denied

[해결] Docker 로그인

docker login

6. Docker Container 실행

# -d = 백그라운드 모드
# -p 8300:80 = 포트 연결 (외부 노출 포트 : 내부 포트)
sudo docker run -d --name 컨테이너이름 -p 8300:80 이미지이름

7. 로컬 PC > localhost:8300에서 확인

[DVA-C02] AWS Certified Developer Associate 자격증 후기

kkangdda — Sun, 6 Aug 2023 18:20:17 +0900

AWS에서는 위와 같이 단계별로 자격증 시험을 제공하고 있다.
나는 클라우드 도메인에 대한 지식을 쌓기 위해 회사에서 추천받은 AWS Developer Associate 자격증을 준비했다.

참고로 Developer Associate는 최근 DVA-C01에서 DVA-C02로 바뀌었고,
해당 버전의 시험에 대한 후기는 그리 많지 않았다.
하지만 유명한 자격증인만큼 강의도 많고 문제 자료도 많으니 걱정할 필요 없다!

준비기간은 약 1달 반, 출근 전 매일 한 시간씩 공부했고 주말에는 3시간 정도 시간 내서 공부하였다.
참고로 기존에 AWS 운영 경험이 있거나 다른 AWS관련 자격증이 있는 사람이라면 더 수월할 것 같다. ~~(당연한 얘기)~~

아래와 같이 두 가지 자료로 공부했다 :

1. 유데미 강의

https://www.udemy.com/course/best-aws-certified-developer-associate/

- 한글 자막 제공
- 이론 강의 + 실습 영상 제공
- 주제 별 모의 테스트 제공
- 마지막 실전 테스트 제공 (처음에 많이 틀려도 다시 한번 풀어보기!)

정리의 흔적..

노션에 강의 주제별로 정리하면서 공부하였고, PDF도 같이 제공하고 있기 때문에 참고해가면서 이론적인 부분을 정리했다.
이론 강의 후에는 실습 영상도 있는데, 시험만을 위하면 굳이 보지 않아도 되지만 AWS를 공부하는 것에 중점을 두었기 때문에 2배속으로 켜두고 최대한 실습까지 다 보려고 했다.

2. 덤프 문제

https://www.examtopics.com/

Free Exam Prep By IT Professionals | ExamTopics

ExamTopics The only source for free & accurate actual exam questions & answers, passing your exam easily is guaranteed, and for free!

www.examtopics.com

마지막 주에는 덤프 문제들만 계속 풀었다.
사이트에서 제공하는 답안보다는 커뮤니티 투표에서 사람들이 가장 많이 뽑은 답을 참고하였다.
사람들이 열정적으로 설명해놓았기 때문에 Community Discussion도 같이 보는 것을 추천한다.

문제를 3회독 하였고, 오답도 노션에 따로 정리했다.
답변을 외우기 보단 정답을 이해하는 게 중요한 것 같다 (물론 이해 안 가는 건 그냥 외웠..)

마지막까지 시험을 미룰까 말까 고민했었다 (2번까지 미룰 수 있는 걸로 알고 있음)
왜냐하면 유데미에서 실전 문제를 풀었을 때 60% 정도밖에 안 나왔고... 덤프문제는 더 어려워서 거의 틀렸었고..
하지만 다행히도 공부한 부분에서 많이 나왔기 때문에 수월하게 풀 수 있었다!

시험 꿀팁이 있다면
- 덤프를 많이 풀면 풀수록 좋다 (시험에서 덤프 문제가 많이 나왔다. 그 외엔 평소에 공부한 부분에서 나왔다.)
- AWS 서비스 & 키워드 정리하기 (ex. Cognito 사용자풀, Cognito 자격증명풀 -> 차이점, 특징)
- 시험문제가 길 수도 있는데 그중 키워드를 잘 뽑아내야 한다 (ex. 순환되는 자격증명 -> AWS Secret Manager)
- 질문의 포인트를 이해해야 한다 (ex. 최소한의 관리 오버헤드로, 최소한의 개발 노력으로 등등)

네트워크 스루풋 측정 (feat. iperf3 말고 iperf..)

kkangdda — Mon, 12 Jun 2023 20:00:09 +0900

https://repost.aws/knowledge-center/network-throughput-benchmark-linux-ec2

Benchmark network throughput between EC2 Linux instances in the same VPC

I want to measure the network bandwidth between Amazon Elastic Compute Cloud (Amazon EC2) Linux instances in the same Amazon Virtual Private Cloud (Amazon VPC). How can I do that?

repost.aws

참고하여 iperf3대신 iperf로 테스트하였다.

iperf는 2.x버전이고, iperf3은 3.x버전을 뜻하는데, iperf를 사용하는 이유는 :
- 2.x버전이 멀티쓰레드를 지원함
- 3.x버전에서 -P태그로 parallel stream을 사용할 수 있지만, 3.x버전은 싱글쓰레드이고 싱글CPU에 의해 제한이 있음

따라서 각 서버(ubuntu)에 iperf를 설치하였다.

apt-get install -y iperf

VPC간 TCP 네트워크 성능 테스트

2023.06.10 - [ WEB지식/Network] - NCP에서 VPC Peering 구축하기

NCP에서 VPC Peering 구축하기

VPC Peering 란? (VPC 간 사설 통신망 Peering) "인터넷 통신을 거치지 않고 비공인 IP를 통해서 내부 네트워크로 다른 VPC와 통신하도록 하는 기술" 즉, 2개 이상의 VPC를 연결하고 싶을 때 사용할 수 있다.

kkangdda.tistory.com

앞전에 NCP에서 peering한 VPC끼리 테스트를 진행하였다.

1. 서버

iperf -s [-p 5001]

2. 클라이언트

$ iperf -c 상대방주소 --parallel 40 -i 1 -t 2

--parallel 40 : 40 Threads (test with 40 parallel connections)
-i 1 : log interval 1 second
-t 2 : total test time 2 seconds

결과

테스트 instance 스펙
- s2-g2-s50(vCPU 2EA, Memory 8GB, [SSD]Disk 50GB)
- mtu 8950

root@pub-vm-b:~# iperf -c 10.0.0.6 --parallel 40 -i 1 -t 2 -p 5001
------------------------------------------------------------
Client connecting to 10.0.0.6, TCP port 5001
TCP window size:  520 KByte (default)
------------------------------------------------------------
[  3] local 10.100.0.6 port 45534 connected with 10.0.0.6 port 5001
[ 12] local 10.100.0.6 port 45554 connected with 10.0.0.6 port 5001
[  5] local 10.100.0.6 port 45538 connected with 10.0.0.6 port 5001
[  4] local 10.100.0.6 port 45536 connected with 10.0.0.6 port 5001
[ 13] local 10.100.0.6 port 45552 connected with 10.0.0.6 port 5001
[ 41] local 10.100.0.6 port 45610 connected with 10.0.0.6 port 5001
[  7] local 10.100.0.6 port 45542 connected with 10.0.0.6 port 5001
...
[SUM]  0.0- 1.0 sec   159 MBytes  1.33 Gbits/sec
[SUM]  1.0- 2.0 sec   125 MBytes  1.05 Gbits/sec
[SUM]  0.0- 2.2 sec   284 MBytes  1.06 Gbits/sec

---> 대역폭은 1.06 Gbits/sec 으로 나왔다.