관찰 가능성과 운영 기본기

서비스는 만든 뒤부터 운영이 시작된다

서버를 만들고, 데이터베이스를 붙이고, 도메인까지 연결하면 서비스가 완성된 것처럼 보입니다. 하지만 실제 운영은 그다음부터 시작됩니다. 사용자가 접속했을 때 느린지, 오류가 늘고 있는지, 누가 설정을 바꿨는지, 비용을 만드는 리소스가 어디 있는지 알아야 합니다.

관찰 가능성은 시스템 안을 직접 열어 보지 않아도 상태를 추적할 수 있게 만드는 능력입니다. 자동차 계기판을 떠올리면 쉽습니다. 운전자는 엔진 내부를 보지 않아도 속도, 연료, 경고등을 보고 판단합니다. AWS 운영에서도 같은 역할을 하는 도구가 필요합니다.

이 장에서는 CloudWatch와 CloudTrail을 중심으로 봅니다. CloudWatch는 성능 지표, 로그, 알람을 모으는 운영 계기판에 가깝습니다. CloudTrail은 AWS 계정 안에서 누가 어떤 API 작업을 했는지 남기는 감사 기록입니다. 둘은 역할이 다릅니다. CloudWatch는 "서비스가 지금 괜찮은가?"를 보는 데 강하고, CloudTrail은 "누가 무엇을 바꿨는가?"를 추적하는 데 강합니다.

AI 생성 이미지

Metrics: 숫자로 상태를 먼저 본다

CloudWatch Metrics의 Metric은 시간에 따라 기록되는 숫자 지표입니다. 예를 들어 EC2의 CPU 사용률, ALB의 요청 수, Lambda의 오류 수, DynamoDB의 읽기·쓰기 사용량처럼 숫자로 표현되는 상태입니다.

운영에서 지표는 원인을 바로 알려 주지는 않습니다. 대신 어디를 먼저 봐야 할지 알려 줍니다.

예를 들어 웹 서비스가 느리다는 신고가 들어왔다고 해 봅시다.

• ALB 요청 수가 갑자기 늘었는가?

• HTTP 5XX 오류가 증가했는가?

• 대상 응답 시간이 길어졌는가?

• EC2 CPU 사용률이 계속 90% 근처인가?

• Lambda 실행 오류나 시간 초과가 늘었는가?

이 질문에 답하면 문제 범위를 좁힐 수 있습니다. 트래픽이 늘어 느린 것인지, 애플리케이션 오류가 생긴 것인지, 서버 자원이 부족한 것인지 구분할 수 있습니다.

초보자가 먼저 볼 만한 대표 지표는 다음과 같습니다.

주의할 점이 있습니다. EC2는 기본 지표만으로 메모리 사용률을 바로 보여 주지 않습니다. 메모리나 디스크 사용률을 CloudWatch에서 보고 싶다면 CloudWatch Agent를 설치해 별도 지표로 보내야 합니다. Agent를 아직 설치하지 않았다면 CPU 사용률, 디스크 I/O, 애플리케이션 응답 시간, 오류율 같은 대체 지표로 상태를 추정할 수 있습니다. 단, 이는 어디까지나 추정입니다. 운영 서비스라면 메모리와 디스크 사용률 수집을 별도로 준비하는 편이 좋습니다.

지표를 볼 때 평균값만 믿는 것도 위험합니다. 평균 응답 시간이 200ms여도 일부 사용자는 5초를 기다릴 수 있습니다. 그래서 운영에서는 평균과 함께 p95, p99 같은 백분위 지표를 봅니다. p95는 전체 요청 중 95%가 이 시간 안에 응답했다는 뜻입니다. 느린 사용자 경험을 찾는 데 평균보다 유용합니다.

Logs: 숫자가 말하지 못한 이유를 찾는다

Metrics가 "무슨 일이 일어났는지"를 숫자로 알려 준다면, Logs는 "왜 그런 일이 생겼는지"를 찾는 단서입니다. 로그에는 애플리케이션이 남긴 실행 기록, 오류 메시지, 요청 정보, 처리 시간 등이 들어갑니다.

CloudWatch Logs의 기본 단위는 Log group과 Log stream입니다.

• Log group: 같은 종류의 로그를 모아 두는 상자입니다. 예를 들어 /aws/lambda/order-api처럼 Lambda 함수별 로그 그룹이 생길 수 있습니다.

• Log stream: 로그 그룹 안에서 실제 로그가 시간 흐름에 따라 쌓이는 단위입니다. EC2 인스턴스, 컨테이너, Lambda 실행 환경별로 나뉠 수 있습니다.

서비스별 로그 수집 방식은 조금씩 다릅니다.

• Lambda는 기본적으로 함수 실행 로그를 CloudWatch Logs로 보낼 수 있습니다.

• ECS는 작업 정의에서 awslogs 로그 드라이버를 설정해 컨테이너 로그를 보낼 수 있습니다.

