Page History

...

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

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

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 프로토콜을 사용하여 안정적인 메시지 큐 제공
• 장점:
  • 메시징 시스템에 최적화
  • 확장 가능하며, 분산 아키텍처에서 활용 가능

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

이 코드는 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 → 해당 토픽을 구독한 모든 세션에 메시지를 전송