0. Summary

  • 기본 정보 : ArXiv,2026.10.26, HiLO: Towards Product-Level Graceful Degradation with a Quality-Aware, Load-Aware Control Framework
  • 연구 배경 : 대규모 온라인 서비스는 과부하 상황에서 가용성을 지키기 위해 우아한 성능 저하(graceful degradation)를 쓴다. GPU 집약적인 LLM 추론이 늘면서 용량 부족은 프로비저닝만으로 해결할 수 없는 상시적 제약이 되었다. 기존 방식은 부하 차단(load shedding)·회로 차단기(circuit breaker) 같은 서비스 수준 보호나, 일부는 수동으로 조작하는 기능 스위치에 의존한다. 이들은 개별 서비스는 지키지만 서로 독립적으로 결정을 내리기 때문에, 제품 전체가 어떤 상태인지 테스트할 수 없고 품질이 예측 불가능해진다. Bing에서는 공유 모델 서빙 서비스 하나의 지역 정책이 상위 호출자와 조율되지 않아 OneDCG(관련성 지표)가 1.11점 떨어지고 안정성이 90%에서 63%로 추락해 4시간 넘게 회복되지 않은 사고가 있었다.
  • 제안 방법 : HiLO(High Load Optimizer)는 각 서비스가 보고하는 정규화된 부하 계수(load-factor)를 집계해, 설계 시점에 미리 검증해 둔 소수의 제품 상태(product state) 격자 중 하나를 선택하고, 그 상태가 결정론적으로 정하는 서비스 수준(service level)을 모든 참여 서비스에 배포하는 제품 수준 제어 프레임워크다. 의존성은 런타임에 탐색하지 않고 설계 시점의 3단계 구축 과정에서 해소한다. 요청 경로 밖에서 동작하며, 부하 증가 시 단조적으로 심한 상태로 이동하고 회복은 감쇠 계수로 조절한다. 같은 추상화가 CPU 서비스, GPU 딥 모델, LLM 파이프라인에 그대로 적용된다.
  • 발견 사실 : 2025년부터 Bing 전 데이터센터에 배포되어 주당 평균 두 번의 트래픽 급증을 처리한다. 2026년 1월 한 달간 9건의 사용자 트래픽 과부하(1.02배~2.38배 기준 피크)와 16건의 용량 테스트를 자율 관리했고, 최악의 OneDCG 하락은 2.38배 부하에서 0.425점으로 운영 목표 0.5점 안에 머물렀다. 약 2배 부하 용량 테스트에서 HiLO 없이는 OneDCG가 0.02~0.05점 떨어졌지만 HiLO를 쓰면 0이었다. 랭킹 모델은 L5에서 추론 호출을 약 29% 줄이고 레이어 축소로 지연을 약 12% 줄이면서 OneDCG 영향은 중간(0.1~0.25점) 수준이었다. 의사결정 주기 2분, 내부 지연 P95 1ms 미만, 지역당 CPU 64코어로 운영된다.
  • 핵심 기여 :
    1. 제품 상태 격자(product state lattice) : 부분 순서를 가진 소수의 사전 검증된 제품 상태로 온라인 동작 공간을 제한해, 과부하 시 품질을 창발적 결과가 아니라 측정·테스트·예측 가능한 통제 결과로 만들었다.
    2. 이기종 서비스에 공통인 부하 계수 추상화 : 서비스마다 병목이 다르다는 전제 아래 단조성만 가정하는 정규화 스칼라로 부하를 보고하게 하여, CPU 서비스·GPU 모델·LLM 서빙 계층을 하나의 제어 루프에 넣었다.
    3. 6년간의 운영 경험과 실측 평가 : 실제 과부하 응답, 한 달 운영 스냅샷, HiLO 유무 용량 테스트 비교, 30시간 데이터센터 유지보수, 딥 모델·서비스·Copilot Search 사례 연구, A/B 실험 기반 사용자 영향, 그리고 설계 시점 부담과 품질-안정성 긴장 같은 교훈을 공개했다.

관련 개념

우아한 성능 저하(Graceful Degradation)와 과부하 문제

이 논문은 기계론적 해석가능성 논문이 아니라 대규모 서비스의 과부하 제어 시스템 논문입니다. 다만 LLM 추론이 서비스 스택의 상시 병목이 되면서, 모델을 “얼마나 덜 쓸 것인가”를 제품 품질과 함께 통제하는 문제를 다룬다는 점에서 모델 서빙 맥락을 이해하는 데 유용합니다.

🌊 1. 수요와 용량의 상시적 불일치

요인 논문의 서술
트래픽 성장 Bing은 월간 활성 사용자 10억 명 이상을 서비스하며, 온라인 트래픽은 지난 수년간 크게 늘었습니다. AI 통합 검색·채팅 시스템이 추가 수요를 만듭니다.
악성 트래픽 DDoS, 자동화된 봇, 대규모 스크래핑이 증가했습니다.
일시적 용량 손실 머신 장애, 새 기능 배포, 결함 있는 서비스가 가용성을 위협합니다.
GPU 병목 검색 엔진이 LLM을 점점 더 활용하면서 GPU 용량에 큰 압박이 생기고, 이에 의존하는 모든 서비스가 지연과 병목에 자주 대처해야 합니다.
시간 척도 이런 변동은 사람이 개입할 수 있는 것보다 빠른 시간 척도로 일어나므로, 과부하가 장애로 번지기 전에 빠르게 반응하는 자동 정책이 필요합니다.

⚖️ 2. 두 가지 전통적 대응

전략 내용 한계
과잉 프로비저닝(overprovisioning) 예상치 못한 트래픽을 흡수할 여유 용량을 유지 비싸고 비효율적입니다. GPU 같은 특수 자원의 용량 제약은 상시적이며, 수요 급증의 규모와 시점은 예측하기 어렵습니다. Bing의 경우 추가 여유 용량 확보가 불가능해 우아한 성능 저하가 필수입니다.
서비스 수준 보호 부하 차단(load shedding), 스로틀링(throttling), 회로 차단기(circuit breaker) 개별 서비스는 지키지만 지역적·독립적으로 동작하므로 제품의 기준 품질을 보장할 수 없습니다. 상호의존적 서비스들의 독립적 성능 저하 결정이 예상치 못하게 상호작용해, 트리거 사건보다 훨씬 오래 지속되는 지연·품질 급변, 즉 준안정(metastable) 동역학을 일으킵니다.

수동 조작 손잡이(knob)에 의존하는 접근은 기능·서비스 간의 큰 상호작용 공간을 만들어 지속적인 유지보수를 요구합니다.

🎯 3. HiLO의 위치

HiLO는 자동화된, 품질 인식(quality-aware)·부하 인식(load-aware) 제품 수준 성능 저하 시스템입니다. 각 서비스가 부하 계수를 보고하면, HiLO는 집계된 부하 계수를 제품 상태 격자에 매핑하고, 각 상태는 모든 참여 서비스의 서비스 수준을 결정론적으로 정합니다. 상태는 설계 시점에 의존성을 해소하는 형식적 구축 과정으로 만들어지므로, 런타임 의존성 탐색 없이 연속적·자율적 제어가 가능합니다. 저자들은 Bing 데이터센터에서 6년 넘게 우아한 성능 저하를 운영한 경험을 바탕으로 하며, HiLO는 2025년부터 프로덕션에 있습니다.

💡 Key Takeaway 과부하 대응의 핵심 문제는 “서비스가 살아남는가”가 아니라 “제품 품질이 통제된 결과인가”입니다. 지역적 보호만으로는 품질이 창발적 결과가 되고, HiLO는 이를 설계 시점에 검증된 소수 상태로 제한해 통제 결과로 바꿉니다.

