변경 사항 롤백

새로운 기능을 작업하고, 기능 브랜치에 배포한 후, PR을 생성하고, 마스터 브랜치에 병합한 뒤, 프로덕션에 배포했습니다! 이제 거의 모든 워크플로우를 살펴봤습니다. 하지만 다음 단계로 넘어가기 전에, 문제가 발생했을 때 서버리스 배포를 롤백할 수 있는지 확인하고 싶습니다. 이는 CI/CD 파이프라인의 중요한 부분이라고 생각합니다. 이번 장에서는 서버리스 앱에 적합한 롤백 전략에 대해 알아보겠습니다.

Seed에서 이를 어떻게 수행하는지 간단히 살펴보겠습니다.

이전 빌드로 롤백하기

이전 빌드로 롤백하려면 Seed에서 여러분의 앱으로 이동하세요. 예를 들어, prod 스테이지에 잘못된 코드를 푸시했다고 가정해 보겠습니다. Activity 탭으로 이동하여 과거 빌드 목록을 확인하세요.

이전에 성공한 빌드를 선택하고 Rollback을 클릭하세요.

prod 스테이지에 대해 새로운 빌드가 트리거되는 것을 확인할 수 있습니다.

인프라 변경 롤백

우리의 모노레포 설정에서 앱은 여러 서비스로 구성되어 있으며, 일부 서비스는 서로 의존성을 가지고 있습니다. 이러한 의존성 때문에 서비스들은 특정 순서로 배포되어야 합니다. 이전에 의존성이 있는 서비스 배포하기에 대해 이야기한 적이 있습니다. 변경 사항을 롤백할 때도 배포 순서를 주의 깊게 고려해야 합니다.

간단한 예제로 billing-api와 notify-job 두 개의 서비스를 살펴보겠습니다. billing-api는 note-purchased라는 이름의 SNS 토픽을 내보냅니다. 다음은 billing-api의 serverless.yml 예제입니다:

Outputs:
  NotePurchasedTopicArn:
    Value:
      Ref: NotePurchasedTopic
    Export:
      Name: ${self:custom.stage}-ExtNotePurchasedTopicArn

그리고 notify-job 서비스는 이 토픽을 가져와서 notify 함수를 트리거하는 데 사용합니다:

functions:
  notify:
    handler: notify.main
    events:
      - sns:
          arn: !ImportValue ${self:custom.stage}-ExtNotePurchasedTopicArn
          topicName: ${self:custom.stage}-note-purchased

billing-api 서비스가 먼저 배포되어야 한다는 점에 유의하세요. 이는 ExtNotePurchasedTopicArn이라는 내보내기 값이 먼저 생성되었는지 확인하기 위함입니다. 그런 다음 notify-job 서비스를 배포할 수 있습니다.

서비스들이 배포된 후에 잘못된 커밋을 푸시했고, 이를 롤백해야 한다고 가정해 봅시다.

이 경우에는 배포 순서의 역순으로 서비스를 롤백해야 합니다.

즉, notify-job을 먼저 롤백하여 ExtNotePurchasedTopicArn이라는 내보내기 값이 다른 서비스에서 사용되지 않도록 한 다음, billing-api 서비스를 롤백하여 SNS 토픽과 내보내기 값을 제거해야 합니다.

다음으로, 빌드 속도를 높이기 위해 적용할 수 있는 최적화 방법을 살펴보겠습니다.