Publish and Subscriber Architecture 와 Event-Driven Architecture은 모두 이벤트 중심의 아키텍처 패턴으로, 어플리케이션의 컴포넌트들 간의 통신을 관리하는 데 사용된다.
1. Publish and Subscriber Architecture Style
Publish and Subscriber Architecture Style은 분산 시스템 및 이벤트 기반 아키텍처이다. 이벤트 발생과 처리하는데 적용하는 스타일이다. 이벤트 발행자와 해당 이벤트를 구독자 사이에 느슨한 결합을 제공하여 확장 가능하고 유연한 시스템을 만들 수 있도록 한다.
publisher는 이벤트를 생성하고 발행한다. 해당 주제에 관심있는 구독자에게 이벤트가 전달 될 수 있도록 Broker에 전달한다. Broker는 발행자와 구독자 간 통신을 중계하고, 이벤트의 분배 및 관리를 담당한다. 구독자는 특정 주제 또는 채널에 관심이 있다면, 구독을 요청하고, 해당 이벤트를 Notify 받을 수 있도록 한다.
Publish and Subscriber Architecture Style은 구독자와 발행자로 구성된다. 발행자와 구독자 간에 느슨한 결합을 제공하는데 중점을 둔다. 발행자가 Event를 통해 자신의 상태 변화를 구독자에게 알린다. 발행자와 구독자가 직접 통신하지 않고, 중개자를 통해 이벤트를 전달한다. 구독자는 특정 이벤트에 대해 구독을 요청하고, 이벤트가 발생하면 발행자의 알림을 받아 처리한다.
발행자와 구독자는 직접적으로 통신하지 않으며, Broker를 통해 상호작용 한다. 이로 인해 유지보수 및 확장이 더 쉬워진다. 또한 다양한 위치에 있는 구독자가 이벤트를 수신 할 수 있다. 중재자나 브로커는 이벤트를 중앙화된 로깅 및 모니터링에 활용할 수 있다. 이벤트 기반의 비동기 통신을 통해 컴포넌트 간의 결합도를 낮출 수 있으며, 확장성과 유연성을 제공한다. Design Pattern에서 Observer Pattern과 유사하다.
2. Event Driven Architecture Style
시스템의 컴포넌트 간 상호작용을 이벤트와 메시지를 통해 주도하는 방식으로 구성된다. 이 아키텍처 스타일은 비동기적이며 느슨하게 결합되어 있으며, 다양한 컴포넌트 및 서비스간의 효율적인 통신과 상호 작용을 지원한다. 임베디드 시스템에 많이 사용되는 Style 이다. Interrupt를 통해 Event를 전달 받아 등록된 Handler를 호출 하여, 각 Event를 처리하는 방식이다. 이벤트를 생성하는 발생자와 이벤트를 수신하고 처리하는 핸들러가 존재한다. 발생자는 이벤트를 생성하고 핸들러는 해당 이벤트를 등록하여 트리거 된다.
- Event : 시스템 내에서 중요한 상태 변화나 사건을 나타내는 메시지이다. 이벤트 주체와 구독자 간의 통신 수단으로 사용된다.
- Event Broker : Event Source로 부터 발생한 Event들을 중앙에서 관리하며 각각의 Event Handler로 전달하여 처리될 수 있도록한다.
- Event Handler : Event를 처리하는 로직이며, 특정 이벤트를 수신하면 해당 이벤트를 처리하거나 관련 동작을 수행한다.
컴포넌트 간에 상호작용이 이벤트를 통해 이루어지기 때문에, 컴포넌트 간의 결합도가 낮아진다. 이로 인해 시스템은 유연하고 확장 가능하며, 변경과 유지보수가 용이해진다. 이벤트 기반의 통신은 비동기적으로 발생하므로, 작업 병렬화와 성능 향상을 지원한다. 시스템의 상태 변화와 이벤트 중앙 집중화된 Event Broker를 통해 관찰 및 모니터링 할 수 있다.
둘 다 이벤트 중심의 아키텍처 패턴이지만, Publish-Subscribe Architecture는 이벤트를 구독하는 방식으로 느슨한 결합을 제공하며, Event-Driven Architecture는 이벤트가 발생했을 때 트리거되는 동작에 초점을 둔 비동기적인 상호작용을 강조한다. 따라서 사용 시나리오와 요구사항에 따라 적합한 패턴을 선택해야 한다.
3. Microservice Architecture Style
Microservice Architecture Style 은 외부 Service를 사용하는 Architecture Style이다. 복잡한 시스템을 작고 독립적인 단위로 분할하여 상호작용 하도록 한다. 각각의 작은 단위는 독립적인 서비스로 구현되며, 이러한 서비스는 분산된 방식으로 서로 통신하며 배로 및 확장될 수 있다. 서로 다른 서비스 간에 네트워크 통신을 통해 상호작용을 한다. 각 서비스는 필요한 데이터 및 기능을 다른 서비스로 부터 요청하고 결과를 받을 수 있다. 시스템 내부에 배치하지 않고, 외부 서비스가 제공하는 기능을 사용하여 시스템의 요구 사항을 달성한다. 이 Style을 채택하는 경우, 서비스의 품질에 대한 책임을 서비스 제공자에게 할당하여, 시스템 내부의 유지 보수 비용을 절약할 수 있다. 그러나, 외부 서비스 제공자에게 의존하기 때문에, 개발 자유도는 떨어질 수 있다.
서비스 단위로 확장이 가능하며, 필요한 서비스만 골라서 선택할 수 있다. 각 서비스는 독립적인 서비스 제공자에 의해 제공되기 때문에, 관리와 배포가 용이하다. 또한 서비스는 표준화된 API를 제공하기 때문에 시스템과 결합도가 낮아진다. 우리 시스템에 맞는 서비스를 선택할 수 있기 때문에 특정 기술에 종속되지 않고 최적의 도구를 선택할 수 있는 유연성을 제공한다. 그러나, 네트워크 상 분산 시스템으로 구성되기 때문에, 네트워크 통신, 모니터링 등 추가적인 운영적인 비용이 발생 할 수 있다. 유연성과 확장성을 제공하는 장점이 있는 반면, 분산 시스템에 대한 운영적인 비용을 고려해야 한다.
AWS(EC2) Cloud system 위에 Database를 구동 시키는 System이 이에 해당 된다.
