CloudOps Archive

CKA (Certified Kubernetes Administrator) 자격증 취득 후기

PARK SEJIN — Thu, 7 May 2026 21:34:06 +0900

CKA (Certified Kubernetes Administrator) 자격증 취득 후기

Kubernetes CKA

취득 배경

시간이 좀 지났지만 CKA 자격증 후기를 한 번 작성해보겠습니다.

부트캠프를 다니면서 Kubernetes에 관심을 많이 가지게 됐는데 프로젝트에서 EKS와 GKE를 사용하다 보니 면접에서도 Kubernetes 관련 기술 질문이 꽤 나왔습니다. 솔직히 제대로 답을 못한 것 같습니다.

그래서 강의만 보고 넘어가는게 아니라 자격증까지 노려서 확실히 공부하자는 마음으로 시작했습니다.

자격증을 알아보니 CKAD, CKA, CKS가 대표적인데 CKS는 CKA가 있어야 지원 자격이 주어지기 때문에 CKA를 먼저 준비하게 됐습니다.

취득 과정

공부 방법은 크게 네 가지였습니다.

1. 유데미 강의

유데미에서 뭄샤드(Mumshad Mannambeth)의 CKA 강의를 들었습니다. CKA 준비할 때 가장 많이 추천되는 강사라서 선택했고 기본적인 내용을 잘 담고 있어서 열심히 봤습니다.

Certified Kubernetes Administrator (CKA) with Practice Tests

CKA Certification Course – Certified Kubernetes AdministratorKubernetes is one of the highest trending technology in Cloud Computing as of today. Kubernetes had the fastest growth in job searches, over 173% from a year before,

www.udemy.com

다만 한글 자막이 가끔 이상하게 번역되어 있는 부분이 있으니 참고하시는 게 좋을 것 같습니다.

2. Reddit 활용

Reddit의 CKA 관련 커뮤니티에서 최근 어떤 유형의 문제가 나오는지 동향을 살펴봤습니다. 시험 트렌드를 파악하기 좋아서 틈틈이 참고했습니다.

Reddit의 CKAExam 커뮤니티

CKAExam 커뮤니티에서 이 게시물을 비롯한 다양한 콘텐츠를 살펴보세요

www.reddit.com

3. KillerCoda 실습

Killercoda에 CKAD, CKA, CKS 문제 시나리오들이 올라와 있습니다. 이걸 토대로 공부하고 Playground에 가서 CKA 문제를 git clone해서 직접 풀어봤습니다.

CKA Certified Kubernetes Administrator | Killercoda

Scenarios for CKA Certified Kubernetes Administrator

killercoda.com

실제 시험 환경과 비슷하게 터미널에서 직접 작업하는 연습이 되니까 꼭 해보시는 걸 추천합니다.

4. 유튜브 강의

외국 유튜브 강의도 참고했습니다. 저는 Jaydemy와 IT Kiddie 채널을 봤는데 문제 풀이 영상이 실전 감각을 잡는 데 도움이 됐습니다.

공부하는 데 총 1달 정도 걸린 것 같습니다.

IT Kiddie

Welcome to IT Kiddie, Your DevOps Hub! Dive into the world of modern DevOps with in-depth tutorials, hands-on demos, and real-world insights on tools and technologies like Kubernetes, AWS, Linux, GCP, and more. Whether you're just starting your DevOps

www.youtube.com

JayDemy

E-learning platform on Linux, AWS Cloud with DevOps and Real CKA exam questions series

www.youtube.com

덤프만 풀어도 합격 자체는 가능할 수 있지만 저의 최종 목표는 Kubernetes를 어느 정도 이해하는 데 초점이 맞춰져 있었기 때문에 강의를 전부 다 들었습니다.

시험 후기

시험은 온라인으로 봤고 여권으로 본인 인증을 했습니다.

주변을 웹캠으로 전부 보여줘야 해서 시간이 좀 걸렸습니다. 시험 전에 미리 책상 정리하고 모니터 뒤쪽까지 깔끔하게 해두시는 걸 추천합니다.

문제 형식 자체는 유튜브에 나오는 것과 거의 동일하니까 조금만 투자하면 충분히 취득할만 한 것 같습니다. 그런데도 불구하고 2시간을 꽉 채워서 시험을 봤으니 시간 분배를 잘하시는 게 중요합니다.

