전직 Azure Core 엔지니어가 폭로하는 Azure 신뢰 붕괴의 시작점

전직 엔지니어가 본 Azure의 민낯

• Azure Core 엔지니어 출신이 "마이크로소프트가 어떻게 1조 달러를 날렸는가"라는 시리즈를 시작함 — OpenAI를 거의 잃을 뻔하고, 미 국방부 장관이 공개적으로 신뢰 상실을 언급할 정도의 사태

  • 글쓴이는 2023년 5월 Azure Core의 Overlake R&D 팀에 시니어로 합류한 인물
  • Windows 팀 출신으로, Docker·Azure Kubernetes·Azure Container Instances 등의 컨테이너 플랫폼을 발명·구현한 경력에 다수의 특허 보유
  • Azure 자체도 2010년 Windows Azure 시절부터 10년 넘게 프로덕션 구독을 운영한 베테랑임

• 첫날 팀 회의에서 목격한 광경이 압권임 — 팀이 Windows의 핵심 컴포넌트들을 Overlake 가속기 카드의 초소형 ARM SoC에 포팅하는 계획을 진지하게 논의하고 있었음

  • Overlake(Azure Boost) 카드는 손톱만 한 크기의 팬리스 Linux 칩으로, RAM과 전력 예산이 극도로 제한적
  • FPGA 위 공유 메모리 통신 프로토콜용으로 할당 가능한 메모리가 겨우 4KB
  • 그런데 COM, WMI, perf counters, VHDX, NTFS, ETW 같은 Windows 커널/유저모드 컴포넌트들을 이 칩에 올리겠다는 계획이었음
  • 122명 규모의 조직 전체가 "Windows를 Linux에 포팅"하는 불가능한 논의에 빠져 있었음

173개 에이전트의 미스터리

• Azure 노드 하나를 관리하는 에이전트가 무려 173개나 있었는데, 마이크로소프트 내 단 한 명도 이게 왜 필요한지 설명하지 못했음

  • Azure의 핵심은 결국 VM, 네트워킹, 스토리지인데 여기에 관측성과 서비싱만 더하면 될 일
  • SQL, K8s, AI 워크로드 전부 이 위에서 돌아가는 거라 무거운 건 Core OS와 하이퍼바이저가 이미 처리하고 있었음
  • "어떻게 173개까지 늘어났는지는 아마 영원한 미스터리일 것"이라는 게 글쓴이의 평가

• 기존 스택은 400W Xeon 프로세서 위에서도 노드당 수십 개 VM 정도에서 한계에 도달하고 있었음

  • 하이퍼바이저 자체는 노드당 1,024개 VM까지 지원 가능한데, 관리 스택이 병목
  • 스택 자체가 "시끄러운 이웃(noisy neighbor)"이 되어서 고객 VM에서 관측 가능한 수준의 지터를 유발
  • 이 상태에서 초소형 ARM SoC로 옮기면서 몇 배로 스케일업하겠다? 어떤 차원에서도 불가능한 계획

아직 공개되지 않은 이야기들

• 이건 시리즈의 첫 번째 글일 뿐이고, 앞으로 공개될 내용이 더 무거움
  • CEO에게 보낸 편지, 마이크로소프트 이사회에 보낸 편지, Cloud + AI EVP에게 보낸 편지 — 그리고 그 모두의 완전한 침묵
  • OpenAI를 거의 잃을 뻔한 사건의 전말
  • 미 국방부 장관이 공개적으로 언급한 신뢰 상실
  • Rust 전환 명령(mandate)의 배경
  • OpenAI 베어메탈 팀에서의 경험
  • 중국 등에서의 "에스코트 세션"
  • 2023년부터 출시된 것처럼 발표했지만 실제 작업조차 시작하지 않았던 기능들

---

기술 맥락

• Azure Boost(Overlake)는 Azure의 차세대 하드웨어 오프로드 전략의 핵심이에요. 네트워킹, 스토리지 I/O 같은 인프라 작업을 호스트 CPU에서 전용 가속기 카드로 넘기는 건데, AWS의 Nitro 시스템이랑 비슷한 방향이에요. 근데 문제는 기존 Windows 기반 관리 스택을 이 카드로 어떻게 옮기느냐였던 거죠.

• 에이전트 173개라는 숫자가 왜 충격적이냐면, 클라우드 노드 관리에서 에이전트는 각각 메모리와 CPU 사이클을 먹거든요. AWS나 GCP는 이걸 최소화하는 방향으로 설계하는데, Azure는 레거시가 겹겹이 쌓이면서 아무도 전체를 파악 못 하는 상황까지 간 거예요.

• "Windows를 Linux에 포팅"한다는 게 단순히 코드를 옮기는 문제가 아니에요. COM이나 WMI 같은 건 Windows 커널과 깊이 결합된 서브시스템이라, Linux 위에 재현하려면 사실상 OS를 새로 만드는 수준이거든요. 4KB 공유 메모리 제약까지 있는 임베디드급 환경에서 이걸 시도한다는 건... 글쓴이가 "화성 식민지화에 비유"한 게 과장이 아니에요.

• noisy neighbor 문제는 멀티테넌트 클라우드의 고전적 과제인데, 보통은 고객 VM이 서로에게 영향을 주는 걸 말해요. 근데 여기서는 클라우드 플랫폼의 관리 스택 자체가 noisy neighbor가 된 거라, 근본적으로 아키텍처가 잘못된 상황이에요.