DevOps Case Study: OpenAI

Info

OpenAI의 공개된 Incident Postmortem, 인프라 블로그, 파트너사 기사 등을 바탕으로 정리한 DevOps 사례 분석입니다. OpenAI에서”만” 유효한 내용은 최대한 배제하고, 대규모 서비스 운영에 일반적으로 적용 가능한 교훈 위주로 작성했습니다.

OpenAI는 LLM 서빙을 위해 대규모 Kubernetes 클러스터를 운영하고 있다. 이 문서에서는 그들의 인프라 구성과 장애 사례를 DevOps 관점에서 분석하고, 대규모 클러스터 운영에서 얻을 수 있는 교훈을 정리한다.

인프라 개요

클라우드 및 컴퓨팅

• OpenAI의 연구/제품/API 워크로드는 Microsoft Azure의 전용 AI 슈퍼컴퓨터 인프라에서 동작한다.
• 2025년 10월, Microsoft와의 독점 계약이 변경되었다. API 제품은 여전히 Azure 독점이지만, Non-API 제품(ChatGPT 등)은 다른 클라우드에서도 서빙 가능하게 되었다. 이후 AWS와의 제휴도 발표되어 Multi-cloud 체제로 전환 중이다.
• GPU 클러스터는 수만 개의 GPU를 랙/팟/클러스터 단위로 묶어 하나의 분산 컴퓨팅 리소스로 운영한다. 최신 세대는 랙 단위로 72개의 NVIDIA Blackwell Ultra GPU를 묶은 NVL72 시스템을 수천 개까지 확장한다.

Kubernetes 사용

OpenAI는 K8s를 핵심 오케스트레이션 도구로 사용하며 이는 공식 블로그에서 확인된 사실이다.

• 최대 7,500 노드 규모의 K8s 클러스터를 운영한다.
• API Server와 etcd를 클러스터 외부의 전용 노드에서 운영한다 (가장 큰 클러스터 기준 각 5대).
• 네트워킹은 Flannel에서 Azure VMSS 네이티브 Pod 네트워킹으로 전환하여 처리량을 개선했다.

추론(Inference) 경로

ChatGPT 요청의 대략적인 처리 흐름은 다음과 같다.

1. 프론트엔드/API 게이트웨이: 인증, 요금제, Rate Limit 처리
2. 프롬프트 전처리/정책 필터: 토큰화 및 안전성 필터
3. 모델 서버: GPU 클러스터에서 토큰 단위 생성
4. 후처리/안전 필터링: 추가 정책 필터 후 사용자에게 전달

캐시 계층에는 Redis 클러스터를 사용하며, 사용자 세션/메타데이터 저장과 DB 조회 부하 감소에 활용한다.

---

주요 Incident 분석

2023-03: Redis 버그에 의한 사용자 데이터 노출

Redis 클라이언트 라이브러리(redis-py)의 버그와, OpenAI 서버 변경으로 인한 요청 취소 증가가 결합되어 발생한 장애다.

원인: Asyncio 환경에서 Redis 클러스터와의 연결을 재사용하는 과정에서, 취소된 요청이 커넥션 풀 상태를 오염시켜 다른 사용자의 응답 데이터가 잘못 반환되었다.

영향: 일부 사용자가 다른 사용자의 채팅 제목, 메시지 일부, 결제 정보 단편(카드 마지막 4자리 등)을 볼 수 있었다. ChatGPT Plus 가입자 중 약 1.2%가 영향을 받았다.

교훈:

• 캐시 계층에 대한 신뢰를 전제로 한 설계에서, 커넥션 풀 + 비동기 처리 + 오픈소스 라이브러리 버그가 결합되면 데이터 노출로 이어질 수 있다.
• 캐시 반환값이 요청 사용자와 일치하는지에 대한 검증 로직이 필요하다.
• 소프트웨어 공급망 보안(SBOM, 의존성 감사)의 중요성을 보여주는 사례다.

2024-12-11: Kubernetes Control Plane 장애

이 사례는 K8s 관련 Postmortem이 상당히 자세히 공개되어 있어 참고할 만한 가치가 높다.

원인: 새로운 텔레메트리 서비스 배포가 모든 노드에서 리소스 집약적인 K8s API 호출을 트리거했다. 이 부하가 클러스터 규모에 비례하여 증가하면서 K8s Control Plane을 압도했고, DNS 기반 서비스 디스커버리까지 연쇄적으로 실패했다.

영향: 약 4시간 22분간 서비스 장애가 발생했다.

핵심 문제 — Break Glass의 부재: 장애 중 On-call 엔지니어가 클러스터에서 kubectl을 실행할 수 없는 상태에 빠졌다. Control Plane이 죽으면 클러스터 접근 자체가 불가능해지는 것이다.

