Eatda 운영 개선기: Datadog Terraform, 알람 분리, 월간 리포트 자동화

1. 무엇이 문제였고 왜 개선이 필요했을까?

Eatda 서비스를 운영하면서 Datadog을 본격적으로 도입해 사용하고 있었습니다.
초반에는 익숙하지 않기도 했고, 빠르게 적용해야 하는 상황이 많다 보니
대부분의 대시보드나 알람을 Datadog 콘솔에서 직접 만들며 운영했습니다.

 

하지만 서비스의 모든 인프라 리소스를 Terraform으로 관리하는 구조에서
콘솔 기반 설정은 재현성이나 변경 이력 관리가 어렵다는 점에서 계속 아쉬움이 남아 있었습니다.

GitHub 이슈에도 “Datadog Terraform으로 관리”를 등록해두었지만
급한 일이 아니다 보니 작업 순위가 뒤로 밀린 상태였습니다.

---

비슷하게 알람도 하나의 Discord 채널에

• SLO Burn Rate 알람
• 메트릭 기반 주의/경고
• 개발 환경 리소스 부족으로 인한 알람

이렇게 성격이 다른 알람들이 모두 섞여 들어오다 보니 정말 중요한 신호를 구분하기 어려웠습니다.

---

여기에 마지막으로, 매달 AWS 콘솔과 Datadog 대시보드를 오가며
서버 비용, WAF 로그, APM 지표 등을 수동으로 점검하던 루틴이
점점 더 비효율적이고 팀원과 공유되지 않는다는 점도 계속 걸렸습니다.

 

그래서 결론적으로

• Datadog 설정을 Terraform으로 이전
• 알람을 체계적으로 분리
• 월간 서버 리포트를 자동으로 발행해 공유

이 세 가지를 한 번에 개선해야겠다는 생각이 들어 이슈를 수정하고 작업을 시작했습니다.

 

 

---

2. Datadog 데이터 Terraform으로 가져오기

현재 서비스에서 Datadog으로 관리하고 있는 리소스는
개발/운영 APM, SLO, SLO 연동 알람, Webhook Integration 정도였습니다.

이 중 APM은 Datadog 에이전트 설정을 Terraform에서 이미 관리하고 있어 문제가 없었지만,
SLO, 알람, 웹훅 설정은 모두 콘솔에만 존재하는 수동 리소스였습니다.

 

import 과정은 아래와 같이 진행하였습니다.

• Datadog 리소스 ID 하나씩 수집
• Datadog 모듈 생성 후 import.tf에서 리소스 매핑
• terraform plan으로 generated 코드 확인
• 실제 콘솔 설정과 diff 비교하며 필요한 부분만 추려서
• slos / integrations / monitors 파일에 정리
• 마지막으로 terraform apply로 상태에 반영

결과적으로 terraform 디렉토리 하위에 Datadog을 전담하는 패키지를 만들었습니다.

리소스 수가 많지 않아 하위 모듈로 나누지 않고
필요한 세가지 파일인 slos, integrations, monitors만 추가했습니다.

 

구조가 한 번 잡히고 나니 다음 단계인

알람 채널 분리 작업을 Terraform 기반으로 일관된 설정 관리가 가능해졌습니다.

---

3. 기존 알람을 경고, 주의 채널로 분기

운영 중 성격이 다른 알람들이 모두 하나의 Discord 채널로 들어오다 보니,
중요한 알람과 단순 경고 메시지가 구분되지 않는 문제가 있었습니다.

특히 Datadog에서는 alert, warning, recovery 상태가 명확히 구분되기 때문에
이를 채널 단위로 나누는 것이 훨씬 합리적이라고 판단했습니다.

 

그래서 알람을 CRITICAL(즉시 대응) / WARNING(주의) / RECOVERY(복구)로 구분해
각각 서로 다른 Discord Webhook 채널로 보내도록 메시지 템플릿 기반 라우팅을 구성했습니다.

---

Alert Routing 템플릿 정의

먼저 locals.tf에서 알람 상태에 따라 다른 Webhook을 호출하도록 footer 템플릿을 정의했습니다.

