마이크로서비스 아키텍처 (Microservices Architecture) 이란?

마이크로서비스 아키텍처 또는 단순히 마이크로서비스 (Microservices)는 최근 몇년간 인기를 얻은 소프트웨어 시스템을 개발하는 독특한 방법입니다. 사실, 그것이 무엇인지, 어떻게 해야 하는지에 대해서는별로 많지 않지만, 많은 개발자들은 엔터프라이즈 애플리케이션을 만드는데 선호되는 방법이 되었습니다. 확장성 덕분에 이 아키텍처 방법은 웹, 모바일,사물인터넷 및 웨어러블 등 다양한 플랫폼 및 장치에 대한 지원을 가능하게 할때 또는 지원할 필요가 있는 장치의 종류가 미래에 아주 많이 증가할때 특히 이상적인 것으로 생각됩니다.

마이크로서비스에 대한 표준적이고 공식적인 정의는 없지만 스타일을 식별하는데 도움이 되는 특성이 있습니다. 근본적으로 마이크로서비스 아키텍처는 소프트웨어 응용프로그램을 독립적으로 배포할 수있는 소형 모듈 서비스로 개발하는 방법으로, 각 서비스는 고유한 프로세스를 실행하고 잘 정의되고 가벼운 메커니즘을 통해 통신하여 비즈니스 목표를 달성할 수 해줍니다.

서비스가 서로 통신하는 방법은 애플리케이션의 요구 사항에 따라 다르지만 많은 개발자는JSON 또는 Protobuf에서 HTTP/REST를 사용합니다. DevOps 전문가는 물론 적합한 것으로 판단되는 통신 프로토콜을 자유롭게 선택할 수 있지만 대부분의 경우 REST (Representational State Transfer)는 다른 프로토콜에 비해 상대적으로 복잡성이 적기 때문에 유용한 통합 방법입니다.

마이크로서비스 아키텍처를 이해하기 위해서는 모놀리식 아키텍처 스타일 (Monolithic Architectural Style)과 반대 개념을 고려해야 합니다. 마이크로서비스와 달리 모노리지 응용프로그램 (Monolith Application)은 항상 단일 자치 단위로 구축됩니다. 클라이언트-서버 모델에서 서버측 응용프로그램은 HTTP 요청을 처리하고 논리를 실행하며 기본 데이터베이스의 데이터를 검색/업데이트하는 단일 구조입니다. 모놀리식 아키텍처 (Monolithic Architecture)의 문제점은 모든 변경 주기가 일반적으로 서로 연결된다는 것입니다. 응용프로그램의 작은 섹션을 수정하면 완전히 새로운 버전을 빌드하고 배포해야 할 수 있습니다.응용프로그램의 특정 기능을 확장해야 하는 경우 원하는 구성 요소가 아닌 전체 응용프로그램의 크기를 조정해야 할 수 있습니다. 이것은 마이크로서비스가 존재하는 이유입니다.

SOA 대 마이크로서비스

서비스 지향 아키텍처 (SOA : Service-Oriented Architecture)는 금세기 초반에 생겨났는데 마이크로서비스 아키텍처 (일부는 MSA로 약칭 )에는 여러 가지 유사점이 있습니다. 그러나 전통적인 SOA는 보다 폭 넓은 프레임워크이며 다양한 것을 의미할 수 있습니다. 다른 사람들은 마이크로서비스는 SOA의 이상적이고 세련된 형태라고 생각하는 반면, 마이크로서비스 옹호론자들은 SOA 태그를 모두 부인합니다. 어쨌든 차별화된 "마이크로 서비스"개념을 정당화하기에 충분한 차이가 분명하다고 생각합니다 (적어도 특수한 형태의 SOA).

예를 들어, 전형적인 SOA 모델은 대개 빠른 메시징 메커니즘 (Messaging Mechanism)을 사용하는 마이크로서비스를 통해 보다 종속적인 ESB를 보유합니다. 또한 SOA는 명령형 프로그래밍 (Imperative Programming)에 중점을 두는 반면 마이크로서비스 아키텍처는 반응형 액터 프로그래밍 스타일 (Responsive-actor Programming Style)에 중점을 둡니다. 또한 SOA 모델은 크기가 큰 관계형 데이터베이스를 사용하는 경향이 있지만 마이크로서비스는 NoSQL 또는 마이크로 SQL 데이터베이스 (기존 데이터베이스에 연결할 수 있음)를 자주 사용합니다. 그러나 진정한 차이점은 통합 된 서비스 세트를 처음에 얻는데 사용된 아키텍처 방법과 관련이 있다는 것입니다.

디지털 세계에서 모든 것이 변하기 때문에 소프트웨어 진화의 요구를 따라 잡을 수 있는 민첩한 개발 기술은 매우 중요합니다. 마이크로서비스 아키텍처에서 사용되는 대부분의 사례는 대기업 조직을 위한 소프트웨어 응용프로그램을 만든 개발자로부터 왔으며 오늘날 최종 사용자가 다양한 장치에서 동적이지만 일관된 경험을 기대한다는 것을 알고 있습니다. 확장성, 적응력, 모듈성 및 신속하게 액세스할 수 있는 클라우드 기반 응용 프로그램이 절실히 요구됩니다. 그리고 이로 인해 많은 개발자들이 접근 방식을 변경하게 되었습니다.

마이크로서비스의 예

Martin Fowler가 지적한 것처럼 Netflix, eBay, Amazon, 영국 정부 디지털 서비스, realestate.com.au, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian 및 많은 다른 대규모 웹사이트 및 응용프로그램은 모두 모놀리식에서 마이크로서비스 아키텍처로 발전했습니다.

Netflix는 단일 아키텍처에서 SOA로 발전한 광범위한 아키텍처를 가지고 있습니다. 800가지 이상의 다른 유형의 장치에서부터 스트리밍 비디오 API에 이르기까지 매일 10억건 이상의 전화를 수신합니다. 각 API 호출은 백엔드 서비스에 대한 다섯개의 추가 호출을 요구합니다.

Amazon은 또한 마이크로서비스로 마이그레이션했습니다. 웹서비스 API를 관리하는 응용프로그램과 웹사이트 자체를 포함하여 다양한 응용프로그램에서 수많은 호출이 발생합니다.이 응용프로그램은 오래된 2계층 아키텍처에서 처리하기가 불가능했을 것입니다.

경매장 eBay는 동일한 전환 과정을 거친 또 다른 예입니다. 이들의 핵심 애플리케이션은 여러 기능 영역에 대한 비즈니스 로직을 실행하는 여러 개의 자율 애플리케이션(Autonomous Application)으로 구성됩니다.