문제 인식
ECS Fargate에서 운영 중인 배치 서비스의 Container Insights 대시보드를 확인하던 중, StorageWriteBytes 지표가 지속적으로 우상향하는 것을 발견했다.
특히 1월 20일과 2월 9일에 급격한 폭증이 확인되었다.
해당 서비스는 EFS를 마운트하여 설정 파일을 관리하는 구조였기 때문에, EFS 연결이 원인인지 확인이 필요했다.
분석 과정
의심 1: ECS 컨테이너 자체 로그
ECS 컨테이너가 자체적으로 생성하는 로그(CloudWatch Logs, Container Insights 등)가 지속적으로 기록되면서 쓰기 I/O가 증가했을 가능성을 검토했다.
가능한 시나리오:
- 컨테이너에서 DEBUG/INFO 레벨 로그가 지속적으로 기록
- 로그가 컨테이너 내부 파일 시스템(
/var/log,/tmp)에 저장 - CloudWatch Logs로 전송하기 전 로그 데이터를 컨테이너 내에 일시적으로 저장하는 과정에서 StorageWriteBytes 증가
- Kafka 및 REST API 관련 로그도 지속적으로 발생하므로, 네트워크 I/O뿐 아니라 디스크 I/O에도 영향
→ 애플리케이션에서 불필요한 로그나 임시 파일을 생성하는 부분이 있는지 개발팀에 확인 요청
의심 2: EFS 사용량 확인
EFS 모니터링 대시보드에서 처리량, IOPS, 클라이언트 연결, 스토리지 바이트를 확인했다.
EFS 자체의 I/O는 특별한 이상이 없었다.
EFS 실제 사용량 확인
서버에 접속하여 EFS 마운트 경로의 실제 사용량을 확인했다.
$ du -sh /ecs/config/COMMON_01/service01/
60K /ecs/config/COMMON_01/service01/EFS에는 설정 파일(YAML, XML)만 저장되어 있었고, 용량은 60KB에 불과했다. EFS는 config 파일 저장 용도로만 사용되고 있었으며, StorageWriteBytes 폭증의 원인이 아니었다.
추가 검토 사항
원인 추적 과정에서 다음 항목들도 함께 점검했다.
| 점검 항목 | 결과 |
|---|---|
| AWS Backup / DataSync 활성화 여부 | 해당 없음 |
| EFS Lifecycle Policy | 정상 |
| EFS 마운트 옵션 | 정상 |
| CloudTrail 로그 (EFS → S3 쓰기) | 특이 사항 없음 |
| 특정 IAM 역할의 과도한 데이터 기록 | 해당 없음 |
결론: 누적 지표(Cumulative Metric)
조사 결과, Container Insights의 StorageWriteBytes는 누적(cumulative) 지표였다.
이 지표는 컨테이너가 시작된 이후 발생한 모든 스토리지 쓰기 바이트를 누적하여 표시한다. 따라서:
- 컨테이너가 오래 실행될수록 값이 계속 증가하는 것은 정상 동작
- 그래프가 우상향하는 것 자체가 문제가 아님
- 1/20, 2/9의 급증은 해당 시점에 배치 작업량이 많았거나 태스크 재시작으로 인한 일시적 쓰기 증가
핵심 포인트
| 지표 | 특성 | 해석 |
|---|---|---|
| StorageWriteBytes | 누적(Cumulative) | 우상향은 정상, 기울기 변화에 주목 |
| StorageReadBytes | 누적(Cumulative) | 동일 |
| CpuUtilized | 순간값(Gauge) | 현재 사용량 그대로 해석 |
| MemoryReserved | 순간값(Gauge) | 현재 예약량 그대로 해석 |
Container Insights 지표를 볼 때 누적 지표와 순간 지표를 구분하지 않으면 "스토리지 쓰기가 계속 증가한다"고 오판할 수 있다. 실제 쓰기 속도(rate)를 보려면 CloudWatch에서 RATE() 함수를 적용하거나 Period 기반 차분으로 확인해야 한다.
마무리
"StorageWriteBytes가 계속 올라간다"는 현상에서 시작해 EFS, 컨테이너 로그, CloudTrail까지 점검했지만, 결국 지표 자체가 누적 방식이라는 것이 핵심이었다.
모니터링 지표를 해석할 때는 해당 지표가 누적(cumulative)인지 순간(gauge)인지 먼저 확인하는 것이 불필요한 트러블슈팅을 줄이는 첫 번째 단계다.
배운 점
며칠을 들여다본 끝에 나온 결론이 "지표를 잘못 읽었다"였다. 누적 지표를 순간 지표처럼 보면 무엇이든 우상향한다. 이상을 발견했을 때 원인을 찾기 전에 그 지표의 성격부터 확인했다면 EFS와 CloudTrail까지 뒤질 일은 없었다.
그래도 이 조사가 헛되지는 않았다. 지표를 의심하는 단계가 조사 순서에 추가됐고, 그 뒤로 대시보드를 만들 때 누적인지 순간인지를 이름이나 설명에 남기게 됐다.
숫자가 올라갔지만 정상이었던 다른 사례가 ECS 강제 재배포 후 메모리 사용률 급증이다. 둘 다 조치가 아니라 해석이 답이었다.
이어 읽기
- ECS 강제 재배포 후 메모리 사용률 급증: 지표 해석이 결론이었던 또 다른 사례
- 통합 모니터링 시스템 구축: 지표를 어디서 어떻게 수집하는지