사례1건

1건 중 1~1번째

1. IL-0368 AWS us-east-1 장애 동안 PlanetScale 컨트롤 플레인이 멈추고, 이어 일부 데이터베이스 브랜치가 네트워크 분할로 쿼리에 실패했다

   PlanetScale2025

   증상

   7:13 UTC 에 프로덕션에서 계속 도는 PlanetScale 테스트가 실패하기 시작했다. 테스트는 새 데이터베이스 브랜치를 만들지 못하고 있었다. 데이터베이스 브랜치를 만들고 크기를 바꾸고 설정하는 서비스가 응답하지 않았다.

   서비스 중단노드 증설 실패네트워크 도달 불가오류율 상승복제 지연DNS 조회 실패

   촉발

   PlanetScale 의 서비스 제공자 한 곳에서 DNS 설정 오류가 났고, 이어서 AWS us-east-1 에 몇 시간 동안 용량 제약과 네트워크 불안정이 이어졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 프록시와 커넥션 풀러오브젝트 스토리지

   기여 요인

   –

   감지

   첫 단계는 7:13 UTC 에 프로덕션에서 계속 도는 테스트가 실패하면서 엔지니어들에게 알림이 갔다. 둘째 단계는 10:05 UTC 에 한 고객 환경의 Kubernetes operator 가 쓸 수 있는 자원을 모두 쓰고 있다는 알림으로 알았다.

   조치

   • us-east-1 에 새 데이터베이스를 만드는 것을 잠시 막고, 새 데이터베이스의 기본 리전을 AWS us-east-2 로 바꿨다.
   • 추가 백업 예약을 미루고, EC2 인스턴스를 띄우려고 기다리던 백업을 취소했다. PlanetScale 의 표준 백업은 백업 동안 데이터베이스의 용량과 장애 내성이 줄지 않도록 복제본을 하나 더 띄워 이전 백업을 복원하고 복제를 따라잡은 뒤 새 백업을 뜬다.
   • vtgate 자동 확장을 쓰는 PlanetScale Managed 고객에게 큐 처리를 미루거나 ETL 작업을 멈추는 식으로 줄일 수 있는 부하를 줄이라고 권했다.
   • 30일이 넘은 EC2 인스턴스를 비우고 종료하던 상시 작업을 멈췄다.
   • 비게 된 EC2 인스턴스를 종료하지 않고 다시 쓰려고 남겨 뒀다.
   • 자동 확장을 설정한 고객의 vtgate 프로세스를 평소보다 빽빽하게 배치해 CPU 용량에 더 가깝게 돌리면서, 미국 업무 시간 동안 쓸 용량을 넉넉히 확보했다.
   • 가능한 곳에서는 손으로 reparent 요청을 보내 프라이머리 데이터베이스를 더 건강하다고 알려진 가용 영역이나 고객 애플리케이션과 같은 영역으로 옮겼다.
   • 네트워크 분할이 풀린 뒤 스스로 복구하지 못한 엣지 로드 밸런서와 vtgate 프로세스를 재시작해 서비스를 되살렸다.

   후속 조치

   • CI/CD, SSO, 웹 애플리케이션 호스팅, 장애 공지에 쓰는 SaaS 의 장애 양상을 더 잘 이해하고, 그 장애에 버틸 수 있게 한다.
   • 런타임에 내부 서비스와 AWS 서비스에 기대는 정도를 더 크게 줄이는 방법을 조사한다.
   • AWS us-east-1 에 있는 가용 영역 여섯 개를 모두 더 잘 써서, 영역 장애와 영역 사이의 네트워크 분할에 더 잘 버티는 방법을 살핀다.

   교훈

   PlanetScale 은 컨트롤 플레인과 데이터 플레인을 확실히 나눠 둔 덕분에 컨트롤 플레인 장애가 고객 데이터베이스에 번지지 않았다고 봤다. 중복 구성과 자동 장애 조치로 프라이머리 데이터베이스 서버가 네트워크 분할의 다수 쪽으로 옮겨 갔고, 영역을 고려한 트래픽 라우팅이 분할의 영향을 최대한 줄였다. 네트워크 분할은 장애 양상 가운데 따져 보기도, 시험하기도, 견디기도 가장 어려운 편이다. 가용 영역 세 개를 쓰면 하나가 망가져도 버틸 수 있지만, 나머지 두 영역 사이의 네트워크 연결이 믿을 만할 때만 그렇다.

   사례 보기

원인별1