그리고 시험이 전부 영어로 진행됩니다. 문제 자체가 어려운 영어는 아니지만 헷갈릴 수 있으니 기본적인 영어 독해는 준비하고 가시는 게 좋을 것 같습니다.

시험 문제

총 16문제로 진행됐습니다. 제가 봤던 문제 유형을 정리하면 다음과 같습니다.

No.	문제 유형
1	Helm을 사용하여 ArgoCD 설치 / `helm template`으로 특정 위치에 파일 생성 및 저장
2	기존 Deployment에 sidecar 컨테이너를 추가하여 로그 남기기
3	Service에 맞춰서 Ingress 생성
4	기존 Ingress를 Gateway와 HTTPRoute로 마이그레이션
5	Deployment의 replicas 3개 상태에서 각 Pod에 memory, cpu 리소스 분배
6	StorageClass 생성 후 Deployment에 연결
7	PriorityClass를 사용하여 Deployment에 연결
8	front-end와 back-end Pod가 있는 상태에서, 생성되어 있는 NetworkPolicy 3개 중 하나를 골라 적용
9	HPA 생성 후 Deployment와 연결
10	조건에 맞는 CNI를 골라 `kubectl create -f`로 생성
11	cri-docker 생성 후 conf 파일 설정
12	특정 Pod를 `kubectl expose`하여 Service와 연결
13	Secret 파일 수정 후 TLS v1.2 추가
14	`/etc/kubernetes/manifests` 내 `kube-apiserver.yaml` 파일에서 잘못된 부분을 찾아 트러블슈팅
15	`kubectl get crd -A`로 특정 이름이 포함된 항목을 추출하여 파일 저장 / `kubectl explain`으로 특정 필드를 확인하여 파일 저장
16	PVC 생성 후 Deployment에 claimName 설정

시험 결과

합격했습니다.

시험 치고 딱 24시간 정도 걸려서 결과가 나왔습니다. 메일로 뱃지와 PDF 파일이 함께 날아옵니다.

PDF 파일은 회사 제출용으로 쓸 수 있으니 꼭 저장해두세요.

앞으로의 계획

회사 입사일이 코앞이라 CKAD까지만 따고 SAP(Solutions Architect - Professional)로 넘어갈 예정입니다.

CKS는 입사 후 여유가 생기면 도전할 계획이고, 개인적으로는 Kubestronaut 칭호를 따는 게 최종 목표입니다.

AWS Solution Architect - Associate (SAA-C03) 취득 후기

PARK SEJIN — Thu, 7 May 2026 15:51:17 +0900

AWS Solutions Architect - Associate (SAA-C03) 자격증 취득 후기

AWS SAA-C03 Solutions Architect

취득 배경

이번에 AWS Solutions Architect - Associate 자격증을 따게 됐습니다.

클라우드 엔지니어 부트캠프에서 SAA 시험비를 지원해줘서 도전하게 됐고 추후 클라우드 엔지니어로 취업하려면 기본적인 자격증은 있어야 한다고 생각했습니다.

근데 제일 큰 이유는 따로 있었습니다.

프로젝트를 할 때 리딩할 사람이 필요했는데 AWS 서비스에 대한 이해도가 높은 사람이 필요했습니다. 비전공자 팀원도 있다 보니 그냥 제가 먼저 따서 정리한 내용을 팀원들과 공유하자는 마음으로 시작하게 됐습니다.

부트캠프의 단점이라고 하면 본인이 직접 설계하고 구축했다고 해도 기본적인 서비스 이해도가 없으면 발표 때 Q&A에서 제대로 대답을 못한다고 생각했습니다. 그리고 나중에 포트폴리오를 만들어서 면접에 간다고 해도 제대로 설명을 못할 게 뻔했습니다.

솔직히 신입이 부트캠프에서 배운 걸로 얼마나 잘할까요.. 이 정도 자격증이라도 있어야 "그래도 놀진 않았구나" 하면서 서류 통과가 될 거라고 생각했습니다.

취득 과정

공부 방법은 크게 두 가지였습니다.

1. 유데미 강의

유데미에서 유명한 Stephane Maarek의 SAA 강의를 들었습니다. 자주 할인하길래 2만원 정도에 사서 봤는데 강의 시간이 길긴 하지만 내용이 알차서 돈이 아깝지 않았습니다.

