분산처리 Reactive 웹소켓 by 액터모델

Stateful VS Stateless

REST API (Stateless 방식)

✔ 개념

• REST API는 Stateless(상태 비유지) 방식으로 동작합니다.
• 클라이언트 요청(Request)은 항상 독립적으로 처리되며, 서버는 클라이언트의 이전 요청 상태를 기억하지 않습니다.
• 각 요청은 필요한 모든 정보를 포함해야 하며, 서버는 이를 기반으로 응답을 반환합니다.

✔ 장점

✅ 확장성(Scalability) 높음

• 서버는 클라이언트의 상태를 유지하지 않으므로 로드 밸런싱 및 수평 확장이 용이합니다.
• 여러 서버에서 요청을 처리해도 문제가 없으며, 서버 간 상태 동기화가 필요하지 않습니다.

✅ 단순하고 유지보수 용이

• 상태를 관리할 필요가 없기 때문에 개발이 단순하고 유지보수가 쉬워집니다.
• API 요청이 독립적이므로 디버깅과 로깅이 용이합니다.

✅ 캐싱 활용 가능

• HTTP 기반이므로 응답을 캐싱하여 성능을 최적화할 수 있습니다.
• 클라이언트 측에서 캐시를 활용하면 서버 부하를 줄일 수 있습니다.

❌ 단점

⛔ 실시간성이 부족함

• 클라이언트가 변경 사항을 지속적으로 확인하려면 주기적인 폴링이 필요하여 비효율적입니다.
• WebSocket처럼 서버에서 즉시 데이터를 Push할 수 없습니다.

⛔ 매 요청마다 인증이 필요

• Stateless 방식이므로 요청마다 인증 정보를 포함해야 하며, 이를 처리하는 과정에서 성능 오버헤드가 발생할 수 있습니다.
• JWT, OAuth와 같은 인증 토큰을 사용하여 이 문제를 해결할 수 있지만, 여전히 매 요청마다 인증 검증이 필요합니다.

🔹 WebSocket (Stateful 방식)

✔ 개념

• WebSocket은 Stateful(상태 유지) 방식으로 동작하며, 클라이언트와 서버 간의 지속적인 연결(Persistent Connection)을 유지합니다.
• 한 번 연결되면, 양방향 통신(Bi-directional Communication)이 가능하며, 서버는 클라이언트의 상태를 기억하고 필요할 때 데이터를 Push할 수 있습니다.

✔ 장점

✅ 실시간 데이터 전송 최적화

• 서버는 클라이언트의 요청 없이도 데이터를 즉시 전송(Push)할 수 있어, 실시간 애플리케이션(예: 채팅, 주식 거래, 게임)에 적합합니다.

✅ 네트워크 오버헤드 감소

• REST API와 달리, 매 요청마다 새로운 연결을 생성하지 않으므로 네트워크 리소스 사용이 효율적입니다.
• 연결이 유지되므로 인증 과정을 한 번만 수행하면 됩니다.

✅ 양방향 통신 가능

• REST API는 클라이언트 → 서버 방향의 요청-응답 방식이지만, WebSocket은 서버 → 클라이언트도 가능하여 보다 유연한 데이터 흐름을 제공합니다.

❌ 단점

⛔ 확장성이 낮음

• 서버가 각 클라이언트와의 연결을 유지해야 하므로 많은 사용자가 접속할 경우 리소스 부담이 증가합니다.
• 로드 밸런싱이 어렵고, 클러스터링 시 세션 공유 또는 연결 유지 로직이 추가적으로 필요합니다.

⛔ 복잡한 상태 관리 필요

• 연결 상태를 유지해야 하므로, 클라이언트가 예기치 않게 연결 해제되거나 재접속할 경우 상태를 관리하는 추가적인 로직이 필요합니다.
• 예: 세션 유지, 연결 끊김 감지, 재연결 로직 구현.

⛔ 브라우저 및 네트워크 제한 사항 존재

• 방화벽, 프록시 등의 네트워크 환경에서 WebSocket 연결이 차단될 수 있습니다.
• HTTP 기반보다 보안 및 안정성을 고려한 추가적인 설정이 필요할 수 있습니다.

