Module 6: 모니터링 대시보드 설계

1

대시보드 설계 원칙

좋은 대시보드는 5초 안에 시스템 상태를 파악할 수 있게 해줍니다. 하지만 많은 팀이 너무 많은 지표를 한 화면에 담으려다가 오히려 혼란스러운 대시보드를 만듭니다. 대시보드 피라미드 구조를 이해하면 이 문제를 해결할 수 있습니다.

대시보드 피라미드 (3계층)

대시보드는 독자(Audience)에 따라 3개 계층으로 나뉩니다. 상위로 갈수록 넓은 시야(전체 상태), 하위로 갈수록 좁은 시야(상세 디버깅)를 제공합니다.

L1 Executive

실시간 ~ 1시간

서비스 전체 상태

• SLO 달성률, 서비스 가용성, Error Budget 잔여량

대상: CTO, VP Engineering, 임원

L2 Operational

실시간 ~ 5분

팀별/컴포넌트별 상세

• API별 레이턴시, DB 커넥션 수, Pod 상태, 배포 현황

대상: 팀 리드, SRE, 온콜 엔지니어

L3 Detailed

실시간

디버깅용 상세

• 개별 쿼리 실행 시간, Pod별 CPU/메모리, 개별 요청 트레이스, 로그

대상: 장애 대응 엔지니어

계층	독자	지표 예시	갱신 주기	행동
L1	임원	SLO 달성률	1시간	전략 결정
L2	팀 리드	API 레이턴시	5분	팀 배정
L3	엔지니어	개별 트레이스	실시간	디버깅

핵심 원칙

하나의 대시보드로 모든 사람을 만족시킬 수 없습니다. L1/L2/L3를 분리하면 각 독자가 필요한 정보만 빠르게 얻을 수 있습니다. 장애 시에는 L1 → L2 → L3 순서로 드릴다운하며 원인을 특정합니다.

2

대시보드 설계 체크리스트

좋은 대시보드는 명확한 설계 원칙을 따릅니다. 다음 체크리스트를 통과하지 못하면 대시보드가 아니라 "지표 쓰레기장"이 됩니다.

1. 5초 규칙

대시보드를 보고 5초 안에 "정상/이상" 판단이 가능해야 합니다. 숫자만 나열되어 있거나 컨텍스트가 없으면 판단할 수 없습니다.

좋은 예

✓ 빨간색/초록색 상태 표시
✓ 임계값 라인 표시
✓ 이상치 자동 하이라이트

나쁜 예

✗ 숫자만 나열
✗ 컨텍스트 없는 그래프
✗ 판단 기준 없음

2. 비교 가능성

단일 시점의 값보다 비교가 중요합니다. "지금"이 좋은지 나쁜지는 "과거"와 비교해야 알 수 있습니다.

비교 패턴

• 어제 vs 오늘
• 배포 전 vs 후
• 지난주 동 시간대 vs 이번주 동 시간대

3. 액션 연결

지표가 이상하면 다음에 무엇을 해야 하는지 명확해야 합니다. 대시보드는 진단의 시작점이지 끝이 아닙니다.

액션 예시

• Runbook 링크 (장애 대응 절차)
• 알림 채널 (Slack, PagerDuty)
• 담당자 정보
• 상세 로그/트레이스로 이동

4. 이상치 하이라이트

임계값을 초과하면 자동으로 색상이 변화해야 합니다. 사람이 숫자를 일일이 읽고 판단하게 만들면 안 됩니다.

색상 체계 예시

정상 (초록)

경고 (노랑)

위험 (빨강)

흔한 실수들

✗ 지표 과다 배치 (한 대시보드에 20+개 그래프)
✗ 컨텍스트 없는 숫자 ("CPU 73%" → 이게 좋은 건가 나쁜 건가?)
✗ 시간 범위 불일치 (한 패널은 1시간, 다른 패널은 24시간)
✗ 모든 사람에게 같은 대시보드 (L1/L2/L3 구분 없이)

3

도구별 대시보드 구성 실전

이론을 실제 도구에 적용하는 방법을 알아봅니다. Datadog, Grafana, CloudWatch 각각의 특징과 구성 방법을 살펴봅니다.

Datadog Dashboard

