AWS CCP 자격증 - 12 (클라우드 모니터링)

CloudWatch

먼저 CloudWatch의 지표 제공 서비스를 살펴보도록 하겠습니다

 

CloudWatch는 AWS 내 모든 서비스에 대한 지표를 제공하며 이때 지표는 모니터링 대상이 되는 변수입니다.

예로는 CPUUtilization나 NetworkIn 등이 있죠 지표는 시간에 대한 내용을 포함하므로 타임스탬프를 갖습니다.

모든 지표를 한 번에 시각화할 수 있도록

CloudWatch 지표 대시보드를 생성할 수도 있습니다.

 

EC2 인스턴스에 대해서는 CPUUtilization이 있는데 이는 CPU가 현재 얼마나 사용되고 있으며

사용량이 늘어나면 인스턴스의 작업량이 과도하게 늘기 때문에

이때는 스케일 업이나 아웃이 필요하다는 판단을 할 수도 있습니다.

 

StatusCheck은 EC2 인스턴스가 제대로 작동하는지 확인하는 지표이며

Network는 얼마나 많은 네트워크가 인스턴스 안팎에서 실행되고 있는지를 살펴보는 지표입니다.

그리고 화면에 나와 있듯 RAM은 EC2 인스턴스에 적합한 지표가 되지 못합니다

앞서 말한 지표는 5분마다 제공되지만 더 비싼 옵션인 Detailed Monitoring을 활성화하여 1분마다 해당 지표를 제공받을 수도 있습니다

 

다음은 데이터를 저장하는 EBS 볼륨에 대한 지표를 볼 텐데

Disk Read/Writes로 디스크에 읽고 쓰는 정보를 알 수 있습니다

 

다음으로 S3 버킷 관련 지표로는 BucketSizeBytes NumberOfObjects 그리고 AllRequests 등 S3 버킷에 대한 요청 수를 알 수 있고

 

과금 관련 지표는 앞서 봤던 Total Estimated Charge로 us-east-1 리전에서만 지원하지만

사용자 전체 계정의 과금 내역을 볼 수 있습니다

 

다음으로는 서비스 한도에 관한 지표로 서비스 API 사용량을 볼 수 있습니다

끝으로 원하는 지표를 찾지 못한 경우 사용자 지정 지표를 생성할 수도 있습니다.

CloudWatch 경보는 지표에 대한 알림을 트리거 할 때에 사용됩니다.

 

즉 지표가 임계값을 넘어서면 CloudWatch 경보가 실행된다는 겁니다

이와 같은 경보로는 먼저 오토 스케일링 그룹이 희망하는 EC2 인스턴스의 수를 늘리거나 줄여서

자동 스케일링이 가능하도록 하는 오토 스케일링 작업과 EC2 인스턴스를 중지, 종료 재시작 또는 복구하는 EC2 작업그리고 SNS 주제에 대해 알림을 보내는 SNS 알림 작업이 있습니다

 

예를 들어서 EC2 인스턴스의 사용률이 90%가 넘을 경우 문제가 발생했는지 살펴볼 수 있도록 이메일로 알려 달라고 설정할 수 있겠죠

 

이 외에도 다양한 옵션이 있습니다 경보 생성이나 샘플링, % 표시 최대, 최솟값 등을 설정할 수 있고

경보를 평가할 기간을 정할 수도 있죠 5분, 10분, 1시간 등으로 말입니다.

 

끝으로 CloudWatch 과금 지표를 이용하여 과금 경보를 생성할 수 있습니다

 

지표에 대한 과금이 10달러나 20달러를 넘을 경우 알림을 받도록 설정할 수 있습니다.

아무 문제 없는 그린일 경우의 경보 상태는 OK,

그린인지 불량인지를 확인할 데이터 포인트가 충분하지 않은 경우는 INSUFFICIENT_DATA

불량한 경우는 ALARM이 뜹니다

 

Amazon CloudWatch Logs

 

이름에서 알 수 있듯 CloudWatch Logs는 로그 파일을 수집합니다

그럼 로그 파일이란 무엇일까요? 어느 서버든 간에 실행되는 애플리케이션에 대해 작업 내역에 대한 기록을 시킬 겁니다.

사용자에 대한 작업을 수행하거나 정리 등을 수행할 때에 말이죠 수집된 모든 로그 파일은 사용자가 트러블 슈팅을 수행할 때에 해당 로그 파일로 가서 애플리케이션의 작업이나 설명을 확인할 때에 쓰입니다

