프로찍먹러

무중단 배포에 대해 알아보자.

1. 무중단 배포란?

말 그대로 애플리케이션의 중단 없이 배포를 하는 것을 말한다. 

애플리케이션은 언제 중단될까?

v1 서비스가 실행 중일 때 v2 버전을 다운로드 받는다.
v1 서비스를 종료 시키는 시점부터 v2를 시작하기 전까지 애플리케이션은 중단된다.
이렇게 서비스가 중단되는 시간을 다운타임(downtime)이라고 한다.

이런 문제를 해결하기위해 무중단 배포라는 개념이 나왔고 크게 3가지 방법이 있다.

2. 무중단 배포 기법

1. Rolling 배포

롤링 배포는 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체하는 것으로 무중단 배포의 가장 기본적인 방식이다.

서비스 중인 인스턴스 하나를 로드밸런서에서 라우팅하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅하도록 한다.

이를 반복하여 모든 인스턴스에 새 버전의 애플리케이션을 배포한다.

위 움짤을 보면

1. 4개의 기존 버전(v0.0.1)이 있다.

2. 그 중에 2개의 라우팅을 끊고 업데이트 버전(v0.0.2)로 업그레이드 한다.

3. 업데이트 버전이 배포가 되면 다시 라우팅을 시작한다.

4. 나머지 2개 인스턴스의 라우팅을 끊고 업데이트 버전을 배포한다.

5. 나머지 2개의 인스턴스의 업데이트가 끝나면 다시 라우팅을 연결한다.

장점

• 인스턴스마다 차례로 배포를 진행하기에 상황에 따라 손쉽게 롤백이 가능하다.
• 추가적인 인스턴스를 늘리지 않아도 된다.
• 간편한 관리

단점

• 새 버전을 배포할때 인스턴스의 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있다. 즉, 서비스 처리 용량을 고려해야 한다. 위 움짤에서 2번과정, 4번과정에서 4개의 인스턴스에서 감당하던 트래픽이 2개의 인스턴스로 몰리는 경우이다.
• 배포가 진행될때 구버전과 신버전이 공존하기에 호환성 문제가 발생할 수 있다. 위 움짤에서 3번과정에서 업데이트 된 버전2개, 안된버전 2개가 공존하므로 사용자들은 균일한 서비스를 받지 못한다.

2. Blue Green 배포

블루는 구버전, 그린은 신버전을 의미한다.

운영중인 구버전과 동일하게 신버전의 인스턴스를 구성한 후 로드밸런서를 통해 모든 트래픽을 한번에 신버전 쪽으로 전환하는 방식이다.

장점.

• 구버전의 인스턴스가 그대로 남아있어서 손쉬운 롤백이 가능하다.
• 구버전의 환경을 다음 배포에 재사용할 수 있다.
• 운영환경에 영향을 주지 않고 새 버전 테스트 가능.

단점.

• 시스템 자원이 두배로 필요하다.
• 새로운 환경에 대한 테스트가 전제되어야 한다.

3. 카나리 배포

옛날 광부들이 유독 가스에 민감한 카나리아 새를 이용해 가스 누출 위험을 감지했던 것에서 유래한 것으로 잠재적 문제 상황을 미리 발견하기 위한 방식이다.

신버전을 소수의 유저들에게만 배포를 해보고 문제가 없는것을 확인해가며 점차 많은 유저들에게 배포하는 기법이다.

블루그린 배포와 유사하지만 블루그린처럼 트래픽을 한번에 확 바꾸는 것이 아니라 단계적으로 전환하기에 부정적 영향을 최소화하고 상황에 따라 트래픽 양을 조절하며 롤백할 수 있다.

장점.

• 문제 상황을 빠르게 감지
• A/B 테스트로 활용 가능

단점.

• 네트워크 트래픽 제어 부담.

*A/B 테스트란? 

대조군과 실험군으로 나누어서 특정한 UI나 알고리즘의 효과를 비교하는 방법론

3. 정리

1. Rolling 배포

• 인스턴스를 늘리지 않고,
• 하나씩 새로운 버전으로 늘리는 기법.
• 사용중인 인스턴스에 트래픽이 몰리는 문제가 있다.
• 버전간 호환성 문제가 생기는 순간이 있다.

2. Blue Green 배포

• 구버전과 같은 환경으로 신버전을 미리 준비.
• 로드밸런서의 라우팅을 한번에 확! 전환시킴.
• 구버전의 환경을 재활용하거나 롤백하기 쉬움.
• 단, 시스템 자원이 두배로 든다.

3. 카나리 배포

• 소수만 사용하는 환경에 신버전을 배포하고 문제를 관찰한다.
• 문제가 없으면 신버전으로의 트래픽을 단계적으로 늘린다.
• 블루그린 배포와 유사. 하지만 블루그린은 한번에 전환, 이건 단계적으로 전환.
• 문제를 빠르게 발견할 수 있다.

참고:

express 앱을 개발하며 자스/타스에 대해 하나씩 배워가고 있다.

오늘은 기본값 파라미터를 사용해보았다.

1. 내용

파라미터에 기본값 파라미터를 설정하면 값이 없거나 undefined가 전달될 경우 지정한 기본값으로 사용한다.

예시)

function multiply(a, b = 1) {
  return a * b;
}

console.log(multiply(5, 2));
// expected output: 10

console.log(multiply(5));
// expected output: 5

같은 개념으로 함수를 파라미터로 사용할 때도 기본값을 지정할 수 있다.

function callSomething(thing = something()) {
  return thing
}

let numberOfTimesCalled = 0
function something(){
  numberOfTimesCalled += 1
  return numberOfTimesCalled
}

callSomething()  // 1
callSomething()  // 2

앞의 파라미터를 뒷쪽의 파라미터의 기본값으로 사용할 수 있다.

function greet(name, greeting, message = greeting + ' ' + name) {
  return [name, greeting, message]
}

