사례33건

33건 중 11~15번째

1. IL-0526 HE.net 암스테르담 라우팅 장비 고장으로 OpenStreetMap.org 의 이중 광 회선이 모두 끊김

   OpenStreetMap Foundation2024

   증상

   2024년 12월 15일 03:53 UTC 에 OpenStreetMap.org 에 접속할 수 없게 됐고, 04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈다. 웹사이트와 지도 API 가 완전히 내려갔다.

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

   촉발

   2024년 12월 15일 03:53 UTC 에 HE.net 의 암스테르담 라우팅 장비가 예기치 않게 고장 났다.

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망데이터베이스 복제

   기여 요인

   단일 장애점런북 부재

   감지

   04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈고, 곧바로 운영 팀에 알려졌다.

   조치

   • 11:31 UTC 에 더블린에 있는 OpenStreetMap.org 의 읽기 전용 백업 인스턴스를 켜 일부 기능을 되살렸다. 사이트에는 편집 내용을 저장할 수 없다는 점검 안내를 띄웠다.
   • 12월 17일 12:21 UTC 에 HE.net 을 거치지 않는 새 Equinix Internet 회선을 암스테르담에서 개통해 OpenStreetMap.org 와 API 의 모든 기능을 되살렸다.
   • 12월 18일 00:29 UTC 에 HE.net 이 암스테르담 서비스가 복구됐다고 확인했고, HE.net 경로가 정상으로 돌아와 OpenStreetMap.org 의 모든 네트워크 경로를 다시 쓸 수 있게 됐다.

   후속 조치

   • 한 사업자가 고장 나도 다른 사업자로 거의 끊김 없이 넘어가도록 여러 ISP 를 쓰는 구성으로 옮긴다.
   • 암스테르담 서버의 예비 ISP 후보를 대역폭, 신뢰성, 비용으로 비교한다. 2025년 2월 Karlsruhe Hack Weekend 에서 BGP 를 쓰는 방안과 HE.net 을 예비 ISP 로 남기는 방안을 포함해 실제 선택지를 논의한다.
   • 경로와 지연 시간을 더 깊이 모니터링해 ISP 문제를 빨리 잡고, 자동 에스컬레이션 절차를 만든다.
   • ISP 사이 트래픽 전환을 시험하는 페일오버 훈련 일정을 정하고, 복제 과정이 최신이며 믿을 만한지 확인해 사이트 페일오버를 부담 없이 쓸 수 있는 선택지로 만든다.
   • HE.net, Equinix Internet 과 계약상 SLA 를 협의하고, 정해진 에스컬레이션 절차와 응답 시간을 계약에 넣는다.
   • 대역 외 접속에 쓰는 Raspberry Pi 4 와 4G 모뎀을 ISP 장애 때 수동 예비 업링크로 쓸 수 있게 미리 설정한다. 이 회선으로 서버에 접속하고 Postgres 복제 데이터를 보조 사이트로 동기화한다. 대역 외 장비는 견고하고 이중화되도록 업그레이드한다.
   • 장애 소식을 알리는 일을 맡을 이해관계자와 각자의 책임, 권장 소통 채널을 정리한 문서를 만든다. 운영 팀은 소통을 다른 사람에게 맡기고 복구에 집중한다.
   • OpenStreetMap.org 의 "rails-port" 유지 관리자가 OAuth 서비스를 분리해, 사이트가 흔들릴 때도 제3자 서비스의 인증이 계속 동작하게 할 수 있는지, 그 방법이 현실적인지 조사한다.

   교훈

   암스테르담 서버가 HE.net 하나에만 기대고 있어 단일 장애 지점이 생겼고, 앞으로는 상위 사업자를 여럿 둔다. 4G 예비 회선을 쓴 대역 외 접속이 아주 쓸모 있었으므로, 데이터 동기화까지 할 수 있게 신뢰성과 기능을 넓힌다. 읽기 전용 백업으로 일부 서비스는 됐지만, 복제가 이어지고 있었다면 편집 기능을 더 빨리 되살렸을 것이다. ISP 와 자주 연락해도 쓸 만한 복구 예상 시각을 받지 못했으므로, SLA 를 더 잘 이해하고 ISP 에 더 투명하게 알려 달라고 요구해야 한다. 상위 연결의 알림을 다듬고 여러 모니터링 출처의 데이터를 한데 모아야 문제를 더 빨리 짚을 수 있다. OpenStreetMap.org 가 읽기 전용이 되면 새 토큰을 저장하지 못해, 장애와 무관한 community.openstreetmap.org 같은 서비스에도 로그인할 수 없게 된다.

   사례 보기
