사례3건

3건 중 1~3번째

1. IL-0213 Consul 클러스터의 KV 쓰기가 느려지고 리더가 뒤처지며 Roblox 전체가 73시간 동안 멈췄다

   Roblox2021

   증상

   2021년 10월 28일 13:37 PST 에 Vault 성능이 떨어지고 Consul 서버 한 대의 CPU 부하가 높아졌다. 이때는 플레이어에게 영향이 없었다.

   지연 시간 증가노드 CPU 고부하서비스 중단모니터링 중단

   촉발

   10월 27일 14:00 PST 에 트래픽 라우팅을 맡는 백엔드 서비스에 Consul 의 새 streaming 기능을 켰다. 같은 롤아웃에서 연말 트래픽에 대비해 트래픽 라우팅 노드 수를 50% 늘렸고, 하루 뒤 Consul 성능이 떨어지기 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리인메모리 캐시

   기여 요인

   단일 장애점장애 중첩모니터링 사각지대수동 조치 악화늦게 드러난 변경

   감지

   10월 28일 13:37 PST 에 Vault 성능 저하와 Consul 서버 한 대의 높은 CPU 부하를 보고 Roblox 엔지니어들이 조사를 시작했다. Consul 클러스터 지표에서 KV 쓰기 지연이 올라간 것을 확인했다.

   조치

   • 하드웨어 성능 저하를 의심해 Consul 클러스터 노드 한 대를 교체했다.
   • 트래픽 증가를 의심해 Consul 클러스터의 모든 노드를 128코어와 더 빠른 NVME SSD 를 단 서버로 바꿨다.
   • Consul 클러스터 전체를 내리고 장애 시작 무렵인 몇 시간 전 스냅샷으로 상태를 되돌렸으며, iptables 로 접근을 막았다가 천천히 풀었다.
   • 외부 트래픽을 막고, Consul 을 쓰는 서비스 목록을 모아 꼭 필요하지 않은 사용을 끄는 설정을 배포했으며, 서비스 인스턴스를 한 자릿수로 줄이고 헬스 체크 간격을 60초에서 10분으로 늘렸다.
   • 경합이 128코어 서버로 옮긴 탓일 수 있다고 보고 Consul 클러스터를 다시 64코어 서버로 옮겼다.
   • 트래픽 라우팅 노드를 포함한 모든 Consul 시스템에서 streaming 기능을 껐고, 설정이 15:51 PST 에 다 퍼지자 KV 쓰기의 p50 지연이 300ms 로 내려갔다.
   • 느린 리더 문제의 원인을 모르는 채로, 문제가 있는 서버가 리더로 뽑힌 채 남지 않게 막았다.
   • 캐시 시스템을 다시 배포했고, 틀어진 스케줄링 데이터와 끝나지 않는 배포 같은 문제를 밤새 찾아 고쳤다.
   • 장애와 문제 분석 중에 내렸던 서비스들을 알맞은 용량으로 다시 띄우고 제대로 도는지 확인했다.
   • DNS 조정으로 무작위로 고른 일정 비율의 플레이어만 들이고 나머지는 정적 점검 페이지로 보냈으며, 데이터베이스 부하와 캐시 성능을 보며 약 10% 씩 늘렸다.

   후속 조치

   • HashiCorp 는 시험 환경에서 이 경합 문제를 재현하는 새 벤치마크를 만들고 대규모 시험을 늘린다.
   • HashiCorp 는 극한 부하에서도 경합이 생기지 않도록 streaming 시스템의 설계를 고친다.
   • 기존 BoltDB 도구로 데이터베이스를 압축하는 절차를 만들어 배포했고, 이것으로 성능 문제가 풀렸다.
   • 텔레메트리 시스템과 Consul 사이의 순환 의존을 없애, 텔레메트리 시스템이 감시 대상 시스템에 기대지 않게 했다.
   • Consul 과 BoltDB 성능, Roblox 서비스와 Consul 사이의 트래픽 패턴을 더 잘 보이게 텔레메트리를 넓혔고, 이번 장애 상태에 가까워지는 신호에 정밀한 알림을 건다.
   • 백엔드 서비스를 둘 지리적으로 떨어진 데이터센터를 하나 더 세웠고, 데이터센터 안에서 여러 가용 영역으로 옮긴다.
   • 서비스들의 Consul KV 와 헬스 체크 사용을 검토해 일부 핵심 서비스를 전용 클러스터로 나눠 중앙 Consul 클러스터의 부하를 줄였다.
   • Consul KV 를 데이터 저장소로 쓰던 핵심 서비스의 데이터를 더 알맞은 저장 시스템으로 옮긴다.
   • 쓰지 않는 KV 데이터를 대량으로 찾아 지웠고, Consul 성능이 좋아졌다.
   • HashiCorp 와 함께 BoltDB 대신 freelist 가 끝없이 커지는 문제가 없는 후속 라이브러리 bbolt 를 쓰는 새 Consul 버전을 배포한다. 연말 최대 트래픽을 피해 새해로 미뤘고 1분기에 끝낸다.
   • 캐시 배포 방식을 다시 설계해 아무것도 없는 상태에서도 캐시 시스템을 빨리 올릴 수 있게 한다.
   • 오래 멈춘 뒤 큰 작업을 다시 올리기 쉽게 하는 Nomad 개선 몇 가지를 HashiCorp 와 찾았고, 다음 Nomad 업그레이드에서 배포한다.
   • 서버 설정을 더 빨리 바꾸는 방법을 만들어 배포했다.
   • 새 streaming 구현을 Roblox 규모와 부하로 시험한 뒤에 조심스럽게 다시 들인다.

   교훈

   Roblox 는 원인 두 가지가 Consul 구현 깊숙이 묻혀 있어 진단이 어려웠던 것이 장애를 길게 만든 주된 이유라고 봤다. 원인을 보여 줄 모니터링 시스템이 장애가 난 Consul 에 기대고 있어 분석이 크게 막혔다. 모든 백엔드 서비스를 Consul 클러스터 하나에 올린 구성이 이런 장애에 취약했다. HashiCorp 는 Roblox 와 비슷한 규모에서 streaming 을 벤치마크했지만, 이 경합은 스트림 수가 많고 교체가 잦은 조건이 겹칠 때만 나타나 전에는 보지 못했다. 더 빠른 하드웨어는 도움이 되지 않았고 오히려 안정성을 해쳤을 수 있다. 오래 완전히 멈춘 상태에서 서비스를 올리는 데도 캐시 배포와 데우기 때문에 시간이 많이 걸렸다.

   사례 보기
