사례6건

6건 중 3~6번째

1. 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 팀을 늘린다.
   • 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.

   사례 보기
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-0289 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다

   updown.io2019

   증상

   2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.

   지연 시간 증가서비스 중단장애 조치 실패

   촉발

   주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다.

   원인

   하드웨어 고장

   구성 요소

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

   기여 요인

   –

   감지

   MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다.

   조치

   • 보조 서버가 넘겨받을 준비가 됐는지 확인한 뒤 주 서버를 강제로 step down 시켰다. 8:56 am CEST 에 웹과 데몬 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다.
   • I/O 문제를 일으킨 SSD 를 RAID 어레이에서 빼자 서버가 원래 성능으로 돌아왔다.
   • 호스팅 업체에 SSD 교체 일정을 잡는 티켓을 열었다.
   • 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿨고, 그 뒤 응답 시간이 정상으로 돌아왔다.

   후속 조치

   • MongoDB 팀이 이 문제를 곧 고칠 것 같지 않아, MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만든다.
   • 더 조사할 것이 없다고 확인되면 옛 보조 서버를 내리고 지운다.
   • 새 보조 서버가 며칠 동안 주 서버 역할을 버틸 수 있는지, clamscan 이 도는 밤까지 포함해 확인한다.
   • 주 서버가 정상으로 돌아오면 자동 step down 스크립트를 시험한다.
   • updown.io 의 제대로 된 상태 페이지를 만든다.
   • MongoDB 가 Storage Node Watchdog 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다.

   사례 보기
4. IL-0219 Postgres 프라이머리의 디스크 어레이가 망가진 뒤 Pacemaker 가 새 프라이머리를 승격하지 못해 GoCardless API 와 대시보드가 1시간 50분 멈췄다

   GoCardless2017

   증상

   2017년 10월 10일 15:09 BST 에 모니터링이 API 와 대시보드가 완전히 멈춘 것을 찾았다. 그동안 들어온 요청은 모두 실패하고 오류를 받았다.

   서비스 중단장애 조치 실패

   촉발

   10월 10일 오후 Postgres 프라이머리 노드의 RAID 컨트롤러가 디스크 3개를 동시에 잃어 디스크 어레이가 망가졌다. 거의 같은 때 동기 복제본에서 Postgres 하위 프로세스 하나가 죽었다.

   원인

   하드웨어 고장

   구성 요소

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

   기여 요인

   장애 중첩미검증 가정

   감지

   15:09 BST 에 모니터링이 API 와 대시보드의 완전한 중단을 찾았고 엔지니어들이 조사를 시작했다.

   조치

   • 15:17 BST 에 디스크 어레이가 망가진 채 켜져 있는 노드를 클러스터에 두지 않으려고 망가진 Postgres 프라이머리 노드의 전원을 껐다. 클러스터는 여전히 새 프라이머리를 승격하지 않았다.
   • 15:18 BST 에 Pacemaker 가 Postgres 인스턴스 상태를 다시 파악하게 하려고 crm resource cleanup 으로 오류 횟수를 지웠지만 효과가 없었다.
   • Pacemaker 클러스터를 유지보수 모드로 두고 동기 복제본의 recovery.conf 에서 복제본 설정을 지운 뒤 유지보수 모드를 풀어 직접 승격하려 했지만, 매번 원래 recovery.conf 로 돌아갔다.
   • 16:18 BST 에 클러스터를 마지막으로 유지보수 모드로 두고 동기 복제본을 프라이머리로 설정해 Postgres 를 직접 띄웠다.
   • 클러스터가 유지보수 모드라 가상 IP 를 옮길 수 없었으므로 백엔드 애플리케이션이 새 프라이머리의 실제 IP 주소로 접속하게 다시 설정했다.
   • 평소 수준의 이중화를 되찾으려고 세 번째 노드를 비동기 복제본으로 띄웠다.
   • Pacemaker 가 유지보수 모드라 자동 페일오버가 없었으므로 인프라 팀이 손으로 관리할 가상 IP 를 하나 더 두어, 프라이머리가 망가지면 동기 복제본을 승격하고 가상 IP 를 직접 옮길 수 있게 했다.
   • 디스크 어레이 장애였으므로 생각할 수 있는 모든 시험으로 데이터 무결성을 확인했고 데이터 손상의 증거는 없었다.
   • Pacemaker 가 다시 관리하는 새 데이터베이스 클러스터를 만들고, 유지보수 시간을 공지한 뒤 문제없이 옮겼다. 옛 클러스터는 내렸다.

   후속 조치

   • Backup VIP 의 colocation 규칙을 Postgres 프라이머리와의 -INF 선호 대신 복제본과의 INF 선호로 바꿔, 같은 장애 조건에서도 동기 복제본이 승격되게 했다.
   • 특정 Postgres 인스턴스로 트래픽을 보내는 가상 IP 를 없애고, 애플리케이션 서버에서 클러스터 상태에 따라 알맞은 노드로 트래픽을 보내는 프록시를 돌려 Pacemaker 가 관리하는 자원 수를 줄인다.
   • Postgres 클러스터를 더 거칠게 시험하고, Chaos Monkey 처럼 계속 장애를 주입하는 자동화를 검토한다.
   • 장애 대응 훈련인 게임 데이에 임의의 제약을 넣는 방안을 검토한다. 예를 들어 자동화가 실패하고 원인도 찾을 수 없는 상황에서 다른 방법으로 서비스를 되살리게 한다.

   교훈

   GoCardless 는 단순해 보이는 Pacemaker 설정이 매우 이상한 동작을 부를 수 있다는 것을 배웠다. 두 자원이 함께 돌면 안 된다는 규칙과 함께 돌아야 한다는 규칙은 반대말처럼 보이지만, 특정 장애 조건에서는 시스템이 완전히 다르게 움직였다. 프로세스 두 개가 거의 동시에 죽을 때만 드러나는 설정 오류는 기본 시험이나 평소 운영으로는 찾을 수 없고, 장애 주입으로만 드러나는 버그가 있다. 자동화가 2년 동안 장애를 잘 처리하자 그 아래 인프라를 손으로 다루는 기술이 녹슬었다. 런북을 써 두어도 몇 년 뒤에 꺼내 보면 거의 확실히 낡아 있다.

   사례 보기

원인별1