Micro Service Architecture
1. Micro Service(마이크로 서비스)란
애플리케이션을 느슨히 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선시키고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄련적으로 만들어 준다.
규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다. 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(deploy)를 가능케 한다.
2. Monolithic Architecture(모노리틱 아키텍처)
모노리틱 아키텍쳐 스타일은 기존의 전통적인 웹 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직들이 모두 들어 가 있는 “통짜 구조” 이다.
예를 들어, 온라인 쇼핑몰 애플리케이션이 있을때, 톰캣 서버에서 도는 WAR 파일(웹 애플리케이션 패키징 파일)내에, 사용자 관리,상품,주문 관리 모든 컴포넌트들이 들어 있고 이를 처리하는 UX 로직까지 하나로 포장되서 들어가 있는 구조이다.
각 컴포넌트들은 상호 호출을 함수를 이용한 call-by-reference 구조를 취한다.
1) 장점
전체 애플리케이션을 하나로 처리하기 때문에, 개발툴 등에서 하나의 애플리케이션만 개발하면 되고, 배포 역시 간편하며 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 편리하다.
- 개발 환경과 개발 방법이 통일되어 있으므로 복잡할 게 없다.
- 기존 IDE와 툴을 이용해 개발하기가 용이하다(각종 툴이 싱글 애플리케이션 개발에 초점이 맞춰져 있음).
- End-to-End 테스트가 쉽다.
- 배포가 간편하다(빌드 결과를 WAS에 올리기만 하면 됨).
- 같은 애플리케이션을 여러개 두고 로드 밸런서를 앞에 두는 방법으로 쉽게 확장(scale)할 수 있다.
2) 단점
모노리틱 구조의 경우 작은 크기의 애플리케이션에서는 용이 하지만, 규모가 큰 애플리케이션에서는 불리한 점이 많다.
크기가 크기 때문에, 빌드 및 배포 시간, 서버의 기동 시간이 오래 걸리며 프로젝트를 진행하는 관점에서도, 한두사람의 실수는 전체 시스템의 빌드 실패를 유발하기 때문에, 프로젝트가 커질 수 록, 여러 사람들이 협업 개발하기가 쉽지 않다.
또한 시스템 컴포넌트들이 서로 로컬 콜(call-by-reference) 기반으로 타이트하게 연결되어 있기 때문에, 전체 시스템의 구조를 제대로 파악하지 않고 개발을 진행하면, 특정 컴포넌트나 모듈에서의 성능 문제나 장애가 다른 컴포넌트에까지 영향을 주게 되며, 이런 문제를 예방하기 위해서는 개발자가 대략적인 전체 시스템의 구조 등을 이해 해야 하는데, 시스템의 구조가 커질 수 록, 개인이 전체 시스템의 구조와 특성을 이해하는 것은 어려워진다.
특정 컴포넌트를 수정하고자 했을때, 컴포넌트 재 배포시 수정된 컴포넌트만 재 배포 하는 것이 아니라 전체 애플리케이션을 재 컴파일 하여 전체를 다시 통으로 재배포 해야하기 때문에 잦은 배포가 있는 시스템의 경우 불리하며, 컴포넌트 별로, 기능/비기능적 특성에 맞춰서 다른 기술을 도입하고자 할때 유연하지 않다.
모노리틱 아키텍쳐가 꼭 나쁘다는 것이 아니다. 규모가 작은 애플리케이션에서는 배포가 용이하고, 규모가 크더라도, call-by-reference call에 의해서 컴포넌트간 호출시 성능에 제약이 덜하며, 운영 관리가 용이하다. 또한 하나의 구조로 되어 있기 때문에, 트렌젝션 관리등이 용이하다는 장점이 있다.
즉 마이크로 서비스 아키텍쳐가 모든 부분에 통용되는 정답은 아니며, 상황과 필요에 따라서 마이크로 서비스 아키텍쳐나 모노리틱 아키텍쳐를 적절하게 선별 선택 또는 변형화 해서 사용할 필요가 있다.
3. Micro Service Architecture(마이크로 서비스 아키텍처)
마이크로 서비스 아키텍쳐는 대용량 웹서비스가 많아짐에 따라 정의된 아키텍쳐인데, 그 근간은 SOA(Service Oriented Architecture : 서비스 지향 아키텍쳐)에 두고 있다.
SOA는 엔터프라이즈 시스템을 중심으로 고안된 아키텍쳐라면, 마이크로 서비스 아키텍쳐는 SOA 사상에 근간을 두고 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍쳐이다.
1) 장점
- 빌드 및 테스트 시간이 단축: 기존 Monolithic은 시스템의 규모가 커질수록 빌드/테스트 시간 역시 길어진다. MSA에서는 해당 서비스만 빌드하기 때문에 배포 과정에서 시스템 규모의 영향을 받지 않는다.
- 서비스간 영향을 받지 않음: Monolithic에서 특정 컴포넌트에 치명적인 오류가 발생했을 경우 시스템 전체가 중단되는 사태가 발생할 수 있다. 하지만 MSA에서는 해당 서비스만 중단될 뿐 전체 서비스는에는 문제가 발생하지 않는다.
- Polyglot 아키텍쳐를 지원: MSA는 자율적이고 독립적이므로 각 서비스는 자신만의 고유한 아키텍쳐와 여러 가지 버전의 기술을 적용해서 구축하고 운영할 수 있다. 예를 들면 스케쥴러로 REST call을 하는 크롤러는 메모리 점유가 낮은 Python을 사용하고, API는 Spring+RDB로 개발하여 시스템을 운영할 수 있다.
- 탄력적이고 선택적인 확장: MSA는 필요한 서비스만을 선택하여 확장하는 선택적 확장과 서비스 품질(QoS; Quality of Service)를 구현할 수 있다. 전체 서비스 중 특정 서비스의 부하가 심할 경우 해당 서비스만 Scale In/Out 하여 성능을 높힐 수 있다.
2) 단점
- Monolithic에 비해 속도가 느림: MSA는 독립적으로 존재하는 서비스 간의 API GATEWAY를 통한 HTTP 통신으로 전체 서비스가 이루어진다. 이러한 구조는 서비스 운영에 안정적이긴 하지만 게이트웨이를 통하지 않는 내부 트랜잭션으로 서비스가 운영되는 Monolithic에 비해 속도가 느릴수 밖에 없다.
- 관리포인트가 늘어남: 하나의 어플리케이션을 여러개의 서비스로 나누기 때문에 모니터링, 로깅, 인스턴스 관리에 어려움이 있다.
3) 서비스
마이크로 서비스 아키텍쳐에서는 각 컴포넌트를 서비스라는 개념으로 정의한다.
서비스는 데이터에서 부터 비지니스 로직까지 독립적으로 상호 컴포넌트간의 의존성이 없이 개발된 컴포넌트(이를 버티컬 슬라이싱/Vertical Slicing-수직적 분할)로 REST API와 같은 표준 인터페이스로 그 기능을 외부로 제공한다.
서비스 경계는 구문 또는 도메인(업무)의 경계를 따른다. 예를 들어 사용자 관리, 상품 관리, 주문 관리와 같은 각 업무 별로 서비스를 나눠서 정의한다. 사용자/상품 관리 처럼 여러개의 업무를 동시에 하나의 서비스로 섞어서 정의하지 않는다.
REST API에서 /users, /products와 같이 주요 URI도 하나의 서비스 정의의 범위로 좋은 예가 된다.
4) 구조
마이크로 서비스 아키텍쳐의 구조는 다음과 같은 모양을 따른다. 각 컴포넌트는 서비스라는 형태로 구현되고 API를 이용하여 타 서비스와 통신을 한다.
배포 구조관점에서도 각 서비스는 독립된 서버로 타 컴포넌트와의 의존성이 없이 독립적으로 배포 된다.
예를 들어 사용자 관리 서비스는 독립적인 war파일로 개발되어, 독립된 톰캣 인스턴스에 배치된다. 확장을 위해서 서비스가 배치된 톰캣 인스턴스는 횡적으로 스케일(인스턴스 수를 더함)이 가능하고, 앞단에 로드 밸런서를 배치하여 서비스간의 로드를 분산 시킨다.
가장 큰 특징이, 애플리케이션 로직을 분리해서 여러개의 애플리케이션으로 나눠서 서비스화하고, 각 서비스별로 톰캣을 분산 배치한 것이 핵심이다.
5) 데이터 분리
데이터 저장관점에서는 중앙 집중화된 하나의 통 데이터베이스를 사용하는 것이 아니라 서비스 별로 별도의 데이터베이스를 사용한다.
보통 모노리틱 서비스의 경우에는 하나의 통 데이터베이스(보통 RDBMS를 사용) 하는 경우가 일반적이지만, 마이크로 서비스 아키텍쳐의 경우, 서비스가 API에서 부터 데이터베이스까지 분리되는 수직 분할 원칙(Vertical Slicing)에 따라서 독립된 데이터베이스를 갖는다.
데이터베이스의 종류 자체를 다른 데이터베이스를 사용할 수 도 있지만, 같은 데이터베이스를 사용하더라도 DB를 나누는 방법을 사용한다. 이 경우, 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영할 수 있다는 장점을 가지고 있으나, 다른 컴포넌트의 데이터를 API 통신을 통해서만 가지고 와야 하기 때문에 성능상 문제를 야기할 수 있고, 또한 이 기종 데이터베이스간의 트렌젝션을 묶을 수 없는 문제점을 가지고 있다. (이러한 데이터 분산에 의한 트렌젝션 문제는 SOA 때부터 있어 왔다.)