위젯 유형

• Timeseries: 시계열 그래프
• Query Value: 단일 숫자 표시
• Top List: 상위 N개 목록

• Heatmap: 분포 시각화
• SLO Summary: SLO 현황

Template Variables 활용

하나의 대시보드로 여러 환경/서비스를 전환하며 볼 수 있습니다.

{
  "template_variables": [
    {
      "name": "service",
      "default": "api-gateway",
      "prefix": "service"
    },
    {
      "name": "env",
      "default": "production",
      "prefix": "env"
    },
    {
      "name": "region",
      "default": "us-east-1",
      "prefix": "region"
    }
  ]
}

위젯 쿼리 예시

{
  "requests": [
    {
      "q": "avg:trace.flask.request.duration{env:$env,service:$service} by {resource_name}",
      "display_type": "line",
      "style": {
        "palette": "dog_classic",
        "line_type": "solid",
        "line_width": "normal"
      }
    }
  ]
}

Grafana Dashboard

패널 구성

• Graph: 시계열 차트
• Stat: 단일 값 표시
• Table: 테이블 형식

• Gauge: 게이지 차트
• Alert List: 알림 목록

변수(Variable) 활용

$namespace, $pod, $interval 등을 사용하여 동적 대시보드를 구성합니다.

# Datadog 태그 기반 변수 쿼리
tag:kube_namespace from kubernetes.cpu.usage.total
tag:pod_name from kubernetes.cpu.usage.total{kube_namespace:$namespace}

Datadog 쿼리 예시

# API 요청 성공률
(sum:trace.graphql.server.request.hits{kube_namespace:$namespace}.as_count()
 - sum:trace.graphql.server.request.errors{kube_namespace:$namespace}.as_count())
/ sum:trace.graphql.server.request.hits{kube_namespace:$namespace}.as_count() * 100

# p99 레이턴시
p99:trace.graphql.server.request.duration{kube_namespace:$namespace}

알림 연동

Grafana → Slack/PagerDuty로 알림을 발송합니다.

CloudWatch Dashboard

위젯

• Line: 선 그래프
• Stacked Area: 누적 영역 차트

• Number: 숫자 표시
• Log: 로그 위젯

크로스-계정 대시보드

여러 AWS 계정의 메트릭을 하나의 대시보드에 표시할 수 있습니다.

위젯 JSON 예시

{
  "type": "metric",
  "properties": {
    "metrics": [
      [ "AWS/ApplicationELB", "TargetResponseTime",
        { "stat": "Average" } ],
      [ ".", "HTTPCode_Target_5XX_Count",
        { "stat": "Sum", "yAxis": "right" } ]
    ],
    "period": 300,
    "stat": "Average",
    "region": "us-east-1",
    "title": "ALB Performance"
  }
}

도구별 특징 비교

도구	비용	유연성	학습 곡선	최적 사용처
Datadog	높음	높음	낮음	전체 스택 통합
Grafana	무료	매우 높음	중간	K8s 클러스터
CloudWatch	중간	중간	낮음	AWS 인프라

4

알림(Alert) 설계

대시보드만으로는 부족합니다. 장애가 발생하면 알림이 울려야 합니다. 하지만 너무 많은 알림은 오히려 독이 됩니다.

알림 피로(Alert Fatigue) 문제

평균 엔지니어가 하루 50+개 알림을 받으면 무시하기 시작합니다. 알림이 너무 많으면 정작 중요한 알림을 놓치게 됩니다.

해결 방법

• 알림 정리 주기적 수행 (분기별 리뷰)
• 30일간 action 없는 알림 삭제 또는 재설계
• 알림을 받은 후 실제로 행동한 비율 측정

좋은 알림의 조건

1. Actionable (행동 가능성)

받은 사람이 즉시 할 수 있는 행동이 명확해야 합니다.

2. 충분한 컨텍스트

무엇이, 언제, 얼마나, 어디서, 왜(추정) 발생했는지 포함되어야 합니다.

3. 적절한 심각도

모든 알림이 P1이면 아무것도 P1이 아닙니다.

알림 심각도 체계

