사례7건

7건 중 1~5번째

1. IL-0158 자격 증명이 만료돼 인증이 실패하면서 모든 리전에서 LKE 와 LKE-E 의 클러스터와 노드를 배포할 수 없었고, 노드 재생성과 오토스케일링도 막혔다.

   Linode2026

   증상

   2026년 4월 16일 11:45 UTC 부터 LKE 와 LKE-E 고객이 클러스터와 노드를 배포하지 못했다. 새 클러스터를 만들거나 기존 클러스터에 노드를 추가할 수 없었다.

   배포 실패노드 증설 실패자격 증명 획득 실패

   촉발

   자격 증명이 만료돼 LKE 와 LKE-E 가 클러스터와 노드를 배포할 때 인증이 실패했다. 상태 페이지의 모니터링 공지에는 원인이 만료된 인증서라고 적혀 있었다.

   원인

   인증서·자격 증명 만료

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   13:20 UTC 에 상태 페이지에 첫 공지가 올라왔다. 모든 리전의 LKE 와 LKE-E 에 영향을 주는 문제를 조사하고 있다는 내용이었다.

   조치

   • 새 자격 증명을 만들어 배포했고, 16:27 UTC 쯤 이 교체로 장애가 완화됐다.

   후속 조치

   • 자격 증명이 만료된 근본 원인을 계속 조사하고 그에 맞는 예방 조치를 한다.

   교훈

   만료된 자격 증명 하나가 모든 리전에서 동시에 새 노드가 필요한 작업을 모두 멈췄다. 새 클러스터 생성, 노드 추가, 노드 재생성, 오토스케일링이 모두 막혔다.

   사례 보기
2. IL-0151 us-east-1 의 Lambda 셀 하나가 처음 겪는 규모로 커지며 잠재 결함이 드러나 Lambda 호출이 실패했고, Lambda 에 기대는 EKS 의 새 클러스터 생성도 오류와 지연을 겪었다.

   Amazon Web Services2023

   증상

   2023년 6월 13일 11:49 AM PDT 부터 us-east-1 리전에서 Lambda 함수 호출의 오류율과 지연이 늘었다. Amazon EKS 에서는 새 클러스터를 만들 때 오류율과 지연이 늘었고, 기존 EKS 클러스터는 영향을 받지 않았다.

   오류율 상승지연 시간 증가자격 증명 획득 실패

   촉발

   트래픽이 평소 하루 패턴 범위 안에서 늘어 10:01 AM 부터 Lambda Frontend 플릿이 확장했고, 11:49 AM 에 셀 하나가 한 번도 도달한 적 없는 용량 임계를 넘었다.

   원인

   소프트웨어 결함

   구성 요소

   서버리스 함수 플랫폼

   기여 요인

   한계 미인지

   감지

   엔지니어링 팀이 곧바로 투입돼 조사를 시작했고, 12:26 PM 에 잠재 결함과 그 결함이 컴퓨트 용량 공급에 준 영향을 찾았다.

   조치

   • 트래픽이 줄어든 것을 확인하고 Lambda Frontend 플릿을 결함이 나타나지 않는 규모로 줄였다.

   후속 조치

   • 장애를 일으킨 Lambda Frontend 플릿의 확장 작업을 곧바로 막았다.
   • 잠재 결함을 고쳐 모든 리전에 배포했다.
   • 셀 확장에서 드러난 시급한 문제에 대응하는 여러 조치를 마쳤다.
   • 모든 셀을 충분히 시험한 크기 안에 묶어 예상하지 못한 확장 문제를 막는 더 큰 작업을 2023년 안에 마친다.

   교훈

   셀 구조여도 셀 하나가 한 번도 겪지 않은 크기로 커지면 잠재 결함이 드러날 수 있다. 이번 장애로 Lambda Frontend 를 확장할 때 셀 구조에 빈틈이 있다는 것이 드러났다. Lambda 함수 호출에 기대는 STS, 콘솔, EKS 같은 서비스도 함께 오류와 지연이 늘었다. EKS 에서는 새 클러스터 생성만 실패했고 이미 돌던 클러스터는 영향이 없었다.

   사례 보기