로그 파일의 형식은 다양하나 Elastic Beanstalk을 이용해 로그를 수집할 수 있죠

ECS, Lambda, CloudTrail CloudWatch 로그 에이전트에서 로그를 수집할 수 있는데 EC2 머신이나

온프레미스 서버에 로그 에이전트를 설치하여 해당 서버에서 AWS로 직접 로그를 가져올 수 있습니다

혹은 DNS 대기열을 로깅하는 Route53도 있죠

전반적으로 CloudWatch Logs는 이 모든 로그를 수집하여 로그에 대한 실시간 모니터링을 지원하며

이를 통해 로그에 발생하는 모든 상황에 대응할 수 있습니다 또한 보존 목적으로 로그를 재조정할 수도 있는데

즉 로그를 일주일이나, 30일, 1년 혹은 영원히 보존되도록 설정할 수 있다는 의미입니다.

EC2 인스턴스에서는 CloudWatch Logs가 어떻게 작동할까요?

기본적으로 EC2 인스턴스는 CloudWatch Logs에 로그 파일을 전송하지 않습니다

전송을 위해서는 EC2 인스턴스에 CloudWatch 로그 에이전트를 생성해야 합니다

그 후 생성한 에이전트가 CloudWatch Log 서비스로 로그 파일을 푸시하죠 요악해 보자면 실행 중인 CloudWatch Logs 서비스가 있고 EC2 인스턴스가 있을 때, 이 인스턴스에 CloudWatch 로그 에이전트를 설치하면 해당 에이전트가 바로 CloudWatch Logs에 로그 파일을 전송합니다.

 

이를 위해서는 해당 EC2 인스턴스에 CloudWatch Logs로 로그 데이터를 전송할 수 있는

올바른 IAM 권한을 갖는 인스턴스 역할이 있는지 확인해야 합니다

또한 로그 에이전트는 온프레미스 서버에도 설치할 수 있는데 이를 하이브리드 에이전트라고 부릅니다

 

이 에이전트는 온프레미스 또는 AWS 모두에서 작동하며

이를 통해 EC2 인스턴스와 온프레미스 서버 모두에서 로그 파일을 수집하여 CloudWatch Log 서비스로 보낼 수 있습니다

 

Amazon EventBridge

예전에는 CloudWatch 이벤트라고 불렸습니다

따라서 CloudWatch Events라고 하면 Amazon EventBridge를 생각하세요, 반대도 마찬가지입니다.

EventBridge가 새로운 이름입니다

EventBridge를 사용하면 AWS 계정 내에서 발생하는 이벤트에 대처할 수 있어요.

한 가지 사용 사례는 크론 작업을 예약하는 거에요

정기적으로 스크립트를 예약하고 싶다고 해보죠

예를 들어 EventBridge에서 1시간마다 이벤트가 생성된다는 규칙을 만들 수 있고

그 이벤트는 람다 함수에서 실행되는 스크립트를 트리거한다고 할 수 있습니다.

사실상 서버리스 크론 작업이죠, 또한 매시간 발생하는 이벤트에 반응할뿐만 아니라

서비스가 하는 작업에 대해서도 반응할 수도 있어요

 

예를 들어, 누군가가 루트 사용자를 사용하여 로그인할 때마다

보안 팀에 알림을 보낼 수 있어요, 왜냐하면 루트 사용자는 매우 드물게만 사용해야 하니까요

 

즉, IAM 루트 사용자 로그인 이벤트에 반응하여, 이를 이메일 알림과 결합된 SNS 토픽으로 보내는 거죠

그러면 누군가가 로그인할 때마다 이메일을 받게 되겠죠, 이렇게

Amazon EventBridge를 사용하여 다양하게 통합할 수 있어요, 목적지를 추가하거나

람다 함수를 트리거하거나, SQS/SNS 메시지를 보낼 수 있죠 할 수 있는 일은 이렇게나 많아요

 

 

기본 이벤트 버스라는 것도 있는데, AWS 서비스 또는 예를 들어 사용자의 Schedules 내에서 발생하는 이벤트입니다.

AWS의 파트너로부터 이벤트를 수신할 수도 있어요

예를 들어 Zendesk나 Datadog 또는 AWS의 파트너인 다른 서비스를 사용하는 경우 파트너 이벤트 버스를 통해 이벤트를 여러분의 계정으로 보낼 수 있어요

 

