기획서 없이도 OK! Kafka로 시스템 내재화 검증 자동화

by DD
2개월 전
조회수 34

기존 시스템 내재화 과정에서 기획서 부재 및 블랙박스 코드라는 난관에 직면하여 검증 시스템 구축의 필요성을 느낌

Kafka 생태계를 활용하여 데이터 스트림 기반 검증 파이프라인을 구축, 실시간 데이터 검증 환경을 마련함

조회, 업데이트, E2E 검증 등 다양한 케이스에 적용하여 내재화 전후 시스템의 동일성을 증명

OpenSearch 대시보드검증 전용 관리자 페이지를 구축하여 개발자의 디버깅 효율성을 극대화함

입력과 출력을 명확히 정의하고, 문제를 세분화하여 접근하는 방식으로 복잡한 시스템의 동일성 검증에 성공함

데이터 스트림 기반 검증 파이프라인 아키텍처

본 글에서는 Kafka(Kafka)를 활용한 데이터 스트림 기반 검증 파이프라인 아키텍처를 소개한다. 데이터 발생부터 개발자 액션까지 이어지는 루프 형태로 설계되었으며, 트리거, 실행 및 비교, 가공 및 적재, 분석 및 개선의 4단계로 구성된다.

트리거(Trigger): DB 변경, 개발자 요청, 파일 수신 등 다양한 이벤트 발생 시 Kafka(Kafka)를 통해 비동기적으로 이벤트 전파

실행 및 비교(Process): 기존 및 신규 시스템에 동일한 입력을 주입하고, 각 시스템의 특성에 맞는 비교 로직을 통해 정합성 판단

가공 및 적재(Output): 불일치 데이터는 실시간 통계로 변환되어 알림 전송 또는 별도 저장소에 적재

분석 및 개선(Action): 개발자는 대시보드나 Slack 알림을 통해 오류 패턴을 분석하고 로직을 수정하여 검증 루프 반복

이러한 아키텍처는 대규모 데이터 처리와 실시간 피드백을 가능하게 하며, 내재화 과정에서 시스템의 안정성을 확보하는 데 기여한다.

조회 로직 검증: 블랙박스 극복 전략

조회 로직 검증은 기획서 부재 및 블랙박스 상황에서 기존 API와 신규 API의 응답을 비교하는 방식으로 진행되었다. CDC(Change Data Capture)를 통해 DB 변경을 실시간으로 감지하고, Kafka(Kafka)를 통해 검증 모듈로 이벤트를 전달한다.

듀얼 API 호출: 기존 API와 신규 API를 동시에 호출하여 응답 필드를 1:1로 정밀 대조

Map 기반 재귀 비교: 응답 객체를 Map 구조로 변환하여 필드명(Key)을 기준으로 값을 대조하는 유연한 검증 로직 구현

정렬 조건 및 기본값 문제 해결: 정렬 조건 미 명시 시, 실제 데이터 값을 개별 추출하여 대조하고, 기본값 문제 역시 대조 과정을 통해 해결

이러한 전략을 통해 블랙박스 상태의 조회 로직을 검증하고, 내재화 과정에서 시스템의 정확성을 확보했다.

업데이트 로직 검증: 비동기 환경에서의 시간차 이슈 해결

업데이트 로직 검증은 데이터의 흐름과 변화를 다루는 카탈로그 통계 업데이트 로직을 검증하기 위해, 기존 조회 검증 파이프라인에 '통계 시뮬레이션' 단계를 추가했다. 비동기 스트림 특유의 지연(Lag)으로 인한 불일치 문제를 해결하기 위해, 필터링과 재시도 큐 전략을 사용했다.

필터링: 카탈로그 통계와 관련 없는 필드 변경 시 검증을 수행하지 않도록 필터링 적용

N회차 재시도 큐: 데이터 불일치 시 즉시 오류로 판단하지 않고, 큐의 맨 뒤로 재전송하여 일정 횟수 이상 재시도 후 실제 로직 차이로 인식

ETL 배치 검증: 실시간 스트림 검증 외에, ETL 데이터를 활용한 배치 검증 체계를 설계하여 트리거 누락 케이스 확인

이러한 전략을 통해 비동기 환경에서의 시간차 문제를 극복하고, 업데이트 로직의 정확성을 확보했다.

E2E 검증: 수신 파이프라인 내재화

수신 파이프라인 내재화는 판매자 상품 파일 다운로드부터 최종 상품 등록까지의 E2E(End-to-End) 검증을 목표로 한다. 파이프라인 복제를 통해 기존 시스템과 동일한 신규 파이프라인을 구축하고, 쉐도우 검증(Shadow Testing)을 수행하여 안전하게 데이터를 확보했다.

스냅숏 비교: 상품 고유값인 SKU(Stock Keeping Unit)와 merchantUpdateDate를 결합하여 스냅숏의 고유 키를 활용, 데이터의 정확한 비교 기준 마련

필터링: 실제 로직 오류가 아닌 단순 사양 변경이나 의도된 차이를 비교 대상에서 제외하여 분석 효율을 높임

수신 파이프라인 단계별 비교: 스케줄별 처리 결과를 비교하여, 파일 내 유효 건수와 오류 건수 등 거시적인 관점의 수신 프로세스 정합성 확인

이러한 E2E 검증을 통해 수신 파이프라인의 내재화 성공을 검증했다.

OpenSearch 대시보드와 관리자 페이지를 활용한 디버깅

개발자의 디버깅 효율을 높이기 위해 OpenSearch 대시보드검증 전용 관리자 페이지를 구축했다. OpenSearch 대시보드는 오류 패턴 분석 및 정합성 추이를 시각화하여 개발자가 문제 해결에 집중할 수 있도록 지원한다.

오류 유형 및 필드별 그룹화: OpenSearch 대시보드를 통해 오류 패턴을 분석하고, 공통 오류를 그룹화하여 개발자가 효율적으로 로직을 수정하도록 지원

타임라인 기반 이상 징후 감지: 데이터 변경 및 불일치 집중 감지 시점을 시계열로 파악하여, 특정 배포 시점이나 외부 시스템 변화의 영향 추적

검증 전용 관리자 페이지: 직관적인 UI를 통해 데이터를 확인하고, 불일치 필드를 시각화하여 디버깅 속도 향상

이러한 도구들을 통해 개발자는 방대한 데이터 속에서 핵심 결함을 빠르게 해결하고, 내재화 프로젝트의 성공적인 완수를 이끌었다.

검증 시스템 구축의 핵심: 입력과 출력의 명확한 정의

본 글에서 제시하는 검증 시스템 구축의 핵심은 '무엇을 넣고 무엇을 비교할 것인가'를 명확히 정의하는 것이다. 입력과 출력을 명확히 연결하면, 내부 로직이 복잡한 블랙박스라도 시스템의 동일성을 통계적으로 증명할 수 있다.

입력: 양쪽 시스템이 동일한 상태에서 시작할 수 있도록 보장하는 값 (예: 동일한 ID, 스냅숏, 상품 파일)

출력: 시스템 성격에 따라 달라지는 최종 산출물 (예: API 응답 객체, DB 업데이트 결과 값, 최종 등록된 상품 데이터)

문제 세분화: 복잡한 문제를 작은 단위로 쪼개어 접근하고, 각 단계별 검증을 통해 시스템의 안정성을 확보

지속적인 개선: 검증 과정을 반복하며 불일치 건수를 0에 수렴시키는 과정을 통해 내재화 완료를 선언

이러한 접근 방식을 통해 기획서 부재 상황에서도 시스템의 동일성을 증명하고, 안정적인 내재화를 달성할 수 있었다.

기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다