사례6건

6건 중 3~6번째

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

   Twingate2025

   증상

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

   오류율 상승

   촉발

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

   원인

   클라우드 제공자 장애

   구성 요소

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

   기여 요인

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

   감지

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

   조치

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

   후속 조치

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

   사례 보기
2. IL-0364 'default' 인그레스 컨트롤러로 들어오는 트래픽의 25% 가 느려졌다

   UK Ministry of Justice2022

   증상

   2022-07-11 09:33 에 사용자들이 #ask-cloud-platform 에 애플리케이션이 가끔 느리다고 알렸다. 영향을 받은 것은 인그레스 트래픽의 25% 였다.

   지연 시간 증가간헐적 타임아웃

   촉발

   AWS 에서 헬스 체크 인스턴스 일부가 재시작될 때 잠재해 있던 소프트웨어 경쟁 상태가 드러났다. 그 뒤 NLB 의 헬스 체크 하위 시스템이 한 가용 영역에 있는 대상을 알지 못하게 됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러

   기여 요인

   –

   감지

   사용자들이 #ask-cloud-platform 에 애플리케이션이 가끔 느리다고 알렸다. 첫 감지는 09:33 이었고 사고 선언은 10:11 이었다.

   조치

   • AWS 가 헬스 체크 하위 시스템을 재시작해 대상 목록을 새로 읽게 했고, 그 뒤 영향을 받은 가용 영역의 NLB 가 돌아왔다.

   후속 조치

   • 사고 뒤 검토에서 정한 완화 작업을 ministryofjustice/cloud-platform 저장소에 post-aws-incident 이슈로 올렸다.

   사례 보기
3. IL-0446 ECS 서비스에 배포한 직후 요청의 20% 쯤이 ALB 의 5XX 를 받았고, 오류는 ap-northeast-1d 에서만 나는 것처럼 보였다

   ITANDI2020

   증상

   운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟았다. 분당 1만 건쯤 요청을 받는 서비스에서 요청의 20% 쯤이 5XX 를 받았고, 같은 때 타깃 연결 오류도 났다.

   오류율 상승

   촉발

   CircleCI 와 Terraform 으로 운영 ECS 에 배포해 ECS 태스크가 다시 만들어졌고, 그 시점에 ELB 와 백엔드 사이의 통신이 불안정해졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서Amazon ECS

   기여 요인

   –

   감지

   팀은 운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟은 것을 보고 알았다.

   조치

   • ECS 태스크를 가장 먼저 재시작했지만 복구되지 않았다.
   • ELB 의 서브넷 가운데 1d 를 같은 1d 의 다른 서브넷으로 바꿨다. dig 로 ELB 이름을 조회해 IP 가 바뀐 것을 확인했지만 해결되지 않았다.
   • ECS 서비스 설정을 바꿔 ECS 태스크 15개 가운데 1d 에서 돌던 6개를 1a 와 1c 로 옮겼지만 해결되지 않았다.
   • 1d 에서 도는 ECS 태스크가 없어진 뒤 ELB 에서 1d 서브넷을 뺐지만 복구되지 않았다.
   • 배포로 ECS 태스크가 무거워져 ELB 와 백엔드 사이에 타임아웃이 났을 가능성을 보고 ELB 의 유휴 타임아웃 설정을 바꿨지만 복구되지 않았다.
   • ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다.
   • VPC, 서브넷, 백엔드, SecurityGroup 이 옛 ELB 와 똑같은 새 ELB 를 만들었다.
   • ECS 서비스 하나에 ELB 여러 개를 붙일 수 있으므로 ECS 서비스에 새 ELB 를 함께 붙였다.
   • 서비스의 호스트 존에 옛 ELB 를 가리키는 레코드와 같은 레코드를 새 ELB 쪽으로 하나 더 만들었다. 두 레코드에 가중치를 줘서 트래픽의 1/10 만 새 ELB 로 보냈다.
   • 새 ELB 에서 ELB_5XX 가 하나도 나오지 않아 옛 ELB 에 문제가 있다고 보고 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다.

   교훈

   네트워크 구성상 있을 수 없는 그래프가 보이면 AWS 쪽도 의심해 봐야 한다.

   사례 보기
4. IL-0494 DDoS 중 호스팅 사업자가 중앙 로드 밸런서 IP를 null route 해 A 레코드로 Netlify를 가리킨 사이트가 응답하지 않았다

   Netlify2016

   증상

   2016-08-22 월요일 오전 8시 PST에 Netlify 중앙 로드 밸런서가 응답하지 않는다는 알림이 왔다. 로드 밸런서의 공개 IP로 가는 트래픽은 서버에 닿기 전에 멈춘 채 응답이 없었다.

   네트워크 도달 불가

   촉발

   DDoS 트래픽이 Rackspace 시카고 데이터센터에 있던 Netlify 중앙 로드 밸런서로 몰렸고, Rackspace가 그 로드 밸런서의 IP를 null route 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서

   기여 요인

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

   감지

   2016-08-22 월요일 오전 8시 PST에 중앙 로드 밸런서가 응답을 멈췄다는 알림을 받았다. 이틀 전 토요일 밤에는 로드 밸런서의 트래픽 패턴에서 들어오는 전송량 급증을 먼저 알아챘다.

   조치

   • Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 서버 클러스터를 띄우기 시작했다.
   • 새 CDN 클러스터가 준비되자 지원 채널로 연락해 온 고객에게 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 알리고, 네이키드 도메인을 되살리도록 A 레코드를 바꾸게 안내했다.
   • 새 IP가 안정적인 해법이라고 확신한 뒤 문서 페이지를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다.

   후속 조치

   • Google 기반의 새 네트워크 IP를 계속 운영한다.
   • Netlify CDN과 밀접하게 통합된 자체 DNS 호스팅을 내놓는다. Netlify DNS를 쓰면 중간 CNAME이나 A 레코드 없이 사용자를 가장 가까운 활성 CDN 노드로 보낸다.
   • 상태 페이지 게시 과정을 고쳐 앞으로 문제가 생기면 상태 페이지가 바로 갱신되게 했다.
   • 장애 때 유료 고객 모두에게 대상을 골라 메일을 빨리 보낼 수 있는 메일 발송 도구를 만든다.

   교훈

   관리형 로드 밸런서를 쓰는 한 DDoS 대응은 Netlify가 손댈 수 없었다. Rackspace의 로드 밸런서는 DDoS 공격에 너무 약했고 DDoS 대응 절차도 함께 일하는 다른 클라우드 사업자에 못 미쳤다. 결국 도메인을 DDoS 장애에서 지키는 유일한 방법은 그 도메인에 고정 IP 주소를 아예 드러내지 않는 것이다. 단일 IP에 기대지 않고 www 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다.

   사례 보기

원인별1