성능 저하 정책을 평가하는 다섯 지표

저자들은 우아한 성능 저하 정책의 영향을 평가하는 다섯 지표를 정의합니다.

📏 1. 지표 정의

지표 의미 Bing의 구체적 신호
가용성(Availability) 정책이 기본 기능을 보존하고 서비스 장애를 막는가 목표 99.95% 이상
품질(Quality) 여러 신호의 조합 주 지표는 OneDCG(정규화된 DCG 변형, 결과 관련성). 그 외 무결과율(no-result rate) 같은 오류 신호, 콘텐츠 신선도·참여(재질의율 등) 같은 사용자 대면 실험 지표
안정성(Stability) 동일 조건에서 반복 실행했을 때 일관된 응답을 받는 질의 비율 아래 식
회복 속도(Recovery velocity) 과부하 사건 후 안정성과 품질이 사건 전 수준으로 돌아오는 데 걸리는 시간 기저 서비스가 정상으로 돌아오는 시간
용량 절감(Capacity savings) 성능 저하 기간 동안 회수한 용량 부하 계수(LF)로 측정

🧮 2. 안정성 식

$$ \text{Stability}(\%) = \frac{|{(q_i, q_j) : r_i = r_j}|}{|Q_{\text{pairs} }|} \times 100 $$

여기서 $Q_{\text{pairs} }$는 동일한 관측 가능 맥락(같은 질의, 같은 시간 창)에서 발행된 질의 쌍 $(q_i, q_j)$의 집합이고 $r_i, r_j$는 각각의 응답입니다. 응답이 동일하면 안정한 쌍으로 셉니다. 불안정성이 높으면 보통 기저 시스템 문제(비정상적 서비스 동작)를 뜻하므로 면밀히 모니터링합니다.

🔍 3. 왜 품질과 안정성을 따로 보는가

뒤의 평가에서 드러나듯, OneDCG가 목표 안에 있어도 안정성은 떨어질 수 있습니다. 안정성은 “같은 질문에 같은 답을 주는가”라는 예측 가능성의 지표이고, 회복 속도는 기저 서비스의 건강도를 간접적으로 보여 줍니다. 저자들은 이 둘을 품질과 분리해서 추적합니다.

💡 Key Takeaway 가용성·품질·안정성·회복 속도·용량 절감 다섯 축으로 정책을 평가합니다. 특히 안정성은 동일 질의 쌍의 응답 일치율로 정의되며, 기저 시스템 이상을 드러내는 조기 신호로 쓰입니다.

서비스 지역 정책의 실패: 사고 사례와 준안정 실패

HiLO 이전 Bing의 정책과, 그 한계를 드러낸 사고를 봅니다.

🏚️ 1. 이전 정책

Bing은 오랫동안 과부하 시 개별 서비스를 보호해 높은 가용성을 확보하는 데 집중했습니다. 각 서비스는 두 가지를 했습니다.

활동 내용
건강 모니터링 CPU 사용률, 요청 큐 깊이, 지연, 오류율 같은 지역 부하·건강 신호를 자체 모니터링
서비스 수준 조정 임계값을 넘으면 미리 정한 성능 저하 동작을 독립적으로 적용. 비핵심 기능 비활성화, 계산 충실도 감소, 요청 팬아웃 제한, 캐시 재사용 증가, 저우선 트래픽 차단 등

이 정책으로 가용성은 99.95%를 훨씬 넘게 유지했지만, 세 가지 근본적 문제가 생겼습니다. (1) 현재 제품 상태를 추론하기 어려워졌고, (2) 사용자에게 일관된 기준 품질을 보장하기 어려워졌으며, (3) 서비스 간 의존성이 지역화된 오케스트레이션과 제어 루프를 낳았습니다. 일부 컴포넌트는 PID 방식 같은 피드백 메커니즘으로 직접 의존 서비스를 제어하려 했는데, 이는 제품 수준의 테스트·디버깅·측정·실험을 복잡하게 만들었습니다.

💥 2. 사고의 전개 (Figure 1, 2)

단계 일어난 일
배포 어떤 기능 배포가 여러 워크플로가 공유하는 모델 서빙 서비스의 호출량을 늘렸습니다. 부분 트래픽의 플라이트 테스트는 통과했는데, 그때는 용량이 충분했기 때문입니다.
급증 전체 배포 후 한 데이터센터가 이미 용량 한계 근처에서 돌고 있었고, 10분 미만의 일시적 부하 급증이 한계를 넘겼습니다.
지역 정책 작동 공유 모델 서빙 서비스는 자기 정책대로 스스로를 보호하기 위해 성능을 낮추고 가용 상태를 유지했습니다.
조율 부재 호출자들은 자기 정책대로 계속 호출했고 수요를 줄일 조율된 방법이 없었습니다. 병목은 상류로 올라가 지연 증가와 연쇄 오류로 나타났습니다.
결과 OneDCG 1.11점 하락. 서비스는 살아남았지만 품질이 크게 손상되었습니다. 안정성은 약 90%에서 약 63%로 떨어져 회복에 4시간 이상 걸렸습니다. 심각도 2(severity-2) 에스컬레이션이 발생했고, 추가 의존성 호출을 줄이는 수정이 배포될 때까지 이틀 더 부하가 오를 때마다 OneDCG가 흔들렸습니다.

🧩 3. 드러난 구조적 공백

Bing에는 서비스별 성능 격리 보장(각 서비스가 자기 용량을 소유해 한 서비스의 과부하가 다른 서비스를 굶기지 못함)과 서비스 지역 성능 저하(최소한 스로틀링)가 늘 있었습니다. 그럼에도 조율되지 않은 정책은 준안정 실패(metastable failure)와 장기 품질 손실로 이어질 수 있음을 이 사고가 보여 줍니다. 조사에서 드러난 공백은 다음과 같습니다.

  • 서비스들이 용량 한계 근처에서 운영되며 넘침을 지역 보호에 맡기고 있었습니다.
  • 급증 전에 공유 서비스의 수요를 줄이거나 이후 회복을 조율할 메커니즘이 없었습니다.
  • 제품 수준 상태가 불분명해 디버깅이 어려웠습니다.
  • 결국 OneDCG는 통제된 결과가 아니라 창발적 행동이었습니다.

이 동역학은 모델 서빙에 국한되지 않고 공유된 용량 제약 서비스 어디서나 생길 수 있지만, GPU 용량 제약이 상시적인 Bing에서는 모델과 그 서빙 계층에서 점점 흔해지는 문제라고 저자들은 지적합니다.

💡 Key Takeaway 모든 서비스가 각자 살아남는 데 성공해도 제품은 실패할 수 있습니다. 10분 미만의 급증이 1.11점 OneDCG 하락과 4시간 이상의 불안정으로 이어진 이 사고가, 부하 신호·의존성·조율을 형식화해 과부하 전에 행동하는 제품 수준 정책의 필요성을 보여 줍니다.

관련 연구: 기능 중심 저하와 입장 제어

저자들은 기존 접근을 기능 중심(feature-centric) 성능 저하와 입장 제어(admission control) 두 축으로 정리합니다.

📚 1. 주요 시스템 비교