【한글자막】 AWS Certified Solutions Architect Associate시험합격! 2025

[2023년 3월]: AWS UI 변경 및 시험 내용 변경에 맞춰 강의 내용이 업데이트 되었습니다! (SAA-C03) <ul><li>AWS 초보도 학습할 수 있는 친절한 강의!<

www.udemy.com

강의에서 나온 내용은 노션에 정리해서 주기적으로 복습했습니다.

2. 덤프 문제 풀기

덤프 문제는 같이 부트캠프를 하시는 분이 가지고 있는 자료를 사용했습니다.

그리고 따로 찾아본 블로그가 하나 있는데 매주 문제를 몇 개씩 올려주셔서 풀어봤습니다. 밑에 해설도 있어서 도움이 많이 됐습니다.

N(e)xtCloud

Cloud/Msp/AWS 및 Big Data에 빠져삽니다.

pacloud.tistory.com

부트캠프 다니면서 저녁에 공부한 거라 총 1달 정도 걸린 것 같습니다.

시험 후기

시험은 오프라인으로 봤습니다. 온라인으로 보면 애로사항이 많을 것 같아서 직접 가는 쪽을 선택했습니다.

구로에서 시험을 봤고 시험 시간이 2시간이 넘다 보니 화장실은 미리 가시는 걸 추천합니다. 준비물은 여권만 들고 갔고 따로 필요한 건 없었습니다.

시험 문제는 덤프와 비슷한 유형이었지만 아예 똑같은 문제는 20~30%도 안 됐습니다. 그러니까 이론적인 부분을 잘 숙지해서 가실 필요가 있습니다.

물론 덤프만 계속 풀어도 합격 자체는 가능할 수 있지만 나중에 면접에서 제대로 알지 못해서 헛소리하는 것보다는 차라리 강의를 끝까지 보고 확실히 이해하고 있는 게 편합니다.

그리고 지금 Solutions Architect - Professional을 공부 중인데 SAA에서 다뤘던 내용이 더 고도화돼서 나옵니다. 덤프만 주구장창 풀어서 합격한다고 한들 이론을 모르면 SAP 문제를 제대로 풀 수가 없을 것 같습니다.

시험 결과

합격했습니다.

시험 치고 다음날 오후 8시 넘어서 합격 문자가 날아왔습니다. 합격하면 메일로 뱃지와 PDF 파일이 함께 옵니다.

PDF 파일은 나중에 회사에 제출할 일이 있으니 잘 저장해두세요.

앞으로의 계획

현재 Solutions Architect - Professional을 공부 중에 있습니다.

지금 MSP 회사로 입사 예정인데 회사에서 AWS 자격증 시험 비용을 지원해줘서 SAP과 DOP 자격증도 딸 계획입니다.

그리고 최근 CKAD 자격증 시험을 봤는데 그 후기와 함께 CKA 자격증도 미리 따놔서 관련 블로그 글도 작성할 예정입니다.

AWS CUR 기반 비용 시각화 파이프라인 구현

PARK SEJIN — Mon, 4 May 2026 21:53:05 +0900

AWS CUR 기반 비용 시각화 파이프라인 구현

리소스 사용 증가나 예상치 못한 비용 폭증을 빠르게 감지하기 위해
AWS CUR → S3 → Glue → Athena → Grafana로 이어지는 비용 시각화 파이프라인을 구축한 과정을 정리

AWS CUR S3 Glue Crawler Athena Grafana IAM Role

1. 왜 비용 시각화 파이프라인이 필요한가?

AWS 콘솔의 Billing Dashboard나 Cost Explorer도 비용 확인에 쓸 수 있지만 몇 가지 한계가 있습니다.

갱신 지연 — Cost Explorer는 최대 24~48시간 지연이 발생할 수 있어 당일 비용 급증을 즉시 파악하기 어렵습니다.
커스텀 대시보드 한계 — 리소스별 비용 분포, 일별 누적 추이 등을 원하는 형태로 조합하려면 별도 시각화 도구가 필요합니다.
운영 대시보드와의 통합 — 인프라 모니터링(Prometheus + Grafana)과 비용 모니터링을 하나의 Grafana에서 함께 보면 운영 판단이 훨씬 빨라집니다.

