:: 배경 ::

마이크로 서비스 아키텍처(MSA)는 근래의 웹기반의 분산 시스템의 디자인에 많이 반영되고 있는 아키텍처 스타일로 특정 사람이 정의한 아키텍처가 아니라, 분산 웹 시스템의 구조가 유사한 구조로 설계되면서, 개념적으로만 존재하던 개념이다.

:: 개념 ::

 

마이크로 서비스 아키텍처는 대용량 웹서비스가 많아짐에 따라 정의된 아키텍처인데, 그 근간은 SOA(Service Oriented Architecture: 서비스 지향 아키텍쳐)에 두고 있다. SOA는 엔터프라이즈 시스템을 중심으로 고안된 아키텍처라면 마이크로 서비스 아키텍처는 SOA 사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처이다.

:: 아키텍처 구조 ::

① 서비스
마이크로 서비스 아키텍처에서는 각 컴포넌트를 서비스라는 개념으로 정의한다. 서비스는 데이터에서부터 비즈니스 로직까지 독립적으로 상호 컴포넌트간의 의존성이 없이 개발된 컴포넌트(이를 버티컬 슬라이싱/vertical Slicing-수직적 분할이라고 한다.)로 REST API와 같은 표준 인터페이스로 그 기능을 외부로 제공한다. 서비스 경계는 구문 또는 도메인(업무)의 경계를 따른다. 예를 들어 사용자 관리, 상품 관리, 주문관리와 같은 각 업무별로 서비스를 나눠서 정의한다. 사용자/상품 관리처럼 여러 개의 업무를 동시에 하나의 서비스로 섞어서 정의하지 않는다. REST API에서 /users, /products와 같이 주요 URI도 하나의 서비스 정의의 범위로 좋은 예가 된다.

② 마이크로 서비스 아키텍처의 구조
마이크로 서비스 아키텍처의 구조는 다음과 같은 모양을 따른다.
각 컴포넌트는 서비스라는 형태로 구현되고 API를 이용하여 타 서비스와 통신을 한다.

배포 구조관점에서도 각 서비스는 독립된 서버로 타 컴포넌트와의 의존성이 없이 독립적으로 배포된다.

 

예를 들어 사용자 관리 서비스는 독립적인 war파일로 개발되어, 독립된 Tomcat 인스턴스에 배치된다. 확장을 위해서 서비스가 배치된 Tomcat
인스턴스는 횡적으로 스케일(인스턴스 수를 더함으로써)이 가능하고, 앞단에 로드 밸런서를 배치하여 서비스간의 로드를 분산시킨다.
가장 큰 특징이, 애플리케이션 로직을 분리해서 여러개의 애플리케이션으로 나눠서 서비스화하고, 각 서비스별로 Tomcat을 분산 배치한 것이
핵심이다.

③ 데이터 분리
데이터 저장관점에서는 중앙 집중화된 하나의 통 데이터베이스를 사용하는 것이 아니라 서비스 별로 별도의 데이터베이스를 사용한다.보통 모노리틱 서비스의 경우에는 하나의통 데이터베이스(보통 R DBMS를 사용)하는 경우가 일반적이지만, 마이크로 서비스 아키텍처의 경우, 서비스가 API에서부터 데이터베이스까지 분리되는 수직 분할원칙(vertical Slicing)에 따라서 독립된 데이터베이스를 갖는다.

데이터베이스의 종류 자체를 다른 데이터베이스를 사용할 수도 있지만, 같은 데이터베이스를 사용하더라도 DB를 나누는 방법을 사용한다.
이 경우, 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포운영 할 수 있다는 장점을 가지고 있으나, 다른 컴포넌트의
데이터를 API통신을 통해서만 가지고 와야 하기 때문에 성능상 문제를 야기할 수 있고, 또한 이 기종 데이터베이스간의 트렌젝션을 묶을 수 없는
문제점을 가지고 있다.

:: API Gateway ::

마이크로 서비스 아키텍처 설계에 있어서 많이 언급되는 컴포넌트 중의 하나가 API Gateway라는 컴포넌트이다. API Gateway는 마치 Proxy 서버처럼 API들 앞에서 모든 API에 대한 end point를 통합하고, 몇가지 추가적인 기능을 제공하는 미들웨어로, SOA의 ESB(Enterprise Service Bus)의 경량화 버전이다. API Gateway가 마이크로 서비스 아키텍처 상에서 수행하는 주요 기능을 살펴보면 다음과 같다.

◎ End Point 통합 및 토폴로지 정리
마이크로 서비스 아키텍처의 문제점 중의 하나는 각 서비스가 다른 서버에 분리 배포되기 때문에 API의 End Point 즉, 서버의 URL이 각기 다르다는 것이다.사용자 컴포넌트는 http://user.server.com 상품 컴포넌트는 http://product.server.com과 같은 분리된 URL을 사용하는데, 이는 API 사용자 경험 관점에서도 사용하기가 불편하다.

