사례2건

2건 중 1~2번째

1. IL-0371 PITR 을 켠 Render Postgres 데이터베이스에서 백업이 도는 동안 새 연결의 절반이 실패했다

   Render2023

   증상

   특정 시점 복구 기능인 PITR 을 켠 Render Postgres 데이터베이스에 새 연결을 맺으면, PITR 백업 작업이 도는 동안 50% 확률로 실패했다. 커넥션 풀링처럼 이미 맺어 둔 연결은 영향이 없었다.

   간헐적 연결 실패요청 오라우팅

   촉발

   Render 는 2023년 4월 21일 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. 이 기능의 백업 작업은 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏서비스 디스커버리

   기여 요인

   –

   조치

   • 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다.
   • 백업 작업의 네트워크 레이블 설정을 고쳐, 라우팅 계층이 백업 작업을 연결 대상 서비스로 잡지 않게 했다.

   후속 조치

   • 장애 업데이트를 공유하는 절차를 엄격하게 바꿔, 문제가 실제로 끝나기 전에 해결됐다고 알리지 않게 한다.
   • 데이터베이스 라우팅 계층에 더 구체적인 네트워크 레이블 설정을 둬, 연결 대상이 아닌 IP 가 서비스 설정에 들어가지 않게 한다.
   • 비동기 작업을 건너뛰었을 때 곧바로 실행하지 않고 다음 예약 시간대로 다시 예약한다.
   • 오픈소스 벤치마크 도구로 시스템을 측정하고, 고객이 알아챈 문제를 재현한다.

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

   사례 보기

원인별2