사례3건

3건 중 1~3번째

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 덕분에 용량과 데워진 캐시가 있었다.

   사례 보기
2. IL-0370 Frankfurt 에서 노드 하드웨어 장애 뒤 Render Postgres 데이터베이스가 다른 노드에서 시작하지 못해 최대 1시간 5분 멈췄다

   Render2022

   증상

   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 는 하드웨어 문제가 드물지만 언젠가는 일어나는 일이라고 봤다. 그래서 대책을 탐지를 앞당기고 복구 시간을 줄이는 데 맞췄다.

   사례 보기
3. IL-0429 GLM-130B 사전 학습이 노드 고장으로 거듭 중단됐고 Lustre 오류로 2.3T 말뭉치를 읽지 못했다

   Tsinghua University2022

   증상

   96개 노드에서 돌던 GLM-130B 사전 학습이 2022년 5월과 6월 내내 노드 고장, GPU 누락, 연결 끊김으로 여러 번 멈췄다. 2022-05-30 에는 재시작이 데이터 로딩에서 멈춰 더 나아가지 않았다.

   학습 작업 실패노드 NotReadyGPU 인식 불가스토리지 연결 끊김처리량 저하

   촉발

   학습 중에 계산 노드가 고장 나거나 연결이 끊기거나 GPU 를 잃었고, 2022-05-30 재시작 때는 Lustre 파일 시스템 오류가 났다.

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리공유 네트워크 파일 시스템

   기여 요인

   –

   감지

   처리량 저하는 학습 flops 가 127T 로 전보다 낮은 것을 보고 알아챘다. Lustre 파일 시스템 오류는 재시작이 데이터 로딩에서 멈춘 것을 보고 찾아냈다. n30039 는 GPU 가 없다고 스스로 보고했다.

   조치

   • 노드가 고장 날 때마다 마지막으로 저장한 step 에서 학습을 다시 시작했다.
   • 체크포인트 저장 간격을 500 step 에서 100 step 으로 줄였다. 500 step 은 너무 길었다.
   • 다른 노드 풀로 옮겨 15600 step 에서 다시 시작했다.
   • 교체해 넣은 n30076 에 알 수 없는 오류가 있다고 보고 16600 step 부터 이 노드를 뺐지만, 처리량은 달라지지 않았다.
   • 2.3T 텍스트 말뭉치를 백업 디스크에서 파일 시스템으로 다시 복사했고, 며칠이 걸렸다.

   사례 보기

원인별1