2. IL-0392 데이터센터 전환을 앞두고 원형 복제를 설정하던 중 Wikimedia x1 섹션의 eqiad·codfw 사이 MariaDB 복제가 6분 멈췄다

   Wikimedia Foundation2024

   증상

   2024년 9월 18일 데이터센터 전환을 앞두고 cookbook 으로 원형 복제를 설정하던 중, 21:28 UTC 쯤 엔지니어가 x1 섹션의 primary master 가 복제를 하지 않는 것을 orchestrator 에서 먼저 알아챘다. es6 섹션도 같은 상태였다.

   복제 지연

   촉발

   다음 주 데이터센터 전환을 앞두고 cookbook 이 핵심 데이터베이스를 eqiad 에서 codfw 로 가는 한 방향 복제에서 원형 복제로 바꿨다. ROW 기반 복제를 쓰는 x1 섹션에 codfw 에서 eqiad 로 가는 복제를 설정하고 pt-heartbeat 를 시작하자, eqiad 서버에 없는 heartbeat 행을 갱신하려다 복제가 멈췄다.

   원인

   설정 변경

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   모니터링 사각지대자동 테스트 공백수동 조치 악화

   감지

   원형 복제의 일반 모니터링이 아직 켜지지 않아, 엔지니어가 orchestrator 에서 먼저 알아챘다. 복제 자동화가 처음 도는 날이라 평소보다 많은 사람이 데이터베이스 상태를 지켜보고 있었다. 사용자에게 영향을 준 eqiad 에서 codfw 로 가는 방향의 고장은 Icinga 알림이 잡았다. 온콜 호출을 받은 사람은 없었다.

   조치

   • SET GLOBAL Replication_wild_ignore_table='heartbeat.%'; 로 heartbeat 테이블 복제를 건너뛰게 해 복제가 다시 흐르게 했다.
   • es 호스트에는 원래 고장이 난 방향에 맞춰, binlog 기록을 끈 채 eqiad 서버마다 빠진 codfw heartbeat 행을 직접 넣었다. 명령은 set sql_log_bin=0; INSERT INTO heartbeat.heartbeat (server_id, shard, datacenter) VALUES (<codfw-server-id>, 'es6' [or 'es7'], 'codfw'); 였다. es6 에서 먼저 시험했고, es7 에는 원형 복제를 설정하기 전에 미리 넣었다.
   • x1 codfw 호스트마다 binlog 기록을 끈 채 빠진 heartbeat 행을 넣어, 임시로 걸어 둔 heartbeat 무시 설정을 대신했다. 명령은 set sql_log_bin=0; INSERT INTO heartbeat.heartbeat (server_id, shard, datacenter) VALUES (<eqiad-server-id>, 'x1', 'eqiad'); 였다.

   후속 조치

   • 같은 문제를 다시 겪지 않게 한다. 빠진 행을 찾으면 직접 넣는 방식을 유력하게 본다.
   • 유지 보수 뒤 복제가 의도대로 양방향으로 동작하는지 확인하는 상태 점검을 cookbook 에 넣는다.
   • 유지 보수를 다른 순서로, 또는 섹션마다 따로 돌릴 수 있는 옵션을 더한다.
   • Phabricator 를 마지막에 한 번만 갱신하지 않고 섹션마다 갱신한다.
   • 모니터링의 빈틈을 메운다.
   • x1 과 ROW 를 쓰는 읽기·쓰기 es 호스트에서 pt-heartbeat-wikimedia 가 자기 세션을 STATEMENT 로 쓰도록 고쳐 배포했다.

   교훈

   원형 복제는 평소 운영 방식이 아니어서 heartbeat 테이블을 지우는 첫 조치가 문제를 eqiad 에서 codfw 로 옮기기만 했다. TRUNCATE 는 DDL 이라 늘 STATEMENT 모드로 전달되므로 이번에는 DELETE 보다 나았겠지만, 더 위험해서 고려하지 않았다. ROW 기반 복제, pt-heartbeat, 서버마다 다른 heartbeat 테이블 행이 겹친 문제는 이전 유지 보수 기록에 없었다. 자동화의 점검은 설정 직후 한 번이 아니라 모든 작업이 끝난 뒤에도 복제 채널을 확인했어야 했다. Wikimedia 는 어느 호스트에서도 sql_skip_slave_counter 를 쓰지 않아 더 큰 문제나 데이터 손실을 피한 것을 잘된 점으로 꼽았다.

   사례 보기
