[AWS] aws 강의 섹션 20-2 (X-Ray, CloudTrail)

AWS X-Ray

• 기존에 디버깅을 하는 방법은 곳곳에 로그를 작성하고
• 재배포한 후 로그를 보며 잘못된 부분을 파악하는 방식이었다.
• 심지어 MSA처럼 여러 개의 애플리케이션을 배포한 경우에는 디버깅이 더욱 더 힘들어질 것이다.
• 이 때문에 엑스레이가 등장했다.

애플리케이션의 시각적 분석

• 엑스레이는 시각적 분석을 제공한다.

• 애플리케이션에 요청을 수행하는 클라이언트 입장에서 요청이 얼마나 실패하고 성공하는지,
  동작하는 작업에 무엇이 있는지, 모든 것을 시각화 해준다.
  • 위의 그림을 보면 애플리케이션의 노란색 에러가 어디서 오는 것인지를 알 수 있다.
    가장 아래 원이 DB인데, 이를 통해 애플리케이션의 에러는 데이터베이스에서 온다는 것을 알 수 있다.

엑스레이 장점

• 트러블 슈팅 퍼포먼스가 높다.
  • 병목 현상을 발견하기 쉽다.
• 마이크로서비스 아키텍처의 의존관계를 파악하기도 쉬워진다.
  • 어떻게 소통하는지 다 시각화해주기 때문이다.
• 문제를 일으키는 서비스를 집어내고
• 각 요청이 어떻게 동작하는지 확인하며, 요청을 바탕으로 오류와 예외도 찾아낼 수 있다. 
• SLA를 준수하는지 (지연시간 면에서)
• 어느 사용자들 때문에 오류가 나는 것인지 

등등을 시각화를 통해 쉽게 파악할 수있다.

엑스레이 호환성

• 엑스레이는 호환성이 높다.

엑스레이 Leverages Tracing

• 엑스레이는 레버리지 트레이싱이란 방식을 통해 동작들을 추적한다.
• 트레이싱이란 엔드 투 엔드 방식으로 요청을 추적하는 방식이다.
  • 엔드에서 엔드 사이로 이동하는 동안 거치는 모든 서비스에 트레이스를 추가한다.
    • EC2, DB, GateWay 모든 곳에 트레이스를 추가한다.
  • 트레이스란 세그먼트로 이뤄지며 세그먼트는 하위 세그먼트로 이뤄진다.
    • 예를 들어, DB를 지나갔다고 하면 세그먼트는 DB (거쳐 간 서비스)가 될 것이고
      하위 세그먼트는 DB에서 이뤄진 쿼리가 될 것이다.
    • 어노테이션을 트레이스에 추가해, 추가적인 정보들도 수집할 수 있다.
• 이것들을 모두 종합해서 각종 요청들을 추적할 수 있게 된다.

보안

• 보안 측면에서는 인증에 IAM을 사용하고
• 미사용 데이터 암호화에는 KMS를 이용한다.

엑스레이는 어떻게 활성화 할까?

1. AWS X-Ray SDK 임포트, 코드는 자바, 파이썬, Go, Node.js, .NET 으로 작성할 수 있다.
   • 코드의 일부는 수정해야한다.
   • 이후 SDK가 AWS 서비스에 대한 호출과 HTTP요청, DB 호출 
     큐 호출 (SQS), 모든 것의 정보를 수집할 것이다.
2. 두 번째로 해야할 일은 바로 X-Ray Demon 활성화다.
   • 서버에서 데몬을 설치해야 하는데
     패킷 인터셉터 같이 돌아가는 아주 작은 레벨에서 작동하는 프로세스다.
     
     • 하위 레벨에서 작동하며 트레이스 작성에 필요한 모든 정보를 수집한다.
   • 이미 엑스레이와 통합된 람다 같은 AWS 서비스를 사용 중이라면 알아서 데몬을 실행해 주니 신경 쓸 필요 없다.
   • 각 애플리케이션은 엑스레이에 데이터를 쓸 수 있는 IAM 권한이 있어야 한다.

• 다시 정리하자면, SDK를 설치하면 SDK에서 정보를 수집
• 이후 가상 서버에 설치된 X-Ray Demon에게 트레이스를 전송
• 데몬이 1초마다, 모아진 배치를 엑스레이에 전송한다.

시각화는 어떻게 할까?

• 트레이스를 전송하는 각 서비스로부터 엑스레이가 데이터를 수집했다.
• 모든 트레이스의 세그먼트로 서비스 맵을 계산한다.
• 이후 시각화를 통해 보여주면 , 그를 통해 트러블 슈팅이 용이해진다.

