TL;DR

  • Kubernetes 자동 확장(autoscaling)의 신뢰성을 사용자 요청 이후 경험이 정상화될 때까지의 평균 시간(Mean Time to Stop Sucking, MTSS)으로 측정해야 함.
  • 일반적인 대기 파드에서 스케줄된 파드까지의 시간은 클라우드 사업자의 프로비저닝 지연만 주로 포착해 사용자 경험 악화 시간을 설명하기에 부족함.
  • MTSS를 분석하려면 사용자 요청, HPA, cAdvisor 메트릭, 클러스터 자동 확장기 반응, 애플리케이션 시작 성능을 연결하는 분산 추적이 필요함.
  • 확장 시간을 줄이는 방법으로 빠른 노드·수평 자동 확장기, 노드 프로비저닝 최적화, 더 나은 확장 메트릭, 의존 서비스 동시 확장, 애플리케이션 시작 최적화가 제시됨.
  • 예측형 자동 확장은 구현이 매우 어렵고 모든 문제를 해결하지 못할 수 있으므로 첫 번째 선택지로 삼기보다 다른 개선책을 우선 검토해야 함.

비용과 신뢰성의 균형

  • 자동 확장에 관심을 갖는 이유는 비용 절감과 용량 계획임. 인프라를 모두 끄면 비용은 낮아지지만 서비스가 중단되고, 모든 파드에 c7i.48xlarge를 할당하면 견고성과 신뢰성은 높아져도 비용이 과도해짐.
  • 지난 글에서는 비용 측면을 다뤘으며, 이번 글과 다음 글에서는 신뢰성 측면을 다룸. 신뢰성은 확장(scale up)과 축소(scale down)로 나뉘며, 각각 다른 항목을 측정해야 함.
  • 확장에서는 새 용량 프로비저닝 지연으로 사용자 경험이 얼마나 오래 저하되는지 알아야 함. 축소에서는 자동 확장기가 작업 중인 사용자를 중단시켜 경험을 저하하는지 확인해야 함.
  • 이번 글은 신뢰성 지표 중 확장에 초점을 맞추며, 다음 지표로 축소를 다룰 예정임.

사용자가 고양이 사진을 보기까지 필요한 단계

  • 트래픽이 급증하면 수평 파드 자동 확장기(HPA)가 과부하 파드를 감지해 파드를 늘리지만, 클러스터에 여유 노드가 없으면 새 파드는 대기 상태가 됨.
  • Karpenter 같은 클러스터 자동 확장기가 대기 파드를 보고 노드를 요청해도, 클라우드 사업자의 하드웨어 제공 지연이 발생할 수 있음. 특히 GPU 인스턴스는 공급 부족으로 확보에 10분이 걸릴 수도 있음.
  • 노드가 준비된 뒤에도 보안 업데이트와 초기화가 필요할 수 있으며, 파드가 실행된 뒤에는 애플리케이션이 데이터베이스를 메모리에 적재하고 JIT 컴파일을 수행하는 데 시간이 걸릴 수 있음.
  • 따라서 노드가 제공되는 시간만 측정하면 파드 시작부터 애플리케이션이 실제로 사용자 요청을 처리할 때까지 이어지는 지연을 놓침.

Mean Time to Stop Sucking 측정

  • 대부분의 조직에서 사용하는 지표는 대기 파드에서 스케줄된 파드까지 걸린 시간임. 이 지표도 추적하기 쉽지 않지만, Karpenter에는 파드 생성부터 바인딩까지의 시간을 추적하는 알파 시계열 지표 karpenter_pods_unbound_time_seconds가 있음.
  • 이 지표는 자동 확장 성능 전반보다 클라우드 사업자의 프로비저닝 지연을 주로 나타냄. 사용자에게 중요한 것은 요청을 보낸 뒤 경험이 정상화되기까지 걸리는 시간임.
  • MTSS는 사용자가 요청한 시점부터 사용자 경험이 더 이상 심각하게 저하되지 않을 때까지의 시간으로 정의됨.
  • 단일 MTSS 값만 측정하면 문제가 있다는 사실은 알 수 있지만 원인은 파악하기 어려움. 지연 원인을 이해하려면 여러 출처의 이벤트를 연결해야 함.
  • 필요한 데이터에는 사용자 요청 시점, 서비스 메시 등을 통한 요청 추적, cAdvisor 집계 메트릭을 바탕으로 한 HPA 반응, 클러스터 자동 확장기 반응, 애플리케이션 시작 성능이 포함됨.
  • 이 데이터를 연결하려면 분산 추적 인프라가 필요하며, 이를 구축하는 방법은 각 환경에 따라 달라짐. 여러 지표를 연결하면 자동 확장 과정의 지연을 세부적으로 분석할 수 있음.
  • MTSS는 프런트엔드의 최초 콘텐츠 표시 시간(first contentful paint)과 관련이 있지만, 화면을 그리지 않는 서비스에는 적합하지 않을 수 있음. 최초 바이트 응답 시간(Mean Time to First Byte)도 관련 지표지만, Kubernetes 애플리케이션이 항상 바이트를 반환하는 것은 아니므로 완전히 알맞지는 않음.
  • 지표를 폭넓게 수집하면 관측 가능성 비용이 늘어나며, 관측 가능성 팀이 비용 문제를 제기할 수 있음.

