🔭헷갈리기 쉬운 AWS 클라우드의 모니터링 및 로깅 서비스 정리

안녕하세요 구독자님, DevOps 소식과 기술 지식을 정리해서 공유해드리는 DevOps 여행을 위한 소식지입니다.

AWS에는 수많은 서비스가 존재합니다. 데이터베이스부터 네트워크, 컴퓨팅, 로그 모니터링 등 폭 넓은 분야를 다루는 AWS 서비스는 그 수만 200개가 넘는데요.

같은 분야 안에 있는 서비스라 하더라도 쓰임새가 조금씩 달라서 각 차이를 명확히 알아야 올바르고 효율적으로 사용 가능합니다.

그래서 이번 글에서는 AWS의 로그 모니터링 기능 분야의 서비스를 비교해보려 합니다.

AWS의 대표적인 모니터링 및 로깅 서비스에는 3가지가 있습니다. 바로 CloudWatch, CloudTrail, X-Ray인데요.

서비스의 이름만으로는 각기 어떤 역할을 하는지, 어떤 차이가 있는지 알기 어렵습니다.

그래서 이번 글에서 이 3개의 AWS 서비스를 같이 살펴보고 비교해보도록 하려는데요. CloudWatch 먼저 알아볼게요.

CloudWatch는 언제 사용하나요?

CloudWatch는 AWS 클라우드 위에서 동작하는 리소스와 애플리케이션의 성능(또는 퍼포먼스)을 모니터링할 수 있는 서비스입니다.

우리가 CloudWatch를 사용하면...

AWS 리소스로부터 데이터를 수집하기 때문에 리소스의 퍼포먼스를 시각화 가능하고,

리소스 퍼포먼스의 변화에 알람을 보내거나 자동으로 대응하도록 설정 가능하며,

운영 중에 문제가 없는지 통합적으로 확인 가능하다는 장점이 있는데요.

CloudWatch는 기본적으로 리소스의 메트릭(시간이 지나면서 변화하는 데이터, 예: 리소스 사용률)이 저장되는 공간인데요.

EC2(AWS의 컴퓨팅 서비스)와 같은 AWS 리소스가 CloudWatch에 메트릭을 저장하면, 사용자는 위와 같이 리소스의 퍼포먼스를 메트릭의 통계로 확인할 수 있는 것입니다. 참고로 사용자가 커스텀하게 정의한 메트릭도 CloudWatch에서 저장 및 통계가 가능합니다.

그리고 CloudWatch의 알람 기능은 이렇게 저장된 메트릭이 사용자 정의된 특정 조건에 부합하면 미리 지정한 행동(리소스 중지, 시작, 제거 등)을 취하는 것을 말합니다.

정리하자면, 메트릭을 저장하고 통계를 제공하는 CloudWatch는 아래와 같이 활용 가능합니다.

애플리케이션 성능 모니터링: 성능 데이터를 시각화하고 알람을 설정해서 AWS 리소스의 성능 이슈를 파악하고 해결

문제 원인 분석: 문제 발생 시 메트릭을 분석해서 원인 파악 및 해결

AWS 리소스 사용량 최적화: 미리 정의한 특정 AWS 리소스의 메트릭(예: EC2의 CPU 또는 메모리 사용량)이 임계값에 도달 시 수행해야 할 조치를 설정해서 리소스 사용량을 자동으로 조정하고 비용 절약

CloudTrail도 비슷한 거 아닌가요?

CloudTrail의 이름에도 Cloud가 포함되기 때문에 CloudWatch와 유사한 서비스라고 생각하기 쉬운데요. 사실 두 서비스의 성격은 꽤 다릅니다.

CloudWatch가 리소스의 메트릭을 지켜본다면(Watch), CloudTrail은 AWS 사용자가 어떤 행위를 했었는지 추적(Trail)하는 서비스이기 때문인데요.

AWS CloudTrail은 AWS 계정이 어떤 행위를 했는지 그 흔적을 추적합니다.

AWS 계정에 대해 규정 준수 여부를 확인하거나 감사(Audit)를 수행하기 위해 만들어진 서비스가 바로, CloudTrail입니다.

