도메인 주도 설계 - Bounded Context 간의 통신

2019/06/05 - [개발자] - [도메인 주도 설계] Bounded Context

이전 블로그에서 Bounded Context에 대해 알아 보았습니다. 각각의 컨텍스를 서비스로 구현한다고 하면, 각 서비스들은 서로 간에 통신이 필수불가결하게 됩니다. 인사팀에서 새로운 영업 직원을 채용했다면, 이 직원의 정보는 당연히 영업팀의 서비스로 넘어가야겠죠. 쇼핑몰에서 상품을 구매하면, 이것이 결제 시스템으로 넘어가야 하는 것도 같은 같이 이치 입니다. 컨텍스트 간의 통신에는 여러가지 방법이 있겠지만 최근 사용되는 방식은 2개만 있다고 봐도 무방합니다.

메시지 또는 REST

메시지는 전통적인 EAI와 다르지 않습니다. 메시지를 생성해서 메시지큐에 보내면 메시지를 구독(Subscribe)하는 서비스들이 이를 받아서 처리하는 것입니다. 마이크로 서비스라고 해서 새로운 개념이 아니라고 누차 강조해서 말씀 드렸는데요, 이미 많은 시스템에서 사용하는 방식입니다. 중앙 집중식 메시지를 이용하면 트랜잭션 관리 같은 부차적인 관리가 필요 없으므로 상당히 편리하게 서비스를 구현할 수 있습니다. 예전에는 IBM MQ 같은 상용 제품을 많이 사용하였으나, 최근에는 오픈소스들도 워낙 잘되어 있고 AWS나 Azure에서 SaaS/PaaS 형태로 서비스를 제공하기 때문에 이곳에 연결해서 사용하는 것도 하나의 방법입니다. 모든 서비스들이 내부 인트라넷에 존재하면 별도의 인증 같은 것 없이 바로 연결할 수 있는 장점도 있고요.

또 다른 방식은 REST 방식인데, 서비스가 외부에 오픈되게 되는 경우 쓰는 방식이 될 수 있습니다. 물론 내부 인트라넷의 경우에도 REST 방식을 써도 무방합니다. 최근에는 다양하게 REST API를 개발툴들이 존재해서 예전보다 더욱 쉽게 REST를 구현할 수 있게 되었습니다. Request를 위한 URI 표준화, Response를 위한 HAL 표준화, 그리고 API 문서화를 위한 Swagger 등 많은 Support 툴들이 존재해서 엔드포인트 개발도 상당히 쉬워졌습니다. 하지만, REST를 쓸 경우 단 한가지의 단점이 존재합니다. 바로 복잡도의 증가입니다.

컨텍스를 구현한 서비스가 증가하면 증가할 수록 바로 이런 모습으로 서비스들이 메쉬업되고 복잡도가 증가하게 됩니다. 서비스가 50개 있다고 생각해 보세요. 정신을 차릴 수가 없을겁니다. 또한 하나의 서비스가 50개의 서비스들에게 데이터를 보내는 경우, 하나가 Fail하게 되면 어떻게 될까요? Transaction 관리는 또하나의 지옥이 될 수 있습니다.

 

 

그래서 등장한 것이 바로 API Gateway입니다. EAI를 REST API에 적용시킨 결과물이라고 보시면 됩니다. API Gateway에서는 어느 서비스에서 받은 Request를 어는 서비스로 다시 제공해야 하는지 관리자 콘솔을 통해 관리할 수 있으며, 모든 트랜잭션을 관리해주게 됩니다. 세상 정말 편해졌습니다. API Gateway를 직접 구축하지 않아도 인증 및 라우팅을 모두 관리해주는 서비스가 있으니까요. 다만, 돈을 좀 많이 지불해야 하지만요.

 

 

위는 AWS API Gateway 예제입니다. 자세히 보시면 AWS Lmanda functions/Endpoints on EC2와 같이 복수형으로 표현되어 있습니다. 즉, 하나의 서비스에서 Gateway로 데이터를 보내면 다른 서비스들에 라우팅을 시켜준다는 것입니다. 물론 인증 기능도 관리자 콘솔에서 가능하고요. 이렇듯 AWS에서 다양하고 많은 서비스를 제공하므로, AWS 전문 System Admin이라는 새로운 Role까지 생겨나고, 채용도 많이 하고 있답니다.

다음에는 아마존의 실제 Bounded Context간의 통신 예를 살펴보겠습니다.