피드로 돌아가기
외부셀러 - 외부 스파크성 트래픽으로부터 내부 시스템을 보호하는 방법 1탄
올리브영 테크블로그올리브영 테크블로그
Backend

외부셀러 - 외부 스파크성 트래픽으로부터 내부 시스템을 보호하는 방법 1탄

올리브영이 외부셀러 서비스의 동기 방식 API를 비동기 이벤트 기반으로 전환해 내부 시스템 보호 및 사용자 응답 시간 단축

2023년 12월 15일8intermediate

Context

외부셀러 서비스가 쇼핑몰통합관리솔루션의 상품·주문·배송 API 요청을 동기 방식으로 처리하면서, 내부 올리브영 API의 Heavy한 작업(validation, 채번, 등록)이 완료될 때까지 외부 사용자가 대기해야 했다. 이로 인해 외부 셀러 서비스의 CPU/Memory가 상승하고, 네트워크 지연 시 정상 요청까지 실패 응답을 받게 되는 사용자 경험 악화 문제가 발생했다.

Technical Solution

  • 역할 기반 서버 분리: seller-external-api(요청 수신 및 필수 validation만 처리) + seller-internal-api(내부 API 연동 전담) 구조로 관심사 분리
  • AWS MSK 도입: 외부 요청과 내부 생산 프로세스 간 비동기 이벤트 전달 채널로 활용
  • Partition Key 지정: ProducerRecord에 상품 ID를 partitionKey로 설정해 동일 상품에 대한 메시지가 동일 파티션으로 라우팅되도록 보장 (Round Robin 방식 제거)
  • 재시도 로직 구현: seller-internal-api에서 내부 API 통신 시 네트워크 지연 또는 장애 발생 시 자동 재시도 기능 추가
  • 빠른 응답: seller-external-api가 메시지를 MSK로 전달한 후 즉시 사용자에게 응답 반환 (내부 처리 완료 대기 제거)

Impact

(아티클에 정량적 수치 미기재)

Key Takeaway

분산 시스템에서 외부 요청으로부터 내부 시스템을 보호하려면 요청 수신과 실제 처리를 비동기로 분리하고 메시지 큐를 통해 느슨한 결합을 유지해야 한다. 특히 순서 보장이 필요한 데이터 처리 시 Partition Key를 명시적으로 지정하지 않으면 분산 처리되어 일관성 문제가 발생할 수 있다.


동기 API로 인해 외부 스파이크 트래픽의 영향을 받는 서비스에서는 요청 수신 계층에서는 최소한의 validation만 수행 후 메시지 큐(Kafka, AWS MSK 등)로 이벤트를 발행하고, 별도의 워커 서비스가 순차 처리하도록 아키텍처를 전환하면 외부 사용자의 응답 시간을 단축하고 내부 시스템의 리소스 스파이크를 완화할 수 있다. 이때 상품 ID와 같은 partition key를 명시 지정해야 동일 엔티티의 메시지가 순서대로 처리된다.

원문 읽기
외부셀러 - 외부 스파크성 트래픽으로부터 내부 시스템을 보호하는 방법 1탄 | Devpick