데이터 홍수 속에서 길을 찾다: EKS와 Grafana Alloy로 구축하는 다중 계정 DB 통합 모니터링 전략

이상륜2026.09.01수정 2026.09.02

1. 서론: 왜 Grafana Alloy인가? 현대적 DB 모니터링의 과제

현대 클라우드 네이티브 인프라는 파편화된 데이터와 다중 계정 환경으로 인해 모니터링 복잡성이 기하급수적으로 증가하고 있습니다. 특히 수십 개의 AWS 계정에 분산된 RDS 로그와 EKS 클러스터 내의 수많은 Pod 로그를 단일 지점에서 통합 관리하는 것은 보안과 운영 효율성 측면에서 매우 까다로운 과제입니다.

전통적인 에이전트 방식은 개별 서비스마다 중복된 설정을 요구하며 통합 가시성 확보에 한계가 있습니다. 이러한 병목을 해결하기 위해 우리는 Grafana Alloy를 선택했습니다. Alloy는 OpenTelemetry(OTel)와의 완전한 호환성, 고성능 데이터 파이프라인, 그리고 컴포넌트 기반의 유연한 구성을 제공하여 복잡한 다중 계정 환경을 아우르는 차세대 통합 콜렉터로서의 역할을 완벽히 수행합니다.

2. 아키텍처 개요: 중앙 집중형 로그 및 메트릭 수집 구조

본 아키텍처는 EKS 클러스터 내에 배포된 Grafana Alloy를 핵심 엔진으로 삼아 다원화된 수집 경로를 통합합니다.

EKS 내부 로그 수집: loki.source.kubernetes 컴포넌트를 통해 클러스터 내 워크로드의 로그를 수집합니다.
다중 계정 RDS 수집: otelcol.receiver.awscloudwatch 컴포넌트를 사용하여 여러 AWS 계정에 산재한 RDS 로그를 수집하며, 보안을 위해 2단계 Role Chain Assume 인증 방식을 채택합니다.

중앙 집중형 관리: EKS 내부에 배치된 Grafana Alloy가 모든 외부 계정의 RDS 로그와 내부 Pod 로그를 흡수하는 통합 엔드포인트 역할을 합니다.
데이터 흐름의 최적화:
1. RDS 로그: 타 계정의 CloudWatch Logs로부터 데이터를 스트리밍 받아 Alloy로 전달합니다.
2. EKS 로그: 클러스터 내부 API를 통해 Pod 로그를 실시간 수집합니다.
3. 가공 및 전송: 수집된 데이터는 Alloy 내부에서 PII 마스킹 및 라벨링을 거쳐 최종적으로 중앙 Loki 저장소로 전송됩니다.
이원화된 배치 전략: 수집 대상의 특성에 따라 EKS 로그는 고가용성을 위한 StatefulSet으로, CloudWatch 로그는 중복 수집 방지를 위해 Deployment(1 Replica)로 구성하여 성능과 안정성을 동시에 확보합니다.

데이터 흐름(Data Flow) 상세:

데이터 소스(Source): EKS Pod Logs, RDS CloudWatch Log Groups.
수집 계층(Alloy):
- EKS 로그 수집: Clustering 모드로 동작하여 부하 분산 처리.
- RDS 로그 수집: Cross-Account Role Assume을 통한 타 계정 접근.
처리 및 변환(Process): OTTL(OpenTelemetry Transformation Language)을 활용한 PII(개인정보) 실시간 마스킹.
저장 및 시각화(Export): 최종 데이터를 Loki(로그) 및 Grafana(대시보드)로 전송.

3. Part 1: EKS Pod 로그 수집 및 고가용성 클러스터링 전략

EKS 환경에서의 로그 수집은 워크로드의 동적인 변화를 즉각적으로 반영할 수 있어야 합니다.

StatefulSet 구성 및 고가용성 (HA)

우리는 Alloy를 3 Replicas 기반의 StatefulSet으로 운영합니다. Deployment가 아닌 StatefulSet을 선택한 이유는 각 Pod의 정체성(Identity)을 유지하면서 loki.source.kubernetes 컴포넌트의 clustering { enabled = true } 기능을 백분 활용하기 위함입니다. 이는 단순한 복제가 아니라, 수집기들이 서로 통신하며 수집 대상을 지능적으로 나누어 갖는 구조를 형성합니다.

일관된 해싱(Consistent Hashing) 분배 알고리즘

수집 대상이 되는 수많은 Pod은 Consistent Hashing 알고리즘을 통해 3개의 Alloy 노드에 자동 분배됩니다. 이때 사용되는 Shard Key는 다음과 같습니다:

