Micro Service Architecuture 의 중심 API Server

2010년 이후 급격하게 보급된 스마트폰으로 인해 브라우저를 통한 웹서비스 외에도 모바일 앱를 함께 고려한 멀티 채티 서비스를 필수적으로 고민해야 되는 시기가 왔다.
어떠한 서비스는 웹보다는 앱이 메인이 되는 서비스도 많이 늘어났지만 , 일반적인 기업환경에서 웹서비스를 메인으로 고객을 위한 디바이스 채널이 점점 늘리는 추세이며, 그에 따라 개발 비용 증가 및 빠른 서비스 출시에 대한 압박이 심해지고 있다.

 다양한 플랫폼을 준비해야 되는 상황에서 어떻게 보다 빠르게 서비스를 출시하고 개발하기 위해 필수적인 MSA(Micro Service Architecture) 및 그 중심인 API Server에 대해 알아보도록 하겠다.

Monolithic Architecture

일반적인 서버 사이드 기업용 web application 은 Java 인 경우는 WAR(Web Application ARchive) 형태와 같은 모놀리틱 아키텍처를 가지고 있다. 
모놀리틱 아키텍처는 단일 디렉토리 구조에 모든 데이터 억세스부터 controller , 화면 관련 UI 및 각종 library 까지 하나의 단일 디렉토리 구조에 모두 모아놓고 배포하는 방식이다.
아래 그림과 같이 하나의 배포판에 모든 UI 및 controller , 그리고 각종 Business Logic 이 하나로 묶여서 관리, 배포되는 방식이다. 상황에 따라 유지보수나 사이트를 관리하면서 각 기능별로 별도로 개발, 배포하고 있지만, 근본적인 형태는 아래와 같다.
[기본 모놀리틱 아키텍처 구조]


초창기 WAR 크기나 규모는 지금처럼 크지 않았지만 현재 대부분은 웹서비스는 그 규모가 상당히 크기때문에 WAR 단위로 배포하고 관리하기는 힘들어지는 단점을 가지고 있다.

초기 모놀리틱 아키텍처의 장점은 다음과 같았다.

  • 개발 편의성 : IDE툴이 모놀리틱 아키텍처 개발방식에 최적화 되어있다.
  • 배포 단순함 : 손쉽게 WAR 형태로 배포할 수 있다.
  • 확장성 : 다수의 WAR 형태를 이용해서 손쉽게 시스템을 확장할 수 있다.
현재 위의 3가지 장점을 동의하는 개발자나 TA 는 거의 없을 것 같다. 왜냐하면 예전처럼 웹 서비스 개발 규모가 단순하지 않고 고려해야 될 사항이 많기 때문이다.  현재 웹 어플리케이션  규모가 엄청나게 커져서 개발,배포,확장성 모두 불편해지고 있는 상황이며 아래와 같은 단점을 가지는 아키텍처 구조가 되어 버렸다.

  • 웹 어플리케이션 이해를 어렵게 만들고, 수정도 어려워 진다. 모듈화는 시간이 갈수록 의미가 없어지며, 소스 품질도 점점 낮아진다.
  • IDE 개발의 어려움 : 한번 WAS에 올라가는 프로그램 양이 커지고 무거워 져서 테스트도 힘들고 종속성이 강해지며 디버그도 힘들어진다.
  • 배포 문제점 : 작은 단위로 배포할 수 있겠지만 이것은 원래 WAR의 취지가 아니다. 콤포넌트가 변경되면 그 콤포넌트에 연관된 배포도 함께 고려해야 되어야 한다.
  • 작업분배의 어려움 : 일반적으로 메뉴 단위로 할 수 밖에 없는데, 어느 부분까지 공통영역이고 어느 부분까지 별도의 개발영역인지 애매할 때가 많다.


새로운 대안 Micro Service Architecture

