수백만 대 서버에 VM 을 배치하는 서비스 (Protean, OSDI 2020)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• Protean 은 Azure 의 VM 할당 서비스로, 인스턴스 하나가 서버 1만~10만 대 규모의 가용성 영역 하나를 맡습니다.
• 배치 정책을 약 100개의 규칙(검증 규칙과 선호 규칙)으로 표현하고, 규칙 사이 우선순위를 엄격하게 매겨 정책과 메커니즘을 분리했습니다.
• 비슷한 요청이 반복된다는 점을 이용해 규칙 평가 결과를 여러 단계로 캐시하고, 여러 할당 에이전트가 낙관적 동시성으로 병렬 처리합니다.
• 운영 환경에서 VM 당 평균 약 20ms, 최대 초당 2,000건의 요청을 처리했고, 주요 사용률 지표인 패킹 밀도 85~90% 를 냈습니다.

왜 나왔나

VM 을 어느 서버에 둘지는 클라우드의 비용을 직접 좌우합니다. 서버의 남는 자투리 용량(단편화)이 늘면 같은 수요에 더 많은 서버가 필요하고, 배치를 잘못하면 성능 문제나 할당 실패가 생깁니다. 논문은 Azure 규모에서 단편화를 1% 줄이는 것이 연간 약 1억 달러의 가치라고 적습니다.

2장은 문제의 어려움을 데이터로 보여 줍니다. 지역은 최대 3개의 가용성 영역으로, 영역은 데이터 센터와 약 1,000대 규모의 클러스터와 랙으로 이루어지고, 큰 영역은 10만 대 이상입니다. 서버 세대도 여러 가지가 섞여 있습니다(표 1, 예: 서버당 10코어인 Gen 3 부터 48코어인 Gen 6 까지). VM 유형은 500가지가 넘고, 표 2와 표 3처럼 영역마다 유형과 코어 수 분포가 다릅니다. 요청은 하루 주기와 급격한 정점을 보여 초당 2,000건을 넘기도 하며(그림 3, 그림 4), 요청의 94% 는 VM 1개, 99% 는 5개 이하입니다.

한편 기회도 있습니다. 그림 2에 따르면 요청의 80% 이상은 바로 직전 요청과 같은 종류입니다. 같은 계산을 반복할 가능성이 크다는 뜻입니다. 요구 사항은 지연(VM 당 보통 20ms 이내), 처리량(정점에서도 조절 없이), 수락률(가능한 배치가 있으면 거절하지 않기), 그리고 장애 도메인 분산이나 GPU 같은 하드웨어 제약 준수입니다.

핵심 아이디어

규칙 기반 할당 에이전트

3장의 할당 에이전트(AA)는 배치를 두 단계로 나눕니다. 먼저 클러스터 선택에서 검증 규칙으로 클러스터를 거르고 선호 규칙으로 정렬해 상위 8~16개를 고릅니다. 다음 머신 선택에서 같은 방식으로 서버를 거르고 정렬한 뒤, 동점이면 무작위로 하나를 고릅니다.

검증 규칙은 "자원이 충분한가", "이 VM 유형을 지원하는가" 같은 참 거짓 판정이고, 선호 규칙은 점수를 매깁니다. 예를 들어 BestFit 은 가장 꽉 맞는 서버를 선호해 패킹을 높이고, PreferNonEmptyMachines 는 이미 VM 이 있는 서버를 선호해 빈 서버를 아끼며, PreferEmptierClusters 는 클러스터 사이 용량을 고르게 합니다.

여러 선호 규칙을 합치는 방식이 핵심입니다(3.3절). 규칙 가중치를 지수적으로 키워, 앞 규칙이 동점으로 남긴 후보 사이에서만 뒤 규칙이 효력을 갖게 합니다. 엄격한 우선순위입니다. 그런데 BestFit 같은 연속 점수를 그대로 쓰면 첫 규칙이 거의 모든 동점을 깨 버려 뒤 규칙이 무의미해지므로, 점수를 몇 개 구간으로 양자화합니다. 이 구조 덕분에 규칙 순서나 구간 수 변경이 설정 변경으로 끝나고, 어떤 서버가 왜 탈락했는지 추적할 수 있습니다.

여러 에이전트와 낙관적 동시성

