AWS CloudWatch 모니터링 완벽 가이드

초급 개발자를 위한 CloudWatch 모니터링 입문서입니다. EC2 인스턴스 상태 확인부터 알람 설정, 로그 관리까지 실무에 필요한 핵심 기능을 쉽게 배울 수 있습니다.

1. CloudWatch란?

첫 출근을 한 김개발 씨는 선배로부터 "서버 상태 좀 확인해봐"라는 요청을 받았습니다. 하지만 서버가 정상인지 어떻게 확인해야 할지 막막했습니다.

바로 그때 선배가 CloudWatch를 소개해주었습니다.

CloudWatch는 AWS 리소스와 애플리케이션을 실시간으로 모니터링하는 서비스입니다. 마치 자동차 계기판처럼 서버의 상태를 한눈에 보여줍니다.

CPU 사용률, 메모리, 네트워크 트래픽 등 다양한 지표를 수집하고 시각화할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

# CloudWatch 클라이언트 생성
cloudwatch = boto3.client('cloudwatch')

# 최근 1시간 CPU 사용률 조회
response = cloudwatch.get_metric_statistics(
    Namespace='AWS/EC2',  # EC2 메트릭 네임스페이스
    MetricName='CPUUtilization',  # CPU 사용률 지표
    Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}],
    StartTime=datetime.utcnow() - timedelta(hours=1),
    EndTime=datetime.utcnow(),
    Period=300,  # 5분 간격
    Statistics=['Average']  # 평균값 조회
)

print(f"평균 CPU 사용률: {response['Datapoints']}")

김개발 씨는 입사 첫날부터 중요한 임무를 맡았습니다. 회사에서 운영 중인 쇼핑몰 서버의 상태를 확인하는 일이었습니다.

하지만 AWS 콘솔에 로그인해도 어디서부터 봐야 할지 감이 잡히지 않았습니다. 선배 개발자 박시니어 씨가 다가와 물었습니다.

"서버 상태 확인해봤어요?" 김개발 씨는 난처한 표정으로 대답했습니다. "어디서 확인하는지 모르겠어요." 박시니어 씨는 웃으며 CloudWatch 대시보드를 열어주었습니다.

화면에는 다양한 그래프와 수치가 실시간으로 변하고 있었습니다. CloudWatch란 무엇일까요? 쉽게 비유하자면, CloudWatch는 자동차의 계기판과 같습니다.

운전할 때 속도계, 연료 게이지, 엔진 온도 등을 확인하듯이, 서버 관리자는 CloudWatch를 통해 CPU 사용률, 메모리, 네트워크 상태를 확인합니다. 계기판 없이 운전하는 것이 위험한 것처럼, CloudWatch 없이 서버를 운영하는 것도 매우 위험합니다.

모니터링이 없던 시절에는 어땠을까요? 과거에는 서버 관리자가 직접 서버에 접속해서 명령어를 입력해야 했습니다. 한 대의 서버라면 괜찮지만, 수십 대, 수백 대의 서버를 관리한다면 어떨까요?

하나씩 접속해서 확인하는 것은 비효율적일 뿐만 아니라 실시간 모니터링도 불가능했습니다. 더 큰 문제는 장애 발생을 뒤늦게 알게 된다는 점이었습니다.

사용자가 "사이트가 안 열려요"라고 연락하고 나서야 문제를 인지하는 경우가 많았습니다. 그때는 이미 비즈니스에 큰 손실이 발생한 후였습니다.

CloudWatch가 이 모든 문제를 해결합니다 CloudWatch를 사용하면 모든 AWS 리소스의 상태를 한 곳에서 확인할 수 있습니다. EC2 인스턴스뿐만 아니라 RDS 데이터베이스, Lambda 함수, ELB 로드밸런서 등 AWS의 거의 모든 서비스를 모니터링할 수 있습니다.

가장 큰 장점은 실시간 모니터링이 가능하다는 점입니다. 1분 단위로 데이터가 수집되며, 상세 모니터링을 활성화하면 1초 단위까지 가능합니다.

문제가 발생하면 즉시 알 수 있습니다. 또한 자동화된 알람 설정도 큰 이점입니다.

CPU 사용률이 80%를 넘으면 자동으로 이메일이나 SMS를 보낼 수 있습니다. 새벽에 잠들어 있어도 서버가 스스로 관리자에게 알려줍니다.

코드를 통해 CloudWatch 이해하기 위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리로 CloudWatch 클라이언트를 생성합니다.

이것은 Python에서 AWS 서비스를 제어하는 공식 SDK입니다. get_metric_statistics 메서드는 특정 지표의 통계 데이터를 가져옵니다.

Namespace는 어떤 AWS 서비스인지 지정하는 것이고, MetricName은 구체적으로 어떤 지표인지를 나타냅니다. CPU 사용률, 네트워크 입출력, 디스크 읽기/쓰기 등 다양한 지표가 있습니다.

Dimensions는 필터 조건입니다. 특정 EC2 인스턴스의 데이터만 가져오고 싶을 때 인스턴스 ID를 지정합니다.

Period는 데이터 집계 간격으로, 300초는 5분을 의미합니다. 실무에서는 어떻게 활용할까요? 실제 쇼핑몰 서비스를 운영한다고 가정해봅시다.

블랙프라이데이 세일 기간에는 평소보다 트래픽이 10배 이상 증가합니다. CloudWatch를 통해 실시간으로 서버 부하를 확인하고, 필요하면 Auto Scaling으로 서버를 자동 증설할 수 있습니다.

많은 기업에서 CloudWatch 데이터를 기반으로 용량 계획을 수립합니다. 최근 3개월간의 트래픽 패턴을 분석하여 다음 분기에 필요한 서버 스펙을 미리 예측하는 것입니다.

주의할 점도 있습니다 초보 개발자들이 흔히 하는 실수는 너무 많은 지표를 한꺼번에 보려고 한다는 점입니다. CloudWatch는 수백 가지 지표를 제공하지만, 처음부터 모두 볼 필요는 없습니다.

CPU, 메모리, 네트워크 정도만 먼저 익숙해지면 충분합니다. 또한 지표를 조회할 때 시간 범위를 너무 길게 설정하면 응답이 느려질 수 있습니다.

필요한 시간 범위만 정확히 지정하는 것이 좋습니다. 이제 시작입니다 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 CloudWatch 콘솔을 직접 열어보았습니다. 그래프에서 CPU 사용률이 안정적으로 유지되고 있는 것을 확인하고 안도했습니다.

CloudWatch를 이해하면 서버 관리가 훨씬 쉬워집니다. 문제가 생기기 전에 미리 대응할 수 있고, 데이터 기반으로 의사결정을 내릴 수 있습니다.

여러분도 오늘부터 CloudWatch를 활용해보세요.

실전 팁

💡 - 처음에는 CPU, 메모리, 네트워크 3가지 지표만 집중해서 모니터링하세요

비용 절감을 위해 기본 모니터링(5분 간격)으로 시작하고, 필요할 때만 상세 모니터링(1분 간격)을 사용하세요
CloudWatch 대시보드를 북마크에 추가하여 매일 아침 확인하는 습관을 들이세요

2. 기본 메트릭 확인

김개발 씨는 CloudWatch 콘솔을 열었지만 수많은 그래프와 숫자들에 압도당했습니다. "이 중에서 뭘 봐야 하죠?" 선배는 가장 중요한 기본 메트릭부터 알려주기로 했습니다.

메트릭은 CloudWatch가 수집하는 측정값입니다. CPU 사용률, 네트워크 트래픽, 디스크 I/O 등 서버의 건강 상태를 나타내는 지표들입니다.

마치 건강검진에서 혈압, 혈당, 콜레스테롤을 확인하듯이 서버도 핵심 메트릭을 정기적으로 확인해야 합니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch')

# 사용 가능한 모든 메트릭 목록 조회
metrics = cloudwatch.list_metrics(
    Namespace='AWS/EC2',  # EC2 서비스의 메트릭
    MetricName='CPUUtilization'  # CPU 사용률 메트릭
)

# 메트릭 정보 출력
for metric in metrics['Metrics']:
    print(f"메트릭 이름: {metric['MetricName']}")
    print(f"네임스페이스: {metric['Namespace']}")
    print(f"차원(Dimensions): {metric['Dimensions']}")
    print("---")

# 특정 인스턴스의 메트릭만 필터링
instance_metrics = cloudwatch.list_metrics(
    Namespace='AWS/EC2',
    Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}]
)

김개발 씨는 CloudWatch 콘솔에서 수십 개의 그래프를 발견했습니다. CPUUtilization, NetworkIn, NetworkOut, DiskReadBytes, DiskWriteBytes...

용어들이 낯설었습니다. 박시니어 씨가 설명했습니다.

"처음에는 다 복잡해 보이지만, 핵심만 알면 간단해요. 건강검진을 생각해보세요." 메트릭은 서버의 건강검진 항목입니다 사람이 건강검진을 받을 때 혈압, 혈당, 콜레스테롤 등을 측정합니다.

각 수치마다 정상 범위가 있고, 이를 벗어나면 문제가 있다는 신호입니다. 서버도 마찬가지입니다.

CPUUtilization은 혈압과 같습니다. 너무 높으면 서버가 과부하 상태이고, 지속적으로 낮으면 서버가 제대로 활용되지 않는다는 의미입니다.

정상 범위는 보통 30-70% 정도입니다. NetworkIn과 NetworkOut은 혈액 순환과 같습니다.

들어오는 트래픽과 나가는 트래픽을 측정합니다. 갑자기 트래픽이 급증하면 DDoS 공격일 수도 있고, 트래픽이 0에 가까우면 서비스가 중단된 것일 수도 있습니다.

메트릭이 없던 시절의 어려움 과거에는 서버에 직접 SSH로 접속해서 top 명령어를 입력해야 CPU 사용률을 확인할 수 있었습니다. 그것도 그 순간의 스냅샷만 볼 수 있었습니다.

한 시간 전에 무슨 일이 있었는지 알 수 없었습니다. 네트워크 트래픽을 확인하려면 ifconfig나 netstat 명령어를 사용해야 했습니다.

하지만 이것도 실시간 값만 보여줄 뿐, 시간에 따른 추세를 파악하기는 어려웠습니다. 더 큰 문제는 여러 서버를 관리할 때였습니다.

10대의 서버가 있다면 10번 접속해서 일일이 확인해야 했습니다. 비효율적이고 실수하기 쉬운 방법이었습니다.

CloudWatch 메트릭이 모든 것을 자동화합니다 CloudWatch는 모든 메트릭을 자동으로 수집하고 저장합니다. 기본적으로 5분 간격으로 데이터를 수집하며, 최대 15개월까지 보관합니다.

과거 데이터를 언제든지 조회할 수 있다는 뜻입니다. 네임스페이스는 메트릭을 분류하는 카테고리입니다.

AWS/EC2는 EC2 관련 메트릭, AWS/RDS는 데이터베이스 관련 메트릭을 의미합니다. 이렇게 분류되어 있어서 원하는 메트릭을 쉽게 찾을 수 있습니다.

코드로 메트릭 목록 가져오기 위의 코드에서 list_metrics 메서드는 사용 가능한 모든 메트릭을 나열합니다. Namespace를 지정하면 특정 서비스의 메트릭만 필터링할 수 있습니다.

Dimensions는 메트릭을 더 세밀하게 필터링하는 조건입니다. 예를 들어 InstanceId 차원을 사용하면 특정 EC2 인스턴스의 메트릭만 조회할 수 있습니다.

수백 대의 서버 중 문제가 있는 한 대만 집중해서 볼 수 있는 것입니다. 반환된 결과에는 MetricName, Namespace, Dimensions 정보가 포함됩니다.

