💻 프로젝트/QRoad

AWS 기반 운영 모니터링 환경 구축기 (EC2 + CloudWatch + Grafana) - 1편

SoloQuest 2026. 2. 19. 01:40

프로젝트에서 인프라를 담당하면서,
단순히 서버를 배포하는 것을 넘어 운영 관점의 모니터링 환경을 직접 구축해보았다.

이번 글에서는 EC2 서버에서 실행 중인 Spring 백엔드 애플리케이션을 기준으로,
CloudWatch와 Grafana를 활용해 인프라 및 로그 모니터링 환경을 구성한 과정을 정리한다.

1. 환경 구성

  • AWS EC2 (Ubuntu)
  • Spring Boot 백엔드 (EC2에서 직접 실행)
  • 로그 파일: /var/log/be/be.log
  • CloudWatch (Metrics + Logs)
  • Grafana (EC2에서 실행)

목표는 다음 두 가지였다.

  1. EC2 인프라 상태를 시각화
  2. 서버 로그를 중앙 수집하고, 에러를 모니터링

2. 인프라 모니터링 구성

2-1. Grafana 설치 및 CloudWatch 연동

EC2 서버에 Grafana를 실행하고,
Data Source로 AWS CloudWatch를 연결했다.

CloudWatch Metrics를 통해 EC2 지표를 가져와 대시보드를 구성했다.

2-2. 구성한 인프라 패널

🔹 CPU Utilization (Time Series)

  • EC2의 CPU 사용률을 시각화
  • 순간적인 부하 및 지속적인 고부하 여부 확인 가능

🔹 Network In / Network Out (Time Series)

  • 네트워크 유입/유출 트래픽 확인
  • 특정 시점의 트래픽 급증 여부 파악 가능

🔹 StatusCheckFailed (Stat Panel)

  • EC2 인스턴스 헬스 체크 상태
  • 0이면 정상, 1이면 장애

이를 통해 서버 리소스 상태를 한 화면에서 확인 가능한 인프라 대시보드를 구성했다.

3. 로그 중앙 수집 시스템 구축

기존에는 로그가 EC2 내부 파일에만 남아 있었다.

/var/log/be/be.log

이 상태에서는:

  • 서버에 직접 접속해야 로그 확인 가능
  • 장애 발생 시 빠른 대응이 어려움

이를 해결하기 위해 CloudWatch Logs로 로그를 중앙 수집하도록 구성했다.

3-1. CloudWatch Agent 설치

Ubuntu 환경에서는 apt로 바로 설치되지 않기 때문에
공식 .deb 패키지를 다운로드하여 설치했다.

설치 후, 로그 수집 설정 파일을 구성하여 다음 파일을 수집 대상으로 지정했다.

{
    "logs":{
        "logs_collected":{
            "files":{
                "collect_list":[
                    {
                        "file_path":"/var/log/be/be.log",
                        "log_group_name":"qroad-backend-log",
                        "log_stream_name":"{instance_id}",
                        "retention_in_days":14
                    }
                ]
            }
        }
    }
}

IAM Role에는 CloudWatchAgentServerPolicy를 부여했다.

설정 적용 후, CloudWatch Logs에 qroad-backend-log 로그 그룹이 생성되고
서버 로그가 정상적으로 수집되는 것을 확인했다.

4. Grafana에서 로그 시각화

CloudWatch Logs를 Grafana에서 Data Source로 활용하여
Logs Insights 쿼리를 통해 로그를 시각화했다.

4-1. 전체 로그 패널

최근 로그를 확인할 수 있도록 구성했다.

 
fields @timestamp, @message
| sort @timestampdesc
| limit 100

초기에는 Hibernate DEBUG 로그가 과도하게 출력되어 가독성이 떨어졌다.
이를 정리하여 INFO 이상 로그만 보이도록 필터링했다.

4-2. ERROR 개수 추이 그래프

단순 로그 조회를 넘어,
로그를 “지표화”하기 위해 ERROR 발생 개수를 시간 단위로 집계했다.

 
fields @timestamp, @message
|filter@messagelike/ERROR/
| stats count() as error_count by bin(5m)

이를 통해:

  • 특정 시점에 에러가 급증하는지
  • 장애 패턴이 있는지

시각적으로 확인할 수 있도록 구성했다.

4-3. 500 에러 로그 패널

사용자 영향이 큰 500 에러를 별도로 필터링하여
최근 로그를 확인할 수 있는 패널을 추가했다.

 
fields @timestamp, @message
|filter@messagelike/500/
| sort @timestampdesc
| limit 50

이를 통해 내부 예외와 사용자 영향 장애를 구분해 확인할 수 있도록 했다.

5. 최종 대시보드 구조

현재 대시보드는 다음과 같이 구성되어 있다.

🔹 Infra 영역

  • CPU Utilization
  • Network In / Out
  • Instance Health (StatusCheck)

🔹 Service 영역

  • ERROR 개수 추이 그래프
  • 500 에러 로그 패널
  • 최근 로그 패널

즉,

인프라 지표 + 애플리케이션 로그를 한 화면에서 통합 확인 가능한 구조

를 완성했다.

완성화면

  • 아직은 서버 운영을 본격적으로 시작하지 않아 데이터가 많지않다.
  • 그러나 서버 운영을 시작하면 큰 도움을 줄것으로 예상하고 있다.

마무리

이번 작업을 통해 단순히 “서버를 운영한다”는 개념을 넘어,

  • 인프라 상태 모니터링
  • 로그 중앙 수집
  • 로그 기반 지표화
  • 인프라 + 서비스 통합 대시보드 구성

까지 직접 설계하고 구축해볼 수 있었다.

운영 환경을 경험해보니, 코드 작성과는 또 다른 영역의 고민이 필요하다는 것을 느꼈다.

 

다음 단계에서는 API 요청 수 및 응답 시간 지표와 비용 데이터를 추가로 시각화하여, 인프라·로그 중심의 모니터링을 서비스 운영 지표까지 확장할 계획이다.