Microservices-Tackling the Complexity
   (Microservice - 복잡함에 태클을 걸다)

Amazon, eBay, Netflix 같은 많은 조직들에서 Microservice Architecture Pattern이라고 알려져 있는 기술을 채택하여 이러한 문제를 해결하고 있다. Microservice Architecture 하나의 괴물같은 monolithic application 만드는 대신에, 작고 서로 연결되어 있는 서비스들의 집합으로 application 나누는 것이다.


일반적으로 서비스는 order management(주문관리), customer management(고객관리), 등과 같은 별개의 특징이나 기능 집합으로 구현되어 있다. 각각의 microservice 자체에 다양한 어댑터에 대한 비즈니스 로직을 가진 6각형의 아키텍처를 가지는 mini-application이다. 어떤 microservice 다른 microservice application client 의해서 호출되는 API 제공하고, 다른 microservice Wen UI 구현할 수도 있다.


런타임시에는 각각의 instance 클라우드 VM이나 Docker container 상에 실행되기도 한다.


예를 들면, 앞서 기술된 시스템을 분해하면, 다음과 같은 다이어그램으로 표현할 있다.


사용자 삽입 이미지


Application 개별 기능은 각각의 microservice 구현되어 있다. 더욱이 web application 간단한 web application 집합으로 나누어져 있다. (택시 호출 서비스 예제에서 보면, 명의 운전 기사가 명의 승객과 매칭되는 경우). 이것은 특정 user, device, 혹은 특별한 use case별로 개별 경험을 쉽게 배포하게 한다.


backend service REST API 제공하고, 대부분의 service들은 다른 service 제공하는 API 사용한다. 예를 들어, Driver Management(기사 관리) 잠재적 이동에 대해 활동 가능한 운전 기사에게 알려주는데 Notification Server 사용한다. UI service들은 web page들을 렌더링하기 위해 다른 서비스들을 호출한다. 서비스들은 메시지 기반의 communication async방식을 사용한다. 서비스간의 communication 대해서는 추가로 나중에 자세히 다룰 것이다.


몇몇 REST API 기사나 승객에 의해 사용되는 mobile app에서 이용한다. 그러나 이러한 app들은 backend service 직접 접속할 없다. 대신에 communication API Gateway 알려진 중재자를 통해 가능하게 된다. API Gateway 로드밸런싱, caching, access control, API metering, monitoring 같은 부분들을 처리해야 한다. 이러한 부분들은 nignx 사용하여 효과적으로 구현할 있다.


사용자 삽입 이미지


Microservice architecture pattern scalability(확장성) 3D Model 대한 최고의 책인 "The Art of Scalability" 나오는 Scale Cube Y Scaling 대응된다. 다른 2개의 Scaling 축은 load balancer 뒤에서 실행중인 여러 개의 동일한 application 복사본으로 구성된  X Scaling 요청의 속성(예를 들면, row primary key 고객의 identity) 특정 서버에 대한 요청으로 route하는데 사용되는 Z Scaling(혹은 data partitioning) 있다.


Application들은 일반적으로 3가지 Scaling 타입을 함께 사용한다. Y Scaling 섹션 첫번째 그림에서 보여주는 대로 application microservice로 분해한다. Runtime 시점에 X Scaling load balancer 뒤에서 처리량과 가용성을 위해 서비스에 대해 여러 개의 instance 실행한다. 어떤 application들은 service partition하기 위해 Z Scaling 사용하기도 한다.


다음 다이어그램은 Trip Management 서비스가 Amazon EC2 서버 상에 Docker 어떻게 배포되는지를 보여준다.


사용자 삽입 이미지


Runtime시에 Trip Management 서비스는 여러 개의 instance 구성되어 있다. 서비스 instance Docker container 제공된다. 가용성을 높이기 위해서 docker container들은 여러 개의 cloud VM에서 돌아간다. Service instance 앞단에는 여러 instance 요청을 분산하는 nginx 같은 load balancer가 있다. Load balancer caching, access control, API metering, monitoring 같은 여러 가지 관심 사항들을 취급할 있어야 한다.


Microservice Architecture Pattern 특히 application database 사이의 관계에 중요한 영향을 준다. 서로 다른 service 하나의 database schema 공유하는 것보다는 각각의 서비스가 독자적인 database schema 갖는다. 다른 한편으로 이러한 접근은 Enterprise-Data Model 관점에서는 이상하다. 또한, 어떤 데이터들은 종종 중복되기도 한다. 그러나 서비스별 database schema 갖는 것은 microservice 통해 혜택을 보기 원한다면, 본질적인 부분이다. 왜냐하면, microservice 느슨한 연결(loose coupling) 보장하기 때문이다. 다음 다이어그램은 예제로 제시된 application 대한 database architecture 보여주고 있다.


사용자 삽입 이미지

각각의 서비스는 자체적으로 데이터베이스를 가지고 있다. 게다가, 서비스별로 소위 polyglot persistence architecture(상황에 맞게 최적화된 구조로 데이터를 구분하여 저장하는 아키텍처)라고 불리는 가장 최적의 데이터베이스 타입을 사용할 있다.


예를 들어, 잠재적인 승객에게 가장 가까운 운전 기사들을 찾아야 하는 Driver Management(기사 관리) geo-query(지리기반 질의) 지원하는 데이터베이스를 사용해야만 한다. 표면적으로는 MSA SOA 유사하다. 두가지 모두 서비스들의 집합으로 구성된 아키텍처이다. 하지만, MSA WS 표준과 ESB 없는 SOA라고 생각하면 된다.


Microservice 기반 application WS 표준보다 굉장히 단순하고, REST 같은 가벼운 프로토콜을 사용한다. 또한 ESB 사용을 지양하고, microservice 자체적으로 ESB 유사한 기능을 구현한다. Microservice Architecture Pattern 정규 스키마(canonical schema) 같은 SOA 다른 부분도 거부한다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/747

트랙백 주소 :: http://www.yongbi.net/trackback/747

트랙백 RSS :: http://www.yongbi.net/rss/trackback/747

댓글을 달아 주세요

댓글 RSS 주소 : http://www.yongbi.net/rss/comment/747
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다