이론적으로, 클라이언트는 각 개별 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에서 상세한 상품 정보를 스크롤했을 때, 여러분이 무엇을 보는 지를 보여준다.

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

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

복잡한 어플리케이션을 만드는 것은 본질적으로 어렵다. Monolithic Architecture는 단지 간단하고 가벼운 어플리케이션에 맞다. 만약 Monolithic Architecture를 복잡한 어플리케이션에 사용한다면, 여러분은 결국 고통의 세계로 끝나게 될 것이다. Microservice Architecture Pattern은 여러 단점들에도 불구하고 복잡하고, 발전하는 어플리케이션과 도전을 성취하는데 있어 더 좋은 선택이다.

이후 블로그 포스트에서는, Microservice Architecture Pattern의 다양한 측면에서 상세하게 들어가 볼 것이다. 그리고 service discovery, service deployment options, monolithic application을 service로 리팩토링하는 전략과 같은 주제들에 대해서 논의할 것이다.

계속해서 주목해 보라....(Stay tuned...)

약 30년 전, Fred Brooks가 쓴 것처럼, 획기적인 방법은 없다. 다른 모든 기술들처럼 Microservice Architecture도 단점이 있다. 한가지 단점은 이름 그 자체에 있다. Microservice라는 용어는 서비스의 크기를 과도하게 강조한다. 사실, 극도로 잘게 나누어진, 10~100줄의 코드로 이루어진 서비스 개발을 지지하는 개발자들도 있다. 작은 서비스들이 더 좋지만, 그것은 목적을 위한 수단이고, 주된 목적은 아니라는 것을 기억하는 것이 중요하다. Microservice의 목적은 어플리케이션을 빠르게 개발하고 배포 가능하도록 하기 위하여 어플리케이션을 충분히 분해하는 것이다.

Microservice의 또다른 주요 단점은 microservice 어플리케이션들이 분산환경에 있다는 사실에서 발생하는 복잡성에 있다. 개발자들은 메시지나 RPC중 하나에 기반한 inter-process communication 메커니즘을 선택하고 구현할 필요가 있다. 더욱이, 요청의 목적지가 느려지거나 이용불가능할 경우가 있기 때문에 부분적인 오류를 다루는 코드를 반드시 작성해야만 한다. 고도의 지능이 요구되는 일은 아니지만, 모듈간 language-level method/procedure 호출을 통해 서로 통신하는 monolithic application에서 훨씬 더 복잡하다.

Microservice의 또다른 도전은 분할된 데이터베이스 구조(partitioned database architecture)이다. 일반적으로 Business Transaction은 여러 개의 business entity들을 업데이트한다. 이러한 종류의 transaction들을 monolithic application에서 구현하는 것은 사소한 일이다. 왜냐하면, 하나의 데이터베이스만 있기 때문이다. 그러나 Microservice 기반 application 에서는 다른 서비스들이 소유한 여러 개의 데이터베이스를 업데이트할 필요가 있다. 분산 transaction을 사용하는 것은 CAP theorem 때문에 유일한 해결책은 아니다. 오늘날 매우 확장 가능한 많은 NoSQL 데이터베이스나 messaging broker에서 분산 transaction을 지원하지 않는다. 결국 개발자들에게 더 도전적인, 궁극적인 일관성에 기반한 접근법을 사용해야만 하는 상황에 직면하게 된다.

Microservice 어플리케이션을 테스트하는 것 또한 훨씬 더 복잡하다. 예를 들면, Spring Boot과 같은 최근의 framework으로 monolithic 웹 어플리케이션을 구동하는 테스트 클래스를 작성하고, REST API를 통해서 테스트 하는 것은 사소한 일이다. 반대로, 서비스에 대한 유사한 테스트 클래스는 테스트 대상 서비스와 의존 관계에 있는 다른 서비스들을 실행할 필요가 있다.(최소한 그러한 서비스들에 대한 stub 환경 설정이라도 해야 한다.) 한번 더 말하면, 이것이 고도의 지능을 요구하는 일은 아니지만, 테스트 수행에 대한 복잡도를 너무 적게 잡지 않는 것이 중요하다. (테스트 수행이 monolithic application 보다 복잡하다는 뜻.)

Microservice Architecture Pattern의 또 다른 주요 도전은 여러 서비스에 퍼져 있는 변경 사항들을 구현하는 것이다. 예를 들어, 서비스 A, B, C의 변경을 요구하는 스토리를 구현하는 것을 상상해 보자.서비스 A는 서비스 B에 의존하고, 서비스 B는 서비스 C에 의존한다. Monolithic application 에서는 해당 모듈들을 간단하게 변경하고, 변경 사항들을 취합하여 한번에 배포할 수 있다. 반대로, Microservice Architecture Pattern 에서는 주의하여 계획을 세우고, 뽑아낸 변경사항들에 대해 각 서비스들을 조정, 반영해야 한다. 예를 들어, 서비스 C를 업데이트할 필요가 있을 경우, 서비스 B도 따라서 업데이트 하고, 마지막으로 서비스 A도 업데이트 해야 한다. 다행스럽게도 대부분의 변경사항들은 보통 하나의 서비스에만 영향을 주고 조정이 필요한 여러 서비스를 변경하는 경우는 거의 드물다.

