Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례24건

24건 중 24~24번째

  1. 증상

    사쿠라 클라우드에서 사용자 서버를 수용한 호스트 서버와 스토리지 장치 사이의 통신이 되풀이해 끊겼다. 포트 전환 때문에 끊길 때는 한 번에 5분 정도 끊겼다. 이 끊김은 2011년 12월부터 간헐적으로 되풀이됐다.

    촉발

    2011년 11월 15일 서비스를 시작한 뒤 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘었고, 스토리지 장치의 네트워크 인터페이스에서 패킷 손실이 나기 시작했다.

    원인
    구성 요소
    기여 요인
    조치
    • 1월 초 스토리지 장치 네트워크 인터페이스의 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔, 물리적으로 링크가 내려갔을 때만 예비 포트로 전환되게 했다.
    • 1월 초 Subnet Manager 의 확인 방식을 보통 모드에서 heavy sweep 모드로 바꿔 스토리지 장치가 네트워크에서 떨어지는 문제를 없앴다.
    • 3월 19일 스토리지 장치의 펌웨어를 업데이트해 장치의 패킷 손실을 없앴다.
    • 스토리지 부하를 줄이려고 3월 12일 두 번째 스토리지 장치를 더했고, 옮길 수 있는 서버를 두 번째 장치로 옮겨 부하를 나눴다.
    후속 조치
    • 기존 스토리지를 자체 개발한 전혀 다른 새 스토리지 장치로 바꾼다.
    • 새 스토리지는 장치의 최대 수용 대수에 맞는 테스트 환경을 준비해 실제로 부하를 걸어 시험했다. 유료 정식 서비스 전에 다시 무료 베타 테스트 기간을 두고, 사용자가 만족할 때까지 시험을 되풀이한다.
    • 새 스토리지의 네트워크 인터페이스 드라이버 같은 부품은 지금까지 운영에서 문제가 없던 호스트 서버와 같은 것을 썼다.
    • 새 스토리지는 사쿠라인터넷이 직접 관리하고 운영할 수 있도록 자사 엔지니어가 개발했다.
    교훈

    사쿠라인터넷은 스토리지 장치의 선정과 검증 과정에 큰 문제가 있었다고 돌아봤다. 검증 때는 설계 사양에 맞는 최대 수용 대수만큼 서버를 준비하지 못하고, 예측으로 만든 부하로 성능을 확인했다. 그래서 성능 한계에서 하는 시험이 부족했고, 실제 운영에서 난 문제에 빠르고 정확하게 대응하지 못했다. InfiniBand 포트의 패킷 손실은 펌웨어 업데이트로 풀렸지만 대응을 마치기까지 석 달이 걸렸다. 자사 엔지니어가 스토리지 장치의 사양과 동작을 다 파악하지 못해서, 제조사와 긴밀히 협력했어도 조사와 확인에 오랜 시간이 걸렸다.

내 클러스터에도 있는지 확인하기

이 24건에서 가장 많이 나오는 구성 요소: BGP 라우팅, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별9

설정 변경5건

  1. IL-0394 Cloudflare Miami 라우터가 내부 IPv6 경로를 BGP 피어와 트랜짓 제공자에게 유출해 25분 동안 백본이 혼잡해지고 트래픽이 드롭됐다
  2. IL-0339 Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다
  3. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.
  4. IL-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다
  5. IL-0361 VPC 피어링을 Transit Gateway 로 옮기던 중 seek.com.au 의 구직 검색이 16분 동안 오류를 냈다
    SEEK2021

용량 한계5건

  1. IL-0564 Linode 의 Miami, Milan, Sao Paulo 데이터센터에서 패킷 손실로 서비스 성능이 떨어졌다
    Linode2025
  2. IL-0341 Cloudflare 와 AWS us-east-1 사이 링크가 혼잡해져 그 리전에 오리진을 둔 고객이 높은 지연과 패킷 손실을 겪었다
  3. IL-0440 파드가 보낸 DNS 쿼리 패킷이 노드에서 버려져 클러스터 내부 서비스의 이름 조회가 no such host 와 i/o timeout 으로 자주 실패했다
    Cybozu2024
  4. IL-0386 Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다
  5. IL-0537 사쿠라 클라우드의 호스트 서버와 스토리지 장치 사이 연결이 몇 달 동안 되풀이해 끊겼다

운영 실수1건

기여 요인
조직
  1. IL-0348 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 끊기고 여러 제품이 오래 불안정했다

의존성 장애2건

  1. IL-0257 한꺼번에 몰린 요청에 API Gateway 태스크가 모두 OOM 으로 종료돼 canva.com 이 약 50분 동안 열리지 않았다
    Canva2024
  2. IL-0358 Packet 공용 클라우드의 여러 리전에서 라우팅 루프와 블랙홀로 연결이 간헐적으로 끊겼다
    Packet2019

소프트웨어 결함4건

  1. IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다
  2. IL-0529 모든 Google Cloud 존에서 VPC 컨트롤러가 꺼져 새로 만든 VM 과 여러 제품의 새 인스턴스가 네트워크 없이 올라왔다
  3. IL-0336 도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다
  4. IL-0222 유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.

배포 결함3건

  1. IL-0293 us-central1 의 Cloud Bigtable 에서 지연과 연결 오류가 32시간 동안 이어졌다
  2. IL-0530 us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다
  3. IL-0532 Azure Software Load Balancer 뒤의 백엔드가 15개를 넘는 로드 밸런서에서 연결이 간헐적으로 끊기고 패킷이 사라졌다

하드웨어 고장1건

  1. IL-0540 센터 사이를 잇는 라우터의 포트에서 큰 패킷이 유실돼 지방행정전산서비스와 정부24가 하루 넘게 멈췄다

클라우드 제공자 장애1건

조직
  1. IL-0220 연휴 뒤 첫 업무일에 AWS Transit Gateway 가 패킷을 버려 Slack 웹 계층이 포화되고 Slack 을 한동안 쓸 수 없었다.
    Slack2021

DNS·네트워크 장애2건

  1. IL-0240 인증 데이터베이스가 과부하에 걸려 Cloudflare API 와 대시보드가 6시간 33분 동안 실패하고 느려졌다
  2. IL-0590 Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다