사례6건

6건 중 3~6번째

1. IL-0431 AWS 로 옮기는 점검 중 PostgreSQL 이 의도하지 않게 장애 조치되어 한 시간 동안 갱신된 데이터가 사라졌다

   Hatena2017

   증상

   Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮긴 뒤 애플리케이션 동작을 확인하다가, 특정 시간대의 데이터가 사라진 것을 발견했다. 2017년 8월 7일 14시 30분부터 15시 30분 사이에 PostgreSQL 서버에서 갱신된 데이터가 없었다.

   데이터 유실복제 지연네트워크 도달 불가

   촉발

   새 마스터인 db001 로 접속을 바꾸고 한 시간 뒤 db001 과 네트워크 통신이 끊겼고, 복제가 멈춰 있던 스탠바이 서버 db002 로 의도하지 않은 장애 조치가 일어났다.

   원인

   운영 실수

   구성 요소

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

   기여 요인

   장애 중첩기본 설정 방치스테이징 불일치자동화 증폭

   감지

   마이그레이션 작업 뒤 애플리케이션 동작을 확인하던 중 특정 시간대의 데이터가 사라진 것을 발견했다.

   조치

   • db001 에 남은 테이블 데이터로 손으로 복구할 수 있는지 검토했지만, 이미 많은 데이터가 갱신되어 테이블 사이 정합성을 지키며 db002 에 반영하기 어렵다고 보고 포기했다.
   • 점검 전 베이스 백업, db001 에 남은 WAL, 백업 서버로 보내 둔 WAL 아카이브로 PostgreSQL 의 PITR 복구를 시도했지만, 갈라진 두 타임라인을 이어서 복구할 수 없어 포기했다.
   • 장애 조치 직후 db002 를 마스터로 하고 새 슬레이브 서버 db003 을 만들어 db002 와 db003 으로 이중화했다.
   • 장애가 난 db001 은 조사용으로 점검 상태에 남겨 두었다.
   • db002 에서 db001 과 같은 문제가 나지 않는지 일정 시간 지켜본 뒤 마이그레이션 점검을 마쳤다.

   후속 조치

   • PostgreSQL 레플리카 생성 스크립트가 recovery.conf 에 recovery_target_timeline = 'latest' 를 기본으로 넣도록 바꾼다.
   • Serverspec 같은 서버 구성 관리 테스트 도구에 recovery.conf 안에 recovery_target_timeline = 'latest' 문자열이 있는지 확인하는 항목을 더한다.

   교훈

   Hatena 는 이 문제가 평소 운영에서는 일어나지 않지만, PostgreSQL 버전을 올리거나 다른 리전으로 옮길 때 같은 구성을 다시 쓸 수 있다고 보았다. recovery_target_timeline = 'latest' 는 평소 스탠바이 서버에 두어도 문제가 없으므로, 사람이 빠뜨릴 여지를 없애려고 슬레이브를 만들 때 기본으로 넣도록 운영을 바꿨다. 이 설정을 쓰려는 사람은 자기 구성에서 문제가 없는지 먼저 확인하라고 덧붙였다.

   사례 보기
