chanstory

지표 설정 - 서비스나 시스템에 있어 중요한 지표를 판단하는 근거가 있어야함 - 적절한 SLI(서비스 수준 판단을 위해 정량적으로 측정한 값)의 선정은 시스템의 분류에 따라 달라질 수 있음 1. 사용자가 직접 대면하는 시스템 => 보통 프론트엔드에 해당 / 이경우 가용성, 응답시간, 처리량이 중요 2. 저장소 시스템 => 응답 시간, 가용성, 내구성이 중요 3. 빅데이터 시스템 => 데이터 파이프라인이 이에 해당하며 처리량, 엔드포인트 간 응답 시간이 중요 척도 수집 - 측정 원본 합산 or 평균을 내는 방법이 있겠지만 대부분의 경우 분포가 중요 - 일부 요청이 빠르게 처리되어도 나머지 요청이 균일하게 느리다면 실제로 서비스는 느린것 - 평균은 이러한 흐름의 변화를 감지하기 어려움 척도의 표준화 - SL..

SLI (서비스 수준 척도, Service Level Indicator) - 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값 1. 응답속도 : 요청에 대한 응답이 리턴되기까지의 시간 2. 에러율 : 전체 요청 수 대비 3. 처리량(throughput) : 초당 처리할 수 있는 요청 수 4. 가용성 : 서비스가 사용 가능한 상태로 존재하는 시간의 비율 5. 내구성 : 데이터 저장이 중요한 목적인 서비스의 경우 특히 중요 SLO (서비스 수준 목표, Service Level Object) - SLI에 의해 측정된 서비스 수준의 목표 값, 또는 일정 범위의 값을 의미 // SLO 표현 SLI

목표 특징 메트릭이 임계치를 넣을 때, 수평 확장이 자동으로 진행되게 하는 것이 바람직함 Auto Scaling Group (ASG)의 원리를 파악하고 주요 메트릭의 임계치 달성 시점을 경보 형태로 제공해야 함 이를 SNS 및 람다를 통해 구현한다. 최소 요구 사항 EC2 서버를 ASG를 통해 구성 CloudWatch 알람을 통해 ASG의 스케일 인/아웃 진행 스케일 인/아웃 진행 시 디스코드 알람 전송 메트릭을 바탕으로 장애 발생 예상 시점에 디스코드 알람 전송 => CPU 사용률 (CPUUtilization) 값이 특정 값 이상일 때 경보 발생 시작 템플릿 구성 그룹정보 - 원하는 용량 : 1 - 최소 용량 : 1 - 최대 용량 : 1 시작 템플릿 구성 - Ubuntu Server (LTS) - t2..

목표 CI/CD 파이프라인 중 가장 마지막 단계인 운영에 있어 필요한 측정 항목(metric)과 AWS의 대표적인 모니터링 도구인 CloudWatch를 좀 더 잘 다룰 수 있게 연습합니다. 또한, 쿠버네티스 환경에서 사용하는 Prometheus와 Grafana 조합을 살펴봅니다. 모니터링 목표 - 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링 함 => 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까?? - 시간을 기준으로 측정되는 주요 메트릭을 최소화 하여 고가용성 달성 - 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선 => 애자일에서는 "검증된 학습 (Validated learning) 을 적용한다." 고 함 https://www.boldare.com/blog/lean-..