Microservice Architecture API Composition

마이크로서비스 아키텍처는 '서비스를 설계하는 Inner 영역'과 '서비스를 지원하는 Outer 영역'으로 구분한다.

Inner는 서비스를 비즈니스 영역에 맞게 쪼개고 API를 설계하는 영역이며, Outer는 API 호출이 원활하게 이루어질수 있도록 도와주는 영역이다.
이와 같이 MSA는 API를 어떻게 쪼개고 어떻게 서비스할 것인지를 결정하는 것이라 할 수 있으며, 결국 MSA의 핵심은 API라고 할 수 있다.

마이크로서비스의 API

"최근 IT(Information Technology)는 진화의 과정을 거쳐 DT(Data Technology) 산업으로 확장해 나가고 있다. Data 중심의 기술로 발전하며, 데이터를 분석하는데 특화된 다양한 언어와 환경이 중요해졌으며, 이는 기존 단일화(?) 되어 있던(사실 하나의 언어로도 표현하기 충분했기 때문에 단일화라고 표현하기에는 논란의 소지가 있기도 하다.) 언어 편향 특히 자바로 개발되던 환경과 다르게 현재는 Digital Transformation에 대응하는 다양한 형태의 개발방식이 혼합되는 시대가 되었다. Java는 여전히 많이 사용되지만, 지금은 Node가 Java 보다 선호되고 있다는 점을 잊지 말아야 한다."

by WASPRO

위와 같은 다양한 형태의 언어로 개발되어진 마이크로서비스들은 상호간 통신을 위한 Interface를 제공해야 하며 그 역시 매우 복잡하다는 사실은 모두 인지하고 있다.

이와 같은 문제를 완화하고자 우리는 API 라는 통신 규칙을 세우게 되었다. 사실 API는 Remote Interface를 통칭하는 용어로 기존 xml 기반의 통신 귀약이었던 SOAP Protocole, WebService, WebSocket, RMI 등의 다양한 형태의 Interface를 제공받아 왔다. 다만 이들은 다루기가 어렵고 Interface를 구현하는 일이 하나의 개발 단위가 되어 버리는 시간이 많이 소모되는 업무 로직으로써 항상 개발에 골치거리로써 존재해 왔다.

더욱이 언어의 다양화는 이와 같은 문제를 더욱 가속화 시키게 되었고 결국 우리는 RestAPI라는 형태의 새로운 규약을 만들게 된다. 마이크로서비스에서 RestAPI는 멀티 채널(Client Side) 환경에서 유입되는 다양한 형태의 사용자의 요청을 받아 줄 수 있는 Interface이자, polyglot을 지향하는 MSA 환경에서 마이크로서비스 간 통신을 정의하는데 사용된다.

하지만, api가 갖고 있는 특수성으로 인해 장점이자 단점이 될 수 있는 요소들이 존재한다. 그 중 stateless 서비스라는 특성을 기반으로 api composition이 주는 영향에 대해 알아보도록 하자.

api composition의 필요성

다양한 언어의 마이크로서비스 간 또는 다양한 형태의 클라이언트의 요청은 "하나의 비즈니스 로직에 하나의 api를 호출하기도 하지만, 두 개 또는 수 개 이상의 api를 동시에 호출하기도 한다."

api는 상태가 없는 stateless application으로 하나의 비즈니스 호출 내의 여러 api는 하나의 트랜잭션으로 묶지 않고 각 api 별 비동기(Async)로 호출하는 것이 일반적이다.

특히 하나의 프레임안에 여러 api 호출 결과를 조합하여 표출해야 하는 경우 api의 호출 결과를 조합하는 기능을 담당하는 모듈이 필요하다.

예를 들자면 다음과 같다.

A 쇼핑몰의 마이크로서비스 구성 현황이 다음과 같다고 가정해 보자.

- 사용자 가입 : A 쇼핑몰 사용자 가입 관련 서비스

- 상품 정보 : 판매 상품 정보 관련 서비스

- 구매 : 구매 관련 결제 서비스

- 배송 : 배송 관련 서비스

- 개인 정보 : 가입자 개인 정보 확인 서비스

