V2는 외부 API 도입, ECS 기반 분산 서버, SLO 기반 운영으로 요구사항이 커졌다. 이 문서는 V2 요구사항에서 모니터링이 답해야 할 질문을 정리하고, 검토한 구조 후보 중 PLG(Prometheus · Loki · Grafana) + Grafana Alloy 구조를 선택한 이유와 V2 인프라 안의 배치를 정리한다.

이 문서의 PLG는 Prometheus(메트릭) · Loki(로그) · Grafana(시각화·알림)를 뜻한다. 로그 수집기는 Promtail이 아닌 Alloy를 쓴다.

1. V2에서 모니터링은 무엇을 보아야 하는가?
2. 어떤 구조 후보가 있었고, 왜 PLG + Alloy를 선택했는가?
3. 로그는 왜, 어떻게 수집하는가?
4. V2 구조 안에서 모니터링 시스템은 어디에 두는가?

이 질문들을 신호별로 묶으면 다음과 같다.

트레이스를 별도 백엔드로 두지 않은 이유는 두 가지다. V2에서 확인된 병목(HikariCP 대기, WebSocket 연결 수, 호스트 메모리)은 메트릭으로 먼저 드러나고, 요청 단위 추적은 이미 쓰고 있는 Sentry가 제공한다. Sentry Spring Boot SDK는 들어온 요청마다 트랜잭션을, RestTemplate·RestClient·WebClient로 나가는 요청마다 span을 만든다.

방법 1을 쓰지 않은 이유. 새 인프라 없이 가장 빨리 시작할 수 있지만, 대시보드 커스터마이징과 세밀한 알림 설정이 번거로운 CloudWatch의 한계가 그대로 남는다. Logs Insights는 조회할 때마다 스캔한 GB만큼 과금되고 위젯 로딩에 5~10초가 걸리며, 그대로는 알람을 걸 수 없다. Discord로 알리려면 SNS 뒤에 Lambda도 필요하다.

방법 2를 쓰지 않은 이유. 트레이스와 서비스 그래프까지 직접 갖는 가장 완전한 구성이지만, 트레이스 역할이 Sentry와 겹친다. BE·FE·FastAPI 모두에 계측을 추가해야 하고, Java agent는 라이브러리 버전과 맞아야 해서 rest·websocket(컨테이너 960MiB)에 대한 검증 부담이 크다. 10/15 알림, 10/19 prod 일정 안에서 범위가 과하다.

방법 3을 쓰지 않은 이유. 운영 부담은 가장 적지만 비용이 신호량에 비례해 늘고, 화면과 알림은 방법 1과 같은 CloudWatch 중심이 된다. Grafana로 보려면 Managed Grafana 사용자당 비용(편집자 월 $9, 뷰어 월 $5)이 추가된다.

방법 4를 선택한 이유.

• 요구사항에 필수인 메트릭·로그·알림을 Grafana 한 곳에서 본다.
• 앱은 지금처럼 stdout에 로그를 쓰고 Actuator로 메트릭을 노출하기만 하면 된다. 앱 팀 공수가 설정 수준이다.
• 트레이스는 Sentry를 그대로 쓰고, ALB가 붙이는 X-Amzn-Trace-Id로 Sentry ↔ Loki 로그를 잇는다.
• 같은 방향의 사례가 있다. 핀다는 메트릭과 PLG로 먼저 관측 체계를 만들고 트레이스(Tempo)를 나중에 붙였고, 우아한형제들은 ELK에서 Loki로 옮긴 뒤 수집량 1.6배에도 비용을 약 23% 줄였다.
• Prometheus·Loki·Grafana·Alloy는 쿠버네티스에서도 그대로 쓰이므로 V3 이행 시 설정만 옮기면 된다.

나중에 방법 2로 넓힐 조건. Sentry span 쿼터를 넘어 비용이 커질 때, Redis Pub/Sub·WebSocket 구간을 트레이스로 봐야 하는 장애가 반복될 때, 서비스가 늘어 서비스 그래프가 필요할 때 OTel 계측과 Tempo를 추가한다. Alloy가 OpenTelemetry Collector 배포판이므로 수집기는 그대로 쓸 수 있다.

