ChatGPT가 동작하지 않았던 이유
OpenAI는 전 세계적으로 수백 개의 Kubernetes 클러스터를 운영하고 있음.
Kubernetes 클러스터
컨트롤 플레인(Control Plane): 클러스터 관리를 담당
데이터 플레인(Data Plane): 모델 추론을 처리하는 실제 워크로드 담당
시스템 상태에 대한 가시성을 강화하기 위해 클러스터 단위의 관측 도구(Observability Tooling)를 개선하는 작업을 진행했고,
텔레메트리(Telemetry) 서비스를 배포하여 Kubernetes 컨트롤 플레인의 세부 메트릭을 수집하도록 설정함.
장애 원인
텔레메트리 서비스 구성의 문제:
새로운 텔레메트리 서비스가 Kubernetes API 호출을 대규모로 유발했으며, 호출의 비용이 클러스터 크기에 비례하여 증가.
수천 개의 노드가 동시에 리소스 집약적인 API 작업을 수행하면서, Kubernetes API 서버가 과부하 상태에 도달.
대규모 클러스터에서의 영향:
가장 큰 클러스터에서 문제가 가장 심각하게 나타났으며, 사전 테스트 단계에서는 클러스터 크기 차이로 인해 이를 감지하지 못함.
DNS 캐싱으로 인해 초기 배포 단계에서 문제가 눈에 띄지 않았고, 대규모 클러스터에 배포되면서 장애가 전면화.
컨트롤 플레인과 DNS 의존성:
데이터 플레인은 컨트롤 플레인 없이도 어느 정도 독립적으로 동작 가능하지만, DNS 기반 서비스 디스커버리는 컨트롤 플레인에 의존.
컨트롤 플레인의 장애로 인해 서비스 간 통신 경로가 차단되어 시스템 전반에 걸친 장애로 이어짐.
검증 상의 취약점
스테이징 환경 규모가 실제 대규모 프로덕션 클러스터와 달라 고부하 상황 재현 실패.
DNS 캐싱으로 문제 발생 시점이 지연되어 롤아웃 도중 명확한 장애 징후 확인 어려움.
CPU/메모리 자원 검증은 수행했으나, Kubernetes API 서버 부하 가능성에 대한 점검 미비.
DNS 의존성 파급효과
데이터 플레인은 컨트롤 플레인 없이 일정 기간 동작 가능하지만, DNS 조회는 컨트롤 플레인에 의존.
DNS 캐시가 만료되며 대량의 DNS 조회 요청 발생 → 컨트롤 플레인 추가 부하 → 복구 난이도 상승.
복구 전략
클러스터 규모 축소를 통한 API 부하 완화.
네트워크 차단 및 API 서버 리소스 증대를 통해 컨트롤 플레인 접근 재확보.
문제 서비스를 제거하고, 정상 클러스터로 트래픽 우회.
예방 대책
단계적(Phased) 롤아웃 및 인프라 변경 시 클러스터·컨트롤 플레인 헬스 모니터링 강화.
컨트롤 플레인 불능 상황 대비를 위한 장애 유도(Fault Injection) 테스트 도입.
비상 상황에서 API 서버 접근을 위한 ‘브레이크 글래스(break-glass)’ 메커니즘 구축.
DNS 의존성을 줄여 데이터 플레인과 컨트롤 플레인의 연계성 축소.
캐싱 개선 및 동적 레이트 리미팅으로 클러스터 재기동 속도 및 안정성 강화.
요약
새로운 텔레메트리 서비스를 설정하면서 각 노드에서 Kubernetes API를 빈번하고 대규모로 호출하게 됨.
대규모 프로덕션 클러스터에서도 테스트로 재현하지 못했던 수준의 API 트래픽이 발생하여, API 서버(컨트롤 플레인)가 과부하되고 작동이 중단됨.
DNS 조회가 실패하면서(컨트롤 플레인을 필요로 함) 서비스 검색 시스템이 무너져, 여러 서비스에 걸쳐 장애가 확대됨.
