변경된 서비스만 배포하기

서버리스 애플리케이션을 반복적으로 배포하다 보면, 서버리스 배포가 그리 빠르지 않다는 것을 알게 될 것입니다. 특히 앱에 많은 서비스가 있는 경우 더욱 그렇습니다. 여기서 빌드 속도를 높이기 위해 할 수 있는 몇 가지 방법이 있습니다. 그 중 하나는 변경된 서비스만 배포하는 것입니다.

이번 장에서는 그 방법을 살펴보겠습니다.

참고로, Seed에서는 기본적으로 이 작업을 수행합니다. like 브랜치를 master 브랜치로 병합했을 때, like-api 서비스와 notes-api만 체크 표시가 나타났던 것을 기억할 것입니다. 다른 두 서비스는 회색 체크 표시가 나타났습니다. 이는 해당 서비스에 배포할 변경 사항이 없음을 의미합니다.

단일 서비스로 구성된 서버리스 앱에서는 CI/CD 파이프라인의 배포 전략이 간단합니다: 모든 git 푸시마다 앱을 배포합니다.

그러나 모노레포 설정에서는 앱이 여러 Serverless Framework 서비스로 구성됩니다. Seed에서 단일 리포지토리에 40개 이상의 서비스가 있는 앱을 가진 팀도 드물지 않습니다. 이러한 설정에서는 오타를 수정하려는 것뿐인데 모든 서비스를 배포하는 것은 말이 되지 않습니다! 변경된 서비스만 배포하고 싶을 것입니다. 모든 커밋마다 모든 서비스를 배포하는 것은 다음과 같은 이유로 문제가 됩니다:

1. 느림: 모든 서비스를 배포하는 데 시간이 오래 걸립니다. 특히 동시에 배포하지 않는 경우 더욱 그렇습니다.
2. 비용이 많이 듦: 전통적인 CI 서비스는 동시성에 대해 추가 요금을 부과합니다. 이 글을 쓰는 시점에서 CircleCI는 동시성 수준을 추가할 때마다 $50의 비용이 발생합니다. 따라서 모든 서비스를 동시에 배포하는 것은 매우 비용이 많이 들 수 있습니다.

서버리스 CI/CD 파이프라인에서 변경된 서비스만 배포하는 방법에는 몇 가지가 있습니다.

전략 1: Serverless Framework에서 배포 건너뛰기

serverless deploy 명령어는 배포 패키지가 변경되지 않았을 경우 배포를 건너뛰는 기능을 기본적으로 지원합니다.

배경을 살펴보면, serverless deploy를 실행하면 두 가지 작업이 내부적으로 수행됩니다. 먼저 serverless package를 실행하여 배포 패키지를 생성합니다. 이 패키지에는 CloudFormation 템플릿과 압축된 Lambda 코드가 포함됩니다. 그다음, 생성된 패키지를 배포하기 위해 serverless deploy -p path/to/package를 실행합니다. Serverless가 두 번째 단계에서 패키지를 배포하기 전에, 패키지의 해시를 계산하고 이전 배포의 해시와 비교합니다. 해시가 동일하면 배포를 건너뜁니다. 여기서는 과정을 단순화했지만 기본적인 개념은 이렇습니다.

하지만 이 방법에는 두 가지 단점이 있습니다.

1. Serverless Framework는 여전히 배포 패키지를 먼저 생성해야 합니다. Node.js 애플리케이션의 경우, 이는 의존성을 설치하고, 린팅을 실행하고, Webpack을 실행한 후 코드를 패키징하는 과정을 의미합니다. 즉, 배포를 건너뛰더라도 전체 프로세스가 여전히 상당히 느릴 수 있습니다.
2. 이전 배포가 외부적인 이유로 실패한 경우, 문제를 해결하고 serverless deploy를 다시 실행해도 배포가 건너뛰어질 수 있습니다. 예를 들어, serverless.yml에서 S3 버킷을 생성하려고 했지만 계정당 100개의 S3 버킷 제한에 걸렸다고 가정해 봅시다. AWS 지원팀과 상담하여 제한을 해제했습니다. 이제 serverless deploy를 다시 실행하지만, CloudFormation 템플릿이나 Lambda 코드가 변경되지 않았기 때문에 배포가 건너뛰어집니다. 이 문제를 해결하려면 --force 플래그를 사용하여 검사를 건너뛰고 강제로 배포를 진행해야 합니다.

전략 2: Git 로그를 통해 변경 사항 확인하기

더 나은 접근 방식은 서비스를 배포하기 전에 해당 서비스 디렉토리에 커밋이 있는지 확인하는 것입니다.

코드가 푸시되면, 다음 명령어를 실행하여 변경된 파일 목록을 얻을 수 있습니다:

$ git diff --name-only ${prevCommitSHA} ${currentCommitSHA}

이 명령어는 두 커밋 사이에 변경된 파일 목록을 제공합니다. 변경된 파일 목록을 바탕으로, 특정 서비스 관점에서 세 가지 시나리오가 있습니다. 여기서는 notes-api를 예로 들어 설명하겠습니다:

1. 내 서비스 디렉토리(예: services/notes-api)에서 파일이 변경된 경우 ⇒ notes-api 서비스를 배포합니다.
2. 다른 서비스의 디렉토리(예: services/like-api)에서 파일이 변경된 경우 ⇒ notes-api 서비스를 배포하지 않습니다.
3. 또는 libs/ 디렉토리에서 파일이 변경된 경우 ⇒ notes-api 서비스를 배포합니다.

여러분의 리포지토리 설정은 다를 수 있지만, 일반적인 개념은 동일하게 적용됩니다. 어떤 파일 변경이 개별 서비스에 영향을 미치는지, 그리고 어떤 변경이 모든 서비스에 영향을 미치는지 파악해야 합니다. 이 전략의 장점은 어떤 서비스를 건너뛸 수 있는지 미리 알 수 있어, 전체 빌드 프로세스의 일부를 생략할 수 있다는 점입니다!

이로써 개발 워크플로우에 대한 섹션을 마칩니다. 다음으로, AWS X-Ray를 사용하여 서버리스 애플리케이션을 추적하는 방법을 살펴보겠습니다.