사례39건

39건 중 34~38번째

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-0396 새로 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, 네트워크 로드 밸런서가 2시간 8분 동안 공인 IP 주소로 연결되지 않았다

   Google Cloud2017

   증상

   2017년 1월 30일 새로 만든 GCE 인스턴스에 네트워크 연결이 되지 않았다. 라이브 마이그레이션 중인 인스턴스, 새로 만든 Cloud VPN 터널과 GCE 네트워크 로드 밸런서도 공인 IP 주소로 닿을 수 없었다. 이미 만들어져 있고 라이브 마이그레이션을 겪지 않은 인스턴스, 로드 밸런서, VPN 터널은 영향이 없었다.

   네트워크 도달 불가프로브 실패

   촉발

   드물게 쓰는 로드 밸런싱 구성에 대량의 변경이 들어갔다. 이 변경이 비효율적인 코드 경로를 타면서 canary 배포가 타임아웃됐다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서네트워크 컨트롤 플레인

   기여 요인

   과도한 영향 범위자동 테스트 공백

   조치

   • 네트워크 로드 밸런서에 변경을 반영하는 작업을 재시작했다. 재시작 뒤 문제의 변경이 한 묶음으로 처리되면서 비효율적인 코드 경로를 타지 않았고, 변경이 다시 처리됐다.
   • 이 조치를 11:36 부터 12:42 까지 존마다 차례로 적용했다.

   후속 조치

   • canary 타임아웃을 늘려, 비효율적인 코드 경로를 타는 변경이 네트워크 변경을 완전히 멈추지 않고 늦추기만 하게 한다.
   • 비효율적인 코드 경로를 개선한다.
   • 더 넓은 범위의 구성에서 동작을 확인하는 테스트를 새로 쓴다.
   • 주소 구성을 전 세계로 퍼뜨리는 방식을 분산 라우팅으로 바꾸는 작업을 앞당겨, 이 계층의 문제가 전 세계에 영향을 주지 않게 한다.
   • 이런 문제를 더 빨리 알아보고 더 빨리 해결할 수 있도록 지표와 알림을 더 만든다.

   사례 보기
3. IL-0494 DDoS 중 호스팅 사업자가 중앙 로드 밸런서 IP를 null route 해 A 레코드로 Netlify를 가리킨 사이트가 응답하지 않았다

   Netlify2016

   증상

   2016-08-22 월요일 오전 8시 PST에 Netlify 중앙 로드 밸런서가 응답하지 않는다는 알림이 왔다. 로드 밸런서의 공개 IP로 가는 트래픽은 서버에 닿기 전에 멈춘 채 응답이 없었다.

   네트워크 도달 불가

   촉발

   DDoS 트래픽이 Rackspace 시카고 데이터센터에 있던 Netlify 중앙 로드 밸런서로 몰렸고, Rackspace가 그 로드 밸런서의 IP를 null route 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서

   기여 요인

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

   감지

   2016-08-22 월요일 오전 8시 PST에 중앙 로드 밸런서가 응답을 멈췄다는 알림을 받았다. 이틀 전 토요일 밤에는 로드 밸런서의 트래픽 패턴에서 들어오는 전송량 급증을 먼저 알아챘다.

   조치

   • Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 서버 클러스터를 띄우기 시작했다.
   • 새 CDN 클러스터가 준비되자 지원 채널로 연락해 온 고객에게 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 알리고, 네이키드 도메인을 되살리도록 A 레코드를 바꾸게 안내했다.
   • 새 IP가 안정적인 해법이라고 확신한 뒤 문서 페이지를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다.

   후속 조치

   • Google 기반의 새 네트워크 IP를 계속 운영한다.
   • Netlify CDN과 밀접하게 통합된 자체 DNS 호스팅을 내놓는다. Netlify DNS를 쓰면 중간 CNAME이나 A 레코드 없이 사용자를 가장 가까운 활성 CDN 노드로 보낸다.
   • 상태 페이지 게시 과정을 고쳐 앞으로 문제가 생기면 상태 페이지가 바로 갱신되게 했다.
   • 장애 때 유료 고객 모두에게 대상을 골라 메일을 빨리 보낼 수 있는 메일 발송 도구를 만든다.

   교훈

   관리형 로드 밸런서를 쓰는 한 DDoS 대응은 Netlify가 손댈 수 없었다. Rackspace의 로드 밸런서는 DDoS 공격에 너무 약했고 DDoS 대응 절차도 함께 일하는 다른 클라우드 사업자에 못 미쳤다. 결국 도메인을 DDoS 장애에서 지키는 유일한 방법은 그 도메인에 고정 IP 주소를 아예 드러내지 않는 것이다. 단일 IP에 기대지 않고 www 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다.

   사례 보기