Microservice 기반 어플리케이션을 배포하는 것은 훨씬 더 복잡하다. Monolithic 어플리케이션은 전통적인 load balancer 뒤에 있는 동일한 서버에 간단하게 배포된다. 각각의 application instance에는 데이터베이스와 messaging broker와 같은 infrastructure service의 위치(host and ports)가 설정되어 있다. 반대로, microservice application은 일반적으로 수많은 서비스들로 이루어져 있다. 예를 들어, Hailo는 160개의 다른 서비스들로 이루어져 있고, Netflix는 Adrian Cockcroft에 따르면 600개가 넘는다. 각 서비스는 여러 개의 runtime instance를 가지고 있을 것이다. 여기에는 설정하고, 배포하고, 확장하고, 모니터링 대상이 되는 많은 이동하는 부품들이 있다. 게다가, 하나의 서비스에서 통신할 필요가 있는 다른 서비스들의 위치(host and ports)를 찾기 위한 service discovery mechanism(나중에 다른 post에서 논의할 것이다.)을 구현할 필요가 있다. 전통적인 trouble ticket 기반과 operation에 대한 수작업 접근법은 복잡도의 레벨을 변경할 수 없다. 따라서, microservice application 을 성공적으로 배포하는 것은 개발자들이 배포 방법을 더 많이 제어하고, high level 자동화가 필요하다.

자동화에 대한 한가지 접근 방법은 Cloud Foundry와 같은 기성 PaaS를 이용하는 것이다. PaaS는 개발자들이 microservice를 배포하고 관리하는 데 쉬운 방법을 제공한다. PaaS는 IT 리소스를 어렵게 구하고 설정하는 것에 대한 우려를 불식시킨다. 동시에, PaaS를 설정하는 시스템과 네트워크 전문가들은 best practice와 회사 정책에 따른 법규 준수를 보장할 수 있다. Microservice 배포를 자동화하는 또다른 방법은 근본적으로 여러분 자신의 PaaS를 개발하는 것이다. 한가지 전형적인 시작 포인트는 Docker와 같은 기술과 함께 Kubernetes와 같은 클러스터링 솔루션을 이용하는 것이다. 이 시리즈의 뒤쪽에서, Microservice level에서 caching, access control, API metering, monitoring을 쉽게 다루는 NGINX와 같은 software 기반 어플리케이션 배포 방법들이 이 문제를 해결하는데 어떤 도움을 줄 수 있는지를 보여줄 것이다.

Microservice Architecture Pattern은 많은 중요한 혜택을 준다.

첫번째로, 복잡성의 문제를 다룬다. Microservice Architecture Pattern은 괴물같은 monolithic application을 반대로 service들의 집합으로 분해한다. 전체 기능성을 변경하지 않는 범위내에서 관리가능한 덩어리나 서비스로 application을 쪼갠다. 각 서비스는 RPC-나 메시지 기반 API 형태로 잘 정의되어 있는 경계를 가진다. Microservice Architecture Pattern은 실제 monolithic code에서는 극도로 달성하기 어려운 모듈화(modularity) 수준을 강화한다. 따라서, 개별 서비스를 훨씬 더 빨리 개발하고, 더 이해하기 쉽고, 유지하기도 쉽다.

두번째로, 이 아키텍처는 한 팀에서 각각의 서비스에 초점을 맞춰 독립적으로 개발할 수 있게 한다. 개발자들은 API를 붙여서 명예로운 서비스를 제공하는데 어떤 기술이 적합한지 선택하는데 자유롭다. 물론, 대부분의 조직에서는 완전한 무정부 상태를 피하고 기술 선택을 제한하고 싶을 것이다. 그러나 이러한 자유는 개발자들이 신규 프로젝트를 시작할 때 존재했던 한물간 기술을 더이상 의무적으로 사용하지 않아도 된다는 것을 의미한다. 새로운 서비스를 만들 때, 현재 기술을 사용할 선택권을 갖는다. 더 나아가, 서비스들이 상대적으로 작기 때문에 현재의 기술을 사용하여 예전 서비스들을 재작성하는 것이 가능하다.

세번째는, Microservice Architecture Pattern에서는 각 microservice별로 독립배포가 가능하다. 개발자들은 로컬환경에서 서비스로 변경 사항들을 배포할 때, 조정할 필요가 없다. 변경 사항들은 테스트가 완료되는 대로 즉시 배포할 수 있다. 예를 들어, UI 팀은 A/B 테스트를 수행하고, UI를 변경하는 작업을 빠르게 반복할 수 있다. Microservice Architecture Pattern은 지속적인 배포가 가능하다.

끝으로, Microservice Architecture Pattern은 각 서비스별로 독립적인 확장이 가능하다. 각 서비스별로 용량과 가용성 제약사항들을 만족시키는 범위 내에서 수많은 인스턴스에 배포할 수 있다. 게다가, 서비스의 리소스 요구사항에 가장 적합한 하드웨어를 사용할 수 있다. 예를 들어, EC2 Compute Optimized instance에 CPU-집중적인 이미지 프로세싱을 배포할 수 있다. 그리고 EC2 Memory Optimized instance에 인메모리 데이터베이스 서비스를 배포할 수 있다.