greet('David', 'Hi')                      // ["David", "Hi", "HiDavid"]
greet('David', 'Hi', 'Happy Birthday!')   // ["David", "Hi", "Happy Birthday!"]

2. 실제로 사용한 상황

express앱을 개발하며 user의 컨트롤러-서비스 부분을 개발하고 있었다.

서비스에서 sequelize ORM을 사용하고 있기에 쿼리문을 간단하게 생성하여 DB를 조작한다.

로직에서 service를 호출하는 컨트롤러에 따라 다르게 조회할 컬럼을 설정해야 했었다.

이때 기본값 파라미터를 설정해주는 것만으로 아주 간단하게 문제를 해결할 수 있었다.

export const findOneUserInfo = async (
  uid: string,
  attributes: string[] = ['name', 'uid', 'email', 'phone', 'createdAt'],
): Promise<any> => {
  try {
    const result = await User.findOne({
      attributes: attributes,
      where: {
        uid: uid,
      },
    });
    return result;
  } catch (err) {
    return err;
  }
};

코드를 보면 인자로 uid와 attributes를 받는다. 원래는 attributes가 없었는데 기본값 파라미터로 추가해주었다.

findOneUserInfo(uid)처럼 uid만 사용하여 호출했을때는 조회할 컬럼이 기본값 파라미터의 

['name', 'uid', 'email', 'phone', 'createdAt']로 지정이 되어 쿼리가 수행된다.

하지만 이 컬럼들 이외로 알고싶다면 

findOneUserInfo(uid, ['address', 'gender']) 이런식으로 인자를 넣어주면 된다.

이러면 기본값 파라미터 값에 ['address', 'gender']가 추가된 것이 아닌 ['address', 'gender']만 조회된다. 주의.

참고:

혼자 개발할때는 사용하지 않고 그냥 이런게 있구나 정도로 넘겼던 도커.

이제 막 배우기 시작하는 입장으로서 한번 개념만 정리해보자.

1. 부두 노동자

어학사전에 docker를 검색하면 부두(항만) 노동자라고 나온다. 

해외에서

화물 컨테이너가

배를 타고 부두에 도착하면

노동자들이

화물 컨테이너를 받아준다.

이를 도커로 바꿔보면

해외(도커 레지스트리)에서

화물 컨테이너(도커 이미지)가

부두(나의 PC)에 도착하면

노동자(도커)들이

화물 컨테이너를 받아준다(도커 이미지를 도커 컨테이너로 만들어 실행시킨다)

이 비유가 맞다고 확신은 못하지만 내 생각엔 맞는 것 같다.(아니라면 알려주세요ㅠㅠ)

2. 컨테이너 기반 가상화 플랫폼?

혼자 개발할때는 나의 PC에 필요한 소프트웨어들을 미리 설치해두고 개발한다. 내가 작성한 코드들은 미리 설치해둔 환경에 의존하며 실행된다. 여기까진 좋은데 내가 만든 것을 배포하려면 어떻게 해야할까? 사용자들도 나의 PC와 같은 환경이 미리 준비돼 있어야 내가 만든 SW가 정상적으로 동작할텐데 말이다. 이때 도커를 사용한다.

도커는 애플리케이션을 어떤 환경에서도 자유롭게 사용할 수 있게 해준다.

도커의 역할을 한마디로 요약해보면

"내가 만든 애플리케이션과

애플리케이션에 요구되는 환경을

몽땅 압축해서 배포하기"

and

"남이 만든 애플리케이션을

애플리케이션에 요구되는 환경과 함께

한번에 받아와서 실행하기"

정도이려나?

(피드백 달게 받습니다..)

VM과 비슷한 개념이긴 하나 VM은 OS위에 다른 OS를 생으로 다시 올린다. 각 VM은 하나의 서버를 여러 서버로 전환하는 물리적인 하드웨어의 추상화라고 하는데 이는 매우매우 무겁다.

도커는 여러 종류의 컨테이너가 동일한 시스템에서 실행되고 호스트의 OS 커널을 다른 컨테이너와 공유할 수 있기에 VM보다 부담이 적다. 즉, 실제로(HW적으로) 내 PC에서 공간을 나누진 않았지만 각각의 독립된 공간을 가진것 처럼 동작하도록 하는 기술이다.

3. 이미지, 컨테이너, 레지스트리

나의 애플리케이션, 혹은 누군가 만들어 놓은 애플리케이션의 실행에 필요한 모든 것들(라이브러리, 미들웨어, OS, 네트워크 설정 등)을 모아서 도커 이미지라는 것으로 만든다.

이 이미지들을 클라우드상에 모아놓은 곳을 레지스트리라고 한다.

대표적인 레지스트리로 도커허브가 있다.

내가 만든 이미지나 남이 만들어 놓은 이미지들을 올리고 내려받을 수 있다. 

이 이미지들을 내려받아서 실행시킨 것을 컨테이너라고 한다. 

이 고래가 도커엔진이고 위에 네모난 것들이 이미지를 내려받아 생성한 컨테이너다.

즉 도커 엔진 위에서 여러 컨테이너들이 실행중인 모습을 보여준다.

이미지를 실행한 상태인 컨테이너는 애플리케이션을 패키징/캡슐화하여 격리된 공간에서 프로세스를 동작시킨다.

일단은 내 로컬 PC 어딘가에서 프로세스가 실행되는 것이긴 한데 이 공간은 내가 접근할 수 없는 격리된 공간이다. 

컨테이너의 특징을 정리하자면

• 가상머신과 비교하여 컨테이너의 생성이 쉽고 효율적이다.
• 컨테이너 이미지를 통한 배포와 롤백이 간단하다.
• 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리한다.
• 개발, 테스팅, 운영 환경은 물론 로컬 PC와 클라우드까지 동일한 환경을 구축한다.
• 특정 클라우드 벤더에 종속적이지 않다.

4. 레이어

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기에 용량이 보통 수백MB다.

따라서 기존 이미지에서 살짝 무언가가 추가된 이미지를 다시 받는다고

이미지 전체를 다시 받으면 용량적으로 비효율적이다.

