Kay's devlog

[NestJS 튜토리얼 초급] 0. NestJS 튜토리얼 초급 소개

iKay — Mon, 14 Aug 2023 16:11:00 +0900

NestJS를 사용해야 하는 이유

NestJS는 NodeJS 런타임에서 구동되는 서버 사이드 애플리케이션을 구축하기 위한 프레임워크입니다. NestJS 프레임워크를 학습하기 전, NestJS를 사용하면 어떤 점이 좋은지를 우선 소개해 드리겠습니다.

1. TypeScript 기반

NestJS는 TypeScript를 주 언어로 사용합니다. TypeScript는 정적 타입 언어로 런타임에 발생할 수 있는 오류를 사전에 개발 과정에서 방지할 수 있고 코드의 가독성을 높여줍니다. 이에 따라 코드 유지 보수가 용이해지며, 협업과 확장성이 향상됩니다.

TypeScript 언어는 "lingua franca(공통어)"가 되었다고 해도 과언이 아닙니다. 누구나 TypeScript를 쉽게 사용할 수 있기 때문에 NestJS를 사용하는 데 부담이 없을 것입니다.

2. 모듈 구조

NestJS는 모듈 기반 아키텍처를 채택하고 있습니다. 이는 애플리케이션을 기능 단위로 분리하여 개발 및 유지 보수를 용이하게 해줍니다. 각 모듈은 독립적으로 작동하며 필요한 모듈만 가져와 조합할 수 있습니다.

3. 의존성 주입(Dependency Indejction)

의존성 주입은 코드의 재사용성과 유지 보수성을 향상시키는 중요한 개념입니다. NestJS는 의존성 주입을 기본적으로 지원하며, 이를 통해 컴포넌트 간의 느슨한 결합을 유지하고 테스트 용이성을 높일 수 있습니다.

4. HTTP 와 WebSocket 지원

NestJS는 Express나 Fastify와 같은 강력한 HTTP 서버 프레임워크 위에서 작동합니다. 이를 통해 RESTful HTTP API, GraphQL 같은 다양한 통신 프로토콜을 구현할 수 있습니다. 또한 WebSocket을 통한 양방향 통신도 쉽게 구현할 수 있습니다.

5. Middleware 와 Interceptor

NestJS는 미들웨어와 인터셉터를 사용하여 요청 및 응답을 가로채고 변형시키는 기능을 제공합니다. 이를 활용하여 로깅, 인증, 데이터 변환 등의 작업을 더욱 쉽게 수행할 수 있습니다.

6. 다양한 ORM(객체-관계 매핑) 지원

NestJS는 다양한 ORM 라이브러리와의 통합을 지원하여 데이터베이스 작업을 편리하게 수행할 수 있습니다. TypeORM을 사용하면 TypeScript 클래스를 데이터베이스 엔터티로 매핑할 수 있어 개발 생산성을 높여줍니다.

7. 테스트 용이성

NestJS는 테스트를 위한 다양한 도구와 기능을 제공합니다. 의존성 주입과 모듈화된 구조를 활용하면 단위 테스트와 통합 테스트를 보다 쉽게 작성할 수 있습니다.

8. 풍부한 커뮤니티와 문서

NestJS는 테스트를 위한 다양한 도구와 기능을 제공합니다. 의존성 주입과 모듈화된 구조를 활용하면 단위 테스트와 통합 테스트를 더욱 쉽게 작성할 수 있습니다.

튜토리얼 목표

NestJS 튜터리얼 초급 강의는 간단하지만, 실용적인 웹 커뮤니티 게시판 API를 직접 만들어 봄으로써 NestJS 프레임워크 개발환경을 스스로 구축할 수 있고, 프레임워크를 어떻게 사용하는지를 익히는 것을 목표로 합니다.

튜토리얼 대상

NestJS 튜토리얼 초급을 웹 커뮤니티 게시판을 만들어 보고 싶은 초급 백엔드 개발자 혹은 백엔드 개발자가 아닐지라도 NestJS 프레임워크를 학습하고 싶은 모든 초보자를 대상으로 만들 예정입니다.

사전지식

NodeJS 기초
Express 사용 경험
JavaScript 또는 TypeScript 사용 경험 (TypeScript 사용 경험이 없어도 무방합니다.)

튜토리얼 목차

튜토리얼 목차는 다음과 같이 12 챕터로 구성될 예정입니다.

NestJS 튜토리얼 초급 소개
NestJS 개발 환경 갖추기
NestJS Controller 알아보기
NestJS Provider 알아보기
NestJS Module 알아보기
NestJS Middleware 알아보기
NestJS Interceptor 알아보기
NestJS Exception Filter 알아보기
NestJS Pipe 알아보기
NestJS Guard 알아보기
NestJS Custom Route Decorator 알아보기
NestJS 튜토리얼 초급 마무리 하기

NodeJS 백엔드 프레임워크로써 NestJS가 큰 인기를 얻고 있지만 초급 튜토리얼 강의가 현재 많지 않은 것 같고 NestJS를 좋아하시는 분들이 많아졌으면 하는 마음에 튜토리얼 초급 강의를 기획하기로 결심했습니다.

NestJS Korea 커뮤니티 Discord 도 많이 활성화되어 있으니 많은 관심과 참여 부탁드려요.

hey, 사용이 간단한 웹서버 부하테스트 커맨드라인 프로그램

iKay — Tue, 1 Aug 2023 01:14:54 +0900

웹서버 부하테스트 툴은 많습니다. 오늘은 여러 툴 중 하나인 커맨드라인으로 간단히 테스트를 쉽게할 수 있는 오픈소스인 hey를 소개합니다.

소스코드는 https://github.com/rakyll/hey에서 보실 수 있습니다.

GitHub - rakyll/hey: HTTP load generator, ApacheBench (ab) replacement

HTTP load generator, ApacheBench (ab) replacement. Contribute to rakyll/hey development by creating an account on GitHub.

github.com

소개

hey는 웹 애플리케이션을 부하테스트 하는 경량화된 프로그램으로 Go 언어로 작성되었고 https://github.com/tarekziade/boom에서 영향을 받아서 만들어 졌다고 합니다.

설치하기

사용하는 OS에 따라 설치파일이 다릅니다.

linux 64bit: https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64
Mac 64bit: https://hey-release.s3.us-east-2.amazonaws.com/hey_darwin_amd64
Windows 64bit: https://hey-release.s3.us-east-2.amazonaws.com/hey_windows_amd64

Mac 사용자라라면 homebrew로도 설치 가능합니다.

brew install hey

장점

부하테스트를 하기 위한 프로그램은 많은데요. 이 프로그램을 사용하는 이유는 다음과 같은 장점이 있기 때문입니다.

무료입니다. 생각보다 쓸만한 무료 부하테스트 툴이 별로 없는 듯 합니다.
용량이 작고 사용이 쉽고 가볍습니다.
요청 클라이언트 query per second(QPS) 옵션이 있습니다. 생각보다 이 기능이 다른 툴에 없습니다.
http2 요청도 가능합니다.

사용 예

# 예 1
hey -c 5 -z 60s -H "Content-Type: application/json" -m POST -d '{"key1":"val1"}' 'https://www.google.com'

# 옵션 설명
-c 5: 테스트 수행 클라이언트 5개
-z 60s: 60초 동안 테스트 수행 
-H "Content-Type: application/json": header에 "Content-Type: application/json" 내용 넣어서 요청
-m POST: 요청 메소드 POST
-d '{"key1":"val1"}': POST body에 요청할 payload


# 예 2
hey -c 3 -z 60s -q 10 'https://www.google.com'

# 옵션 설명
-c 3: 테스트 수행 클라이언트 5개
-z 60s: 60초 동안 테스트 수행
-q 10: 1초당 10개의 요청으로 제한함

응답 예

https://www.google.com에 60초 동안 10 QPS, 5개의 클라이언트로 제한하여 부하테스트를 한 결과 예시 입니다.

hey -c 5 -z 60s -q 10 'https://www.google.com'

Summary:
  Total:        60.1204 secs
  Slowest:      1.0855 secs
  Fastest:      0.1090 secs
  Average:      0.1331 secs
  Requests/sec: 37.4748
  

Response time histogram:
  0.109 [1]     |
  0.207 [2226]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.304 [12]    |
  0.402 [3]     |
  0.500 [5]     |
  0.597 [1]     |
  0.695 [0]     |
  0.793 [0]     |
  0.890 [0]     |
  0.988 [1]     |
  1.086 [4]     |


Latency distribution:
  10% in 0.1196 secs
  25% in 0.1227 secs
  50% in 0.1265 secs
  75% in 0.1323 secs
  90% in 0.1417 secs
  95% in 0.1567 secs
  99% in 0.2127 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0006 secs, 0.1090 secs, 1.0855 secs
  DNS-lookup:   0.0001 secs, 0.0000 secs, 0.0388 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0035 secs
  resp wait:    0.1243 secs, 0.1017 secs, 1.0834 secs
  resp read:    0.0080 secs, 0.0003 secs, 0.2225 secs

Status code distribution:
  [200] 2253 responses

단점

하지만 커맨드라인에서 실행시켜야 하기 때문에 dynamic 하게 쿼리스트링, path param 을 변경하는 것은 어렵습니다.

또한 많이 사용되고 star도 많이 받은 오픈소스이지만 관리는 잘 되지 않고 있는 느낌입니다. 마지막 v0.1.4가 2020년 8월 이후로 업데이트가 없는 듯 하구요.

결론

간단히 커맨드라인 툴로써 부하테스트를 할 수 있는 프로그램을 찾는다면 hey를 사용하는 것은 괜찮은 것 같습니다. 한 번 사용해보시는 것을 추천 드립니다.

NestJS Provider Injection scopes에 대해(singleton, request, transient)

iKay — Mon, 31 Jul 2023 00:28:11 +0900

현대 웹 개발에서 확장 가능하고 유지보수가 용이한 애플리케이션을 구축하는 것은 성공에 아주 중요합니다. NestJS는 강력하고 진보적인 Node.js 프레임워크로서, 체계적이고 효율적이며 확장 가능한 애플리케이션을 만들 수 있는 능력으로 큰 인기를 얻고 있습니다. NestJS 애플리케이션의 유지보수성과 유연성에 기여하는 핵심 기능 중 하나가 강력한 의존성 주입 시스템입니다.