• EC2 애플리케이션 로그는 CloudWatch Agent를 설치해 /var/log/... 같은 파일을 전송하도록 구성합니다.

로그는 아무렇게나 남기면 나중에 찾기 어렵습니다. 운영을 생각한다면 처음부터 일정한 형식을 정하는 것이 좋습니다. 특히 JSON 형태의 구조화 로그를 쓰면 검색과 집계가 쉬워집니다.

예를 들어 다음처럼 남길 수 있습니다.

{
  "level": "ERROR",
  "service": "order-api",
  "requestId": "abc-123",
  "userId": "user-42",
  "path": "/orders",
  "statusCode": 500,
  "message": "database connection timeout"
}

이런 로그는 CloudWatch Logs Insights에서 조건을 걸어 찾기 쉽습니다.

fields @timestamp, level, service, path, statusCode, message
| filter level = "ERROR"
| sort @timestamp desc
| limit 20

로그를 잘 남기는 습관은 장애 대응 시간을 줄입니다. 오류가 발생했을 때 "서버가 이상하다"에서 멈추지 않고, "주문 API에서 데이터베이스 연결 시간이 초과됐다"까지 빠르게 좁혀 갈 수 있습니다.

단, 로그에는 비밀번호, Access Key, 주민등록번호, 카드번호 같은 민감 정보를 남기면 안 됩니다. 로그는 문제 해결을 위한 기록이지만, 동시에 유출되면 위험한 데이터가 될 수 있습니다.

Alarm: 사람이 보기 전에 시스템이 알려 주게 한다

운영자가 CloudWatch 화면을 하루 종일 보고 있을 수는 없습니다. 그래서 Alarm이 필요합니다. CloudWatch Alarm은 특정 지표가 정해 둔 조건을 넘으면 알림을 보내거나 자동 작업을 실행하는 기능입니다.

예를 들어 다음과 같은 알람을 만들 수 있습니다.

• EC2 CPU 사용률이 10분 동안 80% 이상이면 알림

• ALB 5XX 오류가 5분 동안 일정 수 이상이면 알림

• Lambda 오류 수가 1분 동안 5회 이상이면 알림

• SQS 대기 메시지가 15분 이상 계속 쌓이면 알림

• RDS 사용 가능한 저장 공간이 일정 기준 아래로 떨어지면 알림

알림은 보통 SNS와 연결합니다. SNS는 알림을 이메일, 문자, 웹훅 등으로 전달하는 서비스입니다. 학습 단계에서는 이메일 구독을 만들어 두는 것만으로도 충분합니다. 알람이 발생하면 메일을 받고, CloudWatch에서 관련 지표와 로그를 확인하는 흐름을 익히면 됩니다.

알람에는 보통 세 가지 상태가 있습니다.

• OK: 조건이 정상 범위입니다.

• ALARM: 설정한 임계값을 넘었습니다.

• INSUFFICIENT_DATA: 판단할 데이터가 부족합니다.

알람을 만들 때는 임계값만큼 평가 기간도 중요합니다. CPU가 1분 동안 90%를 넘었다고 바로 장애라고 보기는 어렵습니다. 배포 직후나 일시적인 작업으로 순간적으로 튈 수 있기 때문입니다. 그래서 "5분 단위로 2번 연속 80% 이상"처럼 조건을 잡으면 불필요한 알림을 줄일 수 있습니다.

반대로 너무 느슨하게 잡으면 실제 장애를 늦게 알게 됩니다. 알람은 처음부터 완벽하게 만들기보다 운영하면서 조정해야 합니다. 알림이 너무 자주 울리면 사람들이 무시하게 되고, 너무 적게 울리면 장애를 놓칩니다. 이를 알람 피로라고 합니다.

좋은 알람은 단순히 시끄러운 알람이 아니라 행동으로 이어지는 알람입니다. 알람을 받았을 때 무엇을 확인해야 하는지 정해져 있어야 합니다.

예를 들어 "ALB 5XX 오류 증가" 알람을 받았다면 다음 순서로 볼 수 있습니다.

1. ALB의 5XX가 로드 밸런서 오류인지, 대상 서버 오류인지 확인합니다.

2. 같은 시간대의 TargetResponseTime과 RequestCount를 봅니다.

3. 대상 EC2나 ECS 컨테이너 로그에서 ERROR를 검색합니다.

4. 최근 배포나 설정 변경이 있었는지 확인합니다.

5. CloudTrail에서 관련 리소스 변경 기록을 확인합니다.

이렇게 알람, 지표, 로그, 감사 기록이 연결될 때 운영 속도가 빨라집니다.

CloudTrail: 누가 무엇을 바꿨는지 남긴다