따라서 이미지는 레이어로 구성되어있다.

이미지1이 A+B+C의 레이어(구성 요소)로 이루어져있는데

C를 수정한 A+B+C*의 이미지를 받아야 한다면 C레이어만 C*로 수정된다.

위 그림에서 MySQL의 버전이 변경된 새로운 이미지를 내려 받는 경우를 생각해보면 될 것이다.

이미지를 내려받을 때 다음과 같은 로그가 나온다.

$ docker pull mysql

Using default tag: latest
latest: Pulling from library/mysql
69692152171a: Extracting [=======>                                           ]  4.129MB/27.15MB
1651b0be3df3: Download complete 
951da7386bc8: Download complete 
0f86c95aa242: Download complete 
37ba2d8bd4fe: Download complete 
6d278bb05e94: Download complete 
497efbd93a3e: Download complete 
f7fddf10c2c2: Download complete 
16415d159dfb: Downloading [>                                                  ]  2.157MB/115.8MB
0e530ffc6b73: Download complete 
b0a4a1a77178: Waiting 
cd90f92aa9ef: Waiting

69692152171a와 같은 한 줄 한 줄이 모두 레이어이다. 

이런 레이어가 한 겹 한 겹 쌓이고 하나의 이미지로 만들어진다.

이후 이 이미지를 docker run으로 실행하면 도커가 관리하는 파일 시스템 영역에 이미지를 복사한다.

복사 후 이미지 레이어 최상단에 컨테이너 레이어를 추가한다. 이로써 이미지는 컨테이너가 된다.

그리고 사용자에겐 Union File System을 사용하여 레이어가 스택 구조로 쌓인 이미지를 하나의 파일 시스템처럼 보이게 한다.

컨테이너 레이어는 변경 가능하고,

이미지 레이어는 변경 불가능하다.

컨테이너 레이어는 컨테이너 종료 시 소멸되고,

이미지 레이어는 삭제되지 않는다.

레이어를 사용하면 위에 말했 듯 애플리케이션의 일부를 변경할 경우 이미지 전체를 다시 다운받지 않고

변경된 부분의 레이어만 교체해 주면 된다.

5. 정리

그림으로 도커의 전반적인 동작을 정리해보자

왼쪽에 (Code, OS, Other Dependencies)가 Dockerfile로 합쳐지고 이를 build하여 도커 이미지를 생성함을 볼 수 있다.

이렇게 생성된 이미지는 내 PC에 있는 도커엔진에서 실행되어 컨테이너 상태가 된다.

또 왼쪽에 EXE파일로 실행한 프로세스를 확인할 수 있는데 이건 내 PC위에서 실행되는 일반적인(도커가 아닌) 프로세스를 표현한 것 같다.

자 이제 이렇게 내 PC에서 실행되고 있는 두 프로세스(도커 컨테이너와 일반 프로세스)를 그림 우측처럼 다른 환경으로 옮기면 어찌될까?

도커를 통한 공유(배포)는 애플리케이션 실행을 위한 환경이 모두 준비된 이미지를 배포하기에 다른 환경이라도 이를 받아줄 수 있는 도커 엔진만 있다면 정상적으로 동작한다.

단, 일반적인 프로세스라고 표현한 저 애플리케이션은 내 PC와 다른 환경이기에 동작하지 않을 수도 있다.

참고:

nodejs를 통해 애플리케이션을 개발하며 테스트를 위해 Jest 프레임워크를 사용했다.

그런데 테스트 코드 작성이 처음이기도 해서 그런지 "mock"이라는 개념에서 많이 헤맸다.

첫 테스트 코드 작성이기에 다른 블로그의 글 보다 질 좋은 정보는 없겠지만 내가 어떻게 mock을 활용하여 단위/통합 테스트를 진행했는지 나중의 나를 위해 기록해놓는다.

1. Jest란

페이스북에서 개발한 JS를 위한 테스트 프레임워크이다.

npm install --save-dev jest

이렇게 설치해 주고 사용하자. --save-dev의 의미를 모르겠다면 마침 엊그제 쓴 좋은 글이있다. ㅎㅎ

https://llshl.tistory.com/40?category=961696 

설치를 마치고 package.json의 script에 

"scripts": {
	...
    "test": "jest",
    ...
  },

이렇게 한 줄 넣어주자. 이제 우린 npm test라는 명령을 통해 테스트를 할 수 있게 됐다.

2. mock이란

기본적인 테스트 방법은 다른 블로그들이 아주 자세히 설명하고 있으니 여기서는 굳이 기록하지 않을려 한다.

"목", "목하다", "모킹하다"라고 표현하는 mock이란 간단히 말해서 "가짜로 대체하기" 기능이라고 말할 수 있다.

왜 가짜로 대체하는가?

• 테스트 하고싶은 기능이 다른 기능들과 엮여있을 경우(의존) 정확한 테스트를 하기 힘들기 때문

예를들어 request body에 사용자의 id와 password를 넣어서 post요청을 보내면 컨트롤러에서 정보를 추출한 후 데이터베이스에 넣어주는 단위테스트를 하고 싶다고 하자.

데이터베이스에 저장 요청을 보내면 성공이든 실패든 응답이 반환될 것이고 반환된 응답을 기준으로 테스트의 성공과 실패를 구분한다.

이때 실제 데이터베이스에 사용자의 id, password를 넣는 방식으로 테스트를 하는 것은 좋은 방법이 아니다.

실제 트랜잭션이 일어나기에 IO 시간도 테스트에 포함되고, 데이터베이스 연결 상태에 따라 테스트가 실패할 수도 있기 때문이다.

테스트가 실패했을 경우 내가 작성한 컨트롤러 코드의 문제인지, 데이터베이스의 문제인지 알아차리기도 힘들기 때문에 올바른 단위테스트라고 할 수 없다.

따라서 실제 데이터베이스에 데이터를 넣는 것이 아니라 넣은 셈 치자는 개념이다.