특히 마이크로 서비스 아키텍처는 컴포넌트를 되록이면 업무 단위로 잘게 자르는 fine grained(작은 덩어리)의 서비스를 지향하기 때문에,
컴포넌트의 URL 수는 더 많이 늘어날 수 있다. API를 사용하는 클라이언트에서 서버간의 통신이나, 서버간의 API 통신의 경우 P2P(Point to Point)형태로 토폴로지가 복잡해지고 거미줄 모양의 서비스 컴포넌트간의 호출 구조는 향후 관리의 문제를 일으킬 수 있다. 하나의 end point를 변경하였을 때, 제대로 관리가 되지 않을 경우가 있다.



이러한 토폴로지상의 문제점을 해결하기 위해서 중앙에 서비스 버스와 같은 역할을 하는 채널을 배치 시켜서, 전체 토폴로지를 P2P에서
HUB & SPOKE 방식으로 변환시켜서, 서비스간 호출을 단순화 시킬 수 있다.




◎ Orchestration
다른 기능으로는 Orchestration이라는 개념이 잇다. 기존 Open API의 mash up과 같은 개념으로 여러개의 서비스를 묶어서 하나의 새로운 서비스를 만드는 개념이다.예를 들어, 포인터 적립과, 물품구매라는 서비스가 있을 때, 이 두 개의 서비스를 묶어서 "물품구입 시 포인트 적립"이라는 새로운 서비스를 만들어 낼 수 있다. 이러한 Orchestration기능은 API Gateway를 통해서 구현될 수 있다.

이는 마이크로 서비스 아키텍처가 서비스 자체가 Fine grained 형태로 잘게 쪼개졌기 때문에 가능한 일인데, 사실 Orchestration을 API Gateway계층에서 하는 것은 Gateway 입자에서 부담이 되는 일이다. 실제로 과거의 SOA 시절에 많은 ESB(Enterprise Service Bus) 프로젝트가 실패한 원인 중의 하나가 과도한 Orchestration로직을 넣어서 전체적인 성능 문제를 유발한 경우가 많았다. 그래서 Orchestration 서비스의 활용은 마이크로 서비스 아키텍처에 대한 높은 이해와 API Gateway자체에 대한 높은 수준의 기술적인 이해를 필요로 한다.실제로 넥플릭스의 경우 마이크로 서비스 아키텍처를 사용하면서, 여러개의 서비스들을 Gateway 계층을 통해서 Orchestration하는 모델을 사용하고 있다.


◎ 공통 기능 처리(Cross cutting funtion handling)
또한 API에 대한 인증(Authentication)이나, Logging과 같은 공통 기능에 대해서 서비스 컴포넌트 별로 중복 개발해야하는 비효율성을
유발할 수 있다. API Gateway에서 이러한 공통기능을 처리하게 되면, API 자체는 비즈니스 로직에만 집중을 하여 개발에 있어서의 중복 등을
방지할 수 있다.mediation 이외에도 XML이나 네이티브 메시지 포맷을 json등으로 상호 변화해주는 message transformation 기능이나,
프로토콜을 변환하는 기능, 서비스간의 메시지를 라우팅해주는 기능 등 여러 가지 고급 mediation 기능을 제공을 하지만, API Gateway를 최대한
가볍게 가져간다는 설계 원칙 아래서 가급적이면 고급적인 mediation 기능을 사용할 때는 높은 수준의 설계와 기술적인 노하우를 동반해야 한다.

※ ESB vs, API Gateway
SOA 프로젝트의 실패중의 하나가 ESB로 꼽히는 경우가 많은데, 이는 ESB를 Proxy나 Gateway처럼 가벼운 연산만이 아니라, 여러개의 서비스를 묶는 로직에 무겁게 사용했기 때문이다. ESB 메시지를 내부적은 XML로 변환하여 처리하는데, XML처리는 생각하는 것보다 파싱에 대한 오버헤드가 매우 크다. 또한 ESB의 고유적인 버스나 게이트웨이로써의 특성이 아니라 타 시스템을 통합하기 위한 EAI적인 역할을 ESB를 이용해서 구현함으로써 많은 실패 사례를 만들어 내었다. 그래서 종종 ESB는 Enterprise Service Bus가 아니라 Enterprise nightmare Bus로 불리기도 한다.


:: 마이크로 서비스 아키텍처의 문제점 ::

① 성능
마이크로서비스 아키텍처는 서비스간의 호출을 API 통신을 이용하기 때문에 값을 json이나 XML에서 프로그램밍에서 사용하는 데이터 모델(java object 등)으로 변환하는 marsharing 오버헤드가 발생하고 호출을 위해서 이 메시지들이 네트워크를 통해서 전송되기 때문에 그만한 시간이 더 추가로 소요된다.

