Section 20. AWS 모니터링 및 감사: CloudWatch, X-Ray 및 CloudTrail - 2

AWS X-Ray

시험에 반드시 나오니 주의!

발단
운영 환경에서 디버깅할 때를 종종 마주한다.
정석 방법은 로컬에서 테스트하고, 곳곳에 로그 구문을 추가하고, 운영 환경에 재배포하고 로그를 보며 잘못된 방법을 파악하는 방법이다.
이러한 방법은 상당히 성가시기 때문에 AWS X-Ray를 사용한다.

 

AWS X-Ray Visual analysis of our applications

• X-Ray는 어플리케이션에 대한 시각적 분석을 제공한다.
• 이번 강의에서 어플리케이션에 요청을 수행하는 클라이언트 입장에서 요청이 얼마나 실패하고 성공하는지 확인할 것이다.
• 아래 그림에서 볼 수 있듯이 EC2 인스턴스와 소통할 때 일어나는 일을 시각적으로 파악할 수 있다.

노란색 바는 오류, 즉 EC2 인스턴스에서 일어나는 오류가 DynamoDB에서 일어나는 일이라는 것을 확인할 수 있다.

 

X-Ray Advantages

1. 성능 트러블슈팅이 가능하고 병목 현상을 식별할 수 있다.
2. 마이크로서비스 아키텍쳐의 의존관계를 파악할 수 있다.
3. 문제를 일으킨 서비스를 확인할 수 있다.
4. 요청이 어떻게 동작하는지 파악하고 요청을 바탕으로 오류를 찾고 예외를 찾아낼 수 있다.
5. 지연 시간과 요청 처리시간 면에서 우리가 시간 SLA를 준수하는지 알 수 있다.
6. 어떤 서비스에서 지체되는지 확인할 수 있다.

X-Ray Compatibility

• X-Ray는 lambda, elastic beanstalk, ECS, ELB, API Gateway, EC2 인스턴스 및 어떤 어플리케이션 서버와도 호환될 정도로 호환성이 높다.

X-Ray Leverages Tracing

• X-Ray가 작동할 때는 트레이싱을 활용한다.
  • 트레이싱이란 End-To-End 방식으로 요청을 추적하는 방법이다.
  • 트레이스는 세그먼트로 세그먼트는 하위 세그먼트로 구성된다.
• 트레이스에 어노테이션을 추가하여 발생한 일에 대한 추가 정보도 제공할 수 있다.
• 최종적으로 이 모든 것들을 종합하여 아래의 요청들을 추적할 수 있다.
  • 모든 요청
  • 샘플 요청
• X-Ray 보안은 인증에 IAM을 사용하고 미사용 데이터 암호화에는 KMS를 사용할 수 있다.

X-Ray를 활성화하는 방법

1. 코드는 자바, 파이썬, Go, Node.js, NET으로 작성할 수 있고 AWS X-Ray SDK를 임포트해야 한다.
   • 일부는 수정해야 하며, 수정 후에는 X-Ray SDK가 AWS 서비스에 대한 호출과 HTTP 및 HTTPS 요청, DB 호출 등을 포착한 
2. 코드 수정이 끝난 후에는 X-Ray 데몬 설치나 X-Ray AWS 통합 활성화이다.
   • EC2 인스턴스를 실행하면 데몬을 설치해야 한다.(데몬: 저레벨 UDP 패킷 인터셉터처럼 작동하는 작은 프로그램)
   • 이미 X-Ray와 통합된 람다 같은 AWS 서비스를 사용 중이라면 알아서 데몬을 실행해 주니 괜찮다.
   • 각 어플리케이션은 X-Ray에 데이터를 쓸 수 있는 IAM 권한이 필요하다.

참고.

만일 제대로 X-Ray가 작동하지 않으면 IAM 권한이 제대로 부여되었는지 확인할 것.

또는 EC2 인스턴스 경우에는 X-Ray 데몬이 실행 중인지 확인 할 것!

 

X-Ray Instrumentation in your code

코드를 계측하는 방법을 알아보자.
계측이란 뜻은 제품의 성능을 측정하고, 오류를 진단하고 추적 정보를 쓰는 것을 의미한다.

• X-Ray로 어플리케이션을 계측하려면 코드를 수정하여 X-Ray SDK를 이용해야 한다.

X-Ray SDK와 Node.js 코드를 계측한 예시 코드

• X-Ray SDK를 사용하는 것은 미미하다.
  • 그래서 사용자 정의 추적을 쓰거나 데이터에 주석을 달거나 X-Ray가 Express서비스에 보내는 방식을 변경하고 싶을 때 어플리케이션 코드도 수정할 수 있다!
  • 이때는 인터셉터나, 필터, 핸들러를 만들 수 있다.

X-Ray Concepts

X-Ray 개념을 더 알아보자.

