사례24건

24건 중 16~20번째

1. IL-0500 UToronto JupyterHub 의 데이터베이스 디스크가 가득 차서 로그인과 서버 시작이 500 오류로 실패했다

   2i2c2022

   증상

   UToronto JupyterHub 에서 새로 로그인하거나 서버를 시작하려는 사용자가 500 오류를 받았다. 이미 로그인해 있던 사용자는 계속 허브를 쓸 수 있었다.

   오류율 상승영구 볼륨 가득 참

   촉발

   hub 로그가 hub 의 sqlite 데이터베이스와 같은 10G 디스크에 쌓였고, 아주 커진 로그 파일이 디스크를 다 채웠다.

   원인

   용량 한계

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋JupyterHub

   기여 요인

   한계 경보 부재

   감지

   경보가 없었다. 사용자가 오후 7:13 에 [email protected] 로 로그인이 안 된다는 메일을 보내 알게 됐다.

   조치

   • 디스크가 가득 차 로그 파일을 제자리에서 압축할 수 없어서, hub 파드 안에서 gzip < jupyterhub.log > /tmp/jupyterhub.log.gz 로 /tmp 에 압축했다.
   • 파드를 재시작하면 /tmp 의 압축 파일도 사라지므로 kubectl cp 로 압축 파일을 로컬에 먼저 복사했다.
   • 로그를 어떻게 할지 정할 시간을 벌려고 kubectl -n prod edit pvc hub-db-dir 로 hub 데이터베이스 디스크를 10G 에서 60G 로 늘렸다. 크기 조정에도 파드 재시작이 필요해서 로그를 복사한 뒤의 재시작 한 번으로 함께 반영했다.
   • hub 파드를 재시작했다. hub 가 더 큰 디스크로 다시 뜨면서 서비스가 돌아왔다.

   후속 조치

   • hub 로그를 hub 데이터베이스와 같은 디스크에 두지 않는다.
   • Grafana 에 JupyterHub 데이터베이스 디스크의 남은 공간을 보여 주는 그래프를 더한다.
   • 오류율이 오르면 경보를 보낸다. 이 작업은 진행 중이고 2i2c 의 4분기 목표다.

   교훈

   쿠버네티스의 동적 볼륨 크기 조정은 손을 많이 대지 않고도 바로 동작했다. 이 위험은 마이그레이션 때 이미 짚었지만 끝까지 챙기는 절차가 없었다. 2i2c 는 그 뒤로 절차가 많이 나아졌다고 적었다. 경보가 없어서 사람이 알려 줄 때까지 기다려야 했다.

   사례 보기
2. IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.

   GitLab2022

   증상

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.

   지연 시간 증가데이터베이스 과부하OOMKilled오류율 상승

   촉발

   GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도서비스 디스커버리데이터베이스

   기여 요인

   –

   감지

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.

   조치

   • 16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다.
   • 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다.

   후속 조치

   • 메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다.
   • Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다.

   교훈

   파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.

   사례 보기
3. IL-0462 GKE 위 MySQL 파드 일부가 시작과 종료에 오래 걸려 KateSQL 인스턴스 교체가 느려졌다

   Shopify2021

   증상

   KateSQL 의 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉했다. 일부 MySQL 파드는 데이터가 같은 다른 파드보다 시작과 종료가 훨씬 느렸고, 설정 변경이나 업그레이드 같은 유지 보수 때 MySQL 인스턴스를 빨리 교체하기 어려워졌다.

   느린 파드 시작·종료지연 시간 증가

   원인

   소프트웨어 결함

   구성 요소

   리눅스 커널노드 운영체제 이미지데이터베이스

   기여 요인

   미패치 알려진 버그

   감지

   KateSQL 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉한 것을 보고 알았다.

   조치

   • 옛 노드를 cordon 하고, KateSQL 인스턴스 교체로 MySQL 파드를 새 노드로 옮기며 GKE 오토스케일러가 노드를 늘리게 한 뒤, 옛 노드를 drain 해 클러스터를 줄였다. 새 MySQL 파드의 성능이 좋아졌다.
   • `echo 1 | sudo tee /sys/fs/cgroup/memory/kubepods/memory.force_empty` 로 kubepods cgroup 이 죽은 cgroup 을 비우게 해 메모리 cgroup 수를 약 1800개로 줄였다. 재시작한 MySQL 파드는 80G 버퍼 풀을 5초 만에 초기화했다.
   • GKE 1.18 로 새 GKE 클러스터를 만들어 새 MySQL 파드를 그 클러스터에 띄웠다. 몇 주 동안 버퍼 풀 초기화 시간과 질의 성능이 고르게 유지됐다.

   교훈

   이번 조사는 Shopify 데이터베이스 플랫폼 그룹이 한 조사 가운데 가장 오래 걸린 축에 들었다. 문제의 성격, 재현의 어려움, 따를 만한 정해진 방법이 전혀 없었다는 점 때문에 근본 원인을 찾는 데 오래 걸렸다. 그래도 문제를 풀 방법은 여러 가지가 있었다.

   사례 보기