데이터베이스가 잘 작동하는지는 데이터베이스 관련 테스트에서 확인하면 되고 우리는 지금 controller에 대한 테스트를 진행하고 있으니 데이터베이스가 잘 작동한다는 전제를 깔고 가자는 뜻이다. 

데이터베이스 mocking을 표현하면 다음 그림과 같다.

기존의 데이터베이스 저장 메소드를 mock 함수로 만든다. mock 함수가 되면 그 함수는 아무런 기능이 없어진다. mock 함수를 호출하면 

undefined를 반환한다. 그냥 껍데기만 남기고 속을 싹 비워낸 그런 느낌

이제 이 mock함수를 호출했을때 반환 받기 원하는 값을 우리가 직접 지정해 준다.

본래 데이터 저장 함수이기에 데이터 저장 성공 후 응답 값이 다음과 같다고 가정해보자.

{
	"result": "success",
	"id": "testUser@test.com"
}

이런 결과와 저장된 id를 json으로 응답 받았었다면 mock함수가 반환하길 원하는 값으로 저 json을 지정해주자.

우리는 controller의 로직에 집중해야하니 데이터베이스는 "대충 이런이런 값을 반환한다고 치자"라고 하고 넘어가는 개념이다.

3. 작성해본 테스트 코드

모킹을 하는 방법은 Jest에서 제공하는 fn(), spyOn(), mock() 함수를 사용하면 된다. 이 중에서 난 fn()을 쓰려고 했지만 원인 모를 에러로 인해 spyOn 함수를 사용했다! 

이 3가지 함수에 대한 설명은 이 블로그에서 친절하게 설명을 해두었다.

UserController에 있는 getPassword함수를 테스트해보자.

getPassword 함수는 다음과 같다.

export const getPassword = async (req: Request, res: Response, next: NextFunction) => {
  try {
    const id: string = req.query.id ? req.query.id : req['claims']['email'];
    return res.status(200).json(await account.findPasswordById(id));
  } catch (e) {
    Logger.error('%o', e);
    return next(e);
  }
};

getPassword함수는 사용자 Id를 받아서 db에서 password를 조회하는 함수다.

이 함수의 기능은 두가지다.

1. req로부터 사용자 id를 추출하고,
2. findPasswordById함수에 사용자 id를 넘겨준다.

http 요청을 만들기 위해 httpMocks라는 모듈을 사용하였다.

작성한 테스트코드는 다음과 같다.

import * as model from '../models/student.model';

test('[DB 데이터 조회 테스트] 사용자 id를 통해 password 조회 테스트', async () => {
  const req = httpMocks.createRequest({
    method: 'GET',
    url: '/api/test?id=user@test.com',
  });
  const res = httpMocks.createResponse();
  const next = null;
  const expectedResult = { password: 'mypass123' };
  const mockFindPasswordById = jest.spyOn(model, 'findPasswordById');
  mockFindPasswordById.mockResolvedValue(expectedResult);

  await UserController.getPassword(req, res, next);

  expect(res.statusCode).toBe(200);
  expect(res._getJSONData()).toStrictEqual(expectedResult);
});

import한 model은 데이터베이스에 접근하는 함수들을 모아놓은 모듈이다.

11번째 줄의 spyOn함수를 통해서 mock 함수를 생성한다.

  const mockFindPasswordById = jest.spyOn(model, 'findPasswordById');

import된 model 모듈에 존재하는,

findPasswordById 함수를 spyOn을 통해서,

mockFindPasswordById 라는,

mock함수로 만들었다.

findPasswordById는 원래 데이터베이스에 접근하는 함수였지만 이제 아무런 기능이 없는 mock 함수가 되었다.

호출하면 undefined만 반환한다.

우리는 이 함수가 데이터베이스에서 password를 조회해 반환해주기를 원한다. 그렇기에 우리가 원하는 반환 값을 직접 달아준다.

  mockFindPasswordById.mockResolvedValue(expectedResult);

이제 mockFindPasswordById는 쿡 찌르면 우리가 지정해준 응답값을 반환해준다.

이는 "데이터베이스가 정상적으로 동작했다고 치자"라고 설정한것이다.

데이터베이스 관련 함수는 async/await으로 처리되기에 Promise를 resolve하는 mockResolvedValue를 사용했다. 

다른 여러 종류의 반환값에 대한 반환값 지정 함수는 다음 문서에서 확인하면 된다.

https://jestjs.io/docs/mock-function-api

이제 우리는 UserController.getPassword(req, res, next)로 우리가 만들었던 req를 보내준다.

UserController.getPassword(req, res, next)에는 findPasswordById함수가 있는데 우리는 지금 이걸 mock으로 만들어 주었으니 무조건 우리가 지정한 응답을 줄 것이다.

  await UserController.getPassword(req, res, next);

  expect(res.statusCode).toBe(200);
  expect(res._getJSONData()).toStrictEqual(expectedResult);

UserController.getPassword에 잘못된 점이 없다면 테스트는 성공한다.

4. 결론

우리는 이제 무엇에 테스트를 성공한것인가?

UserController의 getPassword함수에서 

1. req로부터 사용자 id를 추출하고,
2. findPasswordById함수에 사용자 id를 넘겨준다.

이 두가지 로직에 대한 검증이 성공한 것이다.

(매우매우 간단한 테스트다)

이는 작은 단위의 단위테스트이고 supertest를 활용한 통합테스트도 작성하였다. 오히려 통합테스트가 더 직관적이라 테스트코드를 처음 작성해보는 나에겐 더 쉬웠다.

라고 말하지만 사실 통합테스트에서는 db의 endpoint를 test일 경우에만 local db로 동적으로 바꿔주는 작업 때문에 많이 고생했다.ㅠㅠ

다음 포스팅에서 하소연 해보겠다.

참고:

tsc --init

을 통해 생성하는 tsconfig.json파일.

타입스크립트를 시작한지 얼마되지 않았기에 대충 설정파일이구나 하고 넘겼다. 

