사례3건

3건 중 1~3번째

1. IL-0389 AWS 서울 리전에서 EC2 DNS 확인 서버군의 정상 호스트가 줄어 EC2 인스턴스 안의 DNS 쿼리가 실패했다

   Amazon Web Services2018

   증상

   2018년 11월 22일 한국 시간 오전 8시 19분부터 서울 리전 AP-NORTHEAST-2 에서 고객 EC2 인스턴스 안의 DNS 쿼리가 실패하기 시작했다. AWS 엔지니어링 팀은 8시 21분에 이 DNS 확인 문제를 알림으로 받았다.

   DNS 조회 실패

   촉발

   설정 업데이트가 서울 리전 EC2 DNS 확인 서버군의 최소 정상 호스트 수를 지정하는 설정을 잘못 지웠다.

   원인

   설정 변경

   구성 요소

   VPC DNS 리졸버

   기여 요인

   설정 테스트 부재파괴적 변경 보호 장치 부재

   감지

   한국 시간 오전 8시 21분에 엔지니어링 팀이 서울 리전의 DNS 확인 문제를 알림으로 받았다.

   조치

   • 정상 호스트가 서비스에서 더 빠지지 않게 막아 영향이 더 커지지 않게 했다. 이 작업에 15분이 걸렸다.
   • EC2 DNS 확인 서버군의 용량을 이전 수준으로 되돌렸다. 복구 시간 대부분이 이 작업에 들었고, 한국 시간 오전 9시 43분에 완전히 복구됐다.

   후속 조치

   • 모든 AWS 리전의 EC2 DNS 확인 서비스에 올바른 용량 설정이 들어 있는지 바로 확인했다.
   • 모든 리전이 늘 충분한 최소 정상 호스트를 갖도록, EC2 DNS 확인 서버군의 설정 업데이트마다 설정 값의 의미까지 확인하는 검증을 넣는다.
   • 서비스에서 시간당 뺄 수 있는 정상 호스트 용량을 제한하는 스로틀링을 더한다. 잘못된 설정 값이 들어와도 EC2 DNS 확인 서버군의 용량이 줄지 않게 하려는 것이다.

   사례 보기
2. IL-0534 US-EAST-1 의 Amazon S3 가 몇 시간 동안 요청을 처리하지 못했고 S3 에 기대는 AWS 서비스도 함께 멈췄다

   Amazon Web Services2017

   증상

   2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.

   서비스 중단

   촉발

   S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지클라우드 블록 스토리지서버리스 함수 플랫폼

   기여 요인

   파괴적 변경 보호 장치 부재과도한 영향 범위순환 의존

   조치

   • 인덱스 하위 시스템을 먼저 재시작했다. PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리할 만큼 용량이 올라왔고, 오후 1:18 에 완전히 회복했다.
   • 인덱스 하위 시스템이 동작하자 배치 하위 시스템을 회복시켰고, PST 오후 1:54 에 회복을 마쳐 S3 가 정상으로 돌아왔다.

   후속 조치

   • 용량을 빼는 도구가 용량을 더 천천히 빼도록 고쳤다.
   • 어떤 하위 시스템이든 필요한 최소 용량 밑으로 떨어지게 하는 용량 제거를 막는 안전장치를 더했다.
   • 다른 운영 도구에도 비슷한 안전 점검이 있는지 감사한다.
   • 핵심 S3 하위 시스템의 회복 시간을 줄인다. 그해 후반에 계획했던 인덱스 하위 시스템의 추가 분할 작업도 앞당겨 바로 시작한다.
   • AWS Service Health Dashboard 의 관리 콘솔이 여러 AWS 리전에서 돌도록 바꿨다.

   사례 보기
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 제어 평면 워크플로가 중앙 서비스 데이터와 현재 로드 밸런서 상태를 더 신중하게 맞추도록 다시 짜, 논리적 데이터 손실이나 손상이 생겨도 손으로 복원하지 않고 자동으로 복구되게 한다.

   사례 보기

원인별2