• Segments | 각 어플리케이션과 서비스가 보낸다.
• SubSegments | 세부 사항을 남길 때 사용한다.
• Trace | 모든 세그먼트는 함께 모았을 때로 API 호출의 종단 간 뷰를 형성한다.
• Sampling | X-Ray로 보내지는 요청의 양을 줄여 비용을 감소시킬 때 사용한다.
• Annotations | 주석은 추적을 인덱싱하고 필터와 함께 사용하기 위해 키-값 쌍 데이터를 추가하는 것이다.
• Metadata | 키-값 쌍이지만, 인덱스는 아니며 검색에 사용되지는 않는다.
• X-Ray 데몬과 agent는 여러 계정에 추적을 보내기 위한 설정을 갖는다.
  • 이때 IAM 권한이 올바른지 확인해야 한다.
  • 중앙 계정을 만들 수도 있다.

X-Ray Sampling Rules

• 샘플링 규칙으로 X-Ray 서비스와 레코드에 보내는 데이터의 양을 제어할 수 있다.
  • 데이터가 많을 수록 비용도 증가한다.
• 기본적으로 샘플링 규칙은 X-Ray SDK가 초마다 모든 첫 번째 요청을 기록하고 다음 추가 요청의 5%를 기록한다.
• 초마다 첫 번째 요청을 '리저버'라고 하고 이는 서비스가 요청을 처리하는 동안 초당 적어도 하나의 추적이 기록되는 것을 보장한다.
• 위의 5%는 '비율'이라고 하며, 리저버의 크기를 초과하는 추가 요청을 샘플링한다.

X-Ray Custom Sampling Rules

• 샘플링 규칙은 리저버와 비율을 통해 스스로도 만들 수 있다!
• 아래의 그림 중 오른쪽은 초당 10개의 요청이 X-Ray에 보내지고 다른 10%가 보내진다!
• 왼쪽은 디버깅을 하는 과정에 모든 요청을 원하기에 리저버가 1, 비율도 1이 된다. 즉, 추적을 놓치고 싶지 않다는 의미이다.

• X-Ray 콘솔에서 샘플링 규칙을 변경한 경우, 어플리케이션을 재시작할 필요는 없다.
  • 위의 말은 X-Ray 데몬을 다시 시작할 필요가 없다는 의미인데, 데몬이 자동으로 샘플링 규칙을 얻어 X-Ray 서비스에 올바른 양의 데이터를 보내주기 때문이다. 
  • 이를 참고하길 바란다.

X-Ray API

1. 쓰기 API

• 쓰기 API는 X-Ray 데몬에서 데이터를 X-Ray 서비스에 쓸 때 사용한다.
• 아래의 그림에 있는 5줄의 코드를 설명해 보이겠다.
  1. PutTraceSegments | AWS X-Ray에 세그먼트 문서를 업로드한다.
  2. PutTelemetryRecords | X-Ray 데몬이 수신/거절 세그먼트가 몇 개인지, 백엔드 연결 오류와 관련된 정보를 업로드한다.
  3. GetSamplingRules | 모든 샘플링 규칙을 검색한다.
  4. GetSmaplingTargets & GetSamplingStaticsticSummaries | 고급 API로 샘플링 규칙과 연관이 있다. 
• 요약하자면 X-Ray 데몬이 X-Ray에 쓸 때 PutTraceSegments와 PutTelemetryRecords가 필요하다. 그리고 샘플링 규칙을 가져와야 한다. 이 역할을 GetSamplingRules가 맡는다. X-Ray 데몬은 API 호출이 동작하게 권한을 부여하는 IAM 정책을 가질 필요가 있다.

2. 읽기 API

• 하나만 빼고 모두 "get"으로 이루어져 있다.
• 아래의 그림에 있는 코드를 알아보자.
  1. GetServiceGraph | 메인 그래프를 가져온다.
  2. BatchGetTraces | ID로 지정된 추적 목록을 검색한다. 각 trace는 단일 요청에서 발생하는 세그먼트 문서의 집합이다.
  3. GetTraceSummary | 추적을 위해 특정 시간에 사용할 수 있는 ID와 주석을 받는다. 만일 전체 추적을 원한다면 이 ID를 배치로 전달하여 추적 API를 가져온다.
  4. GetTraceGraph | 하나 이상의 특정 추적 ID와 관련된 서비스 그래프를 검색한다.

Beanstalk를 사용한 X-Ray

우리는 Beanstalk 콘솔에서 옵션 하나만 설정해 데몬을 실행할 수 있다.
또는 xray-daemon.config라는 .ebextensions 파일로 생성해도 무관하다.

 

X-Ray 및 ECS

이 파트에서는 ECS와 X-Ray를 통합하는 법을 배울 수 있다.
3개의 옵션이 존재하는데 이를 알아보자!

 

Integration Options

1. ECS Cluster - "X-Ray Container as a Daemon"
   
   • X-Ray를 실행시키는 방법으로 데몬 자체를 컨테이너로 사용한다.