4. IL-0172 AWS 도쿄 리전 한 AZ 의 냉각 장애로 쿠버네티스 위에서 돌던 CockroachDB 노드 60대 중 6대가 22분 만에 죽었고, AZ 토폴로지 설정이 없어 일부 Range 가 정족수를 잃었다.

   Devsisters2021

   증상

   2021년 2월 19일, DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔다. CockroachDB 는 노드 일부가 죽어도 견디도록 만든 분산 데이터베이스라서 데브옵스 엔지니어들은 처음에는 크게 걱정하지 않았다.

   노드 NotReady데이터 유실서비스 중단

   촉발

   AWS 도쿄 리전 데이터센터의 냉각 시스템이 고장 나 그 범위에 있던 DB 서버들이 과열로 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스Helm

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   회식 중에 DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔고, 이어서 다른 노드들의 장애 알람이 Ops 채널에 연달아 들어왔다.

   조치

   • INSERT INTO new_table SELECT * FROM old_table WHERE {unaffected_ranges} 같은 쿼리로 깨진 Range 를 뺀 데이터를 새 테이블로 옮겼다.
   • Cockroach Labs 엔지니어와 화면을 공유하며 debug unsafe-remove-dead-replicas 명령을 실행해 사라진 Data Range 2개 중 하나를 살렸다.
   • 남은 Data Range 하나는 1차 장애 때와 같은 방법으로 스토리지 레이어에서 직접 복원해 유저 데이터를 잃지 않고 복구했다.

   후속 조치

   • Locality 를 설정해 데이터를 여러 AZ 에 고르게 나눠 저장했다.
   • 차트 한 벌에 배포할 AZ 마다 다른 values 파일을 쓰는 방식으로 Locality 를 설정했다.
   • Locality 를 설정한 노드를 기존 클러스터에 넣고 모든 AZ 에 레플리카가 복제된 것을 확인한 뒤, Locality 가 없는 기존 노드를 클러스터에서 뺐다.

   교훈

   쿠키런: 킹덤 정도 규모의 게임에서 멀티 AZ 전략은 선택이 아니라 필수다. 분산 DB 라도 레플리카가 어느 AZ 에 놓이는지 정하지 않으면, AZ 하나가 죽을 때 동시에 잃는 노드 수가 안전 마진을 넘을 수 있다. 차트를 깔끔하게 만드는 것보다 반복적이더라도 확실하게 토폴로지를 설정하는 쪽이 낫다. 클라우드 업체를 믿기보다 스스로 할 수 있는 최대한의 대비를 해 두어야 한다.

   사례 보기
5. IL-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.

   Palark2020

   증상

   RedisFailover 리소스에 바뀐 설정을 적용하자 고객 웹사이트의 가장 큰 Redis 데이터베이스에서 데이터가 모두 사라졌다. 이 데이터베이스는 TTL 없이 영속 저장소로도 쓰였고, .rdb 스냅숏이 5 Gb 를 넘었다. 서비스가 멈췄고 백업에서 데이터를 복원해야 했다.

   데이터 유실서비스 중단

   촉발

   RedisFailover 리소스에서 Redis 레플리카 수를 1에서 2로 늘리면서, 같은 변경으로 컨테이너의 메모리 requests 와 limits 를 22 GB 에서 19 GB 로 낮췄다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋컨테이너 메모리 한도

   기여 요인

   단계적 배포 부재단일 장애점미검증 가정

   조치

   • 미리 준비해 둔 백업에서 Redis 데이터를 복원했다.

   후속 조치

   • 레디니스 프로브 문제를 Redis Operator 이슈로 올렸고, 개발자들에게서 받은 수정을 시험해 통과를 확인했다.
   • 상황 분석을 마친 뒤 Spotahome Redis Operator 를 계속 쓸지 다시 검토한다.
   • Redis 데이터베이스를 정리하고, 불필요한 키를 만든 애플리케이션 코드를 고친다.
   • Redis 의 내장 클러스터링과 샤딩을 검토한다.

   교훈

   핵심 인프라를 쿠버네티스 오퍼레이터로 관리할 때는 그 오퍼레이터가 얼마나 성숙하고 검증됐는지 따져 봐야 한다. 레플리카 수와 리소스 값을 한 번에 바꾸면 롤링 업데이트가 예상하지 못한 순서로 파드를 재시작할 수 있다. 레디니스 프로브가 ping 만 보면 복제가 끝나지 않은 빈 인스턴스도 준비됐다고 판단한다. Redis 클러스터를 바꾸기 전에는 반드시 dump.rdb 파일을 백업해야 한다.

   사례 보기

원인별7