사례2건

2건 중 1~2번째

1. IL-0276 Chef 가 ZooKeeper 세 노드 가운데 두 대를 동시에 재시작해 쿼럼이 깨지면서 Parse.ly 의 실시간 데이터 전달이 약 3시간 멈췄다

   Parse.ly2016

   증상

   2016년 6월 9일 목요일 11:30am ET 에 대시보드로 가는 데이터 전달이 갑자기 멈췄다. 데이터 전달 모니터 말고는 어떤 시스템도 장애를 알리지 않았다.

   서비스 중단

   촉발

   2016년 6월 9일 정기적으로 도는 Chef 가 설정 변경에 따라 서비스를 재시작하면서, 세 노드로 된 ZooKeeper 클러스터의 두 노드를 정확히 같은 시각에 재시작했다.

   원인

   배포 결함

   구성 요소

   코디네이션 키-값 저장소

   기여 요인

   미검증 가정단계적 배포 부재

   감지

   데이터 전달 모니터가 대시보드로 가는 데이터 전달이 멈춘 것을 알렸다. 다른 시스템은 장애를 알리지 않았다.

   조치

   • 실시간 시스템에서 몇 시간치 데이터를 비우고, 클러스터를 내렸다가 처음부터 다시 올리는 콜드 스타트를 했다.
   • 멈춘 3시간치 데이터를 이력 재구축 과정으로 대시보드에 다시 넣었다.

   후속 조치

   • 운영 환경의 설정 변경과 노드 재시작을 분리한다.
   • 시스템과 절차에 빠르게 복구할 대안을 늘 준비해 둔다.

   교훈

   Parse.ly 는 자동 서비스 재시작을 다시 생각하게 됐다. Chef 가 설정 변경은 자동으로 내보내되 서비스 재시작은 엔지니어가 손으로 하거나 승인하도록 대기시켜 두었다면, 이 작업의 위험이 바로 드러났을 것이다. ZooKeeper 가 노드 하나의 장애를 견디도록 설계됐어도 여러 노드가 함께 죽는 일이 불가능하다고 여기면 안 된다. 큰 분산 시스템에서는 무엇이든 일어날 수 있으므로 시스템과 절차에 빠르게 복구할 대안을 늘 준비해 둬야 한다.

   사례 보기
2. IL-0275 Kafka 브로커들이 네트워크 한계에 닿아 줄줄이 쓰러지면서 Parse.ly 의 데이터 처리가 멈추고 대시보드에 몇 시간 동안 새 데이터가 나오지 않았다

   Parse.ly2015

   증상

   2015년 3월 26일 목요일 밤, 첫 장애가 나자 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다. Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고, Graphite 그래프에도 장애가 보였다. 고객 사이트는 JavaScript 코드를 계속 불러왔지만 분석 데이터가 실시간 처리 스트림으로 흘러 들어오지 않았고, 대시보드에 새 데이터가 나오지 않았다.

   서비스 중단DNS 조회 실패

   촉발

   2015년 3월 27일 금요일 데이터 양이 한계를 넘어 Kafka 브로커들이 운영체제 네트워크 한계에 닿았고, 한 대가 쓰러지자 나머지가 차례로 쓰러졌다. 그 뒤 클러스터를 넓히려고 넣은 새 브로커들이 잘못된 호스트 이름으로 들어왔다.

   원인

   용량 한계

   구성 요소

   메시지 브로커서비스 디스커버리

   기여 요인

   모니터링 사각지대한계 미인지여유 용량 부재수동 조치 악화

   감지

   Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고 Graphite 그래프에서도 확인했다. 첫 장애 때 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다.

   조치

   • Kafka 클러스터를 넓히려고 노드를 몇 대 더했다.
   • 새 Kafka 노드에 올바른 설정을 넣고 클러스터에 배포했다.
   • Apache Storm 으로 하위 컨슈머 시스템을 모두 천천히 다시 켜고, 쌓인 데이터를 다시 처리했다.
   • Amazon S3 에 보관한 원시 데이터로 모든 고객 계정에 데이터를 다시 채우기 시작했다.

   교훈

   호스트와 운영체제의 한계까지 생각하면 장애를 피할 수 있는 시스템은 없다. CPU 와 디스크 I/O 는 장비 상태를 잘 보여 주지만, 서서히 늘어나는 네트워크 사용률은 더 해롭고 지켜보기도 어렵다. CPU 는 100% 의 뜻이 분명하지만 네트워크 사용률 100% 는 대부분의 노드에서 뜻이 분명하지 않고, 특히 VM 이 호스트를 나눠 쓰는 클라우드에서 그렇다. 원시 데이터 보관을 웹 서버 로그, 일반 파일, Amazon S3 업로드처럼 단순한 방식으로 하고 실시간 처리 스트림과 완전히 떼어 둔 덕분에 Parse.ly 는 영구 데이터 손실을 걱정하지 않아도 됐다. 기계 한두 대가 아니라 서브시스템 전체가 꺼져 하위 시스템이 손쓸 수 없게 되는 연쇄 장애 상황을 더 깊이 생각해야 한다.

   사례 보기

원인별2