[AWS 스터디모임] AWS Monitoring, Troubleshooting & Audits(2)

AWS X - Ray

• 이전에 프로덕션에서의 디버깅 할 때 좋은 방식은
  • 로컬에서 테스트하기
  • 모든 위치에 로그 문 추가
  • 운영 중 재배포한 뒤 로그를 보며 파악
• 핵심은 운영 환경에서는 디버깅이 까다롭다.
• 게다가 애플리케이션이 여러 개라고 한다면 CloudWatch를 사용하는 애플리케이션마다 로그 형식이 다르며 분석이 어렵다.

X-Ray는 이러한 상황에서 애플리케이션에 대한 시각적인 분석을 제공한다.

애플리케이션에 요청을 수행하는 클라이언트 입장에서 요청이 얼마나 성공/실패하는지 확인하며 애플리케이션이 하는 작업들도 볼 수 있다.

DynamoDB에서 노란 오류가 발생함을 눈으로 볼 수 있다.

 

장점을 살펴보자.

• 트러블 슈팅이 가능하고 병목 현상을 식별할 수 있다.
• 마이크로 서비스 아키텍쳐의 의존관계를 파악할수 있으며, 소통을 시각적으로 볼 수 있다.
• 문제를 낸 서비스를 짚어내고 요청이 어떻게 동작하는 지 파악할 수 있다.
• 요청을 바탕으로 오류, 예외를 찾아내기도 가능하다.
• 어느 사용자가 영향을 받는지도 알 수 있다.

 

여러 서비스와 호환이 가능하다.

• AWS Lambda
• Elastic Beanstalk
• ECS
• ELB
• API Gateway
• EC2 인스턴스 혹은 애플리케이션 서버 (온프레미스 서버도 가능)

 

X-Ray 개념

• 세그먼트: 각 응용 프로그램/서비스에서 전송되는 정보.
• 하위 세그먼트: 세그먼트에 더 많은 세부 정보가 필요한 경우 사용하는 작은 단위의 세그먼트.
• 트레이스 : 세그먼트를 모아 종단 간 트레이스를 형성한다.
• 샘플링: 모든 요청이 필요하지는 않을 수 있기에 특정 요청들만 샘플링해 X-Ray로 전송되는 요청의 양을 줄이고 비용을 절감한다.
• 주석: 추적을 인덱싱하고 필터와 함께 사용하는 데 사용되는 키 값 쌍 데이터를 추가하는 것
• 메타데이터: 키 값 쌍, 인덱싱되지 않음, 검색에 사용되지 않음
• X-Ray 데몬/에이전트는 계정 간에 트레이스를 전송하도록 구성되어 있다:
     • IAM 사용 권한이 올바른지 확인해야한다.. 에이전트가 이 역할을 수행.
     • 이를 통해 모든 응용 프로그램 추적을 위한 중앙 계정을 가질 수 있다.

 

작동 방식

