본문에서는 Ruby on Rails 애플리케이션에서 가능한 아키텍처 유형과 이벤트 기반 아키텍처(EDA)의 핵심 요소를 심층적으로 다룹니다.
Ruby on Rails 애플리케이션 아키텍처 유형
Rails 애플리케이션은 목적과 규모에 따라 다양한 아키텍처를 채택할 수 있습니다.
-
모놀리스(Monolith): 모든 기능이 하나의 코드베이스에 통합된 전통적인 방식입니다. 신제품의 빠른 시장 출시 및 MVP 단계의 스타트업에 적합하며, 개발, 테스트, 배포가 간단합니다.
-
마이크로서비스(Microservices): 대규모 애플리케이션을 작고 독립적인 서비스들로 분리합니다. 각 서비스는 특정 기능에 특화되어 있으며, 대규모 확장이 필요한 복잡한 플랫폼에 적합합니다.
-
이벤트 기반 아키텍처(EDA): 서비스들이 직접 명령하는 대신 ‘이벤트’를 통해 간접적으로 통신합니다. 하나의 행동에 여러 반응이 필요한 복잡한 워크플로우를 가진 애플리케이션에 최적화되어 있으며, Zeitview와 같은 SaaS 플랫폼에서 서비스 간 협업 강화에 활용될 수 있습니다.
이벤트 기반 아키텍처의 핵심 구성 요소
EDA는 다음 네 가지 주요 구성 요소의 조화를 통해 작동합니다.
-
이벤트(Events): 시스템에서 발생한 중요한 사실을 기록한 불변의 메시지입니다. (예: OrderPlaced, UserSignedUp)
-
이벤트 생산자(Event Producers): 이벤트를 생성하고 발행하는 부분입니다. 생산자는 이벤트를 누가 소비할지 알지 못합니다.
-
이벤트 브로커(Event Brokers): 생산자로부터 이벤트를 받아 하나 이상의 소비자에게 라우팅하는 중앙 허브 역할을 합니다. Rails에서는 ActiveSupport::Notifications, Redis(Sidekiq), RabbitMQ, Kafka 등이 사용될 수 있습니다.
-
이벤트 소비자(Event Consumers): 관심 있는 이벤트를 구독하고 이에 반응하는 부분입니다. 여러 소비자가 동일한 이벤트에 독립적으로 반응할 수 있어 모듈성과 확장성을 높입니다.
EDA의 이점 및 한계
이점:
-
느슨한 결합(Loose coupling): 구성 요소 간의 직접적인 의존성을 줄여 유지보수 및 확장을 용이하게 합니다.
-
향상된 확장성(Improved scalability): Kafka와 같은 이벤트 기반 시스템을 통해 대규모 메시지 처리가 효율적입니다.
-
더 나은 시스템 관찰 가능성(Better system observability): 이벤트 로깅 및 저장을 통해 시스템 동작 추적이 용이합니다.
-
비동기 처리(Asynchronous processing): 무거운 작업을 백그라운드로 오프로드하여 애플리케이션 반응성을 높입니다.
한계:
-
운영 복잡성 증가(More operational complexity): 메시지 브로커 등 추가 인프라 관리 및 모니터링이 필요합니다.
-
최종 일관성(Eventual consistency): 데이터가 시스템 전체에 즉시 업데이트되지 않을 수 있어 일관성 처리에 주의가 필요합니다.
-
서비스 간 흐름 추적의 어려움(Harder to trace flow across services): 많은 서비스가 이벤트에 반응할 때 전체 프로세스 흐름 추적이 복잡해질 수 있습니다.
Rails에서 EDA를 위한 주요 도구
-
Wisper: 모놀리스 내부에서 구성 요소 간의 느슨한 결합을 위한 간단한 인-프로세스 이벤트 버스입니다.
-
Sidekiq (with Redis): 비동기 처리를 위한 백그라운드 작업 처리기로, Redis를 메시지 브로커로 사용합니다.
-
RabbitMQ: 다른 애플리케이션(마이크로서비스) 간 메시지를 안정적으로 라우팅하는 전용 메시지 브로커입니다.
-
Apache Kafka (Karafka): 대규모 데이터 스트림을 실시간으로 처리하는 고처리량 시스템에 적합하며, 이벤트의 영구 기록을 유지합니다.