이런 이유로 AWS CUR(Cost and Usage Report)을 데이터 소스로 활용하고 Glue + Athena로 쿼리 가능한 상태를 만든 뒤 Grafana로 시각화하는 파이프라인을 설계했습니다.

2. 파이프라인 아키텍처

전체 데이터 흐름은 다음과 같습니다.

구성 요소	역할
AWS CUR	매일 00:00에 계정의 전체 비용·사용량 데이터를 CSV/Parquet 형식으로 생성
S3	CUR 리포트 원본 파일을 저장하는 데이터 레이크 역할
Glue Crawler	S3에 저장된 CUR 파일을 크롤링하여 테이블 스키마를 자동으로 추출·갱신
Athena	Glue 카탈로그 기반으로 S3 데이터를 SQL로 쿼리 (서버리스)
Grafana	Athena를 데이터소스로 연결하여 비용 대시보드 시각화

3. 구축 과정

3-1. CUR(Cost and Usage Report) 설정

AWS Billing 콘솔에서 CUR을 생성합니다.

Report name — 식별 가능한 이름 지정 (예: daily-cost-report)
Time granularity — Daily (일별 비용 추이 확인 목적)
Report data integration — Amazon Athena 선택 (Parquet 포맷 + Athena 통합 자동 구성)
S3 bucket — 리포트가 저장될 전용 버킷 지정

Athena 통합을 선택하면
CUR이 Parquet 포맷으로 생성되고 S3 경로에 Athena용 CloudFormation 템플릿(crawler-cfn.yml)이 함께 제공됩니다. 이 템플릿을 활용하면 Glue Crawler와 데이터베이스를 자동으로 구성할 수 있습니다.

CUR은 설정 후 첫 리포트가 생성되기까지 최대 24시간이 소요될 수 있습니다.

이후부터는 매일 00:00(KST)에 자동으로 S3에 새 데이터가 적재됩니다.

3-2. S3 버킷 구조

CUR이 S3에 저장되면 아래와 같은 경로 구조가 만들어집니다.

s3://<BUCKET_NAME>/<PREFIX>/<REPORT_NAME>/
  ├── <REPORT_NAME>-00001.snappy.parquet
  ├── <REPORT_NAME>-00002.snappy.parquet
  ├── ...
  └── crawler-cfn.yml

Parquet 포맷은 CSV 대비 파일 크기가 작고 Athena 쿼리 성능이 훨씬 빠릅니다.

비용 데이터가 누적되면 스캔량 차이가 곧 Athena 비용 차이로 이어지므로 Parquet 선택을 권장합니다.

3-3. Glue Crawler 설정

Glue Crawler가 S3의 CUR 데이터를 크롤링하여 Athena에서 쿼리 가능한 테이블을 생성합니다.

Data source — CUR이 저장된 S3 경로 지정
Database — Athena에서 사용할 데이터베이스 이름 지정 (예: cur_database)
Schedule — CUR 갱신 주기에 맞춰 일 1회 실행 (예: 매일 01:00 KST, CUR 생성 후 1시간 여유)

Crawler가 실행되면 S3의 Parquet 파일 구조를 분석해서 컬럼명, 데이터 타입 등의 스키마를 자동으로 Glue Data Catalog에 등록합니다.

이후 CUR 구조가 변경되더라도 Crawler가 재실행되면 스키마가 자동으로 갱신됩니다.

3-4. Athena 쿼리 확인

Glue Crawler가 정상 실행되면 Athena 콘솔에서 바로 SQL 쿼리를 실행할 수 있습니다.

-- 일별 총 비용 확인
SELECT
  DATE(line_item_usage_start_date) AS usage_date,
  ROUND(SUM(line_item_unblended_cost), 2) AS daily_cost
FROM cur_database.cost_report
WHERE line_item_line_item_type = 'Usage'
GROUP BY DATE(line_item_usage_start_date)
ORDER BY usage_date DESC
LIMIT 30;

-- 리소스(서비스)별 비용 분포
SELECT
  line_item_product_code AS service,
  ROUND(SUM(line_item_unblended_cost), 2) AS total_cost
FROM cur_database.cost_report
WHERE line_item_line_item_type = 'Usage'
  AND DATE(line_item_usage_start_date) = CURRENT_DATE - INTERVAL '1' DAY