2. IL-0261 GCP 네트워크가 잠깐씩 끊기면서 Discord sessions 클러스터 노드가 연달아 망가지고 서비스 전체가 두 번 멈췄다

   Discord2017

   증상

   2017년 11월 17일 PST 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 이어서 sessions 클러스터의 다른 노드들에서 메모리 부족 알림이 차례로 울렸다.

   네트워크 도달 불가메모리 압박서비스 중단

   촉발

   Google 이 Google Cloud Platform 네트워크 스택에 내보낸 업그레이드가 Discord VM 의 네트워크 연결을 짧게 여러 번 끊었다. 네트워크를 많이 쓰는 sessions 클러스터 노드에서만 16번 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   서비스 디스커버리

   기여 요인

   디버그 접근 제한수동 조치 악화

   감지

   17일 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 그 뒤로는 sessions 노드의 메모리 부족 알림으로 당번 엔지니어가 호출됐다. 18일에는 11시 38분 네트워크 문제로 당번 엔지니어가 호출됐고, 11시 40분에 고객 경험 팀이 지원 채널의 신고를 올렸다.

   조치

   • 12시 14분 sessions-1-9 를 안전하게 빼는 절차가 실패하자 노드를 강제로 종료했다. 같은 증상이 난 다른 sessions 노드도 강제로 종료했다.
   • 12시 42분 Google 지원 티켓을 가장 높은 등급인 P1 로 올리고 기술 담당 매니저에게 알렸다.
   • 14시 21분 Discord 의 핵심 서비스 여러 개를 재시작했다. 이 작업으로 연결된 클라이언트 수백만 대가 약 20분에 걸쳐 다시 연결됐다.
   • 17일 밤 강제 종료하고 재부팅한 노드가 다시 망가지지 않는 것을 보고 sessions 클러스터 전체를 종료하고 재부팅하기 시작했다.
   • 18일 12시 4분 서비스 복구를 도우려고 전 세계에서 메시지 전송을 껐다.
   • 18일 12시 4분 sessions 클러스터의 모든 멤버를 재시작했다.
   • 18일 12시 31분 첫 정상화를 알리고 메시지 전송을 다시 켰다.
   • Google 이 금요일에 네트워크 스택에 넣은 소프트웨어 변경을 18일 13시 30분 무렵부터 롤백했고, 15시 30분쯤 롤백이 끝났다.

   후속 조치

   • Discord 를 재부팅해야 했던 이전 장애에서 Erlang 클러스터가 노드 장애를 다루는 방식의 문제를 찾았다. 그 문제를 고치는 프로젝트를 이어 간다.
   • 그 개선을 안전하게 내보낼 수 있도록 이 서비스들의 업그레이드 부하 테스트 방식을 넓힌다.
   • Elixir 와 Erlang 서비스에서 쓰는 HTTP 라이브러리를 바꾼다.
   • Erlang 의 net_kernel 구성 요소에서 본 불안정을 재현했고 수정을 넣었다.
   • 장애 동안 성능이 떨어진 서비스 디스커버리 구성 요소의 일부를 더 성능이 좋은 구현으로 바꾼다.
   • 이번 장애를 Google 과 같이 처리하며 겪은 문제들을 Google 과 함께 고쳐 나간다.
   • P1 문제의 진행 상황을 제대로 추적하도록 Google 과 소통하는 내부 절차를 넓혔다.

   교훈

   Discord 는 두 번의 큰 장애가 그만큼 커진 데에는 Discord 시스템의 성능과 안정성 문제가 크게 작용했다고 봤다. 이런 형태의 네트워크 장애가 서비스의 연쇄 장애를 일으킬 수 있었기 때문이다. 일부 사용자에게만 머물렀어야 할 문제가 시스템 전체 장애 두 번으로 번진 데에는 여러 문제가 있었고, Discord 는 후속 조치로 그 문제 대부분을 풀 수 있다고 봤다.

   사례 보기
3. 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 는 영구 데이터 손실을 걱정하지 않아도 됐다. 기계 한두 대가 아니라 서브시스템 전체가 꺼져 하위 시스템이 손쓸 수 없게 되는 연쇄 장애 상황을 더 깊이 생각해야 한다.

   사례 보기

원인별3