스케일링 기준은 액세스 로그에 있다

이미지 변환을 별도 서비스로 떼는 설계를 잡으면서 몇 대를 띄울지부터 정하고 싶어졌다. 그 전에 실제 부하가 어떤 모양인지를 재기로 했다.

Open Table of contents

몇 대를 띄울지 정하기 전에

대수는 결과이지 출발점이 아니다. 부하의 모양을 모르면 그 숫자를 정할 근거가 없다.

근거 없이 정한 숫자는 나중에 아무도 못 바꾸는데 왜 그 값인지를 아무도 모르기 때문이다. 그래서 앞단 웹서버의 접근 로그를 먼저 봤다.

보름치 로그를 시간대별 요청 수로 접었고 변환 요청과 단순 복사 요청은 경로가 다르므로 나눠서 셌다. 결과가 세 덩어리로 갈렸다.

새벽에 배치성 스파이크가 있고 이른 아침 몇 시간은 거의 0에 가까웠으며 낮과 오후에 완만한 산이 있었다. 이 모양이면 한 가지 정책으로는 안 맞는다는 것이 바로 보였다.

사용량 기준 자동 확장만 두면 새벽 스파이크의 앞부분을 놓치는데 반응이 뒤늦게 오기 때문이다. 반대로 조용한 새벽 시간에는 최소 대수가 계속 떠 있게 된다.

그래서 배치 직전에 최소 대수를 올려 두는 예약과 그 외 시간의 사용량 추적을 병행했다. 시각을 아는 부하는 예약으로 잡고 모르는 부하는 추적으로 잡는 것이 이 구분의 기준이었다.

가용 영역마다 몇 대씩이라는 형태로 지정하고 싶었는데 그렇게 지정하는 방법이 없었다. 지정할 수 있는 것은 전체 개수이고 분포는 분산 전략으로 정해진다.

고르게 놓는 것이지 영역당 정확한 개수를 보장하는 것이 아니므로 홀수면 한쪽이 하나 많다. 영역당 최소 대수가 요구사항이면 전체 개수를 그만큼 올려 잡아야 했다.

다른 아키텍처의 인스턴스가 이십 퍼센트쯤 싸서 그쪽을 검토했다. 이미지 처리 라이브러리가 네이티브 바인딩을 쓰므로 아키텍처마다 빌드가 필요한지가 관건이었다.

확인해 보니 해당 아키텍처용 사전 빌드 바이너리를 제공하고 있어서 별도 빌드 없이 설치됐다. 단가만 보고 정하면 빌드 시간과 실패 위험이 그 차이를 갉아먹으므로 가용성을 함께 봐야 했다.