🔹 어떤 방식을 선택해야 할까?

✔ REST API가 적합한 경우

• 요청과 응답이 독립적인 경우 (예: CRUD API, 데이터 조회 서비스)
• 서버 확장성과 유지보수가 중요한 경우
• 네트워크 및 보안 이슈가 신경 쓰이는 경우

✔ WebSocket이 적합한 경우

• 실시간성이 중요한 경우 (예: 채팅, 스트리밍, 주식 데이터, 게임)
• 양방향 통신이 필요한 경우 (예: P2P 연결)
• 연결 유지가 가능하고 성능 최적화가 필요한 경우

Spring WebFlux의 org.springframework.web.reactive.socket 기반의 웹소켓과 전통적인 Spring MVC 기반 웹소켓을 비교해보겠습니다.

1. 아키텍처적 차이

2. 성능 및 확장성

• WebFlux 기반 웹소켓은 비동기 이벤트 기반 모델이기 때문에 최소한의 리소스로 높은 동시성을 처리할 수 있습니다.
• 반면 Spring MVC 웹소켓은 Blocking 모델로서 요청당 하나의 스레드를 할당해야 하므로 동접자가 많아질수록 성능 저하가 발생할 수 있습니다.

3. 프로그래밍 모델 차이

✅ Spring WebFlux 웹소켓 (비동기, 리액티브)

@Component
class ReactiveWebSocketHandler : WebSocketHandler {
    override fun handle(session: WebSocketSession): Mono<Void> {
        val input = session.receive()
            .map { it.payloadAsText }
            .doOnNext { println("Received: $it") }

        val output = Flux.interval(Duration.ofSeconds(1))
            .map { "Server response $it" }
            .map(session::textMessage)

        return session.send(output)
    }
}

✅ Spring MVC 웹소켓 (동기, Blocking)

@Controller
class TraditionalWebSocketHandler {

    @MessageMapping("/message")
    @SendTo("/topic/response")
    fun handleMessage(message: String): String {
        println("Received: $message")
        return "Server response: $message"
    }
}

4. 사용 시 고려 사항

✅ WebFlux 웹소켓이 유리한 경우

• 대규모 동시 연결 처리 (ex. 실시간 채팅, 금융 데이터 스트리밍)
• 리소스가 제한적인 환경 (ex. 마이크로서비스)
• Reactive Stack을 기반으로 애플리케이션을 구축할 경우
• Netty 기반 서버를 사용할 때 최적화된 성능 제공

✅ Spring MVC 웹소켓이 유리한 경우

• 기존 MVC 프로젝트와의 통합이 필요할 경우
• 비교적 적은 연결 수를 처리하는 서비스 (ex. 내부 알림 시스템)
• 기존의 @Controller 기반 프로그래밍이 익숙한 경우
• 톰캣(Tomcat)을 사용해야 하는 경우 (WebFlux는 기본적으로 Netty를 사용)

5. 정리

🔥 결론

• 대규모 동시 연결 및 성능이 중요한 서비스에서는 Spring WebFlux의 비동기 리액티브 웹소켓이 적합합니다.
• 기존 Spring MVC 기반 프로젝트와의 호환성이 중요하고, 동접자가 많지 않다면 전통적인 Spring MVC 웹소켓이 더 쉬운 선택이 될 수 있습니다.

🚀 즉, 성능과 확장성이 중요한 경우 WebFlux, 익숙한 개발 방식과 기존 시스템 통합이 중요한 경우 MVC 웹소켓을 선택하는 것이 좋습니다.

✅ 액터 모델 vs 스레드 모델 비교 요약

🚀 액터 모델의 주요 장점

• 고성능 동시성 처리 (수백만 개 액터 운영 가능)
• 데드락 없는 안정적인 상태 관리 (Lock-Free)
• 확장성 뛰어난 구조 (Akka Cluster, Pekko 활용 가능)
• 분산 시스템에 적합 (분산 액터로 수평 확장 가능)

👉 멀티스레드 환경의 동시성 이슈(Lock, 데드락, 컨텍스트 스위칭)를 해결하고, 확장성과 안정성을 극대화한 모델! 🚀

