일반적으로 API Gateway로 알려진 것을 사용하는 것이 훨씬 더 좋은 방법이다. API Gateway는 시스템으로 접속하는 단일 진입점 서버이다. Object-Oriented 디자인에서 Facade 패턴과 유사하다. API Gateway는 내부 시스템 아키텍처를 보호하고, 개별 클라이언트에 맞춰진 API를 제공한다. API Gateway는 Authentication(인증), monitoring, load balancing, caching, request shaping(요청 제어) and management(관리), static response handling(정적 응답 처리)를 책임지고 수행한다.

다음 그림은 아키텍처상에서 API Gateway가 어떻게 표현되는지를 보여준다.

API Gateway는 request routing, composition, protocol translation에 대해 완결적으로 수행한다. 클라이언트에서 하는 모든 요청들은 API Gateway를 통과하게 된다. 그리고 그 요청들은 적합한 micro service들에게 라우팅된다. API Gateway는 종종 하나의 요청에 대해 여러 개의 microservice들을 호출하고, 그 결과를 취합하여 응답을 제공할 것이다. API Gateway는 HTTP나 WebSocket과 같은 Web Protocol을 내부에서 사용하는 웹친화적이지 않은 프로토콜로 변환할 수 있다.

API Gateway는 개별 클라이언트에 Custom API를 제공할 수도 있다. 일반적으로 Mobile client에 대해서는 거친 API를 노출한다. 예를 들어, 상품 상세 정보 제공 시나리오를 생각해 보라. API Gateway는 모바일 클라이언트에서 한번의 요청으로 모든 상품의 상세 정보를 얻을 수 있는 하나의 endpoint(/productdetails?productid=xxx)를 제공할 수 있다. API Gateway는 그 요청을 처리하기 위해 다양한 서비스들(product info, recommendations, reviews, etc.)을 호출하고 그 결과를 조합한다.

API Gateway의 가장 좋은 예제는 Netflix API Gateway이다. Netflix streaming service는 televisions, set-top boxes, smartphones, gaming systems, tablets등등의 수백개의 서로 다른 종류의 다비이스에서 사용할 수 있다. 초기에 Netflix는 streaming service를 위해 임의의 크기(one-size-fits-all) API를 제공하려고 했다. 그러나 다양한 범위의 디바이스와 디바이스별 특정 요구사항 때문에 잘 동작하지 않는다는 것을 발견했다. 오늘날, Netflix는 device-specific adapter code를 실행하여 각각의 디바이스에 맞춰진 API르르 제공하는 API Gateway를 사용한다. Adapter는 일반적으로 평균 6~7개의 backend service를 호출하여 각 요청을 처리한다. Netflix API Gateway는 하루에 수십억건의 요청을 처리한다.

이론적으로, 클라이언트는 각 개별 microservice에 직접 요청할 수 있다. 각각의 microservice는 public endpoint(https://serviceName.api.company.name)를 가지고 있다. 이 URL은 이용할 수 있는 인스턴트들에 요청을 분산처리하는 microservice의 로드밸런서와 맵핑된다. 상품 상세 정보를 얻기 위하여, 모바일 클라이언트는 위에 나열된 각각의 service들에게 요청할 것이다.

불행하게도, 이 옵션에는 여러 가지 도전과 제한이 있다. 한가지 문제는 클라이언트의 필요와 각 microservice에 의해 노출된 잘 나누어진 API사이의 부조화다. 이 예제에서 클라이언트는 7개의 분리되어 있는 요청을 해야만 한다. 더 복잡한 어플리케이션에서는 더 많은 요청을 해야만 할 것이다. 예를 들면, 아마존은 수백개의 서비스들이 상품 페이지를 다루기 위해서 호출된다. 클라이언트에서 LAN을 통해 수많은 요청을 할 때, public internet에서 너무 비효율적이 되고, 분명히 모바일 네트워크에서는 비현실적이다. 이러한 접근법은 클라이언트 코드를 훨씬 더 많이 복잡하게 할 것이다.

클라이언트가 microservice를 바로 호출하는 경우에 발생하는 또다른 문제는 웹 친화적이지 않은 프로토콜을 사용하는 경우이다. 한 서비스는 Thrift binary RPC를 사용하고, 또다른 서비스는 AMQP 메시징 프로토콜을 사용한다고 해보자. 둘 다 특히 브라우저 친화적이거나 방화벽 친화적인 프로토콜이 아니다. 그리고 내부적으로 사용하기에 가장 좋은 것도 아니다. 어플리케이션은 방화벽 밖에서 HTTP나 웹소켓과 같은 프로토콜을 사용해야 한다.

이러한 접근법의 또다른 약점은 microservice를 리팩토링하기 어렵다는 것이다. 시스템이 얼마나 서비스로 분할되었는지에 따라 우리가 변경하고자 할 때 시간이 걸릴 것이다. 예를 들어, 2개의 서비스를 통합하고자 하거나, 하나의 서비스를 2개 이상으로 나누고자 하는 경우가 있다. 그러나, 클라이언트가 직접 서비스들과 통신하고 있다면 이러한 종류의 리팩토링을 수행하는 것은 극도로 어려워질 수가 있다.

이러한 문제들 때문에 클라이언트에서 직접 microservice를 호출하게 하는 것은 전혀 이치에 맞지 않다.

전체 7가지 Article중에 첫번째 article에서는 microservice들을 디자인하고, 빌드하고, 배포하는 Microservice Architecture pattern에 대해서 소개했다. Microservice를 사용했을 때의 장점과 단점에 대해서 논의했고, microservice의 복잡성에도 불구하고 일반적으로 복잡한 application에 대해 얼마나 이상적인 선택인지에 대해서도 논의했다. 이번 두번째 시리즈에서는 API Gateway를 사용한 microservice를 빌드하는 것에 대해서 논의할 것이다.

여러분이 microservce의 집합으로 application을 빌드하는 것을 선택할 때, 여러분의 application을 호출하는 client들이 microservice와 얼마나 상호작용하는지 결정할 필요가 있다. Monolithic application에서는 (일반적으로 복제되고, 부하 분산된) 단 하나의 endpoint들의 세트가 있다. 그러나 Microservice Architecture에서는 각 개별 microservice가 잘 나누어진 endpoint들의 집합을 노출한다.

이번 Article에서는, 이것이 client-to-application communication에 얼마나 영향을 주는지를 결정하고, API Gateway를 사용하는 접근법을 제안한다.

여러분이 쇼핑 application을 위해 native mobile application을 개발하고 있다고 가정해 보자. 주어진 상품에 대한 정보를 보여주는 상품 상세 페이지를 개발해야만 할 것이다. 예를 들어, 다음 다이어그램은 아마존 안드로이드 모바일 application에서 상세한 상품 정보를 스크롤했을 때, 여러분이 무엇을 보는 지를 보여준다.

우리는 모바일 클라이언트에서 이러한 서비스들에 어떻게 접근할 수 있을지 결정해야만 한다.

몇 가지 옵션들에 대해서 살펴보자.