사례3건

3건 중 1~3번째

1. IL-0288 CDN77 의 ClickHouse 데이터 파이프라인에서 이중화된 인스턴스 세 곳의 ZooKeeperWait 가 수천 초로 치솟아 복제가 한 시간 넘게 느려졌다

   CDN772026

   증상

   13:30 UTC 에 ZooKeeperWait 지표가 갑자기 오른다는 알림이 왔다. 이 클러스터의 알림 기준은 낮은 쪽 10초, 높은 쪽 20초인데 값은 수천 초였다. 값은 대칭으로 이중화된 인스턴스 세 곳에서 똑같이 올랐다.

   복제 지연처리량 저하

   촉발

   몇 달 동안 네트워크에서 떨어져 있던 클라이언트 머신 두 대가 다시 연결되면서, 그동안 쌓인 몇 달 치 헬스 체크 데이터를 아주 작은 배치로 빠르게 보냈다.

   원인

   용량 한계

   구성 요소

   데이터베이스코디네이션 키-값 저장소데이터베이스 복제텔레메트리 에이전트

   기여 요인

   모니터링 사각지대기본 설정 방치초기 신호 무시

   감지

   13:30 UTC 에 팀은 ZooKeeperWait 지표가 갑자기 오른다는 알림을 받았다. 이 클러스터 크기에 맞춘 알림 기준은 낮은 쪽 10초, 높은 쪽 20초였다.

   조치

   • 쌓인 파트를 끝내 정리하지 못한 5분 단위 파티션 테이블을 장애 뒤 DROP-CREATE 로 다시 만들어 정상으로 되돌렸다.
   • 그 테이블의 파티션 단위를 분에서 시간으로 넓혔다.

   후속 조치

   • 루트 MaterializedView 테이블에서 범위를 벗어난 타임스탬프를 거부하도록 구현했다.
   • 두 번째 MaterializedView 가 거부된 데이터의 통계를 기록한다.
   • 거부 범위는 과거 데이터 백필을 위해 일부러 넓게 잡았고, 거부되는 데이터를 모아 가며 범위를 다듬는다.
   • 타임스탬프가 며칠이나 몇 달에 걸친 insert 쿼리 하나로 이번 상황을 재현하는 최소 시험 시나리오를 만들었다.
   • 관측 기능을 여러 가지 개선한다.

   교훈

   이 파이프라인은 주로 데이터 양을 다루지만, 어긋난 타임스탬프도 카디널리티 변화만큼 파이프라인을 흔들 수 있었다. 이상한 지표를 바로 설명하지 못했다고 치워 두면 안 된다. 이번에도 원인으로 이끈 것은 처음에 무시한 insert 크기 감소였다. 중앙값과 평균은 각자 쓸모가 있고, 이번에는 평균이 실마리였다. 파티션이 너무 적으면 파트가 커지고 mutation 이 느려지며 TTL 이 너무 비싸지거나 아예 동작하지 않는다. 반대로 너무 많으면 열 스캔과 집계 쿼리가 느려지고 Keeper 가 과부하된다. Keeper 작업은 파트 수에 따라 선형보다 훨씬 빠르게 늘었다.

   사례 보기
2. 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에 어떤 영향을 주는지 이해하는 것이 중요했다.

   사례 보기
3. IL-0443 Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다

   Repro2019

   증상

   Aurora MySQL 의 reader 가 이유를 알 수 없이 재시작했다. 그 직후부터 writer 의 insert latency 가 7배쯤 오르는 등 writer 성능이 크게 떨어진 상태가 오래 이어졌다. 같은 일이 2019년 11월 두 주 사이에 두 번 일어났다.

   지연 시간 증가복제 지연처리량 저하

   촉발

   reader 에서 오래 도는 쿼리 때문에 롤백 세그먼트가 계속 커진 끝에 reader 가 재시작했다. 글쓴이는 그 쿼리가 Redash 에서 reader 로 보낸 것이었다고 기억한다.

   원인

   용량 한계

   구성 요소

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

   기여 요인

   모니터링 사각지대

   조치

   • 팀은 writer 성능이 원래대로 돌아올 때까지 지켜보기만 했다.

   후속 조치

   • 롤백 세그먼트 길이를 Datadog 의 mysql.innodb.history_list_length 로 감시하는 모니터를 더했다.
   • reader 가 재시작할 만큼 오래 도는 쿼리를 찾으면 바로 kill 하게 했다.
   • 모니터 알림이 거의 매주 울리게 되자 사내에 알린 뒤 max_execution_time 을 설정해, 일정 시간이 지난 쿼리를 강제로 끝내게 했다.

   교훈

   롤백 세그먼트가 커지지 않도록 트랜잭션을 작게 해야 한다. 롤백 세그먼트는 클러스터 전체가 함께 쓰므로, 한번 커지면 인스턴스를 바꿔도 해제가 끝나기를 기다리는 수밖에 없다. 롤백 세그먼트 길이는 show engine innodb status 의 "History list length" 값으로 볼 수 있다.

   사례 보기

원인별2