사례7건

7건 중 6~7번째

1. IL-0215 Twilio 결제 시스템의 Redis 가 잔액 데이터를 잃고 읽기 전용이 되어 자동 충전 고객의 신용카드가 반복 결제됐다

   Twilio2013

   증상

   2013년 7월 18일 2:42 AM PDT 에 모니터링 시스템이 결제용 Redis 클러스터의 장애를 당번 엔지니어에게 알렸다. redis-master 호스트의 부하가 극도로 높았고, redis-master 에 기대는 서비스들이 실패하고 있었다.

   데이터베이스 과부하데이터 유실쓰기 거부

   촉발

   7월 18일 1:35 AM PDT 에 네트워크 연결이 끊겨 결제용 redis-slave 전부가 동시에 redis-master 와 끊겼고, 다시 붙으면서 한꺼번에 전체 동기화를 요청했다. 부하가 높아진 redis-master 를 당번 엔지니어가 재시작했다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스 복제

   기여 요인

   재시도 폭주수동 조치 악화안전하지 않은 실패 동작

   감지

   2:42 AM PDT 에 모니터링 시스템이 Redis 클러스터 장애를 당번 엔지니어링 팀에 알렸다. 잘못된 결제는 3:28 AM PDT 에 결제 시스템 모니터링이 이상 동작을 보고해 알았고, 12:36 PM PDT 에는 모니터링이 같은 이상의 재발을 찾았다.

   조치

   • 2:42 AM PDT 에 당번 엔지니어가 높은 부하를 해결하려고 redis-master 를 재시작했다.
   • 4:10 AM PDT 에 신용카드 결제가 더 일어나지 않게 결제 시스템을 내렸다.
   • 6:24 AM PDT 에 정지된 계정을 모두 되살렸고, 결제 시스템은 원인을 조사하는 동안 꺼 둔 채로 뒀다.
   • 별도 관계형 데이터 저장소에 따로 적어 둔 잔액 기록으로 redis-master 에서 잃은 계정 잔액을 복원했다.
   • 12:36 PM PDT 에 같은 이상이 다시 나타나자 결제 시스템을 다시 내리고 정지된 계정을 바로 되살렸다.
   • 2:57 PM PDT 부터 잘못된 신용카드 결제를 환불해 7월 19일 3:00 PM PDT 에 모두 마쳤다.
   • 7월 19일 3:30 PM PDT 에 영향받은 모든 계정에 최근 30일 Twilio 사용액의 10% 를 크레딧으로 줬다.
   • 장애를 일으킨 원래 Redis 클러스터를 교체했고, redis-master 의 잘못된 설정을 찾아 고쳤다.
   • 7월 19일 7:10 PM PDT 부터 고객 계정 묶음마다 결제 시스템을 차례로 켰다.

   후속 조치

   • redis-master 의 Redis 재시작을 막고, 앞으로 redis-master 복구는 slave 를 승격해 처리한다.
   • 결제 잔액이 없거나 쓸 수 없으면 계정을 정지하거나 신용카드를 결제하지 않도록 안전장치를 넣는다.
   • 결제 시스템이 잔액을 따로 적어 두는 데이터베이스와 실시간으로 대조하게 바꾼다.

   교훈

   Twilio 는 현재 잔액 데이터와 잔액을 갱신하는 능력을 동시에 잃자 자동 충전 시스템이 위험한 방향으로 실패했다고 봤다. 잔액이 없거나 쓸 수 없을 때 자동 충전 시스템은 계정을 정지하지 않고 카드를 결제하지 않는 쪽으로 멈춰야 했다.

   사례 보기
2. IL-0274 GitHub 코드 검색의 elasticsearch 클러스터에서 일부 노드 CPU 가 100% 에 가깝게 차고 마스터가 계속 바뀌면서 검색과 색인이 타임아웃되고 샤드 데이터가 사라졌다

   GitHub2013

   증상

   2013년 1월 24일 목요일 예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다. 예외 대부분은 코드 검색 질의의 타임아웃과, 새 push 의 데이터로 코드 검색 색인을 갱신하는 백그라운드 작업의 타임아웃이었다.

   간헐적 타임아웃노드 CPU 고부하스플릿 브레인데이터 유실

   촉발

   2013년 1월 17일 코드 검색 클러스터를 elasticsearch 0.19.9 에서 0.20.2 로 업그레이드했다. 그 뒤 코드 검색을 공개하자 클러스터에 높은 부하가 걸렸고 메모리 할당이 계속 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   Elasticsearch 와 OpenSearch언어 런타임 설정

   기여 요인

   기본 설정 방치미뤄 둔 업그레이드시험하지 않은 변경초기 신호 무시수동 조치 악화

   감지

   예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다.

   조치

   • 클러스터를 완전히 멈추고, 샤드 할당과 재균형을 끄는 "maintenance mode" 로 다시 올렸다.
   • elasticsearch 를 개발하고 지원하는 회사의 엔지니어 두 명에게 도움을 청했다.
   • 두 엔지니어의 권고대로 Java 와 elasticsearch 를 곧바로 업그레이드하고 설정을 바꿨다. Puppetmaster 에 이 변경 전용 토픽 브랜치와 환경을 만들고 각 노드에서 Puppet 을 돌렸다.

   후속 조치

   • 코드 검색 클러스터의 스테이징 환경을 만들어 인프라 변경을 더 잘 시험한다.
   • elasticsearch 팀이 앞으로도 코드 검색 클러스터 설정을 다시 점검해, 쓰임새에 맞게 유지되도록 한다.

   교훈

   GitHub 는 elasticsearch 0.20.2 를 코드 검색 클러스터에 내보내기 전에 자기 인프라에서 충분히 시험하지 않았고 다른 클러스터에서도 시험하지 않았다. 코드 검색 클러스터에 제대로 된 스테이징 환경이 없던 것이 한 요인이었다. elasticsearch 팀은 큰 클러스터에 이렇게 권했다. ES_HEAP_SIZE 환경 변수로 JVM 의 최소·최대 메모리를 같게 하고 시스템 RAM 의 50% 로 둔다. recover_after_time 을 30분으로 두지 말고 복구가 바로 시작되게 한다. minimum_master_nodes 를 설정해 노드가 오래 멈출 때 노드 일부가 따로 클러스터를 이루지 않게 한다.

   사례 보기

원인별4