OpenAI의 최근 장애 보고서 분석 OpenAI가 12월 11일 발생한 장애에 대한 공개 보고서를 발표했어요.

OpenAI의 최근 장애 보고서 분석

OpenAI가 12월 11일 발생한 장애에 대한 공개 보고서를 발표했어요. 이 보고서는 시스템 장애의 원인과 해결 과정을 상세히 다루고 있어서, 이를 통해 배울 점이 많습니다.

1. 시스템 과부하(Saturation) - 장애의 시작

"수천 개의 노드가 동시에 작업을 수행하면서 Kubernetes API 서버가 과부하 상태에 빠졌고, 이는 대규모 클러스터 대부분에서 Kubernetes 제어 플레인을 중단시켰습니다."

• Saturation(포화)는 시스템이 처리할 수 있는 한계를 초과했을 때 발생하는 상태를 말해요. 흔히 오버로드(Overload) 또는 리소스 고갈(Resource Exhaustion)이라고도 불리죠.

• OpenAI의 경우, Kubernetes API 서버가 과도한 트래픽을 처리하지 못해 포화 상태에 빠졌고, 이로 인해 DNS 기반 서비스 검색 메커니즘이 실패했어요.

• 이런 포화 상태는 시스템 장애에서 매우 흔한 원인 중 하나예요. OpenAI의 사례 외에도 Cloudflare, Rogers, Slack 같은 회사들도 비슷한 문제를 겪은 적이 있어요.

2. 테스트는 통과했지만...

"변경 사항은 스테이징 클러스터에서 테스트되었으며, 문제가 관찰되지 않았습니다. 그러나 영향은 특정 크기를 초과하는 클러스터에만 나타났고, 각 노드의 DNS 캐시로 인해 가시적인 장애가 발생하기 전에 롤아웃이 계속 진행되었습니다."

• 모든 테스트를 통과했음에도 불구하고, 실제 운영 환경에서만 발생하는 문제들이 있어요. 특히, 포화 상태와 같은 문제는 시스템이 전체 부하(Full Load)에 노출되었을 때만 드러나는 경우가 많아요.

• OpenAI는 새로운 텔레메트리(telemetry) 서비스를 배포하기 전에 CPU와 메모리 같은 리소스 사용량을 평가했지만, Kubernetes API 서버의 부하를 충분히 고려하지 못했어요.

"서비스 상태는 모니터링했지만, 클러스터 상태를 모니터링하는 프로토콜은 부족했습니다."

3. 복잡하고 예상치 못한 상호작용(Complex, unexpected interactions)

"이는 여러 시스템과 프로세스가 동시에 실패하고, 예상치 못한 방식으로 상호작용한 결과였습니다."

• 복잡한 시스템에서는 개별 구성 요소의 문제만으로 장애가 발생하지 않아요. 시스템 간의 상호작용이 문제를 일으키는 경우가 많습니다.

• OpenAI의 경우, 새로운 텔레메트리 서비스가 Kubernetes API 서버에 과도한 부하를 발생시켰고, 이로 인해 DNS 기반 서비스 검색이 실패했어요.

"새로운 텔레메트리 서비스 구성은 대규모 클러스터에서 Kubernetes API 부하를 예상치 못하게 증가시켰고, 제어 플레인을 과부하 상태로 만들어 DNS 기반 서비스 검색을 중단시켰습니다."

• Kubernetes API가 비정상적으로 작동하면, 일반적으로는 기존 서비스는 계속 작동해야 해요. 하지만 이번에는 DNS가 문제의 연결고리가 되었어요. DNS가 실패하면서, Kubernetes 위에서 실행 중이던 서비스들까지 영향을 받았죠.

4. DNS 캐싱과 문제의 지연(Impact of a change is spread out over time)

"DNS 캐싱으로 인해 변경 사항이 적용된 후 서비스가 실패하기까지 시간이 지연되었습니다."

• DNS 캐싱은 변경 사항의 영향을 시간에 걸쳐 분산시키는 특성이 있어요. 이는 문제를 진단하기 어렵게 만들 수 있죠.

• OpenAI의 경우, 텔레메트리 서비스 배포가 DNS 캐싱으로 인해 즉각적인 문제를 일으키지 않았고, 롤아웃이 거의 완료된 후에야 장애가 드러났어요.

"DNS 캐싱은 문제를 덜 가시적으로 만들었고, 롤아웃이 전체적으로 진행된 후에야 문제가 나타났습니다."

5. 복구의 어려움(Failure mode makes remediation more difficult)

"문제를 해결하려면 Kubernetes 제어 플레인에 접근해야 했지만, Kubernetes API 서버의 부하로 인해 접근이 불가능했습니다."

• 장애가 발생하면, 운영자가 사용하는 도구나 시스템도 함께 영향을 받을 수 있어요. 이는 문제 해결을 더 어렵게 만들죠.

• Facebook도 2021년 대규모 장애 당시 비슷한 문제를 겪었어요. DNS가 실패하면서 내부 도구들까지 사용할 수 없게 되었죠.

"우리는 몇 분 안에 문제를 파악하고, 클러스터를 신속히 복구하기 위해 여러 작업을 동시에 진행했습니다."

• OpenAI는 다음과 같은 세 가지 전략을 병행했어요:

1. 클러스터 크기 축소: Kubernetes API 부하를 줄임.
2. Kubernetes 관리 API에 대한 네트워크 접근 차단: 새로운 요청을 막아 API 서버가 회복할 시간을 확보.
3. Kubernetes API 서버 확장: 대기 중인 요청을 처리할 리소스를 추가로 확보.

"세 가지를 병행한 결과, 문제를 일으킨 서비스를 제거할 수 있을 만큼의 제어를 복구했습니다."

• 하지만 이런 대응은 항상 불확실성을 동반해요. 잘못된 조치가 상황을 더 악화시킬 수도 있죠.

6. 신뢰성을 높이려다 발생한 문제(A change intended to improve reliability) - 아이러니한 상황

"조직 전반의 신뢰성을 높이기 위해 클러스터 관측 도구를 개선하는 작업의 일환으로, Kubernetes 제어 플레인 메트릭을 수집하는 새로운 텔레메트리 서비스를 배포했습니다."

• 이 장애는 신뢰성을 높이기 위한 변경 사항이 오히려 장애를 유발한 사례예요. 이는 복잡한 시스템에서 흔히 발생하는 문제로, 신뢰성을 높이려는 시도가 예상치 못한 방식으로 시스템을 불안정하게 만들 수 있어요.