728x90
반응형

SSE + Kafka + Agent + Redis(선택) 조합은 "SAP ERP 연동을 위한 비동기 전표 처리 시스템"을 구축하는 데 매우 적합합니다.

✅ 아키텍처 개요 (전체 흐름)

[외부 백오피스 (Web)]
   └─ REST API 호출 (전표 처리 요청)
        ▼
[Agent API (Spring Boot)]
   ├─ 저장: Kafka에 전표 처리 이벤트 publish
   ├─ Redis (optional): 캐시 또는 일시 상태 저장
   └─ 응답: 202 Accepted + trackingId

[Kafka Broker]
   └─ 전표 처리 이벤트 Queue

[Agent Consumer (Spring Boot)]
   └─ Kafka에서 consume → SAP OData/SOAP 호출
   └─ 결과 수신 후 상태 저장(DB or Redis)

   └─ 처리 결과 → 백오피스에 전달 (SSE push)

[브라우저 SSE 연결]
   └─ /sse?ids=... 연결 유지 중
   └─ 처리 결과 오면 실시간 알림

[Optional] Redis
   └─ 상태 캐시 (e.g. tx 상태 빠르게 조회)

🧱 컴포넌트별 역할

구성 요소역할
Agent API 외부 요청 수신, Kafka publish, trackingId 발급
Kafka 전표 처리 요청을 비동기 이벤트로 큐잉
Agent Consumer Kafka 메시지 consume → SAP 호출 → 결과 처리
Redis (optional) 처리 상태 cache (e.g. polling 응답 빠르게), TTL 관리
SSE Controller 브라우저와 연결 유지하며 처리 결과 push
백오피스 SSE를 통해 상태 실시간 반영 (F5 없이)
 

🧠 Redis를 "쓸까 말까" 판단 기준

항목Redis 사용하는 경우사용하지 않아도 되는 경우
상태 응답 속도 상태 조회가 빈번하고 빠른 응답 원할 때 상태 조회가 드물고 DB 성능 충분할 때
polling fallback SSE 외에 polling도 지원할 때 SSE만으로 충분할 때
결과 TTL 관리 "전표 처리 후 10분간 상태 유지" 등 캐시 처리 결과를 영구 저장할 때 (DB만으로도 OK)
다중 노드 확장 Agent를 다중 인스턴스로 돌릴 때 상태 공유 단일 서버 구조일 때는 생략 가능
 
반응형

✅ 결론: Redis는 선택 사항이지만 polling + 고속 상태 응답을 고려하면 사용하는 것이 좋습니다.

📦 Kafka 메시지 예시 (전표 처리 요청)

{
  "trackingId": "tx-20240617-00123",
  "sapData": {
    "companyCode": "1000",
    "amount": 120000
  },
  "callbackType": "SSE"
}

🧭 처리 흐름 다이어그램

 [백오피스]
     │   POST /request
     ▼
 [Agent API] ───────────────┐
     │ produce to Kafka     │
     ▼                      │
 [Kafka Broker]             │
     ▼                      ▼
 [Agent Consumer] ──▶ SAP 호출
     │
     ├─ 상태 저장 (Redis/DB)
     └─ SSE Push or Callback

 [브라우저] ←───────┘

🔐 인증/보안 설계

항목권장 방식

 

외부 요청 → Agent JWT 또는 HMAC 서명
Kafka 메시지 내부망 또는 SASL 인증
SAP 호출 OAuth2.0 Client Credentials
SSE 로그인된 사용자만 /sse 허용 (토큰 or 세션 기반)
 

✅ 아키텍처 선택 요약

항목사용 여부설명
Kafka ✅ 필수 Agent ↔ SAP 비동기 처리용
SSE ✅ 필수 사용자 브라우저 실시간 반영
Redis ⚙️ 선택 빠른 상태 응답용 (polling 대응, TTL용)
DB ✅ 필수 트래킹, 로그, 재처리 이력 관리용
WebSocket ❌ 생략 SSE로 충분함
REST Callback ⛔ 대체 가능 SSE 사용 시 별도 callback 불필요
 

💡 확장 고려 시

  • Kafka → Kafka Streams or Debezium 기반 audit trail 확장 가능
  • SSE + Webhook 병행 지원 구조도 가능 (B2B/B2C 이중 대응)
  • Redis 없애고 DB polling만으로도 충분한 경우 존재 (단 소규모)
728x90
반응형
저작자표시 동일조건 (새창열림)

'IT' 카테고리의 다른 글

WebSocket, TCP Socket, WebRTC 상세 비교  (0) 2025.06.24
EAI 시스템에서 동적 배포(Dynamic Deployment)  (0) 2025.06.18
Server Stub이란?  (0) 2025.06.16
Spring Boot에서 OpenAPI 기반 서버 스텁(Server Stub) 생성  (2) 2025.06.16
OpenAPI란?  (0) 2025.06.16
728x90
반응형

