Notifications - Push, Pull, Stream Notification #2
| Exchange 2013을 기반으로 개발을 진행하면서 맞닥뜨리게 된 케이스에 대해서 공유 하고자 한다. 이전에 잠깐 EWS(Exchange Web Service)를 통해 간단한 기능을 사용해본 경험이 전부라서 하나의 기능을 구현하기 위해 여러가지 방안에 대해서 바위에 계란치기로 직접 부딪혀 볼 수 밖에 없었다. 이런 힘들고 시간 싸움을 줄이는데 도움을 드리는데 일조 하고자 이곳에 공유 하고자 합니다. 비록 덜 정제 되고 문서 미비할 수 있지만 참고 사항으로 알아 두셨으면 합니다. |
이전 포스트에서 Push, pull, Stream 방식으로 notification을 구독하는 컨셉에 대해서 알아 보았다. 이번 포스트에서는 실제 서비스 환경에서 고 가용성과 확장성을 고려한 환경에서 어떤 방식으로 이벤트 구독을 하는 것이 효과적인지에 대해서 알아 보도록 하자.
[그림1] 실서버 환경(고 가용성, 확장성 구조)
"그림1"은 고 가용성과 확장성을 고려해서 서비스를 하기 위한 구조라고 가정하자. 대 규모 서비스에서는 위와 같은 구조로 서비스를 할 것이다.
[그림2] Listener 서버가 별도의 서버로 구축된 환경
이와 같은 환경에서 Push notification을 사용해 이벤트를 구독하는 방안을 제안한다. Push notification 방식은 Listener이라는 별도의 서비스가 있어야 하며 다른 방법(Push, Stream)과 달리 세션을 유지 해야 하는 제약 사항이 없다. 그리하여 MBX에서 이벤트를 Listener로 넘겨주면 XML을 이용해서 정보를 파싱하여 알아내야 한다.
[그림3] CAS에 Listener 롤도 추가된 환경
"그림3"은 CAS 서버와 Notification 이벤트를 구독하는 Listener이 하나의 서버로도 구축 할 수 있다. 서버 자원에 따라 선택하면 될 것이다.
Push 이외에 Pull과 Stream은 EWS 사용 방법과 비슷하게 사용할 수 있으나 세션 유지가 되어야 함으로 서버가 다운 되었을 때 처리해야 하는 방식이 훨씬 복잡해진다. ( Notification을 동적으로 구독 추가 로직, 각 서버마다 어떤 사용자를 구독하는지 모니터링 필요, ... ) 그럼으로 위와 같은 규모와 구조에서는 Push 방식으로 접근 하는게 더 효과적이라 할 수 있다.
Exchange flow diagram V1.pptx이제 Notifications에 대해서 전체적인 흐름과 환경에 대해 알아보았으니 다음 포스트에서 실 코딩에 대해서 알아 보도록 하자.