GROUP BY line_item_product_code
ORDER BY total_cost DESC;

✅ Athena 비용 팁
Athena는 스캔한 데이터량 기준으로 과금됩니다(1TB당 $5)
Parquet 포맷을 사용하면 필요한 컬럼만 읽어 스캔량을 대폭 줄일 수 있고 WHERE 절로 날짜 범위를 제한하면 추가로 비용을 절감할 수 있습니다.

3-5. IAM Role 생성 및 Grafana 연동

Grafana에서 Athena 데이터소스에 접근하려면 적절한 권한을 가진 IAM Role이 필요합니다.

IAM Policy 주요 권한:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "athena:GetQueryExecution",
        "athena:GetQueryResults",
        "athena:StartQueryExecution",
        "athena:StopQueryExecution"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "glue:GetTable",
        "glue:GetDatabase",
        "glue:GetPartitions"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::<CUR_BUCKET_NAME>",
        "arn:aws:s3:::<CUR_BUCKET_NAME>/*",
        "arn:aws:s3:::<ATHENA_RESULTS_BUCKET>",
        "arn:aws:s3:::<ATHENA_RESULTS_BUCKET>/*"
      ]
    }
  ]
}

IAM Role을 생성한 뒤 Grafana의 Athena 데이터소스 설정에서 Assume Role ARN에 해당 Role의 ARN을 입력합니다.

S3 권한에는 CUR 원본 버킷뿐 아니라 Athena 쿼리 결과가 저장되는 버킷(보통 aws-athena-query-results-*)도 포함해야 합니다.

3-6. Grafana 대시보드 구성

Athena 데이터소스가 연결되면 SQL 쿼리를 기반으로 세 가지 핵심 패널을 구성합니다.

① Daily Cost (일별 비용 추이)

일별 총 비용을 Time Series 패널로 표시합니다. 비용이 갑자기 튀는 날이 있으면 한눈에 파악할 수 있습니다.

SELECT
  DATE(line_item_usage_start_date) AS time,
  ROUND(SUM(line_item_unblended_cost), 2) AS daily_cost
FROM cur_database.cost_report
WHERE line_item_line_item_type = 'Usage'
GROUP BY DATE(line_item_usage_start_date)
ORDER BY time

② Cumulative Cost (월 누적 비용)

해당 월의 누적 비용을 표시하여 월 예산 대비 현재 소진율을 확인합니다.

SELECT
  DATE(line_item_usage_start_date) AS time,
  ROUND(SUM(SUM(line_item_unblended_cost)) OVER (ORDER BY DATE(line_item_usage_start_date)), 2) AS cumulative_cost
FROM cur_database.cost_report
WHERE line_item_line_item_type = 'Usage'
  AND YEAR(line_item_usage_start_date) = YEAR(CURRENT_DATE)
  AND MONTH(line_item_usage_start_date) = MONTH(CURRENT_DATE)
GROUP BY DATE(line_item_usage_start_date)
ORDER BY time

③ Resource별 비용 분포 (Pie Chart)

EC2, EBS, RDS, S3, ELB 등 서비스별 비용 비중을 Pie Chart로 시각화하여 어느 서비스에 비용이 집중되는지 파악합니다.

SELECT
  line_item_product_code AS service,
  ROUND(SUM(line_item_unblended_cost), 2) AS total_cost
FROM cur_database.cost_report
WHERE line_item_line_item_type = 'Usage'
  AND DATE(line_item_usage_start_date) >= CURRENT_DATE - INTERVAL '7' DAY
GROUP BY line_item_product_code
HAVING SUM(line_item_unblended_cost) > 0
ORDER BY total_cost DESC

4. 전체 파이프라인 동작 흐름

파이프라인이 구축되면 매일 자동으로 다음 순서로 동작합니다.

00:00 KST — AWS CUR이 전일 비용 데이터를 Parquet 포맷으로 S3에 적재
01:00 KST — Glue Crawler가 S3를 크롤링하여 Data Catalog 스키마 갱신
이후 — Grafana 대시보드 접속 시 Athena가 최신 데이터를 쿼리하여 시각화

사람이 개입할 필요 없이 전 과정이 자동으로 돌아갑니다. CUR 데이터가 S3에 쌓이기만 하면 Glue → Athena → Grafana 순서로 자동 반영됩니다.