Warning

Break Glass Workflow란 긴급 상황에서 일반적인 접근 제어를 우회하여 시스템에 접근할 수 있는 비상 메커니즘이다. OpenAI는 이 Postmortem 이후 Break Glass 메커니즘 도입을 약속했지만, 6개월 후 2025년 6월 장애에서도 여전히 부재했던 것으로 확인된다.

다만, Break Glass는 강력한 권한이므로 남용 가능성에 주의해야 한다. 실제로 운영 환경에서 Pod exec 권한을 요구받은 적이 있는데, 당시에는 Audit 시스템이 없었기 때문에 거부했다. 업계 표준(NIST, HIPAA, SOC2 등)에 따르면 Audit은 Break Glass의 핵심 구성요소이므로 무통제 상태에서의 거부 자체는 합리적이었지만, 이상적으로는 수기 로그 등 보상 통제(compensating control)와 함께 Break Glass 자체는 확보하는 것이 권장된다. 궁극적으로는 Hashicorp Boundary나 Teleport 같은 도구로 Audit + 임시 권한 관리를 함께 해결하는 것이 현실적인 접근이다.

교훈:

• 텔레메트리/모니터링 서비스의 배포도 일반 워크로드와 동일한 수준의 Canary 배포와 영향도 분석이 필요하다.
• Control Plane에 대한 부하를 사전에 테스트해야 한다. 특히 클러스터 규모에 비례하는 작업은 위험도가 높다.
• 장애 시 클러스터 접근이 불가능해지는 상황에 대비한 Break Glass 메커니즘이 필수적이다.

2024-12-26: 데이터센터 전원 장애

클라우드 제공자의 데이터센터 전원 장애로 인한 사고다.

영향: 복구에 약 10시간 소요. 데이터베이스는 글로벌 복제가 되어 있었지만, 리전 단위 Failover에 수동 개입이 필요했다.

교훈:

• DB 복제만으로는 부족하다. 리전 장애 시 자동 Failover가 동작하는지까지 검증해야 한다.
• 클라우드 제공자의 인프라 장애는 통제 밖이므로, “벤더 장애 모드”에 대한 별도 Runbook이 필요하다.

2025-06-10~11: 대규모 서비스 장애 (약 15.5시간)

2025년 가장 큰 장애 사례다.

원인: 일상적인 OS 업데이트가 GPU 노드에서 systemd-networkd를 재시작했고, OpenAI의 네트워킹 에이전트와 충돌하여 영향받은 노드의 모든 라우팅 정보가 제거되었다.

영향: ChatGPT, API, Sora 등 전 서비스에서 약 15.5시간 장애. 일부 분석에서는 전체 복구까지 30시간 이상 걸린 것으로 본다.

핵심 문제 — 역시 Break Glass의 부재: 공식 Write-up에서 “The absence of break-glass tooling to rapidly restore network connectivity on affected nodes extended the overall recovery timeline”이라고 명시했다. 2024년 12월에 도입을 약속한 Break Glass가 6개월이 지나도 완성되지 않은 것이다.

교훈:

• OS 업데이트 같은 “일상적” 변경도 네트워킹 스택과의 충돌 가능성을 사전 검증해야 한다.
• Canary 방식의 점진적 롤아웃이 인프라 레벨 변경에도 적용되어야 한다.
• Break Glass 같은 안전장치는 Postmortem에서 “도입 예정”으로 끝나면 안 된다. 실제 구현과 테스트까지 추적해야 한다.

2025-07-16: Config 전파에 의한 연쇄 장애

원인: 잘못된 설정값이 포함된 구성 변경이 여러 서비스로 전파되면서, 다수 백엔드 파드가 크래시 루프에 빠졌다. 로그인, 웹 서비스 등 20개 이상의 구성 요소가 영향을 받았다.

영향: 약 55분간 장애.

교훈:

• Config도 코드와 동일한 수준의 리뷰/테스트/승인 절차가 필요하다 (IaC, GitOps, Policy-as-code).
• 잘못된 값이 들어왔을 때 안전한 기본값으로 폴백하는 방어 로직이 크래시 루프를 방지한다.
• 동일한 설정을 여러 서비스가 공유하면 Blast Radius가 커진다. 서비스별 Config 스코프 분리와 점진적 롤아웃이 필요하다.

2025-11-18: Cloudflare 장애에 의한 서비스 중단

Cloudflare의 Bot Management 기능 파일이 두 배로 커지면서 전 네트워크에 전파되어, 전 세계 웹사이트의 약 20%가 영향을 받은 대규모 장애다. ChatGPT뿐만 아니라 X, Shopify, Claude 등도 함께 다운되었다.

