Incident Library
적용된 필터 원인소프트웨어 결함조직OpenAI모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

    2026년 3월 4일 오후 4시 26분 PST 무렵부터 약 30분 동안 여러 모델의 API 요청에서 오류율과 지연 시간이 올랐다. 영향은 주로 API 트래픽에 나타났고, Codex 트래픽 일부도 영향을 받았다.

    촉발

    보호용 서킷 브레이커가 일부 스케줄링 작업을 멈춰 둔 사이에 인프라 작업이 큐에 쌓였고, 서킷 브레이커가 풀리자 이 작업이 한꺼번에 실행됐다.

    원인
    구성 요소
    기여 요인
    조치
    • 엔지니어들이 영향을 받은 모델에 인프라 자원을 손으로 다시 배정했다.
    • 추론 엔진을 다시 올리고 모델에 재배정해 서비스를 되살렸다.
    후속 조치
    • 자동 용량 관리 시스템이 실제 상태와 어긋났을 때 이를 더 잘 감지하고 대응하도록 보호 장치를 보강한다.
    • 서킷 브레이커와 스케줄링 시스템의 상태와 그 영향을 쉽게 알아볼 수 있도록 관측성을 높인다.
    • 오래 멈췄다가 풀린 뒤 큐에 쌓인 작업이 대량으로 한꺼번에 실행되지 않도록 보호 장치를 더한다.
    • 용량 조정이 실제 상태와 어긋나는 문제를 잡아내도록 모니터링과 알림을 개선한다.
    교훈

    실행을 멈춘 동안에도 작업을 큐에 쌓는 자동화는 멈춤이 풀리는 순간 낡은 상태를 근거로 한 변경을 한꺼번에 쏟아낼 수 있다. 서킷 브레이커가 무엇을 멈춰 두었는지, 풀릴 때 무엇이 실행될지 눈으로 확인할 수 있어야 한다. 긴 멈춤 뒤에 쌓인 작업이 대량으로 한 번에 실행되지 않게 막아야 한다.

  2. 증상

    2023년 11월 8일 태평양 시각 오전 5시 42분부터 7시 16분까지 OpenAI 로 가는 요청 상당수가 502 나 503 오류로 실패했다. 모든 모델과 API 엔드포인트에서 실패가 크게 늘었다.

    촉발

    그날 아침 completion 요청이 그전 어느 날보다 훨씬 많이 들어왔다.

    원인
    구성 요소
    기여 요인
    조치
    • 들어오는 트래픽을 제한했다.
    • 서비스를 한꺼번에 재배포했다.
    • 트래픽을 천천히 다시 올렸다.
    후속 조치
    • 루프에서 responseBuffer 를 매번 새로 할당하던 코드를 버퍼를 미리 할당해 재사용하도록 고쳤다. 배포 뒤 메모리와 CPU 사용량이 모두 3배 개선됐다.
    • 설정된 메모리 한도를 알맞은 수준으로 조정해 서비스에 여유 용량을 넉넉히 확보했다.
    • 트래픽을 더 매끄럽게 덜어 낼 수 있도록 rate limit 제어를 여러 가지 넣었다.
    • 추가 예방책으로 서비스 용량을 늘렸다.
    • 메모리 동작 이상이 서비스 문제로 커지기 전에 잡아내도록 여러 알림을 바꾼다.
    • 이 서비스에 오토스케일링을 설정한다. 용량을 늘리면 상위 서비스에 영향을 주던 문제를 바로잡았기 때문에 이제 설정할 수 있다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: 자동 용량 관리 시스템, 컨테이너 메모리 한도. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1