사례21건

21건 중 1~5번째

1. IL-0471 GitHub Actions 워크플로 실행이 대량으로 실패하거나 큐에서 오래 기다렸다

   GitHub2026

   증상

   2026-08-06 15:05 UTC 부터 GitHub Actions 워크플로 실행이 시작하지 못하거나 도중에 실패했고, 일부 Actions REST API 요청이 오류를 냈다. 일부 고객은 워크플로에서 예상하지 못한 rate limiting 을 겪었다.

   오류율 상승지연 시간 증가

   촉발

   이벤트를 처리하고 Actions 작업을 만드는 Actions 내부 서비스에 일상 배포를 했다. 배포로 파드가 교체되는 동안 남은 용량이 포화됐다.

   원인

   용량 한계

   구성 요소

   CI 시스템

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화

   조치

   • 용량을 늘렸고, 처음 무너진 서비스들은 17:00 에 회복했다.
   • 시스템이 회복할 수 있게 웹훅으로 들어오는 작업을 줄였다. 한때 웹훅의 약 15% 만 처리했다.
   • 밀린 이벤트를 처리할 용량을 늘렸다.
   • 러너가 유효하지 않은 작업을 되풀이해 가져가려 하지 않도록 하는 변경을 배포했다.
   • 작업을 가져가지 못하던 자체 호스트 러너를 위한 수정을 배포하고 조금씩 켰다.
   • 완화 작업에 도움이 되도록 GitHub Enterprise Importer 마이그레이션을 멈췄다.
   • 웹훅으로 시작하는 Actions 워크플로를 전체 처리량으로 되돌렸다.
   • 완화 조치 하나 때문에 오프라인으로 남은 Actions Runner Controller 러너는 손으로 복구했고, 그 변경은 나중에 롤백했다.
   • 재시도도 취소도 되지 않는 작업을 고객이 정리할 수 있는 CLI 와 UI 방법을 GitHub 커뮤니티 토론 글로 공유했다.

   후속 조치

   • 영향받은 서비스의 배포 안전장치와 용량 안전장치를 개선한다.
   • 이번 장애에 앞서 나타난 조건을 잡아내도록 모니터링을 강화한다.
   • 장애가 나도 큐에 쌓인 작업과 러너 배정이 버티고 빨리 복구되도록 개선한다.
   • 다음 Actions Runner 와 Actions Runner Controller 릴리스에 자동 복구를 넣어 손으로 하는 조치가 필요 없게 한다.
   • 대규모 Actions 장애에서 연쇄 장애가 번질 위험을 줄이고 복구를 앞당기는 개선을 더 한다.

   사례 보기
2. IL-0435 Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부해 애플리케이션 오류율이 올랐다

   CyberAgent2026

   증상

   어느 날 갑자기 애플리케이션 오류율이 나빠졌다는 알림이 울렸다. 그 시간대 Aurora MySQL RDS 인스턴스의 오류 로그에는, Aurora MySQL 이 메모리 부족으로 OOM 이 나는 것을 피하려고 커넥션을 끊고 쿼리를 거부한 기록이 남아 있었다.

   오류율 상승메모리 압박

   촉발

   FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스잡과 크론잡

   기여 요인

   기본 설정 방치늦게 드러난 변경

   감지

   애플리케이션 오류율이 나빠졌다는 알림이 울렸다.

   조치

   • Aurora MySQL 파라미터 그룹에서 Performance Schema 를 자동 관리를 뜻하는 0 에서 수동 관리를 뜻하는 1 로 바꾸고, 기본값 -1 로 무제한이던 관련 파라미터 두 개에 상한 100 을 두었다. 적용에는 RDS 인스턴스 재시작이 필요했고, 이 조치로 FreeableMemory 감소와 SwapUsage 발생이 멈췄다.

   교훈

   시스템 알림이 울렸는데 DB 부하 지표가 조용하면 Performance Schema 가 불어난 것도 의심해야 한다. 상한을 둔 두 파라미터는 기본값이 무제한이라 이번처럼 기록이 계속 쌓였다. 상한을 두면 퍼포먼스 인사이트의 호스트별 집계에서 상한을 넘은 호스트의 정보가 빠지는 단점이 있다. 애플리케이션과 Aurora MySQL 사이에 RDS Proxy 를 두어 DB 에 접속하는 HOST 를 일정하게 유지하는 방법도 있다.

   사례 보기