시스템 출처 핵심 메커니즘 HiLO와의 차이(저자 관점)
Brownout 학계 애플리케이션을 선택적 컴포넌트로 분리하고, 측정된 지연에 따라 제어기가 디머(dimmer)를 조절해 선택적 컴포넌트 비활성화 빈도를 결정 단일 애플리케이션 제어, 서비스 간 조율 없음
DefCon Meta 과부하 시 운영자가 수동으로 선택 조작하는 이진 성능 저하 손잡이. 기능이 별도 RPC로 구현되어 격리가 강하다고 가정. 관계형 DB로 손잡이 조합의 결과 결정 드문 사이트 비상 상황을 위한 사람 주도 운영. 수백 개 손잡이 유지 비용이 커진다고 Meta 스스로 언급. 손잡이 상호작용이 제품 행동을 암묵적으로 결정
Google SRE Google CPU·메모리·큐 길이·요청 우선순위 기반 작업별 스로틀링과 우아한 성능 저하. 저하 모드를 정기적으로 테스트하고 모니터링 가시성 유지 강조 지침 수준
SEDA / 적응형 입장 제어 학계 애플리케이션을 명시적 이벤트 구동 단계와 큐로 구조화. 단계별 동적 자원 제어기. 확장판은 P90 응답 시간 목표를 맞추기 위해 각 단계에서 요청을 필터링 단계 수준 자원 제어
Dagor WeChat 대기 큐의 평균 대기 시간으로 과부하 감지. 비즈니스 우선순위(로그인·결제 > 메시징)와 사용자 우선순위를 합성한 입장 수준을 적응 조정. 입장 임계값을 상류 호출자에 전달해 협력적 조기 차단 입장 제어 중심
Breakwater 학계 마이크로초 규모 RPC용 서버 주도 입장 제어. 서버가 발급하는 크레딧으로 부하 관리 입장 제어 중심
Rajomon 학계 시장 기반 접근. 서비스가 API 가격을 정하고 클라이언트가 토큰을 붙여 호출 그래프 전체에서 분산·조율된 속도 제한 입장 제어 중심
Netflix 산업 저우선 요청을 선택적으로 스로틀링해 재생 경험 보존. 지속적 우선순위화, 우선순위 기반 점진적 스로틀링, 카오스 테스트 검증 요청 우선순위 아이디어는 HiLO도 채택
QALM Uber 엔드포인트별 큐와 과부하 감지기(지연 모니터링). 요청 중요도로 영향받는 큐의 요청만 차단해 핵심 trip·인프라 요청 보존 중요도 기반 차단
AWS 산업 우아한 성능 저하를 신뢰성 패턴으로 문서화. 하드 의존성을 소프트 의존성으로 변환 권고 지침 수준

🧭 2. HiLO가 겨냥하는 시스템

HiLO는 서비스들이 긴밀히 상호의존적이고, 용량이 이기종이며, 과부하가 수동 개입이나 이진 기능 토글이 아니라 연속적 자율 관리를 요구하는 시스템을 겨냥합니다. Bing 같은 대규모 검색·LLM 서빙 스택은 질의가 여러 CPU 바운드 서비스와 GPU 바운드 랭킹/LLM 모델을 복잡한 의존성으로 가로지릅니다.

⚙️ 3. 입장 제어·회로 차단기와의 구분

입장 제어와 회로 차단기는 서비스 SLO를 지키기 위해 지역적으로 행동합니다. 격자는 과부하 시 명시적인 제품 수준 품질 기준선을 제공합니다. 저자들은 HiLO가 세밀한 최적성을 의도적으로 포기하고 예측 가능성·테스트 가능성·운영 명료성을 택했다고 말하며, 이것이 GPU 제약 모델과 LLM 파이프라인을 결합한 대규모 의존성 풍부 시스템에서 필수적이라고 봅니다.

💡 Key Takeaway 기존 연구는 단일 애플리케이션의 디머, 수동 기능 손잡이, 또는 서비스별 입장 제어에 머뭅니다. HiLO는 그 사이의 빈자리, 즉 “상호의존적 이기종 서비스에 걸친 자율적·연속적 제품 수준 조율”을 채웁니다.

핵심 추상화 1: 부하 계수(Load-Factor)

HiLO는 두 핵심 추상화 위에 서 있습니다. 첫째는 서비스 수준 용량 압박을 요약하는 부하 계수입니다.

📡 1. 정의와 성질

항목 내용
무엇 각 서비스가 실시간으로 내보내는, 현재 서비스 부하를 반영하는 정규화 스칼라 신호
유도 CPU 또는 GPU 사용률, 요청 큐 깊이, 꼬리 지연, 의존성 배압(backpressure) 같은 서비스별 지표에서 지역적으로 계산
가정 HiLO는 전역 용량 모델이나 서비스 간 비교 가능한 단위를 요구하지 않습니다. 오직 단조성(LF가 높을수록 과부하 위험이 높음)만 가정하고, 집계된 LF를 정밀한 최적화 입력이 아니라 서수적 혼잡 신호로 취급합니다.
Bing의 구현 LF는 유계 척도로 보고되고, 노이즈와 단기 급증을 완화하기 위해 저수지 샘플링(reservoir sampling) 같은 강건한 샘플링으로 서비스별로 집계됩니다.
위치 HiLO는 요청의 임계 경로 밖(Figure 4)에서 동작합니다.

🔀 2. 내부 파이프라인 (Figure 3)

서비스들이 주기적으로 부하 신호를 보고 → HiLO가 샘플링·집계 → 제품 수준 부하와 해당 제품 상태 $L_k$ 결정 → 참여 서비스별 서비스 수준 결정 → HiLO가 이를 서비스로 되돌려 배포 → 서비스가 집행.

🧪 3. 서비스별로 다른 올바른 신호 (Section 5)

저자들의 경험상 모든 서비스에 통하는 단일 지표는 없습니다. 올바른 지표는 서비스가 실제로 병목되는 곳을 반영합니다.

서비스 유형 적합한 신호 이유
네트워크 바운드 큐 길이 네트워크가 제약일 때 CPU는 낮은 채로 요청이 쌓임
CPU 바운드(예: 랭킹) CPU 사용률  
GPU 바운드(모델과 서빙 계층) GPU 사용률  
혼합 CPU 사용률 + 큐 길이 같은 하이브리드 병목을 더 잘 포착

올바른 지표는 워크로드가 진화하면서 바뀔 수도 있습니다. 바로 이 지점에서 단일 부하 계수 추상화가 도움이 됩니다. 각 서비스가 자기 병목에 맞는 지표나 조합을 고르고, HiLO는 정규화된 부하 계수만 요구하므로 자동으로 적응합니다.

💡 Key Takeaway 부하 계수는 “비교 가능한 절대량”이 아니라 “단조적인 서수 신호”입니다. 이 약한 가정 덕분에 CPU 서비스와 GPU 모델이 같은 제어 루프에 들어가고, 각 서비스는 자기 병목에 맞는 지표를 자유롭게 고를 수 있습니다.

핵심 추상화 2: 제품 상태 격자(Product State Lattice)

둘째 추상화는 유효하고 조율된 성능 저하 행동의 공간을 정의하는 제품 상태 격자입니다.

🪜 1. 제품 상태와 격자

개념 정의
제품 상태(product state) 과부하 시 제품의 조율된 운영 모드. 각 상태는 모든 참여 서비스에 대해 미리 정의된 서비스 수준(기능 비활성화, 단순화된 실행 경로, 팬아웃 감소, 저비용 모델 변형 등)에 결정론적으로 매핑됩니다.
격자(lattice) 제품 상태는 성능 저하 심각도로 부분 순서를 가집니다. 높은 상태는 용량 회수 면에서 낮은 상태를 지배하되, 유계이고 사전 검증된 품질 손실을 수반합니다.
Bing의 규모 시나리오당 6개 제품 상태(L0~L5, 심각도 오름차순), 서비스별로 유연성에 따라 2~6개 서비스 수준.

🗺️ 2. 상태-수준 매핑 예시 (Table 2)