2. ECS Cluster - "X-Ray Container as a "Side Car"
   
   • 여전히 EC2 인스턴스가 있지만 각 어플리케이션 컨테이너와 함께 X-Ray 컨테이너 하나를 실행한다. 이들은 서로 연결될 것이다.
   • 사이드카로 부르는 이유는 X-Ray 데몬이 어플리케이션 컨테이너로 나란히 실행되기 때문이다!
3. Fargate Cluster - "X-Ray Container as a "Side Car"
   • Fargate Cluster에서는 EC2 인스턴스를 제어할 수 없다.
   • X-Ray 데몬 컨테이너를 사용할 수 없고, 사이드카 패턴으로 X-Ray 컨테이너를 사용해야 한다.

AWS Distro for OpenTelemetry

오픈텔레메트리란 일종의 프로젝트로, 단일 API 셋, 라이브러리, 에이전트, 컬렉터 서비스를 사용하여 어플리케이션에서 분산된 트레이스 및 지표를 수집하는 방법이다.
이 방법을 통해 AWS 리소스나 서비스에서 메타데이터를 수집하는데 도움이 될 수도 있다.

X-Ray와 비슷하지만 오픈 소스이고, 에이전트가 자동으로 계측하여 트레이스를 수집한다. 또한 코드를 바꾸지 않아도 된다!!

---

CloudTrail

클라우드트레일은 AWS 계정에 대한 Governance, 규정 준수 및 감사를 수행한다!
이는 모든 AWS 계정 내 모든 이벤트의 기록과 API 호출을 얻게 해준다.

모든 로그는 클라우드트레일에서 나타난다.
클라우드트레일에서 얻은 로그들은 CloudWatch Logs나 S3로 보내진다.
또한 모든 리전이나 단일 리전에 적용되는 추적을 만들 수 있다.

만일 리소스가 AWS에서 삭제되었다면, 클라우드트레일에서 먼저 검사한다!

CloudTrail Events

클라우드트레일 이벤트에는 3가지 종류가 있다. 알아보자!

1. Management Events:
   • AWS 계정에 있는 리소스에서 수행되는 작업을 의미한다.
   • 누군가 보안을 구성할 때마다 IAM AttachRolePolicy라는 API 코드를 사용하고 이것은 CloudTrail에 나타난다.
     • 서브넷을 만들면 나타날 것이고, 로깅을 설정하면 기본으로 나타날 것이다.
2. Data Events
   • 기본적으로 분리가 되어 있어서, 데이터 이벤트는 로그에 남지 않는다. 왜냐하면 대용량 작업이기 때문이다.
   • GetObject, DeleteObject, PutObject와 같은 Amazon S3 객체 수준의 활동에서 읽기와 쓰기 이벤트를 분리할 수 있다.
   • AWS Lambda function execution activity
     • 누군가 API를 호출할 때마다 몇 번의 람다 함수가 호출되었는지 알 수 있다.
3. CloudTrail Insights Events
   • 계정에서 예기치 않은 활동을 탐지한다.
   • 동작 방식은 클라우드트레일이 정상 관리 활동을  분석하여 기준선을 만들고 이벤트가 올바른 유형인지 계속하여 분석한다.
   • 무언가 변경되거나 변경을 시도할 때마다 비정상적인 패턴을 감지한다.

CloudTrail Events Retention

• 클라우드트레일에서 이벤트는 기본적으로 90일 동안 보관된다. 그리고 그 이후에는 삭제되는데, 이때 이벤트를 오래 보관하고 싶을 때 사용한다.
• 오래 보관하고 싶다면 S3에 로그를 보내고 Athena를 사용한다.

Amazon EventBridge - Intercept API Calls

CloudTrail 결합과 관련하여 중요한 사항이 있다. 바로 EventBridge이다.

 

CloudTrail vs. CloudWatch vs. X-Ray

각 서비스의 차이를 알아보자

1. CloudTrail
   1. 사용자, 서비스 또는 AWS 콘솔에서 계정에서 이루어진 API 호출을 감사한다.
   2. 승인되지 않은 호출을 감지하거나 API 호출로 인한 변경의 근본적인 원인을 찾을 때 유용하다.
2. CloudWatch
   1. 모니터링을 위해 CloudWatch 지표를 사용한다.
   2. CloudWatch 로그로 어플리케이션 로그를 저장할 수 있다.
   3. CloudWatch 알람으로 예상치 못한 지표가 나왔거나 했을 때 알림을 보낼 수 있다.
3. X-Ray
   1. 자동화된 추적 분석과 중앙 서비스 맵 시각화를 해주기에 분산 서비스에서 한 눈에 보기 좋다.
   2. 디버깅과 X0Ray 콘솔 내 지연, 오류 및 오류 분석 같은 항목을 보는 데 유용하다.
   3. 분산 시스템 전체에서 추적 요청을 얻을 수도 있다.