사례3건

3건 중 1~3번째

1. IL-0508 SourceHut 의 주 데이터베이스 서버 remilia.sr.ht 가 하드웨어 고장으로 연결이 끊겨 모든 서비스가 중단됐다

   SourceHut2023

   증상

   13:40 UTC 무렵 SourceHut 서비스 대부분을 사용할 수 없다는 경보가 한꺼번에 울렸다. 그 가운데 하나는 주 데이터베이스 서버인 물리 호스트 remilia.sr.ht 를 사용할 수 없다는 경보였다.

   서비스 중단

   촉발

   주 데이터베이스 서버 remilia.sr.ht 의 하드웨어가 고장 났다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스

   기여 요인

   단일 장애점디버그 접근 제한

   감지

   13:38 에 Prometheus 가 remilia 의 지표 수집에 실패했고, 13:40 무렵 대부분의 서비스와 remilia.sr.ht 를 사용할 수 없다는 경보가 울렸다.

   조치

   • 데이터센터 직원에게 연락이 닿지 않아 데이터센터 근처의 비상 연락 담당자를 불렀고, 담당자가 데이터센터로 출발했다.
   • 현장에 도착한 비상 연락 담당자가 데이터센터 직원의 진단을 확인한 뒤 디스크를 cirno1.sr.ht 와 바꿔 끼우고 서버를 띄웠다.

   후속 조치

   • 오프사이트 데이터베이스 백업이 장애 조치용 데이터베이스 호스트로도 쓰일 수 있게 고친다. 이 일은 이미 끝났다.
   • EU 이전 작업 전체의 우선순위를 다시 높인다.
   • 새 데이터베이스 장애 조치 구성을 만든다.
   • 빌드 용량을 메우려고 EU 에 새 빌드 워커를 둔다.
   • 앞으로를 대비해 하드웨어 목록을 더 꼼꼼히 기록한다.

   사례 보기
2. IL-0525 Equinix 암스테르담 전원 점검 중 업링크가 하나뿐인 스위치가 꺼져 OpenStreetMap.org 가 7시간 27분 멈춤

   OpenStreetMap Foundation2022

   증상

   2022년 6월 11일 20:18 UTC 부터 OpenStreetMap.org 에 접속할 수 없었다. Equinix 가 암스테르담 데이터센터 AM6 의 전원 A 계통 점검을 시작하고 18분 뒤였고, 암스테르담에 있는 www, API, wiki, planet 서비스가 모두 인터넷과 끊겼다.

   네트워크 도달 불가서비스 중단

   촉발

   2022년 6월 11일 20:00 UTC 에 Equinix 가 암스테르담의 OpenStreetMap 서버에 전원을 대는 전원 A 계통의 5년 주기 점검을 시작했다.

   원인

   하드웨어 고장

   구성 요소

   네트워크 스위치데이터센터 전력·냉각

   기여 요인

   단일 장애점디버그 접근 제한모니터링 사각지대

   조치

   • 운영 팀은 더블린으로 페일오버하거나 업링크를 Switch-2 로 옮기지 않고 Equinix 전원 점검 시간이 끝날 때까지 기다렸다. 장애는 6월 12일 03:45 UTC 에 끝났다.

   후속 조치

   • 진행 중인 장애를 알리는 데 걸리는 시간을 줄인다. 장애 알림은 https://twitter.com/OSM_Tech 로 낸다.
   • 스위치의 PSU 와 팬 상태를 모니터링하고 알림을 건다.
   • Cisco SG550X-48 스위치 Switch-1, Switch-2 와 Cisco Redundant Power System 을 이중 전원을 갖춘 Juniper EX4300 스위치로 바꾼다. 부품 공급 부족으로 설치가 늦어졌고, 2022년 7월 19일 기준 모든 부품이 현장에 도착해 설치를 기다린다.
   • 이중 전원을 받는 대역 외 접속 장비인 4G 모뎀 시리얼 콘솔 서버를 암스테르담에 둔다. 2022년 6월 20~22일 현장 방문 때 설치를 마쳤다.
   • 이중 업링크를 설치한다. 2022년 7월 19일 기준 아직 설치되지 않아 운영 팀이 계속 챙기고 있다.
   • 지금은 실수하기 쉬운 수동 절차인 사이트 페일오버를 더 쉽고, 손이 덜 가고, 덜 위험하게 만든다.
   • 운영 SRE 를 위한 당번 호출 시스템을 들인다. 2022년 7월 19일 기준 업체와 협상 중이다.
   • 한 사람이 24시간 내내 당번을 설 수 없으므로 장기적으로 SRE 팀을 늘린다.
   • 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.

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

   사례 보기

원인별1