이미지 변환을 별도 서비스로 떼는 설계를 잡으면서 Auto Scaling 그룹에 몇 대를 띄울지부터 정하고 싶어졌다. 그 전에 실제 부하가 어떤 모양인지를 재기로 했다.
Table of contents
Open Table of contents
배경 — 몇 대를 띄울지 정하기 전에
대수는 결과이지 출발점이 아니다. 부하의 모양을 모르면 그 숫자를 정할 근거가 없다.
근거 없이 정한 숫자는 나중에 아무도 못 바꾸는데 왜 그 값인지를 아무도 모르기 때문이다. 그래서 nginx 의 access.log 를 먼저 봤다.
검증 — 시간대로 접은 로그
보름치 로그를 awk 로 시간대별 요청 수로 접었고 /convert 와 /copy 는 경로가 다르므로 나눠서 셌다. 결과가 세 덩어리로 갈렸다.
새벽에 배치성 스파이크가 있고 이른 아침 몇 시간은 거의 0에 가까웠으며 낮과 오후에 완만한 산이 있었다. 이 모양이면 한 가지 정책으로는 안 맞는다는 것이 바로 보였다.
조치 — 예약과 추적의 병행
CPUUtilization 대상 추적만 두면 새벽 스파이크의 앞부분을 놓치는데 반응이 뒤늦게 오기 때문이다. 반대로 조용한 새벽 시간에는 최소 대수가 계속 떠 있게 된다.
두 가지 방법이 있었는데 대상 추적 하나로 가는 것과 배치 직전에 MinSize 를 올려 두는 예약 작업과 그 외 시간의 대상 추적을 병행하는 것이다. 뒤쪽을 골랐다. 이유는 시각을 아는 부하를 반응형에 맡기면 매일 같은 지연을 겪어서다. 대신 배치 시각이 바뀌면 예약 작업도 같이 고쳐야 하는 것을 감수했다. 시각을 아는 부하는 예약으로 잡고 모르는 부하는 추적으로 잡는 것이 이 구분의 기준이었다.
주의 — 지정할 수 있는 것과 없는 것
가용 영역마다 몇 대씩이라는 형태로 지정하고 싶었는데 그렇게 지정하는 방법이 없었다. 지정할 수 있는 것은 DesiredCapacity 전체 개수이고 AWS 공식 문서대로 Auto Scaling 이 각 영역의 인스턴스 수를 같게 유지하려고 가장 적은 영역에 새로 띄우는 식으로 분포가 정해진다.
고르게 놓는 것이지 영역당 정확한 개수를 보장하는 것이 아니므로 홀수면 한쪽이 하나 많다. 영역당 최소 대수가 요구사항이면 전체 개수를 그만큼 올려 잡아야 했다.
원인 — 아키텍처 단가와 바이너리 가용성
Graviton 의 arm64 인스턴스가 이십 퍼센트쯤 싸서 그쪽을 검토했다. sharp 가 libvips 네이티브 바인딩을 쓰므로 아키텍처마다 빌드가 필요한지가 관건이었다.
확인해 보니 linux-arm64 사전 빌드 바이너리를 제공하고 있어서 별도 빌드 없이 npm install 로 설치됐다. 단가만 보고 정하면 빌드 시간과 실패 위험이 그 차이를 갉아먹으므로 가용성을 함께 봐야 했다.
정리
- 대수는 결과이지 출발점이 아니다
- 근거 없이 정한 숫자는 나중에 아무도 못 바꾼다
- 스케일링 정책은 실제 접근 로그의 시간대별 처리량에서 시작한다
- 부하 모양이 여럿이면 한 가지 정책으로 안 맞는다
- 시각을 아는 부하는 예약으로 모르는 부하는 추적으로 잡는다
- 예약은 스파이크 앞에 걸어야 반응 지연을 피한다
- 가용 영역당 개수는 직접 지정할 수 없고 전체 개수와 전략으로 정해진다
- 아키텍처 전환은 단가와 사전 빌드 바이너리 가용성을 함께 본다