namespace, pod, container, pod_uid

특히 pod_uid를 샤드 키에 포함함으로써, 동일한 이름의 Pod이 재생성되더라도 고유 인스턴스를 정확히 식별하여 데이터 중복이나 누락 없는 안정적인 해싱 밸런싱을 보장합니다.

수집 대상 및 라벨 구조

discovery.kubernetes 블록의 namespace_pods 설정을 통해 argocd, monitoring, insa, insa-db, stics, alloy 등 주요 네임스페이스를 정밀하게 타겟팅합니다. 수집된 로그에는 cluster, namespace, pod, container 외에도 controller_kind나 cronjob 같은 메타데이터 라벨이 부여되어 분석의 편의성을 높입니다.

4. Part 2: Cross-Account RDS 로그 수집 – 보안과 효율의 조화

보안이 엄격한 다중 계정 환경에서 타 계정의 RDS 로그를 안전하게 가져오기 위해 2단계 Role Chain Assume 방식을 도입했습니다.

Role Chain Assume 프로세스

1단계 (IRSA): EKS Pod에 주입된 Web Identity Token을 사용하여 관리 계정의 IAM Role(base profile) 권한을 획득합니다.

2단계 (Cross-Account): 획득한 base 권한을 기반으로 실제 로그가 있는 타 계정의 alloy-cloudwatch-read-role을 Assume합니다.

IAM 정책 구성

로그 수집 대상이 되는 타 계정에는 반드시 아래의 정책이 포함된 Role이 정의되어야 합니다.

Trust Policy:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::XXXXXXXXX:role/{env}-db-mgmt-cw-assume-role"
  },
  "Action": "sts:AssumeRole"
}

Permission Policy:

{
  "Effect": "Allow",
  "Action": [
    "logs:DescribeLogGroups",
    "logs:DescribeLogStreams",
    "logs:GetLogEvents"
  ],
  "Resource": "arn:aws:logs:ap-northeast-2:*:log-group:/aws/rds/*"
}

Alloy 설정: aws-config.yaml

[profile base]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn = arn:aws:iam::XXXXXXXXXX:role/{env}-db-mgmt-cw-assume-role
role_session_name = alloy-base

[profile <Target_Account_Alias>]
region = ap-northeast-2
role_arn = arn:aws:iam::<Target_Account_ID>:role/alloy-cloudwatch-read-role
source_profile = base
role_session_name = alloy-<Target_Account_Alias>

IAM 정책 설계 (최소 권한 원칙)

보안 가이드라인에 따라 타 계정의 Permission Policy는 리소스를 엄격히 제한합니다.

리소스 한정: "arn:aws:logs:ap-northeast-2:*:log-group:/aws/rds/*"와 같이 RDS 관련 로그 그룹으로만 접근을 제한합니다.
권한 목록: logs:DescribeLogGroups, logs:DescribeLogStreams, logs:GetLogEvents

이러한 논리적 연결은 aws-config.yaml 내에서 프로필 정의를 통해 관리되며, 보안 사고 시 권한 추적을 용이하게 합니다.

5. 유연한 수집 타겟팅: Autodiscover vs Named 구성

로그 수집 효율성을 극대화하기 위해 운영 상황에 따른 두 가지 전략을 제공합니다.

Case 1 (Autodiscover): 특정 Prefix(예: /aws/rds/cluster/)를 가진 모든 로그 그룹을 자동으로 감지합니다. 대규모 클러스터 운영 시 관리 포인트를 획기적으로 줄여주는 권장 아키텍처 패턴입니다.
Case 2 (Named): 특정 로그 그룹(예: .../audit, .../slowquery)을 명시적으로 지정합니다. 레거시 시스템이나 특정 로그만 정밀하게 수집해야 하는 예외적인 경우에 사용합니다.

설계 시 주의사항: 한 리시버 블록 내에서 autodiscover와 named는 **상호 배타적(Mutually Exclusive)**입니다. 혼용이 필요한 경우 논리적으로 분리된 별도의 리시버 블록을 구성해야 합니다.

6. 보안의 완성: OTTL을 활용한 PII(개인정보) 마스킹 처리

로그에 포함된 민감 정보를 보호하는 것은 아키텍트의 최우선 과제입니다. 우리는 otelcol.processor.transform 컴포넌트 내에서 **OTTL(OpenTelemetry Transformation Language)**의 replace_pattern을 활용해 실시간 마스킹을 수행합니다.

개인정보 보호 마스킹 전략

