Amazon ECS, 몇 개를 유지하고 어떻게 바꿔 끼울 것인가

편의점 야간 교대를 생각해 볼게요. 한 사람이 나가고 다음 사람이 오는 사이에 카운터가 비면 그 시간 동안 손님을 받을 수 없어요. 겹쳐서 교대하면 카운터는 비지 않지만 잠깐 두 사람 몫의 자리가 필요해요. 자리가 없으면 겹칠 수 없고, 겹칠 수 없으면 비는 시간을 받아들여야 해요.

컨테이너를 맡아 돌려 주는 도구가 실제로 정하는 것도 이 두 가지예요. 몇 개를 유지할 것인가, 그리고 바꿔 끼울 때 몇 개까지 겹치거나 비워도 되는가. 앞 시리즈에서 컨테이너를 상자에 담는 일까지 다뤘다면, 이 글부터는 그 상자를 실제로 세워 두고 교체하는 쪽 이야기예요. 그리고 운영에서 사고가 나는 자리는 거의 언제나 두 번째예요.

설계도와 실행과 유지는 다른 층이다

Amazon ECS를 처음 만지면 비슷해 보이는 이름 셋이 헷갈려요. 구분해 두면 이후의 모든 동작이 정리돼요.

태스크 정의는 무엇을 어떻게 실행할지 적어 둔 설계도예요. AWS 문서도 이것을 컨테이너를 어떻게 돌릴지 기술한 청사진으로 설명해요. 중요한 성질이 하나 있는데, 이 설계도는 고쳐 쓰는 것이 아니라 새 판을 찍어요. 값을 바꾸면 기존 것이 수정되는 대신 리비전 번호가 하나 올라간 새 정의가 만들어져요.

태스크는 그 설계도로 실제로 떠 있는 하나의 실행 개체예요. 서비스는 그 태스크가 정해진 개수만큼 계속 떠 있도록 지키는 층이고, 그 개수를 원하는 개수라고 불러요. 하나가 죽으면 서비스가 새로 띄워요.

처음 쓰는 사람이 가장 자주 겪는 혼란이 여기서 나와요. 설정을 고쳐 새 리비전을 만들었는데 서비스는 여전히 예전 리비전을 유지해요. 설계도를 고치는 일과 그 설계도를 쓰라고 지시하는 일이 별개이기 때문이에요. 고쳤는데 왜 안 바뀌느냐는 질문의 답은 대개 이것이에요.

기계를 누가 관리하나

AWS는 2014년 re:Invent에서 ECS를 미리 보였고 2015년 4월 정식으로 열었어요. 컨테이너가 개발자 도구에서 운영 수단으로 넘어가던 시기였고, 여러 대의 기계에 상자를 어떻게 나눠 놓을지가 새 문제로 떠오른 때였어요.

초기 방식은 제가 서버를 준비해 두고 그 위에 상자를 배치하는 것이었어요. 기계의 수와 크기를 제가 정하는 대신, 남는 용량과 부족한 용량도 제 몫이 돼요. 2017년에 더해진 방식은 그 기계를 보이지 않게 감췄어요. 무엇을 얼마나 돌릴지만 말하면 그 아래는 알아서 준비돼요.

선택 기준은 대체로 하나로 좁혀져요. 기계 자체에 특별한 것이 필요하면 앞쪽을 골라요. 특수한 계산 장치를 붙이거나, 디스크를 직접 관리하거나, 커널 수준의 설정이 필요한 경우예요. 그런 요구가 없다면 대개 뒤쪽이 편해요.

바꿔 끼우는 동안의 산수

여기가 이 글의 중심이에요. 새 리비전으로 옮길 때 ECS는 도는 태스크를 한꺼번에 갈아 치우지 않고 조금씩 바꿔요. 그 조금씩의 크기를 두 값이 정해요.

공식 문서의 설명은 이래요. 최소 유지 비율은 교체하는 동안 살아 있어야 하는 최소 개수를 원하는 개수에 대한 비율로 정하고, 이 값은 올림해요. 최소가 50이고 원하는 개수가 넷이면 둘을 멈춘 뒤 둘을 시작할 수 있어요. 최대 허용 비율은 교체 중 존재할 수 있는 최대 개수이고 이 값은 내림해요. 최대가 200이고 원하는 개수가 넷이면 넷을 먼저 띄운 뒤 기존 넷을 정리할 수 있어요.

