사례2건

2건 중 1~2번째

1. IL-0173 Let's Encrypt 가 기본 체인을 바꾼 뒤 cert-manager 의 preferredChain 처리 버그로 만료된 DST Root CA X3 체인 인증서가 발급돼, 구버전 BoringSSL 을 쓰는 클라이언트가 개발 서버에 접속하지 못했다.

   Devsisters2024

   증상

   2024년 2월 13일, 설 연휴를 마치고 돌아온 데브시스터즈 인프라셀에 개발 서버에 접속이 안 된다는 요청이 들어왔다. 연휴 직후라 사람이 손댄 변경은 없었다.

   TLS 인증서 오류

   촉발

   Let's Encrypt 가 DST Root CA X3 단계적 폐기의 첫 단계로 2024년 2월 8일부터 기본 체인을 ISRG Root X1 체인으로 바꾸고, DST Root CA X3 체인을 대체 체인으로 내주기 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   cert-manager

   기여 요인

   –

   감지

   설 연휴 뒤인 2월 13일 개발 서버에 접속이 안 된다는 요청이 인프라셀에 들어왔다. 서버가 내주는 인증서 체인을 열어 보다가 만료된 DST Root CA X3 체인이 서빙되는 것을 발견했다.

   조치

   • cert-manager 의 preferredChain 선택 로직을 고치는 PR 을 올렸고, PR 은 머지됐다.

   교훈

   오래 숨어 있던 버그가 외부 서비스의 기본값 변경으로 갑자기 드러날 수 있다. 이번에는 Let's Encrypt 가 기본 체인을 바꾸면서 cert-manager 의 체인 선택 버그가 드러났다. 여기에 신뢰 앵커의 만료일을 검사하고 최상위 인증서를 무조건 검증하려는 구버전 BoringSSL 을 쓰고 있어서 접속 장애로 이어졌다. ACME 클라이언트마다 체인을 고르는 방식이 달라서, 설정한 preferredChain 과 실제로 발급된 체인이 다를 수 있다.

   사례 보기
2. 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 하나가 죽을 때 동시에 잃는 노드 수가 안전 마진을 넘을 수 있다. 차트를 깔끔하게 만드는 것보다 반복적이더라도 확실하게 토폴로지를 설정하는 쪽이 낫다. 클라우드 업체를 믿기보다 스스로 할 수 있는 최대한의 대비를 해 두어야 한다.

   사례 보기

원인별2