2. IL-0434 ElasticSearch 0.19 클러스터 전체 재시작 뒤 샤드 12개가 unassigned 로 남아 데이터 일부를 읽을 수 없었다

   CyberAgent2016

   증상

   OpenStack 호스트 서버가 다운되어 ElasticSearch 노드 하나가 내려간 뒤, API 서버 쪽 ElasticSearch 헬스 체크가 false 를 반환했다. Head 플러그인으로 본 클러스터 상태는 그린이었다.

   지연 시간 증가데이터 유실

   촉발

   OpenStack 호스트 서버가 다운되어 30대짜리 ElasticSearch 클러스터의 노드 하나가 내려갔다.

   원인

   운영 실수

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   미검증 가정자동화 증폭

   감지

   API 서버가 ElasticSearch 에 하는 헬스 체크가 false 를 반환했다. 클러스터 상태는 Head 플러그인에서 그린으로 보였다.

   조치

   • 호스트가 언제 다시 다운될지 몰라, 복구된 ElasticSearch 노드 서버를 다른 호스트 서버로 마이그레이션했다.
   • 마이그레이션 뒤 ElasticSearch 프로세스를 띄워 노드를 클러스터에 다시 넣었다.
   • 헬스 체크를 되살리려고 1번 노드부터 로그를 보며 차례로 전체 재시작했지만, 스무 번째 노드까지 재시작했을 즈음 API 서버 지연이 생겨 멈췄다.
   • 다시 1번 노드부터 차례로 전체 재시작해 API 서버 지연과 헬스 체크를 되살렸다.
   • _cluster/reroute 의 allocate 명령으로 unassigned 샤드를 옮기려 했지만 오류가 나서 실패했다.
   • A 인덱스의 53번 샤드는 22번 노드에만 파일이 남아 있었다. 그래서 프로세스를 멈추고 그 파일을 디렉터리만 남은 3번 노드와 10번 노드로 복사한 뒤, 22번 노드의 상태 파일만 "primary" 를 true 로 바꿨다.
   • B 인덱스의 51번 샤드는 lucene-core 검사로 27번 노드 쪽이 망가진 것을 확인했다. 27번 노드의 파일을 지운 뒤 28번 노드의 파일을 27번 노드와 다른 노드로 복사하고, 28번 노드만 "primary" 를 true 로 바꿨다.
   • C 인덱스의 2번 샤드는 27번 노드에만, 4번 샤드는 25번 노드에만 파일이 남아 있었다. 그래서 각 파일을 다른 두 노드로 복사하고, 복사한 쪽의 상태 파일은 "primary" 를 false 로 바꿨다.

   후속 조치

   • 오래된 ElasticSearch 버전을 그만 쓰고 버전을 올린다.

   교훈

   재시작할 때는 자동 재배치를 끄고 작업해야 했다. 노드 하나를 재시작한 뒤에는 로그만 볼 것이 아니라 재배치가 완전히 끝나는 것을 보고 나서 다음 노드를 재시작해야 했다.

   사례 보기
3. IL-0224 유지보수 작업이 운영 ELB 상태 데이터 일부를 지워 US-East 리전의 Elastic Load Balancer 일부가 오류를 내고 나머지는 확장하거나 바꿀 수 없게 됐다.

   Amazon Web Services2012

   증상

   2012-12-24 PST 오후 12시 24분부터 US-East 리전의 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐다. 이때는 돌고 있는 로드 밸런서의 요청 처리에 영향이 없었다.

   컨트롤 플레인 지연오류율 상승지연 시간 증가

   촉발

   운영 환경에 접근할 수 있는 아주 적은 수의 개발자 가운데 한 명이 유지보수 프로세스를 실수로 운영 ELB 상태 데이터를 대상으로 실행해 데이터 일부를 논리적으로 지웠다. 그 개발자는 그때 실수를 알아채지 못했다.

   원인

   운영 실수

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   파괴적 변경 보호 장치 부재미검증 백업자동화 증폭

   감지

   데이터가 지워진 뒤 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐고, 기술팀은 이 API 오류부터 살폈다. 사라진 상태 데이터는 팀이 성능이 떨어진 로드 밸런서를 깊이 파고든 뒤에야 찾았다. 데이터를 지운 개발자는 그때 실수를 알아채지 못했다.

   조치

   • PST 오후 5시 2분에 확장과 축소 워크플로를 포함한 ELB 제어 평면 워크플로 여러 개를 꺼서, 돌고 있는 다른 로드 밸런서가 사라진 상태 데이터의 영향을 받지 않게 했다.
   • 영향받은 로드 밸런서 가운데 일부를 월요일 밤에 손으로 복구했다.
   • 처음 쓴 복원 방법이 몇 시간 걸리고도 쓸 수 있는 스냅샷을 만들지 못하자 다른 복구 절차를 찾아, 12월 25일 PST 오전 2시 45분에 데이터가 지워지기 직전 시점의 ELB 상태 데이터 스냅샷을 복원했다.
   • 복원한 데이터에 스냅샷 이후의 시스템 상태 변경을 합쳤고, 오전 5시 40분에 병합과 새 상태 데이터 검증을 마쳤다.
   • 영향받지 않은 로드 밸런서를 건드리지 않고 영향받은 로드 밸런서마다 제대로 복구되도록 ELB 워크플로와 API 를 천천히 다시 켰다. 오전 8시 15분에 대부분의 API 와 백엔드 워크플로가 다시 켜졌고, 오전 10시 30분에 영향받은 로드 밸런서가 거의 모두 정상으로 돌아왔다.

   후속 조치

   • 운영 ELB 상태 데이터의 접근 통제를 바꿨다. 상시 권한으로 잘못 설정된 접근을 되돌렸고, 운영 ELB 데이터에 접근할 때마다 사고 건별 Change Management 승인을 받게 했다.
   • 이번에 배운 것을 반영해 데이터 복구 절차를 고쳤다. AWS 는 비슷한 일이 생기면 ELB 상태 데이터를 훨씬 빨리 복구할 수 있다고 봤다.
   • ELB 제어 평면 워크플로가 중앙 서비스 데이터와 현재 로드 밸런서 상태를 더 신중하게 맞추도록 다시 짜, 논리적 데이터 손실이나 손상이 생겨도 손으로 복원하지 않고 자동으로 복구되게 한다.

   사례 보기