이 정보를 활용하여 나중에 get_metric_statistics로 실제 데이터를 조회할 수 있습니다. 실무 활용 사례 실제 금융 서비스를 운영하는 회사에서는 DiskReadOps와 DiskWriteOps 메트릭을 중요하게 모니터링합니다.

데이터베이스 성능이 디스크 I/O에 크게 영향을 받기 때문입니다. 디스크 읽기/쓰기가 비정상적으로 증가하면 쿼리 최적화가 필요하다는 신호입니다.

게임 서비스에서는 NetworkIn 메트릭을 주시합니다. 게임 업데이트를 배포할 때 수백만 명의 사용자가 동시에 다운로드하면 네트워크 대역폭이 포화될 수 있습니다.

이를 미리 예측하고 대비해야 합니다. 초보자가 주의할 점 처음에는 모든 메트릭을 다 보려고 하지 마세요.

CPU, 메모리, 네트워크 이 세 가지만 제대로 이해해도 충분합니다. 경험이 쌓이면 자연스럽게 다른 메트릭도 필요하게 됩니다.

또한 메트릭 이름을 정확히 입력해야 합니다. CPUUtilization인데 CpuUtilization으로 쓰면 데이터를 못 가져옵니다.

대소문자를 정확히 구분해야 합니다. 메트릭을 친구로 만드세요 김개발 씨는 하나씩 메트릭을 클릭해보며 그래프를 확인했습니다.

CPU는 평균 40%, 네트워크는 안정적으로 유지되고 있었습니다. "이제 좀 감이 잡히네요!" 메트릭을 이해하면 서버의 언어를 알아듣게 됩니다.

서버가 "지금 너무 힘들어요"라고 말하는 것을 CPU 메트릭으로 알 수 있고, "네트워크가 끊어졌어요"라는 것을 NetworkOut 메트릭으로 알 수 있습니다. 여러분도 메트릭과 친해지세요.

실전 팁

💡 - 처음에는 CPU, 네트워크, 디스크 3가지 메트릭만 집중하세요

메트릭 이름은 대소문자를 정확히 구분해야 합니다
각 메트릭의 정상 범위를 파악하여 기준선을 만들어두세요

3. EC2 모니터링

"서버가 느린 것 같아요." 김개발 씨에게 동료가 말했습니다. 하지만 막연히 "느리다"는 것만으로는 원인을 찾을 수 없었습니다.

EC2 모니터링을 통해 정확한 원인을 찾아야 했습니다.

EC2 모니터링은 가상 서버의 성능과 상태를 추적하는 과정입니다. CPU, 메모리, 네트워크, 디스크 등 다양한 지표를 실시간으로 확인하여 문제를 조기에 발견할 수 있습니다.

마치 자동차 정비소에서 엔진 상태를 점검하듯이 서버의 모든 구성 요소를 체크합니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

ec2 = boto3.client('ec2')
cloudwatch = boto3.client('cloudwatch')

# 모든 실행 중인 EC2 인스턴스 조회
instances = ec2.describe_instances(
    Filters=[{'Name': 'instance-state-name', 'Values': ['running']}]
)

# 각 인스턴스의 CPU 사용률 확인
for reservation in instances['Reservations']:
    for instance in reservation['Instances']:
        instance_id = instance['InstanceId']

        # 최근 1시간 CPU 평균 조회
        cpu_stats = cloudwatch.get_metric_statistics(
            Namespace='AWS/EC2',
            MetricName='CPUUtilization',
            Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
            StartTime=datetime.utcnow() - timedelta(hours=1),
            EndTime=datetime.utcnow(),
            Period=300,
            Statistics=['Average', 'Maximum']  # 평균과 최대값
        )

        if cpu_stats['Datapoints']:
            avg_cpu = cpu_stats['Datapoints'][0]['Average']
            max_cpu = cpu_stats['Datapoints'][0]['Maximum']
            print(f"인스턴스 {instance_id}: 평균 CPU {avg_cpu:.2f}%, 최대 CPU {max_cpu:.2f}%")

오전 10시, 김개발 씨의 슬랙에 메시지가 도착했습니다. "쇼핑몰 로딩이 너무 느려요.

확인 좀 해주세요." 사용자들의 불만이 접수되기 시작했습니다. 김개발 씨는 당황했습니다.

어제까지만 해도 정상이었는데 무엇이 문제일까요? 코드를 변경한 것도 없고, 배포도 하지 않았습니다.

박시니어 씨에게 급하게 연락했습니다. "일단 EC2 모니터링 화면부터 보세요." 박시니어 씨가 차분하게 말했습니다.

EC2 모니터링은 서버의 건강검진입니다 사람이 아플 때 병원에 가서 검사를 받듯이, 서버도 이상 증상이 있으면 모니터링 데이터를 확인해야 합니다. 체온, 혈압, 맥박을 재는 것처럼 서버의 CPU, 메모리, 네트워크를 체크합니다.

EC2 인스턴스는 AWS의 가상 서버입니다. 여러분이 임대한 컴퓨터라고 생각하면 됩니다.

이 컴퓨터가 제대로 작동하는지 확인하려면 상태 지표를 봐야 합니다. 기본 모니터링 vs 상세 모니터링 CloudWatch는 두 가지 모니터링 수준을 제공합니다.

기본 모니터링은 5분 간격으로 데이터를 수집하며 무료입니다. 상세 모니터링은 1분 간격으로 수집하며 추가 비용이 발생합니다.

대부분의 경우 기본 모니터링으로 충분합니다. 하지만 트래픽 변화가 급격한 서비스라면 상세 모니터링이 필요할 수 있습니다.

5분이면 이미 수천 명의 사용자가 불편을 겪었을 수도 있기 때문입니다. 모니터링 없이 운영했던 과거 과거에는 사용자가 "느려요"라고 신고하면, 관리자가 서버에 접속해서 top 명령어로 CPU를 확인했습니다.

하지만 그 순간의 상태만 볼 수 있었습니다. 10분 전에 CPU가 100%였는지 알 수 없었습니다.

더 큰 문제는 여러 서버를 운영할 때였습니다. 웹 서버 3대, 데이터베이스 서버 2대를 운영한다면, 5대 모두에 접속해서 상태를 확인해야 했습니다.

그 사이에 다른 서버에서 문제가 생길 수도 있었습니다. CloudWatch로 모든 인스턴스를 한눈에 CloudWatch를 사용하면 모든 EC2 인스턴스를 한 화면에서 볼 수 있습니다.

위의 코드처럼 실행 중인 모든 인스턴스를 자동으로 찾아서 각각의 CPU 사용률을 확인할 수 있습니다. describe_instances 메서드는 EC2 인스턴스 목록을 가져옵니다.

Filters를 사용하여 실행 중인 인스턴스만 필터링했습니다. 중지된 인스턴스는 모니터링할 필요가 없기 때문입니다.

각 인스턴스마다 get_metric_statistics를 호출하여 CPU 사용률을 조회합니다. Statistics에 Average와 Maximum을 함께 지정했습니다.

평균값만으로는 순간적인 스파이크를 놓칠 수 있기 때문입니다. 코드 실행 결과 해석하기 코드를 실행하면 각 인스턴스의 평균 CPU와 최대 CPU가 출력됩니다.

예를 들어 "평균 CPU 40%, 최대 CPU 95%"라면 어떤 의미일까요? 평균은 낮지만 최대값이 높다는 것은 순간적인 스파이크가 있었다는 뜻입니다.

특정 시점에 요청이 몰렸거나, 무거운 작업이 실행되었을 가능성이 있습니다. 이런 패턴을 파악하면 원인을 찾을 수 있습니다.

반대로 "평균 CPU 90%, 최대 CPU 95%"라면 지속적인 고부하 상태입니다. 서버 스펙이 부족하거나, 비효율적인 코드가 실행되고 있을 가능성이 높습니다.

서버 증설이나 코드 최적화가 필요합니다. 실무 적용 사례 실제 전자상거래 회사에서는 매일 오전 이 코드를 자동으로 실행합니다.

모든 서버의 전날 CPU 사용률을 리포트로 만들어 운영팀에 전달합니다. 이상 징후가 있으면 즉시 조치를 취합니다.

또 다른 회사에서는 이 코드를 Lambda 함수로 만들어 1시간마다 실행합니다. CPU가 80%를 넘는 인스턴스가 있으면 자동으로 슬랙에 알림을 보냅니다.

관리자가 24시간 모니터링 화면을 볼 필요가 없습니다. 주의할 점 초보자들이 흔히 하는 실수는 CPU만 보고 판단한다는 것입니다.

CPU는 정상인데 네트워크가 병목일 수도 있고, 메모리 부족일 수도 있습니다. 여러 지표를 종합적으로 봐야 합니다.

또한 시간대별 패턴을 이해해야 합니다. 점심시간에 CPU가 높은 것은 정상입니다.

사용자가 많이 접속하는 시간이기 때문입니다. 새벽 3시에 CPU가 높다면 이상한 것입니다.

문제를 찾았습니다 김개발 씨는 코드를 실행하고 결과를 확인했습니다. 웹 서버 1번의 CPU가 평균 92%였습니다.

다른 서버는 40% 정도인데 1번만 유독 높았습니다. 로드밸런서 설정이 잘못되어 트래픽이 한쪽으로만 몰린 것이었습니다.

문제를 수정하자 CPU가 고르게 분산되었고, 서비스 속도도 정상으로 돌아왔습니다. "모니터링이 없었다면 원인을 찾지 못했을 거예요." 김개발 씨가 감탄했습니다.

실전 팁

💡 - CPU 외에도 네트워크와 디스크를 함께 확인하세요

평균값뿐만 아니라 최댓값도 함께 체크하여 스파이크를 놓치지 마세요
시간대별 정상 패턴을 파악하여 비정상 상황을 빠르게 인식하세요

4. 대시보드 생성

매번 코드를 실행하거나 콘솔을 여러 번 클릭하는 것이 번거로웠습니다. 김개발 씨는 "한 화면에서 모든 걸 볼 수는 없나요?"라고 물었습니다.

바로 CloudWatch 대시보드가 그 해답이었습니다.

대시보드는 여러 메트릭을 한 화면에 모아서 보여주는 시각화 도구입니다. 마치 자동차 운전석의 계기판처럼 속도계, 연료 게이지, 엔진 온도를 한눈에 볼 수 있습니다.

CPU, 메모리, 네트워크 그래프를 한 곳에 배치하여 서버 상태를 실시간으로 파악할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

cloudwatch = boto3.client('cloudwatch')

# 대시보드 생성
dashboard_name = 'MyEC2Dashboard'

dashboard_body = {
    "widgets": [
        {
            "type": "metric",
            "properties": {
                "metrics": [
                    ["AWS/EC2", "CPUUtilization", {"stat": "Average"}]
                ],
                "period": 300,
                "stat": "Average",
                "region": "ap-northeast-2",
                "title": "EC2 CPU 사용률",
                "yAxis": {"left": {"min": 0, "max": 100}}
            }
        },
        {
            "type": "metric",
            "properties": {
                "metrics": [
                    ["AWS/EC2", "NetworkIn", {"stat": "Sum"}],
                    [".", "NetworkOut", {"stat": "Sum"}]
                ],
                "period": 300,
                "stat": "Sum",
                "region": "ap-northeast-2",
                "title": "네트워크 트래픽"
            }
        }
    ]
}

# 대시보드 생성 또는 업데이트
response = cloudwatch.put_dashboard(
    DashboardName=dashboard_name,
    DashboardBody=json.dumps(dashboard_body)
)

print(f"대시보드 생성 완료: {dashboard_name}")