제품 상태 Service-1 수준 … Service-X 수준
L0 0 … 0
L1 1 … 0
L2 2 … 1
L3 3 … 1
L4 3 … 2
L5 4 … 2

숫자가 클수록 더 큰 성능 저하입니다. 한 서비스는 L3에서 L4로 갈 때 수준이 그대로(3)인 반면 다른 서비스는 올라갈(1→2) 수 있습니다. 즉 제품 상태는 서비스들의 수준 조합을 조율하는 단위입니다.

🏗️ 3. 설계 시점 구축과 런타임 동작

시점 내용
설계 시점 서비스 소유자가 후보 서비스 수준을 정의하고, 용량 영향을 정량화하며, 품질 효과를 지역적으로 검증합니다. 의존성 효과는 합성 중에 해소됩니다. Figure 5처럼 제품 상태 전환은 개별 서비스를 새 수준으로 옮기며, 서비스 자체 행동뿐 아니라 피호출자를 어떻게 호출하는지도 바꿉니다. 예컨대 호출자가 피호출자를 얼마나 자주 부르는지와 어떤 저비용 변형을 고르는지가 독립적으로 제어됩니다. 상태는 종단간 테스트·실험 훅으로 검증한 뒤 확정됩니다.
런타임 HiLO는 시나리오당 단일 활성 제품 상태를 선택하고, 부하 증가 시 단조적으로 전환하며, 불필요한 진동을 피하기 위해 통제된 회복을 적용합니다. 요청별 결정, 런타임 의존성 탐색, 동적 호출 그래프 추론은 하지 않습니다.

🎚️ 4. 의도적 트레이드오프

DefCon이 많은 기능 수준 손잡이를 노출해 그 상호작용이 제품 행동을 암묵적으로 결정하고, Brownout이 서비스 간 조율 없이 단일 애플리케이션을 제어하는 것과 달리, 격자는 온라인 행동을 검증된 소수의 조율 상태로 제한합니다. 세밀한 최적성 대신 예측 가능성·테스트 가능성·운영 명료성을 택한 것입니다.

💡 Key Takeaway 제품 상태 격자는 “가능한 모든 손잡이 조합” 대신 “검증된 6개 운영 모드”만 허용합니다. 의존성은 설계 시점에 해소되고, 런타임은 상태 선택만 하므로 결정론적이고 테스트 가능하며, 어떤 순간이든 제품이 어떤 상태인지 말할 수 있습니다.

딥 모델과 LLM을 위한 성능 저하 전략

GPU 집약적 딥 모델과 서빙 계층에 HiLO를 적용하는 것은 용량 제약 때문에 Bing에 결정적입니다.

🧠 1. 요청별 라우팅 분류기를 쓰지 않는 이유

대안은 요청별 분류기로 비싼 모델 변형과 싼 변형 사이를 런타임에 라우팅하는 것입니다. HiLO는 이 복잡성을 피합니다. 정상 조건에서는 항상 비싼 모델을 쓰고, 저비용 변형으로의 성능 저하는 과부하가 감지될 때만 균일하게 적용합니다. 분류기와 달리 추가 품질 손실 없이 기본적으로 최선의 OneDCG를 보장합니다.

🛠️ 2. 다섯 가지 전략 (Table 1)

# 전략 심각도
a 다중 질의(multi-queries, MQ) 감소 경미~중간
b 평가 문서 수 감소 경미~중간
c 모델 레이어 축소 중간~높음
d 모델 건너뛰기 높음
e 캐시 만료 시간 증가 경미~높음

🔗 3. 전략의 결합 예

프로덕션 랭킹 모델의 성능 저하는 두 서비스에 걸쳐 조율됩니다. 모든 수준에서 MQ와 처리 문서 수를 점진적으로 줄여 용량을 회수하고, 더 깊은 수준에서는 모델 레이어 축소를 추가합니다. 덜 파괴적인 상류 동작을 먼저 적용하고 모델 수준 동작은 깊은 수준에서 더합니다. 순서는 설계 시점에 결정·검증되며 추가 아키텍처 변경은 필요 없습니다.

💡 Key Takeaway 모델 성능 저하는 “수요를 줄이는 상류 동작(MQ·문서 수 감소)”과 “공급을 싸게 만드는 모델 동작(레이어 축소·건너뛰기)”의 두 축으로 구성되며, 가벼운 것부터 순서대로 쌓입니다. 요청별 분류기를 쓰지 않아 정상 시 품질은 손해 보지 않습니다.

제품 상태 구축의 3단계와 용량 회수 목표

제품 상태 격자는 형식적 3단계 과정으로 만들어집니다.

🎯 1. 용량 회수 목표의 유도

각 서비스의 수준별 회수 목표는 스택 전체의 생존 목표에서 유도됩니다. 예를 들어 제품이 스로틀링 없이 기준 피크의 2배 RPS 생존을 목표로 정하면, 각 서비스는 그 목표를 지원하는 데 필요한 수준 수를 정하고, 일정 RPS에서 수준별 목표 부하 계수 감소량을 추정합니다. 여유 공간 확보 전략은 지역 계산 감소, 상류 서비스의 수요 감소, 또는 둘 다입니다. 서비스가 여러 제품에 공유되면 제품/시나리오별 회수 목표는 독립적으로 정해집니다. 다만 런타임 제품 상태 선택은 상대적이어서, 한 시나리오의 성능 저하가 공유 서비스에 대한 다른 시나리오의 부하에 의해 유발될 수 있습니다.

🪜 2. 세 단계

단계 주체 내용
Phase 1 서비스 지역 검증 서비스 소유자 성능을 낮출 수 있는 지역 작업 집합을 식별하고 영향을 추정합니다. 각 작업에 대해 현재 부하 계수 사용률, 트리거율(실행 빈도), 제안된 대체 동작, 상대적 우선순위에 기반해 부하 계수 개선과 품질 하락을 추정합니다. 필요하면 제품 팀과 논의해 후보를 확정하고, 상대 우선순위와 추정된 전체 서비스 부하 계수 개선에 따라 동작들을 수준으로 묶습니다. 서비스 지역 테스트·A/B 실험으로 추정을 검증한 뒤 서비스 수준을 확정합니다. 모델 레이어 축소처럼 모델 서비스 자체에서 추론 비용을 줄이는 경우가 여기 해당합니다.
Phase 2 의존성 해소 피호출자와 호출자 부하를 줄이기 위해 상류 변경이 필요한 피호출자가 호출자와 조율해 서비스 간 성능 저하 동작(Table 1 등)을 호출자의 서비스 수준에 통합합니다. 새 하위 수준이 생기면 호출자의 수준 정의에 반영합니다. Phase 1의 추정·테스트·실험 단계를 피호출자와 호출자가 공동으로 반복해, 지표 변화·우선순위·회수 목표에 대해 수준을 검증합니다.
Phase 3 제품 상태 생성 제품(시나리오) 소유자 앞 두 단계의 서비스 수준으로 HiLO에 제품 상태 설정을 만듭니다. 높은 제품 상태일수록 서비스 수준이 더 저하되도록 틀을 잡습니다. 후보 상태는 종단간 테스트 훅·실험 훅으로 검증하며, 의도치 않은 경험을 일으키거나 사용자 지표를 목표 이상으로 떨어뜨리는 상태는 버리거나 조정합니다. 마지막으로 종단간 용량 테스트로 시스템 전체가 피크 생존 목표에 놓였을 때 원하는 효과(생존, 품질 유지, 빠른 안정성 회복)가 얻어지는지 확인합니다.

🧷 3. 추가 제어: 시나리오와 요청 우선순위 (Section 3.4)

