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

사례2건

2건 중 1~2번째

  1. 증상

    새로 만든 VM 이 네트워크 연결 없이 올라와 아무 연결도 맺지 못했고, 마이그레이션되거나 재시작된 VM 은 연결을 잃었다. 방화벽이나 네트워크 로드 밸런서 같은 가상 네트워크 설정을 바꿀 수 없었다. GKE 노드와 노드 풀 생성이 실패했다.

    촉발

    한 Google Cloud 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄려던 정기 유지보수 자동화가 존 매개변수를 무시하고, 아직 쓰이던 모든 존의 VPC 컨트롤러를 껐다.

    원인
    구성 요소
    기여 요인
    감지

    엔지니어들은 미국 태평양 시간 15:41 에 내부 모니터링 알림으로 장애를 알았다.

    조치
    • 재발을 막으려고 유지보수 작업을 곧바로 멈췄다.
    • 유지보수 작업을 멈추는 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 미국 태평양 시간 17:30 에, 모든 VPC 컨트롤러는 18:09 에 돌아왔다.
    • 이 변경을 일으킨 자동화를 찾아냈고, 알맞은 안전장치가 생길 때까지 그 자동화를 중단시켰다.
    • Apigee Edge 에서 일부만 배포된 프록시는 손으로 처리해 2024-05-17 미국 태평양 시간 01:00 까지 복구했다.
    • 클러스터 삭제 작업이 실패해 완전히 지워지지 않은 Dataproc VM 을 찾아냈고, 장애가 완화된 뒤 정리했다.
    후속 조치
    • 유지보수 작업에 존 정보가 알맞은 범위로 들어 있는지 검증하는 안전장치를 더한다.
    • 하위 도구가 존을 지정하지 않은 유지보수 작업을 거부하게 해 심층 방어를 넓힌다.
    • 필요할 때만 권한을 주는 접근 제어를 늘려, 유지보수 작업 한 번이 여러 존에 걸쳐 동작하지 못하게 한다.
    • 유지보수 작업에 필요한 안전 점검, 테스트, 검증 절차를 갖춘다. 회귀를 막도록 위의 세 안전장치마다 통과해야 할 경우와 막아야 할 경우의 테스트를 넣는다.
  2. 증상

    AWS 에 있는 A 서비스가 온프레미스 환경의 B 서비스로 보내는 API 요청에서 5xx 오류가 늘고 사용자 요청이 실패했다. 같은 때 B 서비스 앞단 L4 의 세션 카운트도 올라갔다.

    촉발

    트래픽이 많은 주말에 connection pool 을 쓰지 않는 A 서비스가 NAT Gateway 를 거쳐 B 서비스로 새 TCP 연결을 계속 열었다.

    원인
    구성 요소
    기여 요인
    감지

    A 서비스의 5xx 오류 증가와 B 서비스의 L4 세션 카운트 증가로 알아챘다.

    조치
    • A 서비스 인스턴스를 늘렸다.
    • 5xx 오류와 L4 세션 카운트가 평소 수치로 돌아오지 않자 A 서비스 인스턴스를 교체했다.
    후속 조치
    • A 서비스 팀과 함께 A 서비스가 connection pool 을 쓰도록 바꾼다.
    • AWS 와 IDC 사이에서 NAT Gateway 를 쓰는 서비스를 조사해 connection pool 을 쓰도록 바꾼다.
    교훈

    장애를 해결하는 방법은 원인을 분석하다 보면 쉽게 보일 때가 많다. 그러나 원인을 정확히 확인하지 않으면 잠재적인 위험을 안은 채 서비스를 운영하게 된다. 우아한형제들은 장애 해결을 최우선으로 다루면서도, 재발을 막으려고 근본 원인을 찾아내는 과정을 중요하게 여긴다.

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

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

원인별2