임베딩 파이프라인 설계기

About this offer

배경 CS 처리량을 줄이기 위한 챗봇 프로젝트의 책임자가 되었다. 챗봇이 답할 근거는 FAQ 데이터였고, FAQ가 바뀔 때마다 임베딩해서 우리 DB에 실시간으로 반영하는 것 이 목표였다. 왜 그냥 처리하면 안 되는가 임베딩 1건 5초 , 일 최대 1,600건 → 총 작업량 8,000초(약 2시간 13분) API Gateway 통합 타임아웃 기본 29초 , Lambda 최대 실행 900초(15분) 즉 요청 안에서 처리하면 타임아웃 때문에 동작 자체가 불가능 문제는 "느리다"가 아니라 동기 실행이라는 구조 였다. 아키텍처 FAQ 변경 → API Gateway 주소로 webhook 호출 변경 데이터를 DB에 저장하고 SQS 로 전달 후 즉시 리턴 임베딩은 병렬 가능하므로 최대 100개 람다가 동시에 소비해 벡터 생성 및 DB 적재 처리 실패는 DLQ 로 격리, 무한 재시도 없이 담당자에게 알람 요청 경로에서 8,000초를 떼어낸 것이 핵심이다. webhook 응답은 임베딩 시간과 무관해진다. 왜 100개인가 — 병목은 임베딩이 아니라 DB다 동시성을 올리면 임베딩은 빨라지지만, 적재를 위해 DB 커넥션을 잡는 순간 병목이 DB로 옮겨간다. DB 최대 커넥션 500개 다른 서버 사용분을 제외하고 남은 몫의 1/3 을 임베딩 람다에 할당 결과: 최대 동시성 100 100은 임베딩 속도가 아니라 DB 커넥션 예산에서 역산한 값 이다. 워커 수는 가장 좁은 공유 자원에서 결정된다. 에러 처리 webhook 실패 — API 단에서 HTTP 상태 코드를 리턴해 즉시 실패를 알린다 접수 후 임베딩 실패 — DLQ로 넘기고 담당자에게 알람. 무한 재시도 대신 격리한다 트레이드오프 최종 일관성 : 응답 시점엔 임베딩이 없다. 변경이 몰리면 최대 80초 늦게 검색에 반영된다 → "실시간에 가까운"이 정확한 표현 멱등성 : SQS는 at-least-once이므로 재처리에 무해하도록 upsert 설계 정리 느린 작업은 요청 경로에서 떼어낸다 (접수/처리 분리) SQS로 부하를 평탄화하고, 동시 소비자 수로 성능을 조절 한다 동시성은 임베딩 속도가 아니라 DB 커넥션에서 역산 한다 → 100 대가는 최종 일관성이며, 지표로 통제한다

Offer details

Provider

velog

Source

velog-rss

Score

54.38

Confidence

49%