즉, AWS 외부에서 발생하는 이벤트에도 대응할 수 있어요

마지막으로, 여러분의 사용자 정의 애플리케이션을 연결할 수 있어요

사용자 정의 이벤트 버스를 연결하여, 원하는 통합을 만들고 전부 커스터마이징할 수 있죠

 

EventBridge에는 다른 기능도 많아요 스키마 레지스트리가 있어서, 이벤트 스키마를 모델링하여 스키마의 모양 및 데이터 유형 등을 확인할 수 있어요

또한 모든 이벤트를 아카이브하고 이벤트 버스로 보낼 수 있죠, 무기한 또는 설정된 기간 동안요

이렇게 보관된 이벤트를 재생할 수도 있어요

 

AWS CloudTrail

 

CloudTrail은 AWS 계정에 대한 거버넌스, 규정 준수, 감사를 제공하는 서비스입니다

계정을 사용할 때마다 기본적으로 활성화됩니다, 왜냐하면 CloudTrail은 계정 내에서 발생하는 모든 API 호출 또는 이벤트 기록을 가져오기 때문입니다.

 

매우 중요한 거죠, 왜냐하면 예를 들어 누군가가 콘솔에 로그인해서 어떤 작업을 하든

전부 CloudTrail에 기록되는 거니까요

만약 누군가가 SDK를 사용하면 CloudTrail에 기록됩니다

만약 누군가가 명령줄 인터페이스로 명령을 실행하면, 이 명령도 CloudTrail에 기록됩니다

어떤 서비스 활동이라도 CloudTrail에 기록됩니다

 

즉, 일어나는 모든 일이 CloudTrail에 기록된다는 뜻입니다

따라서 감사 및 보안 목적으로, CloudTrail 내에서 수행된 모든 이벤트 및

API 호출 기록을 가져와서, 두 군데, 즉 CloudWatch Logs 또는 Amazon S3로 보낼 수 있습니다

 

CloudTrail에서 트레일을 생성하면, 모든 리전에 적용하여 모니터링할 수 있어요 트레일은 CloudWatch Logs 또는 Amazon S3로 가거나, 단일 리전으로 추적할 수 있죠

 

시험 문제는 이렇게 나와요, 예를 들어, "사용자가 무언가를 삭제했다면"

"무엇을 누가 언제 삭제했는지 어떻게 알 수 있습니까?"라고 물어보죠 이 문제의 답은 CloudTrail이에요

API 호출을 찾아봐야 한다는 얘기가 나오면 CloudTrail이 정답이에요

 

정리해 볼게요, CloudTrail 콘솔 안에서 SDK 및 CLI, 콘솔, 모든 IAM 사용자, IAM 역할, 이들이 수행하는 모든 API 호출 정보를 얻을 수 있어요

 

CloudTrail 콘솔에 표시되지만, 데이터를 장기적으로 보존하려면

CloudWatch Logs 또는 S3 버킷으로 전송할 수 있어요

또한 CloudTrail 내에서 모든 유형의 검사 및 감사를 수행할 수 있어요

 

AWS X-Ray

또 다른 서비스인 AWS X-Ray를 살펴보겠습니다

기본적으로 어떤 분들은 프로덕션 환경에서 디버깅을 합니다

애플리케이션이 배포됐을 때 기본의 방식은 로컬에서 테스트한 뒤 CloudWatch Logs 등에 로그 상태를 추가하고

프로덕션 환경에서 다시 배포해서 문제를 확인하는 것입니다.

하지만 문제는 여러 서비스와 여러 애플리케이션의 로그가 있다는 것입니다

그리고 모두 결합해야 하기 때문에 로그 분석은 정말 어렵죠

아주 큰 모놀리스(Monolith)인 거대한 애플리케이션이라면 디버깅이 쉬운 편이지만

분산된 서비스이며 SQS 대기열과 SNS 주제로 연결되어 있거나 분리돼 있는 경우는 시스템에서 발생하는 일을

추적하기 매우 어렵습니다

그래서 전체 아키텍처의 일반적 뷰가 없습니다 이 문제를 해결하려면 AWS X-Ray를 사용합니다

 

X-Ray를 사용해서 애플리케이션을 추적하고 시각적 분석을 할 수 있습니다

 

 

따라서 서비스에서 X-Ray를 활성화하면 각 서비스에서 일어나는 일을 전체적으로 볼 수 있어서

장애나 성능을 확인할 수 있고 요청이 잘못된 경우에는 X-Ray 콘솔에서 바로 시각화할 수 있습니다

