🔥 Dashboard: 여러 지표를 한 화면에

콘솔 좌측 메뉴에서 Dashboards를 처음 누르면 빈 24열짜리 그리드 한 장이 뜬다. 거기에 위젯을 끌어 놓는 순간부터, CloudWatch란 무엇인가: AWS 모니터링의 중심 도구에서 본 메트릭·로그·알람·이벤트 네 줄을 같은 시간 간격으로 한 화면에 모은다. 그리고 그 정렬이 흔들리는 순간, 다른 계정·다른 statistic·다른 시간 윈도가 끼어드는 곳, 이 그대로 비용과 권한 모델이 나뉘는 분기가 된다.

24열 그리드 위에 위젯을 타일처럼 둔다

Dashboard body는 JSON 한 덩어리다. 최상위 키가 다섯 가지, widgets[](필수), start와 end(시간 윈도를 절대 시각으로 잡고 싶을 때 쓰는 두 키), periodOverride(period 자동 보정 모드), variables[](0~25개의 동적 필터). 위젯 하나가 받는 키도 단순하다. type(metric · text · log · alarm · explorer 다섯 중 하나), x·y(0~23 / 0+ 정수), width·height(기본 6×6, 너비 1~24, 높이 1~1000), 그리고 properties 한 묶음.

여기서 24열이라는 숫자가 모든 레이아웃의 출발이다. 한 행에 두 위젯을 균등하게 깔고 싶다면 width: 12씩 두 개. 세 위젯을 한 줄에 깔고 싶다면 width: 8씩 세 개. 네 위젯이라면 width: 6씩 네 개. 24가 2·3·4·6·8·12로 깨끗하게 나뉘는 수라서 AWS가 이 수를 골랐다는 게 한 화면을 짤 때 가장 자주 쓰는 산수다. 내가 운영용 대시보드를 짜 보면 보통 width: 12, height: 6짜리 시계열 그래프 두 줄(=4개), 그 위에 width: 24, height: 3짜리 단일 number 위젯 한 줄을 깔게 된다. 한 행이 문자 그대로 24칸이고, 그 24칸을 어떻게 잘라 쓰느냐가 시각적 우선순위를 정한다.

한 dashboard 위에 위젯을 몇 개까지 올릴 수 있느냐는 한도는 500이다. 처음 봤을 때 의외로 큰 수다. 한 화면에 100개도 시각적으로 너무 많지만 500개가 의미 있는 경우가 있나 싶어서다. 답은 한 화면이 아니라는 데 있다. dashboardBody는 위에서 아래로 무한 스크롤이고, 위젯 y는 0 이상 어떤 정수든 가능하다. 그래서 SaaS 운영팀이 한 dashboard에 100개 넘는 위젯을 깔아 두고 카테고리별 섹션을 만드는 운영 방식이 종종 등장한다. text 위젯(width: 24)을 헤더로 깔고 그 아래 메트릭 위젯들을 묶는 식이다. 다만 그 순간부터 다른 비용이 같이 자란다, 뒤에서 짚는다.

variables[]는 0~25개. dashboard 한 장 안에서 사용자가 드롭다운·라디오·인풋으로 값을 바꿀 수 있는 동적 필터다. 예를 들어 region이라는 변수에 us-east-1/ap-northeast-2/eu-west-1 세 값을 select 형태으로 깔아 두면, 같은 위젯 묶음을 세 리전에 대해 한 클릭으로 전환할 수 있다. 25개라는 한도가 어느 정도냐 하면, 운영팀 한 곳이 평균 3~5개로 충분하다는 뜻이다. 25는 dashboard 하나가 갖고 있는 컨텍스트 차원 수의 상한 정도로 보면 된다.

위젯 다섯 종류가 같은 시간축을 공유한다

type 다섯 가지가 이 그리드 위에 올라가는 모든 위젯이다.