3. IL-0374 DigitalOcean 내부 서비스 디스커버리가 전 리전에서 멈춰 생성, 이벤트 처리, 제어판과 API 관리가 실패했다

   DigitalOcean2024

   증상

   2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.

   서비스 중단클러스터·노드 생성 정체

   촉발

   새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다.

   원인

   설정 변경

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리데이터베이스 복제

   기여 요인

   과도한 영향 범위

   감지

   16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다.

   조치

   • 17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다.
   • 18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다.
   • 남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다.

   후속 조치

   • 이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다.
   • 이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다.
   • 이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다.
   • 여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다.

   사례 보기
4. IL-0488 EBS 성능 저하 뒤 Kit의 RDS MySQL 쓰기 지연이 100배 넘게 늘어 Sidekiq 작업 처리가 느려졌다

   Kit2022

   증상

   2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수가 9에서 900으로 100배 뛰었다는 첫 호출이 왔다. 크리스마스이브 새벽이라 트래픽이 아주 적은 시간이었다.

   데이터베이스 과부하처리량 저하

   촉발

   스탠바이 서버의 EBS 중단으로 RDS가 replaceSecondaryHostAndVolumesTask를 실행해 스탠바이의 호스트와 볼륨을 교체했다. 새 볼륨은 프라이머리 볼륨의 스냅숏으로 다시 만들어져 AWS가 first touch penalty라고 부른 쓰기 지연이 있었고, 동기 복제 때문에 프라이머리의 쓰기 지연이 함께 늘었다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스클라우드 블록 스토리지데이터베이스 복제

   기여 요인

   초기 신호 무시

   감지

   2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수 급증 알림이 당번 엔지니어를 호출했다. 원인이 된 EBS 성능 저하는 전날 밤 AWS RSS 피드 알림으로 Slack에 들어왔지만 그때는 넘어갔다.

   조치

   • RDS 인스턴스의 스토리지를 12.5TB에서 13.75TB로 늘렸다. 이 과정에서 RDS가 optimizing storage 상태를 거치며 EBS 볼륨을 옮겼고, 쓰기 지연이 1~2ms로 돌아왔다.

   교훈

   AWS Multi-AZ는 동기 복제로 데이터 정합성과 내구성을 지키지만, 모든 트랜잭션을 스탠바이에도 커밋해야 하므로 스탠바이의 EBS 볼륨이 나빠지면 쓰기 지연도 나빠진다. 데이터베이스가 클수록 이런 일에서 회복이 오래 걸린다. 단일 AZ였다면 이번 일은 영향이 없었겠지만, 영향을 받은 가용 영역에 서버가 있었다면 몇 시간 동안 멈췄을 것이다. 운영 RDS의 배치 방식을 정할 때는 이런 득실을 따져야 한다. RDS와 EBS가 어떻게 동작하고 Kit에 어떤 영향을 주는지 이해하는 것이 중요했다.

   사례 보기