프로덕션 배포에서 제품 상태 선택 이외의 제어가 필요하다는 것이 드러났습니다. 서로 다른 제품 버티컬은 독립적인 성능 저하 정책을 요구했고, 비즈니스 이해관계자는 가치 인식 성능 저하를 요청했습니다. HiLO는 핵심 추상화를 바꾸지 않고 둘을 수용합니다.

제어 내용
경로 맥락(시나리오 식별자) 제품 상태가 적용되는 별개의 운영 맥락. 공통 호출 그래프를 공유하는 서로 다른 요청 경로나 진입점(웹 검색, 이미지 검색, 비디오 검색 같은 버티컬). 같은 서비스 집합이 뒷받침해도 여러 경로가 서로 다른 제품 상태에서 동시에 운영될 수 있습니다. HiLO는 시나리오 간 정책과 경로 간 상대 우선순위를 분리합니다.
요청 우선순위 주어진 경로 안에서 트래픽을 우선순위 버킷(높음·중간·낮음)으로 분류하는 선택적 메타데이터. 저우선 트래픽을 고가치 요청보다 먼저 저하시켜 더 세밀한 성능 저하를 가능하게 합니다. HiLO는 요청 우선순위별로 정책을 서비스에 게시합니다. 우선순위 부여는 요청 경로상에서 HiLO 외부에서 이루어지며 메타데이터로 전파됩니다.

프론트엔드 서비스(Figure 4의 Service A)가 경로 맥락을 식별하고 요청 우선순위를 부여해, 하류 서비스가 일관된 종단간 메타데이터로 동작하게 합니다.

💡 Key Takeaway 격자는 “스택 전체 생존 목표 → 서비스별 회수 목표 → 지역 검증 → 의존성 해소 → 제품 상태 합성 → 종단간 검증”이라는 하향식 과정으로 만들어집니다. 시나리오와 요청 우선순위는 핵심 추상화를 바꾸지 않고 버티컬별·가치별 차등 저하를 더합니다.

모니터링, 테스트·실험 훅, 안전 속성

HiLO가 운영 가능하려면 상태를 관측하고, 배포 전에 검증하며, 자체 장애에도 안전해야 합니다.

📊 1. 모니터링

HiLO와 서비스들은 플랫폼의 로깅·모니터링 프레임워크에 추가 아키텍처 변경 없이 통합됩니다. Bing에서는 서버 측에서 헤더와 응답 세부를 포함한 모든 노출(impression)이 개별 서비스와 프론트엔드에서 로깅됩니다. 전용 로깅 파이프라인이 이 로그를 엮어 Kafka·Spark·HDFS 위에 구축된 내부 대규모 오프라인 데이터 처리 플랫폼 Magnetar(MT)로 보내며, Titan이 대화형 시각화·질의 계층입니다. 실시간 보고와 운영 모니터링을 위해 서비스는 Geneva(Azure Monitor와 유사)에 지표와 카운터를 올립니다. 이 인프라는 HiLO에서 세 가지를 로깅하는 것으로 확장됩니다.

  • 참여 서비스에서 집계된 부하 계수
  • 선택된 제품 상태
  • 각 서비스에 배포된 해당 서비스 수준

서비스는 각 노출과 함께 HiLO가 할당한 상태를 로깅하고, 기존 대시보드가 이 메타데이터를 소비해 제품 수준 성능 저하 행동을 보고합니다.

🧪 2. 테스트 훅과 실험 훅

훅 목적 절차
테스트 훅 새 제품 상태나 서비스 수준을 사용자 트래픽에 배포하기 전 격리 검증 새 설정을 HiLO에 테스트 시나리오로 구성합니다. 프론트엔드가 테스트 트래픽 또는 분기된 프로덕션 트래픽의 일부를 테스트 시나리오 식별자로 태깅합니다. HiLO는 후보 상태를 태깅된 트래픽에만 적용해, 실제 사용자에 영향 없이 OneDCG·지연·용량 사용률을 측정합니다.
실험 훅 테스트를 통과한 상태를 A/B 실험으로 승격 기존 A/B 테스트 프레임워크를 통해 새 상태를 사용자 트래픽의 일부(보통 1일 또는 3일간 0.5%, 이후 1%·5%로 점진 승격)에 적용하고 비즈니스 지표(사용자당 매출, DAU, 사용자당 세션 참여) 변화를 기록합니다.

🛡️ 3. 안전과 운영 속성 (Section 3.6)

속성 내용
부적절한 상호작용 제거 시나리오당 단일 활성 상태가 제품 행동의 모호성을 없애고, 독립 적용된 제어 간의 부적절한 상호작용을 막습니다.
진동 조정 부하가 오르면 HiLO는 더 제한적인 상태로 단조 전환합니다. 회복 전환은 설정 가능한 계수로 감쇠되어, 운영자가 빠른 회복과 지속적 안정성 사이의 트레이드오프를 조정할 수 있습니다.
장애 격리 각 서비스는 HiLO가 할당한 수준과 자체 결정한 수준 중 더 제한적인 쪽을 집행합니다. HiLO가 불가용하면 서비스들은 자체 결정 수준을 독립적으로 계속 적용해 HiLO 조율 없이도 가용성을 보존합니다. HiLO가 회복되면 진행 중인 서비스 실행을 방해하지 않고 제품 수준 조율이 재도입됩니다.

💡 Key Takeaway HiLO는 로그에 “집계 LF, 선택 상태, 배포 수준” 세 가지만 더해 기존 관측 인프라에 얹히고, 테스트 훅과 0.5%→1%→5%의 A/B 승격으로 상태를 데이터 기반으로 확정합니다. 서비스는 항상 HiLO 수준과 자체 수준 중 더 제한적인 쪽을 따르므로 HiLO 자체의 장애가 가용성을 해치지 않습니다.

평가 1: 프로덕션 과부하 응답과 한 달 운영 스냅샷

HiLO의 성능은 실제 과부하 조건에 대한 운영 응답, HiLO 없는 경우와의 비교, 서비스·GPU 모델의 부하 계수·용량 개선, A/B 실험과 품질 지표를 통한 사용자 영향의 네 차원으로 평가됩니다.

📈 1. 단일 과부하 사건 응답 (Figure 6)

북미 데이터센터의 한 사건에서 트래픽은 기준 피크의 1.93배에 도달한 뒤 3시간 더 과부하 영역에 머물렀습니다. 아래 차트는 HiLO가 계산한 제품 부하 계수와 제품 상태 전환을 보여 주며, 품질은 목표 한계 안에 있었고 안정성은 빠르게 회복되었습니다. 별도의 모델 유발 과부하(APAC 데이터센터, 피크의 0.94배, 이틀간 매일 약 6시간)에서는 HiLO가 OneDCG 영향을 0.14점으로 억제했습니다. 앞서 본 사고의 1.11점 하락과 심각도 2 에스컬레이션과 대비됩니다.

주의할 점은 제품 상태 전환이 트래픽 곡선이 아니라 부하 계수를 따른다는 것입니다. 기준 피크 1배가 반드시 부하 계수 100%에 대응하지는 않는데, 여유 공간과 현재 질의 구성(query-mix) 때문입니다.

📅 2. 2026년 1월 운영 스냅샷 (Figure 7)

항목 값
관리한 사건 과부하 임계값을 넘은 사용자 트래픽 급증 9건 + 계획된 용량 테스트 16건 = 25건
강도 범위 기준 피크의 1.02배~2.38배
지속 범위 약 10분~약 180분
지역 세 지역