4. IL-0337 US East 리전 한 가용 영역에서 네트워크 변경으로 EBS 노드가 복제본과 끊겨 EBS 볼륨이 멈췄다

   Amazon Web Services2011

   증상

   2011년 4월 21일 오전 12시 47분 PDT, US East 리전의 한 가용 영역에서 EBS 볼륨 일부가 읽기와 쓰기를 처리하지 못하게 됐고, 그 볼륨을 쓰던 EC2 인스턴스도 읽거나 쓰려다 함께 멈췄다. 리전 전체에서 EBS API 의 오류율과 지연도 높아졌다.

   스토리지 연결 끊김네트워크 도달 불가컨트롤 플레인 지연오류율 상승장애 조치 실패데이터 유실

   촉발

   US East 리전의 한 가용 영역에서 주 EBS 네트워크의 용량을 올리는 작업 중, 이중화된 라우터 하나에서 트래픽을 빼는 단계를 잘못 실행했다. 트래픽은 주 네트워크의 다른 라우터가 아니라 용량이 작은 보조 EBS 네트워크로 갔다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스

   기여 요인

   자동화 증폭재시도 폭주여유 용량 부재과도한 영향 범위잡음에 묻힌 신호

   조치

   • 잘못된 트래픽 전환을 되돌려 네트워크 연결을 살렸다. 연결이 돌아오자 노드들이 한꺼번에 재미러링할 공간을 찾기 시작했다.
   • 4월 21일 오전 2시 40분 PDT, 영향받은 가용 영역의 새 Create Volume 요청을 모두 막는 변경을 배포했다. 2시 50분에 다른 EBS API 의 지연과 오류율이 회복했다.
   • 오전 8시 20분부터 망가진 EBS 클러스터와 EBS 컨트롤 플레인 사이의 통신을 모두 끊었다. 그 가용 영역의 EBS API 는 전부 막혔지만 리전의 나머지 EBS API 는 정상으로 돌아왔다.
   • 오전 11시 30분, 클러스터 노드 사이에 꼭 필요한 통신은 그대로 두고, 망가진 클러스터의 EBS 서버가 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 막았다. 이 변경 뒤 클러스터는 더 나빠지지 않았다.
   • 오전 11시 30분, EBS 컨트롤 플레인을 바꿔 다른 가용 영역에서 EBS 기반 EC2 인스턴스를 새로 띄울 때의 오류와 지연을 없앴다. 정오에 거의 정상으로 돌아왔다.
   • 실패한 노드는 다시 쓰지 않고, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 망가진 EBS 클러스터에 설치했다.
   • 새로 들인 서버와는 협상이 일어나되 기존 서버에 처리하지 못할 요청이 다시 몰리지 않도록 협상 스로틀을 조심스럽게 바꿨다.
   • 리전의 다른 가용 영역에 영향이 가지 않도록 영향받은 가용 영역에만 쓰는 EBS 컨트롤 플레인을 따로 세우고 더 세밀한 스로틀을 만든 뒤, 밀린 상태 변경을 처리했다.
   • 장애 초반에 데이터 손실에 대비해 남은 2.2% 의 볼륨을 S3 백업에 스냅샷으로 떠 두었다. 그 스냅샷에서 볼륨을 복구하는 코드를 만들고 시험한 뒤 밤새 묶음으로 처리했다.
   • 기계 고장을 겪어 스냅샷도 뜨지 못한 나머지 볼륨을 포렌식으로 조사했고, 4월 24일 오후 3시부터 복구했다.
   • 자동 장애 전환을 하지 못하고 고립된 RDS multi-AZ 인스턴스의 primary 복제본은 데이터 손실 위험 때문에 사람이 직접 개입해 처리했다.

   후속 조치

   • 변경 절차를 감사하고 자동화를 늘려 이번 같은 실수가 다시 나지 않게 한다.
   • 큰 장애 복구에 필요한 안전 여유 용량을 늘 갖도록 용량 계획과 알람을 바꾼다. 용량 여유분은 이미 크게 늘렸고, 필요한 새 용량은 몇 주 안에 갖춘다.
   • EBS 서버 노드의 재시도 로직을 바꿔, 큰 중단이 나면 더 적극적으로 백오프하고 새 노드를 헛되이 찾기보다 이전 복제본과 연결을 되살리는 데 집중하게 한다.
   • EBS 노드를 죽인 경쟁 조건의 원인을 찾았고, 고친 코드를 시험해 몇 주 안에 클러스터에 배포한다.
   • RDS multi-AZ 인스턴스가 자동 장애 전환을 하지 못하게 만든 버그를 고치고 있다.
   • 한 가용 영역의 클러스터가 요청을 너무 오래 처리할 때 스레드가 고갈되지 않도록 타임아웃 로직을 바로 고친다.
   • EBS 컨트롤 플레인이 가용 영역을 더 잘 구분하고, 용량을 넘었을 때 부하를 골라서 덜어 내게 한다.
   • EBS 컨트롤 플레인의 기능을 더 많이 떼어 내, 지원하는 EBS 클러스터와 같은 가용 영역에서 도는 클러스터별 서비스로 옮긴다.
   • 로드맵을 조정해 지금은 가용 영역 하나만 쓸 수 있는 VPC 고객이 되도록 빨리 여러 가용 영역을 쓰게 한다.
   • 가용 영역 하나를 통째로 잃어도 애플리케이션 가용성이 유지되는 multi-AZ 애플리케이션을 만들 수 있도록 더 나은 도구를 고객에게 준다.
   • 클라우드 설계 모범 사례를 다루는 무료 웨비나를 5월 2일 월요일부터 열고, 모범 사례 백서와 함께 AWS 웹사이트의 새 Architecture Center 에 둔다.
   • 팀이 클러스터를 복구할 때 쓴 세밀한 제어와 스로틀을 EBS 노드 안에 바로 넣고, 여러 종류의 볼륨 복구에 쓴 방식을 자동화한다.
   • 클러스터가 나빠진 동안에도 볼륨 기능을 지키는 방법을 찾고, stuck 볼륨의 스냅샷을 뜨는 기능을 넣는 것을 검토한다.
   • 장애 도중부터 늘린 업데이트 빈도를 앞으로도 같은 수준으로 이어 간다. 또 이런 장애 때 개발자 지원 팀 인력을 더 넓게 배치하고, 짐작은 피하면서 이르고 쓸모 있는 정보를 내도록 조직하는 방법을 준비하고 있다.
   • 고객이 API 로 자기 인스턴스가 손상됐는지 볼 수 있는 도구를 만들고 있다.

   교훈

   AWS 는 이 사고를 촉발한 것은 네트워크 설정 변경이었지만, 앞으로의 일은 비슷한 실패가 나도 EBS 가 견디게 만드는 데 둔다고 했다. 여유 용량이 더 있었다면 망가진 클러스터가 재미러링 요청을 빨리 흡수해 폭주를 피했을 것이라고 봤다. 가용 영역들을 완전히 독립된 것처럼 만들려면 더 투자해야 한다는 것을 이 사고로 배웠다고 했다. 장애 중에 고객이 영향받은 자원을 다른 정상 가용 영역에서 바꾸기 어려웠던 일이 다시 일어나지 않게 하는 것을 최우선으로 꼽았다. 여러 가용 영역에 걸친 배포를 쉽게 설계하고 운영하도록 고객을 돕는 일도 더 잘해야 한다고 했다. 여러 종류의 볼륨 복구에 쓴 방식을 자동화해 두었다면 복구 시간을 크게 줄였을 것이라고 했다. 장애 중 고객 소통은 더 자주, 더 많은 정보를 담아야 한다고 봤다.

   사례 보기

원인별1