로그 인리치먼트(Log Enrichment)

모두사인이 하루 수억 건의 감사 로그에 메타데이터와 컨텍스트를 추가하는 로그 인리치먼트 시스템을 비동기 아키텍처로 구현한 과정을 다룬다. 동기 방식은 서비스 성능에 직접적인 영향을 주기 때문에 비동기 파이프라인을 선택했고, CDC·Kafka·S3를 조합해 중복·삭제·컴플라이언스 요구사항을 모두 해결했다.

핵심 포인트

로그 인리치먼트를 비동기로 설계해 서비스 메인 경로에 지연을 추가하지 않고 하루 수억 건을 처리한다.
서비스를 직접 호출하지 않고 CDC로 별도 메타데이터 저장소를 동기화해 서비스 간 의존성과 삭제 리소스 문제를 동시에 해결했다.
Kafka 스트리밍 → 중간 표현 인리치먼트 → S3 파티셔닝 저장의 파이프라인으로 조회 효율을 높였다.
오프셋 기반 파일 네이밍으로 Kafka 리플레이 시 발생하는 중복 로그를 제거한다.
ISMS-P와 CSAP 보안 인증 요구사항을 이 아키텍처로 충족한다.

상세 정리

문제: 하루 수억 건 로그에 사용자·워크스페이스 메타데이터를 실시간으로 붙여야 하는데, 동기 방식은 로그 기록마다 서비스를 호출해 레이턴시 증가와 장애 연쇄 위험이 있었다.
비동기 선택 이유: 로그 생성 시점과 인리치먼트 시점을 분리해 메인 서비스에 지연을 추가하지 않고, 트래픽 급증 시에도 파이프라인이 독립적으로 동작한다.
CDC 기반 메타데이터 저장소: 원본 서비스에 직접 쿼리하는 대신 CDC로 변경 데이터를 별도 저장소에 복제. 리소스가 삭제된 후에도 인리치먼트 완료가 가능하다.
Kafka 파이프라인: 로그 이벤트를 Kafka로 수신 → 중간 표현(intermediate representation)으로 인리치먼트 처리 → 결과를 S3에 저장하는 3단계 흐름.
S3 파티셔닝: 워크스페이스·시간 기준으로 분할해 특정 워크스페이스의 특정 기간 감사 로그를 최소 파일 읽기로 추출할 수 있다.
중복 제거: Kafka 리플레이 발생 시 같은 로그가 재처리될 수 있는데, 오프셋 기반 파일 네이밍으로 동일 오프셋 파일을 덮어써 중복을 제거한다.
컴플라이언스: ISMS-P(정보보호 관리체계)와 CSAP(클라우드 보안 인증) 요구사항을 이 아키텍처로 충족한다.

왜 읽나대규모 감사 로그 파이프라인을 설계하거나 CDC/Kafka/S3 기반 로그 인리치먼트를 구축하려는 백엔드 엔지니어에게 실제 운영 아키텍처와 설계 근거를 확인할 수 있다.

모두싸인 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청