만약 EC2에서 엑스레이가 실행되지 않는다면

• EC2의 IAM룰이 잘 적용돼 있는지
• 엑스레이 데몬이 잘 돌아가고 잇는지를 확인해야 한다.

람다에서 실행되지 않는다면

• 람다에 IAM정책이 올바르게 연결돼 있는지 확인해야 한다.
• 엑스레이 코드가 임포트 됐는지 확인해야 한다.
• 람다에서 엑스레이 추적 옵션을 활성화 했는지 확인해야 한다.

X-ray Instrumentation in your code

• instrumentaion 뜻이 무엇일까?
  • 계측이란 뜻으로, 제품의 성능을 측정하고 오류를 진단하며, 추적 정보를 수집하는 것을 의미한다.
• 애플리케이션을 계측하려면, 코드에 X-Ray SDK를 사용해야 한다.

• 이는 노드 제이에스로 계측한 예시다.
• 많은 SDK는 환경설정의 변경만 하면 돌아간다.
  • SDK에서 X-Ray로 계측 값을 보내는 방식을 변경하고 싶을 때 애플리케이션 코드를 입맛에 맞게 바꿀 수 있다.
  • 인터셉터나 필터, 핸들러 등을 사용하면 된다.

X-Ray 개념

• 세그먼트: 각 애플리케이션과 서비스에서 세그먼트를 보낸다. 세그먼트란 보통
  특정 서비스를 나타낸다. Ex) EC2, DB, 등등
• 서브 세그먼트: 세그먼트를 더 세분화 한 것이다. 세부사항을 기록하고 싶을 때 사용한다.
  Ex) Db가 세그먼트라면 서브 세그먼트는 날린 쿼리가 된다.
• Trace: 모든 세그먼트를 다 모은 것으로 사용자에서 사용자로 이동할 때 모든 세그먼트를 모은 것이 Trace다.
• Sampling: X-ray로 보내지는 요청의 양을 줄여, 비용을 감소시킨다.
• Annotiation: Trace를 인덱싱 하고, 필터를 사용하가 위해 키 밸류 쌍을 사용한다.
  • Trace를 추적하기 위한 좋은 방법이다.
• MetaData: 마찬가지로 키 밸류 쌍이다. 인덱스는 아니며 검색을 위해 사용되지도 않는다.
• X-Ray Demon: Trace를 수집해서 보낸다.
  • IAM 권한이 올바른지 반드시 확인해야 한다.
  • 모든 애플리케이션 추적을 위해 중앙 계정을 만들 수 있다.

 

X-Ray 샘플링

• 샘플링 규칙으로 X-Ray로 보내는 데이터의 양을 제어할 수 있다.
  • X-Ray로 가는 데이터가 많아질 수록 더 큰 비용을 지불해야 한다.
• 코드를 변경하지 않고 샘플링 규칙을 수정할 수 있다.
• 기본적으로, 샘플링 규칙은 SDK가 초마다 모든 첫 번째 요청을 기록하고, 다음 추가 요청의 5%를 기록한다.
  • 초마다 기록하는 첫 번째 요청은 reservior라고 하고, 이는 적어도 초당 하나의 추적이 기록되는 것을 보장한다.
  • 5%는 rate라고 하는데 리저버의 크기를 초과하는 추가 요청을 샘플링 한다.

X-Ray Custom Sampling Rule

• 마음대로 reservior와 rate를 만들 수 있다.

 

• Post 요청에서 sampling Role의 예시다.
• 리저버는 10이다. 즉, 초당 10개의 요청을 기록한다는 뜻이다.
  • Rate는 0.10.이다. 즉, 리저버 이외에 추가적으로 10%의 요청을 더 기록한다는 뜻이다.
• 이렇게 설정하면 당연히 X-Ray에 보내는 요청이 훨씬 많아진다. 

• 아렇게 Rate를 1로 설정하면 100% 즉, 모든 요청이 X-Ray로 보내지는 것이다.

X-Ray 콘솔에서 샘플링 규칙을 변경한 경우 애플리케이션을 재시작할 필요가 없다.

 

Demon이 자동으로 샘플링 규칙을 얻어, 규칙대로 데이터를 수집한다. 

 

X-Ray API (Used by the Daemon)

• 이는 쓰기와 관련된 권한이다.