확장 시간을 줄이는 일곱 가지 방법

  • 더 빠른 노드 자동 확장기 사용: Kubernetes Cluster Autoscaler와 Karpenter 사이에는 확장 속도 차이가 뚜렷함. Karpenter로 전환하는 것만으로도 클러스터 확장 속도가 눈에 띄게 개선될 수 있음. AWS뿐 아니라 Azure Karpenter Provider와 GCP Karpenter Provider도 있음.
  • 노드 프로비저닝 시간 최적화: 노드가 사용 가능해지기까지 5분 이상 걸리는 환경이 많음. 운영체제 보안 업데이트, 환경별 설정, 리전별 설정 등이 노드 합류를 늦출 수 있음. 가능한 한 많은 아키텍처 구성을 AMI에 미리 반영하는 방법이 일부 조직에서 효과적임.
  • 더 빠른 수평 자동 확장기 사용: KEDA는 기본 HPA보다 더 빠르게 메트릭 평가 루프를 구성할 수 있음. 메트릭을 더 자주 평가하면 값의 변화에 더 빠르게 반응할 수 있음.
  • 더 나은 수평 확장 메트릭 사용: 플랫폼 엔지니어들은 파드 CPU 사용률을 기준으로 확장하지 말라고 말하면서도 실제로는 CPU 사용률에 의존하는 경우가 많음. 초당 요청 수, 큐 깊이 등 CPU 사용률이 아닌 지표를 쓰면 부하 증가 신호를 더 일찍 포착할 수 있음. 임의의 비CPU 메트릭을 활용하는 경우에도 KEDA가 적합함.
  • 의존 서비스 체인 전체를 동시에 확장: 서비스 A에서 D로 이어지는 구조에서는 A의 요청 증가에 따라 A, B, C, D가 차례로 확장될 수 있으며, 마지막 서비스가 확장될 때까지 사용자는 오류를 볼 수 있음. A에서 부하 증가가 감지되면 의존 체인 전체를 함께 확장하는 편이 나음. 어려운 점은 의존 체인을 식별하는 일이며, 몇 년 전 발표된 논문에서 이를 위한 통찰을 제시함.
  • 애플리케이션 시작 시간 단축: 애플리케이션 코드뿐 아니라 파드의 초기화 컨테이너 수와 준비 상태 검사를 통과하기 전에 정상 상태여야 하는 사이드카 수를 검토할 수 있음. 이 구성 요소를 줄이면 시작 지연을 낮출 수 있음.
  • 예측형 자동 확장기 사용: 부하를 예측하면 애플리케이션 개선을 대신할 수 있다는 기대가 있지만, 예측형 자동 확장은 제대로 구현하기 매우 어렵고 성공하더라도 모든 문제를 해결하지는 못함. 항상 나쁜 선택이거나 효과가 없다는 뜻은 아니지만, 첫 번째로 선택할 방법은 아님. 도입을 결정한다면 직접 구현하기보다 성능이 검증된 공급업체를 이용하는 방안이 권장됨.

다음 글 예고

  • 위 일곱 가지는 애플리케이션의 확장 지연을 줄이는 방법임. 다음 글에서는 더 이상 필요한 용량이 없을 때 확장 규모를 줄이는 전략을 다룰 예정임.