채널 목록 channels.json 이 S3 와 코드 두 곳에 있고 둘이 어긋나면 문제가 되는 구조여서 어긋남을 검사하는 check:channels 커맨드를 만들었다. 리뷰에서 S3 의 값이 지금 돌고 있는 값이 맞느냐는 지적을 받았다.
Table of contents
Open Table of contents
원인 — 빌드 시점의 사본
Dockerfile 을 직접 열어 보니 빌드 단계에서 aws s3 cp 로 그 파일을 한 번 복사해 이미지에 넣고 있었다. 실행 중인 컨테이너는 그 빌드 시점의 사본을 쓴다는 뜻이다.
S3 의 값은 다음 배포가 쓸 값이고 실행 중인 값은 마지막 docker build 시점의 값이다. S3 를 갱신해도 재배포 전까지는 아무것도 안 바뀐다.
배경 — 미래를 검사하던 검사기
내 검사기는 S3 값과 코드의 ChannelEnum 목록을 비교하고 있었으므로 다음 배포 후의 상태를 검사하는 셈이었다. 지금 상태가 아니었다.
이것을 알고 나니 배포 순서가 정해졌다. S3 설정을 갱신하고 그 값을 쓰는 서비스를 재배포해 ECS 태스크 교체 완료를 확인한 뒤 그다음 서비스를 배포해야 하며 가운데 두 단계를 건너뛰면 새 목록을 쓰는 쪽과 옛 목록으로 도는 쪽이 어긋난 채로 돈다.
조치 — 전제를 주석에 박기
고치는 길은 두 가지가 있었다. 검사기가 실행 중 컨테이너 안의 사본을 docker exec 로 읽게 하는 것과 전제를 명시하고 배포 순서로 막는 것이다. 뒤쪽을 골랐다. 이유는 앞쪽은 검사기가 운영 환경 접근 권한을 가져야 해서다. 대신 검사기가 지금 상태는 끝내 못 본다는 한계를 감수했다. 검사기의 문서 주석에 그 전제를 적었다. 이 검사가 무엇과 무엇을 비교하는지와 실행 중인 값은 마지막 빌드 시점의 사본이라는 것과 배포 순서를 함께 남겼다.
안 적으면 다음 사람이 검사를 통과했으니 지금 상태도 맞겠거니 하고 읽는다. 검사기가 무엇을 검사하는지를 그 자리에 명시해야 오해가 안 생긴다.
주의 — 부분집합만 닫은 검사
더 큰 지적도 있었는데 설정이 채널 단위 목록이라 queue_name 같은 하위 식별자가 없다는 점이었다. 채널이 양쪽에 있으면 검사가 통과하지만 그 하위 큐 중 하나가 폐기됐거나 오타여도 잡히지 않는다.
그래서 이 검사가 폭주 실패 모드 전체가 아니라 상위 단위 부분집합만 닫는다고 적었다. 무엇을 못 잡는지를 적지 않으면 검사가 있으니 안전하다고 생각하게 된다.
검증 — 보장 안 하는 것을 적기
가장 근본적인 지적은 검사기가 설정만 비교하고 실제 발생을 안 본다는 것이었다. S3 만 넓히고 코드를 배포하면 둘이 맞으니 검사는 통과하는데 실행 중인 값은 여전히 옛것이라 문제가 그대로 남는다.
검사기가 막으려던 바로 그 시나리오가 검사를 통과한다. 그래서 보장하는 것보다 보장 안 하는 것을 적는 쪽이 중요한데 검사가 있다는 사실 자체가 안심을 만들기 때문이다. 이 지적을 받고 추측으로 답하지 않고 Dockerfile 의 그 줄을 직접 열어 확인했다.
정리
- 빌드 시점에 복사하는 설정은 저장소 값이 다음 배포용이다
- 갱신해도 재배포 전까지 안 바뀐다
- 그래서 배포 순서가 정해지고 그 전제를 문서에 박는다
- 검사기가 미래 상태를 검사하고 있을 수 있다
- 설정 입도가 낮으면 하위 수준 공백이 남는다
- 검사기가 무엇을 못 잡는지를 적는다
- 검사가 있다는 사실이 안심을 만든다
- 지적을 받으면 추측이 아니라 해당 파일을 직접 열어 확인한다