여기 있는 설정들을 살펴보며 타입스크립트의 전체적인 그림을 살펴보자.

1. 멋모르고 사용해 온 설정

처음 init을 통해 파일을 생성하면 뭔가 엄청 많다.

이거처럼

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig.json to read more about this file */

    /* Projects */
    // "incremental": true,                              /* Enable incremental compilation */
    // "composite": true,                                /* Enable constraints that allow a TypeScript project to be used with project references. */
    // "tsBuildInfoFile": "./",                          /* Specify the folder for .tsbuildinfo incremental compilation files. */
    // "disableSourceOfProjectReferenceRedirect": true,  /* Disable preferring source files instead of declaration files when referencing composite projects */
    // "disableSolutionSearching": true,                 /* Opt a project out of multi-project reference checking when editing. */
    // "disableReferencedProjectLoad": true,             /* Reduce the number of projects loaded automatically by TypeScript. */

    /* Language and Environment */
    "target": "es5",                                     /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
    // "lib": [],                                        /* Specify a set of bundled library declaration files that describe the target runtime environment. */
    // "jsx": "preserve",                                /* Specify what JSX code is generated. */
    // "experimentalDecorators": true,                   /* Enable experimental support for TC39 stage 2 draft decorators. */
    // "emitDecoratorMetadata": true,                    /* Emit design-type metadata for decorated declarations in source files. */
    // "jsxFactory": "",                                 /* Specify the JSX factory function used when targeting React JSX emit, e.g. 'React.createElement' or 'h' */
    // "jsxFragmentFactory": "",                         /* Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. 'React.Fragment' or 'Fragment'. */
    // "jsxImportSource": "",                            /* Specify module specifier used to import the JSX factory functions when using `jsx: react-jsx*`.` */
    // "reactNamespace": "",                             /* Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit. */
    // "noLib": true,                                    /* Disable including any library files, including the default lib.d.ts. */
    // "useDefineForClassFields": true,                  /* Emit ECMAScript-standard-compliant class fields. */

    /* Modules */
    "module": "commonjs",                                /* Specify what module code is generated. */
    // "rootDir": "./",                                  /* Specify the root folder within your source files. */
    // "moduleResolution": "node",                       /* Specify how TypeScript looks up a file from a given module specifier. */
    // "baseUrl": "./",                                  /* Specify the base directory to resolve non-relative module names. */
    // "paths": {},                                      /* Specify a set of entries that re-map imports to additional lookup locations. */
    // "rootDirs": [],                                   /* Allow multiple folders to be treated as one when resolving modules. */
    // "typeRoots": [],                                  /* Specify multiple folders that act like `./node_modules/@types`. */
    // "types": [],                                      /* Specify type package names to be included without being referenced in a source file. */
    // "allowUmdGlobalAccess": true,                     /* Allow accessing UMD globals from modules. */
    // "resolveJsonModule": true,                        /* Enable importing .json files */
    // "noResolve": true,                                /* Disallow `import`s, `require`s or `<reference>`s from expanding the number of files TypeScript should add to a project. */

    /* JavaScript Support */
    // "allowJs": true,                                  /* Allow JavaScript files to be a part of your program. Use the `checkJS` option to get errors from these files. */
    // "checkJs": true,                                  /* Enable error reporting in type-checked JavaScript files. */
    // "maxNodeModuleJsDepth": 1,                        /* Specify the maximum folder depth used for checking JavaScript files from `node_modules`. Only applicable with `allowJs`. */

    /* Emit */
    // "declaration": true,                              /* Generate .d.ts files from TypeScript and JavaScript files in your project. */
    // "declarationMap": true,                           /* Create sourcemaps for d.ts files. */
    // "emitDeclarationOnly": true,                      /* Only output d.ts files and not JavaScript files. */
    "sourceMap": true,                                /* Create source map files for emitted JavaScript files. */
    // "outFile": "./",                                  /* Specify a file that bundles all outputs into one JavaScript file. If `declaration` is true, also designates a file that bundles all .d.ts output. */
    "outDir": "dist",                                   /* Specify an output folder for all emitted files. */
    // "removeComments": true,                           /* Disable emitting comments. */
    // "noEmit": true,                                   /* Disable emitting files from a compilation. */
    // "importHelpers": true,                            /* Allow importing helper functions from tslib once per project, instead of including them per-file. */
    // "importsNotUsedAsValues": "remove",               /* Specify emit/checking behavior for imports that are only used for types */
    // "downlevelIteration": true,                       /* Emit more compliant, but verbose and less performant JavaScript for iteration. */
    // "sourceRoot": "",                                 /* Specify the root path for debuggers to find the reference source code. */
    // "mapRoot": "",                                    /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,                          /* Include sourcemap files inside the emitted JavaScript. */
    // "inlineSources": true,                            /* Include source code in the sourcemaps inside the emitted JavaScript. */
    // "emitBOM": true,                                  /* Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files. */
    // "newLine": "crlf",                                /* Set the newline character for emitting files. */
    // "stripInternal": true,                            /* Disable emitting declarations that have `@internal` in their JSDoc comments. */
    // "noEmitHelpers": true,                            /* Disable generating custom helper functions like `__extends` in compiled output. */
    // "noEmitOnError": true,                            /* Disable emitting files if any type checking errors are reported. */
    // "preserveConstEnums": true,                       /* Disable erasing `const enum` declarations in generated code. */
    // "declarationDir": "./",                           /* Specify the output directory for generated declaration files. */

    /* Interop Constraints */
    // "isolatedModules": true,                          /* Ensure that each file can be safely transpiled without relying on other imports. */
    // "allowSyntheticDefaultImports": true,             /* Allow 'import x from y' when a module doesn't have a default export. */
    "esModuleInterop": true,                             /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility. */
    // "preserveSymlinks": true,                         /* Disable resolving symlinks to their realpath. This correlates to the same flag in node. */
    "forceConsistentCasingInFileNames": true,            /* Ensure that casing is correct in imports. */

    /* Type Checking */
    "strict": true,                                      /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied `any` type.. */
    // "strictNullChecks": true,                         /* When type checking, take into account `null` and `undefined`. */
    // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
    // "strictBindCallApply": true,                      /* Check that the arguments for `bind`, `call`, and `apply` methods match the original function. */
    // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
    // "noImplicitThis": true,                           /* Enable error reporting when `this` is given the type `any`. */
    // "useUnknownInCatchVariables": true,               /* Type catch clause variables as 'unknown' instead of 'any'. */
    // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
    // "noUnusedLocals": true,                           /* Enable error reporting when a local variables aren't read. */
    // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read */
    // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
    // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
    // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
    // "noUncheckedIndexedAccess": true,                 /* Include 'undefined' in index signature results */
    // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
    // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type */
    // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
    // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */

    /* Completeness */
    // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  },
  "include": [
    "src/**/*"
  ],
  "exclude":[
    "node_modules"
  ]
}