기존의 무겁고 변경이 힘든 아키텍처 구조에서 새롭게 대안이 되고 있는 방식은 마이크로 서비스 아키텍처 구조이다.
각각의 작은 서비스 단위로 분할하고 각 서비스가 기존에 영향을 받지 않고 개발/배포를 가능하도록 하기 위한 아키텍처 구조로 아직 명확하게 정답이 있는 상황은 아니지만,기존의 모놀리틱 아키텍처 문제점을 상당부분 해결해 줄 수 있는 기대를 한 몸에 받고 있는 아키텍처이다.

[Micro Service Architecture]


MSA 는 다음과 같은 특징을 가지고 있습니다.

  • small & focus: 각 기능들은 작게 설계되고 한가지 일을 잘하는데 집중
  • API : 각각의 서비스는 API를 통해 통신
  • autonomous : 자율적으로 서로 영향을 최소화

MSA 의 핵심  API  Server

Micro Service Architecture가 가능하도록 하는 핵심 기술에는 API 서비스가 있다. 가장 기본적으로 UI 및 비즈니스 로직을 분리해야 하는데 현재로는 API Server(Gateway)를 통해 분리시키는 것이 가장 이상적인 방법이 때문이다.
모놀리틱 아키텍처 구조에서는 특정 서버에 있는 비즈니스 로직을 이용하고 싶어도 기술적으로 풀어야 할 문제들이 상당히 많기 때문에 실제 프로젝트에서는 중복적인 난개발이 이루어지는 경우가 상당히 많다.

[API Server 아키텍처]

위 그림에서와 같이 기업내부의 database 및 EAI 서버와 같이 각종 데이터 이용에 대한 부분을 API Server 를 통해 통제하고 관리하도록 하며, 그 데이터 이용을 REST 나 다양한 web protocol 을 통해 모바일앱이나 웹에서 손쉽게 사용할 수 있도록 하는데 특징이 있다. 

API 서비스 중심으로 아키텍처가 개편되면 비즈니스 재활용성도 높이며 그 로직을 활용하는 UI도 업무 기술 종속성을 탈피하여 서비스 개발 및 배포의 생산성을 극대화 할 수 있습니다.

API 서비스를 말하면 보통 OPEN API 기반의 공개용 API 서비스르 생각하기 쉽지만, Google,Netflix나 Amazon 과 같은 회사들은 이미 기업 내부의 업무로직을 API 로 정의하고 각 웹서비스나 앱에서는 그 API 를 호출해서 사용하는 방식을 취하고 있다.
가장 유명한 일화는 2002년 Amazon CEO Jeff Bezos가 내부 역량강화를 위해 내부 개발자에게 API 개발 강령을 정의하고 강제화 하도록 하였다.

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  • It doesn’t matter what technology they use.
  • All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.


API Server의 역활
기업환경에서 API 서버는 다음과 같은 역활을 할 수 있다.

통합 개발 환경
 - 새로운 서비스나 프로그램 개발시 처음부터 모놀리틱 방식으로 모든것을 구축 할 필요없이 필요한 업무로직 개발 및 이용에 집중할 수 있다.

모바일 앱 Backend service
 - iOS및 안드로이드 뿐만 아니라 각종 디바이스용 앱을 개발할때마다 별도의 backend service 를 구축할 필요 없이 API Server를 통해 Mobile backend server를 손쉽게 구축할 수 있다. 앱뿐만 아니라 기타 다양한 어플리케이션에서 바로 이용이 가능하다.

Business Logic 관리

 - 업무로직을 업데이트하고 변경할때마다 어떻게 분산되고 이용되지는 기존 모놀리틱 아키텍처에서는 파악하기 힘들다. API  Server를 통한 중앙 통제는  기존 로직을 그대로 이용하면서 버전업을 하거나 병행처리가 가능하기 때문에 생산성 향상 및 개발 안정성이 증대된다.


참고문서



New Multi-Channel Dynamic CMS