김개발 씨는 매일 아침 출근하면 CloudWatch 콘솔에 들어가서 CPU 그래프를 클릭하고, 네트워크 그래프를 클릭하고, 디스크 그래프를 클릭했습니다. 매번 같은 작업을 반복하는 것이 비효율적이라고 느꼈습니다.

"이거 자동화할 수 있나요?" 김개발 씨가 박시니어 씨에게 물었습니다. "물론이죠.

대시보드를 만들면 됩니다." 대시보드는 나만의 관제 센터입니다 항공 관제탑을 상상해보세요. 관제사는 수십 개의 모니터를 한눈에 보며 모든 비행기를 추적합니다.

각 비행기마다 일일이 정보를 검색하지 않습니다. 모든 정보가 한 공간에 실시간으로 표시됩니다.

CloudWatch 대시보드도 마찬가지입니다. 중요한 메트릭을 한 화면에 배치하여 서버의 모든 상태를 실시간으로 모니터링할 수 있습니다.

아침에 출근하면 대시보드 하나만 열어보면 됩니다. 수동으로 그래프를 찾던 과거 과거에는 각 메트릭을 개별적으로 조회해야 했습니다.

Metrics 탭에 들어가서 EC2를 선택하고, CPUUtilization을 찾고, 인스턴스를 선택하는 과정을 매번 반복했습니다. 10개의 메트릭을 확인하려면 10번의 클릭과 검색이 필요했습니다.

하루에 3번씩 확인한다면? 30번의 반복 작업입니다.

일주일이면 210번입니다. 시간 낭비가 심각했습니다.

게다가 여러 팀원이 같은 메트릭을 봐야 하는 경우에는 더 복잡했습니다. 각자가 자기 방식대로 그래프를 찾아보다 보니 놓치는 것도 생기고, 소통도 어려웠습니다.

대시보드로 모든 것이 간단해집니다 대시보드를 만들면 한 번의 클릭으로 모든 정보를 볼 수 있습니다. URL을 북마크에 저장하면 매일 아침 그 페이지만 열면 됩니다.

팀원들과 대시보드 URL을 공유하면 모두가 같은 화면을 보며 소통할 수 있습니다. 위의 코드에서 widgets는 대시보드에 표시할 그래프 목록입니다.

각 위젯은 하나의 차트를 의미합니다. CPU 그래프, 네트워크 그래프 등을 원하는 만큼 추가할 수 있습니다.

metrics 배열에는 표시할 메트릭을 지정합니다. ["AWS/EC2", "CPUUtilization"]은 EC2의 CPU 사용률을 의미합니다.

여러 메트릭을 한 그래프에 겹쳐서 표시할 수도 있습니다. 코드의 핵심 부분 이해하기 period는 데이터 집계 간격입니다.

300초는 5분을 의미합니다. 1시간 단위로 보고 싶다면 3600을 지정하면 됩니다.

시간 범위가 길수록 그래프가 덜 세밀하지만 전체 추세를 파악하기 좋습니다. yAxis 설정은 Y축의 범위를 지정합니다.

CPU는 0%에서 100% 사이 값이므로 min: 0, max: 100으로 고정하면 그래프가 항상 같은 스케일로 표시됩니다. 시각적으로 비교하기 쉬워집니다.

put_dashboard 메서드는 대시보드를 생성하거나 업데이트합니다. 같은 이름의 대시보드가 이미 있으면 덮어쓰고, 없으면 새로 만듭니다.

코드를 여러 번 실행해도 안전합니다. 실무 활용 사례 스타트업에서는 사무실 벽에 큰 모니터를 걸어두고 CloudWatch 대시보드를 24시간 띄워놓습니다.

모든 개발자가 언제든지 서버 상태를 확인할 수 있습니다. 문제가 생기면 즉시 알아챌 수 있습니다.

대기업에서는 서비스별로 대시보드를 분리합니다. 결제 시스템 대시보드, 추천 엔진 대시보드, 사용자 인증 대시보드 등 각 팀이 자기 영역의 대시보드를 관리합니다.

책임 소재가 명확해지고 집중도가 높아집니다. 금융 서비스에서는 규제 준수를 위해 대시보드를 아카이빙합니다.

특정 시점의 서버 상태를 스크린샷으로 저장하여 나중에 감사 자료로 사용합니다. 실전 팁 대시보드에는 너무 많은 그래프를 넣지 마세요.

한 화면에 10개 이상의 차트가 있으면 오히려 집중력이 떨어집니다. 핵심 메트릭 5-7개만 선별하는 것이 좋습니다.

그래프의 배치 순서도 중요합니다. 가장 중요한 메트릭을 화면 왼쪽 위에 배치하세요.

사람의 시선은 자연스럽게 왼쪽 위에서 시작하기 때문입니다. 색상을 활용하면 더 직관적입니다.

CPU는 빨간색, 메모리는 파란색, 네트워크는 초록색처럼 일관된 색상 규칙을 정하면 한눈에 구분할 수 있습니다. 이제 김개발 씨의 루틴이 바뀌었습니다 김개발 씨는 자신만의 대시보드를 만들었습니다.

매일 아침 커피를 마시며 대시보드를 체크합니다. 5초 만에 모든 서버가 정상인지 확인할 수 있습니다.

팀 회의에서도 대시보드를 공유 화면에 띄워놓습니다. "어제 CPU 스파이크 있었죠?"라고 말하며 그래프를 가리킵니다.

모두가 같은 데이터를 보며 대화하니 의사소통이 훨씬 명확해졌습니다.

실전 팁

💡 - 한 대시보드에 5-7개의 핵심 메트릭만 배치하세요

가장 중요한 그래프를 왼쪽 위에 배치하여 시선을 집중시키세요
팀원들과 대시보드 URL을 공유하여 같은 화면을 보며 협업하세요

5. 알람 설정하기

새벽 2시에 서버가 다운되었습니다. 하지만 아무도 모르고 있었습니다.

아침에 출근한 김개발 씨는 고객 불만 메일을 보고서야 문제를 알았습니다. "미리 알 수 있는 방법은 없나요?"

알람은 메트릭이 특정 임계값을 넘으면 자동으로 알려주는 기능입니다. 마치 화재 경보기처럼 평소에는 조용하다가 위험한 상황이 되면 즉시 경고합니다.

CPU가 80%를 넘거나 네트워크 오류가 발생하면 이메일이나 SMS로 알림을 받을 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch')
sns = boto3.client('sns')

# SNS 토픽 생성 (알림을 받을 채널)
topic_response = sns.create_topic(Name='ServerAlerts')
topic_arn = topic_response['TopicArn']

# 이메일 구독 추가
sns.subscribe(
    TopicArn=topic_arn,
    Protocol='email',
    Endpoint='dev@example.com'  # 알림 받을 이메일
)