• metric, 메트릭 시계열 그래프 / 단일 number / bar / pie / gauge / table. 가장 많이 쓰이는 위젯이고, Metric: 숫자 하나가 찍히는 과정에서 본 namespace × MetricName × dimensions 좌표를 그대로 입력으로 가져온다.
• text, 마크다운 텍스트. 헤더, 메모, 운영 가이드 줄을 끼우는 용도.
• log, Logs Insights 쿼리 결과를 표 형태로. Logs Insights: 로그에 쿼리를 발행하는 법에서 본 그 쿼리가 dashboard에 올라가면 언제 다시 실행되는지를 자동 새로고침 주기가 결정한다.
• alarm, 알람 한 개의 상태(OK / ALARM / INSUFFICIENT_DATA)를 도트로 보여 주거나, 알람 묶음의 trend를 보여준다. Alarm: 임계값을 걸고 알림을 받는 법에서 본 임계값과 M-of-N 윈도가 만들어 낸 그 상태가 화면 한구석에 작은 도트로 표시되는 위젯이다.
• explorer, 태그·dimension 기반으로 여러 리소스의 같은 메트릭을 한 위젯에서 그리드로 보여 준다. EC2 인스턴스 50개의 CPUUtilization을 한 화면에 작은 카드 50장으로 깔아 놓는 식.

다섯이 서로 다른 데이터 형태를 입력으로 가져온다. metric은 좌표, log는 쿼리 결과, alarm은 상태 enum, text는 정적 마크다운, explorer는 태그-dimension 매핑. 그런데 화면 위에서는 dashboard 상단의 시간 선택기 하나가 metric, log, alarm history, explorer 네 종류를 한꺼번에 같은 윈도로 좁힌다. 6시간을 가리키면 네 종류가 다 6시간이고, 일주일을 가리키면 다 일주일이다. 이게 dashboard가 다른 도구와 다른 핵심이다. 시간 선택기 한 번이 네 종류 데이터의 시점을 동시에 결정한다.

운영 시그널 한 가지는 text 위젯에서 나온다. 운영 가이드 한 줄을 위젯에 통째로 옮겨 두고 싶은 충동이 자주 생기지만, 위젯이 길어질수록 콘솔 안에서 다른 위젯 공간을 잡아먹는다. 한 번은 내가 runbook 전체를 위젯에 옮겨 적었다가 dashboard 절반이 텍스트로 도배된 걸 본 적이 있다. text 위젯은 헤더 한 줄이나 어디로 가야 더 자세한 자료가 있는지 알려 주는 링크 한 줄까지가 어울리는 정도다. 그 이상은 README나 runbook URL로 보낸다.

periodOverride, 시간 윈도가 길어지면 디테일이 자동으로 없다

지금까지는 위젯이 어디에 놓이는지를 봤다. periodOverride는 위젯이 어떤 단위로 집계되는지를 시간 윈도와 같이 정한다.

옵션은 두 가지다, auto(시간 범위에 맞춰 모든 위젯의 period가 자동 조정)와 inherit(각 위젯의 period 그대로 유지). 왜 두 가지로 충분하냐면, dashboard라는 화면이 결국 두 결정 중 하나로 갈리기 때문이다, 시간 윈도가 길어지면 디테일을 자동으로 줄일 것인가, 위젯 정의를 그대로 둘 것인가. auto로 두면 긴 윈도를 펼칠 때 위젯이 정한 짧은 period가 자동으로 더 긴 단위로 둔갑한다. 일주일 윈도에서 1분 period 위젯이 1시간 단위로 다운샘플링되는 식이다.

이 규칙이 청구서가 아니라 운영의 가독성과 직접 연결한다. 1초 high-resolution 메트릭(StorageResolution=1)을 일주일 윈도로 끌어다 보면 화면에 60만 점이 깔려야 하는데, 그 그래프는 사람 눈으로 읽히지 않는다. CloudWatch가 auto로 더 긴 단위 다운샘플링을 강제해서 화면이 읽힐 만큼 점 수를 적게 낸다. 디테일을 살리고 싶으면 윈도를 좁혀서 다시 보면 된다.