위와 같은 서비스를 기반으로 환불 서비스를 구현하기 위해 Front End 개발자는 구매 서비스 / 배송 서비스 / 개인 정보 서비스 등에서 제공하는 api를 호출하여 환불 관련 서비스를 개발하고자 한다.

이때 호출된 3개의 서비스의 최소 3개 이상의 api 호출 결과를 aggregation 하는 대상이 필요한데 기존의 경우 대부분 호출자(Front)가 직접 return 결과를 조합하는 형태를 띄곤했다.

지금부터는 api composition을 수행하는 몇가지 방법에 대해 알아보자.

api composition 구현

먼저 앞서 살펴본 예시를 다음과 같이 도식화해보자.

환불이라는 Front End 서비스는 Back End API 서비스인 상품정보, 구매, 배송 API를 호출하여 그 결과를 조합하여 표출하는 서비스이다.

위 이미지의 1, 2, 3은 각각 API Composition을 수행할 위치를 지정한 것이며, 각각 Client Side, Server Side 또는 그 중간의 별도의 컴포넌트가 대상이 된다.

(1) Client Side API Composition

 

각각의 api 조회 결과를 ui 환불 서비스에서 직접 aggregation하는 방식이다.

이와 같은 방식은 api를 처리한 결과를 순차적으로 조합하기 위해 많은 로딩 시간을 기다려야 하지만, 데이터를 다양한 형태로 표출하는데 유연하다는 장점이 있다.

또한, 순차적으로 api 서비스가 반드시 이루어져야 하는 경우 사용하기 적합하다.

(2) Server Side API Composition

 

서버 사이드 마이크로서비스 중 대표 서비스를 지정하고 해당 서비스에서 api를 호출하여 결과를 조합하는 방식이다.

클라이언트에서 모든 api를 호출하는 것보다 서비스 간 호출이 빠르다는 장점이 있지만, 클라이언트 상에 표출하기 위한 데이터 변경 시 서버 사이트 애플리케이션을 수정해야 하는 종속성이 발생한다.

또한 구매 서비스에 환불 서비스에서 사용하는 api가 함께 구성되어 마이크로서비스의 결합도가 높아지는 문제가 발생한다.

이와 같은 문제를 해결하고자 Aggregator Service를 별도로 개발하여 구성하는 방법도 제시할 수 있다.

 

 

이렇게 구성할 경우 서버 사이드에서 빠른 호출과 aggregation이 가능하며, 서비스 종속성이 없는 단일 마이크로 서비스로 구성도 가능하다.

물론 Hop의 증가로 인한 문제와 api 유연성 문제는 여전히 발생할 수 있다.

또한 클라이언트 사이드에서 api 결과를 순차적으로 받아 처리해야 하는 경우에는 적합하지 않다.

(3) API Gateway를 사용한 API Composition

 

API Gateway를 Client와 Server 사이에 두고 API 서비스를 중개하도록 구성하는 방안이다. 이 경우 Client / Server 사이드 모두 종속성에서 벗어날 수 있다.
또한 API를 사용하기 위한 보안, 인증, 제한, 권한, 라이프사이클 관리 등의 Sub Function을 함께 제공하여 개발 생산성을 높여줄 수 있다. 특히 복잡한 Back-End Endpoint를 알 필요없이 API Gateway를 단일접점으로 제공하여 보안 뿐 아니라 개발 편의성을 제공하기도한다. 이로인해 마이크로서비스 아키텍처에서 특히 Outer 영역에서 API Gateway는 가히 가장 핵심적인 컴포넌트라 할 수 있다.

다만 별도의 Outer Architecture 컴포넌트를 설계해야 하며 구축 / 유지보수 비용이 추가될 수 있다는 점을 간과해서는 안된다.

결론

API는 이와 같은 사상을 수렴하기 위한 최적의 통신방식으로 간편하게 표출할 수 있는 json 형태의 데이터를 사용하며, http protocol을 사용하여 Remote와 손쉽게 통신할 수 있도록 Remote Interface를 제공하기 때문에 누구나 쉽게 접근할 수 있다.

다만 API의 특성에 따라 발생 가능한 여러 특수성을 이해하고 아키텍처를 설계하는 것이 반드시 필요하다.