flowchart LR
  subgraph HOST["ECS 컨테이너 인스턴스"]
    TASK["태스크 · awsvpc<br/>rest · websocket · frontend · fastapi"]
    DOCKER["Docker 데몬"]
    ALLOY["Alloy DAEMON"]
    TASK -->|stdout| DOCKER
    DOCKER -->|Docker API| ALLOY
  end

  subgraph MON["모니터링 EC2"]
    PROM["Prometheus"]
    LOKI["Loki"]
    GRAF["Grafana"]
  end

  CLOUDMAP["Cloud Map DNS"]
  CW["CloudWatch<br/>ALB · ECS · RDS · Redis 지표"]
  S3B[("S3")]
  SENTRY["Sentry"]
  DISCORD["Discord"]

  ALLOY -->|로그 push| LOKI
  LOKI --> S3B
  CLOUDMAP -.->|태스크 IP| PROM
  PROM -->|:8090 scrape| TASK
  TASK -->|에러 · 트레이스| SENTRY
  PROM & LOKI & CW --> GRAF
  GRAF -->|알림| DISCORD
  CW -->|독립 알람 · SNS → Lambda| DISCORD

메트릭은 "무엇이 얼마나 나빠졌는가"를 알려주지만 "왜"는 알려주지 않는다. 예외 메시지, 실패한 요청의 파라미터, 외부 API가 돌려준 에러 본문은 로그에만 있다. V2 구조에서는 로그를 컨테이너 밖 한 곳에 모아야 하는 이유가 더 분명해진다.

로그를 Loki로 보내는 방법은 크게 "앱이 직접 보낸다"와 "앱은 stdout에 쓰고 밖에서 가져간다" 두 갈래다.

방법 A가 가장 직관적이지만 선택하지 않은 핵심 이유는 로그 전송 책임이 앱에 들어오기 때문이다. Twelve-Factor App은 "앱은 출력 스트림의 라우팅이나 저장에 관여하지 않고, 각 프로세스는 이벤트 스트림을 stdout에 쓰며, 실행 환경이 이를 모아 목적지로 보낸다"고 정리한다. 앱이 stdout에만 쓰면 로그 저장소를 바꾸거나 Loki가 멈춰도 앱 코드와 요청 처리에는 영향이 없다.

awslogs와의 공존. V2 태스크는 awslogs 드라이버로 CloudWatch에 로그를 보낸다. Docker 문서에 따르면 로그 드라이버가 읽기를 지원하지 않을 때 Docker Engine은 자동으로 dual logging을 켜고, 컨테이너마다 로컬 캐시(최대 20MB × 5개)를 둬 docker logs로 읽을 수 있게 한다. Alloy는 이 Docker 데몬에서 로그를 읽으므로, CloudWatch 원본은 안전망으로 남기고 Loki에도 같은 로그가 들어간다. ECS 최적화 AMI에서 docker logs가 동작하는지 stg에서 먼저 확인하고, 동작하지 않으면 로그 드라이버를 json-file로 바꾼다.

로그 형식과 라벨.

• 로그는 JSON으로 쓴다. Spring Boot 3.4 이상은 logging.structured.format.console=ecs 설정으로 JSON 로그를 내고 MDC 값을 필드로 넣는다.
• BE 필터가 ALB의 X-Amzn-Trace-Id를 MDC와 Sentry 태그에 함께 넣는다. ALB는 요청을 타깃에 보내기 전에 이 헤더를 추가하거나 갱신한다.
• Loki 라벨은 stage·service·container 세 개만 쓴다. Loki 공식 모범 사례대로 추적 ID·사용자 ID 같은 일회성 값은 라벨이 아니라 로그 본문에서 필터로 찾는다.

discovery.docker "local" {
  host = "unix:///var/run/docker.sock"
}

discovery.relabel "ecs" {
  targets = discovery.docker.local.targets

  rule {
    source_labels = ["__meta_docker_container_name"]
    regex         = ".*(ecs-agent|internalecspause).*"
    action        = "drop"
  }
  rule {
    source_labels = ["__meta_docker_container_label_com_amazonaws_ecs_task_definition_family"]
    target_label  = "service"
  }
  rule {
    source_labels = ["__meta_docker_container_label_com_amazonaws_ecs_container_name"]
    target_label  = "container"
  }
}