장애 원인은 코드나 트래픽만이 아닙니다. 누군가 보안 그룹 규칙을 바꾸었거나, IAM 권한을 수정했거나, S3 버킷 정책을 열었거나, Auto Scaling 설정을 바꾸었을 수도 있습니다. 이런 변경은 CloudWatch Metrics만으로는 찾기 어렵습니다.

CloudTrail은 AWS 계정에서 발생한 API 호출 기록을 남깁니다. 콘솔에서 버튼을 누르는 작업도 내부적으로는 AWS API 호출입니다. CLI로 명령을 실행해도 API 호출입니다. CloudTrail을 보면 다음과 같은 질문에 답할 수 있습니다.

• 누가 EC2 인스턴스를 종료했는가?

• 누가 보안 그룹의 22번 포트를 열었는가?

• 누가 IAM 정책을 수정했는가?

• 누가 S3 버킷 정책을 변경했는가?

• 어떤 IP에서 콘솔 로그인이 발생했는가?

CloudTrail 이벤트에는 대체로 사용자, 호출한 API 이름, 시간, 리전, 소스 IP, 대상 리소스 같은 정보가 포함됩니다. 운영 중 문제가 생겼을 때 "최근에 무엇이 바뀌었나?"를 확인하는 데 매우 중요합니다.

학습 단계에서는 CloudTrail 콘솔의 Event history에서 최근 이벤트를 검색해 보는 것부터 시작하면 됩니다. 운영 환경에서는 Trail을 만들어 S3에 장기 보관하고, 필요한 이벤트를 CloudWatch Logs로 보내 알람과 연결할 수 있습니다. 예를 들어 MFA 없이 콘솔 로그인이 발생하거나, 중요한 IAM 정책 변경이 생기면 CloudWatch Logs의 metric filter를 거쳐 CloudWatch Alarm으로 알림을 받을 수 있습니다.¹

CloudTrail은 보안 감사의 기본 도구입니다. 다만 로그를 남긴다고 보안이 자동으로 완성되지는 않습니다. 중요한 것은 기록을 정기적으로 확인하고, 위험한 이벤트에 알림을 붙이고, 필요할 때 추적할 수 있도록 보관 기간과 접근 권한을 관리하는 것입니다.

태그와 이름: 찾을 수 있어야 운영할 수 있다

운영이 어려워지는 흔한 이유는 리소스가 많아서가 아닙니다. 무엇이 무엇인지 알 수 없어서입니다.

EC2 이름이 test, server1, new-server처럼 되어 있고, 보안 그룹 이름이 launch-wizard-3으로 남아 있으면 장애가 났을 때 어떤 서비스의 리소스인지 바로 알기 어렵습니다. 비용이 발생해도 어느 프로젝트 때문인지 찾기 힘듭니다.

그래서 처음부터 이름 규칙과 태그 규칙을 정해야 합니다.

이름은 사람이 읽고 이해할 수 있어야 합니다.

프로젝트-환경-역할-번호
shop-dev-web-01
shop-prod-alb-01
shop-prod-rds-main

태그는 리소스에 붙이는 설명표입니다. AWS 리소스를 검색하거나 비용을 분류하거나 운영 책임자를 찾을 때 도움이 됩니다.

처음에는 다음 태그만 정해도 충분합니다.

태그는 비용 관리에도 연결됩니다. 예를 들어 Environment=dev 리소스는 야간에 중지하고, Project=shop 리소스만 비용을 따로 집계할 수 있습니다. 13장에서 비용 관리를 다룰 때 이 태그가 다시 중요해집니다.

중요한 점은 태그와 이름도 운영 규칙이라는 것입니다. 나중에 정리하려고 하면 이미 리소스가 많아져 어렵습니다. 작은 실습을 할 때부터 규칙을 붙이는 습관을 들이는 편이 좋습니다.

작은 운영 점검표

서비스를 배포한 뒤에는 다음 질문을 스스로 확인해 봅시다.

• 이 서비스의 요청 수, 오류율, 응답 시간을 볼 수 있는가?

• 서버나 함수가 실패했을 때 로그를 어디서 찾는지 아는가?

• 중요한 장애 징후가 생기면 이메일이나 알림을 받을 수 있는가?

• 누가 보안 그룹, IAM, S3 정책을 바꿨는지 추적할 수 있는가?

• 리소스 이름과 태그만 보고 소유자와 용도를 알 수 있는가?

이 질문에 답할 수 있다면 단순히 "만든 서비스"에서 "운영할 수 있는 서비스"로 한 단계 올라선 것입니다.

관찰 가능성은 나중에 붙이는 장식이 아닙니다. EC2, Lambda, ECS, RDS, S3처럼 어떤 방식을 선택하든 운영에 반드시 필요합니다. 문제가 생기지 않는 시스템은 없습니다. 좋은 운영은 문제가 생겼을 때 빨리 알아차리고, 원인을 좁히고, 같은 문제가 반복되지 않게 만드는 일입니다.

참고

¹How do I use CloudWatch alarms to monitor CloudTrail events?