테스트 셋 만들기

실제 돌아가고 있는 서비스의 배포 방식을 변경하는 것이다 보니, 가장 염두에 뒀던 건 모든 과정에서 에러가 없게 하는 것이었다.

이를 위해 프로덕션과 비슷하면서도 편하게 각종 실험을 할 수 있는 테스트 셋을 만드는 데 시간을 많이 쏟았다.

1. 테스트 인스턴스 생성 - 우선 여러 대 서버에 배포하는 상황을 가정하기 위해 EC2 인스턴스를 두 대 만들고, 태그, IAM 등 대부분의 설정을 프로덕션과 동일하게 맞췄다.

2. 로드 밸런서 생성 - 로드 밸런서를 만들어 1의 인스턴스를 타겟 그룹에 넣어주고, SSL도 등록

3. 서브도메인 - 실제 사용하고 있는 도메인에 ec2 라는 서브도메인을 추가한 뒤 여기에 2의 로드 밸런서를 연결해 ec2.example.com 으로 테스트 셋에 접근할 수 있게 했다.

db는 당연히 프로덕션을 그대로 옮기기엔 힘들어 테스트용으로는 sqlite를 사용하기로 했다.

배포 스크립트는 pyinfra로

앞선 글에서 정리했듯, 기존 배포 방식은 도커 이미지를 빌드 서버에서 빌드하고, ECS(EC2의 묶음)에서 해당 이미지를 가져가서 실행하는 식이었다.

EC2로의 직접 배포는 코드로 서버 구성 및 관리를 자동화할 수 있게 도와주는 pyinfra 라는 도구를 사용해서 진행했는데, 큰 장점 중 하나는 yaml이 아니라 우리 팀 백엔드 언어인 파이썬으로 그걸 가능하게 한다는 점이다. (기존 배포에서도 pyinfra 를 썼다.)
덕분에 슬랙 노티 같은 기존 코드도 재활용 가능하다.

여러 서버에 배포 스크립트를 돌리기 위해 내부적으로 Greenlet 를 이용, 스레드로 실행되기 때문에 파이썬적인 직관과는 다른 식으로 동작해 애를 먹기도 하지만 그래도!

(다른 포스팅에서 pyinfra를 더 다뤄볼 예정이다.)

Blue - Green in EC2?

기존 ECS의 Blue-Green 배포 방식은 ALB에서 타겟그룹을 변경하는 식으로 이뤄졌다.

Blue, Green 용으로 각각의 타겟 그룹을 구성해야하는 비효율이 있는데, (굳이 그 이유 때문만은 아니지만) EC2 직접 배포 방식에선 인스턴스의 사양을 더 올리고, 하나의 인스턴스 내부에서 Blue-Green 전환을 해보라는 CTO 님의 가이드가 주어졌다.

이런 자웅동체 방식의 전환은 (여러 조사와 시행 착오 끝에) 배포할 때마다 nginx에서 Blue용 포트, Green용 포트를 동적으로 변환해주는 방식으로 구현했는데 그림으로 나타내면 다음과 같다. 편의상 nginx를 EC2 외부에 표시했지만 EC2 내부에서 전환이 된다고 보면 된다.

EC2 내부를 좀 더 상세히 그림으로 나타내면 아래와 같다.
......

참고로 프론트엔드는 NEXT.js를 이용하는데 ECS 배포 땐 발생하지 않았던, 스태틱 파일을 불러오는 데 실패하는 이슈가 계속 발생했다.

ECS 배포 시엔 빌드 서버에서 만든 하나의 도커 이미지를 여러 서버가 공유하기 때문에 프론트엔드 서비스의 모든 Build Id가 동일했지만, EC2 방식은 인스턴스 각각에서 빌드를 하기 때문에 Build Id가 제각각인 게 문제의 원인.

원인 파악은 (지금 생각하면 이상할 정도로) 오래 걸렸지만 해결은 간단했다. generateBuildId 옵션만 넣어주면 된다.