4장의 구조에서는 여러 AA 가 동시에 돕니다. 요청은 부하 분산기를 거쳐 공유 작업 큐에 들어가고, 각 AA 는 자기 캐시에 있는 인벤토리 상태로 배치를 계산한 뒤 복제된 권한 저장소에 커밋합니다. 저장소는 충돌을 검사하고 커밋을 직렬화하며, 변경 사항을 게시 구독(pub/sub) 서비스로 모든 AA 에 알립니다. 충돌하면 요청을 다시 큐에 넣습니다. 재시도는 10번 넘게 허용되지만 할당의 99.9% 는 세 번 안에 성공합니다.

캐시로 빠르게 고르기

5장은 성능의 핵심인 캐시입니다. 클러스터 선택 후에도 후보 서버가 1만~1.5만 대이므로, 매번 모든 규칙으로 정렬하면 너무 느립니다. 그래서 같은 요구 특성(trait)을 가진 요청에 대해 규칙 객체의 상태를 캐시하고(5.2.1절), 규칙 평가 결과인 정렬된 서버 목록도 캐시합니다(5.2.2절). 다음 요청 때는 그사이 바뀐 서버(보통 수십 대)만 반영하면 되므로 갱신 비용이 전체 정렬보다 훨씬 작습니다. 변경은 번호가 붙은 저널로 기록되어 각 객체가 자기가 마지막으로 본 이후의 기록만 적용하고, 한가할 때는 백그라운드로 캐시를 미리 갱신합니다. 랙 단위 셀로 묶어 정렬 비용도 줄였습니다.

충돌 줄이기도 다룹니다(5.3절). 겹치지 않는 배치는 서로 합쳐 커밋해 한 바쁜 영역에서 충돌을 25% 줄였고, 최근 충돌 비율이 높아지면 최상위 몇 대 중에서 무작위로 골라 에이전트들이 같은 서버를 노리지 않게 합니다.

실험과 결과

6장은 운영 측정과 실제 코드를 쓰는 시뮬레이터로 평가합니다.

• 지연(그림 10): 전체 평균은 약 20ms, 캐시 미스는 보통 70~80ms 였습니다. 약 3만 대 영역에서 캐시 적중 시 할당 한 번에 갱신하는 서버는 약 50대, 미스 시 약 2,000대였습니다. 캐시와 클러스터 선택이 없는 기준선은 큰 영역에서 중앙값이 약 1,000ms 에 이르렀습니다(그림 11).
• 메모리(그림 12): AA 하나가 서버 1만 대당 약 1GiB 를 쓰며, 서버 수에 대해 선형보다 느리게 늘어납니다.
• 확장(그림 13~15): 시뮬레이션에서 AA 5개는 1개보다 급증 부하를 3배 넘게 빨리 처리했고, 시간을 최대 1000배 빠르게 돌린 시험에서 초당 1만 건 넘는 처리량을 낸 뒤 충돌과 거절이 늘며 평탄해졌습니다.
• 배치 품질(표 5): BestFit 점수의 구간 수를 늘리면 패킹 밀도가 1구간 83.5%, 3구간 86.3%, 5구간 87.8%, 무제한 89.1% 로 오르지만, 남는 후보가 줄고 충돌이 늘어납니다. 운영에서는 3구간을 씁니다.
• COVID-19 수요 급증(그림 16): 2020년 봄 수요가 몰렸을 때 클러스터 사용률 한도를 1% 올리고 패킹 기반 마이그레이션 권고를 적용해, 사용률과 패킹 밀도를 높이고 4월 중순까지 용량 충족률을 목표 이상으로 되돌렸습니다(절댓값은 공개하지 않음).

지금 Azure 에서는

논문 발표 시점 기준으로 Protean 은 Azure 에서 VM 을 만들 때 실제로 서버를 고르는 내부 서비스이며, 고객이 직접 설정하는 제품 기능은 아닙니다. 논문은 장애 도메인 분산, 함께 두기(co-location), 떨어뜨려 두기(anti-affinity), 격리 같은 배치 조건과 GPU 같은 하드웨어 요구가 모두 검증 규칙과 선호 규칙으로 표현된다고 설명합니다. 고객이 VM 을 만들 때 고르는 가용성 영역이 곧 Protean 인스턴스 하나가 맡는 범위입니다. 저자들은 2장의 분석에 쓴 VM 패킹 트레이스를 연구용으로 공개했다고 밝힙니다.

함께 읽기

• Virtual Machines 와 VM Scale Sets: 이 사이트의 기능 문서
• Resource Central: VM 행동 예측으로 배치를 돕는 앞선 논문
• Azure Public Dataset (GitHub)
• Microsoft Research 논문 페이지