다나와의 상품 색인 파이프라인

다나와 검색개발팀이 상품 동적 색인 파이프라인에서 자체 개발한 Queue Loader 를 Logstash 로 교체한 과정이다. RabbitMQ 에 강하게 묶인 자바 서비스 탓에 이관 비용과 유지보수 부담이 컸고, Logstash 설정 몇 줄로 대체하면서 1GB 로그 처리 시간이 약 25초에서 5초로 줄었다.

핵심 포인트

다나와는 약 11억 건의 상품 데이터를 다루며, 대용량을 실시간에 가깝게 처리하고 전문 검색을 하려고 RDBMS 대신 Elasticsearch 를 검색 엔진으로 쓴다.
기존 흐름은 Indexing API 가 1분 간격으로 로그 파일을 남기고, Queue Loader 가 실시간으로 읽어 전처리 후 MQ 로 보내면, Queue Indexer 가 소비해 ES 에 색인하는 구조다.
Queue Loader 는 보일러플레이트가 많고 SOLID 가 지켜지지 않아 MQ 를 갈아타려면 관련 코드를 전부 손봐야 했고 사이드이펙트 위험이 컸다.
Logstash 로 바꾸면 output 파라미터만 고쳐 MQ 를 이관할 수 있고, sincedb·filter·dead letter queue 같은 기능을 직접 만들지 않아도 된다.
동일 조건(WSL2 Ubuntu, 힙 4GB, 1GB 로그) 비교에서 기존 서비스 약 25초 대 Logstash 약 5초로 80% 이상 개선을 확인했다.

상세 정리

문제 제기: 파이프라인이 외부 서비스인 RabbitMQ 에 지나치게 의존적이고 내구성·안정성이 떨어진다고 판단해 구조 개선을 시작했다.
유지보수 비용: 정책이 바뀔 때마다 복잡한 코드를 고쳐야 하고, 데이터 유실 방어책도 미비했다는 점을 개선 목표로 잡았다.
Logstash 선택 근거: 수백~수천 줄 수정이 설정 몇 줄로 줄어들고, 로그를 마지막으로 읽은 지점을 기록하는 sincedb 와 파이프라인 구성용 filter, MQ 전송용 output 이 이미 갖춰져 있다.
장애 대응: 서버 장애 시 dead letter queue 로 처리할 수 있어 자체 방어 로직을 따로 만들 필요가 없다.
점진 이관: RabbitMQ 의 모든 큐를 한 번에 교체할 수 없으므로 전처리 과정을 순차적으로 옮겨 완전 대체를 목표로 한다. Queue Router 도 멀티 파이프라인 구성으로 같은 방식으로 옮길 수 있다고 본다.
모듈형 파이프라인: 큐가 수십 개인데 파이프라인 파일 하나에서 filter 분기를 하면 재사용이 어렵다. `pipeline.yml` 에서 glob 표현식으로 구성 요소를 조합해 정책별 필터를 나눴다.
성능 테스트 방법: 실제 1분간 유입된 요청을 쌓은 1GB txt 파일을 쓰고, Logstash 는 처리 시간 측정이 어려워 첫 라인과 마지막 라인의 처리 시각 차이로 계산했다.
테스트 환경 통제: 기존 서비스는 `java -Xmx4g -jar queue-loader.jar`, Logstash 는 docker-compose 에서 `LS_JAVA_OPTS: "-Xms4g -Xmx4g"` 로 힙을 맞췄고 이미지 태그는 `logstash:7.9.1` 이다.
정확성 확인: 성능뿐 아니라 MQ 에 들어간 데이터가 기존과 동일한지 큐 내용을 직접 대조해 검증했다.
부수 효과: 직접 관리할 서비스 수가 줄어 핵심 비즈니스 로직에 집중할 수 있게 됐다는 점을 이관의 실질적 이득으로 꼽는다.