pring WebFlux의 WebClient는 기존의 RestTemplate보다 훨씬 강력하고 유연한 HTTP 클라이언트입니다.
특히 비동기/논블로킹 I/O 기반으로 만들어져 있기 때문에, 대규모 API 호출 처리, 마이크로서비스 환경, 고성능 서버에 적합합니다.

✅ WebClient 주요 장점 요약

항목설명
💡 비동기 / 논블로킹 Mono, Flux 기반으로 리액티브 스트림 처리 가능. 적은 리소스로 많은 동시 요청 처리
🧵 스레드 효율 극대화 동기 방식보다 훨씬 적은 스레드로 높은 처리량 유지 가능
🌐 RESTful API 호출 최적화 GET/POST/PUT/DELETE 등 모든 메서드 지원. 유연한 요청 구성
🔗 함수형 체이닝 .get().uri().retrieve().bodyToMono() 등 간결하고 직관적
🔐 OAuth2, Bearer 등 인증 용이 인증 헤더, 토큰 주입 등 손쉬움 (filter, mutate)
🛡️ 타임아웃 / 재시도 / fallback 설정 용이 Resilience4j 등과 궁합 좋음
📦 백프레셔(Backpressure) 소비량 제어 가능 → 부하 조절에 유리
🔁 스케줄/폴링/Streaming API 지원 SSE, WebSocket, Kafka REST 등과 쉽게 연동 가능
🧪 테스트 용이 MockWebServer 또는 WebClient.Builder로 쉽게 테스트 가능
 

 

📊 WebClient vs RestTemplate

 

항목 WebClient RestTemplate
처리 방식 비동기/논블로킹 동기/블로킹
성능 고성능, 고동시성에 유리 스레드당 1요청
사용성 함수형, 유연 단순하지만 유연성 낮음
미래성 ✅ Spring 공식 권장 🚫 Deprecated 예정 (RestTemplate)
 

✅ Spring 공식 문서에서는 WebClient를 새로운 HTTP 클라이언트로 권장하고 있으며,
RestTemplate은 향후 유지보수만 되고 기능 추가는 중단되었습니다.

💡 실무 사용 예시: 마이크로서비스 간 통신

WebClient.create("https://user-service")
         .get()
         .uri("/users/{id}", userId)
         .retrieve()
         .bodyToMono(UserDto.class)
         .timeout(Duration.ofSeconds(3))
         .retry(2)
         .subscribe(user -> log.info("사용자 정보: {}", user));

🚀 언제 WebClient를 써야 하나요?

상황권장 여부
다량의 외부 API 호출 ✅ 매우 적합
비동기 스트리밍 필요 ✅ 매우 적합 (ex: SSE, WebSocket)
단순 API 1~2건 RestTemplate도 가능하지만 WebClient로 전환 권장
마이크로서비스 통신 ✅ WebClient + Resilience4j + Retry 매우 효과적
 

🧠 결론

WebClient는 비동기, 고성능, 미래 지향적 HTTP 클라이언트이며,
특히 타사 API 연동, 마이크로서비스 환경에서 필수 도구로 자리잡고 있습니다.

728x90
반응형
저작자표시 동일조건 (새창열림)

'Java' 카테고리의 다른 글

Google Calendar API에 일정(Event)을 추가(POST)  (1) 2025.06.16
Spring WebClient기반 Google OAuth2 인증  (0) 2025.06.16
Spring WebFlux의 WebClient 기반의 CircuitBreaker 및 Retry 기능을 적용한 실무 예제  (1) 2025.06.16
RetryTemplate 과 CircuitBreaker  (0) 2025.06.16
G1 GC 관리 항목별 Default 값 및 권장 설정  (1) 2025.05.14
728x90
반응형

최근 실시간 웹 애플리케이션의 중요성이 증가하면서, Spring의 WebFlux와 **Server-Sent Events(SSE)**가 많은 주목을 받고 있습니다. 이번 글에서는 WebFlux와 SSE의 특징과 사용 이유를 명확히 이해하고 장단점 및 실전 예제를 통해 알아보겠습니다.

📌 WebFlux와 SSE란?

  • WebFlux
    Spring의 리액티브 웹 프레임워크로, 비동기(Asynchronous), 논블로킹(Non-blocking) 방식의 요청 처리를 지원하여 동시성과 확장성을 극대화한 웹 애플리케이션을 개발할 수 있게 합니다.
  • Server-Sent Events(SSE)
    클라이언트와 서버 간 단방향으로 실시간 이벤트 데이터를 전달할 수 있는 웹 표준 기술입니다. 주로 서버가 클라이언트로 계속해서 데이터를 실시간으로 보내는 환경에 적합합니다.

🚀 WebFlux SSE를 사용하는 이유

✅ 1. 실시간 데이터 스트리밍 지원

  • 주식 시세, 뉴스 알림, 시스템 모니터링 등 데이터를 지속적이고 실시간으로 전달할 수 있습니다.

✅ 2. 비동기, 논블로킹 처리

  • 많은 동시 접속자가 있더라도 적은 자원으로 효율적이고 빠르게 이벤트를 전달할 수 있습니다.

