AWS용 Config Drift Detector 구축 (Snapshots, Lambdas 및 Next.js Dashboard 포함)

Source: Dev.to

고수준 아키텍처

여기 이 글에서 사용한 아키텍처 다이어그램이 있습니다:

한눈에 보기

• AWS 서비스(예: EC2, 보안 그룹)는 일정에 따라 샘플링됩니다.
• Snapshot Lambda는 원시 JSON 스냅샷을 S3와 Supabase/PostgreSQL에 기록합니다.
• Detect Lambda는 최신 스냅샷을 이전 베이스라인과 비교하여 드리프트를 감지합니다.
• Alert Lambda는 드리프트 이벤트를 기록하고, 베이스라인을 업데이트하며, 필요에 따라 Slack 알림을 보냅니다.
• Next.js 대시보드는 Supabase/PostgreSQL을 백엔드로 하는 가벼운 API를 폴링하여 드리프트와 베이스라인을 표시합니다.

이 글의 나머지 부분에서는 빠른 피드백, 명확한 감사 로그, 그리고 부수 프로젝트처럼 느껴지지 않는 UI를 원하는 SRE/DevOps 엔지니어의 관점에서 이를 자세히 설명합니다.

설계 목표 및 제약 조건

프로젝트 범위를 잡을 때 몇 가지 명시적인 목표를 설정했습니다:

• 의미 있는 드리프트 감지, 모든 필드 변화를 감지하는 것이 아니라.
• 아키텍처를 단순하고 관찰 가능하게 유지: 맞춤형 인프라보다 관리형 서비스를 사용.
• UI를 운영자 친화적으로 만들기: 장난감 대시보드가 아니라 SRE 콘솔을 생각하세요.
• 혼자 구축할 수 있을 정도로 작게, 하지만 시니어 엔지니어나 채용 담당자에게 보여줄 만큼 신뢰성을 갖추기.

여기서부터 아키텍처는 자연스럽게 네 부분으로 나뉘었습니다:

1. 스냅샷 파이프라인.
2. 드리프트 감지 엔진.
3. 알림 및 감사 로그.
4. 웹 대시보드.

1. Snapshot pipeline

무엇이 스냅샷으로 저장되나요?

우선, 영향력이 크지만 범위가 좁은 AWS 리소스에 집중했습니다:

• EC2 인스턴스 – 라이프사이클, 인스턴스 유형, 태그.
• 보안 그룹 – 인바운드/아웃바운드 규칙 및 연결된 리소스.

이들은 “빠른 수정”이나 “디버깅용” 변경으로 자주 사용되며, 나중에 보안 및 신뢰성 문제로 이어지는 경우가 많습니다.

스냅샷이 시스템을 통해 흐르는 방식

스냅샷 파이프라인은 예약된 Lambda를 중심으로 동작합니다:

• 트리거: EventBridge 규칙이 30분마다 실행됩니다.
• Snapshot Lambda:
  1. AWS API를 호출해 EC2 인스턴스와 보안 그룹을 목록화합니다.
  2. 데이터를 안정적인 JSON 형태로 정규화합니다.
  3. 각 스냅샷을 다음 위치에 기록합니다:
     • S3 – 원시, 타임스탬프가 포함된 JSON (예: YYYY-MM-DD/HH-MM-SS.json).
     • Supabase/PostgreSQL – 나중에 빠른 조회를 위한 요약된 스냅샷 메타데이터.

이를 통해 얻을 수 있는 장점:

• 저렴한, 추가 전용 로그 형태로 각 시점의 전체 상태를 보관 (S3).
• 대시보드와 드리프트 감지를 위한 쿼리 가능한 상태 (Postgres).

2. Drift 탐지 엔진

베이스라인 vs. 스냅샷

시스템은 간단한 사고 모델을 사용합니다:

• 스냅샷은 “현재 세계가 어떻게 보이는지”를 의미합니다.
• 베이스라인은 “우리가 기대하는 세계의 모습”을 의미합니다.

새로운 스냅샷이 도착할 때마다, Detect Lambda는 이를 현재 베이스라인과 비교합니다:

1. 각 리소스를 안정적인 식별자(예: 인스턴스 ID)로 매핑합니다.
2. 신뢰성/보안에 중요한 필드만 비교합니다.
3. 잡음이 많고 빠르게 변하는 필드(예: 타임스탬프)는 무시합니다.

출력은 드리프트 이벤트 집합입니다:

각 드리프트 이벤트는 다음을 포함합니다:

• 리소스 메타데이터(ID, 유형, 환경).
• 변경된 필드(이전 vs. 이후).
• 심각도 분류(아래 참고).

감지 후, 베이스라인은 앞으로 업데이트되어 시스템이 매번 처음부터 재생하는 대신 드리프트를 점진적으로 추적합니다.

3. 알림 및 심각도

모든 드리프트가 동일하게 심각한 것은 아닙니다. 태그를 변경하는 것과 전 세계에 SSH를 열어두는 것은 다릅니다.

심각도 수준

알림 Lambda 책임