② 메모리
마이크로 서비스 아키텍처는 각 서비스를 독립된 서버에 불할 배치하기 때문에 중복되는 모듈에 대해서 그만큼 메모리 사용량이 늘어난다.
예를 들어 하나의 Tomcat 인스턴스에서 사용자 관리와 상품 관리를 배포하여 운용할 경우, 하나의 Tomcat을 운영하는데 드는 메모리와 스프링
프레임웍과 같은 라이브러리를 사용하는데 소요되는 메모리 그리고 각각의 서비스 애플리케이션이 기동하는 메모리가 필요하다. 그러나 마이크로
서비스 아키텍처로 서비스를 배포할 경우 사용자관리 서비스 배포와 상품 관리 서비스 배포를 위한 각각의 별도의 Tomcat 인스턴스를 운용해야 하고, 스프링 프레임웍과 같은 공통 라이브러리도 각각 필요하기 때문에 배포하고자 하는 서비스의 수만큼 중복된 양의 메모리가 필요하게 된다.

위의 두 문제는 반드시 발생하는 문제점이기는 하나 현대의 인프라 환경에서는 크게 문제는 되지 않는다. 현대의 컴퓨팅 파워 자체가 워낙
발달하였고, 네트워크 인프라 역시 기존에 1G 등에 비해서 내부 네트워크는 10G를 사용하는 등, 많은 성능상 발전이 있었다.
메모리 역시 비용이 많이 낮춰지고 32bit에서 64bit로 OS들이 바뀌면서, 가용 메모리 용량이 크게 늘어나서 큰 문제는 되지 않는다.
또한 성능상의 문제는 비동기 패턴이나 캐슁 등을 이용해서 해결할 수 있는 다른 방안이 많기 때문에 이 자체는 큰 문제가 되지 않는다.


:: Evolutionary Model ::

마이크로 서비스 아키텍처는 서비스의 재사용성, 유연한 아키텍처 구조, 대용량 웹 서비스를 지원할 수 있는 구조 등으로 많은 장점을 가지고 있지만, 운영하는 팀에 대해서 높은 성숙도를 필요로 한다. 그래서 충분한 능력을 가지지 못한 팀이 마이크로 서비스 아키텍처로 시스템을 개발할 경우에는
많은 시행착오를 겪을 수 있다.
마이크로 서비스 아키텍처를 적용할 때는 처음부터 시스템을 마이크로 서비스 아키텍처 형태로 설계해서 구현할 수도 있겠지만, 모노리틱 시스템에서부터 시작하여 비즈니스 운용 시 오는 문제점을 기반으로 점차적으로 마이크로 서비스 아키텍처 형태로 진화시켜 나가는 방안도 좋은 모델이 된다. 비즈니스와 고객으로부터 오는 피드백을 점차적으로 반영 시켜나가면서 동시에 팀의 성숙도를 올려가면서 아키텍처 스타일을 변화시켜가는 모델로 많은 기업ㅇ들이 이런 접근 방법을 사용했다. 트위터의 경우에도 모노리틱 아키텍처에서 시작해서 팀의 구조를 점차적으로 변환시켜 가면서 시스템의 구조 역시 마이크로 서비스 아키텍처 형태로 전환을 하였고, 커머스 시장에서 유명한 이베이 같은 경우에도 그 시대의 기술적 특성을 반영하면서 비즈니스의 요구사항을 적절히 반영 시켜가면서 시스템을 진화형 모델로 전환하였다.

:: 결론 ::

마이크로 서비스 아키텍처는 대용량 웹시스템에 맞춰 개발된 API 기반의 아키텍처 스타일이다. 대규모 웹서비스를 하는 많은 기업들이 이와 유사한 아키텍처 설계를 가지고 있지만, 마이크로 서비스 아키텍처가 무조건 정답은 아니다. 하나의 설계에 대한 레퍼런스 모델이고, 각 업무나 비즈니스에 대한 특성 그리고 팀에 대한 성숙도와 가지고 있는 시간과 돈과 같은 자원에 따라서 적절한 아키텍처 스타일이 선택되어야 하며, 또한 아키텍처는 처음부터 완벽한 그림을 그리기 보다는 상황에 맞게 점진적으로 진화 시켜 나가는 모델이 바람직하다. 특히 근래의 아키텍처 모델은 시스템에 대한 설계 사상뿐만 아니라 개발조직의 구조나 프로젝트 관리 방법론에까지 영향을 미치기 때문에 단순히 기술적인 관점에서가 아니라 조금 더 거시적인 관점에서 고려를 해볼 필요가 있다.

[출처]
Ebay 아키텍처
Netflix 아키텍처
http://bcho.tistory.com/m/post/948