Level	설명	대응	예시
P1 Critical	서비스 장애, 매출 영향	즉시 대응 (24/7)	API 전체 다운, DB 장애
P2 High	성능 저하, 일부 기능 영향	업무시간 내 대응	p99 SLO 위반, Replica Lag
P3 Medium	잠재적 문제	다음 스프린트	디스크 70%, 인증서 30일
P4 Low	정보성	참고	배포 완료, 스케일 이벤트

Datadog Monitor 설정 예시

{
  "name": "API Error Rate High",
  "type": "metric alert",
  "query": "avg(last_5m):sum:trace.flask.request.errors{env:production,service:api}.as_count() / sum:trace.flask.request.hits{env:production,service:api}.as_count() > 0.05",
  "message": "{{#is_alert}}
**[P1 CRITICAL] API Error Rate > 5%**

**Current**: {{value}}%
**Service**: {{service.name}}
**Environment**: {{env}}

**Actions**:
- Check APM traces: https://app.datadoghq.com/apm/traces
- Review recent deployments
- Check Runbook: https://wiki.company.com/runbooks/api-errors

@slack-oncall @pagerduty-critical
{{/is_alert}}",
  "tags": ["service:api", "severity:p1"],
  "priority": 1,
  "options": {
    "thresholds": {
      "critical": 0.05,
      "warning": 0.03
    },
    "notify_no_data": true,
    "no_data_timeframe": 10
  }
}

중요: 알림은 적을수록 좋습니다

"모든 것을 알림으로 만들자"는 잘못된 접근입니다. 알림은 즉시 행동이 필요한 것만 설정하세요. 나머지는 대시보드에서 확인하면 됩니다.

5

실전: 서비스 대시보드 구축 워크스루

가상의 이커머스 서비스 "ShopFast"를 위한 대시보드를 설계해봅니다. 이론을 실제 사례에 적용하는 과정을 단계별로 살펴봅니다.

Step 1: 서비스 구조 파악

[사용자] ↓ [Frontend - React SPA] ↓ [API Gateway - Kong] ↓ ├─ [주문 서비스] → RDS (MySQL) ├─ [결제 서비스] → RDS (MySQL) + 외부 PG └─ [재고 서비스] → Redis + RDS

Step 2: L1 Executive 대시보드 설계

임원이 한눈에 보는 전체 서비스 상태

포함 지표

• 전체 가용성 (%) - 지난 30일
• Error Budget 잔여량 (%) - SLO 대비
• 주요 SLO 달성 현황 (주문 성공률, 결제 성공률)
• 현재 활성 장애 수

Step 3: L2 Operational 대시보드 설계

팀 리드와 온콜 엔지니어가 보는 서비스별 상세

포함 지표

• 서비스별 RED 지표 (Rate, Error, Duration)
• DB 커넥션 풀 사용률, IOPS
• K8s Pod 상태 (Running/Pending/Failed)
• 최근 배포 현황 및 영향
• 외부 의존성 상태 (PG API, 3rd party)

Step 4: L3 Detailed 대시보드 설계

장애 대응 엔지니어가 디버깅에 사용하는 상세 정보

포함 지표

• Top Slow Queries (실행 시간 상위 10개)
• 개별 Pod별 CPU/메모리 사용률
• 요청별 트레이스 (APM trace waterfall)
• 에러 로그 스트림 (실시간)
• 네트워크 I/O, 디스크 I/O wait

Step 5: 알림 설계

P1: Critical

• 전체 에러율 > 5% (5분 평균)
• 결제 API 완전 다운 (no data 5분)
• DB Primary 다운

P2: High

• p99 레이턴시 > SLO (200ms)
• DB CPU > 80% (10분 이상)
• Replica Lag > 10초

P3: Medium

• 디스크 사용률 > 70%
• 메모리 사용률 > 75%
• SSL 인증서 만료 30일 전

이 구조의 장점

장애 발생 시 L1 → L2 → L3 순서로 드릴다운하며 원인을 빠르게 특정할 수 있습니다. 임원은 L1만, 팀 리드는 L2까지, 엔지니어는 L3까지 접근하여 각자에게 필요한 정보만 얻습니다. 알림은 심각도별로 분리되어 있어 알림 피로를 최소화합니다.

퀴즈

학습한 내용을 확인해봅시다. 5문제를 모두 풀어보세요.