사례35건

35건 중 16~20번째

1. IL-0105 VPC CNI 교체로 ALB 에서 타깃 그룹이 떨어져 나가 쿠버네티스 클러스터의 모든 서비스가 503 을 냈다

   DFDS2021

   증상

   2021-06-22 08:29 UTC 에 알림이 울렸다. 쿠버네티스 클러스터로 들어오는 트래픽이 모두 실패했고, 모든 서비스가 503 을 냈다.

   서비스 중단오류율 상승

   촉발

   EKS 애드온을 kubectl 대신 Terraform 으로 관리하려는 리팩터링과 정리 작업 중에 파이프라인이 VPC CNI 를 교체했다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI클라우드 로드 밸런서Terraform

   기여 요인

   미검증 가정설정 테스트 부재

   감지

   08:29 UTC 에 알림으로 감지했다. 파이프라인이 VPC CNI 를 교체한 지 8분 뒤였다. 08:32 에는 고객도 문제를 알려 왔다.

   조치

   • infrastructure-modules 참조를 되돌리는 수정을 커밋했다.
   • AWS API 타임아웃으로 멈춘 파이프라인을 다시 돌렸다.
   • 파이프라인이 타깃 그룹을 ALB 에 다시 붙였다.

   후속 조치

   • ALB 의 등록 해제 지연을 기본값 300초로 되돌린다.
   • 노드 교체 스크립트가 교체 전에 ALB 등록 해제 지연을 잠시 0 으로 낮추도록 고친다.
   • Ingress 테스트 스위트를 만든다.

   교훈

   팀은 등록 해제 지연을 주로 성능 측면에서만 보고 바꿨다. 중요한 파이프라인 실행은 끝날 때까지 지켜봐야 한다. 알림은 모든 사람이 받고 대응해야 한다. 뜻이 분명하지 않은 알림 문구는 고쳐 써야 한다.

   사례 보기
2. IL-0197 Elasticsearch StatefulSet 을 새 퍼시스턴트 볼륨으로 옮기던 중 빈 볼륨으로 다시 뜬 elasticsearch-0 이 혼자 새 클러스터를 만들어 스플릿 브레인이 났다.

   Palark2021

   증상

   옛 노드 세 개를 하나씩 새 StorageClass 의 볼륨으로 바꾸다가 마지막으로 elasticsearch-0 파드를 지우고 다시 띄웠다. elasticsearch-0 안에서 `_cat/nodes` 를 조회하자 자기 자신 하나만 마스터로 나왔다.

   스플릿 브레인

   촉발

   옛 PVC 와 파드를 지운 뒤 elasticsearch-0 이 새 StorageClass 의 빈 볼륨을 받아 다시 시작했다.

   원인

   운영 실수

   구성 요소

   Elasticsearch 와 OpenSearch영구 볼륨과 스테이트풀셋Helm

   기여 요인

   미검증 가정

   감지

   마지막으로 0번 파드를 교체한 뒤 엔지니어가 elasticsearch-0 과 elasticsearch-1 안에서 각각 `_cat/nodes` 를 조회했다. 두 결과가 서로 다른 노드 목록과 다른 마스터를 보여 스플릿 브레인을 알아챘다.

   조치

   • 데이터를 실시간으로 쓰는 워커의 디플로이먼트 세 개를 0으로 줄여 새 데이터가 갈라진 클러스터로 들어가지 않게 했다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-0, elasticsearch-1, elasticsearch-2 로 바꾸고 StatefulSet 에서 cluster.initial_master_nodes 환경 변수를 지웠다.
   • 롤링 업데이트가 도는 동안 디스커버리용 elasticsearch Service 를 YAML 로 저장한 뒤 지우고, 0번 파드의 PVC 도 지웠다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-3, elasticsearch-4, elasticsearch-5 로 바꾸고, 0번 파드의 빈 PVC 를 만든 뒤 파드 6개를 모두 지워 다시 띄웠다.
   • 저장해 둔 YAML 로 Service 를 다시 만들었다. 노드 6개가 한 클러스터로 모였고 green 이 아닌 인덱스는 0개였다.

   후속 조치

   • ConfigMap 의 initial_master_nodes 를 원래 값으로 되돌리고 모든 파드를 한 번 더 재시작한다.
   • 모든 샤드를 0, 1, 2번 노드로 옮기고 클러스터를 노드 6개에서 3개로 줄인다.
   • 손으로 바꾼 내용을 모두 저장소에 커밋한다.

   교훈

   운영 데이터를 옮길 때는 설정 오류, 데이터센터 장애, 네트워크 단절처럼 무언가 잘못될 수 있다는 전제로 준비해야 한다. 이번에 쓴 다운타임 없는 절차는 예상하지 못한 문제에 약했다. 팀은 ConfigMap 을 꼼꼼히 확인했지만 Helm 차트 템플릿이 StatefulSet 에 넣는 환경 변수는 보지 않았다. cluster.initial_master_nodes 가 파드 하나로 고정된 상태에서 그 파드가 빈 볼륨으로 다시 뜨면 기존 클러스터에 합류하지 않고 새 클러스터를 만든다.

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

   사례 보기
4. IL-0108 워크숍 중 운영 클러스터에 적용한 Alcide admission 컨트롤러 때문에 Deployment 생성과 수정이 타임아웃되었다

   DFDS2020

   증상

   2020-11-04 14:41 CET 에 사용자들이 쿠버네티스 클러스터 Hellman 에 배포할 때 타임아웃이 난다고 알려 왔다.

   배포 실패컨트롤 플레인 지연

   촉발

   Alcide 워크숍 중 13:13 CET 에 운영 클러스터에 Alcide admission 컨트롤러를 적용했다. 팀은 이미 있던 것을 다시 적용하는 일이라 영향이 없을 거라고 여겼다.

   원인

   설정 변경

   구성 요소

   어드미션 웹훅쿠버네티스 API 서버

   기여 요인

   설정 테스트 부재미검증 가정모니터링 사각지대

   감지

   팀은 적용 1시간 28분 뒤인 14:41 CET 에 사용자들이 Hellman 에 배포할 때 타임아웃이 난다고 알려 와서 문제를 알았다. 이어 15:04 에 타임아웃을 확인했다.

   조치

   • Alcide admission 컨트롤러를 껐다 켜 보며 이 컨트롤러가 원인인지 확인했다.
   • Alcide admission 컨트롤러를 영구히 지웠다.

   후속 조치

   • 쿠버네티스 Deployment 의 타임아웃을 모니터링한다.
   • kube-apiserver 의 5xx 응답 코드를 모니터링한다.

   교훈

   새로 들이는 구성 요소는 샌드박스 클러스터에 적용한다. Alcide 를 완전히 걷어낼 때까지 팀은 이를 유지할 수 있는 지식을 갖춰야 한다.

   사례 보기
5. IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.

   2i2c2020

   증상

   WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   서비스 중단노드 CPU 고부하

   촉발

   WER 학생들의 사용량이 늘어 사용자 파드와 코어 파드가 함께 도는 노드의 CPU 와 메모리를 다 썼다.

   원인

   용량 한계

   구성 요소

   노드 풀컨테이너 메모리 한도

   기여 요인

   리소스 요청과 한도 미설정미검증 가정과도한 영향 범위

   감지

   08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   조치

   • 09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다.
   • 09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다.

   후속 조치

   • 사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다.
   • prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다.
   • 메모리 오버커밋 비율을 검토하고 문서로 남긴다.
   • 자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다.
   • 다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다.

   교훈

   코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.

   사례 보기

원인별10