이 의존성 주입 시스템의 핵심에는 "프로바이더(Provider)"라는 개념이 있습니다. 프로바이더는 다른 부분에서 주입될 수 있는 클래스 또는 값으로, 기능을 구성하고 공유하는 데 도움을 줍니다. 그러나 프로바이더를 정의하는 것만으로는 충분하지 않습니다. 또한 이러한 프로바이더들이 어떻게 애플리케이션 내에서 관리되고 공유되어야 하는지 고려해야 합니다. 이것이 "프로바이더 스코프(Provider Scope)" 개념이 등장하는 곳입니다.

이번 스트에서는 NestJS Provider scopes 중 singleton, request 그리고 transient에 대해 정리해 보고자 합니다. 이러한 스코프를 이해하는 것은 애플리케이션 구조를 결정하고 provider의 라이프사이클을 효과적으로 관리하는 데에 꼭 필요하다고 생각합니다.

Singleton

default 옵션으로 동작하기 때문에 가장 일반적으로 사용되는 scope입니다. singleton scope에서 Provider는 애플리케이션 전체에서 단 하나의 인스턴스만 생성되고 공유됩니다. 즉, 처음 bootstrap 됐을 때 인스턴스가 생성되며, 그 후로는 같은 인스턴스가 계속해서 사용됩니다.

방금 설명드린대로 싱글톤은 기본적으로 NestJS 프로바이더의 default 스코프입니다. 따라서 `@Injectable()` 데코레이터를 사용하여 Provider를 정의하면 scope가 명시되지 않은 경우 자동으로 singleton scope로 취급됩니다.

singleton은 애플리케이션에서 여러 곳에서 동일한 인스턴스를 사용해야 할 때 유용합니다. 예를 들어, 데이터베이스 연결, 로깅 서비스, 설정 정보, 캐싱 메커니즘 등과 같이 여러 부분에서 동일한 상태를 공유해야 하는 경우에 singleton scope를 사용합니다.

singleton scope를 사용하는 경우, 주의해야 할 점이 있습니다. Provider가 애플리케이션 전체에서 하나의 인스턴스를 공유하기 때문에, Provider에 상태를 저장하면 다른 부분들이 이 상태를 공유하게 됩니다. 따라서 싱글톤 프로바이더의 상태는 멱등성(idempotence)을 유지하고, 사이드 이펙트가 없도록 신경 써야 합니다.

Singleton은 애플리케이션의 공통적인 상태와 로직을 공유하는 데 유용하지만, 상태 변경에 대한 주의가 필요하다는 점을 잊지 말아야 합니다.

Request

매번 HTTP 요청과 관련된 단위 작업에서 프로바이더의 라이프사이클을 유지해야 하는 경우 사용됩니다. Request scope에서 프로바이더는 각각의 HTTP 요청마다 새로운 인스턴스가 생성되고, 해당 요청을 처리하는 동안에만 유지됩니다.

Request scope는 웹 서버 애플리케이션에서 각각의 클라이언트 요청을 독립적으로 처리해야 할 때 유용합니다. HTTP 요청은 보통 서로 다른 클라이언트들이 동시에 접속하고 요청하는 상황이 발생하게 되는데, Request scope는 각각의 요청 처리를 위해 별도의 인스턴스를 제공함으로써 각 Request 마다 고유한 데이터를 가지게 됩니다.

이러한 특성으로 인해, Request scope는 주로 요청마다 state를 유지해야 하는 경우에 사용됩니다. 예를 들어, 사용자의 로그인 정보, 요청마다 다른 인증 토큰, 요청마다 생성되는 request id 등이 이에 해당합니다.

Request scope 사용하기 위해서는 `@Injectable()` 데코레이터와 함께 `Scope.REQUEST` 옵션을 설정해야 합니다:

Request scope는 HTTP 요청마다 독립적인 상태를 유지해야 하는 경우에 매우 유용하지만, 동시에 인스턴스를 많이 생성하므로 성능에 영향을 미칠 수 있습니다. 따라서 신중하게 사용해야 하며, 필요한 경우에만 적절하게 활용하는 것이 좋습니다.

Transient

Transient scope는 injection 될 때마다 새로운 인스턴스가 생성되어야 하는 Provider에 사용됩니다. 이 Scope는 애플리케이션의 다른 부분들과 상태를 공유하지 않으려는 경우에 유용하며, 각 Injection 지점이 새롭고 독립적인 인스턴스를 받도록 보장할 수 있습니다.

Transient scope는 생소하기도 하고 특별한 경우인 것 같아 NestJS에서 Transient scope를 사용하는 일반적인 상황에 대해 위 둘의 내용보다는 조금 더 자세히 정리하고자 합니다.

1. 상태를 유지하는 서비스(Stateful Services)

특정 작업 또는 요청에 대해 상태를 유지하는 서비스가 있는 경우, Transient scope를 사용하여 각 요청이나 작업에 대해 독립적인 서비스 인스턴스를 생성합니다. 이렇게 함으로써 서로 다른 요청들 간에 상태가 공유되지 않고, 데이터 오염이나 예상치 못한 동작을 방지할 수 있습니다.

2. 요청별 데이터 저장(Request-Specific Data)

특정 HTTP 요청과 관련된 데이터를 저장해야 할 때(예: 요청별 데이터 캐싱 등), Transient scope를 사용할 수 있습니다. 이렇게 하면 각 요청마다 데이터를 격리하여 서로 간섭하지 않도록 보장할 수 있습니다.

3. 성능 최적화(Performance Optimization)

일부 경우에는 Transient scope를 사용하여 성능 최적화를 할 수 있습니다. 예를 들어, Provider를 생성하는 데 자원이 많이 소모되는 경우, 해당 프로바이더의 수명을 최소한으로 제한하여 작업이 완료된 후 인스턴스가 폐기되도록 할 수 있습니다.

4. 병렬 작업(Parallel Operations)

멀티스레드 또는 병렬 처리 환경에서는 Transient scope를 사용하여 공유 리소스에 대한 경합을 피할 수 있습니다. 각 스레드 또는 프로세스는 자체적인 프로바이더 인스턴스를 가져오므로 동기화와 잠재적인 병목 현상을 줄일 수 있습니다.

5. 외부 API 또는 연결(External APIs or Connections)

외부 API나 연결(예: 데이터베이스 연결, 웹소켓 등)과 같이 독립된 인스턴스가 필요한 경우, Transient scope를 사용하여 각 애플리케이션 부분이 독립적인 연결 또는 세션을 받도록 할 수 있습니다.

하지만 Transient scope를 사용할 때는 신중해야 합니다. 각 주입 지점마다 새로운 인스턴스를 생성하는 것은 메모리와 리소스를 더 소비할 수 있으므로, singleton이나 request scope와 비교해 메모리 사용에 주의해야 합니다. 애플리케이션의 기능과 요구사항에 따라 적절한 스코프를 선택하는 것이 중요합니다.

모든 서비스가 tansient로 정의되어야 하는 것은 아니며, 많은 서비스는 기능과 요구사항에 따라 singleton이나 request scope로 정의하는 것이 적절합니다. 각 provider에 적합한 scope를 선택하여 NestJS 애플리케이션의 올바른 동작과 성능을 보장하는 것이 중요합니다.

NestJS + TypeORM 트랜잭션(Transaction) 사용에 대한 고민

iKay — Sun, 23 Jul 2023 13:48:02 +0900

