그래프
사례5건
5건 중 1~5번째
- 증상
2024년 11월 12일 8:47 AM UTC 에 편집기 새 버전을 배포한 뒤, 아시아의 많은 사용자에게 편집기의 객체 패널이 끝없이 로딩 상태로 남았다. 9:08 AM UTC 부터는 canva.com 자체가 열리지 않았다.
- 촉발
2024년 11월 12일 8:47 AM UTC 에 Canva 편집기 새 버전이 배포돼 클라이언트들이 새 정적 자산을 받기 시작했다. 같은 시각 Cloudflare 의 싱가포르와 애슈번 사이 경로에서 패킷이 손실돼 JavaScript 파일 하나의 전송이 20분 동안 끝나지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 임시 Cloudflare 방화벽 규칙을 넣어 CDN 에서 모든 트래픽을 막고, 새 API Gateway 태스크가 요청을 받지 않은 상태에서 뜨게 했다.
- canva.com 을 상태 페이지로 돌려 사용자에게 장애 중임을 알렸다.
- 엄격한 속도 제한을 건 오스트레일리아 사용자부터 시작해 canva.com 트래픽을 조금씩 되살렸다.
- 후속 조치
- 트래픽을 세밀하게 돌리고 막은 뒤 단계적으로 다시 늘리는 내부 런북을 만든다.
- canva.com 을 쓸 수 없을 때 사용자에게 더 자세한 오류 페이지를 보여 준다.
- API Gateway 의 기본 태스크 수와 태스크 하나에 주는 메모리를 늘린다.
- 비슷한 트래픽 패턴에서 실패할 위험을 줄이는 부하 차단 규칙을 API Gateway 에 더한다.
- API Gateway 에 정기 부하 테스트를 들인다.
- 텔레메트리 라이브러리의 스레드 잠금 버그를 고치는 패치를 배포한다.
- 텔레메트리 라이브러리의 마이크로벤치마크 테스트에 스레드 경합을 일으킨 코드 경로의 멀티스레드 테스트를 더한다.
- 페이지 자산 카나리 릴리스에서 JavaScript 오류율에 더해 페이지 로드 완료 이벤트를 보조 지표로 본다.
- 카나리에 롤아웃 단계를 하나 더 두어 단계적 배포 중 문제를 찾을 시간을 늘리는 실험을 한다.
- 사용자 요청이 자산을 너무 오래 기다리지 않도록 자산 받기에 타임아웃을 둔다.
- Cloudflare 와 함께 이번 사고에서 여러 시스템이 어떻게 얽혀 작용했는지 자세히 파악한다.
IL-0339Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다Microsoft Azure2024- 증상
2024년 7월 30일 11시 45분 UTC 부터 Azure Front Door 와 Azure CDN 을 거치는 Microsoft 서비스에 접속하던 일부 고객이 간헐적인 연결 오류, 타임아웃, 지연 급증을 겪었다. 11시 47분에 Azure Portal 팀이 먼저 서비스 성능 저하를 알아챘다.
- 촉발
Azure 네트워크 DDoS 보호 서비스가 TCP SYN flood DDoS 공격을 자동으로 막은 뒤 트래픽을 Azure Front Door 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 2분 뒤인 11시 47분 UTC 에 Azure Portal 팀이 서비스 성능 저하를 알아채고 조사를 시작했다. 12시 10분에 네트워크 모니터링이 이 포털 장애를 유럽의 한 사이트에서 난 네트워크 문제와 연결 지었다.
- 조치
- 12시 55분 UTC 에 국지적인 혼잡을 확인하고, 트래픽 경로 변경을 포함한 혼잡 완화용 표준 플레이북을 실행했다. 13시 58분에 영향 대부분이 사라졌다.
- 16시 58분, 네트워크 컨트롤 플레인이 명령을 다시 내리게 했지만 문제의 장비에는 명령이 닿지 않았다.
- 17시 50분부터 문제의 장비를 네트워크에서 안전하게 빼면서 다른 문제가 없는지 네트워크를 훑었다. 장비는 19시 32분에 다 뺐다.
- 후속 조치
- 한 지역의 DDoS 완화 문제가 다른 지역으로 번지지 않도록, 네트워크 장비에 빠져 있던 설정을 넣었다. 이 일은 끝났다.
- 잘못된 설정을 찾아내도록 Azure 네트워크의 기존 검증과 모니터링을 강화한다. 2024년 11월에 끝낼 예정이다.
- DDoS 보호 서비스가 컨트롤 플레인에서 닿지 않는데도 트래픽을 계속 받는 상황을 잡아내도록 모니터링을 개선한다. 2024년 11월에 끝낼 예정이다.
- 증상
2023년 11월 17일 금요일 오전, 지방자치단체가 쓰는 지방행정전산서비스와 정부24가 멈췄다. 장애 당시 로그를 보면 통합인증서버의 네트워크 세션이 비정상 상태였다. 네트워크 장비인 L4 장비가 비정상 상태로 바뀌었다는 로그도 여러 번 반복해 남았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 11월 18일 04시에 정상 작동하지 않던 L4 장비를 고성능 장비로 바꾸고, 기능 테스트와 부하 테스트로 안정성을 확인한 뒤 오전 9시에 정부24 서비스를 다시 열었다.
- 대전센터 라우터 중 광주센터와 연결된 포트의 불량을 찾아, 11월 19일 오전 7시에 다른 포트로 연결을 옮겨 지연을 없앴다.
- 정부 서비스를 다시 연 다음 날 아침에 문제가 생긴 라우터의 모듈을 바꿔 끼웠다.
- 후속 조치
- 비슷한 포트 불량이 있을 수 있는 오래된 장비를 전수 점검한다.
- 국민에게 장애 상황을 빨리 알리지 못한 문제를 풀기 위해 장애가 났을 때의 처리 매뉴얼을 보완한다.
- 여러 수단을 써서 장애로 멈춘 서비스의 복구 상황을 빠르게 알린다.
- 장애 징후를 빨리 잡도록 중요 서비스 시스템과 연관 장비를 함께 보는 통합 모니터링 체계를 만든다.
- 상설 장애대응반을 꾸려 중요 장애에 투입해 문제를 일찍 해결한다.
- 핵심 디지털정부 서비스가 멈춘 상황에서도 행정서비스를 제공할 수 있도록 행정조치 방안을 마련하고 대응 매뉴얼을 만든다.
- 국가전산망 마비를 재난과 사고의 유형으로 명시해 예방부터 복구까지 체계적으로 관리한다.
- 여러 정보시스템이 연계된 환경에 맞는 위기대응체계를 만들고, 이를 총괄하는 범정부 장애 예방·대응 컨트롤타워를 강화한다.
- 공공정보화사업의 추진 절차와 사업관리체계를 고치고, 내용연수가 지나 잠재적 위험이 높은 하드웨어와 소프트웨어를 빨리 교체하며, 기술력 높은 기업이 참여할 수 있게 사업대가를 현실화한다.
- 정보시스템 개발과 운영을 외주용역에 기대는 지금의 체계를 고치고, 디지털 분야의 우수한 인재가 정부에 들어오게 한다.
- 국가정보자원관리원에 입주한 시스템의 이중화, 재복구 시스템, 네트워크 구성 같은 기술 구조를 전면 검토하고, 조직 진단으로 조직 구성과 인사 운영의 개선 방안을 마련한다.
- 제조사와 협의해 장비 안의 부품 고장을 더 일찍 발견하고 모니터링하는 체계를 만든다.
- 교훈
라우터 장비의 기본 모니터링은 하고 있었고 전산실에서는 매일 눈으로도 점검했지만, 이번 문제는 모듈 안의 특수한 부분에서 생겨 미리 잡아내지 못했다. 이중화는 장비 하나가 완전히 작동하지 않을 때 다른 장비가 대신하는 구조여서, 모듈 일부만 고장 난 이번 경우에는 제대로 작동하지 않았다. 고장 난 포트가 전체 서비스에 영향을 주는 위치에 있어 파급이 컸다. 장애가 L4 장비의 OS 업데이트 바로 뒤에 나서 업데이트가 원인처럼 보였지만, OS 를 되돌린 뒤에도 같은 문제가 나서 원인이 아닌 것으로 드러났다.
- 증상
2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.
- 촉발
2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.
- 조치
- node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
- AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
- SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.
- 후속 조치
- Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.
- 교훈
gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.
- 증상
2021년 5월 seek.com.au 에서 구직 검색을 하던 일부 사용자가 오류를 받았고, 장애는 16분 이어졌다. SEEK 는 검색 트래픽을 처리하던 피어링 연결을 Transit Gateway 로 옮기던 중이었고, 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.
- 촉발
SEEK 는 VPC 피어링 연결에서 Transit Gateway 로 옮기는 절차의 둘째 단계로 첫 VPC 의 라우팅 테이블만 Transit Gateway 를 쓰게 바꿨다. 이 상태에서는 VPC A 에서 나가는 패킷은 피어링 연결로, VPC B 에서 나가는 패킷은 Transit Gateway 로 가서 오가는 경로가 달라졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
마이그레이션 도중 SEEK 는 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.
- 조치
- 검색이 동작하지 않는 것을 보고 피어링 연결에서 Transit Gateway 로 옮기던 마이그레이션을 롤백했다.
- 후속 조치
- SEEK 환경의 EC2 인스턴스 MTU 를 8500 으로 낮춰 8500 바이트보다 큰 패킷을 보내지 않게 한다. Amazon Linux 2 에서는 네트워크 인터페이스가 올라올 때마다 인터페이스 이름을 인자로 받아 실행되는 /sbin/ifup-local 스크립트를 두어 인스턴스의 기본 MTU 를 8500 으로 덮어쓴다.
- 교훈
SEEK 는 피어링 연결과 Transit Gateway 의 MTU 가 다르다는 중요한 정보를 마이그레이션 전에 알지 못했다. Transit Gateway 가 큰 패킷을 알리지 않고 버린다는 사실은 AWS 의 Transit Gateway 할당량 문서에 적혀 있었지만, SEEK 는 이것이 할당량이라기보다 더 찾기 쉬운 곳에 있어야 할 기본 정보라고 봤다. SEEK 는 이 장애로 MTU, MSS, AWS 관리형 네트워크 장비의 세부 동작을 많이 배웠다. 장애에서 얼마나 배우는지는 장애의 심각도보다 근본 원인을 이해하려는 호기심과 의지에 달려 있다고 보았다.
이 5건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, API 게이트웨이. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.