X-Ray의 장점은

병목 현상을 통해서 성능 문제를 해결하거나

마이크로서비스 아키텍처의 종속성을 이해할 수 있습니다

이전 그래프와 같이 모두 연결되어 있기 때문입니다

추적을 통해 서비스 문제를 파악할 수 있고

특정 요청을 검토할 수 있으며

해당 요청의 오류와 예외 사항을 찾을 수 있습니다

그리고 서비스 수준에 관한 계약인 SLA를 충족하는지도 알 수 있는데

이는 모든 요청을 제시간에 응답하는지를 말합니다

 

어떤 서비스에서 스로틀 되거나 속도가 느려지는 현상이 발생하면 이 장애의 영향을 받는 사용자를 식별할 수 있습니다

 

따라서 X-Ray는 분산 추적 및 문제 해결과 서비스 그래프에 유용합니다

 

Amazon CodeGuru (머신러닝 기반 서비스)

Amazon CodeGuru를 살펴보겠습니다 머신 러닝 기반 서비스로 2가지를 실행합니다

 

첫 번째는 자동화된 코드 검토이고

애플리케이션 성능 권장 사항이 두 번째입니다

 

개발자가 코드를 푸시하면 다른 개발자가 코드를 검토하고 코드가 프로덕션에 배포되면 코드의 성능을 모니터링하고

버그를 탐지할 수도 있습니다 CodeGuru에서 자동화된 방식으로 수행합니다

 

CodeGuru Reviewer는 정적 코드 분석으로 자동화된 코드 검토를 실행합니다 코드를 CodeCommit이나 GitHub와 같은

리포지토리에 배포하면 CodeGuru에서 전체 코드줄을 확인해 이전에 살펴봤던 버그나 메모리 누수와 같은 경우에 실행 가능한 권장 사항을 제공하는 것입니다.

그리고 머신 러닝 기능으로 Reviewer가 탐지하기도 전에 버그를 탐지해 매우 유용합니다

 

CodeGuru Profiler는 프로덕션이나 런타임 도중에 애플리케이션 성능에 관한 가시성과 권장 사항을 제공합니다.

애플리케이션을 설계하고 테스트하면 CodeGuru Profiler가 비용이 높은 사전 프로덕션 환경의 코드줄을 탐지하고 최적화 합니다.

 

그리고 애플리케이션을 배포하면 실시간 애플리케이션을 측정하는데 CodeGuru Profiler가 프로덕션에서 성능과 비용 개선 사항을 식별해 코드에 바로 권장 사항을 제공합니다 이것이 CodeGuru의 장점입니다

 

 

조금 더 자세히 살펴보면 CodeGuru Reviewer는 코드를 푸시할 때마다

커밋을 확인하고 잘못된 코드줄을 알려줍니다 

정말 유용하죠 중요한 문제를 식별하고 보안 취약성과 찾기 힘든 버그를 식별합니다

예를 들어, 코딩 모범 사례를 구현할 수 있고 리소스 누수를 찾거나 보안 허점이 생기거나 입력값 유효성을 검사할 때 보안 탐지를 할 수 있으며 머신 러닝과 자동화된 추론을 사용해 실행합니다

CodeGuru에서 수천 개의 오픈 소스 리포지토리와 모든 amazon.com 리포지토리에서 분석한 코드 분석을 사용하는 것이죠 이런 방식으로 머신 러닝을 통해 코드 Reviewer가 학습합니다.

 

현재는 Java와 Python을 지원하고 GitHub, Bitbucket 그리고 CodeCommit과 통합되었습니다 제가 말한 게 전부가 아니고 나중에 더 늘어날 수도 있습니다

 

Profiler는 애플리케이션이 프로덕션 환경에 있거나사전 프로덕션 환경에 있을 때 애플리케이션의 런타임을 이해하고

로깅 루틴 등에서 CPU 사용률을 과도하게 소비하는 것을 확인할 수 있습니다.

 

따라서 코드 비효율성을 식별하고 제거해 CPU 사용률을 줄이고 컴퓨팅 비용을 줄이며

어떤 객체가 메모리 공간을 많이 차지하는지를 식별하는 힙(heap) 요약을 제공할 뿐만 아니라 애플리케이션에 문제가 생긴 경우 이상 탐지를 제공해 애플리케이션의 성능을 개선합니다

 