내가 평소 쓰는 운영용 dashboard에서는 inherit로 두는 게 맞았다. 운영팀이 만든 위젯의 period: 60(1분)이 일주일 보기에서 1시간으로 자동으로 둔갑하면 '왜 갑자기 그래프가 둔하냐' 하는 혼란이 생긴다. inherit로 두면 위젯 정의가 시간 선택기와 독립적으로 산다. 다만 inherit + 긴 윈도 + 1초 해상도 조합은 점이 너무 많아져 콘솔 로딩이 더 느리다는 대가가 따른다. 어디까지 가독성을 우선하고 어디서부터 로딩 시간을 절충할지 한 번 정해 두면 다음 dashboard도 같은 형태으로 짤 수 있다.

자동 새로고침 주기는 다섯 단계, 10초 / 1분 / 2분 / 5분 / 15분, 와 함께 Off(자동 새로고침 끄기) 옵션이 메뉴에 같이 있다. 새로고침을 아예 멈춰 두고 사용자가 수동으로만 reload하는 모드도 가능하다. 새로고침이 살아 있는 동안에는 위젯들이 GetMetricData·Logs Insights 같은 데이터 fetch API를 주기마다 호출하는데, 그 호출이 청구서에 어떻게 잡히는지가 다음 단락이다.

비용, $3 dashboard 한 줄이 끝이 아니다

dashboard 자체의 가격은 한 줄로 정해져 있다. 매월 3개의 사용자 정의 dashboard까지 무료, 단, 한 dashboard당 메트릭이 50개 이하인 경우에 한해서. 그 너머는 한 장당 월 $3 (메트릭 50개 이하인 Basic 등급, 청구 라인 코드는 DashboardsUsageHour-Basic). 메트릭이 50개를 넘는 dashboard는 더 높은 단가의 DashboardsUsageHour 라인으로 잡는다. AWS가 자동으로 만들어 주는 Automatic Dashboards는 항상 무료. 시간 단위 pro-rate라 한 달 중 보름만 살아 있던 dashboard는 $1.50으로 청구한다.

내가 처음 봤을 때 $3가 작은 수다. 그래서 dashboard를 잘게 쪼개 30개를 만든다고 가정한다, 27개가 유료 = 월 $81 = 한 해 약 $972, 작지 않다. CloudWatch란 무엇인가: AWS 모니터링의 중심 도구에서 무료 한도를 메트릭·로그·알람으로만 기억하기 쉬운데, 대시보드 3장도 같은 무료 한도 안에 들어 있다는 걸 같이 짚어 두면 청구서가 자라기 시작할 때 한 번 더 멈출 수 있다.

청구서가 자라는 곳이 dashboard 자체보다 dashboard가 부르는 데이터 API 쪽일 거라고 짐작하기 쉽다. AWS는 정반대로 잘라 두었다. dashboard 자동 새로고침이 부르는 GetMetricData 호출은 과금되지 않는다. 공식 docs가 정확히 명시한다, "GetMetricData calls initiated by CloudWatch dashboards to refresh widget data ... These API calls do not incur CloudWatch charges." 콘솔 탭을 24시간 열어 두고 10초 주기로 돌려도, dashboard가 부르는 그 GetMetricData는 청구서에 안 잡는다. 같은 면제는 cross-account dashboard에도 적용한다, 모니터링 계정이 source 계정 데이터를 dashboard로 끌어 올 때 부르는 GetMetricData도 면제다.

이게 처음 봤을 때 의외다. CloudWatch pricing 페이지에는 GetMetricData·GetInsightRuleReport·GetMetricWidgetImage 세 API가 무료 한도 1M API 호출에 포함되지 않는다고 명시돼 있어서, 자연스럽게 '그러면 dashboard가 부르는 것도 다 과금되겠지'라고 생각하기 쉽다. 답은 호출자가 누구냐에 따라 다르다. dashboard가 부른 GetMetricData는 면제, 외부 코드(SDK · CLI · 3rd-party 도구)가 부른 GetMetricData는 메트릭 1,000개당 $0.01로 첫 호출부터 과금. 같은 API, 같은 단가인데 청구서가 호출 출처에 따라 다르다.