3. IL-0113 한 번도 교체되지 않은 GKE API 서버 인증서 때문에 메인 클러스터의 컨트롤 플레인이 망가져 EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 멈췄다

   Webhook Relay2022

   증상

   2022년 5월 10일 낮 12시 EST 에 헬스체크 시스템이 경보를 울렸다. EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 내려가 있었다. 처음에는 클라이언트 쪽에서 요청이 끊겼거나, 메모리나 CPU 사용량 때문에 축출된 서버에 요청이 닿은 일시적 오류라고 생각했다. 메인 대시보드가 내려간 것을 보고 바로 대응을 시작했다.

   서비스 중단컨트롤 플레인 지연컨트롤 플레인 무응답API 조회 결과 불일치자격 증명 획득 실패

   원인

   인증서·자격 증명 만료

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버노드 풀RBAC 와 서비스 어카운트

   기여 요인

   디버그 접근 제한단일 장애점

   감지

   헬스체크 시스템이 서비스가 내려갔다는 첫 알림을 보냈다. 팀은 처음에 일시적 오류로 보고 자동 복구를 기대했지만, 메인 대시보드가 내려간 것을 확인하고 바로 대응을 시작했다.

   조치

   • 인증서 교체가 노드를 다시 만들지 않아 13시 20분 노드 풀을 손으로 다시 만들었다.
   • 14시 30분에는 이미 메인 클러스터의 서비스를 새로 만든 GKE 클러스터에 복제하고 있었다.
   • 16시 50분 기존 클러스터에서 쿠버네티스 Service 레코드를 지워 로드 밸런서를 새 클러스터에 붙일 수 있게 했다.
   • 17시 30분 StatefulSet 을 기존 클러스터에서 떼어 내고 모든 쓰기를 메인 디스크로 돌렸다.
   • 18시 30분 임시 ClickHouse 인스턴스의 데이터를 내보내 메인 인스턴스에 다시 넣었다.

   후속 조치

   • 디스크 데이터를 복잡하게 옮기지 않고도 클러스터 사이를 빠르게 바꿀 수 있도록 배포 매니페스트를 고쳤다.

   교훈

   기존 인프라를 살리는 작업에는 시간 상한을 정해야 한다. 장애 내내 서비스가 곧 살아날 것처럼 보였지만, 기존 클러스터를 훨씬 일찍 포기하고 새 클러스터에서 다시 시작했어야 했다. 이미 들인 노력이 아까워 살리기를 멈추지 못한 것이 판단을 늦췄다. 오래된 GKE 클러스터라면 클러스터 CA 인증서의 유효기간을 `gcloud container clusters describe <cluster name> --zone europe-north1-a --format "value(masterAuth.clusterCaCertificate)" | base64 --decode | openssl x509 -text | grep Validity -A 2` 로 확인할 수 있다.

   사례 보기
4. IL-0521 AKS 클러스터의 Azure 서비스 주체 자격 증명이 만료돼 파드가 볼륨을 마운트하지 못함

   Jenkins project2021

   증상

   2021년 6월 2일 18:02 UTC 부터 Jenkins 인프라의 AKS 클러스터에서 파드가 볼륨을 마운트하지 못한다는 오류와, 스케일 업으로 늘어난 노드가 CNI 에서 네트워크 가상 인터페이스를 받지 못한다는 오류가 나타나기 시작했다.

   자격 증명 획득 실패파드 ContainerCreating 정체

   촉발

   2021년 6월 2일 17:53 UTC 에 AKS 노드가 Azure API 인증에 쓰는 Azure 서비스 주체 자격 증명이 만료됐다.

   원인

   인증서·자격 증명 만료

   구성 요소

   클러스터의 클라우드 자격 증명영구 볼륨과 스테이트풀셋CNI 플러그인노드 풀

   기여 요인

   모니터링 사각지대

   감지

   LTS 2.289.1 릴리스 문제의 근본 원인을 조사하던 엔지니어가 AKS 콘솔 화면에서 오류를 확인했다.

   조치

   • 인프라 팀이 서비스 주체 자격 증명을 갱신했다. 그러자 AKS 가 모든 노드를 재시작하는 작업을 자동으로 시작했고, 이 작업은 멈출 수 없었다.

   후속 조치

   • 인증서 만료 점검처럼, 서비스 주체 만료 일주일 전에 PagerDuty 알림을 울리는 자동 점검을 더한다.
   • 자격 증명 재설정 같은 수동 작업 일정을 적어 둘 팀 공용 캘린더를 마련한다.
   • 서비스 주체 대신 자동으로 갱신되는 Azure managed identity 를 쓰는 방안을 검토한다.

   사례 보기
