Incident Library

IL-0368 PlanetScale · 2025-10-20awsdatabasenetworking

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

2025년 10월 20일 PlanetScale 은 서비스 제공자 한 곳의 DNS 설정 오류로 시작해 몇 시간 동안 이어진 용량 제약과 네트워크 불안정의 영향을 받았다. 장애는 두 단계로 나뉘었다. 첫 단계에서는 PlanetScale 컨트롤 플레인이 멈췄고, 둘째 단계에서는 AWS us-east-1 에 있는 일부 데이터베이스 브랜치가 영향을 받았다.

첫 단계는 7:13 UTC 에 프로덕션 테스트가 실패하면서 드러났다. 데이터베이스 브랜치를 만들고 크기를 바꾸고 설정하는 서비스는 us-east-1 에 있었고, 내부 시크릿 배포 서비스에 기댔다. 이 시크릿 배포 서비스는 Amazon S3 에, S3 는 AWS STS 에 기댔는데, AWS STS 가 Amazon DynamoDB 장애의 영향을 받았다. us-east-1 에 있는 제공자가 호스팅하는 대시보드도 됐다 안 됐다 했고, SSO 로그인과 상태 페이지 업데이트도 막혔다. 고객 데이터베이스 브랜치는 용량과 연결을 잃지 않았다. 엔지니어들은 조사만 하고 고치는 조치는 하지 않았고, 9:30 UTC 에 상위 서비스 제공자가 복구되자 서비스가 돌아왔다.

둘째 단계는 10:05 UTC 에 한 고객 환경의 Kubernetes operator 가 자원을 다 쓰고 있다는 알림으로 시작했다. 원인은 us-east-1 에서 새 EC2 인스턴스를 띄울 수 없는 것이었다. 미국 동부의 월요일 업무가 곧 시작될 참이었다. Vitess 클러스터의 vtgate 를 하루 주기로 자동 확장하는 큰 고객 일부는 지난주의 절반도 안 되는 vtgate 용량으로 주간 최대 트래픽을 맞을 상황이었다. 엔지니어들은 띄워야 할 EC2 인스턴스를 줄이고 돌고 있는 인스턴스를 지키는 조치를 했다. vtgate 프로세스는 평소보다 빽빽하게 배치했다. 14:30 UTC 쯤부터는 부분적인 네트워크 분할로 가용 영역 사이의 쿼리 라우팅과 복제가 끊겨 일부 고객의 쿼리가 많이 실패했다. 엔지니어들은 프라이머리를 더 건강한 영역으로 옮겼고, 분할이 18:30 UTC 에서 19:30 UTC 사이에 풀린 뒤 스스로 복구하지 못한 프로세스를 재시작했다. 인시던트 커맨더는 20:32 UTC 에 장애가 끝났다고 선언했다.

심각도
–
영향 범위
PlanetScale control plane (creating, resizing and configuring database branches), dashboard, SSO login and status page; queries, replication and query routing for some database branches in us-east-1
영향 사용자
–
지역
AWS us-east-1
감지까지
–
복구까지
–

증상

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

거의 전면적인 컨트롤 플레인 장애였다. 고객 데이터베이스 브랜치는 이 동안 용량이나 연결을 잃지 않았다.

같은 시기에 PlanetScale 대시보드는 됐다 안 됐다 했고, SSO 를 쓰는 고객은 이미 로그인한 상태가 아니면 로그인하지 못했다. https://planetscalestatus.com 에는 업데이트를 올릴 수 없었고, 이 사이트 자체도 적어도 30분 동안 열리지 않았다. 9:30 UTC 에 상위 서비스 제공자가 복구되자 컨트롤 플레인도 돌아왔다.

10:05 UTC 에 한 고객의 대형 싱글 테넌트 환경에서 PlanetScale 의 Kubernetes operator 하나가 쓸 수 있는 자원을 모두 쓰고 있다는 알림이 왔다. 이 알림은 보통 지연이 늘었거나 컨트롤 플레인 요청이 실패해 재시도되고 있다는 뜻이다. 대응자들은 us-east-1 에서 새 EC2 인스턴스를 띄울 수 없다는 것을 곧 찾았다. 고객이 데이터베이스 브랜치를 만들거나 크기를 바꾸는 요청은 끝나지 않고 장애가 끝날 때까지 큐에 남았다. 기존 MySQL 과 Postgres 서버는 계속 동작했다.

14:30 UTC 쯤부터 us-east-1 에서 부분적인 네트워크 분할이 보였다. 일부 데이터베이스 서버는 인터넷에서는 닿았지만 쿼리 라우팅이나 복제, 또는 둘 다를 위해 가용 영역 사이에서 통신하지 못했다. 일부 복제본은 시작할 때 컨테이너 레지스트리에는 닿았지만 MySQL 이나 Postgres 프라이머리에서 복제하지 못했다. 일부 서버는 내부 DNS 이름을 풀지 못했고, 다른 서버는 그 이름이 가리키는 내부 서비스에 연결하지 못했다.

네트워크 분할 때문에 일부 고객은 쿼리의 상당한 비율이 실패했다. 영향은 어느 가용 영역을 쓰는지와 트래픽이 영역 사이를 오가는지에 크게 좌우돼, 모든 데이터베이스 브랜치가 영향을 받지는 않았다. 분할은 18:30 UTC 에서 19:30 UTC 사이에 조금씩 풀렸다.

분할이 풀린 뒤에도 PlanetScale 의 엣지 로드 밸런서와 vtgate 프로세스 몇 개는 분할을 겪은 방식 때문에 스스로 복구하지 못했다.

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

원인

원인 클라우드 제공자 장애

구성 요소 데이터베이스데이터베이스 복제데이터베이스 프록시와 커넥션 풀러오브젝트 스토리지
기여 요인 –
촉발
PlanetScale 의 서비스 제공자 한 곳에서 DNS 설정 오류가 났고, 이어서 AWS us-east-1 에 몇 시간 동안 용량 제약과 네트워크 불안정이 이어졌다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 복제, 데이터베이스 프록시와 커넥션 풀러. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.