마이크로서비스

**마이크로서비스**()는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다. 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다. 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 한다.

## 개요
마이크로서비스의 속성과 관련하여 아직 산업적인 합의는 없으며 공식적인 정의도 없다. 자주 인용되어 정의되는 특징들 가운데 일부는 다음을 포함한다:
* 마이크로서비스 아키텍처(microservice architecture, MSA)의 서비스들은 HTTP와 같은 기술 불가지론적인 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스들인 경우도 있다. 그러나, 서비스들은 공유 메모리와 같은 다른 종류의 프로세스 간 통신 메커니즘을 사용할 수도 있다. 서비스들은 이를테면 OSGI 번들에서처럼 동일한 프로세스 내에서 실행할 수 있다.
* 마이크로서비스 아키텍처의 서비스들은 독립적인 전개(deploy)가 가능하다.
* 서비스의 교체가 쉽다.
* 서비스는 기능별로 분류된다. (예: 사용자 인터페이스 프론트엔드, 추천, 로지스틱스, 청구서 발부 등)
* 서비스는 최적의 조건에 부합하는 바에 따라 각기 다른 프로그래밍 언어, 데이터베이스, 하드웨어, 소프트웨어 환경을 사용하여 구현할 수 있다.
* 서비스들은 규모가 작고, 메시지 전달이 가능하며 컨텍스트별로 묶이며 자율적으로 개발되며 독립적으로 전개할 수 있으며 분산적이며 빌드가 되며 자동화된 프로세스들로 출시된다.

마이크로서비스 기반 아키텍처는:
* 모듈성이 있는 구조를 자연스럽게 강제한다.
* 자기 자신을 지속적 배포 소프트웨어 개발 프로세스에 위치시킨다. 애플리케이션의 사소한 부분의 변경은 하나 이상의 적은 수의 서비스의 다시 빌드, 재전개만을 필요로 한다.
* 섬세(fine-grained)한 인터페이스(독립적으로 서비스를 전개할 수 있음), 비즈니스 주도의 개발(예: 도메인 드리븐 디자인), 클라우드 애플리케이션 아키텍처, 폴리곳 프로그래밍, 퍼시스턴스, 가벼운 컨테이너 전개, 탈중심화된 지속적 배포, 전체론적인 서비스 모니터링을 갖춘 데브옵스와 같은 원칙들을 고수한다.
* 확장성에 이득이 되는 특징들을 제공한다.

## 역사
2011년 5월 베니스에서 개최된 소프트웨어 아키텍처의 워크숍에서 "마이크로서비스"(microservice)라는 용어를 사용하여 참여자들이 공통의 아키텍처 스타일을 본바, 즉 참여자 중 다수가 최근 탐구했던 바를 기술하였다. 2012년 5월, 동일 그룹은 "마이크로서비스"를 가장 적절한 이름으로 결정하였다. 제임스 루이스는 2012년 3월 33rd Degree in Kraków in Microservices - Java, the Unix Way에서 사례 연구로 이 아이디어 가운데 일부를 발표했는데, 이는 프레드 조지가 거의 같은 시기에 했던 내용과 같다. "섬세한 SOA"(fine grained SOA)으로 이러한 접근을 설명한 넷플릭스의 에이드리언 콕크로프트는 웹 규모로 이 스타일을 개척했는데, 다른 사람들 다수(Joe Walnes, Dan North, Evan Bottcher, Graham Tackley)가 이 문서에서 언급한 바와 같다.

## 철학
마이크로서비스 아키텍처의 철학은 필연적으로 "한 가지 일을 하되 잘하라"(Do one thing and do it well)는 유닉스 철학과 상응한다. 다음과 같이 기술된다:

* 서비스의 크기는 작다 - 하나의 기능을 수행하는데 섬세(fine-grained)하다.
* 조직 문화는 테스트 및 전개의 자동화를 받아들여야 한다. 이를 통해 관리 및 운용상의 부담을 완화하며 다른 개발팀들이 코드의 전개 가능한 단위를 독립적으로 작업할 수 있게 한다.
* 문화와 디자인 철학은 안티프래질 시스템과 비슷하게 실패와 고장을 받아들여야 한다.
* 각 서비스를 유연하고 회복력 있고 구성할 수 있으며 최소한이고 완전하다.

## 기술
컴퓨터 마이크로서비스들은 각기 다른 프로그래밍 언어로 구현할 수 있으며 각기 다른 인프라스트럭처를 사용할 수 있다. 그러므로 가장 중요한 기술적 선택은 마이크로서비스가 서로(동기, 비동기, UI 연동) 통신하고 프로토콜이 통신을 위해 사용되는 방식(REST, 메시징, ...)을 의미한다. 전통적인 시스템에서 프로그래밍 언어와 같은 대부분의 기술적인 선택들은 시스템 전반에 영향을 미친다. 그러므로 기술 선택을 위한 접근법은 상당히 다르다.

## 비평
마이크로서비스의 접근은 수많은 문제의 비평에 종속된다:
* 서비스들은 정보의 장벽을 형성한다
* 네트워크상의 서비스 간 호출은 모놀리식 서비스 프로세스 내의 프로세스 내 호출과 비교해 네트워크 레이턴시, 메시지 처리 면에서 비용이 더 많이 든다
* 테스트와 전개는 더 복잡하다
* 서비스 간에 책무를 이동하는 일은 더 어렵다. 서로 다른 팀 간의 커뮤니케이션을 수반하거나 다른 언어로 기능을 재작성하거나 이를 다른 인프라스트럭처로 맞추는 일이 수반될 수 있다
* 서비스들의 규모를 주된 구조적 메커니즘으로 바라보면 너무 많은 서비스를 생성하는 결과를 낳을 수 있다(내부 모듈화의 대안이 더 단순한 디자인으로 이어질 때).

## 같이 보기
* 횡단 관심사
* 데브옵스
* 마이크로커널
* REST
* 서비스 지향 아키텍처(SOA)
* 유닉스 철학
* 서버리스 컴퓨팅

## 각주

## 추가 문헌
* Microservices – Definition, Principles and Benefits
* S. Newman, Building Microservices – Designing Fine-Grained Systems, O’Reilly, 2015
* E. Wolff, Microservices: Flexible Software Architecture, Addison-Wesley, 2016
* E. Wolff, Microservices Primer: A Short Overview, Leanpub / Createspace, 2016
* E. Wolff, Microservices - A Practical Guide, Leanpub / Createspace, 2018
* E. Wolff, Microservices Recipes - Technology Overview, Leanpub / Createspace, 2017
* I. Nadareishvili et al., Microservices Architecture – Aligning Principles, Practices and Culture, O’Reilly, 2016, http://transform.ca.com/rs/117-QWV-692/images/CA%20Technologies%20-%20OReilly%20Microservice%20Architecture%20eBook.pdf
* C: Richardson, Microservice architecture pattern language http://microservices.io/
* SEI SATURN 2015 microservices workshop, https://github.com/michaelkeeling/SATURN2015-Microservices-Workshop
* Wijesuriya, Viraj Brian (2016-08-29) *[http://www.slideshare.net/tyrantbrian/microservice-architecture-65505794 Microservice Architecture, Lecture Notes, University of Colombo School of Computing, Sri Lanka *]

분류:아키텍처 패턴
분류:서비스 지향