언어 선택

COLA: 클라우드 마이크로서비스를 위한 집합적 오토스케일링

COLA는 종단 간 지연 시간 목표를 충족하면서 비용을 최소화하기 위해 VM 할당을 전역적으로 최적화하는 마이크로서비스 애플리케이션용 새로운 오토스케일러 분석입니다.
apismarket.org | PDF Size: 1.6 MB
평점: 4.5/5
당신의 평점
이미 이 문서를 평가했습니다
PDF 문서 표지 - COLA: 클라우드 마이크로서비스를 위한 집합적 오토스케일링

1. 서론

클라우드 애플리케이션에서 모놀리식 아키텍처에서 느슨하게 결합된 마이크로서비스로의 전환은 리소스 관리에 상당한 복잡성을 초래합니다. 개발자는 각 마이크로서비스에 할당할 컴퓨팅 리소스(예: 컨테이너 복제본, VM)의 양을 결정해야 합니다. 이 결정은 개발자의 운영 비용과 애플리케이션 사용자가 경험하는 종단 간 지연 시간 모두에 결정적인 영향을 미칩니다. Horizontal Pod Autoscaling(HPA)과 같은 기존 오토스케일링 방법은 CPU 사용률과 같은 로컬 메트릭을 기반으로 각 마이크로서비스를 독립적으로 스케일링합니다. 그러나 이 접근법은 애플리케이션 워크플로 내 마이크로서비스의 상호 의존적 특성을 무시하기 때문에 최적이 아닙니다. COLA(Collective Autoscaler)는 전역적 목표, 즉 애플리케이션의 종단 간 지연 시간이 지정된 목표치 이하로 유지되도록 보장하면서 비용을 최소화하는 방식으로 모든 마이크로서비스에 걸쳐 리소스를 집합적으로 할당하는 솔루션으로 제안됩니다.

2. 독립적 오토스케일링의 문제점

현재 산업 표준 오토스케일링은 분산된, 마이크로서비스별 방식으로 작동합니다. 각 서비스는 자체 리소스 사용률(CPU, 메모리)이 임계값을 초과할 때 스케일링 작업(VM 또는 Pod 추가/제거)을 트리거합니다. 근본적인 결함은 이 로컬 관점이 애플리케이션의 전역적 성능을 고려하지 못한다는 점입니다. 체인 내 다른 서비스가 병목 현상으로 남아 있다면, 하나의 마이크로서비스 지연 시간을 개선해도 전체 사용자 인지 지연 시간에는 미미한 영향만 있을 수 있습니다. 이는 비효율적인 리소스 할당(일부 서비스는 과도하게 프로비저닝하고 중요한 병목 현상은 프로비저닝 부족)으로 이어져, 원하는 지연 시간 서비스 수준 목표(SLO)를 달성하지 못한 채 더 높은 비용을 초래합니다.

3. COLA: 집합적 오토스케일링 접근법

COLA는 오토스케일링 문제를 제약 최적화 문제로 재정의합니다. 여러 개의 독립적인 오토스케일러를 애플리케이션의 마이크로서비스 토폴로지와 성능에 대한 전역적 가시성을 가진 단일 중앙 집중식 컨트롤러로 대체합니다.

3.1. 핵심 최적화 프레임워크

목표는 다음과 같이 공식화됩니다:

  • 목적 함수: 총 컴퓨팅 비용 최소화.
  • 제약 조건: 애플리케이션 종단 간 평균 또는 꼬리 지연 시간 ≤ 목표 지연 시간.
  • 결정 변수: 각 마이크로서비스 $i$에 할당된 VM(또는 복제본)의 수, $n_i$로 표기.

$n_i$와 종단 간 지연 시간 간의 관계는 직관적이지 않으며 워크로드 패턴과 서비스 간 통신에 의존하기 때문에 이는 복잡한 비선형 최적화 문제입니다.

3.2. 오프라인 탐색 프로세스

프로비저닝 및 성능 안정화에 필요한 시간으로 인해 이 최적화를 온라인에서 해결하는 것은 비현실적입니다. 따라서 COLA는 오프라인 탐색 프로세스를 사용합니다:

  1. 워크로드 적용: 애플리케이션에 대표적인 워크로드를 적용합니다.
  2. 병목 현상 식별: 가장 혼잡한 마이크로서비스(부하 하에서 CPU 사용률 증가가 가장 큰 서비스)를 식별합니다.
  3. Bandit 문제를 통한 리소스 할당: 병목 현상 서비스에 대해, 다중 슬롯머신(Bandit) 문제 공식화를 사용하여 최적의 VM 수를 결정합니다. "보상" 함수는 지연 시간 개선과 비용 증가 사이의 균형을 맞춥니다.
  4. 반복: 전역 지연 시간 목표가 달성될 때까지 다음으로 가장 혼잡한 마이크로서비스에 대해 2-3단계를 반복합니다.
  5. 정책 생성: 결과는 온라인에 배포할 수 있는 스케일링 정책(워크로드 특성에서 리소스 할당으로의 매핑)입니다.