5. 성과 정리

항목	도입 전	도입 후
비용 확인 방식	AWS 콘솔 수동 접속	Grafana 대시보드 자동 시각화
확인 주기	필요할 때 수동 확인	매일 자동 갱신
리소스별 분석	Cost Explorer에서 수동 필터링	Pie Chart로 즉시 확인 (EC2, EBS, RDS, S3, ELB 등)
비용 이상 탐지	사후 인지	일별 추이 그래프로 폭증 조기 감지
운영 통합	비용/인프라 모니터링 분리	하나의 Grafana에서 통합 관리

마무리

AWS CUR → S3 → Glue → Athena → Grafana 파이프라인은 한 번 구축하면 추가 운영 비용 없이(Athena 쿼리 비용 제외) 지속적으로 비용 데이터를 시각화할 수 있는 구조입니다.

특히 이미 인프라 모니터링용 Grafana가 운영 중이라면 Athena 데이터소스만 추가하면 비용 대시보드를 바로 붙일 수 있어서 구축 비용 대비 효과가 큽니다. 일별 비용 추이와 리소스별 분포를 한눈에 확인할 수 있게 되면 예상치 못한 비용 폭증을 조기에 감지하고 빠르게 대응할 수 있습니다.

Prometheus + Grafana 모니터링 & Slack 알람 구축

PARK SEJIN — Mon, 4 May 2026 16:54:28 +0900

AWS 환경에 Prometheus + Grafana 모니터링 & Slack 알람 구축

CloudWatch 기본 지표만으로는 부족했던 모니터링을 Prometheus·Grafana로 강화
Slack 알람과 메트릭 필터링까지 적용한 과정 정리

Prometheus Node Exporter Grafana Cloud Slack Webhook AWS EC2

1. 왜 Prometheus + Grafana인가?

AWS CloudWatch는 기본적인 인스턴스 지표(CPU Utilization, NetworkIn/Out 등)를 제공하지만 메모리 사용률이나 파일시스템 용량 같은 OS 레벨의 상세 지표는 기본 제공하지 않습니다. CloudWatch Agent를 추가 설치하면 수집 자체는 가능하지만 커스텀 대시보드 구성의 유연성이나 PromQL 같은 강력한 쿼리 언어를 활용한 분석에는 한계가 있습니다.

이 프로젝트에서는 CPU·메모리·파일시스템·네트워크 등 세밀한 지표를 초 단위로 수집하고 유연한 대시보드로 시각화하기 위해 Prometheus + Grafana 조합을 선택했습니다.

2. 모니터링 아키텍처

전체 데이터 흐름은 다음과 같습니다.

구성 요소	역할
Node Exporter	각 EC2에서 OS 레벨 메트릭(CPU, 메모리, 디스크, 네트워크)을 HTTP 엔드포인트로 노출
Prometheus	Node Exporter의 `/metrics` 엔드포인트를 주기적으로 scrape하여 시계열 데이터로 저장
Grafana	Prometheus를 데이터소스로 연결해 대시보드 패널로 시각화

3. 구축 과정

3-1. Node Exporter 설치

모니터링이 필요한 모든 EC2 인스턴스에 Node Exporter를 설치합니다. 기본 포트는 9100이며 systemd 서비스로 등록하여 인스턴스 재시작 시에도 자동 실행되도록 구성합니다.

# Node Exporter 다운로드 및 설치
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.8.1.linux-amd64.tar.gz
sudo mv node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/

# systemd 서비스 등록
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

정상 동작 확인은 curl http://localhost:9100/metrics로 메트릭이 출력되는지 확인하면 됩니다.

3-2. Prometheus 설치 및 설정

Prometheus 서버에서 각 Node Exporter를 scrape 대상으로 등록합니다.

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets:
          - '<WEB_SERVER_1_IP>:9100'
          - '<WEB_SERVER_2_IP>:9100'
          - '<WAS_SERVER_1_IP>:9100'
          - '<WAS_SERVER_2_IP>:9100'

CloudWatch와의 차이
scrape_interval: 15s로 설정하면 15초마다 각 타겟의 메트릭을 수집합니다. CloudWatch 기본 5분 간격과 비교하면 훨씬 세밀한 모니터링이 가능합니다.

3-3. Grafana 대시보드 구성