1. PutTraceSegment: 세그먼트 문서를 X-Ray로 보내는 기능
2. PutTelemetryRecord: 세그먼트를 받는 횟수, 세그먼트를 거절한 횟수, 백엔드와의 연결 에러 등등을 체크한다.
3. GetSamplingRules: daemon이 샘플링 규칙을 얻어서 규칙에 맞게 세그먼트를 만들기 위해 호출한다.
4. GetSamplingTargets, GetSamplingStatisticSummaries: 마찬기지로 샘플링 규칙과 관련된 것이다.

이러한 API드의 권한이 모두 허용되어 있어야 Trace를 만들 수 있다.

 

이는 읽기와 관련된 권한들이다.

1. GetServiceGraph: 그래프를 가져온다.
2. BatchGetTraces: 특정 ID의 모든 Traces를 가져온다. Trace는 하나의 요청에서 발생하는 세그먼트들의 집합이다. 
3. GetTraceSummaries: 여러 Trace의 요약 정보를 가져온다. 
   트레이스를 전부 가져오는 것이 아니라, 다양한 트레이스의 간략한 정보들을 한 번에 확인할 수 있다.
4. GetTraceGraph: 특정 트레이스 ID에 해당하는 세그먼트들 간의 관계를 그래프로 가져온다.

X-Ray with Elastic Beanstalk

• 빈 스톡에서는 X-Ray 데몬이 포함돼 있어서 따로 추가할 필요가 없다. 
• 빈 스톡 콘솔에서 옵션 하나만 설정해 데몬을 실행할 수 있다.
  • 아니면 xray-daemon.config라는 .ebextention 파일을 생성해도 된다.
• EC2 인스턴스에 올바른 IAM 권한을 가진 인스턴스 프로필이 있는지 확인해야 된다.
• 계측을 위해 X-Ray SDK가 애플리케이션 코드에 존재하는지도 확인해야 한다.
• 멀티 컨테이너 도커를 사용중이라면 ECS로 X-Ray 데몬을 직접 관리해야 한다.
  • 멀티 컨테이너 도커에선 x-Ray 데몬이 기본적으로 지원되지 않는다.

ECS + X-Ray intergration options

• ECS 와 X-Ray를 통합하는 방법들에 대해서 배워보자

우선 ECS Cluster가 있다.

• 데몬 자체를 컨테이너로 사용한다. 
• 예를 들어, ECS 클러스터에, EC2 인스턴스 2개가 있다. 이 EC2 인스턴스에 데몬 작업을 실행하려 한다.
• 각각의 EC2 인스턴스마다 데몬을 위한 컨테이너를 만들고 실행한다.

두 번째 방법은 사이드카 패턴이라고 한다.

• 똑같이 EC2인스턴스 두 개가 있다고 해보자.
• 이번엔 애플리케이션 컨테이너 마다 하나의 X-Ray 데몬을 실행하고, 네트워크적으로 연결시키는 방식이다.
• 모든 컨테이너 마다 옆에 데몬이 하나씩 딸려가니 사이드카 패턴이라고 부르는 것이다.

Fargate 클러스터에서는 EC2 인스턴스를 제어할 수 없다.

단일 X-Ray 데몬용 컨테이너를 만들 수 없으므로, 사이드카 패턴으로 데몬을 사용해야 한다.

 

ECS + X-Ray Example Task Definition

• 데몬은 포트 2000 번에 UDP 프로토콜을 활용하여 정의 됐다.
• 밑의 ECS는 5000 포트로, 환경 변수에 데몬의 포트 번호를 명시해주고 있다.
  • 데몬의 포트 번호를 명시해주지 않으면 데몬을 찾을 수 없다.
• 마지막으로 links를 통해 ECS와 데몬 두 컨테이너를 연결해주는 것을 확인할 수 있다.

AWS Distro for OpenTelemetry

• 오픈 텔레메트리라는 일종의 프로젝트인데, AWS는 이 프로젝트의 배포판을 만들었다.
• 오픈 텔레메트리는 Trace, metric, log를 수집하는 서비스로 여러 플랫폼, 에서 작동하도록 설계되었다.
  • 당연히 AWS 서비스에서 메타데이터를 수집하는데 도움이 될 수 있다.
• X-Ray와 매우 비슷하지만 오픈 소스이며, 더 다양한 데이터를 수집하고 AWS에 국한되어 있지 않다는 차이점이 있다.
• 에이전트가 자동으로 계측값을 수집한다.
  • 코드를 바꿀 필요가 없다.
• 수집한 Trace, metiric 등을 여러 협력 업체로 보낼 수 있다.
  • X-Ray, CloudWatch, Prometheus ,, 