COLA는 알려진 워크로드 사이를 보간할 수 있으며, 보지 못한 워크로드 패턴에 직면하면 기본 오토스케일러로 폴백할 수 있습니다.

4. 기술적 세부사항 및 수학적 공식화

핵심 최적화 문제는 추상적으로 다음과 같이 표현될 수 있습니다:

$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{subject to: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ 여기서:

  • $M$: 마이크로서비스의 수.
  • $n_i$: 마이크로서비스 $i$에 대한 리소스 단위(예: VM)의 수.
  • $C_i(n_i)$: $n_i$ 단위를 가진 마이크로서비스 $i$의 비용 함수.
  • $L_{e2e}$: 종단 간 지연 시간 함수, 모든 $n_i$와 워크로드 강도 $\lambda$에 의존.
  • $L_{target}$: 원하는 지연 시간 SLO.
COLA 탐색의 3단계에서 "Bandit 문제"는 병목 현상 서비스에 대한 각각의 가능한 VM 할당을 "팔"로 취급하는 것을 포함합니다. 팔을 당기는 것은 해당 구성을 프로비저닝하고 결과적인 비용-지연 시간 절충을 측정하는 것에 해당합니다. Upper Confidence Bound (UCB)와 같은 알고리즘을 사용하여 구성 공간을 효율적으로 탐색하고 활용할 수 있습니다.

5. 실험 결과 및 평가

COLA는 Google Kubernetes Engine(GKE)에서 여러 기준 오토스케일러(사용률 기반 및 ML 기반)에 대해 엄격하게 평가되었습니다.

5.1. 실험 설정

  • 애플리케이션: 5개의 오픈소스 마이크로서비스 애플리케이션(예: Simple WebServer, BookInfo, Online Boutique).
  • 플랫폼: GKE Standard(사용자 관리 노드) 및 GKE Autopilot(공급자 관리 인프라).
  • 기준선: 표준 HPA(CPU 기반), 고급 ML 기반 오토스케일러.
  • 워크로드: 63개의 고유한 워크로드 패턴.
  • 목표: 지정된 중앙값 또는 꼬리(예: p95) 지연 시간 SLO 충족.

5.2. 주요 성능 지표

SLO 달성률

53/63

COLA가 지연 시간 목표를 달성한 워크로드 수.

평균 비용 절감률

19.3%

다음으로 저렴한 오토스케일러 대비.

가장 비용 효율적인 정책

48/53

성공한 53개 워크로드 중 48개에서 COLA가 가장 저렴했습니다.

소형 앱 최적성

~90%

철저한 탐색이 가능한 소형 애플리케이션의 경우, COLA는 약 90%의 경우에서 최적 구성을 찾았습니다.

5.3. 결과 요약

결과는 COLA의 상당한 이점을 보여줍니다. COLA는 다른 방법이 실패한 곳에서도 일관되게 원하는 지연 시간 SLO를 달성했으며, 훨씬 더 낮은 비용으로 이를 이루었습니다. 비용 절감 효과가 너무나 뚜렷해서 COLA의 오프라인 탐색을 실행하는 "훈련 비용"은 운영 시작 며칠 만에 회수되었습니다. GKE Autopilot에서는 COLA의 이점이 더욱 두드러졌는데, 이는 공급자 관리 추상화를 효과적으로 탐색하여 비용을 최소화했기 때문입니다.

차트 설명 (상상): 막대 차트는 Y축에 "성공한 요청당 비용" 또는 "총 클러스터 비용"을, X축에 다른 오토스케일러(COLA, HPA, ML-A)를 표시할 것입니다. COLA의 막대는 상당히 낮을 것입니다. 두 번째 차트는 "지연 시간 SLO 위반률"을 보여줄 수 있는데, COLA의 막대는 0에 가까운 반면 다른 방법들은 더 높은 위반률을 보일 것입니다.

6. 분석 프레임워크 및 예시 사례

분석가 관점: 4단계 해체

핵심 통찰: 이 논문의 근본적인 돌파구는 멋진 새로운 알고리즘이 아니라, 전체 마이크로서비스 애플리케이션을 독립적인 부품들의 모음이 아닌 최적화해야 할 단일 시스템으로 취급하는 관점의 결정적 전환입니다. 이는 CycleGAN(Zhu et al., 2017)과 같은 모델이 가져온 컴퓨터 비전의 전환과 유사합니다. CycleGAN은 전체 변환 도메인의 주기 일관성을 고려함으로써 짝을 이루는 이미지 변환을 넘어섰습니다. COLA는 리소스 관리에 유사한 "전역 일관성" 원칙을 적용합니다.

논리적 흐름: 논증은 설득력 있게 단순합니다: 1) 로컬 최적(서비스별 스케일링)은 전역적 비효율성으로 합산됩니다. 2) 따라서, 전역적 제약 조건(종단 간 지연 시간)을 가진 전역적 목표(비용)를 사용하십시오. 3) 이를 온라인에서 해결하는 것은 너무 느리므로, 탐색을 통해 오프라인에서 해결하고 정책을 배포하십시오. 우아함은 Bandit 문제를 사용하여 병목 현상의 최적 할당 탐색을 효율적으로 만드는 데 있으며, 이는 시스템 최적화를 위한 강화 학습에 대한 광범위한 연구(예: UC Berkeley의 RISELab 연구)로 뒷받침되는 기법입니다.

