현재 모니터링의 어려움
운영자는 종종 알람은 발생했지만 무엇이 문제인지 바로 알아차리기 힘든 상황에 처합니다.
특히 시스템이 복잡해지고 서비스와 컴포넌트가 긴밀하게 연결되어 있는 경우, 단일 지표에 대한 알람 만으로 문제를 정확히 파악하기가 점점 어려워지고 있습니다.
CloudWatch, Datadog, Prometheus 등 다양한 모니터링 툴이 있지만, 대다수는 개별 메트릭이나 로그를 중심으로 동작합니다.
예를 들어 CPU 알람이 떴을 때, 운영자는 로그, 네트워크 지표, 디스크 상태 등을 모두 찾아서 확인해야합니다.
이러한 상황에서 운영자는 다음과 같은 한계를 자주 마주하게 됩니다:
- 알람은 떴지만 무엇을 먼저 확인해야 할지 모르는 상황
- 연관 지표/로그를 일일이 찾는 데 드는 시간과 정신적 피로
- 팀 간 협업 시 진단 정보가 흩어져 있어 커뮤니케이션 지연 발생
이러한 상황에서는 문제의 구조와 연결성을 빠르게 파악하고, 시각화 하는 것이 문제를 해결할 수 있는 주요한 요소라고 생각합니다.
AWS를 사용하는 환경이라면, 2025년 6월에 정식 출시한 Amazon CloudWatch의 CloudWatch Investigations 기능을 통해 알람과 관련된 지표, 로그, 인프라 상태를 하나의 흐름으로 연결하여 확인 할 수 있어서 알람의 원인을 빠르게 파악하는데 도움이 될 수 있을 것입니다.
CloudWatch Investigations 기능이란
- 알람과 연결된 로그, 메트릭, 리소스 상태를 자동 수집 및 연결
- 연관 인프라 컴포넌트들을 하나의 시각적 흐름으로 표시
- 클릭 기반으로 다음 탐색을 유도하는 탐사형 인터페이스 제공
- SSM Runbook 또는 Slack을 통한 대응 자동화 가능
CloudWatch Investigations는 단순히 이상 징후를 감지하는 것을 넘어서 ‘무엇이 이상하다’가 아니라 ‘왜 이런 일이 발생했는가’에 주목하도록 설계된 기능입니다.
CloudWatch Investigations는 생성형 AI를 활용한 탐색형 인터페이스를 통해 문제 발생 시점 전후의 지표와 로그 흐름을 따라가며 원인 후보를 좁혀갈 수 있도록 설계된 도구입니다.
운영자에게 필요한 것은 단순 수치의 이상 유무가 아니라, 그 숫자가 어떤 맥락에서 발생했는지 빠르게 파악하는 것이 중요합니다.
CloudWatch Investigations는 그러한 해석의 출발점을 시각적으로 제시해주는 역할을 하여, 운영자의 경험 의존도를 줄이는 데 기여하는데 도움이 될 것이라고 생각합니다.
또한, 탐색형 인터페이스를 통해 문제 발생 시점 이전/이후의 흐름을 따라갈 수 있게 한다는 점에서 기존 CloudWatch Alarm과는 다른 접근법입니다.
실시간성보다는 구조적 맥락을 제공한다는 데 의의가 있습니다..
(단, 외부 API 문제나 네트워크 경로상의 이슈 등은 여전히 별도의 도구나 지표가 필요할 수 있습니다.)
다음으로는, CloudWatch Investigations가 지원되는 리전에 대해 살펴 보겠습니다.
CloudWatch Investigations는 다음과 같은 리전에 대해 Cross‑Region inference 지원과 함께 제공하고 있습니다.
| 지리 영역 (Geography) | 지원 리전 | 가능한 inference 리전 |
|---|---|---|
| United States (US) | US East (N. Virginia), US East (Ohio), US West (Oregon) | 해당 리전 자체 간 inference 가능 |
| Europe (EU) | Europe (Frankfurt), Ireland, Paris, Stockholm | 미국 리전들 및 유럽 리전들 간 inference (예: Frankfurt ↔ N. Virginia 등) |
| Asia ‑Pacific (AP) | Mumbai, Hong Kong, Singapore, Sydney, Tokyo, Malaysia, Thailand | 각 AP 리전에서 US East (N. Virginia), US East (Ohio), US West (Oregon) 로 inference 가능 |
위에 나열된 리전들이 CloudWatch Investigations 사용 리전이며 리전 간에 Cross‑Region inference가 지원됩니다.
데이터는 기본 리전에만 저장되지만, 교차 리전 추론을 사용하면 조사 데이터가 기본 리전 외부로 이동할 수 있습니다.
모든 데이터는 Amazon의 보안 네트워크를 통해 암호화되어 전송됩니다.
CloudWatch Investigations 사용 예시
CloudWatch Investigations는 단순한 지표 나열이 아닌, 장애의 실질적인 ‘맥락’을 따라가는 구조적 분석 도구입니다.
아래는 실제 운영 환경에서 자주 마주치는 장애 시나리오에 대해, Investigations가 어떤 식으로 흐름을 추적하고 구조화된 정보를 제공할 수 있는지를 보여주는 예시입니다
- 다중 알람 폭주 → 동일 시점에 여러 알람이 발생할 때, 공통 리소스(AZ, Subnet 등)를 기준으로 상관관계를 시각적으로 분석해 공통 원인을 좁혀나갈 수 있습니다.
- EC2 CPU 상승 → CPU 알람 발생 시, 해당 인스턴스의 디스크 및 네트워크 지표, 상태 로그까지 함께 분석해 원인을 유추할 수 있습니다.
- ALB 오류 증가 → ALB에 연결된 Target Group과 EC2 인스턴스 상태, 응답 코드 패턴 등을 시간 흐름에 따라 자동으로 연결해 원인 분석에 도움을 줍니다.
CloudWatch Investigations 사용해보기
복잡한 실습이 아닌, 전체 개념을 따라가기 위한 시뮬레이션 중심 흐름 설명입니다.
1. EC2 인스턴스 하나를 생성하고, CloudWatch Agent를 통해 로그 수집을 설정합니다.
2. CPU 사용률이 60%를 초과하면 경고 알람이 발생하도록 설정합니다.
3. 의도적으로 CPU 부하를 발생시켜 알람을 트리거합니다.
4. CloudWatch 콘솔에서 알람 → “Investigate” 버튼 클릭
5. 연결된 로그, 메트릭, 리소스 상태를 하나의 흐름처럼 따라가며 확인합니다.
이를 통해 이상 징후 → 원인 후보 → 대응 액션까지의 구조를 실제로 따라가 볼 수 있습니다.
CloudWatch Investigations 사용해보기 (상세)
1. EC2 인스턴스 준비
- IAM Role: CloudWatchAgentServerPolicy 포함
1-2.CloudWatch Agent 설치 및 설정
sudo yum install -y amazon-cloudwatch-agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
- CPU, Memory, Disk 등의 메트릭 수집 설정 후 에이전트 시작
3. CloudWatch Alarm 생성
- 조건:
CPUUtilization > 60%, 지속 시간 2분 이상 - 알람 이름:
HighCPUAlarm
3-2. 부하 유발 명령어 실행
CPU 부하가 올라가도록 한 뒤 알람이 발생할 때까지 대기
4. CloudWatch Investigations 실행
- 알람 발생 후 → CloudWatch 콘솔 → 알람 상세 보기 → [Investigate] 버튼 클릭
5. 자동으로 연결된 메트릭, 로그, 관련 인프라 컴포넌트 확인
6. (선택) Runbook 실행
- AWS Systems Manager → 자동화 문서 생성
- 예: EC2 재시작 or 경고 Slack 전송
- Investigations 화면에서 직접 연동 가능
제가 시도한 CPU 부하 테스트의 경우 stress --cpu 명령어로 CPU 부하를 인위적으로 발생시켰습니다.
그러나 실시간으로 함께 증가한 디스크 쓰기 작업에 대한 메트릭까지 CloudWatch가 포착했고, 결과적으로 CPU 알람의 원인으로 EBS Volume의 쓰기 지연과 큐 길이 증가를 보여주었다.
이는 실제 원인과 완전히 일치하진 않더라도, 운영 중 문제 발생 시 관련된 지표와 리소스 흐름을 빠르게 연결해 볼 수 있는 강점을 의미합니다.
즉, CloudWatch Investigations는 “어느 지표와 리소스가 연관돼 있었는가”를 통해
장애의 맥락(Context) 을 파악하는 데 도움을 주는 것으로 ,
꼭 ‘정답’을 제시하지 않더라도 “조사의 실마리”를 제공한다는 점에서 유용할 수 있다고 생각됩니다.
운영자의 시선에서 본 활용 포인트
CloudWatch Investigations를 단순히 신규 기능으로 받아들이기보다는, 기존 모니터링 체계의 보완재로 접근하는 것이 실무 도입에 현실적인 전략입니다.
많은 기업에서는 이미 다양한 APM, 로그 분석 도구, 대시보드를 통해 관찰성과 가시화를 확보하고 있습니다.
그러나 문제가 생겼을 때 “무엇부터 봐야 할지”를 체계적으로 안내해주는 구성은 부족한 경우가 많습니다.
CloudWatch Investigations는 그런 의미에서 관찰 데이터를 연결하고 순서를 제시해주는 ‘조사 가이드’ 역할을 해줄 수 있을 것이라고 생각합니다.
특히 아래와 같은 운영 니즈에 부합할 수 있을 것 같습니다.
- 여러 팀이 협업하는 장애 대응 체계에서, 동일한 ‘흐름의 시각’을 공유하고 싶은 경우
- 온콜 엔지니어나 주니어 운영자가 구조적 분석을 처음 접할 때, 탐색 경로의 시작점과 다음 단계를 도구가 제시해주길 바라는 경우
- 알람은 많지만 어떤 알람이 중요한지 파악하기 어려울 때, 연관된 메트릭과 로그를 통해 중요도와 영향도를 구조적으로 판단하고 싶은 경우
결과적으로, CloudWatch Investigations는 문제 해결 자체보다는 문제 해결의 방향을 탐색하는 과정을 지원하는 도구입니다.
단독으로 모든 원인을 해결하진 않지만, 복잡한 장애 상황에서 무엇부터 살펴봐야 할지를 제시해주는 도구로써의 가치가 있을 것입니다,
🔔 Slack 연동을 통해 팀 협업 강화
- AWS Chatbot을 이용해 알람과 분석 흐름을 Slack 채널로 전달
- 무료 플랜에서도 사용 가능 (제한 유의)
🔔 Runbook으로 자동 대응 연계
- SSM을 통해 EC2 재시작, 보안그룹 차단 등 자동화된 대응 가능
- Investigations Action을 통해 반자동 대응 구성 가능
🔔 운영 체계에 녹이기
- 기존 장애 대응 플레이북에 ‘Investigate 활용 절차’를 추가
- 알람 설계 시, 단독 메트릭보다 맥락 추적 가능한 구조로 설계
마무리하며
CloudWatch Investigations는 기존 CloudWatch의 연장선에 있는 기능이지만, 기존 도구와는 다른 ‘문제 맥락 중심’의 접근 방식을 보여줍니다.
물론 모든 운영 환경에 만능처럼 들어맞지는 않을 것입니다.
정량 지표 위주의 인프라나 단순한 워크로드에서는 과한 기능일 수 있고, 오히려 간단한 대시보드와 룰 기반 경보 시스템이 더 효과적일 수도 있습니다.
하지만 문제의 흐름을 구성하기 어려운 환경, 알람은 많은데 원인을 좁히기 힘든 환경이라면 CloudWatch Investigations는 충분히 사용해볼 가치가 있는 도구입니다.
결국 중요한 것은 도구 자체가 아니라, 도구가 제안하는 ‘탐색의 관점’을 우리의 운영 환경에 어떻게 녹여낼 수 있느냐라고 생각합니다.
지금 운영 중인 환경에서 알람과 원인을 연결하는 데 어려움이 있다면, 이번 글에서 소개한 CloudWatch Investigations 기능이 작게나마 도움이 되었기를 바랍니다.
어떤 도구든 운영자의 상황에 맞게 잘 활용되는 것이 가장 중요하다는 점, 기억해주시면 좋겠습니다.
긴 글 읽어주셔서 감사합니다.
<참고자료>
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Investigations-Security.html