• X-Ray에서 오픈 텔레메트리로 데이터를 보낼 수도 있다.
• 텔레메트리의 오픈 소스 API로 표준화 하고 싶다면 말이다.

• 트레이스, 메트릭, 리소스의 정보를 수집해 
  X-Ray, CloudWatch, Prometheus, 협력 업체 등등으로 보낼 수 있다. 

AWS CloudTrail

• API 호출을 모두 감시하여, 보안 감사, 문제 해결, 비정상적 활동 감지, 변경 기록 등을 추적하는 서비스다.
• 콘솔 SDK, CLI, 계정 내 모든 이벤트의 기록과 API 호출을 얻게 해준다.
• 수집된 로그의 장기간 보관을 위해 CloudWatchLogs, S3 등으로 보낼 수 있다.
  • 기본적으로 90일까지 보관 가능하다.
  • 그 이상을 원하면 저기로 보내야 한다.
  • 이후 보관 중인 데이터의 분석을 원한다면 Athena로 보내 분석을 할 수 있다.
• 단일 리전을 추적할 수도 있고, 모든 리전을 추적할 수도 있다.
• 만약 누군가가 EC2 인스턴스를 삭제했다면 클라우드 트레일을 사용하면 된다.
  • 로그를 통해 누가 무엇을 언제 했는지 파악할 수 있다.

 

CloudTrail - Events

• ManageMent Event
  • 계정의 리소스에서 수행되는 작업의 정보를 수집한다.
    • 예를 들어, IAM AttachRolePolicy 라는 IAM 사용하고, 
    • 서브넷을 만드는 것,
    • 로그를 설정하는 것
    • 계정의 리소스에서 일어나는 모든 작업은 클라우드 트레일에 나타난다.
  • 관리 이벤트는 두 가지로 분리할 수 있다.
    • 읽기 이벤트 (리소스를 수정하지 못 함)
    • 쓰기 이벤트 (리소스를 수정할 수 있음)
• Data Event
  • 기본적으로 대용량이기 때문에 로그를 남기지 않는다.
    • getObject, putObject 같이 데이터가 오고가는 이벤트를 말한다.
  • 읽기와 쓰기를 분리할 수 있는 옵션이 있다.
  • 람다 기능 수행도 여기에 속한다.
    • 누군가 람다 API를 호출하는 것도 다 수집된다.
• CloudTrail Insights Events
  • 모든 서비스에서 관리 이벤트가 발생하면, 굉장히 많은 API가 발생한다.
    • 여기서 어떤 것이 특이하고, 어떤 것이 이상한지 구분해주는 역할을 하는 이벤트다.
  • 인사이트를 활성화하면 이벤트를 분석하고 비정상적인 활동을 찾아낸다.
    • 예를 들면, 작업 폭주, 서비스 제한 걸림 등등이 있다.
  • 인사이트가 정상 활동에 대한 기준선을 만들고
    • 이벤트가 올바른 유형인지 계속 분석한다. 
    • 비정상적인 이벤트를 감지한다.
  • 이렇게 감지된 비정상적인 이벤트는 클라우드 트레일 콘솔, S3 버킷, 이벤트 브릿지 등으로 보내진다.

CloudTrail + EventBridge

• 만약 DB가 삭제될 때마다 메일을 받고 싶다면 위 그림처럼
• 이벤트 브릿지로 이벤트를 보내고 특정 API 호출에 이벤트를 만들어 SNS 로 보낼 수 있다.
• 이 외에도 모든 API 호출마다 이벤트를 만들어 무궁 무진하게 활용할 수 있다.

CloudTrail vs CloudWatch vs X-Ray

• 클라우드 트레일
  • API 호출을 감지한다.
  • 승인되지 않은 호출을 감지하거나
  • API 호출로 인한 변경의 원인 탐지에도 사용된다.
• 클라우드 워치
  • 모니터링을 위해 지표를 사용한다.
  • 클라우드 워치 로그로 애플리케이션 로그를 저장하며
  • 클라우드 워치 알람으로 예상치 못한 지표가 나왔을 때 알림을 보낸다.
  • 모두 모니터링과 관련된 것이다.
• X-Ray
  • 자동화된 분석과 시각화 서비스
  • 이 때문에 큰 숲을 보기 좋다. 
  • 디버깅과 콘솔 내 지연 위치 분석, 오류 및 오류 분석 등에 정말 유용하다. 
  • 분산 시스템 전체에서 추적 요청을 얻을 수도 있다.