worked example 한 줄, Grafana 같은 외부 도구가 dashboard에 묶인 메트릭 50개를 분당 한 번씩 GetMetricData로 끌어 온다고 가정한다. GetMetricData는 한 호출에 최대 500개 metric query를 묶을 수 있어서, 50개라면 보통 한 호출 안에 다 들어간다. 단가는 호출이 아니라 metric 수로 계산되니까 한 번에 묶었든 따로 호출했든 결과가 비슷하다. 한 시간에 50 × 60 = 3,000 metric, 한 달 30일이면 약 216만 metric. 1,000으로 나누고 $0.01을 곱하면 월 약 $21.60(첫 1M 무료 한도 흡수 후). 같은 dashboard를 콘솔에서 본 청구는 $3, 같은 데이터를 Grafana에서 끌어서 받는 청구는 약 $21~$22, 일곱 배쯤 차이가 난다. 같은 데이터를 어디서 보느냐가 비용을 구분한다.

운영팀이 자주 놓치는 한 가지, NOC 모니터 벽 dashboard를 콘솔에서 띄워 두면 자동 새로고침 GetMetricData가 면제로 잡는다. 24시간 켜 둬도 청구서 추가 비용이 없다. 비용은 외부 도구가 같은 메트릭을 또 한 번 끌어 오는 순간부터 자란다. dashboard를 콘솔에서만 보는지, Grafana 같은 외부 도구로 같은 데이터를 또 한 번 보내는지에 따라 한 달 청구에 일곱 배쯤 차이가 생긴다.

다른 계정 데이터를 한 화면에: 두 길이 다르다

여기까지가 한 계정 안의 dashboard 이야기다. 다른 계정의 메트릭·로그·알람을 같은 화면에서 보고 싶어지는 순간이 곧 온다. 회사가 prod / staging / dev 세 계정을 운영하면 각 계정이 자기 CloudWatch에 데이터를 쌓고, 운영자는 셋을 동시에 보고 싶어한다.

AWS는 이 문제에 두 길을 나누어 두었다, 2019년 11월에 나온 Cross-Account Cross-Region Dashboard와 2022년 11월 27일 re:Invent에서 발표된 CloudWatch Cross-Account Observability via OAM. 같은 문제를 두 메커니즘으로 풀고, 권한 모델·범위·운영 모델이 전부 다르다.

길 A, Sharing Role (2019-11). 데이터를 공유하려는 계정마다 CloudWatch-CrossAccountSharingRole이라는 IAM Role을 만든다. 이 role은 모니터링 계정에 AssumeRole을 허용하고, 자기 자신에게는 CloudWatchReadOnlyAccess(필수)에 옵션으로 CloudWatchAutomaticDashboardsAccess(자동 dashboard용)와 AWSXrayReadOnlyAccess(트레이스 맵용) 같은 추가 정책을 붙이는 구조다. 모니터링 계정의 콘솔에서 Settings → View cross-account cross-region → Enable을 켜면, 그 role을 거쳐 다른 계정의 메트릭과 알람을 dashboard 위젯에 그릴 수 있다. 읽기 전용 콘솔 토글이 정확한 구조다. CloudFormation 템플릿이 콘솔에서 한 번에 들어선다는 점이 운영의 시작점이다.

이 길의 한계가 두 가지. 첫째, 매 source 계정마다 role을 따로 깔아야 한다, 100개 계정이면 100번. 둘째, 기본으로 흘러오는 데이터가 메트릭·알람·자동 dashboard 중심이고, X-Ray 트레이스 맵이나 Database Insights 같은 추가 telemetry는 같은 role에 정책을 더 붙여서 별도로 켜는 구조다. telemetry 한 묶음을 한 번에 끌어오는 모델이 아니라, 원하는 데이터마다 정책 한 줄을 더 붙여서 켜는 모델이라는 뜻이다. 그래서 회사가 multi-account observability를 진지하게 운영하기 시작하면 곧 이 한계가 드러난다.

