이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 Kubernetes HPA를 이용해 API 서버 오토스케일링을 구현한 경험이 있습니다. CPU 80% 이상이면 파드를 늘리도록 설정했는데, 트래픽 급등 시 한 번에 파드가 10개 이상 붙는 문제가 발생했습니다.
알고 보니 scale-up 안정화 윈도우를 너무 짧게 설정하여, 잠깐 스파이크가 발생해도 바로 스케일 아웃이 이루어졌습니다. 비용이 두 배 가까이 늘었고, 팀장님이 알림을 받고 가장 먼저 이 문제를 지적하셨습니다.
이후 안정화 윈도우를 3분으로 늘리고, 스케일 인 조건도 별도로 보수적으로 설정하니 불필요한 스케일링이 많이 줄어들었습니다. 단순히 임계값만 설정하는 것이 아니라 스케일 인/아웃 비대칭 정책을 함께 설계해야 한다는 것을 이때 배웠습니다.
학교 프로젝트에서 이미지 처리 파이프라인을 만들 때, RabbitMQ 큐 깊이를 기준으로 워커 컨테이너 수를 자동 조절하는 구조를 구현했어요.
처음엔 큐 길이가 100 이상이면 어떤 상황에서도 워커를 2배로 늘리도록 단순하게 짰는데, 워커가 올라오는 데 20~30초가 걸려서 이미 큐가 줄어들고 있는 상황에서도 워커가 계속 올라왔습니다.
결국 큐 길이 증가율도 같이 보는 방식으로 바꿨어요. 절댓값보다 변화율을 보는 게 훨씬 반응이 좋았습니다. 처리량이 30% 개선됐고, 워커 과잉 배포도 많이 줄었어요. 다만 큐 모니터링 폴링 주기를 너무 짧게 잡으면 브로커에 부하가 가는 부분은 여전히 개선이 필요하다고 느꼈습니다.
직접 오토스케일링 시스템을 개발한 경험은 없지만, 관련 자료를 읽으며 접근 방식에 대해 생각해본 적이 있어요.
리소스 사용 패턴을 분석하려면 단순 스냅숏보다 시계열 집계가 중요하다고 생각해요. 예를 들어 CPU 평균보다 p90 지연 시간이나 큐 대기 시간이 스케일링 트리거로 더 정확할 것 같습니다. 평균은 아웃라이어에 눌려서 실제 병목을 가릴 수 있거든요.
또 스케일 아웃보다 스케일 인이 훨씬 조심스러워야 한다고 배웠어요. 너무 빨리 줄이면 다음 트래픽 증가 때 레이턴시가 튀거든요. 이런 비대칭 정책을 직접 튜닝해보고 싶어서 개인 프로젝트에서 작은 규모로 시험해볼 계획입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.