이 많은 옵션들 중 내가 사용하고 있는 옵션들부터 살펴보겠다.

compilerOptions과 include/exclude

tsconfig.json 파일을 살펴보면 최상위 경로는 compilerOptions, include, exclude 프로퍼티로 구성돼있다.

• compilerOptions은 말 그대로 어떤 컴파일 설정을 사용할지에 대한 속성이다.
• include는 프로그램에 포함하고 싶은 파일들의 목록을 지정한다. 보통

{
    "include": ["src/**/*", "tests/**/*"]
}

이와 같은 형태로 표기하여 한번에 지정한다.

• exclude는 include에 속한 파일들 중에서 제외시킬 파일들을 지정한다. 이때 프로그램에서 포함되지 않도록 제외시키는 메커니즘이 아니라 단순이 include 프로퍼티에서만 제외시킨다는 것에 주의하자.

"target"

여기서부터는 compilerOptions 프로퍼티 내부의 옵션들이다.

target은 어떤 버전의 자바스크립트로 컴파일할지 지정한다.

ts파일들을 tsc로 컴파일하여 js로 만드는 과정이 필요한 타입스크립트이기에 실제 런타임은 대부분 js다. 이 js의 버전을 지정한다.

"module"

프로그램에서 사용할 모듈 시스템을 결정한다. 즉, 모듈 내보내기/불러오기 코드가 어떠한 방식의 코드로 컴파일 될지를 결정한다.

"lib"

타입스크립트 파일을 자바스크립트로 컴파일 할 때 포함될 라이브러리의 목록이다. 이렇게만 하면 와닿지 않는데, async코드를 컴파일 할 때 Promise객체가 필요하므로 "es2017"과 같은 항목을 넣어준다고 한다.

"baseUrl"

비상대적 import의 모듈 해석시 기준이 되는 경로를 지정한다. 예시를 들자면, 프로젝트의 루트 디렉토리에 존재하는 src 디렉토리를 기준으로 각종 모듈들을 불러오고 싶다면 이 프로퍼티를 './src'로 지정한다.

"typeRoots'

기본적으로 @types 패키지들은 컴파일 목록에 포함된다. 하지만 만약 typeRoots 프로퍼티가 특정 경로들로 지정돼 있다면 오직 그 경로에 존재하는 패키지들만 컴파일 목록에 포함된다. 

"paths"

baseUrl 기준으로 상대 위치로 가져오기를 다시 매핑하는 항목 설정

"emitDecoratorMetadata"

"experimentalDecorators"

데코레이터 설정이다. 데코레이터란, 자바의 어노테이션과 비슷한 느낌의 기능으로, 데코레이터가 붙은 클래스, 메소드 등에 데코레이터에서 지정한 기능이 동작하도록 하는 기능이다.

"allowSyntheticDefaultImports"

불러오려는 모듈에 default export가 없어도 import * as XXX가 아닌 import XXX로 사용할 수 있게 해주는 설정이다.

"forceConsistentCasingInFileNames"

사용할 파일의 이름을 대소문자까지 정확하게 작성하도록 강제하는 설정이다.

"moduleResolution"

모듈 해석 전략을 결정한다. Nodejs 방식대로 모듈 해석을 하려면 "Node"를, 1.6버전 이전의 타입스크립트에서 사용하던 방식대로 모듈을 해석하려면 "Classic"을 입력한다.

"pretty"

에러와 메시지를 색과 컨텍스트를 사용해서 스타일을 지정하는 옵션

"sourceMap"

빌드시 map파일을 생성할지 설정한다. 생성된 소스맵 파일은 크롬 개발자 도구로 디버깅에 사용된다.

"allowJs"

js파일을 허용하는 옵션이다.타입스크립트는 .js확장자를 허용하지 않는다. 이에대한 예외를 허락하는 옵션.

"esModuleInterop"

"모든 가져오기에 대한 네임스페이스 객체 생성을 통해 CommonJS와 ES 모듈 간의 상호 운용성을 제공"이라고 돼있는데 이게 무슨소리인가?

피부에 와닿진 않지만 Commonjs방식으로 내보낸 모듈을 es모듈 방식의 import로 가져올 수 있게 해주는 기능 정도로 일단 이해하자.

"outDir"

컴파일 후 생성되는 js파일이 생성될 폴더를 지정한다

참고:

노드자스를 통해 개발하면서 무지성 install들을 해온것 같다. 그래서 정리해보는 시간.

1. npm options

기본적으로 npm install은 ./node_modules 폴더에 패키지를 다운받는 명령어이다.

나는 주로 npm 쓸때 접미사로 -D, -S, -g 옵션을 썼다. 왜냐? 블로그에서 이렇게 하라고 해서..

무슨 차이인지 모르고 써왔고 이거 때문에 문제 생긴적은 없었지만 찾아보니 나름의 의미가 있더라.

package.json을 보면 dependencies와 devDependencies가 있는데 얘네 중 어느쪽에 속하게 하도록 구분짓는 용도였다.

• dependencies: 프로덕션 환경에서 응용 프로그램에 필요한 패키지.
• devDependencies: 로컬 개발 및 테스트에만 필요한 패키지.

