사례1건

1건 중 1~1번째

1. IL-0306 Neon us-east-1 에서 pageserver 를 돌리던 EC2 인스턴스가 예고 없이 죽어 프로젝트 0.4% 의 Postgres 가 최대 2시간 동안 멈췄다

   Neon2024

   증상

   2024년 8월 14일 17:38 에 알림이 Slack 으로 오고 온콜 엔지니어에게 자동으로 호출이 갔다. us-east-1 의 pageserver 하나가 응답하지 않았고, 그 pageserver 에 연결된 고객 Postgres 데이터베이스는 버퍼 캐시에 없는 데이터를 읽으려 할 때마다 멈췄다.

   스토리지 연결 끊김오류율 상승

   촉발

   us-east-1 에서 pageserver-7.us-east-1.aws.neon.tech 를 돌리던 EC2 인스턴스가 17:28 에 AWS 의 사전 경고 없이 응답을 멈췄다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   부분 배포

   감지

   17:38 에 여러 알림이 울렸다. 알림은 Slack 으로 팀에 전해졌고, 온콜 엔지니어가 자동으로 호출됐다. pageserver 가 지표 수집에 응답하지 않는 것, 컨트롤 플레인 API 오류율이 오르는 것, 엔드포인트 시작과 타임라인 생성 같은 사용자 작업이 멈추는 것이 각각 알림을 울렸다.

   조치

   • 반자동 스크립트로 pageserver 7 에 연결되어 있던 프로젝트 17037개를 같은 리전의 다른 pageserver 로 옮겼다. 약 40분 걸렸다.
   • 진행 중이던 작업 때문에 이전이 막혀 이상한 상태로 남은 프로젝트 20개쯤을 손으로 처리해 되살렸다.

   후속 조치

   • 이번 장애를 보고 유료 고객 전부를 Storage Controller 로 옮기는 계획을 앞당긴다.
   • 기존 pageserver 인프라를 Storage Controller 가 관리하도록 옮기는 작업을 이어 간다. Storage Controller 는 조정 루프로 프로젝트를 pageserver 에 배치하고, 자체 하트비트로 노드 장애를 판단해 사람 없이 몇 초 안에 작업을 다른 노드로 옮긴다.

   교훈

   Neon 은 장애 대응이 모든 프로젝트를 되살렸지만 너무 오래 걸렸다고 밝혔다. 노드 장애가 난 뒤 이전을 결정하기까지 사람이 판단해야 했고, 알림이 텔레메트리 손실을 잡는 데 몇 분이 걸렸으며, 반자동 이전과 손으로 푸는 작업이 느렸다. 컨트롤 플레인은 원래 작업 큐를 둔 CRUD API 로 설계되었고, 작업은 프로젝트마다 하나씩 돌며 늘 끝까지 실행된다는 전제였다. 이 설계는 아래에서 움직이는 시스템의 가용성이 높을 때는 잘 맞지만, 언제든 멈출 수 있는 EC2 인스턴스 같은 물리 자원에 기대는 작업에는 맞지 않았다. 한편 알림은 늦었지만 정확해서 원인을 빨리 찾을 수 있었다. 이전은 느렸지만 데이터 손실과 스플릿 브레인이 없었고, 미리 준비해 둔 보조 pageserver 덕분에 용량과 데워진 캐시가 있었다.

   사례 보기

원인별1