사용자는 AWS 계정이 새로 생성되는 시점부터 CloudTrail에 접근 가능한데요. 특히 CloudTrail의 Event History 기능을 사용해서 지난 90일 동안 AWS 계정에서 발생한 이벤트(AWS 리소스 생성, 수정 제거 등)의 기록을 확인, 검색, 다운로드할 수 있게 됩니다.

Event History에서는 지난 90일 동안 발생한 AWS 계정의 이벤트만 조회 가능하기 때문에, 이런 이벤트를 더 오래 보관하려면 CloudTrail Lake라는 기능으로 이벤트 데이터 저장소를 생성해야 하는데요.

CloudTrail Lake를 사용 시 추가 비용이 발생할 수 있지만, 해당 기능에서는 아래와 같이 대시보드를 통해 AWS 계정의 이벤트 트렌드를 시각화할 수 있습니다.

그래서 CloudTrail은 아래와 같이 활용 가능합니다.

규정 준수 및 감사: 규정 준수 여부 증명에 필요한 정보를 CloudTrail 로그로 활용

보안: AWS 계정의 이용자 및 API 행위를 기록하여 보안성 제고

운영: AWS 계정에서 발생한 이벤트를 검색하여 이슈 분석에 활용 가능. CloudTrail Lake 대시보드에서 AWS 계정 이벤트의 트렌드를 시각화

이렇게 CloudTrail과 CloudWatch는 성격과 쓰임새가 서로 다릅니다.

그럼 X-Ray는요?

AWS X-Ray는 프로덕션 단계 또는 배포된 애플리케이션을 분석하고 디버깅 가능한 서비스인데요.

X-Ray를 사용하면...

애플리케이션에 대한 사용자의 요청(Request)을 쉽게 추척 가능하고,

병목 현상과 높은 대기 시간(Latency)을 파악할 수 있어 애플리케이션의 성능 향상에 활용 가능하며,

실시간으로 서버리스 애플리케이션을 디버깅함으로써 클라우드 사용 비용 절약과 성능 향상이 가능하다는 이점이 있습니다.

애플리케이션 성능이라고 하니 위에서 살펴봤던 CloudWatch가 떠오르는데요.

CloudWatch는 애플리케이션이나 AWS 리소스에 대한 메트릭을 수집하고 통계 및 조치가 가능하다고 했었죠.

하지만 X-Ray는 해당 애플리케이션을 거치는 사용자의 요청을 기반으로 디버깅을 하거나, 성능 분석이 가능하다는 점에서 CloudWatch와 다릅니다.

X-Ray의 동작 방식을 살펴보면 그 차이점을 좀 더 명확하게 알 수 있는데요.

먼저 X-Ray를 사용하려는 애플리케이션에서 X-Ray SDK를 통해 X-Ray 데몬으로 세그먼트 정보를 전송합니다.

X-Ray SDK(Software Development Kit)는 애플리케이션 내에서 자체 수정 없이도 메타 데이터를 쉽게 기록하고 AWS의 X-Ray로 전달할 수 있도록 고안된 소프트웨어 개발 도구 모음인데요. C#, Java, Go, Node.js, Python, Ruby로 개발된 애플리케이션에서 X-Ray SDK를 사용 가능합니다.

참고로, AWS Lambda, AWS Elastic Beanstalk 등에서는 X-Ray와 바로 연동 가능한 설정이 존재합니다.

세그먼트(Segment)란 X-Ray에서 사용되는 개념으로, 호스트 정보와 요청 및 응답, 작업 내용, 발생 이슈에 대한 정보가 담긴 메타 데이터를 말합니다.

X-Ray 데몬은 전달받은 데이터를 X-Ray 콘솔로 다시 전송하는데요. 이후 사용자는 웹 브라우저 상에서 X-Ray 콘솔로 접근하여 애플리케이션 분석 및 디버깅이 가능하게 되는 것입니다.

X-Ray 콘솔에서는 아래와 같이 애플리케이션이 요청을 받고 보내는 애플리케이션과 AWS 리소스를 그림으로 보여줄 뿐만 아니라, 각 요청과 응답에 걸리는 시간도 함께 보여주기 때문에 병목 현상이나 레이턴시도 확인 가능합니다.