この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Summit Online Korea 2021의 옵저버빌러티(Observability) 확보로 서버리스 마이크로서비스 들여다보기 세션을 보면서 작성한 기록입니다.
발표자 분은 김형일, 솔루션즈 아키텍트, AWS입니다.
아젠다
위의 순서로 진행됩니다.
옵저빌리티(Observability)
예전의 모니터링 방법과 현대의 모니터링 방법은 바뀌어왔습니다.
마이크로 서비스 아키텍처의 도입, 새로운 디바이스들의 등장, CI/CD, 서버리스와 같은 짧은 생명주기의 리소스들을 운영하고 문제를 해결하기 위한 더 진보적인 모니터링 환경이 필요하게 되었습니다.
서버리스와 모니터링 계층(Layers)
기존 모니터링의 경우 인프라 영역 네트워크 부터 비지니스 계층까지 모두 대응해야 했습니다.
하지만, 서버리스의 경우 AWS가 어플리케이션, 비지니스 로직 이외의 부분을 전담하여 좀 더 많은 시간을 투자할 수 있게 되었습니다.
옵저버빌리티(Observability)의 3가지 요소
- 로그
-
매트릭
-
추적
옵저버빌리티는 업체가 제공하는 기능이 아니라 사용자가 만들어가야 하는 시스템 속성입니다.
운영자는 바람직하지 않은 동작, 근본 원인을 파악하기 위해 모든 정보를 수집, 분석 가능한 시스템을 설계, 구축이 필요합니다.
옵저버빌러티를 위한 ClouWatch와 X-Ray
로그와 매트릭을 대시보드로 관찰하거나, 경보, 모니터링, 이상탐지, 카나리 테스트로 상황을 감지하고 조치할 수 있습니다.
매트릭과 로그를 활용하여 시각화, 분석에 사용할 수 있습니다.
메트릭(Metrics)
CloudWatch 빌트인(Built-in) 메트릭
위 이미지에 나온 메트릭 이외에도 Amazon CloudWatch에서 70개 이상의 AWS 서버시의 Built-in 메트릭을 사용 할 수 있습니다.
CloudWatch 사용자 정의 메트릭
비지니스 메트릭, 운영 메트릭, 다양한 사용자가 필요한 메트릭을 직접 만들 수 있습니다.
이러한 메트릭을 1분, 1초 단위로 수집할 수 있으면 수집한 메트릭을 콘솔에서 그래프로 확인 할 수 있습니다.
람다의 콜드 스타트 카운트를 사용자 정의 메트릭으로 보내는 코드입니다.
사용자 정의 메트릭을 사용하기 위해서는 위와 같이 데이터를 Amazon CloudWatch로 보내면 됩니다.
CloudWatch 임베디드 메트릭 형식(EMF)
임베디드 메트릭 포맷으로 전송을 위해 별도의 많은 코드 추가없이 높은 카디널리티(중복이 적은) 데이터를 로그형식으로 수집할 수 있습니다.
람다 함수의 실패와 성공의 횟수 정보를 Amazon CloudWatch에 푸쉬하는 코드입니다.
디멘션, 메트릭, 네임스페이스를 지정하여 푸쉬할 수 있습니다.
위와 같이 메트릭이 포함된 json 로그는 Amazon CloudWatch 메트릭으로 자동으로 보내지기 때문에 별도로 메트릭을 추출할 필요가 없습니다.
로그(Log)
Amazon CloudWatch로 준실시간으로 로그를 수집할 수 있습니다.
위와 같은 로그 메시지들 기반으로 메트릭을 생성하고, 메트릭의 시각화를 대시보드를 통해 보거나 임계값 기준으로 경보를 만들 수 있습니다.
CloudWatch 로그 인사이트
로그를 쿼리로 분석할 수 있습니다.
이미 AWS 서비스 로그에 대한 샘플 쿼리가 생성되어있고, 쿼리를 생성 후 저장할 수 있기 때문에 사용한 쿼리를 다시 작성할 필요가 없습니다.
경보(Alerts)
CloudWatch 이상 탐지(Anomaly Detection)
과거 메트릭에 대해 머신러닝 알고리즘을 사용하여 예상값 모델을 생성하고 예상값 기준으로 측정된 값이 벗어난다면 경보를 발생시킬 수 있습니다.
또한, 시각화를 통해 좀 더 쉽게 파악할 수 있습니다.
추적(Tracing)
AWS X-Ray
MSA(마이크로 서비스 아키텍처)의 경우 분산된 애플리케이션들이 복잡성을 만들게 됩니다. 이러한 환경의 문제를 식별하고 해결하기 위해 AWS X-Ray를 사용할 수 있습니다.
AWS X-Ray는 세그먼트라는 추적 정보를 사용하고, 세분화된 추적과 필터링을 위해 서브 세그먼트나 키-밸류 기반의 어노테이션을 적용할 수 있습니다.
서비스 맵으로 시각화를 통해 노드들의 추적을 쉽게 파악할 수 있습니다.
현재 AWS Lambda, Amazon API Gateway, Amazon SNS, Amazon SQS, AWS AppSync 등에서만 사용가능하지만 앞으로 좀 더 많은 서비스들에서 사용가능해질 예정입니다.
옵저버빌리티를 위한 통합
CloudWatch ServiceLens
Amazon CloudWatch ServiceLens는 Amazon CloudWatch의 메트릭과 로그를 AWS X-Ray의 추적과 통합해 사용할 수 있습니다.
인프라, 트랜잭션, 사용자 모니터링도 가능하여 이를 통해 성능 병목을 해결하거나, 문제의 근본 원인을 찾거나 영향을 받은 사용자를 찾을 수 있습니다.
서버리스 기반의 AWS Lambda, Amazon API Gateway 이외에도 Amazon EC2의 java 어플리케이션이나 컨테이너 인사이트가 배포된 Amazon EKS에서 실행되는 java 기반 어플리케이션에 대한 로그 상관관계까지 지원합니다.
또한, Amazon CloudWatch ServiceLens도 서비스 맵을 사용할 수 있습니다.
CloudWatch Synthetics
배포가 빈번하게 생기는 MSA 환경에서의 가용성, 지연시간 등을 쉽게 테스트 할 수 있습니다.
고객 트래픽이 없는 경우에도 테스트를 통해 문제를 알 수 있습니다.
CloudWatch Lambda Insights
지표, 로그 및 추적의 상관 분석을 위한 자동화 대시보드를 제공하고, 로그 데이터의 심층 분석을 위해 Amazon CloudWatch Logs와 통합 되어있습니다.
메모리 누수, 성능 변화, 지연 요인을 이해하는 등 AWS Lambda에 대한 심층적인 분석이 가능해집니다.
새로운 서비스들
Amazon Managed Service for Prometheus
컨테이너 환경의 오픈소스 모니터링 솔루션인 Prometheus를 관리형으로 사용할 수 있습니다.
이미 운영중인 Prometheus가 있다면 동일한 데이터 모델과 쿼리 언어를 사용할 수 있습니다.
인프라를 관리할 필요 없이, 향상된 확장성, 보안성, 가용성을 얻을 수 있고, AWS의 서비스들과 원할하게 통합이 가능합니다.
Amazon Managed Service for Grafana
다양한 유형의 데이터 소스를 통합하고 시각화하고 분석 모니터링하기 위해 사용하는 Grafana를 완전 관리형인 서버리스 로 사용할 수 있습니다.
또한, 콘솔에서 직접 Grafana Enterprise로 업그레이드도 가능합니다.
AWS Proton
컨테이너, 서버리스를 위한 완전 관리형 애플리케이션 배포 서비스입니다.
일관된 표준과 모범사례 보장에 필요한 관리 도구나, 거버넌스, 가시성을 사용하여 개발자가 컨테이너나, 서버리스를 위한 코드를 쉽게 배포할 수 있게 해줍니다.
Troubleshooting
옵저버빌러티 관점에서 문제를 해결하는 일반적인 워크플로에 대한 예입니다.
- Amazon CloudWatch를 통해 경보 알림을 수신 합니다.
- 이상이 있는 애플리케이션을 시각적으로 관찰하기 위해 Amazon CloudWatch ServiceLens를 사용합니다.
- 해당 되는 구성요소의 추적을 확인하고, 분석합니다.
- X-Ray를 통해 심층 분석할 수 있습니다.
- Amazon CloudWatch Log Insights를 사용하여 근본 원인을 직접 검색 할 수도 있습니다.
요약
옵저버빌리티는 단순히 메트릭을 모니터링하고 대응하는 것 뿐만 아니라 데이터 기반의 의사결정을 도우고, 대상의 상태 변화를 이해하는 것 입니다.
Amazon CloudWatch 및 AWS X-Ray를 이용하면 서버리스 마이크로 서비스를 운영하는 경우 옵저빌리티를 확보할 수 있게 도와줍니다.
감상
CloudWatch나 X-Ray로 모니터링 및 디버깅용으로 사용하고 있지만, 이외에도 세부적으로 많은 서비스들이 있었네요. 잘 사용한다면 매우 유용할 것 같습니다. 프로메테우스나 그라파나를 매니지드로 제공하는 건 좋아보이네요.. 모니터링과 로그 분석의 성장에 따라 AWS를 사용하면서 점점 고려하고 준비해야할 게 많아질 것 같습니다...
0