🔹 액터 모델을 채택한 메시징/메신저 시스템

1. WhatsApp

• 기술 스택: Erlang 기반
• 특징:
  • Erlang의 BEAM VM에서 동작하는 **Erlang OTP(Actor 기반 시스템)**을 활용
  • 수백만 개의 동시 연결을 지원하는 강력한 메시징 처리 능력
  • 고가용성을 위해 분산 시스템으로 설계됨
• 장점:
  • 낮은 오버헤드와 높은 동시성을 지원
  • 메시지 큐와 액터 기반 모델을 통해 안정적인 메시징 서비스 제공

2. Telegram

• 기술 스택: Erlang 및 C++
• 특징:
  • 서버는 Erlang과 C++로 구축되었으며, 내부적으로 액터 모델을 활용하여 비동기 메시지 처리
  • MTProto 프로토콜을 사용하여 효율적인 메시지 전송
  • 분산된 데이터 센터 구조를 통해 성능 최적화
• 장점:
  • 빠른 메시지 처리 및 낮은 지연 시간
  • 확장성이 뛰어난 아키텍처

3. Microsoft Orleans

• 기술 스택: .NET 기반 액터 모델 프레임워크
• 특징:
  • 마이크로소프트에서 개발한 가상 액터(Virtual Actor) 모델을 제공
  • 내부적으로 Skype, Xbox, Teams의 메시징 시스템에 활용
  • 분산 환경에서 동적인 액터 생성을 지원하여 대규모 메시징 시스템 구축 가능
• 장점:
  • 비동기 메시지 처리를 최적화
  • 클라우드 환경(Azure)에서 강력한 확장성 제공

4. Akka 기반 메시징 시스템

• 기술 스택: Scala, Java, Kotlin
• 특징:
  • **Akka (현재 Apache Pekko)**를 활용하여 분산된 메시지 기반 시스템 구축
  • Persistent Actor를 활용한 상태 유지형 메시징 가능
  • Event Sourcing + CQRS 패턴을 적용할 수 있어 메시지 로그 기반의 안정적인 설계 가능
• 사례:
  • LinkedIn: Akka 기반 메시징 시스템 사용
  • Guardian 뉴스: Akka Streams 기반 스트리밍 서비스 구축
  • Signal(부분적으로 Akka 사용)

5. RabbitMQ (Erlang 기반)

• 기술 스택: Erlang
• 특징:
  • 메시지 브로커로 사용되지만, 내부적으로 Erlang의 액터 모델을 활용하여 높은 동시성 처리 가능
  • AMQP 프로토콜을 사용하여 안정적인 메시지 큐 제공
• 장점:
  • 메시징 시스템에 최적화
  • 확장 가능하며, 분산 아키텍처에서 활용 가능

6. Apache Flink

• https://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/what-is.html
• https://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/flink-1-18.html
  • Akka(Pekko)가 코어처리 모듈로 채택됨

7. Ray

• https://docs.ray.io/en/latest/ray-core/actors.html
  • OpenAI가 ML 파이프라인용으로 채택해 알려진 ray도 액터 프레임워크입니다. ( 파이썬진영 )

🚀 분석: 액터 모델과 웹소켓 연동의 장점

이 코드는 Akka (현재 Apache Pekko) 기반 액터 모델을 활용하여 **웹소켓을 관리하는 세션 관리자(SessionManagerActor)**를 구현한 것입니다.
액터 모델이 웹소켓과 연동될 때 가지는 장점은 다음과 같습니다.

🔹 1. 높은 동시성 및 확장성 (Scalability & Concurrency)

• 문제: 웹소켓 연결은 지속적인 세션을 유지해야 하며, 많은 사용자가 접속할 경우 서버 부담이 증가할 수 있음.
• 해결: 액터 모델을 사용하면 각 클라이언트의 세션을 독립적인 액터(Actor)로 관리할 수 있음.
• 효과:
  • 액터는 경량 스레드로 동작하므로 수십만 개의 웹소켓 연결도 효율적으로 처리 가능
  • 세션 관리를 비동기 메시징 기반으로 처리하여 블로킹을 방지
  • 수평 확장(Scale-out)이 용이하여, 클러스터링(Akka Cluster)과 연계하면 더 많은 사용자를 처리 가능

