문서 병렬 분석 - 처리시간 282.11초 → 73.89초 단축

01 배경

문서를 Wiki로 생성하는 AI 파이프라인을 순차 처리하면 뒤의 문서가 외부 AI 응답을 기다려야 했습니다. 이를 위해 작업자를 늘리면 API 호출과 메모리 사용도 함께 증가하므로 어느 단계까지 확장할지 확인해야 했습니다. 작업 분배에는 메시지를 다시 읽을 수 있고 같은 키 안에서 순서를 보장하는 Kafka를 써, 오래 걸리는 AI 작업을 비동기로 돌리면서 ID 기준으로 중복 처리를 막았습니다. Worker를 1개에서 4개로 늘려 분석 시간을 282.11초에서 73.89초로 줄였습니다. 반면 Worker 안의 동시 AI 요청을 2개에서 4개로 늘리자 95.92초로 오히려 느려졌고, 같은 GPU에서 벡터 생성을 2개 돌리자 각각 약 9.5초에서 19~21초로 늘었습니다. 두 단계는 병렬화 효과가 달라 확장 기준을 나눴습니다.

02 실험과 개선 과정

03 개선한 처리 흐름

flowchart TD
 A[문서 처리 요청] --> K[Kafka에서 문서별 작업 분배]
 K --> W[여러 Worker로 분석, Worker별 동시 요청 제한]
 W --> L[같은 워크스페이스의 저장은 잠금으로 조정]
 V[벡터 생성] --> G[같은 GPU의 처리 경합 확인]
 L --> D[시간, 메모리, 내용 보존을 함께 확인]
 G --> D
 D --> R[단계별 증설 여부 판단]

flowchart TD
 A[문서 처리 요청] --> K[Kafka에서 문서별 작업 분배]
 K --> W[여러 Worker로 분석, Worker별 동시 요청 제한]
 W --> L[같은 워크스페이스의 저장은 잠금으로 조정]
 V[벡터 생성] --> G[같은 GPU의 처리 경합 확인]
 L --> D[시간, 메모리, 내용 보존을 함께 확인]
 G --> D
 D --> R[단계별 증설 여부 판단]

04 결과와 배운 점

문서 4개 분석 시간 73.8% 단축, 문서 100개 큐 재현 300건 누락과 실패 0건

Worker 4개, 각 2개 동시 요청 조건에서 문서 4개의 총 처리 시간을 약 73.8% 줄였습니다. 대신 프로세스 메모리 합이 351.7MiB에서 1,401.0MiB로 약 4배 늘었습니다. 미리 정해 둔 사실 16개 중 완전히 보존된 수도 Worker 1, 2, 4개에서 10, 14, 11개로 달라, 조건별 1회의 작은 표본이지만 품질이 같다고 보지는 않았습니다. 동시 요청을 더 늘리는 제안과, 같은 GPU에서 벡터 생성을 병렬화하는 제안은 오히려 느려져 제외했습니다. 외부 응답 대기와 장치 경합은 서로 다른 병목이라, 확장 방식도 단계마다 달라야 했습니다. 저장된 AI 응답으로 문서 100개의 큐 처리를 3가지 조건에서 재현해, 총 300건 모두 누락과 실패 없이 처리됨을 확인했습니다. 메모리 증가는 MSA로 EKS에서 AI 기능을 분산 배치해 감당할 수 있다고 보고, 문서 병렬 처리에는 최대 Worker 4개를 쓰기로 했습니다.