Grafana에서 Prometheus를 데이터소스로 추가한 뒤 Node Exporter Full 대시보드(Dashboard ID: 1860)를 import하면 CPU, 메모리, 디스크 I/O, 네트워크 트래픽 등을 한눈에 확인할 수 있는 대시보드가 바로 구성됩니다.

4. Slack 실시간 알람 체계 구축

모니터링 지표가 확보되었으니 다음 단계는 이상 징후 발생 시 즉각 알림을 받는 것입니다. 도입 전에는 장애를 인지하기까지 평균 10분 정도 걸렸는데 이를 개선하기 위해 Grafana Alert Rules와 Slack Webhook을 연동했습니다.

4-1. Alert Rule 설정

CPU 사용률이 50%를 초과하면 알람이 발생하도록 PromQL 기반 Alert Rule을 작성합니다.

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

이 쿼리는 최근 5분간 idle 상태로 보낸 CPU 시간의 초당 변화율을 구한 뒤 100에서 빼서 실제 CPU 사용률(%)을 계산합니다.

node_cpu_seconds_total{mode="idle"} — CPU가 idle 상태로 소비한 누적 시간(초)
rate(...[5m]) — 최근 5분간 초당 변화율 (0~1 사이 값)
avg by (instance) — 멀티코어 환경에서 인스턴스별 평균
100 - (... * 100) — idle 비율을 사용률로 변환

4-2. Notification Template

알람 메시지가 한눈에 들어오도록 커스텀 Go Template을 작성했습니다.

{{ define "cpu_alert" }}
{{ if gt (len .Alerts.Firing) 0 }}

{{ range .Alerts.Firing }}
*Server :* {{ .Labels.instance | reReplaceAll ":.*" "" }}
*Usage :* {{ index .Values "A" | printf "%.1f" }}%
*Threshold :* 50%
*Time :* {{ .StartsAt.Add 32400000000000 | date "2006-01-02 15:04:05" }} KST
{{ end }}
{{ end }}
{{ end }}

템플릿 주요 포인트:

reReplaceAll ":.*" "" — 인스턴스 주소에서 포트 번호(:9100)를 제거하여 IP만 표시합니다.
index .Values "A" — Alert Rule에서 정의한 쿼리(A)의 현재 값을 가져옵니다.
.StartsAt.Add 32400000000000 — UTC 시간에 9시간(나노초 단위)을 더해 KST로 변환합니다. Grafana Alert 시간은 기본 UTC이므로 이 처리가 필요합니다.

4-3. Slack 알람 결과

Alert Rule의 Threshold 조건이 충족되면 Slack 채널에 아래와 같은 메시지가 즉시 전송됩니다.

5. 성과 정리

항목	도입 전	도입 후
수집 가능 지표	CloudWatch 기본 (CPU Utilization 등)	CPU, 메모리, 파일시스템, 네트워크 상세 메트릭
수집 간격	5분 (CloudWatch 기본)	15초 (Prometheus scrape_interval)
대시보드	CloudWatch 콘솔	Grafana 커스텀 대시보드
장애 감지	평균 약 10분	5분 이내
알림 체계	없음 (수동 확인)	Slack 실시간 알람 자동 발송

6. Grafana Cloud 메트릭 필터링으로 비용 최적화

Prometheus를 로컬에서 운영하면 스토리지 비용만 고려하면 되지만 Grafana Cloud로 Remote Write하는 경우 무료 티어의 Active Series 제한(10,000 시리즈)을 의식해야 합니다. Node Exporter는 기본적으로 수백 개의 메트릭을 노출하는데, 인스턴스 수가 늘어나면 시리즈 수가 금방 한계에 도달합니다.

6-1. 문제 상황

Rate Limit 초과
EC2 인스턴스 4대에 Node Exporter를 설치하고 모든 메트릭을 Grafana Cloud로 전송하니 무료 티어의 rate limit에 걸려 데이터가 누락되기 시작했습니다. 실제로 대시보드와 알림에 사용하는 메트릭은 전체의 일부에 불과한데, 불필요한 메트릭까지 전부 전송하고 있었던 것이 원인이었습니다.

6-2. 필터링 전략

Prometheus에서 메트릭을 필터링할 수 있는 단계는 크게 세 가지입니다.