• End to End 방식으로 요청을 추적하는 트레이싱 방식으로 이루어진다.
• 애플리케이션 서버에 어떤 요청을 보냈을 때 요청을 처리하는 여러 컴포넌트가 저마다의 트레이스를 추가한다.
• 트레이스는 세그먼트 형태로, 세그먼트는 하위 세그먼트로 구성된다.(https://docs.aws.amazon.com/ko_kr/xray/latest/devguide/xray-concepts.html)
• 이 트레이스들을 종합해서 요청을 추적할 수 있다.
• 보안적인 측면에서는 인증에 IAM를 사용하고 KMS를 사용할 수도 있다.

 

X-Ray는 어떻게 활성하나? (시험 출제 가능성 )

Java, Python, go, Node.js, .NET 등으로 작성된 코드에 AWS x-ray SDK를 Import 해야한다.

코드를 크게 바꿀 부분은 없지만 일부를 수정해야하며 이후엔 SDK가 AWS 서비스 호출, HTTP 요청 db 호출 등을 포착한다.

 

코드 수정 이후에는 X-Ray 데몬을 설치하거나 x-Ray aws 통합을 활성화 하는 것이다.

리눅스, 윈도우, 맥에서 호환이 가능하다. 각 애플리케이션은 X-Ray에 데이터를 쓸수 있는 IAM 권한이 있어야한다.

 

 

 

X- Ray TroubleShooting

• EC2에서 X-Ray가 작동하지 않는 경우
  • EC2 IAM 역할에 적절한 권한이 있는지 확인한다.
  • EC2 인스턴스가 X-Ray 데몬을 실행하고 있는지 확인한다.
• AWS Lambda에서 사용하려면 :
  
  • 적절한 정책으로 IAM 실행 역할이 있는지 확인한다. (AWSX-RayWriteOnlyAccess)
  • X-Ray가 코드에 Import되었는지 확인.
  • Lambda X-Ray 추적 활성화

X-Ray 계측

정보를 효율적으로 검색하고 필터링할 수 있는 기능

계측은 제품의 성능을 측정하고 오류를 진단하며 추적 정보를 작성하는 것을 의미한다.
• 응용 프로그램 코드를 계측하기 위해 X-Ray SDK를 사용한다.
• 큰 코드 수정은 필요없다. 많은 SDK에서 구성 변경만 요구하기도 한다.

 

 

X-Ray Sampling

모든 요청의 데이터가 필요하지 않을 수도 있다. 이 때 샘플링 규칙을 사용하면 기록하는 데이터의 양을 제어할 수 있다.
• 코드를 변경하지 않고 샘플링 규칙을 수정할 수 있다.
• 기본적으로 X-Ray SDK는 매초마다 모든 첫 번째 요청을 기록하고, 추가요청의 5%를 기록한다.
• 초당 하나의 요청은 리저버(Reservoir)라 하고, 서비스가 요청들을 서빙하는 동안 매초마다 적어도 하나의 트레이스가 기록되는 것을 보장하는 저장소이다.
• 5%는 비율이라고 하는데 저장소 크기를 초과하는 추가 요청을 샘플링하는 비율입니다.

 

Reervoir와 Rate가 이해가 잘안된다....

Reservoir (저장소)
Reservoir는 특정 시간 동안 추적 데이터를 수집하는 고정된 양을 의미합니다. 예를 들어, Reservoir 값이 1이라면, 매 초마다 하나의 요청 트레이스를 샘플링하여 수집한다는 뜻입니다. 이는 매우 낮은 트래픽에서도 최소한의 트레이스 데이터를 확보할 수 있도록 보장합니다. 따라서, Reservoir는 애플리케이션에 대한 최소한의 가시성을 유지하는 데 도움이 됩니다.
Rate (비율)
Rate는 초과 트래픽에 대한 샘플링 비율을 나타냅니다. 이 비율은 전체 요청 중에서 얼마나 많은 요청을 샘플링할 것인지를 결정합니다. 예를 들어, Rate가 5%라면, Reservoir를 초과하는 요청 중에서 5%만 샘플링한다는 의미입니다. 이 비율은 트래픽이 많을 때 트레이스 데이터의 양을 제어하고, X-Ray의 비용을 관리하는 데 유용합니다.

 

샘플링은 커스텀 규칙을 생성할 수 있다. 사진을 보자.

왼쪽은 초당 10개의 요청이 보내진다는 뜻이고 추가 요청의 10%를 기록한다는 뜻이다.

오른쪽은 모든 요청에 대해 디버깅을 한다는 의미.

 

샘플링 규칙을 변경할 때는 별다른 재시작이 필요없다. 데몬이 자동으로 샘플링 규칙을 얻어내어 X-Ray SDK에 적용한다.

 

 

X-Ray Write APIs (Used by the x-ray daemon)

쓰기 전용 액세스라는 관리 정책.

 

PutTraceSegments : 세트먼트 문서를 AWS X-ray에 업로드

PutTelemetryRecords : X-Ray 데몬이 수신/거절 세그먼트가 몇개 인지 백엔드 연결 오류와 관련된 정보를 업로드

GetSamplingRules : 모든 샘플링 규칙을 검색

GetSamplingTarget : 샘플링 규칙이 적용되는 타겟 검색

GetSamplingStatisticSummaries : 샘플링 통계 요약 검색

 

 

 

 

 

X-Ray Read APIs 

 

 

GetServiceGraph : 콘솔의 메인 그래프를 검색

BatchGetTraces : ID로 지정된 추적 목록을 검색

GetTraceSummary : 추적을 위해 특정 시간에 사용할 수 있는 ID와 주석을 검색. 전체 추적을 원한다면 이 ID를 배치로 전달하여 추적 API를 가져오면 된다.

GetTraceGraph : 하나 이상의 특정 추적 ID와 관련된 서비스 그래프를 검색.

 

 

 

 

 

 

X-Ray with Elastic Beanstalk

Elastic Beanstalk 플랫폼에는 X-Ray 데몬이 포함되어 있어 따로 추가할 필요는 없다.

옵션 하나만 설정해서 실행할 수 있다.

(혹은  xray-daemon.config라는 .ebextensions 파일로 생성, ebextensions 폴더의 xray-daemon.config에 이런 한 줄짜리 옵션이 있어서 X-Ray 데몬을 간단히 활성화할 수 있다.)

 

이후 인스턴스에 올바론 IAM 권한을 가진 프로필이 있는지 확인한다. 또한 SDK에 애플리케이션 코드가 갖춰졌는지도 확인한다.

 

 

ECS + X-Ray 통합

• ECS Cluster
  • 데몬을 실행하는 방법으로 데몬 자체를 컨테이너로 사용한다.

  • 이 말은 X-Ray 에이전트가 모든 EC2 인스턴스에서 실행되고 애플리케이션 컨테이너를 EC2 인스턴스에서 실행한다는 것이다. 

• Side Car 
  • 각 애플리케이션 컨테이너와 함께 하나의 X-Ray 컨테이너를 실행한다.

  • 사이드카라고 부르는 이유는 X-Ray 데몬이 애플리케이션 컨테이너로 나란히 실행되기 때문

 

• Fargate Cluster
  • AWS Fargate는 별도로 인스턴스를 생성 관리하지 않고, 완전한 매니지드 서비스의 형태로 도커 컨테이너를 실행시킬 수 있는 아마존의 서비리스 컨테이너 상품 
  • 인스턴스를 제어할 수 없고 Fargate에 컨테이너를 적재, x-ray 컨테이너는 사이드 카 형태로 사용하는 형태

데몬의 실행 부분

작업 정의를 보면 upd 프로토콜로 컨테이너 포트는 2000번을 사용한다.

아래에 환경을 보면 aws_xray_daemon_address라는 환경변수에 의해 2000포트의 데몬 환경이 설정된 것이 보인다.

마지막 아래에 links에 의해 xray-daemon이라는 호스트를 컨테이너에 저장한다.

 

이 슬라이드의 핵심은 X-Ray 데몬의 컨테이너 포트를 2000 UDP로 매핑해야 하며 XRAY_DAEMON_ADDRESS라는 환경 변수를 설정하고 마지막으로 2개의 컨테이너를 네트워킹 관점에서 연결해야 한다는 것이다.

 

 

AWS Distro for OpenTelemetry

OpenTelemetry라는 일종의 프로젝트를 AWS는 배포판을 제공한다.

OpenTelemetry는 단일 API 셋, 라이브러리, 에이전트, 컬렉터 서비스를 사용하며 분산된 트레이스 및 지표를 수집하는 프레임워크의 일종이다. x-ray와 비슷하다.

오픈 소스입이며, 에이전트가 자동으로 계측하여 트레이스를 수집하죠 이 역시 x-ray와 비슷하다.

 

AWS CloudTrail

AWS 계정의 운영 및 위험 감사, 거버넌스 및 규정 준수를 활성화하는 데 도움이 되는 AWS 서비스. 사용자, 역할 또는 AWS 서비스가 수행하는 작업은 CloudTrail에 이벤트로 기록된다.

 

AWS 계정 내의 모든 이벤트 기록, API 호출을 콘솔, SDK, CLI, 다른 AWS 서비스 등에서 얻는다.

얻은 로그를 CloudWatch Logs나 S3 Bucket으로 송신한다.

 

CloudTrail Events

• Management Events
  • Aws 계정에 있는 리소스에서 수행되는 작업을 의미한다.
  • 예를 들면 
    • 보안 구성 시 IAM AttachRolePolicy API를 사용한다하면 이 내용이 CloudTrail에 기록된다.
    • EC2 서브넷을 생성시 구성설정이나 라우팅 데이터가 기록된다.
  • 기본적으로 관리 이벤트는 어떤 경우에도 기록하도록 구성된다.
  • 관리 이벤트는 리소스에 변경이 일어나지 않는 읽기 이벤트와 변경이 일어나는 쓰기 이벤트로 세분화 할 수 있다.
• Data Events
  • 기본적으로는 로그에 기록되지 않는다. (대용량 작업이기 때문)
  • 아마존 S3 객체 수준 활동(예: GetObject, Delete다.Object, PutObject): 읽기 및 쓰기 이벤트를 분리할 수 있다.
  • Lambda 기능 수행 활동을 기록할 수 있다.(API를 누군가 호출 할 때 몇 번의 함수가 호출되었는지 파악 가능)
• CloudTrail Insights Events
  • 유료 서비스. 사용할 경우 비용이 발생한다. 
  • 모든 유형의 서비스에서 관리 이벤트가 발생할 경우 많은 API가 빠르게 발생한다.
    • 이때 어떤 로그가 특이하고, 특이하지 않은지 구분하는 것을 어려울 수 있다.
  • CloudTrail이 정상 관리 활동을 분석해 기준선을 만들고 이벤트가 올바른 유형인지 지속적으로 분석한다.
  • 이벤트를 분석하고 계정내 비정상적인 활동을 분석한다.
    • IAM 작업 폭주
    • 부정확한 리소스 프로비저닝
    • 서비스 제한 초과 등
  • 비정상적인 이벤트가 발생할 경우 인사이트 이벤트를 생성해 콘솔이나 S3에 보낼 수 있다.
  • EventBridge 와 결합하여 EventBridge Event를 생성할 수 있다.

 

CloudTrail Events Retention

CloudTrail Event 보존.

• 이벤트는 CloudTrail에서 90일 동안 저장된다.
• 이 기간을 넘어서 이벤트를 보관하려면, S3에 로깅해야한다.

 

 

CloudTrail - EventBridge 결합 예시 이미지

• DB Table 삭제 시 SNS 알람 발생 이벤트 설정

• 특정 사용자에게 IAM 역할을 위임했다고 했을 때 메시지를 발생
• 보안 그룹 인바운드 규칙 변경 시 (EC2 AuthorizeSecurityGroupinggress API 호출) 메시지 발생 

 

 

CloudTrail vs CloudWatch vs X-Ray

CloudTrail	CloudWatch	X-Ray
사용자, 서비스, 콘솔에서 계정에 이루어진 API 호출을 감지	모니터링에 대한 서비스를 제공	자동화된 추적 분석, 중앙 서비스 맵시각화 서비스
API 호출로 인한 변경의 원인을 찾을 때 유용	모니터링을 위해 CloudWatch지표를 사용하거나 CloudWatch 로그로 애플리케이션의 로그를 저장하거나 CloudWatch 경보를 통해 지표에 대한 알림을 보낸다.	분산서비스에서 활용하기 좋다. 디버깅과 콘솔 내의 오류 및 오류 분석 항복을 보는 데 유용하다.
API 호출 중점	모니터링 중점
	전반적인 지표를 중점	세분화되고 추적 지향적인 지표를 중점

 

 

 

---

2024.03.11 - [AWS] - [AWS 스터디모임] AWS Monitoring, Troubleshooting & Audits(1)

[AWS 스터디모임] AWS Monitoring, Troubleshooting & Audits(1)