어떤 라이브러리가 빌드타임에 필요하면 devDependencies에 넣고, 런타임에도 필요하면 dependencies에도 넣어준다.

즉, 배포용 패키지와 개발용 패키지의 차이

--save는 package.json에 의존성 항목에 추가하도록 해주는 옵션인데 npm5부터는 굳이 --save 쓰지 않아도 된다고 한다.

-P/--save-dev (default)

암튼 그래서 

npm install [패키지명] -P
npm install [패키지명] --save-prod

이렇게 옵션을 주면 패키지를 설치하고 dependencies 목록에 추가한다.

사실 디폴트 옵션이라 아무 옵션도 안써주는 경우가 이 경우였다.

npm install [패키지명]

-D/--save-dev

그렇다면 얘는 devDependencies에 속하도록 하는 옵션이다.

npm install [패키지명] -D
npm install [패키지명] --save-dev

-g/--global

전역모드로 설치하면 시스템 폴더에 패키지를 설치하게 된다. -g를 통해서 설치하면 package.json의 의존성 목록에 기록되지 않는다.

-P나 -D는 지역설치옵션으로 루트 디렉토리의 node_modules에 설치된다. 이렇게 설치된 패키지는 해당 프로젝트 내에서만 사용 가능하다.

-g를 통한 전역설치를 하면 모든 프로젝트에서 사용 가능하다.

npm install [패키지명] -g
npm install [패키지명] -global

이 내용들을 어떤 분이 친절하게 정리해 두셨다.

npm install
// package.json의 dependencies에 있는 모든 패키지를 설치한다.
// 처음 프로젝트를 세팅했다면 이 명령어로 패키지를 설치하고 개발을 시작하면 된다.

npm i
// npm install 의 줄인 명령어. 

npm install [package]
// 현재 작업중인 디렉토리 내에 있는 ./node_modules에 [package]를 설치한다. 
// (예: npm install moment) -> ./node_modules에 moment 패키지를 설치 함

npm install [package] --save
// [package]를 설치 하면서 package.json파일에 있는 dependencies 객체에 지금 설치한 패키지 정보를 추가한다.

npm install [package] --save -dev
// --save옵션과 같이 package.json파일에 의존성 내용을 추가하지만
// dependencies가 아닌 devDepenencies 객체에 추가한다.
–save와 –save-dev의 차이는 의존성을 기본으로 추가할지, 개발용으로 추가할지의 차이이다.
--production로 빌드할 경우 devDepenencies에 있는 패키지들은 설치되지 않는다

npm install [package] --no-save
// dependencies에 패키지 정보를 추가하지 않는다.

npm install [package] --save-exact
// 정확히 일치하는 버전의 패키지를 추가한다.

npm install [package] --save-bundle
// 해당 패키지를 bundleDependencies에 추가한다.

npm install [package] --force
// 해당 패키지가 존재하더라도 원격 저장소에 있는 패키지를 가져온다.

참고:

거의 한달만에 글을 쓴다. 그간 참 많은 일이 있었다. 

취업을 했고 킥보드를 타다가 응급실도 갔다. 너무 정신없는 시간이었다고 변명을 해본다ㅠ

요즘은 TypeScript+Express를 통한 개발을 하고있는데 Express 사용시 헤더의 설정을 통하여 웹 취약점으로부터 서버를 보호해주는 보안 모듈인 Helmet이라는 것을 알게 됐고 간단하게 정리해보겠다.

(헤더에 씌운다고해서 이름이 헬멧인 것이 너무 귀엽다. 내 머리에 헬멧을 썻어야했는데 익스프레스에만 씌우고있다 아ㅋㅋ)

1. 사용법

그냥 한 줄만 추가해 주면 된다.

npm install helmet

헬멧을 설치하고,

const helmet = require('helmet');
const express = require('express');
const app = express();

app.use(helmet());

이렇게 붙혀주기만 하면 된다.

2. 무엇을 보호해주는가?

세부적인 미들웨어 함수들을 포함하고있는 헬멧은 다음과 같은 기능이 있다.

1. csp

csp는 Content-Security-Policy이다. 브라우저에서 사용하는 컨텐츠 기반의 보안 정책으로 XSS나 Data Injection, Click Jacking 등 웹 페이지에 악성 스크립트를 삽입하는 공격기법들을 막기 위해 사용된다.

2. hidePoweredBy

헤더에서 X-Powered-By를 제거한다. 이는 서버에 대한 정보를 제공해주는 역할로 나 같은 경우는 이 영역에 Express라고 표기됨을 확인할 수 있었다. 이 정보는 악의적으로 활용될 가능성이 높기에 헬멧을 통해서 제거해 주는 것이 좋다.

3. HSTS

HTTP Strict Transport Security의 약자로 웹 사이트에 접속할 때 강제적으로 HTTPS로 접속하게 강제하는 기능이다. 

사용자가 특정 사이트에 접속할 때 해당 사이트가 HTTPS를 지원하는지, 하지 않는지를 미리 모르는 경우가 대부분이다. 그렇기에 브라우저는 디폴트로 HTTP로 먼저 접속을 시도한다. 이때 HTTPS로 지원되는 사이트였다면 301Redirect나 302 Redirect를 응답하여 HTTPS로 다시 접속하도록 한다.

하지만 이때 해커가 중간자 공격을 하여, 중간에 프록시 서버를 두고

[나] <-> [해커] 사이에서는 HTTP 통신을 하고 [해커] <-> [웹사이트] 사이에선 HTTPS 통신을 한다면,

우리의 개인정보가 HTTP 프로토콜을 통해 해커에게로 전해지는 참사가 일어난다.

이러한 공격을 SSL Stripping이라고 하며 이런 공격을 방지하기 위해 HSTS를 설정한다.

4. IeNoOpen