대상	패턴 예시	마스킹 결과
이메일	user@example.com	`[EMAIL_MASKED]`
전화번호	010-1234-5678	`[PHONE_MASKED]`
주민등록번호	880101-1234567	`[RRN_MASKED]`
신용카드	1234-5678-1234-5678	`[CARD_MASKED]`
IPv4	10.0.1.100	`[IP_MASKED]`
비밀번호/토큰	password=abc123	`[CREDENTIAL_MASKED]`
DB 사용자(영문)	‘seyeon.park’	`'[USERNAME_MASKED]'`
한글 이름	김철수	`[NAME_MASKED]`

참고: 한글 이름(2~4자) 마스킹 시 일반 명사가 포함되는 오탐(False Positive) 가능성이 있으므로, 업무 환경에 특화된 정규표현식 튜닝이 지속적으로 필요합니다.

7. 관측성 시각화: Datadog에서 Grafana로의 메트릭 전환 전략

기존 Datadog 중심의 지표를 Grafana로 전환하면서, 수집 주기와 계산 로직을 최적화했습니다.

지표 수집 엔진의 이원화

Alloy MySQL Exporter (10s 주기): 실시간 성능 추적이 필요한 DB 내부 메트릭(Connections, QPS 등)을 담당합니다.
Alloy CW Exporter (60s 주기): AWS 인프라 관점의 지표(CPU Utilization, Replication Lag 등)를 보완적으로 수집합니다.

핵심 모니터링 임계값 및 변환 원칙

DML Latency의 경우 엔진 필터 미적용 기준으로 다음과 같은 엄격한 임계값을 적용합니다:

정상: < 3ms
주의: 3 ~ 10ms
경고(Critical): > 10ms

아키텍처적 통찰: Datadog은 주로 last 또는 max 값을 시각화하는 반면, Grafana는 rate()나 average를 활용해 초당 변화율과 전반적인 추세를 분석하는 데 강점이 있습니다. 수집 방식 차이로 수치상 미세한 차이가 발생할 수 있으나, 지표의 추이(Trend)와 패턴은 동일하게 유지되도록 설계되었습니다.

8. 운영 자동화: ArgoCD와 GitOps 기반 파이프라인

새로운 수집 대상 추가는 완벽한 GitOps 흐름을 따릅니다.

Config 수정: aws-config.yaml 및 리시버 설정을 Git에 반영합니다.
IAM 프로비저닝: 대상 계정에 필요한 읽기 권한 역할을 생성합니다.
자동 동기화: PR Merge 후 ArgoCD가 변경 사항을 감지하여 Alloy의 설정을 자동으로 Sync하고 적용합니다.

9. 기술적 제약 및 주의사항 (Critical Notes)

실무 적용 시 안정성을 위해 다음의 제약 사항을 반드시 숙지해야 합니다.

컴포넌트 상태: otelcol.receiver.awscloudwatch는 현재 실험적(Experimental) 단계입니다. Helm 설정 시 stabilityLevel: "experimental" 명시가 필요합니다.
Deployment Replicas 제약: CloudWatch 리시버는 내부 클러스터링을 지원하지 않습니다. 데이터 중복 수집을 방지하기 위해 이 리시버를 포함한 Pod은 반드시 1개의 Replica로 운영해야 합니다.
Loki Labeling (RDS): RDS 로그 쿼리 시 source="aws-rds", cluster, log_group 라벨을 필수로 활용하여 검색 성능을 최적화하십시오.
start_from과 체크포인트(Checkpoint): start_from 설정은 최초 기동 시에만 유효합니다. 이후 Pod이 재시작되면 Alloy 내부의 체크포인트 메커니즘이 마지막 수집 위치를 기억하여 데이터 유실이나 중복 없이 수집을 재개합니다. (EFS PV&PVC 설정 필요)

10. 결론: 스마트한 모니터링이 가져다주는 비즈니스 가치

Grafana Alloy를 활용한 중앙 집중형 모니터링 전략은 단순한 도구의 교체를 넘어, 데이터 관리의 거버넌스를 확립하는 과정입니다. 파편화된 다중 계정의 데이터를 한데 모으고, 강력한 PII 마스킹으로 보안성을 높이며, GitOps를 통한 운영 자동화를 달성함으로써 엔지니어는 더 본질적인 서비스 안정화 업무에 집중할 수 있습니다.

데이터의 홍수 속에서 명확한 가시성을 제공하는 Grafana Alloy는 복잡한 클라우드 아키텍처를 지탱하는 가장 신뢰할 수 있는 관측성 파이프라인이 될 것입니다.