4. IL-0519 AWS 보안 그룹 변경으로 cloud.gov PaaS 의 나가는 트래픽이 막혀 애플리케이션들이 멈췄다

   cloud.gov2016

   증상

   cloud.gov 에서 돌던 애플리케이션 가운데 의존하는 서비스에 접속하려고 밖으로 트래픽을 보내던 애플리케이션들은 그 트래픽이 막혀 쓸 수 없게 됐다. 한때는 cloud.gov 의 모든 애플리케이션이 멈췄다.

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

   촉발

   3월 8일 태평양 시간 오전 9시 28분에 Aquilent 의 외주 엔지니어가 AWS 의 보안 그룹 설정을 바꿔 cloud.gov PaaS 의 나가는 트래픽을 제한했다. 이 변경은 플랫폼의 ATO 를 받는 과정에서 하던 여러 변경 가운데 하나였다.

   원인

   설정 변경

   구성 요소

   VPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   –

   조치

   • 애플리케이션마다 보안 그룹 예외를 더해 일부 애플리케이션을 되살렸다.
   • 결국 보안 그룹 변경을 롤백하기로 했고, 3월 9일 태평양 시간 오전 8시에 모든 애플리케이션이 돌아왔다.

   후속 조치

   • 보안 그룹 설정을 모두 버전 관리에 넣고, 풀 리퀘스트로 바뀔 내용을 보이게 하며 변경을 언제 적용할지 통제한다.
   • cloud.gov 에서 도는 애플리케이션을 모니터링하고, 애플리케이션이 기대대로 돌지 않으면 cloud.gov 팀이 알림을 받게 한다.
   • AWS 보안 그룹 대신 CF 보안 그룹을 쓰고, 이 규칙의 현재 상태를 cloud.gov 팀과 cloud.gov 를 쓰는 팀들이 볼 수 있게 한다.
   • 플랫폼에서 도는 애플리케이션마다 주요 연락 담당자에게 알릴 수 있는 알림 체계를 만든다.
   • 이런 변경을 실제와 더 가깝게 시험할 수 있도록 스테이징 환경을 더 정확하게 만든다.

   사례 보기
5. IL-0258 DDoS 방어 업체에서 데이터센터로 가는 GRE 터널이 끊겨 FastMail 이 두 시간 가까이 접속되지 않았다

   Fastmail2016

   증상

   멜버른 시간 2016년 2월 7일 일요일 오전 4시 50분, UTC 로는 2월 6일 오후 6시 무렵 Level 3 와 NYI 사이의 GRE 터널이 끊겼다. FastMail 로 오는 트래픽이 FastMail 네트워크에 전혀 들어오지 못해 고객은 서비스를 쓸 수 없었다.

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

   촉발

   멜버른 시간 2016년 2월 7일 오전 4시 50분에 DDoS 방어를 맡은 Level 3 와 주 데이터센터 NYI 사이의 GRE 터널이 끊겼다.

   원인

   의존성 장애

   구성 요소

   DDoS 방어 서비스BGP 라우팅

   기여 요인

   디버그 접근 제한

   감지

   데이터센터 업체 NYI 가 장애를 금방 알아챘다.

   조치

   • NYI 가 Level 3 지원 창구에 계속 상급자 대응을 요청해, FastMail 의 공인 IP 대역이 다시 NYI 를 가리키게 했다.

   후속 조치

   • DDoS 방어를 예전 방식으로 되돌려, NYI 가 직접 통제하는 가운데 Black Lotus 가 방어를 맡는다.
   • Los Angeles 데이터센터에 보조 네트워크로 NYI 의 애플리케이션·메일 서버와 통신하는 nginx 프런트엔드를 새로 만든다. NYI 의 주 네트워크가 끊기면 DNS 로 www.fastmail.com, mail.messagingengine.com 같은 이름을 LA 프런트엔드로 돌린다.
   • Amsterdam 에 하드웨어를 늘리고, 배달 시스템이 NYI 와 덜 통신하도록 내부를 바꾼다.
   • NYI 가 네트워크 장애를 감지하고 대응하는 내부 절차를 NYI 와 함께 더 자세히 파악한다.

   교훈

   이렇게 복구가 늦어지는 것은 받아들일 수 없다. FastMail 과 NYI 가 쌓아 온 신뢰성의 큰 부분은 NYI 가 인프라를 직접 통제하는 데서 나왔다. 상시 DDoS 방어로 옮기면서 그 통제를 잃었다.

   사례 보기

원인별10