💡 예제 코드 적용:

• sessions: ConcurrentHashMap<String, WebSocketSession> : 액터 내부에서 웹소켓 세션을 관리
• 각 명령(UserSessionCommand)이 액터 간 메시지로 전달되어 병렬로 처리됨

🔹 2. 상태(State) 유지 및 장애 복구 (Fault Tolerance)

• 문제: 일반적인 REST API 기반의 웹소켓 관리 시스템에서는 클라이언트 상태를 별도로 관리해야 하며, 장애 발생 시 복구가 어렵다.
• 해결: 액터 모델을 활용하면 각 웹소켓 세션을 하나의 액터 단위로 관리하여 상태를 자연스럽게 유지할 수 있음.
• 효과:
  • 액터 모델 자체가 상태 기반(Stateful) 아키텍처이므로, 세션과 구독 정보를 쉽게 유지
  • 장애 발생 시 해당 액터만 복구하여 서비스 중단을 최소화
  • Akka Persistence 적용 시 세션 및 구독 정보를 이벤트 소싱 기반으로 저장하여 장애 이후에도 빠른 복원 가능

💡 예제 코드 적용:

• sessions.remove(command.session.id) → 연결이 끊어진 세션을 자동으로 정리
• topicSubscriptions.computeIfAbsent(command.topic) { mutableSetOf() }.add(command.sessionId) → 액터가 상태를 직접 유지하므로 상태 복원 가능

🔹 3. 비동기 이벤트 기반 처리 (Reactive & Event-driven)

• 문제: 웹소켓은 실시간 이벤트 처리가 핵심이지만, 기존 REST 기반 시스템에서는 동기적인 요청-응답 구조로 인해 이벤트 처리의 유연성이 떨어짐.
• 해결: 액터 모델은 **비동기 메시지 패싱(Asynchronous Message Passing)**을 기반으로 동작하며, 웹소켓과 자연스럽게 연계됨.
• 효과:
  • 클라이언트가 특정 토픽을 구독(Subscribe)하면 액터가 이벤트를 관리하고 비동기적으로 메시지를 Push
  • 대량의 클라이언트에게 동시에 이벤트를 전달 가능 (예: 실시간 채팅, 알림 시스템)
  • REST API 기반의 Polling 없이 서버에서 직접 푸시(Push) 가능

💡 예제 코드 적용:

• UserSessionCommand.SendMessageToTopic → 특정 토픽을 구독한 모든 세션에 비동기 푸시
• UserSessionCommand.SendMessageToSession → 특정 세션에 개별적으로 메시지 전송

🔹 4. 트래픽 부하 감소 (Efficient Resource Utilization)

• 문제: 대규모 웹소켓 연결을 유지하는 것은 서버 리소스 부담이 크며, 특히 HTTP Polling을 사용할 경우 네트워크 오버헤드가 증가함.
• 해결:
  • 액터 모델은 자체적으로 비동기 메시지 큐 역할을 수행하여 네트워크와 CPU 부하를 최소화
  • 액터 간 직접 메시지 전송이 가능하여 불필요한 HTTP 요청을 제거
• 효과:
  • 네트워크 오버헤드 최소화 (웹소켓은 한 번 연결되면 지속 유지)
  • 클라이언트가 필요할 때만 메시지를 푸시 받도록 최적화
  • HTTP Polling과 비교하면 서버 부하가 현저히 줄어듦

💡 예제 코드 적용:

• sendService.sendEventTextMessage → 웹소켓을 통해 바로 클라이언트에 메시지 전송
• topicSubscriptions → 불필요한 요청 없이 미리 등록된 구독자를 대상으로 메시지를 브로드캐스트

🔹 5. 확장성 있는 토픽 기반 메시징 시스템 (Scalable Pub/Sub Architecture)