relabel_configs — scrape 전 타겟 자체를 선택/제외하는 단계
metric_relabel_configs — scrape 후 로컬 저장 전 메트릭을 필터링하는 단계
write_relabel_configs ← 이번에 사용 — Remote Write 전 외부 전송 대상 메트릭을 필터링하는 단계. 로컬에는 전체 데이터를 유지하면서 비용이 발생하는 구간에서만 필터링합니다.

6-3. 실제 적용 설정

대시보드(Node Exporter Dashboard EN 20201010-StarsL)와 Alert Rule에서 실제로 참조하는 메트릭만 allowlist 방식으로 유지했습니다.

# prometheus.yml — remote_write
remote_write:
  - url: '<GRAFANA_CLOUD_REMOTE_WRITE_URL>'
    basic_auth:
      username: '<USER_ID>'
      password: '<API_KEY>'

    write_relabel_configs:
      - source_labels: [__name__]
        regex: '(node_load.*|node_cpu_seconds_total
                |node_memory_.*|node_filesystem_.*
                |node_disk_.*|node_network_.*_bytes_total
                |node_network_.*_packets_total
                |node_netstat_.*|node_sockstat_.*
                |node_filefd_.*|node_context_switches_total
                |node_boot_time_seconds|node_time_seconds
                |node_uname_info|up)'
        action: keep

✅ allowlist vs denylist
action: keep은 regex에 매칭되는 메트릭만 남기고 나머지를 모두 버리는 allowlist 방식입니다. 반대로 특정 메트릭만 제거하는 action: drop(denylist)도 있지만, 불필요한 메트릭이 추가될 때마다 규칙을 추가해야 하므로 allowlist가 더 안전합니다.

6-4. 타겟 관리 최적화: 단일 Job 통합

필터링과 함께 타겟 관리 방식도 정리했습니다. 처음에는 Web, WAS, Bastion을 별도 job으로 분리했는데 job이 늘어날수록 설정 파일 관리가 복잡해졌습니다. 이를 단일 job으로 통합하고 EC2 태그 기반의 server_type 라벨로 구분하는 방식으로 변경했습니다.

# prometheus.yml — scrape_configs
scrape_configs:
  - job_name: 'Project-Server'
    scrape_interval: 60s

    ec2_sd_configs:
      - region: ap-northeast-2
        port: 9100

    relabel_configs:
      - source_labels: [__meta_ec2_instance_state]
        regex: running
        action: keep
      - source_labels: [__meta_ec2_tag_Environment]
        regex: production
        action: keep
      - source_labels: [__meta_ec2_tag_type]
        regex: (web|was|bastion)
        action: keep
      - source_labels: [__meta_ec2_tag_type]
        target_label: server_type

ec2_sd_configs를 사용하면 Auto Scaling으로 인스턴스가 추가/제거될 때 static_configs를 수동으로 수정할 필요 없이 자동으로 타겟이 갱신됩니다. relabel_configs로 실행 중인 Production 인스턴스만 scrape 대상에 포함시키고, EC2 태그의 type 값을 server_type 라벨로 변환하여 Grafana에서 서버 유형별 필터링이 가능하도록 구성했습니다.

6-5. 필터링 성과

항목	필터링 전	필터링 후
전송 메트릭	Node Exporter 전체 (수백 개)	대시보드·알림 필수 메트릭만
감소율	—	약 85% 감소
Rate Limit	초과 → 데이터 누락	무료 티어 내 안정 운영
로컬 Prometheus	전체 메트릭 유지	전체 메트릭 유지 (영향 없음)

마무리

Prometheus + Grafana 조합은 AWS 환경에서 CloudWatch를 보완하는 강력한 모니터링 스택입니다. Node Exporter를 통해 OS 레벨의 상세 지표를 확보하고 Grafana의 Alert Rules + Slack Webhook으로 실시간 알림까지 구성하면 운영 가시성과 장애 대응 속도를 크게 끌어올릴 수 있습니다.

다만 Grafana Cloud 같은 SaaS 기반 백엔드를 사용할 때는 비용과 rate limit을 반드시 고려해야 합니다. write_relabel_configs로 전송 메트릭을 선별하고 ec2_sd_configs로 타겟 관리를 자동화하면 비용을 통제하면서도 필요한 가시성은 유지할 수 있습니다.