사례2건

2건 중 1~2번째

1. IL-0189 KIAM 이 준 15분짜리 AWS 자격 증명 때문에 쿠버네티스로 옮긴 Java 서비스가 요청마다 메타데이터 API 를 불러 지연이 최대 10배 늘었다.

   Adevinta2019

   증상

   마이크로서비스 하나를 쿠버네티스 기반 중앙 플랫폼에 배포하고 운영 트래픽 일부를 보내자 요청 지연이 EC2 보다 최대 10배 높게 나왔다. 백엔드 응답 시간이 EC2 에서는 약 20ms 였는데 쿠버네티스에서는 100~200ms 였다.

   지연 시간 증가

   촉발

   쿠버네티스로 옮긴 서비스가 KIAM 을 거쳐 받은 AWS 임시 자격 증명의 만료 시간이 정확히 15분이었다. AWS Java SDK 는 만료까지 15분 이내로 남은 자격 증명을 곧바로 새로 받는다.

   원인

   설정 변경

   구성 요소

   파드용 자격 증명 중개자

   기여 요인

   기본 설정 방치

   감지

   서비스를 쿠버네티스에 배포하고 운영 트래픽 일부를 보낸 뒤, 요청 지연이 EC2 보다 최대 10배 높게 나오는 것을 보고 알았다.

   조치

   • KIAM 이 더 긴 만료 시간으로 자격 증명을 요청하도록 설정을 바꿨다.

   교훈

   이번 지연은 쿠버네티스, KIAM, AWS Java SDK, 서비스 어느 쪽의 버그도 아니었다. 자격 증명을 일찍 갱신하는 SDK 의 정책과 짧은 만료 시간을 주는 KIAM 의 기본값은 따로 보면 둘 다 타당하지만, 함께 쓰면 요청마다 갱신이 일어난다. 마이그레이션에서 생기는 문제는 대개 처음 함께 붙여 본 구성 요소들이 만나는 지점에서 나온다. 따로따로 타당한 두 결정이 함께 쓰여도 타당하다는 보장은 없다.

   사례 보기
2. IL-0035 ElastAlert 에 새로 넣은 알림 규칙 때문에 ElastAlert 파드가 메모리를 끝없이 써서 노드가 잇달아 NotReady 가 되었고, 같은 클러스터의 도구와 Grafana, Prometheus 가 함께 흔들렸다.

   NU.nl2019

   증상

   팀은 여러 서비스가 이상하게 동작한다는 보고를 받았다. 가끔 오류 페이지가 뜨고, 응답이 느리고, 타임아웃이 났다.

   노드 NotReady오류율 상승지연 시간 증가간헐적 타임아웃모니터링 중단OOMKilled

   촉발

   장애 직전에 팀원 한 명이 ElastAlert 에 새 알림 규칙을 명령줄로 배포했다. Cloudfront-* 인덱스에 일정 시간 새 문서가 들어오지 않으면 울리는 규칙이었다.

   원인

   설정 변경

   구성 요소

   컨테이너 메모리 한도kubeletPrometheus

   기여 요인

   리소스 요청과 한도 미설정기본 설정 방치한계 경보 부재모니터링 사각지대과도한 영향 범위

   감지

   여러 서비스에서 오류 페이지, 느린 응답, 타임아웃이 난다는 보고가 팀에 들어왔다. 알림은 하나도 울리지 않았다. 팀은 Prometheus 와 Grafana 가 안정적인 노드로 옮겨 간 뒤 파드 메모리 사용량 대시보드에서 원인을 찾았다.

   조치

   • NotReady 노드를 하나씩 종료해 오토스케일링 그룹이 새 노드를 띄우게 했다. 새 노드도 곧 NotReady 가 되어 이것만으로는 풀리지 않았다.
   • Prometheus 와 Grafana 가 안정적인 노드에 다시 스케줄된 뒤 파드 메모리 대시보드를 보고 ElastAlert 파드가 원인임을 찾아냈다.
   • 원인인 ElastAlert 문제를 고쳤다.

   후속 조치

   • CPU, 메모리, 디스크 공간 같은 자원 사용량에 알림 규칙을 정의한다.
   • 여러 출처를 함께 쓰는 알림 전략을 계속 연구한다. 지금은 Elasticsearch, 아직 설정하지 않은 Prometheus alertmanager, APM 용 New Relic 이 있다.
   • 지표를 클러스터 밖으로 내보내고 Grafana 도 클러스터 밖으로 옮기는 방안을 검토한다. 옮길 곳은 EC2 나 별도 쿠버네티스 클러스터가 될 수 있다.
   • 중요한 지표를 ELK 에서 시각화하거나 Prometheus 와 Grafana 의 가용성을 높인다. 지표 전략도 개선한다.
   • ElastAlert 의 자원 한도를 Helm values 로 지정한다.
   • 네임스페이스에 메모리 요청값의 기본값과 한도를 설정한다.
   • 고객 대면 워크로드를 빌드, 로깅, 모니터링 워크로드와 떼어 놓는다. 먼저 운영 클러스터 안의 전용 노드 그룹으로 옮기고, 경험에 따라 별도 도구 클러스터도 검토한다.
   • 모든 배포를 Jenkins 파이프라인 같은 자동화로 하고, 새 버전 배포에 GitOps 방식을 검토한다.
   • 배포 뒤 스모크 테스트 단계가 있는 파이프라인으로 배포한다.
   • 쿠버네티스와 클라우드 인프라 작업을 팀 스프린트에 넣어 모든 팀원이 경험 많은 팀원과 짝을 지어 맡게 하고, 주제별 심화 워크숍을 연다.

   교훈

   근본 원인 하나만 탓하는 포스트모템은 장애로 이어진 문제의 15% 정도만 다룬다. 이번에도 ElastAlert 를 고친 것은 일부일 뿐이었다. 알림이 없었고, 모니터링이 같은 클러스터 안에 있었고, Helm 차트의 자원 한도에 기본값이 없었다. 운영 도구와 고객 워크로드가 자원을 나눠 썼고, 손으로 한 배포를 팀이 몰랐고, 스모크 테스트가 없었고, 운영 지식이 일부에게만 있었다. 이렇게 배우려면 장애 건수나 해결 시간만 보지 않고 비난 없는 포스트모템을 허용하는 문화가 필요하다.

   사례 보기

원인별1