배포 자동화 스크립트를 만들기 전에 가장 궁금했던 것은 배포 전략(?) 이었다.

예를 들어 로드 밸런서에 인스턴스 2 대를 운영 중이라면, 3 가지 정도의 배포 방법을 생각할 수 있다.

• 인스턴스를 2 대 이용할 경우, A 인스턴스를 중단하고 새로 배포 후, B 인스턴스를 중단하고 새로 배포하는 방법이 있을 수 있다.
• 인스턴스를 2 대에서 2 대를 추가할 경우, C/D 인스턴스에 새로 배포 후, A/B 인스턴스를 중단하는 방법이 있을 수 있다.
• 인스턴스를 2 대에서 1 대를 추가할 경우, C 인스턴스에 새로 배포 후에, A 나 B 인스턴스를 중단하든 그 반대로 하든... 아무튼...

Service 설정에 보면 Replica 전략에서 배포구성에 관한 옵션이 두가지 있다. minimumHealthyPercent 와 maximumPercent 인데 이것과 인스턴스 수 조정으로 배포 전략을 결정할 수 있다. minimumHealthyPercent 은 RUNNING 상태인 Task 수를 최소 얼만큼 유지할 것인지를 설정한다. 로드 밸런서를 붙인 상태에서는 동시에 inService 상태 인지도 체크한다. maximumPercent 는 RUNNING 상태이거나 PENDING 상태의 최대 Task 수를 고려하여 설정한다.

(아래는 min / max 로 표현하겠음.)

로드 밸런서를 붙인 상태에서 운영중인 2 대의 인스턴스를 가장 빠르고 안정적으로 배포하기 위한 설정을 위해 다음과 같이 테스트 해 보았다.

A. Instance 2 (+0) 50% 100%

이 설정은 인스턴스 2 대 중, 하나의 인스턴스의 Task(50%) 는 무조건 RUNNING 상태를 유지하게 된다는 것을 예상할 수 있다. 그로 인해 번갈아 가면서 배포가 가능하게 될 것이다.

- Service Log

로그를 보면 Task 를 삭제하거나 실행하는 과정은 간단하다.

1. 로드밸런스에서 인스턴스 등록 해제

2. Task DRAINING 시작

3. Task 중지

4. 새로운 Task 시작

5. 로드밸런스에서 인스턴스 재등록

여기서 max 를 200% 로 둔 다면 하나의 Task 를 DRAINING 으로 변경하며 즉시 여유분의 인스턴스를 찾을 것이므로 경고가 발생한다. 배포는 되겠지만 약간의 딜레이가 발생할 것이다.

B. Instance 2 (+0) 100% 150%

이 설정은 인스턴스 2 대 중, 2 대의 인스턴스의 Task(100%) 가 무조건 RUNNING 상태를 유지하게 되므로 배포할 방법이 없다.

min 을 100% 로 설정하려면 max 값에 대응할 수 있는 추가 인스턴스가 필요하다.

CPU / MEM / PORT 등의 요구사항을 만족하는 인스턴스를 찾지 못했다는 에러 메시지가 나타날 것이다.

- Service Log

C. Instance 2 (+1) 50% 150%

- Service Log

D. Instance 2 (+1) 100% 150%

- Service Log

E. Instance 2 (+2) 50% 200%

- Service Log

F. Instance 2 (+2) 100% 200%

- Service Log

위와 같이 minimumHealthyPercent / maximumPercent / task 수를 설정하여 다양한 배포 방법들을 테스트 해 보았다. B 를 제외한 A/C/D/E/F 의 배포는 모두 정상적으로 이루어 졌다. 물론 시간이나 순서 등은 각자의 배포물 용량이나 트래픽에 따라 변할 수 있다. 단계가 간결한 F 배포가 가장 빠를 것 같았는데 E 배포가 더 빨랐다는 것은 예상 밖이다. C 나 D 같은 경우는 min 과 max 값이 동시에 모두 가능할 때 어느쪽으로 먼저 배포에 영향을 미치는지를 보고 싶어서 테스트 한 것이었는데 minimumHealthyPercent 가 매우 중요함을 알게 됐다.이번 테스트로 A 방법이 가장 효율적인 것을 알게 되었고, 빠르고 빈도수가 높은 배포는 E/F 방법을 으로 전략을 세우는 것이 효과적임을 알게 됐다.

