Project #01
문서 전처리 서비스
Spring BootKafkaSpring BatchMariaDBMongoDB
개요
사용자의 문서(PDF, HWP, DOCX 등)를 받아 100억건 이상의 다른 문서들과 비교하여 표절을 측정하는 서비스인 "카피킬러"를 운영하고 있습니다. 이 서비스에서 표절을 측정하기 전, 문서를 "전처리"하는 과정이 필수적이며 이 전처리 파이프라인을 이벤트 기반 아키텍처로 재설계하여 안정성과 확장성을 개선했습니다.
문서 전처리 파이프라인
문서 업로드
PDF, HWP, DOCX
텍스트 추출
OCR 처리
이미지 내 텍스트
문장 분할
저장
표절 검사
100억+ 문서 비교
문제 상황
- 기존에는 모든 전처리 과정을 하나의 동기 API로 처리하고 있었습니다.
- 대용량 문서 처리 시 빈번한 Read Timeout 발생
- 문서당 평균 N개 문장의 개별 DB 쓰기로 과도한 I/O 부하
- 하나의 과정이라도 실패 시 전체 프로세스 재시작 필요 (SPOF)
해결 과정
원인 분석
- 문서 전처리 각 과정들의 강한 "의존성"
- 클라이언트가 전처리 요청 후 모든 과정이 완료될 때까지 대기
- 대용량 문서의 경우 N천~N만 건의 데이터를 문장당 한 Row 저장하여 I/O 부하
해결 방안
- Kafka를 활용하여 각 과정의 의존성 분리 (이벤트 유실 방지를 위해 Kafka 선택)
- API 모듈과 Worker 모듈 분리, 완료 후 Callback 처리
- 문장 데이터 조회 특성상 NoSQL이 적절하다고 판단, MongoDB 채택
- JdbcTemplate batchUpdate로 N번 쓰기를 1번의 배치 작업으로 통합
Before — 동기 처리
클라이언트 요청
단일 API (동기 처리)
문서 업로드
텍스트 추출
OCR 처리
문장 분할
DB 저장
응답 대기...
Read TimeoutI/O 과부하처리량 병목SPOF
After — 이벤트 기반 아키텍처
클라이언트
요청
조회/콜백
API
전처리 요청 수신
문장 데이터 조회
Outbox 저장
MariaDB
이벤트 발행
Batch
Outbox 조회
이벤트 발행
Worker (Kafka Consumer)
텍스트 추출
OCR
문장 분할
MongoDB (텍스트/문장 데이터)
JdbcTemplate batchUpdate 적용 성능 비교
| 1,000문장 | 2,000문장 | 3,000문장 | 4,000문장 | 5,000문장 | |
|---|---|---|---|---|---|
| 적용 전 | 8,890ms | 16,214ms | 23,637ms | 29,010ms | 37,391ms |
| 적용 후 | 1,182ms | 2,059ms | 3,788ms | 4,049ms | 5,155ms |
Impact
83% 단축
평균 문서 처리 시간: 18초 → 3초
93% 감소
주평균 장애: 28건 → 2건 (이벤트 기반 아키텍처 전환)
CS 문의 급감
대용량 문서 관련 고객 문의 대폭 감소
부분 장애 대응
각 과정 중 부분 장애 발생 시 유연한 대처 가능