문서가 예로 든 반대 경우가 더 중요해요. 최소가 75이고 원하는 개수가 둘이면 올림한 결과가 둘이라 아무것도 멈출 수 없어요. 최대가 125이고 원하는 개수가 셋이면 내림한 결과가 셋이라 아무것도 시작할 수 없어요. 두 값을 여유 없이 잡으면 배포가 실패하는 것이 아니라 아예 시작되지 못한 채 멈춰요. 문서는 이 상황에서 서비스 이벤트 메시지가 나간다고 함께 적어 두었어요.

두 값을 어떻게 잡나	교체 방식	잘못 잡으면
최소를 낮추고 최대를 그대로	먼저 내리고 나중에 올린다	교체하는 동안 처리 용량이 빈다
최소를 지키고 최대를 올린다	먼저 올리고 나중에 내린다	그만큼 여유 자원이 항상 필요하다
둘 다 여유 없이	아무것도 하지 못한다	배포가 시작되지 못하고 멈춘다

세 번째 줄이 배우기 가장 어려운 이유는 오류처럼 보이지 않기 때문이에요. 배포를 눌렀는데 조용히 아무 일도 일어나지 않아요.

최소 75%·최대 125%는 그대로 두고 희망 개수만 바꿔 보세요.

유지할 최소

2개

75%를 올림

동시에 둘 최대

2개

125%를 내림

기존 1기존 2

2개의 75%를 올리면 2개, 125%를 내리면 2개예요. 4개라면 최소 3개·최대 5개로 교체 여유가 생겨요.

2개를 유지해야 하는데 최대도 2개예요. 먼저 내리거나 더 띄울 자리가 없어요.

최소 3개, 최대 5개예요. 기존 4개 옆에 새 태스크 하나를 띄울 자리가 있어요.

ECS rolling 배포의 개수 조건만 계산해요. 실제 배포에는 자원 확보와 새 태스크의 정상 판정도 필요해요.

실패를 언제 인정할 것인가

새 태스크가 계속 뜨지 못한다면 언제 실패로 볼지도 정해야 해요. ECS는 배포 회로 차단기와 CloudWatch 알람을 이용한 실패 감지를 제공해요. 자동 되돌리기는 해당 옵션을 켜고, 돌아갈 수 있는 완료 상태의 배포가 있어야 해요. 실패 감지를 켰다는 것만으로 언제나 복구되는 것은 아니에요.

예전 태스크 정의가 남아 있어도 그 정의가 가리키는 이미지나 비밀 값이 사라지면 같은 상태를 다시 만들 수 없어요. 데이터 형식이 바뀌었다면 옛 코드가 새 데이터를 읽을 수 있는지도 봐야 하고요. 정의의 리비전은 되돌릴 출발점을 주지만, 되돌릴 수 있는 모든 조건을 보장하지는 않아요.

저는 무엇을 감수했나

제가 만드는 앱의 AI 응답을 만드는 서버가 이 위에서 돌아요. 계산 장치가 필요해 기계를 직접 준비하는 쪽을 골랐고, 그 장치를 붙인 기계가 한 대뿐이에요. 그러면 위 표의 두 번째 줄을 고를 수 없어요. 새 태스크를 먼저 띄울 자리가 물리적으로 없기 때문이에요.

그래서 첫 번째 줄을 골랐어요. 기존 태스크를 내리고 새 태스크를 올리며, 그사이 모델을 장비에 적재하는 동안 그 기능은 비어 있어요. 무중단 교체가 불가능한 구성이라는 사실을 설정으로 인정한 셈이에요. 대신 앞 글에서 이야기한 대체 경로가 그 빈 구간을 흡수해요. 설정 한 줄이 다른 층의 설계를 부른 자리였어요.

돌아보면 이 도구를 이해하는 데 걸린 시간의 대부분은 개념 이름이 아니라 이 산수였어요. 몇 개를 유지할지는 쉽게 정하지만, 바꿔 끼우는 동안 몇 개까지 겹치거나 비워도 되는지는 가진 자원이 대신 정해 줘요.