loki.source.docker "ecs" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.relabel.ecs.output
  labels     = { stage = "prod" }
  forward_to = [loki.write.monitor.receiver]
}

loki.write "monitor" {
  endpoint {
    url = "http://<모니터링 호스트>:3100/loki/api/v1/push"
  }
}

설정은 stg에서 검증한 뒤 확정한다. 스테이지별로 stage 값만 다르다.

flowchart TB
  TEAM["사용자 · 팀원"] --> R53["Route 53"]

  subgraph VPC["VPC 10.20.0.0/16 · 워크로드 AZ-a"]
    subgraph PUB["public-a · public-b"]
      PALB["Prod ALB"]
      NALB["Non-Prod ALB<br/>dev · stg · monitor 호스트 규칙"]
      NAT["NAT Gateway"]
    end

    subgraph APPA["private-app · app-a"]
      subgraph PRODHOST["prod ECS 컨테이너 인스턴스 · 호스트마다"]
        PRODTASK["rest · websocket · frontend · fastapi<br/>awsvpc · :8090"]
        PRODALLOY["Alloy DAEMON<br/>host 네트워크"]
      end
    end

    subgraph DEVA["private-dev · dev-a / stg-a 예정"]
      subgraph DEVHOST["dev · stg ECS 컨테이너 인스턴스"]
        DEVTASK["dev · stg 태스크"]
        DEVALLOY["Alloy DAEMON"]
      end
    end

    subgraph OPSA["private-ops · ops-a 10.20.43.0/24 신설 제안"]
      MONH["모니터링 EC2<br/>Prometheus · Loki · Grafana"]
    end

    subgraph DATA["private-data"]
      RDS["RDS MySQL"]
      REDIS["ElastiCache Redis"]
    end

    CLOUDMAP["Cloud Map 프라이빗 DNS"]
    S3GW["S3 Gateway Endpoint"]
  end

  S3B[("S3 · Loki 블록")]
  CW["CloudWatch"]
  DISCORD["Discord"]
  SENTRY["Sentry"]

  R53 --> PALB --> PRODTASK
  R53 --> NALB --> DEVTASK
  NALB -->|monitor.moyeota.com| MONH
  PRODTASK -.->|IP 등록| CLOUDMAP
  MONH -->|DNS 조회| CLOUDMAP
  MONH -->|scrape :8090| PRODTASK
  MONH -->|scrape :8090| DEVTASK
  PRODALLOY -->|push :3100| MONH
  DEVALLOY -->|push :3100| MONH
  PRODTASK --> RDS
  PRODTASK --> REDIS
  MONH --> S3GW --> S3B
  MONH -->|조회| CW
  MONH --> NAT
  PRODTASK --> NAT
  NAT --> DISCORD
  NAT --> SENTRY

• Grafana Loki — Send log data to Loki (클라이언트 목록)
• Grafana Loki — Promtail EOL 안내
• Grafana Alloy — Introduction
• Grafana Alloy — loki.source.docker
• Grafana Loki — Best practices (라벨)
• The Twelve-Factor App — XI. Logs
• Amazon ECS — LogConfiguration (EC2 지원 로그 드라이버)
• Amazon ECS — FireLens 로그 라우팅
• Amazon ECS — DAEMON 스케줄링 전략
• Amazon ECS — 서비스 디스커버리
• AWS — Prometheus metric collection on Amazon ECS
• Docker — dual logging
• Elastic Load Balancing — ALB 요청 추적 (X-Amzn-Trace-Id)
• Spring — Structured logging in Spring Boot 3.4
• Spring — OpenTelemetry with Spring Boot
• Sentry — Spring Boot 자동 계측
• Google SRE Workbook — Alerting on SLOs
• Sloth — Prometheus SLO 생성기
• cloudonaut — CloudWatch Dashboard Cost Efficiency
• Amazon Managed Grafana 요금
• 우아한형제들 — ELK Stack에서 Loki로 전환한 이유
• 핀다 — LGTM 스택 도입기