전체 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를 사용하는 접근법을 제안한다.
Introduction
여러분이 쇼핑 application을 위해 native mobile application을 개발하고 있다고 가정해 보자. 주어진 상품에 대한 정보를 보여주는 상품 상세 페이지를 개발해야만 할 것이다. 예를 들어, 다음 다이어그램은 아마존 안드로이드 모바일 application에서 상세한 상품 정보를 스크롤했을 때, 여러분이 무엇을 보는 지를 보여준다.
비록 스마트폰 어플리케이션이지만, 상품 상세 페이지는 많은 정보를 보여준다. 예를 들면, 기본적인 상품정보(이름이나 설명, 가격과 같은) 뿐만 아니라 이 페이지는 다음 내용을 보여주고 있다.
- 쇼핑 카트에 있는 상품 수
- 주문 이력
- 고객 리뷰
- 낮은 재고에 대한 경고
- 배송 방법
- 이 상품을 구매한 사람들이 자주 함께 구매한 다른 상품이나 보았던 다른 상품을 포함한 다양한 추천
- 다른 구매 방법
Monolithic application architecture를 사용할 경우, 모바일 클라이언트는 어플리케이션에 한번의 REST 호출(GET api.company.com/productdetails/productId)로 이 데이터를 얻어야 한다. 로드밸런서는 일반적으로 N개의 어플리케이션 인스턴스 중 하나로 요청을 전송한다. 어플리케이션은 다양한 데이터베이스 테이블에 질의하고, 그 결과를 클라이언트로 보낼 것이다.
반대로, microservice architecture에서는 상품 상세 페이지를 보여주는 데이터를 여러 개의 microservice가 소유하고 있다. 여기 상품 상세 페이지 예제로 소유한 데이터를 보여주는 몇가지 가능성이 있는 microservice가 있다.
- 쇼핑 카트 서비스 : 쇼핑 카트에 있는 상품 수
- 주문 서비스 : 주문 이력
- 카탈로그 서비스 : 상품의 이름과 이미지, 가격과 같은 기본 상품 정보
- 리뷰 서비스 : 고객 리뷰
- 재고 서비스 : 낮은 재고 상품에 대한 경고
- 배송 서비스 : 배송방법, 마감시간, 배송 제공하는 API로부터 별도로 뽑아내진 비용
- 추천 서비스 : 추천 상품
우리는 모바일 클라이언트에서 이러한 서비스들에 어떻게 접근할 수 있을지 결정해야만 한다.
몇 가지 옵션들에 대해서 살펴보자.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/752