AWS 클라우드와 온프레미스에서 실행되는 애플리케이션도 지원합니다 CodeGuru Profiler를 사용해 모니터링할 애플리케이션에서 최소한의 오버헤드가 발생합니다.

CodeGuru와 CodeGuru Reviewer, CodeGuru Profiler만 알면 됩니다.

 

AWS Health Dashboard 

대시보드는 크게 두 부분으로 나뉩니다 (서비스 기록과 계정)

 

서비스 기록에는 모든 리전과 서비스 상태가 표시됩니다 이렇게 보입니다

따라서 서비스가 어떻게 작동했는지, 어떤 문제가 있었는지 리전별로 추적할 수 있습니다.

기록을 볼 수도 있습니다 이건 매일의 기록이고요, RSS 피드가 있어서 구독할 수도 있죠

이전에는 AWS Service Health 대시보드라고 불렸습니다

 

다음으로 볼 것은, 사용자 계정의 AWS Health 대시보드입니다

예전에는 AWS Personal Health 대시보드(PHD)라고 불렀습니다

하지만 지금은 그냥 계정 Health 대시보드라고 해요

사용자에게 직접적인 영향을 미치는 이벤트가 AWS에서 발생할 때, 알림과 해결 지침을 알려줍니다.

 

서비스 상태 대시보드에는 모든 서비스의 일반적인 상태가 표시되지만 계정 상태 대시보드에서는 사용자의 계정과 리소스에서 사용 중인 서비스의 성능과 가용성을 확인할 수 있습니다.

 

시기적절한 관련 정보를 제공하며, 알림도 보내줍니다 예정된 유지 관리 활동을 미리 살펴볼 수 있도록요

또한 계정 상태 대시보드에서는 사용자의 AWS 전체 조직의 데이터를 집계할 수 있어요

상태 대시보드에 액세스하려면 오른쪽 상단 모서리 종 아이콘을 클릭하면 돼요

이건 글로벌 서비스에요, 또한 사용자에게 직접적인 영향을 미치는 운영 중단도 보여줍니다

Event log에서는 과거 이벤트를 확인할 수 있고요

예를 들어, 여기에는 us-east-2에 저에게 영향을 줄 수 있는 EC2 이슈가 있네요

 

알림, 문제 해결 정보, 사전 예방적 알림을 받을 수 있어요

예정된 변경 사항이나 예정된 활동이 있는 경우에요

클라우드 모니터링 요약

첫 번째는 CloudWatch로 여러 가지 종류가 있습니다

 

- CloudWatch Metrics은 AWS 서비스의 성능과 요금 지표를 모니터링하고

- CloudWatch Alarms로는지표가 특정 범위를 벗어나면 자동으로 알림을 받고 재부팅과 같은

EC2 인스턴스를 실행하도록 자동화 할 수 있습니다. 특정 제한을 초과하는 지표를 기반으로 SNS 서비스에 정리 알림을 보낼 수도 있습니다.

- CloudWatch Logs는 EC2 인스턴스나 서버 혹은 람다 함수에서 로그 파일 수집 시 사용하며 한 가지 서비스로 중앙화됩니다

- CloudWatch Events는 Events Bridge라고도 하며 AWS 이벤트에 반응하거나 특정 예약을 기반으로 규칙을 트리거 하는 방식입니다.

- 계정 내에서 발생한 API 호출을 감사하려면 CloudTrail 서비스를 사용합니다.

- 무엇보다 CloudTrail Insights로 CloudTrail 이벤트에 관한 자동화된 분석을 얻을 수 있습니다.

- Amazon X-Ray는 분산 애플리케이션을 통한 요청을 추적하는 데 사용합니다 특히 오류가 발생했고 모든 애플리케이션이 서로 통신할 때 성능을 분석하거나 근본 원인을 분석할 때 매우 유용합니다.

- Service Health Dashboard에서는 모든 리전 전반의 모든 AWS 서비스에 관한 상태를 확인할 수 있습니다.

- 조금 더 개인화된 것이 필요하면 배포나 인프라에 직접 영향을 미치는 AWS 이벤트에 관한 알림을 제공하는 Personal Health Dashboard를 사용합니다

- 마지막은 CodeGuru입니다 CodeGuru는 머신 러닝으로 자동화된 코드 검토를 실행하고 프로덕션 환경 내 애플리케이션의 성능을 모니터링해 애플리케이션 성능 권장 사항을 제공하며 이 또한 머신 러닝을 활용해 제공합니다