# CPU 사용률 알람 생성
cloudwatch.put_metric_alarm(
    AlarmName='HighCPUAlarm',
    ComparisonOperator='GreaterThanThreshold',  # 임계값보다 클 때
    EvaluationPeriods=2,  # 2번 연속으로 조건을 만족해야 알람
    MetricName='CPUUtilization',
    Namespace='AWS/EC2',
    Period=300,  # 5분 간격
    Statistic='Average',
    Threshold=80.0,  # 80% 임계값
    ActionsEnabled=True,
    AlarmActions=[topic_arn],  # 알람 발생 시 SNS로 전송
    AlarmDescription='CPU 사용률이 80%를 초과했습니다',
    Dimensions=[
        {'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}
    ]
)

print("알람 설정 완료: CPU 80% 초과 시 이메일 발송")

그날 밤, 김개발 씨는 편안히 잠들어 있었습니다. 하지만 회사의 EC2 서버는 CPU 100%로 과부하 상태였습니다.

웹사이트는 응답하지 않았고, 수백 명의 고객이 접속을 포기했습니다. 다음 날 아침, 출근한 김개발 씨는 고객 지원팀으로부터 연락을 받았습니다.

"밤새 사이트가 다운되어 있었어요. 왜 조치하지 않았나요?" 김개발 씨는 아무것도 몰랐습니다.

박시니어 씨가 말했습니다. "모니터링만으로는 부족해요.

알람을 설정해야 합니다." 알람은 잠들지 않는 파수꾼입니다 화재 경보기를 생각해보세요. 평소에는 조용히 천장에 붙어 있다가 연기를 감지하면 큰 소리로 경보를 울립니다.

여러분이 잠들어 있어도, 다른 일을 하고 있어도 화재를 알려줍니다. CloudWatch 알람도 똑같습니다.

24시간 내내 메트릭을 감시하다가 임계값을 넘으면 즉시 알려줍니다. 개발자가 화면을 보고 있든 말든 상관없습니다.

문제가 생기면 자동으로 통보합니다. 알람이 없던 시절의 악몽 과거에는 관리자가 직접 모니터링 화면을 계속 지켜봐야 했습니다.

하지만 사람이 24시간 화면만 볼 수는 없습니다. 잠도 자야 하고, 식사도 해야 하고, 회의도 해야 합니다.

대기업에서는 교대 근무를 했습니다. 낮 근무자, 밤 근무자를 나눠서 24시간 누군가는 모니터링 화면을 지켜봤습니다.

인건비도 많이 들고, 야간 근무는 건강에도 해로웠습니다. 스타트업에서는 그럴 여유가 없었습니다.

개발자가 개발도 하고 모니터링도 해야 했습니다. 결국 문제를 놓치는 경우가 많았고, 고객 불만으로 이어졌습니다.

알람이 모든 것을 자동화합니다 CloudWatch 알람은 사람 대신 메트릭을 감시합니다. CPU 사용률을 1분마다 체크하고, 임계값을 넘으면 즉시 SNS(Simple Notification Service)로 알림을 보냅니다.

SNS는 알림 전달 서비스입니다. 이메일, SMS, 슬랙, 전화 등 다양한 채널로 메시지를 보낼 수 있습니다.

개발자가 가장 선호하는 방식으로 알림을 받을 수 있습니다. 코드로 알람 설정하기 위의 코드를 단계별로 살펴보겠습니다.

먼저 SNS 토픽을 생성합니다. 토픽은 알림 채널이라고 생각하면 됩니다.

"ServerAlerts"라는 이름의 채널을 만드는 것입니다. 다음으로 subscribe 메서드로 이메일 구독을 추가합니다.

이 채널에서 발생하는 모든 알림을 지정된 이메일로 받겠다는 뜻입니다. 실행하면 이메일로 확인 메일이 오고, 구독을 승인해야 합니다.

put_metric_alarm은 실제 알람을 생성합니다. ComparisonOperator는 비교 방식입니다.

GreaterThanThreshold는 "임계값보다 클 때"를 의미합니다. 반대로 LessThanThreshold도 있습니다.

EvaluationPeriods의 중요성 EvaluationPeriods=2는 매우 중요합니다. 이것은 "2번 연속으로 조건을 만족해야 알람을 발생시킨다"는 뜻입니다.

왜 1번이 아니라 2번일까요? 순간적인 스파이크를 무시하기 위해서입니다.

CPU가 잠깐 85%로 올라갔다가 바로 40%로 떨어질 수 있습니다. 이런 경우마다 알람을 받으면 거짓 양성으로 피로도가 높아집니다.

2번 연속이면 "진짜 문제"일 가능성이 높습니다. 10분 동안 계속 80%를 넘으면 명백한 과부하 상태입니다.

이때만 알람을 받는 것이 효율적입니다. 실무 활용 사례 전자상거래 회사에서는 다단계 알람을 설정합니다.

CPU 70% 경고, 80% 주의, 90% 위험 이렇게 3단계로 나눕니다. 70%에서는 슬랙 알림, 80%에서는 이메일, 90%에서는 SMS와 전화까지 보냅니다.

게임 회사에서는 동시 접속자 수를 기준으로 알람을 설정합니다. 평소 1만 명인데 갑자기 10만 명이 접속하면 서버가 버티지 못합니다.

2만 명을 넘으면 알람이 울리고, 미리 서버를 증설합니다. 금융 서비스에서는 네트워크 오류율을 모니터링합니다.

정상적으로는 오류가 0.01% 이하인데, 1%를 넘으면 DDoS 공격이나 네트워크 장애일 가능성이 있습니다. 즉시 보안팀에 알립니다.

알람 피로도 관리 초보자가 흔히 하는 실수는 너무 많은 알람을 설정하는 것입니다. CPU 50%, 60%, 70%, 80%...

모든 단계마다 알람을 설정하면 하루에 수십 통의 이메일을 받게 됩니다. 알람이 너무 자주 오면 무시하게 됩니다.

"늑대가 나타났다"고 매번 거짓말하던 양치기 소년처럼, 진짜 위험할 때도 알람을 확인하지 않게 됩니다. 이를 알람 피로도라고 합니다.

핵심 지표에만 알람을 설정하세요. CPU 80%, 메모리 90%, 디스크 사용률 85% 정도면 충분합니다.

정말 중요한 알람만 울리도록 하는 것이 효과적입니다. 이제 안심하고 잘 수 있습니다 김개발 씨는 알람을 설정한 후 마음이 편해졌습니다.

집에 가서 쉬어도, 주말에 여행을 가도 문제가 생기면 즉시 알림을 받을 수 있습니다. 일주일 후, 새벽 3시에 휴대폰이 울렸습니다.

"CPU 사용률 80% 초과" 알람이었습니다. 김개발 씨는 노트북을 켜서 원인을 확인하고, 임시로 서버를 재시작했습니다.

고객들은 아무도 모르게 문제가 해결되었습니다. "알람이 없었다면 큰일 날 뻔했네요." 김개발 씨는 안도했습니다.

실전 팁

💡 - EvaluationPeriods를 2 이상으로 설정하여 거짓 양성을 줄이세요

핵심 지표에만 알람을 설정하여 알람 피로도를 방지하세요
SNS 구독 후 반드시 이메일 확인 링크를 클릭하여 구독을 승인하세요

6. 로그 그룹 기초

"CPU는 정상인데 왜 에러가 나는 거죠?" 김개발 씨는 당황했습니다. CloudWatch 메트릭에는 문제가 없었지만 사용자는 계속 오류를 겪고 있었습니다.

박시니어 씨가 말했습니다. "로그를 확인해보세요."

로그 그룹은 애플리케이션에서 발생하는 모든 이벤트와 오류 메시지를 기록하는 저장소입니다. 마치 비행기의 블랙박스처럼 모든 활동을 기록하여 나중에 분석할 수 있습니다.

메트릭은 "무엇이 일어났는지" 알려주고, 로그는 "왜 일어났는지" 알려줍니다.

다음 코드를 살펴봅시다.

import boto3
import time

logs = boto3.client('logs')

# 로그 그룹 생성
log_group_name = '/aws/application/myapp'
try:
    logs.create_log_group(logGroupName=log_group_name)
    print(f"로그 그룹 생성: {log_group_name}")
except logs.exceptions.ResourceAlreadyExistsException:
    print("로그 그룹이 이미 존재합니다")

# 로그 스트림 생성
log_stream_name = 'app-server-001'
logs.create_log_stream(
    logGroupName=log_group_name,
    logStreamName=log_stream_name
)

# 로그 메시지 전송
logs.put_log_events(
    logGroupName=log_group_name,
    logStreamName=log_stream_name,
    logEvents=[
        {
            'timestamp': int(time.time() * 1000),  # 밀리초 단위
            'message': 'User login successful: user_id=12345'
        },
        {
            'timestamp': int(time.time() * 1000),
            'message': 'ERROR: Database connection timeout'
        }
    ]
)

print("로그 전송 완료")

# 로그 조회
response = logs.filter_log_events(
    logGroupName=log_group_name,
    logStreamNames=[log_stream_name],
    filterPattern='ERROR'  # ERROR 키워드만 필터링
)

for event in response['events']:
    print(f"[{event['timestamp']}] {event['message']}")

김개발 씨는 CloudWatch 대시보드를 확인했습니다. CPU는 40%, 메모리는 60%, 네트워크도 정상이었습니다.

하지만 고객 지원팀에서는 계속 오류 신고가 들어온다고 했습니다. "결제가 안 돼요", "로그인이 안 돼요" 숫자로 된 메트릭만으로는 원인을 알 수 없었습니다.

박시니어 씨가 다가와 물었습니다. "로그는 확인해봤어요?" "로그요?" 김개발 씨는 로그를 어디서 보는지도 몰랐습니다.

로그는 서버가 남기는 일기장입니다 사람이 매일 일기를 쓰듯이, 서버도 모든 활동을 기록합니다. "오전 10시 23분, 사용자 A가 로그인했습니다", "오전 10시 25분, 데이터베이스 연결 오류가 발생했습니다" 이런 식으로 모든 이벤트를 남깁니다.

메트릭은 요약 정보입니다. CPU 사용률이 60%라는 것은 알지만, 어떤 프로세스가 CPU를 많이 쓰는지는 모릅니다.

로그는 상세 정보입니다. "payment-service 프로세스가 무한 루프에 빠졌습니다"처럼 구체적인 원인을 알려줍니다.

로그가 없던 시절의 어려움 과거에는 각 서버의 로컬 파일에 로그를 저장했습니다. /var/log/app.log 같은 파일에 텍스트로 기록했습니다.

문제가 생기면 서버에 SSH로 접속해서 tail -f /var/log/app.log 명령어로 확인했습니다. 하지만 여러 대의 서버를 운영하면 문제가 복잡해집니다.

웹 서버 3대, API 서버 5대가 있다면 8곳의 로그 파일을 일일이 확인해야 했습니다. 어느 서버에서 오류가 났는지 알 수 없으니 전부 뒤져야 했습니다.

더 큰 문제는 로그 검색이었습니다. 하루에 수백만 줄의 로그가 쌓이는데, 특정 오류 메시지를 찾으려면 grep 명령어로 텍스트를 검색해야 했습니다.

시간도 오래 걸리고 서버 부하도 높았습니다. CloudWatch Logs가 모든 문제를 해결합니다 CloudWatch Logs는 모든 서버의 로그를 중앙 집중화합니다.

여러 서버에서 발생한 로그를 한곳에 모아서 통합 검색할 수 있습니다. 어느 서버에서 오류가 났는지 찾기 위해 일일이 접속할 필요가 없습니다.

로그 그룹은 로그를 분류하는 폴더와 같습니다. 애플리케이션별, 환경별로 로그 그룹을 나눕니다.

/aws/application/myapp은 "myapp 애플리케이션의 로그"를 의미합니다. 로그 스트림은 로그 그룹 안의 개별 파일입니다.

서버별로 로그 스트림을 만듭니다. app-server-001, app-server-002처럼 각 서버의 로그를 구분하여 저장합니다.

코드로 로그 기록하기 위의 코드를 살펴보겠습니다. create_log_group으로 로그 그룹을 만듭니다.

이미 존재하면 예외가 발생하므로 try-except로 처리했습니다. 여러 번 실행해도 안전합니다.

create_log_stream은 로그 스트림을 생성합니다. 서버마다 고유한 이름을 사용하세요.

인스턴스 ID나 호스트네임을 사용하면 좋습니다. put_log_events는 실제 로그 메시지를 전송합니다.

timestamp는 밀리초 단위이므로 time.time() * 1000으로 변환합니다. message에는 원하는 텍스트를 자유롭게 기록할 수 있습니다.

로그 검색의 강력함 filter_log_events는 로그를 검색합니다. filterPattern에 키워드를 지정하면 해당 키워드가 포함된 로그만 가져옵니다.

"ERROR"로 필터링하면 모든 오류 로그만 볼 수 있습니다. 패턴은 매우 강력합니다.

[ERROR], [WARN], timeout, exception 등 다양한 키워드로 검색할 수 있습니다. 정규표현식도 지원하여 복잡한 패턴도 가능합니다.

시간 범위도 지정할 수 있습니다. "어제 오후 2시부터 3시 사이의 ERROR 로그"처럼 정확한 시점의 로그를 찾을 수 있습니다.

문제가 언제 시작되었는지 정확히 파악할 수 있습니다. 실무 활용 사례 스타트업에서는 모든 API 요청을 로그로 남깁니다.

어떤 사용자가 언제 어떤 API를 호출했는지 모두 기록합니다. 사용자가 "결제가 안 됐어요"라고 신고하면 로그를 검색하여 정확한 오류 원인을 찾습니다.

게임 회사에서는 게임 이벤트를 로그로 기록합니다. 아이템 획득, 레벨업, 결제 등 모든 행동을 남깁니다.

나중에 데이터 분석에 활용하여 사용자 패턴을 파악하고 게임을 개선합니다. 금융 회사에서는 감사 로그로 활용합니다.

누가 언제 어떤 데이터에 접근했는지 모두 기록합니다. 규제 기관에서 요청하면 로그를 제출하여 투명성을 증명합니다.

로그 비용 관리 주의할 점은 로그 비용입니다. CloudWatch Logs는 저장된 데이터 양과 보관 기간에 따라 비용이 부과됩니다.

너무 많은 로그를 너무 오래 보관하면 비용이 증가합니다. 로그 보관 기간을 설정하세요.

개발 환경 로그는 7일, 운영 환경 로그는 30일 정도면 충분한 경우가 많습니다. 1년 이상 보관할 필요는 거의 없습니다.

오래된 로그는 자동으로 삭제되도록 설정하세요. 로그 레벨도 중요합니다.

DEBUG 레벨까지 모두 기록하면 로그 양이 폭발적으로 증가합니다. 운영 환경에서는 INFO, WARN, ERROR만 기록하는 것이 좋습니다.

문제를 해결했습니다 김개발 씨는 로그를 검색했습니다. filter_log_events로 "ERROR"를 검색하니 "Database connection timeout" 메시지가 보였습니다.

데이터베이스 연결이 끊어진 것이 원인이었습니다. 데이터베이스 서버를 확인하니 최대 연결 수를 초과했습니다.

설정을 조정하고 연결 풀을 최적화하자 문제가 해결되었습니다. "메트릭만 봤다면 절대 못 찾았을 거예요." 김개발 씨가 감탄했습니다.

로그는 메트릭과 함께 사용할 때 진가를 발휘합니다. 숫자와 메시지를 함께 보면 서버의 모든 것을 이해할 수 있습니다.

실전 팁

💡 - 로그 보관 기간을 설정하여 비용을 절감하세요 (개발 7일, 운영 30일)

운영 환경에서는 DEBUG 로그를 끄고 INFO 이상만 기록하세요
중요한 이벤트는 ERROR 레벨로 기록하여 쉽게 필터링할 수 있게 하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#CloudWatch#EC2#Monitoring#Logs

AWS CloudWatch 모니터링 완벽 가이드

# AWS CloudWatch 모니터링 완벽 가이드 초급 개발자를 위한 CloudWatch 모니터링 입문서입니다. EC2 인스턴스 상태 확인부터 알람 설정, 로그 관리까지 실무에 필요한 핵심 기능을 쉽게 배울 수 있습니다. --- ## 목차 1. [CloudWatch란?](#cloudwatch란?) 2. [기본_메트릭_확인](#기본-메트릭-확인) 3. [EC2_모니터링](#ec2-모니터링) 4. [대시보드_생성](#대시보드-생성) 5. [알람_설정하기](#알람-설정하기) 6. [로그_그룹_기초](#로그-그룹-기초) --- ## 1. CloudWatch란? 첫 출근을 한 김개발 씨는 선배로부터 "서버 상태 좀 확인해봐"라는 요청을 받았습니다. 하지만 서버가 정상인지 어떻게 확인해야 할지 막막했습니다. 바로 그때 선배가 CloudWatch를 소개해주었습니다. **CloudWatch**는 AWS 리소스와 애플리케이션을 실시간으로 모니터링하는 서비스입니다. 마치 자동차 계기판처럼 서버의 상태를 한눈에 보여줍니다. CPU 사용률, 메모리, 네트워크 트래픽 등 다양한 지표를 수집하고 시각화할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta # CloudWatch 클라이언트 생성 cloudwatch = boto3.client('cloudwatch') # 최근 1시간 CPU 사용률 조회 response = cloudwatch.get_metric_statistics( Namespace='AWS/EC2', # EC2 메트릭 네임스페이스 MetricName='CPUUtilization', # CPU 사용률 지표 Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}], StartTime=datetime.utcnow() - timedelta(hours=1), EndTime=datetime.utcnow(), Period=300, # 5분 간격 Statistics=['Average'] # 평균값 조회 ) print(f"평균 CPU 사용률: {response['Datapoints']}") ``` 김개발 씨는 입사 첫날부터 중요한 임무를 맡았습니다. 회사에서 운영 중인 쇼핑몰 서버의 상태를 확인하는 일이었습니다. 하지만 AWS 콘솔에 로그인해도 어디서부터 봐야 할지 감이 잡히지 않았습니다. 선배 개발자 박시니어 씨가 다가와 물었습니다. "서버 상태 확인해봤어요?" 김개발 씨는 난처한 표정으로 대답했습니다. "어디서 확인하는지 모르겠어요." 박시니어 씨는 웃으며 CloudWatch 대시보드를 열어주었습니다. 화면에는 다양한 그래프와 수치가 실시간으로 변하고 있었습니다. **CloudWatch란 무엇일까요?** 쉽게 비유하자면, CloudWatch는 자동차의 계기판과 같습니다. 운전할 때 속도계, 연료 게이지, 엔진 온도 등을 확인하듯이, 서버 관리자는 CloudWatch를 통해 CPU 사용률, 메모리, 네트워크 상태를 확인합니다. 계기판 없이 운전하는 것이 위험한 것처럼, CloudWatch 없이 서버를 운영하는 것도 매우 위험합니다. **모니터링이 없던 시절에는 어땠을까요?** 과거에는 서버 관리자가 직접 서버에 접속해서 명령어를 입력해야 했습니다. 한 대의 서버라면 괜찮지만, 수십 대, 수백 대의 서버를 관리한다면 어떨까요? 하나씩 접속해서 확인하는 것은 비효율적일 뿐만 아니라 실시간 모니터링도 불가능했습니다. 더 큰 문제는 장애 발생을 뒤늦게 알게 된다는 점이었습니다. 사용자가 "사이트가 안 열려요"라고 연락하고 나서야 문제를 인지하는 경우가 많았습니다. 그때는 이미 비즈니스에 큰 손실이 발생한 후였습니다. **CloudWatch가 이 모든 문제를 해결합니다** CloudWatch를 사용하면 모든 AWS 리소스의 상태를 한 곳에서 확인할 수 있습니다. EC2 인스턴스뿐만 아니라 RDS 데이터베이스, Lambda 함수, ELB 로드밸런서 등 AWS의 거의 모든 서비스를 모니터링할 수 있습니다. 가장 큰 장점은 **실시간 모니터링**이 가능하다는 점입니다. 1분 단위로 데이터가 수집되며, 상세 모니터링을 활성화하면 1초 단위까지 가능합니다. 문제가 발생하면 즉시 알 수 있습니다. 또한 **자동화된 알람 설정**도 큰 이점입니다. CPU 사용률이 80%를 넘으면 자동으로 이메일이나 SMS를 보낼 수 있습니다. 새벽에 잠들어 있어도 서버가 스스로 관리자에게 알려줍니다. **코드를 통해 CloudWatch 이해하기** 위의 코드를 살펴보겠습니다. 먼저 `boto3` 라이브러리로 CloudWatch 클라이언트를 생성합니다. 이것은 Python에서 AWS 서비스를 제어하는 공식 SDK입니다. `get_metric_statistics` 메서드는 특정 지표의 통계 데이터를 가져옵니다. `Namespace`는 어떤 AWS 서비스인지 지정하는 것이고, `MetricName`은 구체적으로 어떤 지표인지를 나타냅니다. CPU 사용률, 네트워크 입출력, 디스크 읽기/쓰기 등 다양한 지표가 있습니다. `Dimensions`는 필터 조건입니다. 특정 EC2 인스턴스의 데이터만 가져오고 싶을 때 인스턴스 ID를 지정합니다. `Period`는 데이터 집계 간격으로, 300초는 5분을 의미합니다. **실무에서는 어떻게 활용할까요?** 실제 쇼핑몰 서비스를 운영한다고 가정해봅시다. 블랙프라이데이 세일 기간에는 평소보다 트래픽이 10배 이상 증가합니다. CloudWatch를 통해 실시간으로 서버 부하를 확인하고, 필요하면 Auto Scaling으로 서버를 자동 증설할 수 있습니다. 많은 기업에서 CloudWatch 데이터를 기반으로 용량 계획을 수립합니다. 최근 3개월간의 트래픽 패턴을 분석하여 다음 분기에 필요한 서버 스펙을 미리 예측하는 것입니다. **주의할 점도 있습니다** 초보 개발자들이 흔히 하는 실수는 너무 많은 지표를 한꺼번에 보려고 한다는 점입니다. CloudWatch는 수백 가지 지표를 제공하지만, 처음부터 모두 볼 필요는 없습니다. CPU, 메모리, 네트워크 정도만 먼저 익숙해지면 충분합니다. 또한 지표를 조회할 때 시간 범위를 너무 길게 설정하면 응답이 느려질 수 있습니다. 필요한 시간 범위만 정확히 지정하는 것이 좋습니다. **이제 시작입니다** 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 CloudWatch 콘솔을 직접 열어보았습니다. 그래프에서 CPU 사용률이 안정적으로 유지되고 있는 것을 확인하고 안도했습니다. CloudWatch를 이해하면 서버 관리가 훨씬 쉬워집니다. 문제가 생기기 전에 미리 대응할 수 있고, 데이터 기반으로 의사결정을 내릴 수 있습니다. 여러분도 오늘부터 CloudWatch를 활용해보세요. **실전 팁** 💡 - 처음에는 CPU, 메모리, 네트워크 3가지 지표만 집중해서 모니터링하세요 - 비용 절감을 위해 기본 모니터링(5분 간격)으로 시작하고, 필요할 때만 상세 모니터링(1분 간격)을 사용하세요 - CloudWatch 대시보드를 북마크에 추가하여 매일 아침 확인하는 습관을 들이세요 --- ## 2. 기본_메트릭_확인 김개발 씨는 CloudWatch 콘솔을 열었지만 수많은 그래프와 숫자들에 압도당했습니다. "이 중에서 뭘 봐야 하죠?" 선배는 가장 중요한 기본 메트릭부터 알려주기로 했습니다. **메트릭**은 CloudWatch가 수집하는 측정값입니다. CPU 사용률, 네트워크 트래픽, 디스크 I/O 등 서버의 건강 상태를 나타내는 지표들입니다. 마치 건강검진에서 혈압, 혈당, 콜레스테롤을 확인하듯이 서버도 핵심 메트릭을 정기적으로 확인해야 합니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudwatch = boto3.client('cloudwatch') # 사용 가능한 모든 메트릭 목록 조회 metrics = cloudwatch.list_metrics( Namespace='AWS/EC2', # EC2 서비스의 메트릭 MetricName='CPUUtilization' # CPU 사용률 메트릭 ) # 메트릭 정보 출력 for metric in metrics['Metrics']: print(f"메트릭 이름: {metric['MetricName']}") print(f"네임스페이스: {metric['Namespace']}") print(f"차원(Dimensions): {metric['Dimensions']}") print("---") # 특정 인스턴스의 메트릭만 필터링 instance_metrics = cloudwatch.list_metrics( Namespace='AWS/EC2', Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}] ) ``` 김개발 씨는 CloudWatch 콘솔에서 수십 개의 그래프를 발견했습니다. CPUUtilization, NetworkIn, NetworkOut, DiskReadBytes, DiskWriteBytes... 용어들이 낯설었습니다. 박시니어 씨가 설명했습니다. "처음에는 다 복잡해 보이지만, 핵심만 알면 간단해요. 건강검진을 생각해보세요." **메트릭은 서버의 건강검진 항목입니다** 사람이 건강검진을 받을 때 혈압, 혈당, 콜레스테롤 등을 측정합니다. 각 수치마다 정상 범위가 있고, 이를 벗어나면 문제가 있다는 신호입니다. 서버도 마찬가지입니다. **CPUUtilization**은 혈압과 같습니다. 너무 높으면 서버가 과부하 상태이고, 지속적으로 낮으면 서버가 제대로 활용되지 않는다는 의미입니다. 정상 범위는 보통 30-70% 정도입니다. **NetworkIn**과 **NetworkOut**은 혈액 순환과 같습니다. 들어오는 트래픽과 나가는 트래픽을 측정합니다. 갑자기 트래픽이 급증하면 DDoS 공격일 수도 있고, 트래픽이 0에 가까우면 서비스가 중단된 것일 수도 있습니다. **메트릭이 없던 시절의 어려움** 과거에는 서버에 직접 SSH로 접속해서 `top` 명령어를 입력해야 CPU 사용률을 확인할 수 있었습니다. 그것도 그 순간의 스냅샷만 볼 수 있었습니다. 한 시간 전에 무슨 일이 있었는지 알 수 없었습니다. 네트워크 트래픽을 확인하려면 `ifconfig`나 `netstat` 명령어를 사용해야 했습니다. 하지만 이것도 실시간 값만 보여줄 뿐, 시간에 따른 추세를 파악하기는 어려웠습니다. 더 큰 문제는 여러 서버를 관리할 때였습니다. 10대의 서버가 있다면 10번 접속해서 일일이 확인해야 했습니다. 비효율적이고 실수하기 쉬운 방법이었습니다. **CloudWatch 메트릭이 모든 것을 자동화합니다** CloudWatch는 모든 메트릭을 자동으로 수집하고 저장합니다. 기본적으로 **5분 간격**으로 데이터를 수집하며, 최대 **15개월**까지 보관합니다. 과거 데이터를 언제든지 조회할 수 있다는 뜻입니다. 네임스페이스는 메트릭을 분류하는 카테고리입니다. `AWS/EC2`는 EC2 관련 메트릭, `AWS/RDS`는 데이터베이스 관련 메트릭을 의미합니다. 이렇게 분류되어 있어서 원하는 메트릭을 쉽게 찾을 수 있습니다. **코드로 메트릭 목록 가져오기** 위의 코드에서 `list_metrics` 메서드는 사용 가능한 모든 메트릭을 나열합니다. `Namespace`를 지정하면 특정 서비스의 메트릭만 필터링할 수 있습니다. `Dimensions`는 메트릭을 더 세밀하게 필터링하는 조건입니다. 예를 들어 `InstanceId` 차원을 사용하면 특정 EC2 인스턴스의 메트릭만 조회할 수 있습니다. 수백 대의 서버 중 문제가 있는 한 대만 집중해서 볼 수 있는 것입니다. 반환된 결과에는 `MetricName`, `Namespace`, `Dimensions` 정보가 포함됩니다. 이 정보를 활용하여 나중에 `get_metric_statistics`로 실제 데이터를 조회할 수 있습니다. **실무 활용 사례** 실제 금융 서비스를 운영하는 회사에서는 **DiskReadOps**와 **DiskWriteOps** 메트릭을 중요하게 모니터링합니다. 데이터베이스 성능이 디스크 I/O에 크게 영향을 받기 때문입니다. 디스크 읽기/쓰기가 비정상적으로 증가하면 쿼리 최적화가 필요하다는 신호입니다. 게임 서비스에서는 **NetworkIn** 메트릭을 주시합니다. 게임 업데이트를 배포할 때 수백만 명의 사용자가 동시에 다운로드하면 네트워크 대역폭이 포화될 수 있습니다. 이를 미리 예측하고 대비해야 합니다. **초보자가 주의할 점** 처음에는 모든 메트릭을 다 보려고 하지 마세요. CPU, 메모리, 네트워크 이 세 가지만 제대로 이해해도 충분합니다. 경험이 쌓이면 자연스럽게 다른 메트릭도 필요하게 됩니다. 또한 메트릭 이름을 정확히 입력해야 합니다. `CPUUtilization`인데 `CpuUtilization`으로 쓰면 데이터를 못 가져옵니다. 대소문자를 정확히 구분해야 합니다. **메트릭을 친구로 만드세요** 김개발 씨는 하나씩 메트릭을 클릭해보며 그래프를 확인했습니다. CPU는 평균 40%, 네트워크는 안정적으로 유지되고 있었습니다. "이제 좀 감이 잡히네요!" 메트릭을 이해하면 서버의 언어를 알아듣게 됩니다. 서버가 "지금 너무 힘들어요"라고 말하는 것을 CPU 메트릭으로 알 수 있고, "네트워크가 끊어졌어요"라는 것을 NetworkOut 메트릭으로 알 수 있습니다. 여러분도 메트릭과 친해지세요. **실전 팁** 💡 - 처음에는 CPU, 네트워크, 디스크 3가지 메트릭만 집중하세요 - 메트릭 이름은 대소문자를 정확히 구분해야 합니다 - 각 메트릭의 정상 범위를 파악하여 기준선을 만들어두세요 --- ## 3. EC2_모니터링 "서버가 느린 것 같아요." 김개발 씨에게 동료가 말했습니다. 하지만 막연히 "느리다"는 것만으로는 원인을 찾을 수 없었습니다. EC2 모니터링을 통해 정확한 원인을 찾아야 했습니다. **EC2 모니터링**은 가상 서버의 성능과 상태를 추적하는 과정입니다. CPU, 메모리, 네트워크, 디스크 등 다양한 지표를 실시간으로 확인하여 문제를 조기에 발견할 수 있습니다. 마치 자동차 정비소에서 엔진 상태를 점검하듯이 서버의 모든 구성 요소를 체크합니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta ec2 = boto3.client('ec2') cloudwatch = boto3.client('cloudwatch') # 모든 실행 중인 EC2 인스턴스 조회 instances = ec2.describe_instances( Filters=[{'Name': 'instance-state-name', 'Values': ['running']}] ) # 각 인스턴스의 CPU 사용률 확인 for reservation in instances['Reservations']: for instance in reservation['Instances']: instance_id = instance['InstanceId'] # 최근 1시간 CPU 평균 조회 cpu_stats = cloudwatch.get_metric_statistics( Namespace='AWS/EC2', MetricName='CPUUtilization', Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}], StartTime=datetime.utcnow() - timedelta(hours=1), EndTime=datetime.utcnow(), Period=300, Statistics=['Average', 'Maximum'] # 평균과 최대값 ) if cpu_stats['Datapoints']: avg_cpu = cpu_stats['Datapoints'][0]['Average'] max_cpu = cpu_stats['Datapoints'][0]['Maximum'] print(f"인스턴스 {instance_id}: 평균 CPU {avg_cpu:.2f}%, 최대 CPU {max_cpu:.2f}%") ``` 오전 10시, 김개발 씨의 슬랙에 메시지가 도착했습니다. "쇼핑몰 로딩이 너무 느려요. 확인 좀 해주세요." 사용자들의 불만이 접수되기 시작했습니다. 김개발 씨는 당황했습니다. 어제까지만 해도 정상이었는데 무엇이 문제일까요? 코드를 변경한 것도 없고, 배포도 하지 않았습니다. 박시니어 씨에게 급하게 연락했습니다. "일단 EC2 모니터링 화면부터 보세요." 박시니어 씨가 차분하게 말했습니다. **EC2 모니터링은 서버의 건강검진입니다** 사람이 아플 때 병원에 가서 검사를 받듯이, 서버도 이상 증상이 있으면 모니터링 데이터를 확인해야 합니다. 체온, 혈압, 맥박을 재는 것처럼 서버의 CPU, 메모리, 네트워크를 체크합니다. EC2 인스턴스는 AWS의 가상 서버입니다. 여러분이 임대한 컴퓨터라고 생각하면 됩니다. 이 컴퓨터가 제대로 작동하는지 확인하려면 **상태 지표**를 봐야 합니다. **기본 모니터링 vs 상세 모니터링** CloudWatch는 두 가지 모니터링 수준을 제공합니다. **기본 모니터링**은 5분 간격으로 데이터를 수집하며 무료입니다. **상세 모니터링**은 1분 간격으로 수집하며 추가 비용이 발생합니다. 대부분의 경우 기본 모니터링으로 충분합니다. 하지만 트래픽 변화가 급격한 서비스라면 상세 모니터링이 필요할 수 있습니다. 5분이면 이미 수천 명의 사용자가 불편을 겪었을 수도 있기 때문입니다. **모니터링 없이 운영했던 과거** 과거에는 사용자가 "느려요"라고 신고하면, 관리자가 서버에 접속해서 `top` 명령어로 CPU를 확인했습니다. 하지만 그 순간의 상태만 볼 수 있었습니다. 10분 전에 CPU가 100%였는지 알 수 없었습니다. 더 큰 문제는 여러 서버를 운영할 때였습니다. 웹 서버 3대, 데이터베이스 서버 2대를 운영한다면, 5대 모두에 접속해서 상태를 확인해야 했습니다. 그 사이에 다른 서버에서 문제가 생길 수도 있었습니다. **CloudWatch로 모든 인스턴스를 한눈에** CloudWatch를 사용하면 모든 EC2 인스턴스를 한 화면에서 볼 수 있습니다. 위의 코드처럼 실행 중인 모든 인스턴스를 자동으로 찾아서 각각의 CPU 사용률을 확인할 수 있습니다. `describe_instances` 메서드는 EC2 인스턴스 목록을 가져옵니다. `Filters`를 사용하여 실행 중인 인스턴스만 필터링했습니다. 중지된 인스턴스는 모니터링할 필요가 없기 때문입니다. 각 인스턴스마다 `get_metric_statistics`를 호출하여 CPU 사용률을 조회합니다. `Statistics`에 `Average`와 `Maximum`을 함께 지정했습니다. 평균값만으로는 순간적인 스파이크를 놓칠 수 있기 때문입니다. **코드 실행 결과 해석하기** 코드를 실행하면 각 인스턴스의 평균 CPU와 최대 CPU가 출력됩니다. 예를 들어 "평균 CPU 40%, 최대 CPU 95%"라면 어떤 의미일까요? 평균은 낮지만 최대값이 높다는 것은 **순간적인 스파이크**가 있었다는 뜻입니다. 특정 시점에 요청이 몰렸거나, 무거운 작업이 실행되었을 가능성이 있습니다. 이런 패턴을 파악하면 원인을 찾을 수 있습니다. 반대로 "평균 CPU 90%, 최대 CPU 95%"라면 **지속적인 고부하** 상태입니다. 서버 스펙이 부족하거나, 비효율적인 코드가 실행되고 있을 가능성이 높습니다. 서버 증설이나 코드 최적화가 필요합니다. **실무 적용 사례** 실제 전자상거래 회사에서는 매일 오전 이 코드를 자동으로 실행합니다. 모든 서버의 전날 CPU 사용률을 리포트로 만들어 운영팀에 전달합니다. 이상 징후가 있으면 즉시 조치를 취합니다. 또 다른 회사에서는 이 코드를 Lambda 함수로 만들어 1시간마다 실행합니다. CPU가 80%를 넘는 인스턴스가 있으면 자동으로 슬랙에 알림을 보냅니다. 관리자가 24시간 모니터링 화면을 볼 필요가 없습니다. **주의할 점** 초보자들이 흔히 하는 실수는 CPU만 보고 판단한다는 것입니다. CPU는 정상인데 네트워크가 병목일 수도 있고, 메모리 부족일 수도 있습니다. 여러 지표를 종합적으로 봐야 합니다. 또한 **시간대별 패턴**을 이해해야 합니다. 점심시간에 CPU가 높은 것은 정상입니다. 사용자가 많이 접속하는 시간이기 때문입니다. 새벽 3시에 CPU가 높다면 이상한 것입니다. **문제를 찾았습니다** 김개발 씨는 코드를 실행하고 결과를 확인했습니다. 웹 서버 1번의 CPU가 평균 92%였습니다. 다른 서버는 40% 정도인데 1번만 유독 높았습니다. 로드밸런서 설정이 잘못되어 트래픽이 한쪽으로만 몰린 것이었습니다. 문제를 수정하자 CPU가 고르게 분산되었고, 서비스 속도도 정상으로 돌아왔습니다. "모니터링이 없었다면 원인을 찾지 못했을 거예요." 김개발 씨가 감탄했습니다. **실전 팁** 💡 - CPU 외에도 네트워크와 디스크를 함께 확인하세요 - 평균값뿐만 아니라 최댓값도 함께 체크하여 스파이크를 놓치지 마세요 - 시간대별 정상 패턴을 파악하여 비정상 상황을 빠르게 인식하세요 --- ## 4. 대시보드_생성 매번 코드를 실행하거나 콘솔을 여러 번 클릭하는 것이 번거로웠습니다. 김개발 씨는 "한 화면에서 모든 걸 볼 수는 없나요?"라고 물었습니다. 바로 CloudWatch 대시보드가 그 해답이었습니다. **대시보드**는 여러 메트릭을 한 화면에 모아서 보여주는 시각화 도구입니다. 마치 자동차 운전석의 계기판처럼 속도계, 연료 게이지, 엔진 온도를 한눈에 볼 수 있습니다. CPU, 메모리, 네트워크 그래프를 한 곳에 배치하여 서버 상태를 실시간으로 파악할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json cloudwatch = boto3.client('cloudwatch') # 대시보드 생성 dashboard_name = 'MyEC2Dashboard' dashboard_body = { "widgets": [ { "type": "metric", "properties": { "metrics": [ ["AWS/EC2", "CPUUtilization", {"stat": "Average"}] ], "period": 300, "stat": "Average", "region": "ap-northeast-2", "title": "EC2 CPU 사용률", "yAxis": {"left": {"min": 0, "max": 100}} } }, { "type": "metric", "properties": { "metrics": [ ["AWS/EC2", "NetworkIn", {"stat": "Sum"}], [".", "NetworkOut", {"stat": "Sum"}] ], "period": 300, "stat": "Sum", "region": "ap-northeast-2", "title": "네트워크 트래픽" } } ] } # 대시보드 생성 또는 업데이트 response = cloudwatch.put_dashboard( DashboardName=dashboard_name, DashboardBody=json.dumps(dashboard_body) ) print(f"대시보드 생성 완료: {dashboard_name}") ``` 김개발 씨는 매일 아침 출근하면 CloudWatch 콘솔에 들어가서 CPU 그래프를 클릭하고, 네트워크 그래프를 클릭하고, 디스크 그래프를 클릭했습니다. 매번 같은 작업을 반복하는 것이 비효율적이라고 느꼈습니다. "이거 자동화할 수 있나요?" 김개발 씨가 박시니어 씨에게 물었습니다. "물론이죠. 대시보드를 만들면 됩니다." **대시보드는 나만의 관제 센터입니다** 항공 관제탑을 상상해보세요. 관제사는 수십 개의 모니터를 한눈에 보며 모든 비행기를 추적합니다. 각 비행기마다 일일이 정보를 검색하지 않습니다. 모든 정보가 한 공간에 실시간으로 표시됩니다. CloudWatch 대시보드도 마찬가지입니다. 중요한 메트릭을 한 화면에 배치하여 서버의 모든 상태를 실시간으로 모니터링할 수 있습니다. 아침에 출근하면 대시보드 하나만 열어보면 됩니다. **수동으로 그래프를 찾던 과거** 과거에는 각 메트릭을 개별적으로 조회해야 했습니다. Metrics 탭에 들어가서 EC2를 선택하고, CPUUtilization을 찾고, 인스턴스를 선택하는 과정을 매번 반복했습니다. 10개의 메트릭을 확인하려면 10번의 클릭과 검색이 필요했습니다. 하루에 3번씩 확인한다면? 30번의 반복 작업입니다. 일주일이면 210번입니다. 시간 낭비가 심각했습니다. 게다가 **여러 팀원이 같은 메트릭을 봐야 하는 경우**에는 더 복잡했습니다. 각자가 자기 방식대로 그래프를 찾아보다 보니 놓치는 것도 생기고, 소통도 어려웠습니다. **대시보드로 모든 것이 간단해집니다** 대시보드를 만들면 한 번의 클릭으로 모든 정보를 볼 수 있습니다. URL을 북마크에 저장하면 매일 아침 그 페이지만 열면 됩니다. 팀원들과 대시보드 URL을 공유하면 모두가 같은 화면을 보며 소통할 수 있습니다. 위의 코드에서 `widgets`는 대시보드에 표시할 그래프 목록입니다. 각 위젯은 하나의 차트를 의미합니다. CPU 그래프, 네트워크 그래프 등을 원하는 만큼 추가할 수 있습니다. `metrics` 배열에는 표시할 메트릭을 지정합니다. `["AWS/EC2", "CPUUtilization"]`은 EC2의 CPU 사용률을 의미합니다. 여러 메트릭을 한 그래프에 겹쳐서 표시할 수도 있습니다. **코드의 핵심 부분 이해하기** `period`는 데이터 집계 간격입니다. 300초는 5분을 의미합니다. 1시간 단위로 보고 싶다면 3600을 지정하면 됩니다. 시간 범위가 길수록 그래프가 덜 세밀하지만 전체 추세를 파악하기 좋습니다. `yAxis` 설정은 Y축의 범위를 지정합니다. CPU는 0%에서 100% 사이 값이므로 `min: 0, max: 100`으로 고정하면 그래프가 항상 같은 스케일로 표시됩니다. 시각적으로 비교하기 쉬워집니다. `put_dashboard` 메서드는 대시보드를 생성하거나 업데이트합니다. 같은 이름의 대시보드가 이미 있으면 덮어쓰고, 없으면 새로 만듭니다. 코드를 여러 번 실행해도 안전합니다. **실무 활용 사례** 스타트업에서는 사무실 벽에 큰 모니터를 걸어두고 CloudWatch 대시보드를 24시간 띄워놓습니다. 모든 개발자가 언제든지 서버 상태를 확인할 수 있습니다. 문제가 생기면 즉시 알아챌 수 있습니다. 대기업에서는 서비스별로 대시보드를 분리합니다. 결제 시스템 대시보드, 추천 엔진 대시보드, 사용자 인증 대시보드 등 각 팀이 자기 영역의 대시보드를 관리합니다. 책임 소재가 명확해지고 집중도가 높아집니다. 금융 서비스에서는 **규제 준수**를 위해 대시보드를 아카이빙합니다. 특정 시점의 서버 상태를 스크린샷으로 저장하여 나중에 감사 자료로 사용합니다. **실전 팁** 대시보드에는 너무 많은 그래프를 넣지 마세요. 한 화면에 10개 이상의 차트가 있으면 오히려 집중력이 떨어집니다. **핵심 메트릭 5-7개**만 선별하는 것이 좋습니다. 그래프의 **배치 순서**도 중요합니다. 가장 중요한 메트릭을 화면 왼쪽 위에 배치하세요. 사람의 시선은 자연스럽게 왼쪽 위에서 시작하기 때문입니다. **색상**을 활용하면 더 직관적입니다. CPU는 빨간색, 메모리는 파란색, 네트워크는 초록색처럼 일관된 색상 규칙을 정하면 한눈에 구분할 수 있습니다. **이제 김개발 씨의 루틴이 바뀌었습니다** 김개발 씨는 자신만의 대시보드를 만들었습니다. 매일 아침 커피를 마시며 대시보드를 체크합니다. 5초 만에 모든 서버가 정상인지 확인할 수 있습니다. 팀 회의에서도 대시보드를 공유 화면에 띄워놓습니다. "어제 CPU 스파이크 있었죠?"라고 말하며 그래프를 가리킵니다. 모두가 같은 데이터를 보며 대화하니 의사소통이 훨씬 명확해졌습니다. **실전 팁** 💡 - 한 대시보드에 5-7개의 핵심 메트릭만 배치하세요 - 가장 중요한 그래프를 왼쪽 위에 배치하여 시선을 집중시키세요 - 팀원들과 대시보드 URL을 공유하여 같은 화면을 보며 협업하세요 --- ## 5. 알람_설정하기 새벽 2시에 서버가 다운되었습니다. 하지만 아무도 모르고 있었습니다. 아침에 출근한 김개발 씨는 고객 불만 메일을 보고서야 문제를 알았습니다. "미리 알 수 있는 방법은 없나요?" **알람**은 메트릭이 특정 임계값을 넘으면 자동으로 알려주는 기능입니다. 마치 화재 경보기처럼 평소에는 조용하다가 위험한 상황이 되면 즉시 경고합니다. CPU가 80%를 넘거나 네트워크 오류가 발생하면 이메일이나 SMS로 알림을 받을 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudwatch = boto3.client('cloudwatch') sns = boto3.client('sns') # SNS 토픽 생성 (알림을 받을 채널) topic_response = sns.create_topic(Name='ServerAlerts') topic_arn = topic_response['TopicArn'] # 이메일 구독 추가 sns.subscribe( TopicArn=topic_arn, Protocol='email', Endpoint='dev@example.com' # 알림 받을 이메일 ) # CPU 사용률 알람 생성 cloudwatch.put_metric_alarm( AlarmName='HighCPUAlarm', ComparisonOperator='GreaterThanThreshold', # 임계값보다 클 때 EvaluationPeriods=2, # 2번 연속으로 조건을 만족해야 알람 MetricName='CPUUtilization', Namespace='AWS/EC2', Period=300, # 5분 간격 Statistic='Average', Threshold=80.0, # 80% 임계값 ActionsEnabled=True, AlarmActions=[topic_arn], # 알람 발생 시 SNS로 전송 AlarmDescription='CPU 사용률이 80%를 초과했습니다', Dimensions=[ {'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'} ] ) print("알람 설정 완료: CPU 80% 초과 시 이메일 발송") ``` 그날 밤, 김개발 씨는 편안히 잠들어 있었습니다. 하지만 회사의 EC2 서버는 CPU 100%로 과부하 상태였습니다. 웹사이트는 응답하지 않았고, 수백 명의 고객이 접속을 포기했습니다. 다음 날 아침, 출근한 김개발 씨는 고객 지원팀으로부터 연락을 받았습니다. "밤새 사이트가 다운되어 있었어요. 왜 조치하지 않았나요?" 김개발 씨는 아무것도 몰랐습니다. 박시니어 씨가 말했습니다. "모니터링만으로는 부족해요. 알람을 설정해야 합니다." **알람은 잠들지 않는 파수꾼입니다** 화재 경보기를 생각해보세요. 평소에는 조용히 천장에 붙어 있다가 연기를 감지하면 큰 소리로 경보를 울립니다. 여러분이 잠들어 있어도, 다른 일을 하고 있어도 화재를 알려줍니다. CloudWatch 알람도 똑같습니다. 24시간 내내 메트릭을 감시하다가 **임계값**을 넘으면 즉시 알려줍니다. 개발자가 화면을 보고 있든 말든 상관없습니다. 문제가 생기면 자동으로 통보합니다. **알람이 없던 시절의 악몽** 과거에는 관리자가 직접 모니터링 화면을 계속 지켜봐야 했습니다. 하지만 사람이 24시간 화면만 볼 수는 없습니다. 잠도 자야 하고, 식사도 해야 하고, 회의도 해야 합니다. 대기업에서는 **교대 근무**를 했습니다. 낮 근무자, 밤 근무자를 나눠서 24시간 누군가는 모니터링 화면을 지켜봤습니다. 인건비도 많이 들고, 야간 근무는 건강에도 해로웠습니다. 스타트업에서는 그럴 여유가 없었습니다. 개발자가 개발도 하고 모니터링도 해야 했습니다. 결국 문제를 놓치는 경우가 많았고, 고객 불만으로 이어졌습니다. **알람이 모든 것을 자동화합니다** CloudWatch 알람은 사람 대신 메트릭을 감시합니다. CPU 사용률을 1분마다 체크하고, 임계값을 넘으면 즉시 SNS(Simple Notification Service)로 알림을 보냅니다. SNS는 **알림 전달 서비스**입니다. 이메일, SMS, 슬랙, 전화 등 다양한 채널로 메시지를 보낼 수 있습니다. 개발자가 가장 선호하는 방식으로 알림을 받을 수 있습니다. **코드로 알람 설정하기** 위의 코드를 단계별로 살펴보겠습니다. 먼저 SNS 토픽을 생성합니다. 토픽은 **알림 채널**이라고 생각하면 됩니다. "ServerAlerts"라는 이름의 채널을 만드는 것입니다. 다음으로 `subscribe` 메서드로 이메일 구독을 추가합니다. 이 채널에서 발생하는 모든 알림을 지정된 이메일로 받겠다는 뜻입니다. 실행하면 이메일로 확인 메일이 오고, 구독을 승인해야 합니다. `put_metric_alarm`은 실제 알람을 생성합니다. `ComparisonOperator`는 비교 방식입니다. `GreaterThanThreshold`는 "임계값보다 클 때"를 의미합니다. 반대로 `LessThanThreshold`도 있습니다. **EvaluationPeriods의 중요성** `EvaluationPeriods=2`는 매우 중요합니다. 이것은 "2번 연속으로 조건을 만족해야 알람을 발생시킨다"는 뜻입니다. 왜 1번이 아니라 2번일까요? **순간적인 스파이크**를 무시하기 위해서입니다. CPU가 잠깐 85%로 올라갔다가 바로 40%로 떨어질 수 있습니다. 이런 경우마다 알람을 받으면 **거짓 양성**으로 피로도가 높아집니다. 2번 연속이면 "진짜 문제"일 가능성이 높습니다. 10분 동안 계속 80%를 넘으면 명백한 과부하 상태입니다. 이때만 알람을 받는 것이 효율적입니다. **실무 활용 사례** 전자상거래 회사에서는 **다단계 알람**을 설정합니다. CPU 70% 경고, 80% 주의, 90% 위험 이렇게 3단계로 나눕니다. 70%에서는 슬랙 알림, 80%에서는 이메일, 90%에서는 SMS와 전화까지 보냅니다. 게임 회사에서는 **동시 접속자 수**를 기준으로 알람을 설정합니다. 평소 1만 명인데 갑자기 10만 명이 접속하면 서버가 버티지 못합니다. 2만 명을 넘으면 알람이 울리고, 미리 서버를 증설합니다. 금융 서비스에서는 **네트워크 오류율**을 모니터링합니다. 정상적으로는 오류가 0.01% 이하인데, 1%를 넘으면 DDoS 공격이나 네트워크 장애일 가능성이 있습니다. 즉시 보안팀에 알립니다. **알람 피로도 관리** 초보자가 흔히 하는 실수는 **너무 많은 알람**을 설정하는 것입니다. CPU 50%, 60%, 70%, 80%... 모든 단계마다 알람을 설정하면 하루에 수십 통의 이메일을 받게 됩니다. 알람이 너무 자주 오면 **무시하게 됩니다**. "늑대가 나타났다"고 매번 거짓말하던 양치기 소년처럼, 진짜 위험할 때도 알람을 확인하지 않게 됩니다. 이를 **알람 피로도**라고 합니다. 핵심 지표에만 알람을 설정하세요. CPU 80%, 메모리 90%, 디스크 사용률 85% 정도면 충분합니다. 정말 중요한 알람만 울리도록 하는 것이 효과적입니다. **이제 안심하고 잘 수 있습니다** 김개발 씨는 알람을 설정한 후 마음이 편해졌습니다. 집에 가서 쉬어도, 주말에 여행을 가도 문제가 생기면 즉시 알림을 받을 수 있습니다. 일주일 후, 새벽 3시에 휴대폰이 울렸습니다. "CPU 사용률 80% 초과" 알람이었습니다. 김개발 씨는 노트북을 켜서 원인을 확인하고, 임시로 서버를 재시작했습니다. 고객들은 아무도 모르게 문제가 해결되었습니다. "알람이 없었다면 큰일 날 뻔했네요." 김개발 씨는 안도했습니다. **실전 팁** 💡 - EvaluationPeriods를 2 이상으로 설정하여 거짓 양성을 줄이세요 - 핵심 지표에만 알람을 설정하여 알람 피로도를 방지하세요 - SNS 구독 후 반드시 이메일 확인 링크를 클릭하여 구독을 승인하세요 --- ## 6. 로그_그룹_기초 "CPU는 정상인데 왜 에러가 나는 거죠?" 김개발 씨는 당황했습니다. CloudWatch 메트릭에는 문제가 없었지만 사용자는 계속 오류를 겪고 있었습니다. 박시니어 씨가 말했습니다. "로그를 확인해보세요." **로그 그룹**은 애플리케이션에서 발생하는 모든 이벤트와 오류 메시지를 기록하는 저장소입니다. 마치 비행기의 블랙박스처럼 모든 활동을 기록하여 나중에 분석할 수 있습니다. 메트릭은 "무엇이 일어났는지" 알려주고, 로그는 "왜 일어났는지" 알려줍니다. 다음 코드를 살펴봅시다. ```python import boto3 import time logs = boto3.client('logs') # 로그 그룹 생성 log_group_name = '/aws/application/myapp' try: logs.create_log_group(logGroupName=log_group_name) print(f"로그 그룹 생성: {log_group_name}") except logs.exceptions.ResourceAlreadyExistsException: print("로그 그룹이 이미 존재합니다") # 로그 스트림 생성 log_stream_name = 'app-server-001' logs.create_log_stream( logGroupName=log_group_name, logStreamName=log_stream_name ) # 로그 메시지 전송 logs.put_log_events( logGroupName=log_group_name, logStreamName=log_stream_name, logEvents=[ { 'timestamp': int(time.time() * 1000), # 밀리초 단위 'message': 'User login successful: user_id=12345' }, { 'timestamp': int(time.time() * 1000), 'message': 'ERROR: Database connection timeout' } ] ) print("로그 전송 완료") # 로그 조회 response = logs.filter_log_events( logGroupName=log_group_name, logStreamNames=[log_stream_name], filterPattern='ERROR' # ERROR 키워드만 필터링 ) for event in response['events']: print(f"[{event['timestamp']}] {event['message']}") ``` 김개발 씨는 CloudWatch 대시보드를 확인했습니다. CPU는 40%, 메모리는 60%, 네트워크도 정상이었습니다. 하지만 고객 지원팀에서는 계속 오류 신고가 들어온다고 했습니다. "결제가 안 돼요", "로그인이 안 돼요" 숫자로 된 메트릭만으로는 원인을 알 수 없었습니다. 박시니어 씨가 다가와 물었습니다. "로그는 확인해봤어요?" "로그요?" 김개발 씨는 로그를 어디서 보는지도 몰랐습니다. **로그는 서버가 남기는 일기장입니다** 사람이 매일 일기를 쓰듯이, 서버도 모든 활동을 기록합니다. "오전 10시 23분, 사용자 A가 로그인했습니다", "오전 10시 25분, 데이터베이스 연결 오류가 발생했습니다" 이런 식으로 모든 이벤트를 남깁니다. 메트릭은 **요약 정보**입니다. CPU 사용률이 60%라는 것은 알지만, 어떤 프로세스가 CPU를 많이 쓰는지는 모릅니다. 로그는 **상세 정보**입니다. "payment-service 프로세스가 무한 루프에 빠졌습니다"처럼 구체적인 원인을 알려줍니다. **로그가 없던 시절의 어려움** 과거에는 각 서버의 로컬 파일에 로그를 저장했습니다. `/var/log/app.log` 같은 파일에 텍스트로 기록했습니다. 문제가 생기면 서버에 SSH로 접속해서 `tail -f /var/log/app.log` 명령어로 확인했습니다. 하지만 여러 대의 서버를 운영하면 문제가 복잡해집니다. 웹 서버 3대, API 서버 5대가 있다면 8곳의 로그 파일을 일일이 확인해야 했습니다. 어느 서버에서 오류가 났는지 알 수 없으니 전부 뒤져야 했습니다. 더 큰 문제는 **로그 검색**이었습니다. 하루에 수백만 줄의 로그가 쌓이는데, 특정 오류 메시지를 찾으려면 `grep` 명령어로 텍스트를 검색해야 했습니다. 시간도 오래 걸리고 서버 부하도 높았습니다. **CloudWatch Logs가 모든 문제를 해결합니다** CloudWatch Logs는 모든 서버의 로그를 **중앙 집중화**합니다. 여러 서버에서 발생한 로그를 한곳에 모아서 통합 검색할 수 있습니다. 어느 서버에서 오류가 났는지 찾기 위해 일일이 접속할 필요가 없습니다. **로그 그룹**은 로그를 분류하는 폴더와 같습니다. 애플리케이션별, 환경별로 로그 그룹을 나눕니다. `/aws/application/myapp`은 "myapp 애플리케이션의 로그"를 의미합니다. **로그 스트림**은 로그 그룹 안의 개별 파일입니다. 서버별로 로그 스트림을 만듭니다. `app-server-001`, `app-server-002`처럼 각 서버의 로그를 구분하여 저장합니다. **코드로 로그 기록하기** 위의 코드를 살펴보겠습니다. `create_log_group`으로 로그 그룹을 만듭니다. 이미 존재하면 예외가 발생하므로 try-except로 처리했습니다. 여러 번 실행해도 안전합니다. `create_log_stream`은 로그 스트림을 생성합니다. 서버마다 고유한 이름을 사용하세요. 인스턴스 ID나 호스트네임을 사용하면 좋습니다. `put_log_events`는 실제 로그 메시지를 전송합니다. `timestamp`는 밀리초 단위이므로 `time.time() * 1000`으로 변환합니다. `message`에는 원하는 텍스트를 자유롭게 기록할 수 있습니다. **로그 검색의 강력함** `filter_log_events`는 로그를 검색합니다. `filterPattern`에 키워드를 지정하면 해당 키워드가 포함된 로그만 가져옵니다. "ERROR"로 필터링하면 모든 오류 로그만 볼 수 있습니다. 패턴은 매우 강력합니다. `[ERROR]`, `[WARN]`, `timeout`, `exception` 등 다양한 키워드로 검색할 수 있습니다. 정규표현식도 지원하여 복잡한 패턴도 가능합니다. 시간 범위도 지정할 수 있습니다. "어제 오후 2시부터 3시 사이의 ERROR 로그"처럼 정확한 시점의 로그를 찾을 수 있습니다. 문제가 언제 시작되었는지 정확히 파악할 수 있습니다. **실무 활용 사례** 스타트업에서는 모든 API 요청을 로그로 남깁니다. 어떤 사용자가 언제 어떤 API를 호출했는지 모두 기록합니다. 사용자가 "결제가 안 됐어요"라고 신고하면 로그를 검색하여 정확한 오류 원인을 찾습니다. 게임 회사에서는 **게임 이벤트**를 로그로 기록합니다. 아이템 획득, 레벨업, 결제 등 모든 행동을 남깁니다. 나중에 데이터 분석에 활용하여 사용자 패턴을 파악하고 게임을 개선합니다. 금융 회사에서는 **감사 로그**로 활용합니다. 누가 언제 어떤 데이터에 접근했는지 모두 기록합니다. 규제 기관에서 요청하면 로그를 제출하여 투명성을 증명합니다. **로그 비용 관리** 주의할 점은 **로그 비용**입니다. CloudWatch Logs는 저장된 데이터 양과 보관 기간에 따라 비용이 부과됩니다. 너무 많은 로그를 너무 오래 보관하면 비용이 증가합니다. **로그 보관 기간**을 설정하세요. 개발 환경 로그는 7일, 운영 환경 로그는 30일 정도면 충분한 경우가 많습니다. 1년 이상 보관할 필요는 거의 없습니다. 오래된 로그는 자동으로 삭제되도록 설정하세요. **로그 레벨**도 중요합니다. DEBUG 레벨까지 모두 기록하면 로그 양이 폭발적으로 증가합니다. 운영 환경에서는 INFO, WARN, ERROR만 기록하는 것이 좋습니다. **문제를 해결했습니다** 김개발 씨는 로그를 검색했습니다. `filter_log_events`로 "ERROR"를 검색하니 "Database connection timeout" 메시지가 보였습니다. 데이터베이스 연결이 끊어진 것이 원인이었습니다. 데이터베이스 서버를 확인하니 최대 연결 수를 초과했습니다. 설정을 조정하고 연결 풀을 최적화하자 문제가 해결되었습니다. "메트릭만 봤다면 절대 못 찾았을 거예요." 김개발 씨가 감탄했습니다. 로그는 메트릭과 함께 사용할 때 진가를 발휘합니다. 숫자와 메시지를 함께 보면 서버의 모든 것을 이해할 수 있습니다. **실전 팁** 💡 - 로그 보관 기간을 설정하여 비용을 절감하세요 (개발 7일, 운영 30일) - 운영 환경에서는 DEBUG 로그를 끄고 INFO 이상만 기록하세요 - 중요한 이벤트는 ERROR 레벨로 기록하여 쉽게 필터링할 수 있게 하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, CloudWatch, EC2, Monitoring, Logs

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS CloudWatch 모니터링 완벽 가이드

목차

1. CloudWatch란?

2. 기본 메트릭 확인

3. EC2 모니터링

4. 대시보드 생성

5. 알람 설정하기

6. 로그 그룹 기초

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

Grafana 대시보드 완벽 가이드

Prometheus 메트릭 수집 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드