• 드리프트 이벤트를 Supabase/PostgreSQL에 기록하여 나중에 조회할 수 있게 합니다.
• 필요에 따라 기준선을 업데이트합니다.
• 선택적으로 CRITICAL 및 HIGH 심각도 이벤트에 대해 Slack 알림을 보냅니다.

HIGH 및 CRITICAL 드리프트에 대한 Slack 알림

• Channel: 예시 #infra-alerts
• Message includes: 리소스, 환경, 심각도 및 간단한 설명.

이렇게 하면 Slack 알림이 과도하게 발생하지 않으면서도 실제로 중요한 변경에 대한 긴밀한 피드백 루프를 제공할 수 있습니다.

4. The Next.js dashboard

대시보드는 의도적으로 단순하지만, 데모보다는 SRE/DevOps 워크플로에 최적화되어 있습니다.

주요 뷰

앱은 세 가지 주요 페이지를 제공합니다:

Dashboard

• 고수준 통계: 활성 드리프트 수, 베이스라인 수, 모니터링 중인 환경 수.
• 최근 드리프트(시간 및 심각도 순 정렬).
• 베이스라인 개요(어떤 환경이 포함되어 있는지, 어떤 베이스라인이 오래된 상태인지).

Drifts

• 드리프트 이벤트 테이블, 포함 항목:
  • 심각도 칩.
  • 리소스 및 환경.
  • 드리프트 유형 (ADDED, REMOVED, MODIFIED).
  • 감지된 시간.
• 심각도, 상태, 환경별 필터.

Baselines

• 베이스라인 목록, 포함 항목:
  • 이름, 환경.
  • 상태(Active / Stale / Archived).
  • 마지막 업데이트 시간.
  • 베이스라인별 필터가 적용된 Drifts 뷰로 연결되는 링크.

데이터 흐름

대시보드는 가벼운 API 레이어를 통해 Supabase/PostgreSQL을 조회합니다:

• 드리프트와 베이스라인 목록을 가져오기.
• 대시보드 메트릭을 위한 간단한 집계 지원(예: 활성 드리프트 수).
• 백엔드에 과부하를 주지 않으면서 UI가 “실시간”처럼 느껴지도록 충분히 자주 폴링.

핵심은 운영상의 명확성에 있습니다. 다음 질문에 쉽게 답할 수 있어야 합니다:

• “최근에 무엇이 변경됐나요?”
• “이 환경이 다른 환경보다 더 많이 드리프트하고 있나요?”
• “어떤 베이스라인이 오래됐나요?”

왜 이 아키텍처인가?

이 설계는 조기 복잡성을 의도적으로 피합니다:

• Cadence‑based 작업을 위한 서버리스 – Lambda와 EventBridge 스케줄러는 “N분마다 실행하고 스냅샷을 비교”하는 작업에 자연스럽게 맞습니다.
• S3 + Postgres는 내구성과 쿼리 가능성을 모두 제공합니다:
  • 원시 히스토리는 S3에 저장.
  • 빠른 읽기와 간단한 집계를 위해 Postgres 사용.
• Next.js 대시보드:
  • 배포가 쉽다.
  • UX를 빠르게 iterating 할 수 있다.
  • Supabase와 백엔드로 잘 어울린다.

동시에 확장성을 남겨 둡니다:

• EC2와 보안 그룹 외에 더 많은 리소스 유형 추가.
• 환경별 베이스라인 및 다중 계정 지원 도입.
• 타임라인, diff 뷰, 풍부한 필터를 포함하도록 대시보드 확장.

향후 개선 사항

• 더 나은 diff 뷰 – UI에서 구조화된 diff(필드 수준 전/후)를 보여주고, 단순히 “modified”만 표시하지 않음.
• 알림 정책 – 어떤 드리프트가 어디에 알림을 보낼지(Slack, 이메일 등) 설정 가능한 규칙.
• 멀티‑클라우드 지원 – 다른 클라우드 제공자를 처리하도록 스냅샷/감지 로직을 추상화.
• 드리프트 복구 훅 – 특정 드리프트 유형에 대해 런북이나 자동 복구를 트리거.

현재 버전은 기본에 집중합니다: 감지, 분류, 알림, 시각화. 이는 가장 고통스러운 “누가 프로덕션을 바꿨다” 문제를 포착하고, 포트폴리오나 블로그 포스트에서 일관된 이야기를 전달하기에 충분합니다.

마무리

Config Drift Detector는 구성 변경을 더 눈에 띄게 만들기 위한 방법으로 시작했지만, 작고 집중된 아키텍처를 연습하는 좋은 사례가 되었습니다:

• 명확한 데이터 흐름 하나: AWS → snapshots → drift detection → alerts → dashboard.
• 최소한의 구성 요소로 각각의 작업을 잘 수행합니다.
• 운영자가 실제로 드리프트를 조사하고 대응하는 방식을 반영한 UI.

구성 관리, SRE 도구에 관심이 있거나 CRUD를 넘어서는 포트폴리오 프로젝트를 원한다면, 이런 것을 구축하는 것이 클라우드 아키텍처, 관측성, 그리고 개발자 경험의 교차점을 탐구하는 좋은 방법입니다.