사례3건
3건 중 1~3번째
IL-0306Neon 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 덕분에 용량과 데워진 캐시가 있었다.
- 증상
Frankfurt 의 한 노드에 있던 사용자 Postgres 데이터베이스가 모두 완전히 멈췄다. Render 는 Frankfurt 의 Postgres 데이터베이스 가용성 문제 보고를 받았다.
- 촉발
외부 클라우드 제공자가 준 노드에 하드웨어 문제가 생겨 2022년 5월 23일 08:30 AM UTC 에 상태 검사에 실패했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
데이터베이스가 시작 도중 한 상태에서 15분 이상 넘어가지 못하면 울리는 알림이 08:57 AM UTC 에 당번 엔지니어를 자동으로 호출했다. 장애가 시작되고 27분 뒤였다.
- 조치
- 엔지니어가 09:27 AM UTC 쯤 문제의 노드를 손으로 종료했다. 그러자 디스크가 건강한 노드에 붙었고, 09:35 AM UTC 에 모든 데이터베이스 인스턴스가 돌아왔다.
- 후속 조치
- 당번 엔지니어를 더 일찍 호출하는 알림을 만든다.
- 알맞은 조치를 더 빨리 찾을 수 있게 하고, 결국 그 조치를 자동화해 복구 시간을 줄인다.
- 장애 절차를 검토해 상태 페이지가 실제 가용성을 최대한 정확하게 보여 주게 한다.
- Postgres 고가용성 기능을 만든다. 2022년 4분기쯤 나올 예정이고, 이 기능을 켠 사용자는 프라이머리가 있는 노드에 하드웨어 문제가 나도 장애 시간이 아주 짧아진다.
- 교훈
Render 는 하드웨어 문제가 드물지만 언젠가는 일어나는 일이라고 봤다. 그래서 대책을 탐지를 앞당기고 복구 시간을 줄이는 데 맞췄다.
- 증상
96개 노드에서 돌던 GLM-130B 사전 학습이 2022년 5월과 6월 내내 노드 고장, GPU 누락, 연결 끊김으로 여러 번 멈췄다. 2022-05-30 에는 재시작이 데이터 로딩에서 멈춰 더 나아가지 않았다.
- 촉발
학습 중에 계산 노드가 고장 나거나 연결이 끊기거나 GPU 를 잃었고, 2022-05-30 재시작 때는 Lustre 파일 시스템 오류가 났다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
처리량 저하는 학습 flops 가 127T 로 전보다 낮은 것을 보고 알아챘다. Lustre 파일 시스템 오류는 재시작이 데이터 로딩에서 멈춘 것을 보고 찾아냈다. n30039 는 GPU 가 없다고 스스로 보고했다.
- 조치
- 노드가 고장 날 때마다 마지막으로 저장한 step 에서 학습을 다시 시작했다.
- 체크포인트 저장 간격을 500 step 에서 100 step 으로 줄였다. 500 step 은 너무 길었다.
- 다른 노드 풀로 옮겨 15600 step 에서 다시 시작했다.
- 교체해 넣은 n30076 에 알 수 없는 오류가 있다고 보고 16600 step 부터 이 노드를 뺐지만, 처리량은 달라지지 않았다.
- 2.3T 텍스트 말뭉치를 백업 디스크에서 파일 시스템으로 다시 복사했고, 며칠이 걸렸다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스, 클라우드 블록 스토리지. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.