1. 개요

API-based Platform에서 (MicroService Architecture, Serverless..) 서비스 간 복잡도가 증가하게 되면 서비스 간 통신에 필요한 API 호출의 빈도가 증가함에 따라 오버헤드가 생기게 됩니다. 
마이크로 서비스 아키텍쳐에서도 대규모 또는 복잡한 마이크로 서비스로 구성될수록 REST API들이 기능별로 세세하게 나뉘어(Fine-Grain)지게 되는데 이에 따라 클라이언트(or API 컨슈머)가 호출해야 하는 API의 빈도수가 증가하게 되죠.

이 때 컨슈머가 덜 부담스럽도록 해주기 위한 방법은 단연 호출해야 하는 API의 개수를 줄여주는 것입니다. 그게 하나가 된다면 더 좋을 거구요. 컨슈머가 하나의 API 리퀘스트를 보내면, 각 서비스들로 보내주고, 또 다시 응답을 모아서 하나로 받을 수 있도록해주면 좋을 것 같네요.

그것이 바로, API Composition이라고 합니다. API Orchestration이라고도 하고, API Aggregation으로 부르기도 한다고 하네요.

2. 이슈

분산 시스템에서의 데이터 조회가 이슈입니다.

• 분산 서비스마다 DB가 분리되어 있어 물리적인 Join 불가
• DB Link 사용 이슈 (lock 자주 걸림)

3. API Composition/Orchestration/Aggregation

API Composition를 구글에서 검색해보니, 아래 사이트가 보이네요.

https://microservices.io/patterns/data/api-composition.html

사이트에 있는 그림을 보면, API Composer가 위에서 얘기했던 내용들을 해주는 것 같습니다. 결과적으로는 API Composition 패턴을 사용함으로써 MSA에서 데이터를 쿼리해오는 것이 더 심플해졌다고 얘기합니다.

예로, API Gateway가 API Composition 을 해준다는 내용도 있네요! 참고로 이 API Composition Layer는 API Gateway 앞단, 내부, 뒷단에 구현할 수 있다고 합니다. 

검색결과를 더 봐볼게요..

아래와 같이 정의를 내린 글귀도 보입니다.

API service composition is about taking the basic building blocks of any web API, the URL, path, and VERBS (ability to get, add, update, and delete), and put them into as many different configurations as you think makes sense. Limiting who can access, how much they use, restrict by time frame, and crafting different pricing for different users or groups, require trial periods, setup costs, and even restricting to specific countries. API service composition is all about taking your APIs, and if you are using modern API infrastructure like from 3Scale, you can compose any service you desire, serving it up to anyone, in a secure way, using the open Internet.

정리를 해볼께요.

• API Composition은 여러 서비스 API의 호출 결과를 조합하여 응답하는 방식입니다.
• 하지만 대량 데이터, 혹은 복잡한 데이터를 응답하는 경우에는 적합하지 않아요.

4. API Composition Layer 위치에 따른 장.단점

4.1. API Gateway 앞

• Wrapper 형태로 Gateway 앞에 위치해서 Gateway 단을 전혀 건드리지 않지만, Composition Layer가 Consumer의 End Point가 되면서 모든 트래픽을 부담해야 합니다.
• Composition Layer와 Gateway 간의 Latency를 최소화해야 합니다.
• Composition Layer가 필요하지 않아도 무조건 통과해야 합니다.

4.2. API Gateway 내부

• Gateway 내부에서 동작함으로 Network Hop이 존재하지 않습니다. 
• Gateway 구현이 복잡해지고, Composition Layer 때문에 성능에 영향을 줄 수도 있습니다.
• 로직 변경이나 확장이 필요할 때, Gateway 재시작이 필요할 수도 있습니다. 

4.3. API Gateway 뒤

• Gateway는 아무것도 하지 않아도 되기때문에 도입하기 가장 쉽습니다.
• Composition Layer가 API Provider가 되는거나 마찬가지라고 할 수 있습니다.
• Composition Layer를 위한 End Point를 API Provider가 제공해야 할 수도 있습니다.

5. 고려사항

설계 시에는 API부터 디자인한 후 분산 구조를 설계한다.

1. API 설계 : API Provider, API Consumer 협업하여 API 설계 및 구현, 예를 들어 특정 Operation 수행에 필요한 API들 중 일부가 없다면 해당 서비스 Provider에 API 요청
2. 동기/비동기 설계 : 서비스 독립성을 위해서는 응답이 오지 않아도 다음 작업을 수행하는 비동기 선호
3. 트랜잭션 설계 : 데이터 정합성 유지 방안(취소/무시/재시도/Compensation), 관련 패턴 적용(Saga)
4. 데이터 조회 설계 : 마이크로서비스마다 DB 분리되어 물리적 Join 불가 -> 추가 설계 

6. 예

6.1. 일별주문현황

일별주문현황 조회 요청이 있는 경우 아래 3개의 결과를 조합하여 응답한다.

1. 일별주문목록조회 API
2. 일변승인목록조회 API
3. 배송상태조회 API

6.2. 은행고객상세

1. 계좌목록조회 API
2. 이체한도조회 API