Figure 7의 x축은 과부하 지속 시간(사용자 트래픽이 기준 피크 1.0배를 넘은 첫 분부터 마지막 분까지), y축은 활성 성능 저하 시간(제품이 L1 이상에 머문 총 분)입니다. 모든 점이 대각선 아래에 있어 활성 성능 저하 시간이 항상 과부하 지속 시간보다 짧습니다. HiLO는 부하 계수가 임계값을 넘는 동안만 성능을 낮추고 즉시 회복하며, 나머지 과부하 기간에는 용량 여유가 부하 계수를 임계값 아래로 유지해 제품이 완전 품질(L0)로 운영됩니다. 일부 사건은 매우 짧아 수동 개입을 완전히 배제합니다.

✅ 3. 지표별 결과

지표 결과
가용성 모든 데이터센터가 이 사건들 내내 99.95%(목표) 이상 유지
품질 (Figure 8) 최악의 OneDCG 하락은 2.38배 피크 부하에서 0.425점으로 0.5점 목표 임계값 아래. 무결과율도 정상 범위
회복 속도 (Figure 9) OneDCG 회복은 5분 이동 평균이 사건 전 기준선의 0.05 이내로 돌아오는 것, 안정성 회복은 첫 5분 평균이 90%에 도달하는 것으로 정의. 과부하 종료부터 이 창의 첫 분까지의 기간을 보고. 최대·중앙값 모두 HiLO가 과부하 중 기저 서비스를 건강하게 유지해 부하가 빠지면 빠르게 회복됨을 확인

🔄 4. 급증 프로파일에 따른 적응 (Figure 10)

피크 트래픽은 비슷하지만 비례적 급증이 다른 두 APAC 사건(기준 피크 1배에서 +45% vs 0.5배에서 +203%)을 비교하면, HiLO의 응답은 피크 트래픽만으로 결정되지 않습니다. 부하 계수 동역학에 적응해 같은 피크에서 서로 다른 에스컬레이션 깊이를 만듭니다.

💡 Key Takeaway 한 달 9건의 실제 급증(최대 2.38배)에서 가용성 99.95% 이상, 최악 OneDCG 하락 0.425점으로 목표 안에 머물렀습니다. 성능 저하는 부하 계수가 임계값을 넘는 동안에만 적용되므로 활성 저하 시간은 항상 과부하 지속보다 짧습니다.

평가 2: HiLO 유무 용량 테스트와 30시간 데이터센터 유지보수

🧪 1. 용량 테스트 설계

Bing은 합성 트래픽을 원하는 수준까지 천천히 주입한 뒤 멈추는 방식으로 용량 테스트를 합니다. 기준선(“HiLO 없음”)에서도 서비스들은 서비스 지역 정책(비조율)으로 성능을 낮춥니다. Figure 11은 유럽 데이터센터에서의 점진적 램프업과 HiLO 응답을 보여 줍니다. 트래픽과 HiLO 응답 사이의 타이밍 차이(램프다운 후 회복 지연, 피크 트래픽 전의 상태 변경)는 HiLO의 결정 간격, LF 신호 지연, 용량을 회수하는 성능 저하 동작을 반영합니다. HiLO 없이는 이 제품 수준 행동이 관측 불가능했습니다.

📊 2. 두 데이터센터 비교 (Table 3)

  HiLO 없음 지속(분) HiLO 없음 피크 부하 HiLO 없음 OneDCG Δ HiLO 있음 지속(분) HiLO 있음 피크 부하 HiLO 있음 OneDCG Δ
APAC 34 2.13× −0.05 35 2.06× 0
EU 35 2.06× −0.02 36 2.16× 0

두 테스트 모두 기준 피크의 약 2배 부하를 겨냥했고, HiLO를 쓰면 OneDCG 영향이 관측되지 않았습니다. 다만 용량 테스트는 부하가 점진적으로 오르는 단기 사건이므로, 프로덕션 과부하 영향은 앞 절의 OneDCG 변화가 더 대표적이라고 저자들은 덧붙입니다.

🚫 3. 무결과 오류율 (Figure 12)

무결과 오류율은 백엔드 서비스가 결과를 내지 못한 질의 비율로, 용량 유발 실패를 나타냅니다. HiLO 없이는 이 오류율이 일관되게 더 높거나 테스트가 진행되며 증가했고, APAC 데이터센터에서는 테스트 후반의 증가가 극적이었습니다. HiLO는 더 나은 조율과 더 낮은 오류율을 가능하게 했으며, 운영자들은 이제 데이터센터를 약 2배 기준선까지 자신 있게 정기적으로 스트레스 테스트합니다.

🏢 4. 30시간 이상, 3개 데이터센터, 자율 과부하 관리 (Figure 13, 14)

항목 내용
상황 주요 미국 데이터센터(DC-A)가 유지보수로 약 30시간 이상 오프라인. CDN이 트래픽을 재분배해 다른 두 데이터센터(DC-B, DC-C)가 부하를 흡수
가용성 목표 SLO 이상 유지, 성능 저하는 필요한 만큼만 적용
DC-B 16.7시간의 성능 저하 시간 중 83%를 L1~L2에서 운영
DC-C L5 급등은 짧았음(0.4시간)
OneDCG 성능 저하 중에도 목표 안(최대 하락 0.38점)
안정성 부하가 정상화되자 즉시 회복

DC-C에서는 재분배된 트래픽이 GPU 집약적 모델의 용량 부족을 드러내 상태가 진동했습니다(Figure 14b). 성능 저하와 회복은 설정 가능하며 비즈니스 우선순위를 반영합니다. 지속 과부하 아래에서 저하 상태를 너무 오래 유지하는 것은 (적어도 Bing에서는) 부하 계수가 임계값 아래로 떨어졌을 때 회복을 재시도하는 것보다 매출 영향이 큽니다. 따라서 시스템은 추가 모델 용량 프로비저닝으로 부족이 해소될 때까지(몇 시간 후) 저하와 회복 사이를 진동했습니다. 그러나 비슷한 병목이 큰 OneDCG 하락과 심각도 2 에스컬레이션을 일으킨 앞의 사고와 달리, HiLO는 품질을 한계 안에 유지하고 기저 서비스를 내내 건강하게 지켜 심각도 2 개입이 필요 없었습니다. 핵심 성과는 과부하 창 동안 진동을 완전히 피하는 것이 아니라, 과부하 아래에서 시스템 건강과 품질을 자율적으로 유지하는 능력입니다.

💡 Key Takeaway 약 2배 부하 용량 테스트에서 HiLO는 OneDCG 하락을 −0.02~−0.05에서 0으로 없앴고, 30시간 데이터센터 오프라인 중에도 최대 0.38점 하락으로 품질을 지켰습니다. 진동은 남았지만 이는 “저하 상태를 오래 유지하는 비용 > 회복 재시도 비용”이라는 비즈니스 선택의 결과입니다.

🧠 1. 딥 랭킹 모델의 용량 이득과 품질 트레이드오프 (Table 4)

샘플 랭킹 모델의 성능 저하 모드는 두 독립 메커니즘으로 구동됩니다. 첫째, 상류의 MQ와 문서 감소가 모델의 추론 호출을 점진적으로 줄여(L5에서 최대 29%) 모델 자체는 그대로 둔 채 상당한 여유를 만듭니다. 둘째, 깊은 수준(L4~L5)에서 모델 레이어 축소가 추론당 지연과 계산 비용을 줄입니다. 호출량 감소는 수요(호출 수)에, 레이어 축소는 공급(호출당 비용)에 작용하므로 독립적으로 보고됩니다.

OneDCG 영향 범주: 최소(Min., < 0.1), 중간(Mod., 0.1~0.25), 높음(High, 0.25~0.5), 심각(Sev., > 0.5).