과거 그리고 현재에도 웹 애플리케이션을 개발할 때 Spring Boot(https://spring.io/projects/spring-boot)가 많이 사용되고 있습니다.

하지만 요즘 TypeScript 생태계가 점점 강력해지면서 NestJS의 점유율도 조금씩 증가하는 것 같습니다.

그림1. 구글트렌드 Spring Boot vs NestJS

NestJS는 Spring을 모방하면서 발전한다는 생각이 드는데 이유는 사용법과 철학이 매우 유사하게 느껴지기 때문입니다. Spring에서 주요하다고 여겨지는 개념인 DI, IoC, AOP 등의 개념이 NestJS 에서도 그대로 보여지구요.

하지만 아직은 Spring Boot에 비해 다른 기능들이 빈약한 편이긴 합니다. 한 가지 예로, 트랜잭션(Transaction) 사용법입니다. Spring에서 표준이다 시피한 JPA를 사용한다면 @Transactional 어노테이션을 반드시 사용해 봤을 것입니다. 이에 Spring 사용자라면 Service Layer에서 트랜잭션 사용에 대한 불편함을 크게 경험해 본적이 없을 것 같습니다.

여기서 말하는 불편함이란, 트랜잭션 커넥션을 열고 예외가 발생하면 롤백하거나 성공하면 커밋 하는 등의 애플리케이션 로직을 직접 Service Layer에서 해야 한다는 점을 말하는 것입니다.

NestJS에는 Spring에서의 JPA와 같이 표준 ORM이 없는 것 같습니다. 현재는 TypeORM이 가장 많이 사용되지만 가장 많이 사용된다고 표준이라 할 수는 없고 앞으로 현재 인기를 얻고 있는 Prisma(https://www.prisma.io/) 같은 것이 더 많이 사용될 수도 있을 것 같습니다.

그래도 현재 NestJS + TypeORM 의 조합이 가장 많이 사용되는 것 같으니 TypeORM 에 대한 이야기를 당분간 해보려 합니다.

이제까지 NestJS + TypeORM 조합으로 애플리케이션을 개발할 때 트랜잭션 처리에 대한 불편함을 많이 느껴왔는데 이것을 어떻게 해결하면 좋을지 고민해본 내용을 정리하고자 합니다.

쇼핑몰에서 다수 계정의 상태를 일괄적으로 비활성화 시키는 기능을 추가하고자 하는 예제입니다.

User Entity는 다음과 같습니다. beInactive() 메소드를 추가해서 user를 비활성화 시키는 메소드를 추가하였습니다.

@Entity()
export class User {
  @PrimaryGeneratedColumn({ type: 'int', unsigned: true })
  id: number;

  @Column({ type: 'varchar', length: 20 })
  name: string;

  @Column({ default: true })
  isActive: boolean;

  constructor(args?: { name: string; isActive?: boolean }) {
    if (args) {
      this.name = args.name;
      this.isActive = args.isActive ?? true;
    }
  }

  /**
   * 비활성화 시킨다
   */
  beInactive() {
    this.isActive = false
  }
}

UserRepository는 다음과 같이 custom repository를 구성하였습니다. findByIds()와 save()를 하는 메소드를 UserRepository에 정의한 후 구현하였습니다.

@Injectable()
export class UsersRepository {
    constructor(
        @InjectRepository(User)
        private usersRepository: Repository<User>,
    ) {}

    async findByIds(ids: number[]): Promise<User[]> {
        const users = await this.usersRepository.findBy({ id: In(ids) })
        return users
    }

    async save(users: User[]): Promise<User[]> {
        const savedUsers = await this.usersRepository.save(users, { transaction: false })
        return savedUsers
    }
}

이제 실제로 로직을 구성해봅시다.

여러 계정의 상태를 일괄적으로 비활성화 시키는 기능을 추가하고자 합니다. 목적을 달성하기 위해 다음과 같이 Service layer에 코드를 작성할 수 있습니다.

@Injectable()
export class UsersService {
 constructor(
        private usersRepository: UsersRepository,
    ) {}

    async makeUsersBeInactive(userNos: number[]): Promise<void> {
        const users = await this.usersRepository.findByIds(userNos)
        users.forEach((user) => user.beInactive())
        await this.usersRepository.save(users)
    }
}

잘 동작하는 것 처럼 보이겠지만 중간 실패시 롤백처리를 하기 위해 트랜잭션 기능을 넣고 싶은 경우 어떻게 하면 좋을까요?

1. QueryRunner를 통해 트랜잭션을 제어

가장 쉽게는 DataSource로 부터 QueryRunner를 얻어 트랜잭션을 직접 제어하는 방식입니다. 이 방법은 NestJS 공식문서(https://docs.nestjs.com/techniques/database#typeorm-transactions)에서도 소개하고 있는 방법이고 합니다. 그리고 Node.js를 사용해온 사람이라면 가장 흔하게 사용할 방법일 것 같네요.

export class UsersService {
    constructor(
        private dataSource: DataSource,
    ) {}

    async makeUsersBeInactive(userNos: number[]): Promise<void> {
        const queryRunner = this.dataSource.createQueryRunner()

        await queryRunner.connect()
        await queryRunner.startTransaction()
        try {
            const users = await queryRunner.manager.findBy(User, { id: In(userNos) })
            users.forEach((user) => user.beInactive())
            await queryRunner.manager.save(users)

            await queryRunner.commitTransaction()
        } catch (err) {
            await queryRunner.rollbackTransaction()
        } finally {
            await queryRunner.release()
        }
    }
}

물론 잘 동작합니다. 그러나 두 가지 문제가 있습니다.

첫 째, userRepository custom repository를 사용할 수 없습니다

둘 째, user를 비활성화 시키는 비즈니스 로직과 트랜잭션을 제어하는 애플리케이션 로직이 혼재돼 있어 관심사 분리 측면에서 서로 분리가 필요해 보입니다.

이 두 가지 문제를 해결해 보고자 합니다.

2. custom repository와 dataSource를 공유

UsersService.makeUsersBeInActive는 dataSource를 통해 queryRunner를 얻었고 이것을 custom repository인 UsersRepository와 queryRunner를 공유하면 custom repository를 이용하면서 트랜잭션을 사용할 수 있을 것 같습니다. 그러면 다음과 같이 Repository와 Service 코드를 변경할 수 있을 것 같습니다

@Injectable()
export class UsersRepository {
    constructor(
        @InjectRepository(User)
        private usersRepository: Repository<User>,
    ) {}
    
     async findByIds(ids: number[], queryRunner?: QueryRunner): Promise<User[]> {
        if (!queryRunner) {
            const users = await this.usersRepository.findBy({ id: In(ids) })
            return users
        } else {
            const users = await queryRunner.manager.findBy(User, { id: In(ids) })
            return users
        }
    }

    async save(users: User[], queryRunner?: QueryRunner): Promise<User[]> {
        if (!queryRunner) {
            const savedUsers = await this.usersRepository.save(users, { transaction: false })
            return savedUsers
        } else {
            const savedUsers = await queryRunner.manager.save(users, { transaction: false })
            return savedUsers
        }
    }
}

export class UsersService {
    constructor(
      private usersRepository: UsersRepository,
      private dataSource: DataSource,
    ) {}
  
    async makeUsersBeInactive(userNos: number[]): Promise<void> {
      const queryRunner = this.dataSource.createQueryRunner();
      await queryRunner.startTransaction();
      try {
        const users = await this.usersRepository.findByIds(userNos, queryRunner);
        users.forEach((user) => user.beInactive());
        await this.usersRepository.save(users, queryRunner);

        await queryRunner.commitTransaction();
      } catch (err) {
        await queryRunner.rollbackTransaction();
      } finally {
        await queryRunner.release();
      }
    }
  }

첫 번째 문제였던 custom repository를 사용하는 목적은 달성하였습니다. 하지만 repository가 괴상해졌습니다. 각 메소드마다 queryRunner 파라미터를 검사해서 있으면 넘겨받은 queryRunner를 사용하고 없으면 inject된 repository를 사용하는게 괴상하지 않나요? 그리고 일일이 service에서 queryRunner를 만들어서 넘기는 것도 괴상하지 않나요?

이를 해결하기 위해 repository에서 생성자로 queryRunner를 넘겨받아서 queryRunner를 통해 manager로 usersRepositry를 생성해서 사용하면 될 것 같습니다.

export class UsersRepository {
  private usersRepository: Repository<User>;

  constructor(private queryRunner?: QueryRunner) {
    if (queryRunner) {
      this.usersRepository = queryRunner.manager.getRepository(User);
    }
  }

  async findByIds(ids: number[]): Promise<User[]> {
    const users = await this.usersRepository.findBy({ id: In(ids) });
    return users;
  }

  async save(users: User[]): Promise<User[]> {
    const savedUsers = await this.usersRepository.save(users, {
      transaction: false,
    });
    return savedUsers;
  }
}

@Injectable()
export class UsersService {
  constructor(
    private dataSource: DataSource,
  ) {}
  
  async makeUsersBeInactive(userNos: number[]): Promise<void> {
    const queryRunner = this.dataSource.createQueryRunner();
    const usersRepository = new UsersRepository(queryRunner)
    await queryRunner.startTransaction();
    try {
      const users = await usersRepository.findByIds(userNos);
      users.forEach((user) => user.beInactive());
      await usersRepository.save(users);

      await queryRunner.commitTransaction();
    } catch (err) {
      await queryRunner.rollbackTransaction();
    } finally {
      await queryRunner.release();
    }
  }
}

하지만 또 다른 문제를 낳았어요. UsersService에서 UsersRepository를 inject 할 수 없고 필요한 곳에서 객체를 직접 생성해야만 하는 점이 말이에요. 이렇게 되면 모킹이 어려워 테스트 하기가 어려운 코드가 되어 좋지 않습니다.

또한 현재로서는 dataSource를 UsersService가 생성해서 UsersRepository에 넘겨줘야하기 때문에 트랜잭션에 관한 애플리케이션 로직도 제거하기 힘들어 보입니다.

이쯤에서 고민해 봤을 때 문제는 dataSource를 생성하고 접근하는 부분인 것 같습니다. 근본적인 해결을 위해서는 dataSource를 전역에서 접근할 수 있는 곳에 저장해야 맞을 것 같습니다. 그리고 dataSource는 각 요청(request)마다 격리되어 생성되어야 하며, 응답(response)이 완료됐을 때 dataSource에 관한 resouce가 반환 되어야 할 것 같습니다.

3. Request 마다 전역적으로 접근 가능한 QueryRunner 만들기

request 마다 전역적으로 접근 가능한 무언가를 만들어 주기 위해 우선 Injection scopes를 알아야 합니다.

https://docs.nestjs.com/fundamentals/injection-scopes

Documentation | NestJS - A progressive Node.js framework

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Rea

docs.nestjs.com

각 request 마다 생성되는 request 객체에 db connection을 넣을 것인데 싱글 쓰레드로 동작하는 Node.js 환경에서 각 request 마다 독립된 한경을 갖기 위해서는 매번 각 요청마다 객체를 생성하는 방법이 있습니다. 이를 이용할 것입니다.

이를 위해 UsersRepository의 scope를 REQUEST로 설정합니다.

@Injectable({ scope: Scope.REQUEST })
export class UsersRepository {

그리고 각 request 마다 독립된 queryRunner를 만들기 위해 QueryRunnerMiddleware라는 것을 만듭니다.

@Injectable()
export class QueryRunnerMiddleware implements NestMiddleware {
  constructor(private dataSource: DataSource) {}
  async use(req: Request, res: Response, next: NextFunction) {
    const queryRunner = this.dataSource.createQueryRunner()
    await queryRunner.connect()
    // @ts-expect-error
    req.queryRunner = queryRunner
    next();
  }
}

QueryRunnerMiddleware에서는 QueryRunner를 만들어 request 객체에 넣습니다.

이제 전역적으로 QueryRunner에 접근가능합니다. 그래서 UsersRepository와 UsersService를 다음과 같이 수정할 수 있습니다.

@Injectable({ scope: Scope.REQUEST })
export class UsersRepository {
  usersRepository: Repository<User>;

  constructor(
    @Inject(REQUEST) private request: Request,
  ) {
    // @ts-expect-error
    const queryRunner: QueryRunner = this.request.queryRunner
    queryRunner.manager.getRepository(User)
    this.usersRepository = queryRunner.manager.getRepository(User)
  }

  async findByIds(ids: number[]): Promise<User[]> {
    const users = await this.usersRepository.findBy({ id: In(ids) });
    return users;
  }

  async save(users: User[]): Promise<User[]> {
    const savedUsers = await this.usersRepository.save(users, {
      transaction: false,
    });
    return savedUsers;
  }
}

@Injectable()
export class UsersService {
  constructor(
    private usersRepository: UsersRepository,
    @Inject(REQUEST) private request: Request,
  ) {}

  async makeUsersBeInactive(userNos: number[]): Promise<void> {
    // @ts-expect-error
    const queryRunner: QueryRunner = this.request.queryRunner
    await queryRunner.startTransaction()
    try {
      const users = await this.usersRepository.findByIds(userNos);
      users.forEach((user) => user.beInactive());
      await this.usersRepository.save(users);
      throw new Error() // 예외를 던져 commit 되지 않는 것을 확인합니다.

      await queryRunner.commitTransaction();
    } catch (err) {
        console.log(err)
      await queryRunner.rollbackTransaction();
    } finally {
      await queryRunner.release();
    }
  }

UsersService에서 볼 수 있듯이 중간에 throw Error 를 해서 데이터의 변경이 롤백되는 것을 확인할 수 있었습니다.

이제 대략 첫 번째 문제였던 Custorm Repository를 사용할 수 없던 것을 해결한 것 같습니다.

이제 두 번째 문제였던 UsersService에서 애플리케이션 로직과 비즈니스 로직을 분리하는 방법에 대해 고민해봅시다.

4. 트랜잭션(Transaction)을 데코레이터(Decorator)로 분리하기

UsersService 메소드를 다시 살펴보면 트랜잭션을 제어하는 애플리케이션 로직과 유저를 비활성화 시키는 비즈니스 로직은 서로 연관이 거의 없음을 알 수 있습니다. 심지어 서로 파라미터를 주고 받지도 않습니다.

  async makeUsersBeInactive(userNos: number[]): Promise<void> {
    // @ts-expect-error
    const queryRunner: QueryRunner = this.request.queryRunner
    await queryRunner.startTransaction()
    try {
      const users = await this.usersRepository.findByIds(userNos);
      users.forEach((user) => user.beInactive());
      await this.usersRepository.save(users);

      await queryRunner.commitTransaction();
    } catch (err) {
        console.log(err)
      await queryRunner.rollbackTransaction();
    } finally {
      await queryRunner.release();
    }
  }

이렇게 메소드를 실행시킬 때 로직 전 후 서로 영향을 미치지 않는 어떤 로직을 실행시키고 싶은 경우 여러 가지 방법이 있겠으나 프록시를 이용해 데코레이터를 사용할 수 있습니다.

export function Transactional() {
    return function(target: any, key: string, description: PropertyDescriptor) {
        const originalMethod = description.value

        description.value = new Proxy(originalMethod, {
            async apply(target, thisArgs, args) {
                // originalMethod 실행 전 애플리케이션 로직 실행 

                const result = await originalMethod.apply(thisArgs, args)
                
                // originalMethod 실행 전 애플리케이션 로직 실행
                return result
            }
        })
    }
}

이해하기 어려울 것 같아 코드 완성 전 모습을 보여드리자면, 위 주석으로 설명한대로 originalMethod가 실행되기 전후에 트랜잭션을 생성하고 커밋, 롤백하는 등의 로직을 넣을 예정입니다.

완성하면 다음과 같습니다.

import type { QueryRunner } from 'typeorm';

export function Transactional() {
  return function (target: any, key: string, description: PropertyDescriptor) {
    const originalMethod = description.value;

    description.value = new Proxy(originalMethod, {
      async apply(target, thisArgs, args) {
        const queryRunner: QueryRunner = thisArgs.request.queryRunner;
        await queryRunner.startTransaction();
        try {
          const result = await originalMethod.apply(thisArgs, args);
          await queryRunner.commitTransaction();
          return result;
        } catch (err) {
          await queryRunner.rollbackTransaction();
        } finally {
          await queryRunner.release();
        }
      },
    });
  };
}

@Injectable()
export class UsersService {
  constructor(
    private usersRepository: UsersRepository,
  ) {}

  @Transactional()
  async makeUsersBeInactive1(userNos: number[]): Promise<void> {
      const users = await this.usersRepository.findByIds(userNos);
      users.forEach((user) => user.beInactive());
      await this.usersRepository.save(users);
  }
}

이제 두 번째 목적도 드디어 달성했습니다. 제가 원하던 코드가 이런 것이었습니다! UsersService에 비즈니스 로직과 애플리케이션 로직이 분리되어 훨씬 깔끔해졌네요..!

하지만 scope를 Request를 선언했다는 점에서 매 요청마다 객체를 계속 만들기 때문에 자원을 비효율적으로 사용할 것 같다는 느낌이 남습니다.

5. Typeorm Transactional 사용하기

더 쉬운 방법이 있습니다. Typeorm Transactional을 사용하는 것입니다. https://www.npmjs.com/package/typeorm-transactional

typeorm-transactional

A Transactional Method Decorator for typeorm that uses cls-hooked to handle and propagate transactions between different repositories and service methods. Inpired by Spring Trasnactional Annotation and Sequelize CLS. Latest version: 0.4.1, last published:

www.npmjs.com

본래 https://github.com/odavid/typeorm-transactional-cls-hooked 였는데 TypeORM이 0.3 버전이 나오면서 호환되로록 folk 된 버전입니다.

GitHub - odavid/typeorm-transactional-cls-hooked: A Transactional Method Decorator for typeorm that uses cls-hooked to handle an

github.com

원리는 cls-hooked(https://www.npmjs.com/package/cls-hooked)를 사용해서 request 마다 context를 만들어서 거기에 connection을 저장해서 사용하는 것으로 보입니다.

cls-hooked

CLS using AsynWrap instead of async-listener - Node >= 4.7.0. Latest version: 4.2.2, last published: 6 years ago. Start using cls-hooked in your project by running `npm i cls-hooked`. There are 719 other projects in the npm registry using cls-hooked.

www.npmjs.com

3년 전에 이와 관련된 내용을 다룬 적이 있는데 아마 동작 원리가 비슷할 것 같습니다. https://kay0426.tistory.com/60

AsyncHooks로 context에 DB connection 저장하기

서론 Node 13.X 버전부터 AsyncHooks라는 것이 도입되었다. AsyncHook이란, 쉽게 설명하자면, 실행 context마다 고유한 id를 줘서 callback후에도 callback 전의 context를 알 수 있게 해주는 것이다. 더 자세한 내

kay0426.tistory.com

라이브러리화 했기 때문인지라 사용법은 정말 쉽습니다. 설명대로,

필요한 라이브러리를 설치하고

yarn add typeorm-transactional
yarn add typeorm reflect-metadata

main.ts에 initializeTransactionalContext()를 추가해줍니다.

import { NestFactory } from '@nestjs/core';
import { initializeTransactionalContext } from 'typeorm-transactional';

import { AppModule } from './app';

const bootstrap = async () => {
  initializeTransactionalContext();

  const app = await NestFactory.create(AppModule);

  await app.listen(3000);
};

bootstrap();

그리고 app.module.ts 에 다음과 같이 dataSourceFactory에 addTransactionalDataSource()를 추가해줍니다.

import { DataSource } from 'typeorm';
import { addTransactionalDataSource } from 'typeorm-transactional';

@Module({
  imports: [
    UsersModule,
    TypeOrmModule.forRootAsync({
      useFactory() {
        return {
          type: 'mysql',
          host: 'localhost',
          port: 3306,
          username: 'root',
          password: 'root',
          database: 'store',
          logging: true,
          entities: [User],
          synchronize: true,
        }
      },
      async dataSourceFactory(options) {
        if (!options) {
          throw new Error('Invalid options passed')
        }
        
        return addTransactionalDataSource(new DataSource(options));
      }
    }),
  ],
  controllers: [...],
  providers: [...],
})

그러면 별다른 수정없이 트랜잭션이 잘 동작합니다; 너무 쉽습니다;

import { Transactional } from 'typeorm-transactional'

@Injectable()
export class UsersService {
  constructor(
    private usersRepository: UsersRepository,
  ) {}
  
  @Transactional()
  async makeUsersBeInactive(userNos: number[]): Promise<void> {
      const users = await this.usersRepository.findByIds(userNos);
      users.forEach((user) => user.beInactive());
      await this.usersRepository.save(users);
      throw new Error() // 예외를 던지면 transaction이 rollback
  }
}

별 다른 이유가 없다면 현재로서는 typeorm-transactional을 사용하는 것이 베스트 프랙티스가 아닌가 싶습니다.

오늘은 예전 부터 NestJS에서 typeorm transaction을 잘 사용하는 방법에 대해 고민해본 점을 정리해보았습니다.

우선 Service layer에서 트랜잭션과 관련된 애플리케이션 로직과 User를 다루는 비즈니스 로직이 혼재되어 있는 부분이 좋지 못하다는 것을 밝혔습니다. 이를 해결하기 위해 query runner를 어떻게 다룰지를 긴 여정을 통해 살펴봤고 결국에는 UsersRepository scope를 Request로 두면서 request 객체에 query runner를 저장하여 이를 해결하였습니다. 또한, decorator를 이용해 트랜잭과 관련된 애플리케이션 로직을 감추는데 성공했습니다. 하지만 이 경우 Request 마다 객체를 생성하는 방식이라 리소르를 낭비할 수 있다는 한계점이 존재합니다.

더 좋은 방법은 이미 있는 오픈소스를 사용하는 것입니다. 이미 이 문제를 해결하기 위해 많은 사람들이 노력해온것 같고 그 방법으로는 typeorm-transactional(https://www.npmjs.com/package/typeorm-transactional)을 사용하는 것입니다. typeorm-transctional은 cls-hooked 기반으로 동작하여 db connection을 async local storage에 저장하여 동작할 것 같습니다.

앞으로 실제 프로덕트에서 NestJS가 더 흥했으면 하는 바람입니다.

긴 글 읽어주셔서 감사합니다.

MySQL innodb_flush_log_at_trx_commit 옵션

iKay — Fri, 3 Mar 2023 00:17:50 +0900

서론

실무에 있어서 MySQL 설정 중 하나인 innodb_flush_log_at_trx_commit 옵션이 무엇인지 알아두면 좋다.

공식문서 내용을 참고하는 것이 가장 정확하겠지만 영어문서를 읽는 것이 익숙하지 않다면 아래 정리 내용을 봐도 좋을 것 같다.

요약

innodb_flush_log_at_trx_commit 옵션은 InnoDB 스토리지 엔진에서 트랜잭션의 커밋(commit) 작업 시 로그 파일을 언제 디스크에 쓸 것인지를 결정하는 옵션이다. DB 운영 중 고민 해야 할 부분이 성능(performance)와 데이터 트랜잭션 커밋 신뢰성(ACID) 사이의 균형일텐데 이 둘 사이의 균형을 조절하는 옵션이라 보면 될 것 같다. 성능과 트랜잭션 커밋된 데이터의 신뢰성은 양립할 수 없고 경우에 따라 이 둘의 중요도에 따라 옵션을 잘 선택하는 것이 중요하다.

innodb_flush_log_at_trx_commit 은 0, 1, 2 값을 가질 수 있는데 기본값은 1 이다.

각 경우에 대해 설명하면 다음과 같다.

1. innodb_flush_log_at_trx_commit = 0 인 경우

트랜잭션의 커밋이 발생할 때마다 로그를 즉시 기록하지 않고, 일정 시간(기본적으로 대략 1초이지만 항상 1초를 보장하지는 않음)마다 로그가 기록되고 디스크에 flush 된다. 따라서 flush 되지 않은 트랜잭션은 DBMS가 다운되면 해당 데이터를 잃어버리게 된다. 또한 데이터 영속도 시간차가 발생해 트랜잭션에서 데이터는 삽입, 변경 후 직후 트랜잭션에서 쿼리하면 데이터가 제대로 쿼리되지 않을 수 있다.

이 경우 DBMS의 안정성은 낮겠지만 가장 높은 성능을 낼 수 있다.

2. innodb_flush_log_at_trx_commit = 1 인 경우 (default, 기본값)

트랜잭션의 커밋이 발생할 때마다 로그가 기록되고 디스크에 flush 된다. 즉, 모든 트랜잭션에 대해 full ACID compliance를 준수한다.

이 경우 데이터베이스 시스템의 안정성이 가장 높겠지만 매우 빈번한 디스크 I/O가 발생하므로 성능 저하가 발생할 수 있다.

3. innodb_flush_log_at_trx_commit = 2 인 경우

트랜잭션의 커밋이 발생할 때마다 로그를 기록하고, 일정 시간(기본적으로 대략 1초이지만 항상 1초를 보장하지는 않음)마다 디스크에 flush 한다. 따라서 0으로 설정했을 때와 마찬가지로 flush 되지 않은 트랜잭션은 DBMS가 다운되면 해당 데이터를 잃어버리게 된다. 또한 데이터 영속도 시간차가 발생해 트랜잭션에서 데이터는 삽입, 변경 후 직후 트랜잭션에서 쿼리하면 데이터가 제대로 쿼리되지 않을 수 있다.

이 경우 데이터베이스 시스템의 안정성과 성능 모두를 어느 정도 만족시키는 중간정도의 선택이라 볼 수 있다.

Log Flushing 에 대해

innodb_flush_log_at_timeout 설정에 의해 Log Flushing 주기가 설정되는데 기본값은 1초이다. 이 설정에 대해서는 우선 공식 문서 링크로 대체하고 다음에 다시 포스팅하면 좋을 것 같다.

결론

각 설정에 대해 성능과 DMBS의 안정성에 대한 관계를 표로 정리하면 다음과 같다.

innodb_flush_log_at_trx_commit 값	성능(Performance)	안정성(ACID compliance)
0	상	하
1(기본값)	하	상
2	중	중

성능과 안정성은 양립할 수 없는 관계이기 때문에 innodb_flush_log_at_trx_commit 옵션을 어떻게 설정하는지는 정답 없으며 운영하는 서비스 성격에 맞게 DBMS의 안정성과 성능 사이에서 균형있게 설정하면 된다.

헤드퍼스트 디자인패턴

iKay — Mon, 22 Aug 2022 00:21:25 +0900

얼마 전 지인에게 「헤드퍼스트 디자인페턴」이라는 책을 추천받아 읽게 되어 책을 읽고 난 후 느낀 점을 남기려 한다. 평점은 4/5점을 주고 싶다.

http://www.yes24.com/Product/Goods/108192370

헤드 퍼스트 디자인 패턴 - YES24

유지관리가 편리한 객체지향 소프트웨어 만들기!“『헤드 퍼스트 디자인 패턴(개정판)』 한 권이면 충분하다.이유 1. 흥미로운 이야기와 재치 넘치는 구성이 담긴 〈헤드 퍼스트〉 시리즈! 하나

www.yes24.com

코드를 자주 읽고 쓰는 사람이라면 디자인 패턴을 학습하는 것이 필요하다고 생각한다. 왜냐하면 다른 사람의 코드를 더 쉽게 읽을 수 있어 더 빠르게 파악할 수 있다고 생각하기 때문이다. 좋은 코드를 작성하기 위해서는 다른 사람의 코드를 오해 없이 이해하는 것이 우선이다. 이런 이유로 스스로도 평소에 틈틈이 이런 부류의 책을 시간을 내서 읽으려고 노력한다. 그리고 좋은 예제 소스코드(주로 유명한 오픈소스)로 부터 내가 아는 패턴을 발견했을 때 즐거움을 느끼곤 한다.

디자인 패턴의 고전은 그 유명한 「GoF의 디자인 패턴」 일 것이다. 이 책도 한 번 읽은 적은 있는데 워낙 오래전이고 이해를 못 했던 부분이 많아 책을 구해서 다시 읽어 보는 것도 좋을 것 같다. 그런데 한글 번역판 내용이 좋지 못하다는 것을 많이 들어서 한글책을 살지 말지 계속 고민이 된다.

http://www.yes24.com/Product/Goods/17525598

GoF의 디자인 패턴 - YES24

이 책은 디자인 패턴을 다룬 이론서로 디자인 패턴의 기초적이고 전반적인 내용을 학습할 수 있다.

www.yes24.com

서론이 길었던 것 같다. 본론으로 들어가 보자.

책은 각 챕터마다 하나의 디자인패턴을 다루고 있다. 각 챕터에서는 실제 세계에 있을법한 상황을 던져주고 이 문제를 해결하기 위해 어떤 디자인 패턴을 사용하면 될지를 보여주면서 문제를 해결해 나간다. 문제를 해결하기 위해 실제 어떻게 설계하면 될지 다이어그램을 그려보고 그것을 Java 코드로 옮기고 있다. 그렇게 문제를 해결한 후 각 디자인 패턴에 대한 정의, 설명도 자세히 다루는 편이다.

사실 나도 어떤 소프트웨어 문제를 해결하기 위해 바로 코딩을 시작하기보다는 다이어그램을 이렇게 저렇게 많이 그려 보면서 설계를 많이 고민하는 편이다. 그래서 그런지 이 책에서 문제를 해결하는 방식이 공감이 잘 되는 편이었다. 만약 소프트웨어 입문 자라면 이 책을 통해 디자인 패턴에 대한 지식뿐만 아니라 실제 있을 법한 문제를 해결해 나가는 습관까지 기를 수 있지 않을까 생각한다.

각 챕터의 순서는 저자가 생각하기에 주로, 자주 사용되는 순서로 배치를 한 것 같다. 그렇다고 뒤에 등장하는 챕터들이 중요하지 않은 것은 아닌 것 같다. 하지만 맨 마지막 챕터에서 여러 디자인 패턴을 두 페이지 정도에 간략히 설명하고 있는 부분이 있는데 이 부분은 조금 아쉽다. 각 패턴을 간략히 설명하려다 보니 설명이 너무 부족한 것 같다. 차라리 맨 마지막 챕터는 없애는 게 좋지 않을까 생각한다.

책의 내용은 굳이 요약하지 않겠다. 그냥 사서 읽어라. 읽는 과정에서 이 패턴이 어떤 문제를 해결할 수 있는지를 따라가는 재미를 내가 뺏고 싶지 않기 때문이다. 책의 구성이 좋은 편이고 몰입력도 좋은 편인 것 같다.

만약 디자인패턴 입문, 초보 수준이라면 이 책을 한 번 읽어보는 것이 큰 도움이 될 것 같다. 아마 코드를 보는 시야가 더 넓어질 것이고 코드를 작성하는 습관이 달라질 것이다. 그리고 이 책에서 다루지 않고 있는 다른 디자인 패턴을 학습하는 데 있어서 큰 밑거름이 될 것 같다. 좋은 책인 것 같다.

multi-stage로 TypeScript 기반 Nodejs docker image 크기 줄이기

iKay — Tue, 2 Aug 2022 01:54:26 +0900

서론

최근 몇 년 전만 해도 소스코드의 runtime을 container 환경으로 빌드해서 배포&운영 한다는 것이 생소하고 어려웠던 것으로 인식되던 것으로 기억한다. 하지만 요즘은 container 환경으로 빌드만 할 수 있으면 쉽게 배포&운영할 수 있게 해주는 제품들이 시장에 많이 나와서 이러 진입장벽이 많이 낮아진 것 같다. 심지어 소규모 스타트업 회사가 kubernates를 운영할 줄 모른다고 해도 AWS의 ECS, EKS 등을 사용한다면 container 환경으로 쉽게 배포&운영하는데 큰 지장이 없을 정도이다. 현재 내가 몸담고 있는 서비스회사에서도 ECS를 사용하는 곳이 있는데 크게 무리없이 서비스를 잘 하고 있는 것 같다.

container는 주로 Docker가 사용되는 것 같다. 사실 나도 Docker말고는 다른 container를 사용해본적이 거의 없고 사실상 현재 업계에서는 Docker가 container로써 표준인 것 처럼 인식되는 것 같다.

개인적으로 Nodejs 런타임을 Docker container로 배포하고 운영하는게 난이도가 쉽고 작은 서비스에서는 매우 효율적이라고 생각한다. 왜 좋은지는 다음에 한 번 상세히 다뤄보면 좋을 것 같다.

그리고 사실상 Nodejs로 백엔드를 운영한다면 JavaScript를 직접 쓰는 곳은 거의 없고 TypeScript를 사용할 것이다. 나도 현재는 매일매일 TypeScript를 사용하고 있다. 하지만 나는 Nodejs 백엔드를 TypeScript를 이용해서 제대로 운영하고 있을까 매일매일 의심하기도 한다. TypeScript, Nodejs 자체가 진입장벽이 낮고 자유도가 높으니 말이다.

Docker도 마찬가지이다. 아마 구글에 "typescript dockerfile example" 라고 치고 맨 위에 있는 Dockerfile 스크립트를 복사 붙여넣기 해도 실제 운영환경에 배포가능한 docker image가 빌드될 것이다.

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

이렇게 생각없이 붙여넣은 스크립트가 당장은 동작하기 때문에 지금 이 순간에는 정답이라 볼 수 있겠지만 프로젝트 덩치가 커지면 배포되는 container image 크기도 커질 것이기 때문에 배포시 효율적이지 못하게 된다.

서론이 길었는데 오늘은 간단히 TypeScript 기반 Nodejs Docker container image의 크기를 줄이는 방법에 대해 살펴보려고 한다. 여러 시도가 있겠지만 최종적으로는 multi-stage 방법으로 그 크기를 최소화 해 볼 예정이다.

소스코드는 https://github.com/i-kay/multi-stage-example-1 를 참고하면 되겠다.

준비

예제를 보이기 위해 NestJs 웹 애플리케이션 하나를 준비했다. 아래 cli 한 줄이면 NestJS 프로젝트가 생성된다.

nest new .

.dockerignore 파일을 하나 만들어서 내용을 채워준다. Dockerfile에서 Copy시 무시되는 파일, 디렉토리들이다.

vi .dockerignore

# 아래 내용 추가
dist
node_modules

# :wq

이렇게만 하면 웹 애플리케이션 하나를 개발하고 컨네티어로 만들 준비가 벌써 끝나게 된다.

1 단계 - 시작

서론에서 보였듯이 Dockerfile을 아래처럼 작성하고,

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

image를 build 해보자

docker build . -t multi-stage-example-1:1

image size는 다음과 같다

docker images           
---
REPOSITORY             TAG  ...  SIZE
multi-stage-example-1  1    ...  532MB

2 단계 - devDependencies를 삭제?

Nodejs를 경험해봤다면 devDependencies가 운영할때 필수가 아님을 누구나 알 것이다. 그렇다면 Dockerfile에서 `npm install` 된 `node_modules`를 모두 삭제하고 다시 `npm install --production`을 해주면 container image size가 줄어들지 않을까?

Dockerfile을 아래와 같이 수정해보자. 방금 설명대로 `npm_modules`를 production 환경에 맞게 재설치해서 크기를 줄이려 하는 의도이다.

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
+ RUN rm -rf ./npm_modules
+ RUN npm install --production
EXPOSE 3000
CMD ["npm", "start"]

image를 build 해보자.

docker build . -t multi-stage-example-1:2

하지만 용량이 줄어 들지 않는다. 오히려 2MB 늘었다.

docker images           
---
REPOSITORY             TAG  ...  SIZE
multi-stage-example-1  2    ...  534MB
multi-stage-example-1  1    ...  532MB

그 이유는

+ RUN rm -rf ./npm_modules
+ RUN npm install --production

을 추가했을지라도 그 전 명령어들이 image layer에 남아있기 때문이다. 쉽게 말해서 `>` 표시된 부분이 image가 build될 때 그대로 남게 된다.

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
> RUN npm install
> COPY . .
> RUN npm run build
+ RUN rm -rf ./npm_modules
+ RUN npm install --production
EXPOSE 3000
CMD ["npm", "start"]

그 내용은 `docker image history`를 통해 자세히 볼 수 있다. 결과를 보면 알 수 있겠듯이 상당한 용량을 차지하는 `npm install` 부분이 제거되지 않을 것 같다.

docker history multi-stage-example-1:2
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
c1674234860f   2 hours ago   CMD ["npm" "start"]                             0B        buildkit.dockerfile.v0
<missing>      2 hours ago   EXPOSE map[3000/tcp:{}]                         0B        buildkit.dockerfile.v0
<missing>      2 hours ago   RUN /bin/sh -c npm install --production # bu…   1.98MB    buildkit.dockerfile.v0
<missing>      2 hours ago   RUN /bin/sh -c rm -rf ./npm_modules # buildk…   0B        buildkit.dockerfile.v0
<missing>      2 hours ago   RUN /bin/sh -c npm run build # buildkit         62.5kB    buildkit.dockerfile.v0
<missing>      2 hours ago   COPY . . # buildkit                             470kB     buildkit.dockerfile.v0
<missing>      2 hours ago   RUN /bin/sh -c npm install # buildkit           365MB     buildkit.dockerfile.v0
<missing>      2 hours ago   COPY package*.json ./ # buildkit                325kB     buildkit.dockerfile.v0
<missing>      2 hours ago   WORKDIR /usr/src/app                            0B        buildkit.dockerfile.v0
<missing>      4 days ago    /bin/sh -c #(nop)  CMD ["node"]                 0B        
<missing>      4 days ago    /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B        
<missing>      4 days ago    /bin/sh -c #(nop) COPY file:4d192565a7220e13…   388B      
<missing>      4 days ago    /bin/sh -c apk add --no-cache --virtual .bui…   7.77MB    
<missing>      4 days ago    /bin/sh -c #(nop)  ENV YARN_VERSION=1.22.19     0B        
<missing>      4 days ago    /bin/sh -c addgroup -g 1000 node     && addu…   153MB     
<missing>      4 days ago    /bin/sh -c #(nop)  ENV NODE_VERSION=18.7.0      0B        
<missing>      13 days ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B        
<missing>      13 days ago   /bin/sh -c #(nop) ADD file:a2648378045615c37…   5.53MB

3 단계 - devDependencies를 정말 삭제할 수 없을까?

결론부터 말하자면 docker가 build될 때 devDependencies를 삭제할 수 있다. `RUN` 명령어 마다 layer를 만들기 때문에 하나의 명령어로 실행되게끔 만들면 되긴 한다.

이건 change 이고

FROM node:18-alpine
WORKDIR /usr/src/app
- COPY package*.json ./
- RUN npm install
COPY . .
- RUN npm run build
- RUN rm -rf ./npm_modules
- RUN npm install --production
+ RUN npm install \
	&& npm run build \
	&& rm -rf ./npm_modules \
	&& npm install --production
EXPOSE 3000
CMD ["npm", "start"]

이건 결과 script 이다. 이것을 보면 되겠다.

FROM node:18-alpine
WORKDIR /usr/src/app
COPY . .
RUN npm install \
	&& npm run build \
	&& rm -rf ./npm_modules \
	&& npm install --production
EXPOSE 3000
CMD ["npm", "start"]

보다시피 심플하다.

마찬가지로 image를 build 해서

docker build . -t multi-stage-example-1:3

image 사이즈를 보면 줄긴했다.

docker images           
---
REPOSITORY             TAG  ...  SIZE
multi-stage-example-1  3    ...  301MB
multi-stage-example-1  2    ...  534MB
multi-stage-example-1  1    ...  532MB

결과로만 보면 이 방법도 나쁘진 않은 것 같다. 하지만 이 방법의 문제점은 한 줄로 명령어를 작성해서 보기가 좋지 않고 layer가 캐싱될 수 없다는 것이다. 대부분의 경우 소스코드의 수정이 일어나지만 node module을 새로 설치하는 경우는 드물 것이다. 그래서

COPY package*.json ./
RUN npm install

부분을 따로 1 단계, 2 단계 에서 분리한 것인데 3 단계에서는 그것을 이용할 수가 없다. 이 캐싱을 잘 이용하면 빌드를 매우 빠르게 할 수 있다.

docker의 layer caching에 대해서는 다음에 한 번 다뤄보면 좋을 것 같다.

4 단계 - multi-stage 도입

실제로 3 단계까지 고민을 했었고 더 나은 방법이 없을까 찾아봤을 때 쉽게 답을 찾을 수 있어서 조금 허무했다. 그 방벙이 지금 소개할 multi-stage 방식이다. multi-stage 방식에서는 흔히 builder라는 stage와 실제 배포될 stage를 구분해서 build 될 때 불필요한 것들을 가지지 않게 하는 것 같다.

우선 Dockerfile을 보자.

FROM node:18-alpine AS builder
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --production
COPY --from=builder /usr/src/app/dist ./dist
EXPOSE 3000
CMD ["npm", "run", "start:prod"]

script를 살펴보자.

FROM으로 stage는 구분되고 첫 번째 stage는 `AS builder`라고 붙여서 `builder` 라고 명시를 하였다. 이름을 붙이지 않으면 `STAGE-0` 이런식으로 숫자가 붙게된다.

`package.json`과 `package-lock.json`만 복사해오고 `npm install --production` 함으로써 `devDependencies`는 제외하고 `dependencies`만 설치돼 매우 경량화 된다.

첫 번째 stage에서 `/usr/src/app`이란 곳에 install & build를 하게 돼서 1 단계와 같은 결과를 가지고 있을 것이다 하지만 두 번째 stage로 넘어오면서 `COPY --from=builder {src} {dest}` 해준 것만 실제로 전달되며 최종 stage로만 image는 build 된다. script 내용대로 `COPY --from=builder` 할 때 실행가능한 .js 파일들, 즉 dist 디렉토리만 복사해오게 돼 매우 경량화된다.

그리고 `devDependencies`애 있던 `nestcli`를 이젠 더 이상 사용할 수 없기 때문에 `npm run start:prod` 로 실행되도록 해야 한다.

image를 build하고

docker build . -t multi-stage-example-1:4

image size를 보자.

docker images           
---
REPOSITORY             TAG  ...  SIZE
multi-stage-example-1  4    ...  258MB
multi-stage-example-1  3    ...  301MB
multi-stage-example-1  2    ...  534MB
multi-stage-example-1  1    ...  532MB

1 단계로부터 약 280MB나 줄일 수 있게 됐고 캐싱 레이어도 유지할 수 있게 되었다..!

docker history를 보자. 첫 번째 stage에서 install, build 등은 포함되지 않는 것을 한 번 더 확인할 수 있다.

docker history multi-stage-example-1:4
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
4d6a2809a48f   2 hours ago   CMD ["npm" "run" "start:prod"]                  0B        buildkit.dockerfile.v0
<missing>      2 hours ago   EXPOSE map[3000/tcp:{}]                         0B        buildkit.dockerfile.v0
<missing>      2 hours ago   COPY /usr/src/app/dist ./dist # buildkit        60.8kB    buildkit.dockerfile.v0
<missing>      2 hours ago   RUN /bin/sh -c npm install --production # bu…   91.3MB    buildkit.dockerfile.v0
<missing>      2 hours ago   COPY package*.json ./ # buildkit                325kB     buildkit.dockerfile.v0
<missing>      2 hours ago   WORKDIR /usr/src/app                            0B        buildkit.dockerfile.v0
<missing>      4 days ago    /bin/sh -c #(nop)  CMD ["node"]                 0B        
<missing>      4 days ago    /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B        
<missing>      4 days ago    /bin/sh -c #(nop) COPY file:4d192565a7220e13…   388B      
<missing>      4 days ago    /bin/sh -c apk add --no-cache --virtual .bui…   7.77MB    
<missing>      4 days ago    /bin/sh -c #(nop)  ENV YARN_VERSION=1.22.19     0B        
<missing>      4 days ago    /bin/sh -c addgroup -g 1000 node     && addu…   153MB     
<missing>      4 days ago    /bin/sh -c #(nop)  ENV NODE_VERSION=18.7.0      0B        
<missing>      13 days ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B        
<missing>      13 days ago   /bin/sh -c #(nop) ADD file:a2648378045615c37…   5.53MB

결론

이번에는 TypeScript기반 Nodejs 웹 애플리케이션을 Docker container로 build 하는 과정에서 multi-stage 방식을 사용함으써 container image를 줄여봤다. container image size가 계속 커진다면 이렇게 multi-stage 방식으로 builder를 분리시켜 운영하는 것도 고려해볼 만한 선택지 중 하나가 될 것 같다.

참고

- https://docs.docker.com/develop/dev-best-practices/#how-to-keep-your-images-small

Clustered Index와 Secondary Index

iKay — Thu, 28 Jan 2021 01:03:58 +0900

Index란?

Index란, 테이블에 대한 동작속도를 높여주는 자료구조이다.

조금 더 자세히 설명하자면, Disk에서 발생하는 I/O 시간은 Main Memery에서 발생하는 I/O에 비해 매우 크다. 따라서, DB를 통해 데이터를 검색시 Disk I/O가 빈번히 일어나지 않도록 하는 것이 유리할 것 같다. 이를 위해 Index를 사용한다. Index를 통해 Disk I/O의 횟수를 최대한 줄여 DB의 성능을 높일 수 있는 것이다. 따라서, Index는 DB에서 뿐만 아니라, random access를 할 때 사용하면 적합하다.

아래 그림은 id=106번 학생을 검색하는 과정이다. Disk I/O에 비해, block 내의 탐색 시간은 매우 적게 걸리므로 일단 무시한다. 순서대로 정렬되어 있는 key인 경우, 이진탐색을 한다면 꽤 빠를 것이다.

Index를 이용한다면,
[index block1 -> (index block2) -> data block3-> 2 번째 레코드] 이렇게 탐색하게 되면 총 I/O는 2~3번 일어난다. 다른 레코드를 검색한다고 해도 총 2~3번이 보장될 것이다.
index를 이용하지 않으면,
최선의 경우 바로 data block3에 random access 하게 되어 1번의 I/O만으로 id=106을 검색성공 하겠지만, 최악의 경우는 data block1, data block2, ... data block N 이렇게 모든 N개의 disk block을 scan 해야 할 수도 있다.

그림1. Index를 통해 data를 검색하는 과정 예

Index는 data와 별개로 저장된다. data 파일 레코드를 저장하는 것에 비해 공간을 덜 차지해 하나의 디스크 블록에 더 많은 데이터가 담길 수 있어서 한 번의 I/O 발생시, Index는 데이터 파일 레코드에 비해 더 많은 데이터를 읽을 수 있다. 따라서, index block에 데이터가 더 많이 저장되기 때문에 index를 fully scan 하는 것이 data를 fully scan 하는 것 보다 부담이 덜하다.

Index를 통해 data를 검색을 하는 것은 Index가 없는 것 보다 시간이 적게 걸리겠지만 새로운 data를 insert 하는 경우는 index 와 data를 순차적으로 정렬해야 하는 경우가 발생할 수도 있기 때문에 좋은 성능을 내지 못 할 수가 있어서 항상 Index를 사용하는 것은 올바르지 않다. 또한, Index는 Clustered Index와 Secondary Index로 보통 종류가 나뉘는데 둘의 특징을 잘 구분해서 사용해야 더 좋은 성능을 낼 수 있을 것이다.

Spatial Index(Spatial Index는 R-Tree)를 제외하고는 보통 B-Tree로 구현된다. B-Tree로 구현되기 때문에 Binary Tree에 비해 child가 많아 Block 단위로 I/O가 일어날 수 있도록 구현한다면 I/O를 최소화 할 수 있어 Binary Tree에 비해 유리한 것 같다. Memory DB의 경우 Index로써 Hash Table로 구현되는 경우도 있다. 이 경우 access time은 B-Tree보다 빠르겠지만 크기를 비교하는데는 사용할 수 없다.

Index에 대해 다룰 주제는 많겠지만 오늘은 Clustered Index와 Non Clustered Index의 탐색 방법에 초점을 맞춰서 차이점을 비교해 보고자 한다.

Clustered Index

특징

InnoDB 엔진에서 table의 Primary Key를 정의하면 Clustered Index가 된다.
테이블당 하나만 가질 수 있다.
Insert시 data가 정렬되고 index는 data block의 첫 번째 레코드의 주소값을 갖게 된다. index가 곧 바로 data block에 접근해서 Secondary Index보다 동작이 빠른 편이다.
data가 정렬되어 저장되므로, Secondary Index에 비해 범위로 질의를 하는 것에 유리하다. 빈번한 I/O가 덜 발생할 것이기 때문이다.

사실 위에서 나타낸 그림이 Clustered Index 이다. 그림을 보면 알겠지만 id=106인 Brian을 찾기 위해 우선 index block을 scan(1~2번의 I/O 발생) 하고, data block3번 에서(1번의 I/O 발생) id=106 Brian을 총 2~3번의 I/O로 찾을 수 있다.

범위로 검색하는 경우를 보자. 만약 id=101~104번의 학생을 fetch 한다고 생각해보자. 그러면, index block을 scan 한 후(1~2번의 I/O 발생) data block1를 가져오고(I/O 1번 발생), data block2(I/O 1번 발생)를 가져오면 범위 검색을 할 수 있다. 총 3~4번의 I/O가 발생하게 된다.

그림 2. Clustered Index

Secondary Index

특징

Primary Key 이외에 필요한 정렬 기준이 있을 경우 사용한다.
테이블당 여러 개 가질 수 있다.
data record가 정렬되어 있지 않다.
index가 data record의 모든 주소값을 가지고 있어야 한다.
unique 하지 않아도 된다.
데이터 레코드가 index 순서대로 정렬 되어 있지 않기 때문에 범위 조건으로 검색하게 되면 많은 I/O가 발생할 수 있다. 그러면 좋은 성능을 내지 못 할 것이다.
index는 모든 레코드에 대한 색인 데이터를 들고 있어야 하고 정렬된다. 따라서, update, delete, insert시 오래 걸릴 수 있고, clustered index에 비해 더 많은 공간을 차지하게 된다.

학생의 경우 id는 Primary Key로써 clustered index가 되지만 name으로 검색 조건을 더 빠르게 하고 싶을 수 있다. 이런 경우 Secondary Index를 사용한다. 아래 그림이 그 예이다.

name이 Jane인 학생을 찾는 과정은 id=105로 Jane을 찾는 것과 비슷하다. 하지만 ASCII Code, 알파벳 순서대로 Bill~James의 범위의 레코드를 가져오려면 index block1로부터 data block1, data block2, data block3, data block4를 모두 읽어야 하므로 그림상 I/O가 5~6번 정도 발생할 것임이 보인다. 이처럼 범위로 데이터를 검색하는 경우는 clustered index에 비해 불리하고, 모든 data의 entry에 대해 색인을 갖고 있어야 해서 더 많은 공간을 차지하게 된다.

그림 3. Secondary Index

결론

index에 대해 간략히 알아봤고, 그 중 clustered index, secondary index의 차이와 동작방식에 대해 조금 정리를 해 보았다. 아직 실제로 인덱스로 DB를 튜닝해본 경험이 거의 없지만 나중에 실제로 튜닝해보면서 성능이 얼마나 차이가 나는지 실험하여 내용을 추가하면 좋을 것 같다.

TypeScript, tsconfig.json 주요 설정

iKay — Thu, 7 Jan 2021 03:49:38 +0900

서론

TypeScript를 더 잘 사용하기 위해 컴파일 하기 위한 설정, 동작방식을 정의하는 tsconfig를 어느 정도 이해할 필요가 있다고 생각한다. Node.js 프로젝트에 TypeScript를 설정하기 위해서 공식문서를 참고하는 것이 가장 정확하겠지만 정보의 양이 방대해서 주요한 몇몇 설정만 정리해 보고자 한다. 앞으로 지식과 경험이 더 넓어지면 내용을 계속 덧붙여 나갈 계획이다. 자세한 설명은 당연히 공식문서를 참조하는 것이 좋겠다.

tsconfig.json을 작성하는 것은 옳고 그름의 문제가 아니다. 프로젝트 마다, 팀마다 각각 상황에 맞게 설정하면 되는 것이기 때문에 무조건 따라야 하는 설정은 없다. 잘 모르겠으면 권장하는대로, 기본값대로 사용해도 될 것이다. 다만, 각 프로젝트 마다 성격에 맞게 사용하기 위해, "어떤 설정이 있었고, 이 설정이 무엇을 뜻했던 것 같다." 정도는 알고 있는 것이 좋을 것 같아서 정리해 보고자 한다. 만약 TypeScript 설정에 당장은 관심이 없고 잘은 모르겠지만 TypeScript를 사용해야 하는 상황이라면 공식 문서에서 추천해주는 대로 extends 해서 일단 사용하는 것도 큰 노력을 사용하지 않는 좋은 방법일 것이다.

TypeScript가 컴파일 될 때, 보통 TypeScript 프로젝트의 root에 tsconfig.json 파일이 위치하는데, compile하기 위한 소스코드의 위치, compile 옵션을 이곳에 json 파일로 나타내면 된다. 만약, tsc 명령어로 compile 하는데 input file이 주어지지 않으면 현재 디렉토리에서 부터 부모 디렉토리 체인으로 거슬러 올라가면서 tsconfig.json 파일을 찾는다. 반대로, tsc 명령어에 input file이 주어지면 tsconfig.json 파일을 검색하지 않는다.

설정들에 대한 설명들을 레퍼런스 문서에서 나누고 있는 큰 범주대로 나누었다. 공식문서에는 알파벳 순으로 설정들을 나열하고 있지만 여기서는 개인적으로 중요하다고 생각되는 것을들 먼저 나열할 수도 있다.

1. File Inclusion

TypeScript가 compile에 포함하거나 제거할 파일들을 명시하고, compile 하기 위해 참조해야하는 설정이 있는 파일들을 설정한다.

include, exclude

컴파일 할때 포함하거나 제외할 filenames 배열이나 패턴을 명시한다. 패턴을 명시할 때 glob pattern을 사용하고, filenames의 path는 tsconfig.json 이 있는 곳으로 부터 상대경로에 있는 것들이다.

주의할 점은 exclude는 include와 함께 동작하면서 include 될 것을 exclude 시키는 것이지, code에 있는 것을 제외시키는 것은 아니다.

include는 defalut로 다음과 같은 값을 갖는다.

["**/*"]

exclude는 default로 다음과 같은 값을 갖는다.

// 만약 outDir이 명시되어 있으면 그것도 default에 포함된다.
["node_modules", "bower_components", "jspm_packages"]

예

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

extends

상속받을 다른 base file을 명시한다. 설정들은 base file이 우선 load 되고, 상속하는 file이 override 하게 동작한다. 팀 내에서 이런식으로 tsconfig.json 파일을 npm으로 관리해도 좋을 것 같다.

files

include 시킬 파일들을 개별적으로 포함시킨다. 보통의 경우 include만으로 해결될 것이기 때문에 아마 잘 사용되지 않을 것 같다.

예

{
  "compilerOptions": {},
  "files": [
    "core.ts",
    "sys.ts",
    "types.ts",
    "scanner.ts",
    "parser.ts",
    "utilities.ts",
    "binder.ts",
    "checker.ts",
    "tsc.ts"
  ]
}

2. Compiler Options

Project Options

TypeScript가 compile 되는 방식, 동작하는 방식을 설정한다.

사용할 수 있는 많은 옵션들이 있다. 중요하다고 생각되는 것들, 자주 사용될 것 같은 것 위주로 정리해 보고자 한다.

lib

lib는 target과 함께 사용되기도 해서 target과 함께 구분해가면서 봐두면 좋다고 생각한다.

lib는 타입스크립트는 built-in JS API(예, Math)와 브라우저 환경(예, document) 등에서 사용할 수 있는 타입을 기본적으로 제공한다. JS 버전마다 사용할 수 있는 문법이나 API 등이 조금씩 다른다. 보통 계속 추가되면서 하위호환을 유지하는 편이다. 이런 것들 중 target에 설정한 버전에 부합하는 API 등의 타입을 사용할 수 있게 해준다.

예를 들어,

target에 ES6라고 설정한 경우, ES6+부터 Map이라는 것을 JS에서 네이티브하게 사용할 수 있기 때문에 Map을 사용하기 위한 타입을 제공한다.
백엔드 개발을 하는 경우 브라우저 환경의 개발환경을 설정할 필요가 없다. 그래서 이런 경우, "dom" 타입을 설정할 필요가 없다.
polyfill을 사용하거나, nodeJS가 native 적으로 ECMAScript 버전을 일부 지원하는 경우 target 버전과 완전히 동일하지 않아도 liib로 선택적으로 버전을 올려서 사용할 수 있다.

타입이 어떻게 설정될까 궁금해서 조금 찾아보다가, TypeScript의 lib에 대한 소스코드에서 동작하는 방식을 추론할 수 있었는데, 소스코드에서 볼 수 있듯이 상위버전은 하위 버전을 포함해서 사용할 수 있게 되고, lib.esXXXX.d.ts는 ECMAScript의 XXXX 버전에 해당하는 모든 것을 포함한다는 것도 볼 수 있다.

// 예, lib.es2019.d.ts 파일의 소스코드

/// <reference no-default-lib="true"/>


/// <reference lib="es2018" />
/// <reference lib="es2019.array" />
/// <reference lib="es2019.object" />
/// <reference lib="es2019.string" />
/// <reference lib="es2019.symbol" />

Node.JS 가 지원하는 ES 버전에 맞는 맞는 lib 설정을 할 필요가 있을 것이다. 그렇다면 Node.JS가 어떤 버전의 ES를 지원하는지 잘 알아야 한다. 그런 곳을 정리해 놓은 곳이 있는데, 이것을 보고 lib에 ES 버전을 적절히 올리거나 필요한 것만 추가해서 사용하면 될 것 같다. 예를 들어, Node12 버전을 사용하는 경우, ES2019는 100% 지원하고 ES2020은 BigInt, Promose.allSettled 등을 일부 지원하므로 이런 것을 추가해서 사용하면 될 것 같다.

default는 ES3이고, 현대 JavaScript 브라우저와 애플리케이션은 보통은 ES6+에서 동작하므로 ES6(ES2015)로 설정하기를 개인적으로 권장한다. 만약 target을 설정했는데 lib를 생략했다면, lib는 target과 같은 버전으로 변경되어 동작하게 된다고 공식문서에서 설명하고 있다. 다음은 공식문서의 target 부분에서 인용한 것이다. 이 부분 때문이라도 lib를 target과 함께 봐두면 좋은 것 같다.

Changing target also changes the default value of lib. You may “mix and match” target and lib settings as desired, but you could just set target for convenience.

target

target은 TypeScript가 컴파일 되는 결과물인 JavaScript 코드로 변환되는 버전을 결정한다. 즉, 위의 lib 설정에서 밝힌 것 처럼, 만약 백엔드 Node.JS를 운영할 것이라면, 운영하는 Node.JS가 지원하는 버전의 ES 버전에 맞게 target을 지정하면 될 것이다. 프론트엔드라면 개발하려는 브라우져 버전에 맞게 target을 설정하면 될 것 같다.

allowJs

TypeScript는 기본적으로 JavaScript 위에서 동작하는 언어이고, JavaScript를 TypeScript로 점차적으로 변환시켜서 사용할 수도 있다. 이 점으로 볼 때, .ts 파일에서 .js 파일도 import 있게 할 수 있어야 하는 경우도 있을 것 같다. 그래서 allowJS는 .ts, .tsx 파일에서 .js 파일을 import 할 수 있게 해준다.

기본적으로 false 이지만, JavaScript 프로젝트를 점차 TypeScript로 변환시키는 경우 true로 설정하는 것이 필요할 것이다.

removeComments

TypeScript 코드를 JavaScript로 컴파일 시킬 때, 주석(comments)을 모두 제거 시키는 옵션이다.

기본적으로 false 이지만, 번들 사이드 등을 줄이기 위해 소스코드에서 주석을 제거하고 싶다면 true로 하면 된다.

sourceMap

sourcemap fiile(xxx.js.map)을 생성할 것인지 유무를 설정하는 것이다. 이 file은 JavaScript와 함께 생성되면, debugger나 다른 툴이 본래의 TypeScript 소드 코드를 볼 수 있게 해주도록 한다. hello.ts를 컴파일 하고 sourceMap을 true로 하면 hello.js와 함께 hello.js.map 파일이 생성되는 것을 볼 수 있을 것이다.

기본값은 false인데, 디버깅이 필요한 개발환경에서는 true로 하고, 배포 사이즈를 줄여야 하는 배포환경에서는 false 해, 서로 다른 환경에서 적절하게 컴파일 되도록 설정하면 될 것 같다.

Strict Checks

Type을 얼마나 엄격하게 검사할지를 검사하는 옵션이라고 보면 될 것 같다. strict 에는 8가지 옵션이 있다.

1) strict

2) alwaysStrict

3) noImplicityAny

4) noImplycityThis

5) strictBindCallApply

6) strictFunctionTypes

7) strictNullChecks

8) strictPropertyInitialization

위에서도 밝혔지만, 여기서는 각 옵션이 어떤 것인지를 간단히만 밝히고 있다. 더 자세한 설명은 공식문서를 보는 것이 더 잘 이해가 될 것이고 정확하다.

1) strict

만약 이 모든 옵션을 모두 사용하려면 단지, { "strict": true } 로 설정하면 될 것 같다. 하지만, JavaScript에서 TypeScript로 옮기는 경우에는 바로 strict 를 적용할 수 없으니 여러 옵션들 중 선택해서 사용해야 하는 경우도 있을 것이다. 그래서 나머지 strict 특징들을 알아두었다가 필요할 때 적절히 사용하는 것도 좋을 것 같다. 또한 나머지 각각의 특징을 이해하는 것이 strict를 이해하는 것이기도 할 것 같다. 그리고 strict: true로 설정한 후 TypsScript 버전을 올렸을 때 추가되는 속성이 있다면 그 시점에 타입에러가 발생할 수도 있을 것이다.