사례13건

13건 중 3~7번째

1. 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분기에 끝낼 예정이다.
   • 인프라 클러스터를 더 배포하고 기존 레지스트리를 다시 나눠, 어느 클러스터도 안전한 운영 용량을 넘지 않게 한다. 사용량이 늘면 자동화가 부하를 계속 고르게 맞춘다.

   사례 보기
2. IL-0063 Redis 스테이트풀셋을 다시 만들자 Redis 클러스터가 한꺼번에 재시작되며 일부가 망가졌고, 재연결 폭주로 백엔드가 OOM 으로 죽어 AdGuard VPN 이 약 50분 멈췄다.

   AdGuard VPN2025

   증상

   8:10 UTC 에 팀은 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 그대로 두고 스테이트풀셋 객체만 지우는 방식이다. 스테이트풀셋을 다시 만들자 쿠버네티스가 8:10 부터 8:15 UTC 사이에 스테이트풀셋 전체를 빠르게 재시작했다. 처음에는 백엔드 서비스가 Redis 연결 오류를 냈지만 서비스 전체가 곧바로 무너지지는 않았다.

   서비스 중단OOMKilled프로브 실패지연 시간 증가

   촉발

   팀은 디스크를 온라인으로 늘린 뒤 Git 의 선언적 설정을 실제 상태와 맞추려고 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 남기고 스테이트풀셋 객체만 지우는 방식이다. 그다음 늘린 크기를 적은 저장소 템플릿으로 스테이트풀셋을 다시 만들었다.

   원인

   설정 변경

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시컨테이너 메모리 한도

   기여 요인

   헬스 프로브 부재미검증 가정단일 장애점재시도 폭주여유 용량 부재

   감지

   Redis 클러스터 여러 인스턴스의 디스크 여유 공간이 바닥나고 있다는 알림이 시작이었다. 그 뒤의 장애는 스테이트풀셋을 다시 만든 직후 백엔드 서비스가 Redis 연결 오류를 내면서 드러났다.

   조치

   • 망가진 Redis 클러스터를 손으로 복구했다. 마스터에서 쓸모없어진 노드 ID 를 지우고, 해당 레플리카를 리셋한 뒤 클러스터에 다시 붙이고 복제가 따라잡기를 기다렸다.
   • 실제로 메모리가 바닥난 구성 요소를 찾아낸 뒤, 백엔드 서비스를 확장하고 그 구성 요소의 메모리 한도를 올렸다.
   • 프로브를 잠시 느슨하게 해, 백엔드 인스턴스가 ready 와 not ready 를 오가지 않고 바로 트래픽을 받게 했다.
   • 10:00 UTC 에 임시 조치를 되돌렸다.

   후속 조치

   • 빠져 있던 스타트업 프로브를 넣는다. 데이터셋을 다 읽기 전에는 파드를 ready 로 표시하지 않는다.
   • 재시작한 파드가 옛 마스터 IP 주소에 묶여 있을 때 쓸 수 있도록 Redis 용 자체 컨트롤 플레인을 만든다.
   • 서비스 전체의 단일 장애점이 된 이 Redis 클러스터 의존을 줄인다. 중요한 정보 일부를 서버마다 따로 둔 Redis 클러스터 같은 다른 데이터 저장소로 옮기고, 백엔드 일부 구성 요소에 Kafka 를 쓰기 시작한다.

   교훈

   장애를 일으킨 것은 디스크 확장이 아니라 상태를 맞추려고 컨트롤러 객체를 다시 만든 단계였다. 고칠 수 없는 필드가 있으면 객체를 통째로 바꾸는 위험한 방법을 쓰게 된다. 그렇게 바꾸면 쿠버네티스가 워크로드를 넓은 범위에서 다시 조정할 수 있다. 스타트업 프로브와 엄격한 레디니스 프로브가 있어야 롤링 재시작이 현재 파드가 정말 준비될 때까지 기다린다. 이번 장애에서 가장 뼈아픈 것은 프로브가 없었다는 점이다. 분산 클러스터가 다시 붙고 복제를 따라잡는 데는 시간이 걸리므로, 의존하는 서비스는 그동안 기능을 줄여서라도 버티도록 설계해야 한다.

   사례 보기
