사례14건

14건 중 11~14번째

1. 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 버전을 그만 쓰고 버전을 올린다.

   교훈

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

   사례 보기
2. IL-0319 mysql2 를 다시 적재하려고 데이터베이스를 지우는 동안 mysql1 의 데이터베이스도 함께 지워졌다

   Oregon State University Open Source Lab2015

   증상

   복제 오류를 고치려고 mysql2 의 데이터베이스를 하나씩 지우던 중, 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다. 지워진 데이터베이스들은 복원될 때까지 쓸 수 없었다.

   데이터 유실서비스 중단복제 지연

   촉발

   7월 30일 오후 4시 PDT 에 팀은 복제 오류를 고치려고 mysql2 를 다시 적재하기로 했다. 슬레이브 복제를 멈춘 뒤 mysql2 의 데이터베이스를 하나 지울 때마다 잠깐씩 쉬면서 지웠다.

   원인

   운영 실수

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   미검증 가정미검증 백업

   감지

   데이터베이스를 지우는 스크립트가 하나를 지울 때마다 짧게 쉬었기 때문에, 시작하고 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다.

   조치

   • mysql1 에서도 데이터베이스가 지워지는 것을 보고 스크립트를 멈췄다.
   • 곧바로 지워진 데이터베이스의 복원을 시작했다.
   • 인덱스와 외래 키 문제로 복원이 실패한 데이터베이스는 약 200GB 백업 파일에서 따로 꺼내 복원했고, 아직 복원하지 못한 나머지 데이터베이스도 다시 꺼내 복원했다.
   • 백업은 mysql1 보다 뒤처진 mysql2 에서 뜬 것이어서, 17일부터 30일까지의 바이너리 로그로 대부분의 데이터를 되살렸다. 15일과 17일 사이의 데이터 일부는 되살리지 못했다.

   후속 조치

   • 처음 문제였던 복제 오류를 줄이려고 행 기반 복제를 포함해 더 나은 복제 방식을 검토한다.
   • 바이너리 로그를 별도 서버에 백업으로 보관한다.
   • 전체 복원이 훨씬 빨라지도록 Percona XtraBackup 으로 백업한다.
   • 논리 백업 속도를 높이려고 mysql-zrm 대신 mydumper 를 쓴다.
   • 복잡한 시스템의 문서와 교육을 손본다.
   • 백업 절차의 하나로 예비 서버에서 전체 복원을 정기적으로 시험한다.
   • 복원에 걸리는 예상 시간을 더 정확하게 잡는다.
   • 호스팅하는 데이터베이스를 정기적으로 점검한다. 시험용 데이터베이스와 100GB 넘게 불어난 데이터베이스 여러 개가 이번 복원을 크게 늦췄다.
   • 더 크고 성능이 좋은 MySQL 클러스터로 옮긴다. 이 이전은 장애 전부터 계획돼 있었다.
   • 장애와 유지보수, 자원 사용량과 경고 신호를 대시보드로 커뮤니티에 더 잘 알리는 정책과 수단을 만든다.
   • 핵심 서비스의 용량 한계를 정하고 감시한다.
   • 핵심 서비스에 이중화와 복원 절차를 갖추고 직원 훈련을 한다.
   • 핵심 서비스를 더 많이 Chef 로 옮긴다.
   • 문서, 정책, 성능 지표를 주기적으로 검토한다.
   • 커뮤니티의 전문 지식으로 연구소의 역량을 보완할 더 나은 방법을 찾는다.
   • 가장 낡은 인프라를 교체하고 가장 심한 기술 부채를 해소할 기금을 모은다.

   교훈

   Open Source Lab 은 이번 장애에서 MySQL 클러스터를 운영하는 방식과 연구소 전체가 자원을 계획하고 관리하는 방식 모두에서 교훈을 얻었다고 적었다. 디스크 공간을 아끼려고 백업을 강하게 압축한 선택은 전체 복원이 드물었던 그동안에는 괜찮았지만 이번 복원을 크게 늦췄다. 더 많은 프로젝트를 받으려고 자원을 빠듯하게 나눠 써 왔고, 그 대가로 백업을 압축하고 바라던 것보다 이중화를 덜 갖췄다. 장애가 길었던 것과 진행 상황을 알리지 못한 것은 받아들일 수 없는 일이었다고 밝혔다.

   사례 보기
3. IL-0538 사쿠라 클라우드 스토리지의 일괄 삭제 작업이 고객이 쓰던 디스크 53개를 지웠고 되살리지 못했다

   Sakura Internet2012

   증상

   2012년 1월 5일 긴급 점검에서 스토리지의 불필요한 파일 시스템을 한꺼번에 지운 뒤, 고객이 사용 중이던 사쿠라 클라우드 디스크 53개가 함께 지워졌다. 이 디스크들은 백업에서도 되살릴 수 없었다.

   데이터 유실

   촉발

   스토리지 부하가 너무 높아 통상 절차로는 삭제가 실행되지 않자, 이 점검만을 위해 배치 명령을 새로 만들어 불필요한 파일 시스템을 한꺼번에 지웠다. 리뷰와 테스트를 충분히 거치지 않은 이 명령이 예비로 미리 만들어 둔 파일 시스템을 생성에 실패한 디스크로 잘못 분류했다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스 백업과 스냅숏

   기여 요인

   리뷰 누락미검증 백업

   후속 조치

   • 불필요한 파일 시스템을 지우는 절차를 단순하게 바꾼다.
   • 리뷰와 테스트를 충분히 거치지 않은 스크립트는 실행하지 않는다는 원칙을 철저히 지킨다.

   사례 보기
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