길 B, OAM (Observability Access Manager, 2022-11-27). 이 길에서 나온 답이 모니터링 계정에 Sink 한 개, 각 source 계정에 Link 한 개를 만들고, 둘 사이를 한 번 묶어 두면 그 다음부터는 메트릭·로그·X-Ray 트레이스·Application Signals·Application Insights·Internet Monitor, 6종 telemetry가 한 번에 같이 흘러간다는 구조다. 모니터링 계정의 콘솔에서 source 계정의 데이터를 원래 자기 계정 데이터처럼 검색·시각화한다. 한 계정의 dashboard에서 다른 계정의 LogGroup을 그대로 쿼리하는 식이다.

OAM의 한도가 두 가지, 한 모니터링 계정이 받을 수 있는 source 계정 수가 100,000, 한 source 계정이 보낼 수 있는 모니터링 계정 수가 5다. 100,000은 사실상 한도가 아니라고 봐도 되는 수다. 5는 운영팀·보안팀·재무팀·SRE팀처럼 같은 데이터를 여러 시각으로 보고 싶을 때 충분한 수다. AWS Organizations와도 통합돼서, source 계정을 개별 ID 대신 OU(Organizational Unit)나 organization path로 한 번에 묶을 수 있다.

worked example 한 줄, 회사가 prod 1개, staging 1개, dev 5개 = 7개 계정을 운영한다고 가정한다. 길 A는 7번 role 생성 + 7번 CloudFormation deploy, 그리고 메트릭·알람 외에 트레이스 맵이나 Application Insights 같은 다른 telemetry를 같이 보고 싶다면 각 source 계정의 role마다 정책을 추가로 붙이는 7번이 더 든다. 길 B는 모니터링 계정에 sink 한 개 + 7개 source 계정에 link 한 개씩 = 8개 OAM 리소스 + 6종 telemetry가 한 번에. AWS Organizations로 묶여 있다면 link 7개를 organization path 한 줄로 한 번에 깐다. 운영 부담의 차이가 여기서 나뉜다.

다만 OAM은 cross-region을 직접 지원하지 않는다. 같은 region 안에서만 sink와 link가 짝을 짓는다. 다른 region 데이터를 같이 보고 싶다면 길 A의 cross-region 콘솔 토글과 길 B의 OAM을 함께 운영하는 결정이 필요하다. AWS가 이 부분만은 깔끔하게 통합하지 않았다, 두 메커니즘이 한 운영팀의 결정을 둘로 구분한다.

권한 모델도 다르다. 길 A는 Policy 평가 흐름, Allow와 Deny가 만나면에서 본 Identity-based × Resource-based union(same-account)·intersection(cross-account) 모델 위에서 AssumeRole을 거친다. 길 B는 OAM 자체의 sink/link API, oam:CreateSink, oam:CreateLink, cloudwatch:Link, cloudwatch:Sink, 가 별개의 권한 묶음으로 평가한다. 그래서 보안팀이 cross-account observability를 검토할 때 둘 중 어느 길로 갔느냐가 검토 항목 자체를 바꾼다.

언제 dashboard를 쓰지 말아야 하는가

dashboard는 좋은 도구지만 모든 관측 화면은 아니다. 내가 회사에서 dashboard를 쓰면서 가장 자주 마주친 한 가지 오해가, dashboard를 실시간 알림 도구처럼 쓰려는 욕심이다. 새로고침을 10초로 줄이고, 화면을 항상 켜 두고, 빨간 줄이 뜨면 사람이 알아채길 기대한다. 내 경험으로 이 길이 잘 안 된다.