5. IL-0460 Vault 가 만료된 TLS 인증서를 계속 써서 Vault 에 기대는 서비스 파드가 연쇄로 죽고 GoCardless 서비스 전체가 22분간 멈췄다

   GoCardless2020

   증상

   07:32 에 자동 모니터링이 장애를 잡아 온콜 엔지니어를 호출했다. 07:31 부터 GoCardless API 로 가는 요청이 전부 실패했고, 대시보드, 결제 페이지, 파트너 연동을 거치는 작업도 쓸 수 없었다. 07:32 부터 07:54 GMT 까지 22분 동안 서비스 전체가 멈췄다.

   서비스 중단컨테이너 재시작 반복TLS 인증서 오류자격 증명 획득 실패

   촉발

   cert-manager 가 Vault 의 TLS 인증서를 갱신했지만 Vault 는 새 인증서를 다시 읽지 않고 옛 인증서를 계속 썼다. 07:22 에 그 옛 인증서가 만료됐다.

   원인

   인증서·자격 증명 만료

   구성 요소

   cert-manager시크릿 저장소

   기여 요인

   단일 장애점모니터링 사각지대미검증 가정수동 조치 악화

   감지

   07:32 에 자동 모니터링이 장애를 잡아 온콜 엔지니어를 호출했다.

   조치

   • 07:42 에 인증서가 만료됐다고 보고 cert-manager 가 인증서를 다시 만들도록 손으로 강제했다. 실제로 인증서는 이미 갱신돼 있어 이 단계는 필요 없었다.
   • 07:48 에 새 인증서가 만들어지자 Vault 가 그 인증서를 읽도록 Vault 클러스터를 손으로 재시작했다.
   • 중요한 워크로드의 파드 몇 개를 직접 삭제해 5분까지 늘어난 지수 백오프를 건너뛰었고, 서비스가 몇 분 일찍 완전히 돌아왔다.

   후속 조치

   • L7 로드 밸런서에만 있던 TLS 인증서 만료 모니터링을 Vault 가 쓰는 단순 TCP 로드 밸런서까지 넓히고, Blackbox exporter 로 그 인증서도 주기적으로 검사한다.
   • Vault 서버가 바뀐 인증서를 스스로 다시 읽는 기능이 없으므로, Reloader 컨트롤러를 배포해 인증서 데이터가 바뀌면 Vault 를 롤링 업데이트한다.
   • Vault 로 가는 네트워크 분할 같은 다른 장애가 실행 중인 서비스에 번지지 않도록, theatre-envconsul 을 바꿔 envconsul 이 자식 프로세스를 관리하지 않게 하고 컨테이너 시작 때 비밀 환경 변수를 넣는 일만 하게 한다.

   교훈

   Vault 를 쓸 수 없게 된 것보다 Vault 에 기대는 모든 애플리케이션이 거의 곧바로 실패한 것이 훨씬 나빴다. 이런 장애 상황을 충분히 시험하지 않았고, 단일 장애점과 피해 범위를 줄여야 한다는 것을 장애를 겪고서야 다시 확인했다. 대응 중에는 인증서 자체가 만료됐다고 여겨 인증서를 다시 만들게 했다. 실제로는 인증서가 이미 갱신돼 있었고 Vault 가 다시 읽지 않았을 뿐이었다. 그래서 DNS 검증 때문에 몇 분 걸리는 이 단계는 건너뛸 수 있었다.

   사례 보기

원인별4