locals {
  notification_footer = <<-EOT

    ---

    {{#is_alert}}
    🚨 **CRITICAL ALERT**
    @webhook-discord-alert-channel
    {{/is_alert}}

    {{#is_warning}}
    ⚠️ **WARNING ALERT**
    @webhook-discord-warn-channel
    {{/is_warning}}

    {{#is_recovery}}
    ✅ **RECOVERY**
    @webhook-discord-warn-channel-recovery
    {{/is_recovery}}
  EOT
}

 

---

Monitor 메시지에 템플릿 적용

그리고 Monitor 메시지 message 블록 안에 각 상태별 내용을 넣고,
마지막에 footer를 포함해 채널 라우팅이 자동으로 이뤄지도록 했습니다.

 

message                  = <<-EOT
    ## 💾 [System] 메모리 부족 위험
    **Host:** {{host.name}} / **Usage:** {{value}}%

    {{#is_alert}}
    **[CRITICAL] 가용 메모리가 10% 미만입니다.**
    - **영향:** OOM Killer로 인한 주요 프로세스 강제 종료 위험
    - **조치:** 메모리 누수 확인 및 덤프 분석 권장
    {{/is_alert}}

    {{#is_warning}}
    **[WARNING] 메모리 사용량이 안전 구간을 벗어났습니다.**
    - 지속적인 증가 추세인지 모니터링 필요
    {{/is_warning}}

    ${local.notification_footer}
  EOT

---

테스트를 진행한 결과

• CRITICAL → alert-channel
• WARNING → warn-channel
• RECOVERY → warn-channel-recovery

 

 

정상적으로 각 상태에 맞는 Discord 채널로 라우팅되는 것을 확인했습니다.

채널이 분리되면서 알람 메시지의 흐름이 더 명확해졌고,
어떤 신호가 어떤 목적의 알람인지 한눈에 구분할 수 있게 되었습니다.

---

 

4. 월간 서버 리포트 발간

월간 리포트를 자동화하려면 Datadog과 AWS 데이터를 주기적으로 수집해 가공할 실행 환경이 필요했습니다.

이에 두 가지 접근 방식을 비교해보았습니다.

Lambda + EventBridge

• AWS 내부에서 바로 실행되어 IAM, VPC, CloudWatch 등과 자연스럽게 연동되지만
• 라이브러리, 람다 레이어, Terraform 설정 등이 복잡해짐

GitHub Actions + Python Script

• Cron 설정과 라이브러리 사용이 단순하고
• 추가 인프라 없이 바로 구성 가능함

월 1회 실행되는 작업의 규모를 고려해 GitHub Actions + Python Script 조합을 선택했습니다.

---

실행 흐름 요약

GitHub Actions가 한 달에 한 번 실행되면, 스크립트는 아래 순서로 월간 리포트를 생성합니다.

• 기간 계산
  • 지난달 전체 기간을 계산해 Datadog·AWS API 조회에 필요한 날짜 정보를 준비합니다.
• Datadog 지표 수집
  • SLO(가용성·레이턴시) 이력과 장애 이벤트 수를 API로 조회합니다.
• WAF 보안 지표 집계
  • CloudWatch Metrics로 Allowed/Blocked 요청 수를 월간 단위로 합산합니다.
• 비용 데이터 조회
  • Cost Explorer에서 지난달 비용과 전월 대비 증감을 조회합니다.
• Discord 리포트 생성
  • 수집한 모든 데이터를 하나의 Embed 메시지로 구성해 Discord 채널로 발송합니다.

 

결과

월 15분씩 들여 여러 콘솔을 오가며 점검하던 작업이 자동화되었고,
서비스 품질·보안·비용을 한눈에 확인할 수 있는 고정된 형식도 갖추게 되었습니다.

이 과정에서 Datadog 설정, 알람 라우팅, 월간 리포트까지 일관된 방식으로 정비되면서
팀원들과 운영 상태를 자연스럽게 공유할 수 있는 흐름이 만들어졌습니다.
앞으로도 팀 피드백을 반영해 필요한 지표나 자동화 범위를 조금씩 확장해 나갈 계획입니다.