5. IL-0308 RevenueCat 이 Aurora PostgreSQL 10 에서 14 새 클러스터로 넘어간 직후 쿼리가 극도로 느려져 대시보드와 SDK 엔드포인트가 세 시간 넘게 실패했다

   RevenueCat2022

   증상

   2022년 11월 23일 9:39 UTC 에 트래픽 전부가 새 Aurora PostgreSQL 14.x 클러스터로 넘어갔고, 지연이 나빠져 인프라 팀이 조사를 시작했다. 9:54 UTC 에는 쿼리가 평소보다 훨씬 오래 걸리면서 데이터베이스 연결을 모두 차지하고 있었다.

   데이터베이스 과부하지연 시간 증가서비스 중단커넥션 풀 고갈

   촉발

   복제를 이용해 Aurora PostgreSQL 10.x 클러스터에서 새 14.x 클러스터로 트래픽을 넘겼다. 그런데 가장 큰 테이블 하나의 vacuum 이 전환 전에 끝나지 않아, 새 클러스터의 가장 큰 테이블들에 ANALYZE 가 돌지 않은 상태였다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 프록시와 커넥션 풀러쿼리 플래너와 테이블 통계

   기여 요인

   스테이징 불일치미검증 가정자동화 증폭모니터링 사각지대

   감지

   9:39 UTC 에 트래픽 전부가 새 클러스터로 넘어갔을 때 지연이 나빠 보였고, 인프라 팀이 바로 조사를 시작했다.

   조치

   • 9:54 UTC 에 쿼리가 데이터베이스 연결을 너무 오래 잡지 않도록 데이터베이스 사용자에 statement timeout 을 걸었다.
   • 9:58 UTC 에 로드 밸런서에서 트래픽의 90% 에 503 을 보내 부하를 덜고 시스템이 회복할 여유를 만들었다.
   • 10:00 UTC 무렵부터 오래 걸리는 쿼리에 EXPLAIN 을 돌려 보고, 해만 끼치고 필요 없는 인덱스를 지우기 시작했다.
   • 트래픽을 100% 로 되돌리는 동안 Apple 웹훅을 잠시 받지 않았다.
   • New Relic 이 느린 쿼리마다 돌리는 EXPLAIN 쿼리를 없애려고 New Relic 을 끈 새 릴리스를 냈다.
   • 12:00 UTC 무렵부터 가장 큰 테이블들에 손으로 ANALYZE 를 돌렸다.
   • 미리 준비해 둔 스크립트로 영향받은 시퀀스 값을 자동으로 올려 기본 키 중복을 풀었다.
   • 전환 몇 분 뒤 통합 이벤트 발송 작업이 이벤트 테이블을 갱신하지 못하는 것을 잡고 발송 작업을 손으로 멈췄다.
   • 발송되었지만 데이터베이스에 기록되지 않은 웹훅을 만일에 대비해 다시 보냈다.
   • 13:33 UTC 에 통합 이벤트 발송, ETL, 웹 서버 밖의 작업을 모두 되살렸다.

   후속 조치

   • 사업에 중요한 시기에는 변경 동결을 두는 것을 검토한다.
   • 백엔드 장애 때 SDK 가 얼마나 믿을 만하게 동작하는지 더 잘 알린다.
   • 개발자 대시보드와 기술 담당자에게 보내는 직접 이메일을 써서 유지보수와 장애를 고객에게 더 잘 알린다.
   • 사전 연습에서 트래픽 일부를 재생해 전환 당일과 더 비슷한 조건을 만든다. 이번 연습은 쓰기 트래픽을 재생하지 않았다.
   • API 를 빠르고 안정적으로 유지하려고 비용이 큰 작업을 최대한 비동기로 옮기는 데 더 투자한다.
   • 테이블 인덱스를 다시 검토한다. 쓰이지 않는 인덱스가 있고, 데이터베이스가 쿼리에 그 인덱스를 고르면 성능이 떨어질 수 있다.
   • 데이터베이스 대시보드에서 엔드포인트와 시스템별 부하를 더 잘 보여 줘 부하가 어디서 오는지 빨리 찾게 한다. 이번에는 Apple 웹훅 부하가 복구를 막는다는 것을 아는 데 너무 오래 걸렸다.
   • 장애 중에 고객 지원과 고객 커뮤니케이션 담당을 불러 소통을 맡긴다.

   교훈

   RevenueCat 은 처음부터 롤백했으면 더 나았다고 돌아봤다. 사전 연습에서는 데이터 일관성과 쿼리 성능만 보고 쓰기 트래픽을 재생하지 않았다. 쓰기는 인덱스가 얽히지 않아 읽기보다 단순하다고 여겼기 때문이다. 복제를 멈추고 평소처럼 쓰기를 해 봤다면 문제를 찾을 수 있었다. 시퀀스 상태가 복제되지 않는다는 한계를 놓치고 상태도 함께 복제된다고 가정했다. 사전 연습 때는 새 클러스터가 오래 떠 있어 vacuum 과 통계가 이미 끝나 있었기 때문에 ANALYZE 가 없는 문제를 보지 못했다. 시기로는 추수감사절과 블랙 프라이데이 전에 끝내려 했지만, 미국 지원팀 일부가 이미 휴가 중인 민감한 때였으므로 그다음 주로 미뤘어야 했다고 밝혔다.

   사례 보기

원인별11