상태 동작 호출량 Δ 지연 Δ (vs L0) OneDCG 영향
L1 MQ + 문서 감소 ~ −3% N/A 최소
L2 MQ + 문서 감소 ~ −7% N/A 최소
L3 MQ + 문서 감소 ~ −13% N/A 최소
L4 위 + 레이어 축소 ~ −22% ~ −7% 중간
L5 위 + 레이어 축소 ~ −29% ~ −12% 중간

비교를 위해, 이 모델을 스로틀링하거나 완전히 건너뛰면 OneDCG 영향은 심각 임계값(≫ 0.5)을 훨씬 넘습니다. 이진 모델 비활성화보다 단계적 성능 저하가 가치 있는 이유입니다. 모델 레이어 축소는 현재 검증 완료 후 프로덕션 배포 대기 중이며, 추가 성능 저하 수준도 동시에 탐색 중입니다.

OneDCG는 Bing의 주된 비즈니스 핵심 품질 지표라 서비스 소유자가 수준별 하락을 목표 안에 신중히 관리하지만, 유일한 신호는 아닙니다. 콘텐츠 신선도와 참여 같은 더 넓은 사용자 대면 온라인 지표는 OneDCG가 유지되더라도 깊은 상태에서 더 많이 떨어질 수 있습니다.

⚙️ 2. 두 서비스의 용량 이득 (Table 5)

서비스 상태 CPU Δ (vs L0) 지연 Δ (vs L0) OneDCG 영향
Exec. Engine L3+ −40% N/A 중간
ReRanking L1 −5% −4% 최소
ReRanking L2 −10% −4% 최소
ReRanking L3 −23% −14% 최소
ReRanking L4 −33% −25% 중간
ReRanking L5 −36% −25% 중간

Exec. Engine은 두 수준(전체 서비스 그래프와 하나의 저하 수준)으로, ReRanking은 여섯 수준(다섯 개가 저하)으로 운영됩니다.

💬 3. Copilot Search 사례 (Figure 15)

HiLO는 웹 검색을 넘어 Bing 안의 LLM 중심 대화형 검색 경험인 Copilot Search에도 배포되어 있습니다.

항목 웹 검색 Copilot Search
제품 상태 수 6 (L0~L5) 5 (L0~L4)
부하 계수 출처 백엔드 서비스 기저 모델 서비스
성능 저하 방식 백엔드 처리 조정 모델 호출을 유발하는 제품 기능을 점진적으로 비활성화
집행 위치 백엔드 서비스 전적으로 프론트엔드 계층
실행 체제 팬아웃이 많은 저지연 서비스 높고 가변적인 추론 지연을 가진 LLM 중심 파이프라인

Copilot Search의 단계별 동작은 Copilot Search 탭을 오른쪽으로 재배치(L1), 추가 제안 비활성화(L2), 위치 기능 비활성화(L3), 탭 완전 숨김(L4)입니다. 실행 체제와 성능 저하 메커니즘이 다름에도 HiLO 프레임워크는 그대로 적용됩니다.

⏱️ 4. 운영 오버헤드 (Table 6)

HiLO는 요청 경로 밖에서 동작해 실행 경로 지연을 더하지 않습니다.

지표 값
결정 주기 2분
HiLO 내부 지연 (P95) < 1 ms
지역당 CPU 코어 수 64

💡 Key Takeaway 랭킹 모델은 L5에서 호출 −29%·지연 −12%에 OneDCG 영향은 0.1~0.25점 범위로, 모델을 통째로 끄면 0.5점을 훨씬 넘는 것과 대비됩니다. 같은 프레임워크가 백엔드 조정(웹 검색)과 프론트엔드 기능 숨김(Copilot Search) 모두에 적용되며, 오버헤드는 지역당 64코어·결정 주기 2분·내부 지연 1ms 미만입니다.

사용자 대면 영향: A/B 실험 결과

제품 상태는 배포 전 사용자 대면 A/B 실험으로 검증됩니다. 각 후보 상태를 프로덕션 트래픽의 통제된 일부에 활성화하고, 핵심 비즈니스 지표(매출, DAU, 세션 참여)에 대한 영향을 기준선(L0) 대비 측정합니다.

📊 1. L1, L2의 영향 (Table 7)

각 셀은 기준선(L0) 대비 상대 변화(Δ%)이며, ∗는 $p < 0.05$에서 통계적으로 유의함을 뜻합니다.

범주 지표 표면 L1 Δ% L2 Δ%
유지(Retention) 단기 DAU 둘 다 ≈ 0% ≈ 0%
콘텐츠 신선도 SuperFresh Rate 데스크톱 −11.02%∗ −15.21%∗
콘텐츠 신선도 SuperFresh Rate 모바일 −10.70%∗ −14.41%∗
참여 DSQ 재질의율 데스크톱 +0.14% +0.36%
참여 DSQ 재질의율 모바일 +3.49%∗ +1.93%
지연(서버 측) WebAnswer 지연 P95 데스크톱 −1.65%∗ −3.30%∗
지연(서버 측) WebAnswer 지연 P95 모바일 −1.69%∗ −3.37%∗

🔍 2. 읽기

관찰 해석
유지는 영향 없음 단기 DAU가 두 상태 모두 약 0%
콘텐츠 신선도는 단조 감소 성능 저하 아래 예상된 트레이드오프를 확인
DSQ 재질의율 증가 사용자가 첫 질의로 만족스러운 결과를 찾지 못했음을 뜻하는 고유 검색 질의(Distinct Search Query) 재질의율이 두 표면·두 상태에서 일관되게 증가(+0.14%~+3.49%). 모바일 L1 증가(+3.49%)는 통계적으로 유의. 방향이 일관된 이 추세는 성능 저하 아래의 가볍지만 측정 가능한 사용자 대면 품질 트레이드오프를 확인
꼬리 지연 개선 두 표면 모두에서 개선되어, 모든 참여 서비스에 걸친 조율된 성능 저하의 집합적 효과로서 용량 회수를 확인
기타 매출 등 다른 지표도 비슷한 방향 패턴을 보이지만 생략

💡 Key Takeaway L1·L2는 DAU에 영향 없이 꼬리 지연을 1.65~3.37% 줄이지만, 콘텐츠 신선도를 10.7~15.2% 낮추고 재질의율을 올립니다. OneDCG가 목표 안이어도 다른 사용자 지표는 움직이므로, A/B 실험이 상태 선택을 데이터 기반 과정으로 만듭니다.

교훈과 한계

HiLO의 설계는 적용 범위를 제한하는 의도적 트레이드오프를 포함합니다. 저자들은 Bing의 경험에서 채택 결정을 안내하는 교훈을 정리합니다.

⚠️ 1. 설계 트레이드오프

