비동기 요청-응답 패턴으로 풀어낸 발주 서비스 개발기

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

백엔드 개발자, DevOps 엔지니어, 고부하 시스템 아키텍처 설계자

핵심 요약

• 비동기 처리 도입을 통해 발주 처리 시간을 수분에서 즉시 응답으로 단축
• 그룹 기반 DTO 구조로 유효성 검증 중복을 70% 이상 줄임
• Kafka + 요청-응답 패턴으로 비동기 처리 결과 추적 문제 해결

섹션별 세부 요약

1. 기존 발주 시스템 문제점

• 동기식 처리로 5,000건 처리 시 5~10분 지연 발생
• 유효성 검증 단계에서 중복 검증(예: 매장 코드, 발주일자 등 반복 입력)으로 리소스 낭비
• 서버 메모리 과부하로 인한 간헐적 처리 장애 발생

2. 아키텍처 개선 방안

• 그룹 기반 DTO로 헤더 레벨(물류센터, 발주일자)과 상품 리스트 분리
• ```java

public class OrderGroupDTO {

private String warehouseCode;

private LocalDate orderDate;

private List items;

}

```

• 유효성 검증 로직을 그룹 단위로 수행하여 처리 시간 60% 단축

3. Kafka 기반 비동기 처리 도입

• Kafka로 메시지 전송 → 별도 Consumer에서 발주 처리
• ```kotlin

producerRecord.headers().add(KafkaHeaders.REPLY_TOPIC, "order-reply-topic".toByteArray())

```

• at-least-once 보장으로 중복 처리 방지 위해 Unique Index 기반 요청 이력 DB 설계

4. 요청-응답 패턴 구현

• ReplyingKafkaTemplate 사용 → sendAndReceive 메서드로 비동기 응답 처리
• ```java

public RequestReplyFuture sendAndReceive(ProducerRecord record) {

record.headers().add(KafkaHeaders.CORRELATION_ID, UUID.randomUUID().toString());

}

```

• CORRELATION_ID로 요청-응답 연결 고리 구축

5. 설계 검토 및 최종 아키텍처

• 1차 설계(API Polling) → 요청 이력 ID 누락 문제 발생
• 2차 설계(ReplyingKafkaTemplate) → Kafka 의존성 문제로 포기
• 최종 설계(API + Kafka 하이브리드)

- 요청 시 API 응답에 이력 ID 포함

- Kafka로 처리 결과 전송 → @SendTo 어노테이션으로 응답 토픽 설정

결론

• 하이브리드 아키텍처로 성능/안정성 균형 달성
• Kafka 설정 시 group.id 고유성(UUID), auto.offset.reset=latest 필수
• 요청-응답 패턴에서 CORRELATION_ID는 요청/응답 연결 핵심 요소
• 중복 처리 방지 위해 Unique Index 기반 요청 이력 DB 설계 필수