✅ 3. 경량 프로토콜 활용

  • WebSocket 대비 프로토콜 자체가 단순하며, HTTP 표준만으로도 쉽게 구현할 수 있습니다.

✅ 4. 손쉬운 브라우저 호환성

  • 별도의 플러그인이나 복잡한 설정 없이 HTML5를 지원하는 모든 브라우저에서 사용 가능합니다.

🎯 WebFlux SSE 예시 코드 (Spring Boot WebFlux)

💻 서버측 코드 예제 (Java)

import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import reactor.core.publisher.Flux;
import java.time.Duration;

@RestController
public class SSEController {

    @GetMapping(value = "/stream-sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> streamEvents() {
        // 1초 간격으로 클라이언트에 메시지 전송
        return Flux.interval(Duration.ofSeconds(1))
                   .map(sequence -> "SSE Event - " + sequence);
    }
}

위 코드에서 Flux는 비동기 스트림으로, 서버가 클라이언트에 1초마다 지속적으로 이벤트를 전달하는 예시입니다.

🌐 클라이언트 측 JavaScript 코드 예시

 
<!DOCTYPE html>
<html>
<body>
    <div id="events"></div>
    <script>
        const events = new EventSource('/stream-sse');
        
        events.onmessage = (event) => {
            document.getElementById("events").innerHTML += `<p>${event.data}</p>`;
        };

        events.onerror = () => {
            console.error("Error occurred");
            events.close();
        };
    </script>
</body>
</html>

위의 코드에서 JavaScript의 EventSource를 사용하여 서버로부터 오는 SSE 데이터를 실시간으로 처리하고 웹 페이지에 표시합니다.

📈 WebFlux SSE의 장점과 단점

🔥 장점

  1. 빠른 성능 및 확장성
    • 논블로킹 모델로 인해 다수의 동시 연결 처리 시 매우 효율적입니다.
  2. 쉬운 브라우저 지원
    • 모든 최신 브라우저가 기본적으로 SSE를 지원하므로 별도의 호환성 처리 필요 없음.
  3. 리소스 효율성
    • 별도의 풀링이나 연결 관리 복잡성이 없어서 서버 리소스 소모가 적습니다.
  4. 단순한 구현
    • 웹소켓(WebSocket)에 비해 구현이 훨씬 간편하고 직관적입니다.

⚠️ 단점

  1. 단방향 통신 제한
    • 클라이언트가 서버에 메시지를 보내는 기능이 없으며 단지 서버가 클라이언트로 보내는 데이터만 전달 가능.
  2. HTTP 프로토콜 제약
    • HTTP 프로토콜 위에서 동작하므로 Header 크기 제한, 커넥션 타임아웃 관리 등 제약 사항 존재.
  3. 대규모 양방향 통신에는 부적합
    • 양방향 상호작용이 필수적인 채팅이나 게임과 같은 애플리케이션에서는 WebSocket이 더 효율적입니다.

📊 SSE vs WebSocket 비교 간단 정리

항목 SSE WebSocket
통신 방식 단방향 (서버→클라이언트) 양방향(서버↔클라이언트)
프로토콜 HTTP WebSocket 전용 프로토콜
연결 복잡성 간단하고 연결 유지 용이 상대적으로 복잡한 핸드셰이크 과정
브라우저 지원 HTML5에서 바로 지원 HTML5에서 지원
사용 분야 실시간 알림, 스트림 데이터 양방향 채팅, 게임, 실시간 협업

📍 WebFlux SSE를 언제 사용하면 좋을까?

  • 실시간 알림 서비스 (채팅 알림, SNS 알림 등)
  • 실시간 데이터 스트리밍 서비스 (주식 시세, 경기 실시간 스코어, 뉴스 피드)
  • 실시간 모니터링 시스템 (서버 상태 체크, 실시간 분석 대시보드)

반면, 양방향 채팅이나 실시간 협업 도구 같은 경우라면 WebSocket을 고려하는 것이 더 효율적입니다.

🚩 결론 및 추천

  • WebFlux의 SSE는 효율적이며 손쉬운 실시간 데이터 전달 방법을 제공합니다.
  • 실시간 데이터를 지속적으로 클라이언트에게 전달할 필요가 있으며, 단방향 통신이면 SSE가 최적입니다.
  • 양방향 통신이 필수적인 경우는 WebSocket 등 다른 솔루션을 선택하는 것이 좋습니다.

실제 서비스의 특성과 요구사항에 따라 WebFlux와 SSE 기술을 적절히 선택하여 최적의 성능을 얻으시길 바랍니다!

728x90
반응형
저작자표시 동일조건 (새창열림)

'Java > Basic' 카테고리의 다른 글

로깅 프레임워크 선택  (0) 2025.03.25
Spring vs. NestJS 상세 비교  (0) 2025.03.24
Filter(필터)란?  (0) 2025.03.24
HttpServletResponse와 getOutputStream() 정리  (0) 2025.03.24
Java 11 vs 17 vs 21: 주요 변화와 코드로 살펴보기  (0) 2025.03.24

+ Recent posts

티스토리툴바