이유가 한 가지로 충분하다. 내가 직접 NOC 화면 앞에서 다른 일을 하다가 빨개진 위젯을 5분 뒤에야 알아챈 적이 있다. 화면이 켜져 있는 것과 사람이 그 화면을 보고 있는 것은 다르다. 1초 전에 빨개졌어도 사람이 키보드를 두드리고 있으면 그 1초는 그냥 놓친 1초다. 이런 경우는 dashboard가 아니라 Alarm: 임계값을 걸고 알림을 받는 법에서 본 알람 + SNS + AWS Chatbot/Amazon Q Developer로 Slack 채널에 능동적으로 알림이 가는 게 맞다. 알람이 능동적으로 알림을 보내는 도구이고, dashboard가 장애 알림 전달을 대체하지 않는다는 점은 같은 글에서 이미 짚어 두었다.

또 하나, 깊은 분석이다. dashboard 위젯은 메트릭을 평균·합계·percentile 같은 고정된 statistic으로만 본다. 어떤 시간 사이에 outlier가 어디서 왔는지 같은 깊은 분석은 Logs Insights: 로그에 쿼리를 발행하는 법나 OpenSearch, 또는 Grafana / Datadog 같은 외부 도구가 더 맞는 도구다. dashboard는 하루에 한 번 훑어보는 도구다, 어제와 달라진 곳이 있는지 5초 안에 확인하는 화면. 그 이상으로 쓰면 dashboard가 다른 도구의 일을 어색하게 흉내내는 셈이 된다.

그래서 내가 정한 운영 규칙 한 줄, Dashboard는 5초 안에 '오늘이 평소와 같은가'를 확인하는 도구다. 이상이 보이면 그 다음 도구로 넘어간다. 새로고침은 5분이 기본, NOC 화면용은 1분, 그 이하로는 거의 내려가지 않는다. cross-account가 필요하면 OAM을 먼저 본다, 길 A는 마이그레이션이 어려운 레거시 환경에서만. periodOverride는 inherit 기본, 위젯 정의가 시간 선택기와 독립적으로 살아야 운영팀이 계속 같은 그래프를 본다.

대시보드는 메트릭·로그·알람·이벤트 네 줄을 같은 시간 간격에 묶어 한 화면에 보여 주는 도구다. 그 이상으로 쓰면 알람이 해야 할 일을 어색하게 흉내내고, 그 이하로 쓰면 무료 3장이 줄 수 있는 일상의 5초를 놓친다. 운영팀이 매주 한 번씩 같이 짚는 dashboard 한 장이, 그것도 무료 한도 안에서, 한 분기 운영 회의의 절반을 줄여 준다는 점이 이번에 다시 확인한 결과다.

참고 자료

• Dashboard Body Structure (CloudWatch API Reference), 24열 그리드, 다섯 최상위 키, 위젯 5종 type, x/y/width/height 한도, variables 0~25
• Refresh and periodOverride, auto/inherit 두 옵션, 자동 새로고침 5단계 + Off
• CloudWatch billing, DashboardsUsageHour-Basic 라인 코드, dashboard 자동 새로고침 GetMetricData 면제 명시
• CloudWatch pricing, 첫 3 dashboard 무료, $3/dashboard/month, GetMetricData $0.01/1,000 metrics
• GetMetricData API Reference, 한 호출 최대 500 metric query 배치
• Cross-Account Cross-Region console (CloudWatch User Guide), Sharing Role 메커니즘, CloudFormation 템플릿
• What's New: Cross-Account Cross-Region Dashboards (2019-11), 길 A 출시 공식 발표
• AWS News Blog: CloudWatch Cross-Account Observability (2022-11-27), 길 B(OAM) GA 발표
• CloudWatch Cross-Account Observability User Guide, Sink/Link 모델, 6종 telemetry, region 제약, source 100,000 / monitoring 5 한도
• Managed policies for CloudWatch, CloudWatchReadOnlyAccess, CloudWatchAutomaticDashboardsAccess