3. IL-0101 자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.

   Wealthy2025sev1

   증상

   2025년 9월 14일, 이미 떠 있던 노드는 계속 돌았지만 새로 만들어지는 노드는 하나도 클러스터에 제대로 들어오지 못했다. 스팟 인스턴스에서 돌던 백그라운드 워커, 리포트 서비스, 주문 할당 시스템이 완전히 멈췄다. API 는 기존 노드에서 계속 응답했지만 부하가 늘어도 확장할 수 없었다.

   노드 증설 실패컨테이너 재시작 반복서비스 중단DNS 조회 실패

   촉발

   노드 풀의 자동 업그레이드를 꺼 두었는데도 Google 이 버전 지원 종료 기한을 이유로 컨트롤 플레인을 v1.32.x 에서 v1.33.2 로 강제 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   GKE 컨트롤 플레인노드 풀클라이언트 쪽 DNS 리졸버와 캐시영구 볼륨과 스테이트풀셋컨피그맵과 시크릿

   기여 요인

   미뤄 둔 업그레이드단일 장애점롤백 무효여유 용량 부재

   조치

   • 강제 업그레이드와 같은 버전인 v1.33 으로 새 GKE 클러스터를 만들었다.
   • 쿠버네티스 1.33 과 호환되도록 Istio 를 1.27.1 로 올렸다.
   • 쿠버네티스 1.33 에 맞게 cert-manager 설정을 갱신했다.
   • 모든 운영 워크로드를 새 클러스터로 옮기고, 파드 스케줄링, DNS 조회, PVC 마운트, 외부 연동이 정상인지 확인했다.
   • 손상된 기존 클러스터를 폐기했다.

   후속 조치

   • 모든 클러스터를 GKE stable 릴리스 채널로 설정한다.
   • 2025년 4분기까지 Argo CD 와 모니터링 같은 관리용 구성 요소를 따로 돌리는 관리 클러스터를 만든다.
   • 중요한 워크로드의 스팟 인스턴스 사용을 다시 검토하고, 온디맨드 대체 노드 풀을 추가한다.
   • SRE 업그레이드 절차를 문서로 남긴다. 관리 클러스터를 먼저 올리고, 며칠 동안 지켜본 뒤 운영 클러스터를 올린다.
   • 쿠버네티스, Istio, cert-manager 사이의 호환 표를 문서로 남긴다.
   • 업그레이드를 자동으로 시험하는 파이프라인을 만든다.
   • 빠르게 이전할 수 있도록 고정 IP 를 예약해 둔다.
   • Istio, cert-manager, CSI, DNS 애드온의 버전을 고정한다.
   • 지원 종료 기한에 몰리지 않도록 stable 릴리스를 따라 제때 올리고, GKE 알림과 공지를 정기적으로 확인한다.

   교훈

   Google 은 자동 업그레이드를 꺼 두어도 버전 지원 종료 기한이 되면 컨트롤 플레인을 강제로 올린다. 강제 업그레이드를 피하려면 지원 버전 범위 안에 머물러야 한다. 기존 노드가 멀쩡해도 새 노드 초기화는 완전히 실패할 수 있다. 선점된 스팟 노드가 클러스터에 돌아오지 못하면 장애가 연쇄로 번진다. 컨트롤 플레인을 올린 뒤 노드 초기화가 되돌릴 수 없게 망가지면 클러스터를 통째로 다시 만들어야 할 수도 있다. 예측할 수 있고 검증된 릴리스 주기를 원하면 GKE stable 채널을 쓴다. 쿠버네티스를 올릴 때는 Istio, cert-manager 같은 의존 구성 요소를 함께 맞춰야 한다. 같은 클라우드에 대기 클러스터가 없으면 바로 넘어갈 곳이 없다. SRE 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.

   사례 보기
4. IL-0542 Twingate 의 인증과 인가 요청 일부에서 약 30분 동안 오류율이 올라갔다

   Twingate2025

   증상

   Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.

   오류율 상승

   촉발

   GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서GKE 컨트롤 플레인수평 파드 오토스케일러클러스터 오토스케일러

   기여 요인

   재시도 폭주여유 용량 부재장애 중첩수동 조치 악화

   감지

   사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다.

   조치

   • 앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다.

   후속 조치

   • 예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다.
   • HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다.
   • 클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다.
   • HPA 가 더 빨리 확장하도록 설정했다.

   사례 보기
5. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

   UK Ministry of Justice2025

   증상

   2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

   파드 축출파드 Pending서비스 중단업그레이드 정체

   촉발

   EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

   원인

   배포 결함

   구성 요소

   디스케줄러노드 풀클러스터 오토스케일러

   기여 요인

   여유 용량 부재한계 경보 부재기본 설정 방치

   감지

   팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

   조치

   • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
   • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
   • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
   • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.

   후속 조치

   • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
   • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
   • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
   • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
   • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
   • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

   사례 보기

원인별7