강점과 결점: 강점: 실증적 결과는 뛰어납니다 — 19.3%의 비용 절감은 이사회 수준의 수치입니다. 오프라인 접근법은 실용적이며 런타임 불안정성을 피합니다. 프레임워크는 플랫폼에 구애받지 않습니다. 결점: 아킬레스건은 대표적인 오프라인 워크로드에 대한 의존성입니다. 빠르게 진화하는 애플리케이션이나 "블랙 스완" 트래픽 사건 하에서, 사전 계산된 정책은 구식이 되거나 치명적일 수 있습니다. 논문의 기본 오토스케일러로의 폴백은 이 견고성 문제에 대한 임시방편일 뿐 근본적인 해결책이 아닙니다. 더욱이, 탐색 복잡도는 마이크로서비스 수에 따라 확장성이 좋지 않을 가능성이 높아, 극도로 크고 복잡한 애플리케이션에서의 사용을 제한할 수 있습니다.

실행 가능한 통찰: 클라우드 설계자들에게 메시지는 분명합니다: CPU 임계값을 고립적으로 설정하는 것을 멈추십시오. 전역적 성능 가시성과 중앙 집중식 의사 결정 엔진을 구축하거나 채택하는 데 투자하십시오. 하이브리드 접근법으로 시작하십시오: COLA의 철학을 사용하여 중요한 서비스 체인을 정의하고 거기에 집합적 스케일링을 적용하는 반면, 덜 중요하고 독립적인 서비스는 기존 HPA에 맡기십시오. 보여준 바와 같이 투자 수익률(ROI)은 빠를 수 있습니다. 클라우드 공급자들은 주목해야 합니다; GKE Autopilot과 같은 도구들은 진정으로 "관리형" 인프라의 약속을 지키기 위해 이러한 지능형 오케스트레이션 계층이 필요합니다.

7. 적용 전망 및 향후 방향

COLA의 원칙은 기본적인 VM 스케일링을 넘어 광범위한 적용 가능성을 가집니다:

  • 다중 리소스 및 이기종 스케일링: 향후 버전은 VM 크기(메모리 최적화 vs. 컴퓨팅 최적화), GPU 할당, 심지어 비용과 복원력을 위한 가용 영역 또는 클라우드 공급자 간 배치를 집합적으로 결정할 수 있습니다.
  • 서비스 메시와의 통합: COLA를 Istio와 같은 서비스 메시와 결합하면 더 풍부한 원격 측정(요청 수준 추적, 종속성 그래프)을 제공하고 최적화의 일부로 트래픽 라우팅 및 서킷 브레이커에 대한 직접 제어를 가능하게 할 수 있습니다.
  • 온라인 적응 및 메타러닝: 주요 연구 전선은 오프라인 제한을 극복하는 것입니다. 메타러닝의 기술은 COLA가 실시간 피드백을 기반으로 정책을 온라인에서 빠르게 적응시키거나, 저트래픽 기간 동안 새로운 구성을 안전하게 탐색할 수 있게 할 수 있습니다.
  • 그린 컴퓨팅 목표: 최적화 목표는 Cloud Carbon Footprint 프로젝트와 같은 소스의 데이터를 통합함으로써 탄소 발자국이나 에너지 소비를 최소화하도록 확장되어 지속 가능한 컴퓨팅 이니셔티브와 조화를 이룰 수 있습니다.
  • 정책 마켓플레이스: 일반적인 애플리케이션 패턴(예: 전자상거래, 미디어 스트리밍)에 대해 사전 최적화된 COLA 정책을 공유하거나 판매하여 개별적인 훈련 실행 필요성을 줄일 수 있습니다.

8. 참고문헌

  1. Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
  2. Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
  3. Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
  4. Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (온라인 적응과 관련된 고급 RL 예시).
  5. Cloud Carbon Footprint. (n.d.). An open source tool to measure and visualize the carbon footprint of cloud usage. Retrieved from https://www.cloudcarbonfootprint.org/.
  6. Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).