교훈:

• 단일 CDN/에지 네트워크에 대한 의존은 앱 상태와 무관한 전체 서비스 중단으로 이어질 수 있다.
• 중요한 서비스라면 Multi-CDN 전략 또는 Origin 직접 접근 경로를 고려해야 한다.
• 외부 사업자 장애라도 최종 사용자에게는 “우리 서비스 장애”이므로, 상태 페이지에 투명하게 알려야 한다.

2025-12-02: 라우팅 Misconfiguration

원인: 잘못된 라우팅 구성으로 일부 요청이 적절한 백엔드로 전달되지 못했다.

영향: 약 45분, 일부 사용자에게만 영향.

교훈:

• 네트워크/라우팅 계층 변경도 코드 배포와 같은 수준으로 관리해야 한다 (Staging 검증, Health check 기반 전환).
• “일부 사용자에게만 영향”이라는 것은 Blast Radius를 세그먼트 단위로 제한하는 구조가 동작했다는 의미이기도 하다.

---

종합 교훈

1. 변경 관리(Change Management)

위 사례들의 공통점은 구성 변경 또는 시스템 업데이트가 직간접 원인이라는 것이다.

• 모든 변경(코드, 인프라, 설정)은 Git 기반 관리 + 리뷰/승인 절차를 표준화
• Canary/Blue-green 등 점진적 배포 전략 도입 및 자동 롤백
• 변경 전후 SLO 메트릭(에러율, 레이턴시, 성공률) 자동 비교, 이상 시 배포 중단

2. Blast Radius 최소화

하나의 잘못된 변경이 전체 서비스로 전파되는 것을 막아야 한다.

• Config 스코프를 서비스 경계별로 분리
• 텔레메트리/모니터링 같은 인프라 서비스도 점진적 롤아웃 대상
• 세그먼트 단위로 변경을 적용하여 장애 영향 범위를 제한

3. Break Glass 메커니즘

장애 상황에서 시스템 접근이 불가능해지면 복구 자체가 불가능하다.

• K8s Control Plane 장애 시에도 클러스터에 접근할 수 있는 비상 경로
• VPN, 별도의 관리 네트워크, Out-of-band 접근 수단 마련
• Postmortem 액션 아이템은 구현/테스트까지 완료를 추적해야 한다 — OpenAI는 6개월간 방치했다

4. 모니터링/관측가능성

장애 탐지에는 내부 모니터링뿐 아니라 외부 신호도 활용한다.

• 애플리케이션 레벨: 에러율, p95 Latency, 요청 수, 스로틀링
• 인프라 레벨: 노드 상태, 오토스케일링, 네트워크 라우팅, CDN 헬스
• 비즈니스 레벨: 사용자 보고(DownDetector, SNS 등)
• SLO 기반 알림과 온콜 체계의 정교화

5. 서드파티/공급망 리스크 관리

Mixpanel 보안 사고, Cloudflare 장애 등 내부 시스템과 무관한 장애도 결국 “우리의 장애”가 된다.

• 벤더 선정 시 보안/가용성/컴플라이언스 기준 명확화
• 벤더 교체가 가능하도록 추상화 레이어 설계
• 벤더 장애를 전제로 한 Runbook 마련 (커뮤니케이션, 폴백, 로깅)
• 데이터 최소 수집 원칙: 분석 도구에 정말 그 데이터가 필요한지 점검

6. 캐시/세션 계층의 데이터 안전성

Redis 사례에서 보듯, 캐시 계층은 성능과 데이터 무결성 사이의 트레이드오프가 존재한다.

• 캐시 반환값의 사용자 일치 검증 (단순히 성능만 보지 말 것)
• 비동기 환경에서의 커넥션 풀 관리에 각별한 주의
• 오픈소스 라이브러리의 버그가 데이터 노출로 이어질 수 있으므로 SBOM과 의존성 감사 필요

---

참고 자료

• Scaling Kubernetes to 7,500 nodes | OpenAI
• December 11, 2024 Incident Postmortem | OpenAI Status
• June 10, 2025 Outage Write-up | OpenAI Status
• June 10th Service Disruption FAQ | OpenAI Help Center
• ChatGPT Outage July 2025 Recap | Pingdom
• Mixpanel Incident | OpenAI
• Cloudflare November 18, 2025 Outage | Cloudflare Blog
• OpenAI-Microsoft Partnership Restructuring (Oct 2025)
• Infinite Scale: Azure AI Superfactory Architecture | Microsoft
• OpenAI Redis Bug Analysis | RedPacket Security
• Break Glass Workflows for K8s | Rafay