IE8 이상에 대해 X-Download-Options를 설정한다. 이 옵션은 8 버전 이상의 인터넷 익스플로러에서 다운로드된 것들을 바로 여는 것 대신 저장부터 하는 옵션이다. 사용자는 저장부터 하고 다른 응용프로그램에서 열어야 한다.

5. noCache

클라이언트 측에서 캐싱을 사용하지 않도록 하는 설정이다. 

6. noSniff

X-Content-Type-Options 를 설정하여 선언된 콘텐츠 유형으로부터 벗어난 응답에 대한 브라우저의 MIME 스니핑을 방지한다. MIME이란 Multipurpose Internet Mail Extensions의 약자로 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 포맷이다. 브라우저는 리소스를 내려받을 때 MIME 타입을 보고 동작하기에 정확한 설정이 중요하다.

MIME 스니핑이란 브라우저가 특정 파일을 읽을 때 파일의 실제 내용과 Content-Type에 설정된 내용이 다르면 파일로 부터 형식을 추측하여 실행하는 것인데, 편리함을 위한 기능이지만 공격자에게 악용 될 가능성이 있다.

7. frameguard

 X-Frame-Options 헤더를 설정하여 클릭재킹에 대한 보호를 제공한다.

클릭재킹이란 사용자가 자신이 클릭하고 있다고 인지하는 것과 다른 것을 클릭하도록 하여 속이는 해킹 기법이다. 속이기 위해 보이지 않는 레이어에 보이지 않는 버튼을 만드는 방법이 있다.

8. xssFilter

xss필터는 xss필터.

참고:

이 카테고리는 Ground X에서 진행한 한양대학교 일반대학원 블록체인 융합학과 강의와 그 외의 참고자료를 보고 정리하는 곳입니다. 강의 동영상은 여기서 볼 수 있습니다.

너무 빈약한 지식이기에 이 글을 신뢰하지는 마세요.. 혹시 지나가시다가 잘못된 점 발견하시면 피드백 부탁드립니다.

1. 블록체인이 기업(비즈니스)에 적용됐을 때

공급망 관리(Supply Chain Management)

공급망 관리란,

• 부품 제공업자, 생산자, 배포자, 고객에 이르는 물류의 흐름을 하나의 가치사슬 관점에서 파악하고 필요한 정보가 원활히 흐르도록 지원하는 시스템
• 즉, 어떤 원료로 생산했고, 누가 생산했고, 누가 유통했고, 누가 구매했는지를 한번에 관리하는 시스템
• 제품 가치의 60~70%가 제조 이외의 부분에서 발생하므로 전체 라인의 관리가 필요

한 예시로 IBM의 Food Trust 가 있다.

IBM의 푸드 트러스트는 식품 생산과 유통, 판매 등 ‘농장에서 식탁까지’의 식품 생태계 데이터 정보에 농가와 공급업체, 판매업체 등 참여주체가 간편하면서 신속하게 접근할 수 있도록 설계된 것이 특징이다. 특히 기존에 6~7일 정도 소요된 식품 생산이력추적이 단 2초 만에 이뤄져 식품안전 문제가 발생했을 경우, 원인을 더욱 빨리 규명하면서 상황이 확산되는 것을 조기에 차단할 수 있는 것이 가장 큰 장점이다.

여기에 사물인터넷(IoT)과 빅데이터 등의 여러 첨단기술이 접목되면서 원산지 추적은 물론 상세한 유통경로와 제품 입·출하내역, 공급량·재고량 확인 등의 내용까지 즉각 확인할 수 있다.

https://www.econovill.com

해외 송금/자산

은행을 거친 국가간 지급 결제 방식 => 매우 불편하고 오래걸린다.

이를 블록체인으로 개선한 사례

BoC & MAS Cross-border Settlement(캐나다 - 싱가포르 중앙은행간 블록체인 결제 실험)

캐나다 중앙은행은 R3 코다 기반, 싱가포르는 쿼럼 기반 블록체인 네트워크를 활용해 중계자 없이 직접 대금 결제가 가능함을 보여줬다. 

https://www.digitaltoday.co.kr/news/articleView.html?idxno=303128 

2. 블록체인이 소비자에게 적용됐을 때

소비자는 금액이 조금 더 발생하더라도 더 편리한 것, 더 이쁜 것을 선택하는 경향이 있다.

이 부분에서 기업과 조금 다르다고 할 수 있다.

전자화폐

실물화폐에서 전자화폐로 변화하는 사회

• 효율성을 위해 실물화폐에서 전자화폐로 전환되는 추세
• 중앙은행, 기업 등이 발행 및 원장 관리를 수행 => 불투명한 운영
• 위변조 위험 존재

블록체인 기반 전자화폐

• 발행은 여전히 중앙화된 기관 또는 사업자가 수행
• 분산원장(=블록체인)에 기록함으로써 투명성 및 추적성 확보
• 빠른 정산 가능

좋은 예시가 김포페이(지역화폐)

• 발금된 해당 지자체 관내 가맹점에서만 사용 가능한 화폐 => 지역경제 활성화를 목적으로 함
• 김포페이는 KT의 블록체인 기반 지역화폐 플랫폼 '착한페이'를 통해 발행
• 추적이 가능하기에 투명하다
• 정산이 빠르다

유일한 전자 자산(NFT)

블록체인의 불변성을 사용하여 복제 불가능한 디지털 데이터 생성 => 희소성

희소성을 가진 자산은 거래가 가능하다

NFT는

• 상호운용불가
• 불가분성(NFT를 쪼갤 수 없다)
• 파괴 불가능성(토큰 제거, 복제 불가능)
• 검증 가능성

의 성질을 가진다.

옛날 소리바다처럼 mp3 복제를 막기위해 DRM 기술을 사용하고 있지만 한계가 존재한다.

대표적인 예시에는 크립토 키티가 있다.

• 이더리움 기반의 가상 펫 육성 게임
• 각각의 캐릭터는 NFT로 발급되어 희소성을 가짐
• 실제로 거액에 거래된 적이 있음

https://www.coindeskkorea.com/news/articleView.html?idxno=72672