항목 내용
거친 입도 제어 Bing에서 HiLO는 6개의 이산 제품 상태로 동작합니다. 이 거친 입도는 검증과 운영 추론을 단순화하지만 기능별 세밀한 조정은 제한합니다. 저자들의 경험상 거친 제어로 충분한데, 더 세밀한 입도는 단계당 의미 있게 더 많은 용량을 회수하지도, 회수를 가속하지도 않았습니다.
설계 시점 부담 제품 상태 정의에는 각 참여 서비스가 성능 저하 동작을 식별하고 용량 영향을 정량화해 일관된 제품 상태로 합성해야 하며, 이는 종종 수 주에서 수 개월의 팀 간 조율이 걸립니다. 복잡한 호출 그래프를 가진 서비스에서 저하 가능 동작을 찾는 것은 간단치 않습니다. 예를 들어 각각 CPU의 아주 작은 비율을 쓰는 9만 개 이상의 하위 워크플로를 가진 서비스는 3개월의 분석이 필요했습니다. 소유권도 모호할 수 있습니다. 플랫폼 팀은 부하와 용량을, 기능 팀은 워크플로와 사용자 대면 품질을 담당하므로, 저하 동작이 리프 서비스에 속하는지 호출 계층에 속하는지 불분명한 경우가 많습니다. 호출 그래프 분석이 수작업을 줄이지만 분석 시간은 서비스 복잡도에 따라 늘어납니다. 구축의 완전 자동화는 열린 문제이며, 적응형·학습된 제어가 활발한 방향입니다. 이 비용의 상당 부분은 RPS가 커진 대규모 기존 서비스에 HiLO를 후속 적용한 데서 비롯되며, 처음부터 성능 저하를 일급 관심사로 다루는 서비스는 훨씬 적은 노력으로 온보딩됩니다.
단계적 채택 Bing에서는 먼저 서비스들이 부하 계수 신호를 내보내고, 가장 중요하고 용량 제약이 큰 백엔드 서비스와 모델에 조율된 저하를 적용해 종단간 검증한 뒤, 점진적으로 범위를 확장했습니다. 아직 온보딩되지 않은 서비스는 기존 서비스 지역 저하를 유지했습니다. 이 규모에서는 경영진 후원과 팀 간 조율을 주도하는 전담 중앙 팀도 필요합니다.
분리된 아키텍처 적용성 많은 작고 독립 소유된 서비스로 이루어진 제품에 제품 수준 조율이 확장되는가라는 질문에, 저자들은 중앙 제어 평면이 대역 밖에서 분리된 서비스를 관리하는 것이 서비스 메시에서 확립된 패턴이라고 답합니다. HiLO는 요청 경로 밖에 있고, 불가용 시 서비스가 지역 저하로 후퇴하며, 시나리오별로 조율을 분할하므로 중앙 집계기는 초크 포인트가 아닙니다. 서비스 메시와 달리 품질 인식 저하를 조율하고 요청별 지연을 더하지 않습니다. 조율은 일반적으로 설계 시점에 식별된 용량 제약 임계 경로상의 소수 서비스에 적용되며, 나머지는 성능 격리 보장에 기대어 지역 저하를 계속합니다. Bing의 한 시나리오는 십여 개 주요 서비스와 모델을 조율하므로, 설계 비용은 총 서비스 수가 아니라 병목 서비스 수에 비례합니다.

🔄 2. 운영 교훈

교훈 내용
품질 vs 안정성 긴장 안정성은 선택입니다. 저하로부터의 회복은 설정 가능한 감쇠 계수로 지배되며, 저하를 더 오래 강제하면 매우 안정적인 결과를 얻을 수 있습니다. Bing의 정책은 균형을 추구하며 때로는 저하 중 안정성 감소를 받아들입니다. 예컨대 2배 부하에서 OneDCG는 보존되지만 집합 안정성은 떨어집니다(Figure 14). 정책은 안정성 자체를 목표로 삼기보다 매출을 포함한 비즈니스 지표에 최적화됩니다.
성능 저하 자체를 추적 효과적인 저하는 기저 문제를 가릴 수 있습니다. 한 사례에서 모델 용량 부족이 2주 넘게 여러 데이터센터에서 매일 저하를 일으켰는데, OneDCG와 오류율은 한계 안이었고 안정성도 매 사건 후 빠르게 회복되어 문제가 실제보다 덜 심각해 보였습니다. 이에 저자들은 저하 자체를 일급 신호로 다루어 빈도·깊이·지속을 독립적으로 추적합니다. 예컨대 단일 모델이 더 깊거나 긴 저하를 일으키면 심각도 2 사건으로 에스컬레이션합니다.
지표 지연과 튜닝 위험 가용성과 OneDCG는 거의 실시간으로 측정되지만 매출·DAU 같은 비즈니스 핵심 지표는 수 시간 또는 다음 날 지연으로 도착합니다. 잘못 설정된 제품 상태가 빠른 루프 신호에서는 건강해 보여도 몇 시간 뒤에야 드러나는 비즈니스 영향을 일으킬 수 있으므로, 실시간 신호와 A/B 실험이 모두 필요합니다.
부하 분산 먼저, 저하는 다음 과부하 처리는 두 계층에서 일어납니다. 먼저 한 지역의 증가한 부하는 CDN 라우팅으로 전역에 분산되며, 집계된 백엔드 부하 계수는 CDN 라우팅의 품질 신호 중 하나이기도 합니다. 데이터센터 수준 저하는 분산이 불충분할 때만 개입합니다. 그래서 HiLO는 전역이 아니라 데이터센터별로 범위가 잡힙니다. 이 메커니즘은 데이터센터 간 동등성을 가정하며, 없으면 분산이 불가능합니다. 두 계층이 공유 신호에 독립적인 임계값과 타이밍을 적용하므로 불일치가 피드백을 일으킬 수 있습니다. 한 관측 사건에서 이중 트래픽 급증이 CDN 재분배와 HiLO 응답의 상호작용을 가리켰고, 임계값 정렬의 필요성을 재확인했습니다. Bing은 페일어웨이(failaway)와 데이터센터 수준 저하에 적절한 감쇠 계수를 두어 빠른 진동을 막습니다.
지속적 투자와 최적화 지역 테스트·용량 테스트·A/B 실험을 통한 상태의 주기적 검증이 필수입니다. 초기 A/B 실험에서 특정 모바일 표면 지표가 예상과 달라 재보정을 촉발했습니다. 입증된 용량 이득을 바탕으로 모델 레이어 축소 투자를 확대해 더 깊은 저하 수준을 탐색하고 추가 모델로 범위를 넓히고 있습니다. 초기에는 모델 갱신 주기가 저하 검증을 앞질러, 저하 모드 설계·검증을 정규 모델 개발 주기에 포함시켰습니다. HiLO 범위 밖 서비스와 모델의 LF도 정기적으로 모니터링해 필요시 온보딩합니다. 회복 시간, 특히 안정성은 데이터센터마다 달라 최적화 기회를 추적·연구합니다.

🔭 3. 결론과 향후 방향

Bing의 우아한 성능 저하는 6년에 걸쳐 진화했습니다. 초기 접근은 서비스 지역 보호를 우선해 높은 가용성을 유지했지만 제품 품질을 창발적 행동으로 남겼습니다. HiLO는 설계 시점에 의존성을 해소하고 사전 검증된 소수 제품 상태 격자 위에서 자율적으로 운영함으로써 품질을 통제된 결과로 만듭니다. 2025년부터 배포되어 모든 Bing 데이터센터의 과부하 사건을 지속적으로 관리하며, 웹 검색과 LLM 파이프라인에 걸쳐 품질 손실을 운영 목표 안에 묶습니다.

향후 방향은 제품 수준 인식을 지역 간 트래픽 관리에 통합하는 것과, 과거 부하 패턴과 품질 결과를 이용해 최적 제품 상태를 발견하는 학습된 제어 정책을 탐색하는 것입니다.

💡 Key Takeaway HiLO의 가장 큰 비용은 런타임이 아니라 설계 시점입니다. 상태 정의에 수 주~수 개월, 극단적으로는 9만 개 하위 워크플로 서비스에 3개월이 걸렸습니다. 운영에서는 “저하가 문제를 가린다”는 역설 때문에 저하의 빈도·깊이·지속을 독립 신호로 추적하고, CDN 분산과 데이터센터 저하 두 계층의 임계값을 정렬하는 것이 핵심 교훈입니다.