• 문제: 단순한 클라이언트-서버 메시징 모델은 확장성이 떨어지며, 많은 클라이언트가 특정 이벤트를 구독할 경우 관리가 어려움.
• 해결:
  • 액터 모델은 Publish-Subscribe 패턴을 자연스럽게 지원하며, 토픽(Topic) 기반 메시지 브로드캐스팅이 가능
  • 추가적으로 Kafka, Redis Pub/Sub 등과 연계하면 더욱 확장 가능
• 효과:
  • 특정 주제(Topic)에 대한 구독/해지를 쉽게 관리
  • 대규모 실시간 방송 시스템(예: 주식 거래, 뉴스 알림, 스포츠 경기 알림)에 적합

💡 예제 코드 적용:

• onSubscribeToTopic → 클라이언트가 특정 토픽을 구독하면 세션 ID를 저장
• onSendMessageToTopic → 해당 토픽을 구독한 모든 세션에 메시지를 전송

고성능 IO

도입시 로드테스트 사례및 글로벌 기업

• Server For LoadTest
• https://theworkshop.com/

소개가 길었지만~ 본방인 Reactive Websocket과 액터모델을 연동하는 샘플코드를 살펴보겠습니다.

Reactive Websocket with ActorModel 구현체

• 샘플코드
• 유닛테스트 코드

구현샘플 코드

• base : pub/sub을 로컬클래스 모델로 구현한 기본 Reactive 사용법입니다.
• actor : base버전의 로컬클래스 모델을 로컬액터모델로 변환한 ActorModel버전입니다.

위 버전은 로컬로 작동되며 , 액터모델을 최초한번 연동하고 나면 액터모델 자체만으로 리모트/클러스터 등으로 확장할수 있습니다.

약간의 액터를 배치하고 Discovery요소및 영속성장치를 활용하게 되지만 핵심은 외부장치의 변화로 도메인을 처리하는 액터로직의 코드 수정이 없다는것이 가장 큰장점이며 이러한 장점으로 액터모델의 학습곡선과 장치를 이해한다고 가정하면

외부장치의 도움없이 로컬 Only 모놀리식으로 시작해 기능구현을 모두 해도 나중에 MSA로 확장시 기존 구현된 코드를 변경할 필요 없는것이 액터모델의 큰장점입니다.

로컬액터가 구현되었을때 확장하는 샘플코드는 별도로 구분하였으며 모든 구현코드는 유닛테스트로 코드를 설명하며 활용방법을 알수 있습니다.

확장하기

• 샘플코드
• 유닛테스트 코드

확장 장치및 설명

• core : actor 모델의 기본 사용법
• discovery : 액터모델을 위치투명성 기법을 이용해 사용하기 ( 로컬에서 필요없지만 클러스터로 확장될시 필요한 개념)
• persitent : 이벤트소싱 durable을 포함 액터모델의 이벤트를 영속화(db장치 선택가능)하는 CQRS 기법을 학습
  • state : repository 패턴을 활용해 액터모델의 상태를 동기화하는 예제 ( Redis장치에 대응하고 저비용으로 더 빠르게 사용 )
• timer : 액터모델에 스케줄러 기능을 부여해, 수십만개의 독립적 가능 타이머 생성가능  ( 스레드 모델에 대응)
• bulkprocessor : realTime 에서 발생하는 이벤트를~ 효율적으로 저장해 DB부하를 획기적으로 줄입니다. - 데이터를 부분 지속처리 
• router : 액터메시지를 분배처리하는 라우팅 장치 ( 라운드로빈,해쉬로빈등 다양한 분배장치를 채택할수도 커스텀할수도 있음)
• supervisor : 호출자에게 예외를 전파하는 전통적 장애복구 방식이 아닌  부모가 자식객체를 모니터링해 복구하는 전략 방식
• stream : reactive stream 을 준수하는 장치를 활용해 액터모델과 연결하는 샘플 ( kafka등의 외부 장치와 연결 )
• cluster : 로컬로 잘 작성된 액터모델을 클러스터화합니다. 기존 코드의 변경을 최소화하고 클러스터화 시스템에 액터를 배치하게됩니다.

다음장에서는 웹소켓과 여기에 연결된 액터모델을 비동기 수신검사하는 유닛테스트를 알아보겠습니다.

Next : UnitTest Reactive Websocket&Actor