결론

가성비 좋은 배포는 A, 속도/빈도수 높은 배포는 E/F 를 사용하자.

드디어 ECS 마지막 단계인 배포다. ㅋㅋ 지금까지 Docker Image 를 만들었고, Docker Image 를 ECR 에 푸시했고, 해당 이미지를 Task 정의에 할당했고, Task 정의를 Cluster 의 인스턴스에서 실행해 보았다. 제목의 ECS 배포란 말은 Cluster 의 인스턴스에서 Task 정의를 실행한 것을 말한다. 정확한 표현으로는 단지 Task 실행이다. ^^ 이미 Task 정의를 Cluster 에서 직접 시켜봤으니 사실상 배포를 해 본 셈이다. 실제 웹서버 운영이라면 Auto scaling 이나 Load Balancing 을 붙이게 되는데 이것은 Cluster 의 Service 를 생성하여 설정할 수 있다.

* Service 가 해주는 일

1. Service 생성

Cluster - Services - [Create] 를 클릭하고 항목을 작성한다. Service 이름, Task 정의 선택, Task 수, 로드 밸런싱, Auto scaling 등을 설정하고 나머지는 다 default 로 둔다. (로드 밸런싱, Auto scaling 생성/설정은 알아서 ㅜ). Service 생성을 마치고 나면 Task 수 만큼의 인스턴스가 생성되어 바로 구동된다. 즉 바로 배포.

Service 에서는 Task 실행이 실패하거나 중단되어도 Task 수를 유지할 수 있도록 계속해서 Task 실행을 시도하게 된다. 이것 역시 Task 를 직접 실행하는 것과이 차이점이다. Service 에서 Task 수를 유지하려는 것은 Service 생성시 default 설정으로 둔 Replica 전략 때문이다. 이 Replica 는 최소 상태 백분율 및 최대 백분율 파라미터 등의 설정 대로 실행할 Task 정의를 어느 인스턴스에 배포할지를 판단한다.

즉, ECS 배포는 Task 의 실행, 곧 Service 를 생성하거나 업데이트 하는 순간 Task 정의가 실행되며 배포된다고 볼 수 있다. 추후 이미지를 수정하여 변경되거나 했을 때 최신 버전으로 인스턴스에 올리기 위해서는 Service 를 업데이트만 해주면 된다. Service 생성도 배포이고, Service 업데이트도 배포인 것이다.

2. Service 업데이트

Service 를 다른 용도로 업데이트 할 일은 별로 없을 것이다. 주로 인스턴스 수를 조정하거나 최신 이미지를 재배포 할 때 업데이트를 하게 될텐데, 업데이트는 매우 간단하다. Service 리스트에서 업데이트할 Service 에 체크하고 Update 를 클릭하면 기존 세팅이 나타나는데 [Force new deployment] 항목에 체크하고 나머지 항목은 모두 그대로 두면 latest 이미지를 가져와 업데이트 할 것이다.

이렇게 배포를 마쳤다. 여기까지는 ECS Document 만 보고 쉽게 따라할 수 있지만, Free Tier 사용자의 경우 EC2 를 두 개 이상 테스트 해보기는 쉬운 결정이 아닐 수도 있다. Fargate 도 마찬가지. 표면상 배포는 잘 돌아가겠지만, 관리 측면에서 보면 앞으로 고민해야 할 일이 더 많을 수도 있다. Image 업데이트부터 배포까지의 매우 번거로운 단계를 최대한 자동화 시키는 것에 대한 고민과, 인스턴스에 늘어나는 Image 에 대한 용량이나 롤백에 대한 고민, task 실행 실패시 알람 및 전략, ECS/Docker/EC2 로그 수집 방법 등등 필요로 하는 더 많은 기능들에 대해 고민해 봐야 한다. 운영면에서는 관련 문서가 그리 많지 않으니 그냥 열심히들 삽질해 보자.