3. IL-0465 IONOS Container Registry 에서 이미지 푸시와 풀이 504 Gateway Timeout 으로 실패했다

   IONOS Cloud2026

   증상

   2026-03-04 에 IONOS Container Registry 고객이 컨테이너 이미지를 푸시하거나 풀할 때 504 Gateway Timeout 오류를 받았다. 레지스트리에 기대는 배포가 막혔다. 상태 페이지에는 09:23 UTC 에 레지스트리의 오류 수가 늘었고 고객이 이미지를 풀하지 못할 수 있다고 처음 올라왔다.

   이미지 풀 실패오류율 상승

   촉발

   마이그레이션 중 일시적인 용량 제약 때문에 중요한 컨트롤 플레인 구성 요소 둘이 같은 프록시 인스턴스에 놓였다. 직접적인 계기는 그 프록시가 동시 연결 한도에 닿아 새 연결을 받지 않은 것이었다.

   원인

   용량 한계

   구성 요소

   컨테이너 레지스트리와 자격 증명관리형 쿠버네티스 컨트롤 플레인과 제공자 API파드 스케줄링과 배치

   기여 요인

   여유 용량 부재단일 장애점한계 경보 부재

   조치

   • 12:22 UTC 에 쿠버네티스 팀이 쿠버네티스 컨트롤 플레인 구성 요소 하나의 버전을 롤백하는 완화책을 배포했다.
   • 프록시 용량을 더 마련했다.
   • 영향받은 컨트롤 플레인 구성 요소를 서로 다른 프록시 인스턴스로 옮겨 부하를 고르게 되돌렸고, 504 오류가 끝났다.

   후속 조치

   • 노드마다 전용 로컬 프록시를 쓰도록 레지스트리와 쿠버네티스 API 사이의 연결을 다시 설계해 공유 프록시 병목을 없앤다. 운영 적용은 2026년 2분기로 잡았다.
   • 프록시 연결 사용률이 한도에 다가가기 전에 경고가 울리도록 알림 기준을 조정한다. 2026년 2분기에 끝낼 예정이다.
   • 인프라 클러스터를 더 배포하고 기존 레지스트리를 다시 나눠, 어느 클러스터도 안전한 운영 용량을 넘지 않게 한다. 사용량이 늘면 자동화가 부하를 계속 고르게 맞춘다.

   사례 보기
4. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.

   PostHog2025

   증상

   2025-10-21 21:45 UTC, 타임아웃 오류를 줄이려는 배포 직후 자동 모니터링이 기능 플래그 서비스의 오류율 상승을 잡았다. 2분 만에 롤백했지만 오류율은 내려가지 않았고, US 데이터센터에서 평가 요청의 약 38% 가 오류를 냈다.

   노드 CPU 고부하오류율 상승지연 시간 증가컨테이너 재시작 반복데이터베이스 과부하

   촉발

   10월 21일에는 증상만 고치려던 타임아웃 처리 배포가 장애를 일으켰다. 28일에는 플래그 서비스와 무관한 일상 배포가 파드 롤아웃을 일으켰고, 이 롤아웃이 장애로 이어졌다. 24일에는 로드밸런서 뒤에서 모든 트래픽을 IP 하나에서 온 것으로 본 레이트 리밋 배포가 장애를 일으켰다.

   원인

   용량 한계

   구성 요소

   노드 풀파드 스케줄링과 배치인메모리 캐시데이터베이스

   기여 요인

   한계 경보 부재재시도 폭주롤백 무효단일 장애점단계적 배포 부재스테이징 불일치

   감지

   21일에는 배포 2분 뒤 자동 모니터링이 오류율 상승을 잡았고, 28일에는 온콜이 높은 오류 수 경보를 받았다. PostHog 는 대부분의 경우 2분 안에 감지했다고 정리했다. 24일에는 429 오류 경보가 없어서 18:10 UTC 부터 들어온 고객 신고로 알았고, 감지까지 62분이 걸렸다. CPU 경보가 아예 없어서 공통 원인인 CPU 포화는 오래 드러나지 않았고, 29일에서 30일 사이 장애는 7시간 넘게 이어졌다.

   조치

   • 10월 21일 타임아웃 처리를 바꾼 배포를 2분 안에 롤백했지만 오류는 멈추지 않았다.
   • 10월 21일 23:00 UTC 부터 연결과 Redis 쓰기를 조절해 23:28 UTC 에 서비스를 복구했다.
   • 10월 28일 롤아웃을 멈추고 US 플래그 파드를 0개로 줄여 Redis 가 회복되기를 기다린 뒤, 파드를 차례로 다시 올렸다.
   • 10월 30일 00:03 UTC 에 하드웨어 변경을 롤백해 오류는 대부분 가라앉혔지만 지연은 남았다.
   • 파드 리소스 요청을 늘리고 쿠버네티스 플릿 크기를 조정해 노드당 파드 수를 줄였다.
   • 로드밸런서와 서비스 사이 Envoy 재시도에 한도를 걸었다.
   • 데이터베이스 연결 타임아웃과 다른 중요한 설정을 런타임 설정으로 옮기고, 타임아웃 값을 피크 부하에 맞게 늘렸다.
   • 노드마다, 파드마다 CPU 사용률이 80% 를 5분 동안 넘으면 온콜을 호출하는 CPU 경보를 추가했다.

   후속 조치

   • 플래그, 수집, 인프라 팀 엔지니어로 전담 팀을 꾸려 애플리케이션과 인프라 전체를 살피고 남은 병목을 찾는다.
   • 플래그 서비스의 Redis 를 본 애플리케이션의 Redis 와 분리하는 방안을 검토한다.
   • ArgoCD 동기화를 다시 켜기 전에 플래그 서비스 차트 설정을 ArgoCD 의 현재 값에 맞추고, 배포 전략과 Redis 전략을 정한다.
   • 플래그 관련 코드의 필수 코드 오너를 기능 플래그 팀으로 정한다.
   • 중요한 플래그 지표와 런북 링크를 한데 모은 대시보드를 만들고, 기능 플래그 런북을 고친다.
   • 기존 서비스 지표와 인프라 지표에 빠져 있는 경보를 추가한다.
   • readiness 검사가 liveness 검사를 그대로 따라 하지 않고, 데이터베이스에 ping 을 보내는 식으로 부하가 걸렸을 때 약해졌던 의존성을 확인하게 바꾼다.
   • 캐시 채우기 작업에 레이트 리밋을 걸어 Redis 에 감당하지 못할 만큼 작업이 몰리지 않게 한다.
   • 연결 풀을 모니터링해 풀이 바닥에 가까워지면 자동으로 요청을 조절하고, 동시 연결 수에 상한을 둔다.
   • 운영 규모의 부하 시험 체계를 만든다.
   • 점진적 롤아웃 기반을 만들어 배포가 미치는 범위를 줄인다.
   • Postgres 에서 Redis 로 가는 데이터 흐름을 문서로 정리하고, 데이터 전송이 한꺼번에 몰릴 때 쓸 런북을 만든다.

   교훈

   가장 큰 교훈은 CPU 크기 산정이었다. 노드가 파드 요청에 비해 작으면 노드 하나에 파드가 너무 많이 몰리고, CPU 포화가 과도한 병렬 처리, 연결 풀 고갈, 느린 쿼리처럼 서로 다른 모습으로 나타난다. 증상만 고친 수정 때문에 21일의 장애가 28일에 되풀이됐다. PostHog 는 CPU 를 넉넉히 받은 파드를 적은 수로 돌리는 편이 낫다고 정리했다. 기능 플래그 서비스와 본 애플리케이션이 Redis 를 같이 쓰면 한쪽 과부하가 다른 쪽을 쓰러뜨리는 단일 장애 지점이 된다. CPU 지표는 처음부터 경보로 걸어야 하고, Postgres 에서 Redis 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기
5. IL-0413 Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다

   Microsoft2025

   증상

   Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.

   간헐적 타임아웃오류율 상승지연 시간 증가

   촉발

   몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다.

   원인

   용량 한계

   구성 요소

   모델 추론 서버

   기여 요인

   모니터링 사각지대

   감지

   논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다.

   조치

   • 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켰다.
   • request batching 과 GPU·CPU 레플리카 수를 조정했다.
   • gRPC backoff 와 오류 매핑을 고쳤다.
   • 샘플링 파라미터에 제한을 두고 클라이언트별 throttling 을 걸었다.
   • 오래 걸리는 요청에서 엔진 연결이 타임아웃 나는 문제에는 스트리밍을 켜고, request batching 을 조정하고, 대기 토큰에 상한을 뒀다. 그 결과 HTTP 408 이 줄고 성공률이 높아졌다.
   • 용량 증설, 트래픽 라우팅, 재시작을 주로 추론 엔진 장애를 완화하는 데 썼다.

   후속 조치

   • 오래 걸리는 요청과 높은 샘플링 조건에 맞게 서빙을 최적화해 타임아웃과 자원 고갈을 줄인다.
   • 헬스 프로브 기반 failover 와 GPU 용량 인지 라우팅을 넓혀, 상태가 나빠진 엔드포인트에서 트래픽이 스스로 빠져나가게 한다.
   • 토큰과 처리량 증가를 예측하고 용량 증설 결정을 자동화해, 완화 시간을 늘리는 수동 핫픽스와 수동 증설을 피한다.
   • 적응형 알림을 배포하고 엔진 수준 텔레메트리를 늘려, 트래픽이 적은 엔드포인트에서, 그리고 오류가 모호하게 변환되는 곳에서 생기는 감지 빈틈을 메운다.

   교훈

   논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.

   사례 보기

원인별1