2019.10.14

대세로 부상한 소프트웨어 아키텍처 ··· ‘마이크로서비스’ 이해하기

Josh Fruhlinger | InfoWorld
거의 모든 컴퓨터 시스템은 ‘공유되는 자원’을 사용하여 여러 작업을 수행한다. 컴퓨터 프로그래밍의 질문 중 하나는 이러한 작업을 수행하는 코드 비트가 서로 얼마나 엮여야 하는가에 관한 것이다. 그리고 점점 더 인기를 얻고 있는 해답은 마이크로서비스 개념이다. 즉, 전체 시스템을 구성하는데 다른 마이크로서비스들과 상호 작용하는 작고 분리된 기능성 덩어리를 이용하는 개념이다.

이렇듯 분리된 구성요소를 갖는다는 개념이 완전히 새로운 것은 아니지만, 마이크로서비스가 구현되는 방식은 현대적이고 클라우드에 기반한 애플리케이션을 위한 자연스러운 토대를 만든다. 마이크로서비스는 또한 데브옵스 철학과 잘 들어맞는다. 새로운 기능성을 빠르고 지속적으로 출시하도록 장려하는 것이다.
 
ⓒ Image Credit : Getty Images Bank


마이크로서비스란?
마이크로서비스의 ‘마이크로’는 작은 애플리케이션들을 의미한다. 나름 사실에 기반한 설명이기는 하지만 그것들을 이해하는 더 좋은 방법은 그것들이 한 가지 특정한 일을 하거나 특정한 문제를 해결하기 위해 필요한 만큼만 커야 한다는 것이다. 즉 기술적이기보다는 개념적으로 접근하는 것이 바람직하다.

“마이크로서비스는 데이터 액세스나 메시징과 같은 수평적 계층이 아니라 비즈니스 기능을 중심으로 설계되어야 한다”라고 설명된다. 그것들은 비교적 안정적인 API를 통해 다른 마이크로서비스 및 외부 사용자들과 통신하여 더 큰 애플리케이션을 만든다.

따라서, 개별 마이크로서비스의 기능성은 시스템의 나머지 부분에 영향을 미치지 않고 조정되거나 급격하게 업그레이드될 수 있다. 이는 다시 데브옵스 부문들이 어떻게 운영하려고 하는지와 관련이 있다. 더 큰 애플리케이션의 특정 기능이 독립적으로 작동하는 코드의 분리된 조각으로 세분화되면 CI/CD(지속적 통합 및 지속적 전달)의 데브옵스 더욱 쉽게 작동할 수 있다. 또한, 잘 정의된 API는 마이크로서비스들을 자동으로 테스트하기 쉽게 만든다.

마이크로서비스 아키텍처 vs 모놀리틱 아키텍처 
마이크로서비스가 ‘마이크로서비스 아키텍처’의 측면에서 이야기되는 것을 종종 듣게 될 것이다. 이 표현은 마이크로서비스 자체뿐만 아니라 관리 및 서비스 발견 위한 구성요소뿐만 아니라 마이크로서비스와 외부 세계 간의 통신을 처리하는 API 게이트웨이를 망라한다. 

일체형을 의미하는 ‘모놀리틱 애플리케이션’은 마이크로서비스 개념과는 정반대다. 이것은 모든 코드가 하나의 큰 이진법적 실행 파일에 있는 애플리케이션의 일반화된 표현이다. 이러한 일체형 애플리케이션은 확장과 개선이 더 어렵다. 그러나 단일한 응집력 있는 애플리케이션으로 구축되기 때문에 마이크로서비스 아키텍처만큼 많은 관리가 필요하지 않다.

개념의 한계 : 마이크로서비스를 어떻게 정의할 것인가?
마이크로서비스가 한 가지 특정한 일을 해야 한다는 이전의 설명으로 잠시 되돌아가보자. 말하기는 쉽지만, 실제로는 기능성이 서로 얽혀 있는 경우가 많으며, 구분되는 선을 긋는 것은 생각보다 어렵다. 

도메인 분석과 도메인 기반 설계는 큰 그림을 그리는 작업을 마이크로서비스가 해결할 수 있는 개별적인 문제들로 풀어내는 데 도움이 되는 이론적 접근법이다. 당신은 이 프로세스에서 당신의 비즈니스 도메인의 추상적인 모델을 만들게 된다. 그리고 그 과정에서 특정한 방식으로 세상과 상호 작용하는 기능성을 함께 묶는 맥락을 발견하게 된다. 마이크로소프트가 게재한 일련의 블로그 포스트 시리즈에서 이에 대해 참조할 수 있다. 

예를 들어, 당신은 배송에 대해 한 가지 격리된 맥락(bounded context)과 어카운트에 대한 또 다른 격리된 맥락을 가지고 있을 수 있다. 현실세계의 물리적인 물체는 물론 가격과 그것이 도착해야 할 장소를 둘 다 가지고 있을 것이다. 하지만 격리된 맥락은 당신의 애플리케이션이 그러한 물체들에 대해 생각하고 상호 작용하는 특정한 방법을 나타낸다. 일부 격리된 맥락이 둘 이상의 마이크로서비스를 포함할 수 있지만, 각 마이크로서비스는 하나의 격리된 맥락 내에 완전히 존재해야 한다.

마이크로서비스 vs 서비스 지향 아키텍처 vs 웹 서비스
IT 전문가라면 이 중 많은 부분이 친숙하게 들린다고 생각할 수도 있을 것이다. 작고 개별적인 프로그램이 함께 작동한다는 생각은 2000년대 웹 2.0 시절의 2가지 유행어인 SOA(서비스 지향 아키텍처)와 웹 서비스를 떠올리게 할 지도 모른다. 어떤 의미에서 이 세상에는 정말로 새로운 것이 없는 것이 사실이다. 그러나 이러한 개념과 마이크로서비스 사이에는 중요한 차이점이 있다. 

- 서비스 지향 아키텍처에서 개별 구성요소는 상대적으로 단단하게 결합되어 스토리지와 같은 자산을 공유하는 경우가 많으며, 엔터프라이즈 스토리지 버스라고 하는 전문 소프트웨어를 통해 통신한다. 마이크로서비스는 더 독립적이며, 더 적은 자원을 공유하고, 더 가벼운 프로토콜을 통해 통신한다. 마이크로 서비스는 SOA 환경에서 생겨났으며, 때때로 SOA의 일종, 또는 개념의 계승자로 간주된다는 점에 주목할 가치가 있다.

- 웹 서비스는 공개적으로 직면하는 기능성의 집합으로, 다른 애플리케이션들이 웹을 통해 접속할 수 있는 기능성이다. 아마도 가장 일반적인 예는 구글맵일 것이다. 구글맵은 레스토랑의 웹사이트가 고객들에게 찾아오는 길을 알려주기 위해 탑재시킬 수 있다. 이것은 마이크로서비스 아키텍처에서 볼 수 있는 것보다 훨씬 더 느슨한 연결이다.




2019.10.14

대세로 부상한 소프트웨어 아키텍처 ··· ‘마이크로서비스’ 이해하기

Josh Fruhlinger | InfoWorld
거의 모든 컴퓨터 시스템은 ‘공유되는 자원’을 사용하여 여러 작업을 수행한다. 컴퓨터 프로그래밍의 질문 중 하나는 이러한 작업을 수행하는 코드 비트가 서로 얼마나 엮여야 하는가에 관한 것이다. 그리고 점점 더 인기를 얻고 있는 해답은 마이크로서비스 개념이다. 즉, 전체 시스템을 구성하는데 다른 마이크로서비스들과 상호 작용하는 작고 분리된 기능성 덩어리를 이용하는 개념이다.

이렇듯 분리된 구성요소를 갖는다는 개념이 완전히 새로운 것은 아니지만, 마이크로서비스가 구현되는 방식은 현대적이고 클라우드에 기반한 애플리케이션을 위한 자연스러운 토대를 만든다. 마이크로서비스는 또한 데브옵스 철학과 잘 들어맞는다. 새로운 기능성을 빠르고 지속적으로 출시하도록 장려하는 것이다.
 
ⓒ Image Credit : Getty Images Bank


마이크로서비스란?
마이크로서비스의 ‘마이크로’는 작은 애플리케이션들을 의미한다. 나름 사실에 기반한 설명이기는 하지만 그것들을 이해하는 더 좋은 방법은 그것들이 한 가지 특정한 일을 하거나 특정한 문제를 해결하기 위해 필요한 만큼만 커야 한다는 것이다. 즉 기술적이기보다는 개념적으로 접근하는 것이 바람직하다.

“마이크로서비스는 데이터 액세스나 메시징과 같은 수평적 계층이 아니라 비즈니스 기능을 중심으로 설계되어야 한다”라고 설명된다. 그것들은 비교적 안정적인 API를 통해 다른 마이크로서비스 및 외부 사용자들과 통신하여 더 큰 애플리케이션을 만든다.

따라서, 개별 마이크로서비스의 기능성은 시스템의 나머지 부분에 영향을 미치지 않고 조정되거나 급격하게 업그레이드될 수 있다. 이는 다시 데브옵스 부문들이 어떻게 운영하려고 하는지와 관련이 있다. 더 큰 애플리케이션의 특정 기능이 독립적으로 작동하는 코드의 분리된 조각으로 세분화되면 CI/CD(지속적 통합 및 지속적 전달)의 데브옵스 더욱 쉽게 작동할 수 있다. 또한, 잘 정의된 API는 마이크로서비스들을 자동으로 테스트하기 쉽게 만든다.

마이크로서비스 아키텍처 vs 모놀리틱 아키텍처 
마이크로서비스가 ‘마이크로서비스 아키텍처’의 측면에서 이야기되는 것을 종종 듣게 될 것이다. 이 표현은 마이크로서비스 자체뿐만 아니라 관리 및 서비스 발견 위한 구성요소뿐만 아니라 마이크로서비스와 외부 세계 간의 통신을 처리하는 API 게이트웨이를 망라한다. 

일체형을 의미하는 ‘모놀리틱 애플리케이션’은 마이크로서비스 개념과는 정반대다. 이것은 모든 코드가 하나의 큰 이진법적 실행 파일에 있는 애플리케이션의 일반화된 표현이다. 이러한 일체형 애플리케이션은 확장과 개선이 더 어렵다. 그러나 단일한 응집력 있는 애플리케이션으로 구축되기 때문에 마이크로서비스 아키텍처만큼 많은 관리가 필요하지 않다.

개념의 한계 : 마이크로서비스를 어떻게 정의할 것인가?
마이크로서비스가 한 가지 특정한 일을 해야 한다는 이전의 설명으로 잠시 되돌아가보자. 말하기는 쉽지만, 실제로는 기능성이 서로 얽혀 있는 경우가 많으며, 구분되는 선을 긋는 것은 생각보다 어렵다. 

도메인 분석과 도메인 기반 설계는 큰 그림을 그리는 작업을 마이크로서비스가 해결할 수 있는 개별적인 문제들로 풀어내는 데 도움이 되는 이론적 접근법이다. 당신은 이 프로세스에서 당신의 비즈니스 도메인의 추상적인 모델을 만들게 된다. 그리고 그 과정에서 특정한 방식으로 세상과 상호 작용하는 기능성을 함께 묶는 맥락을 발견하게 된다. 마이크로소프트가 게재한 일련의 블로그 포스트 시리즈에서 이에 대해 참조할 수 있다. 

예를 들어, 당신은 배송에 대해 한 가지 격리된 맥락(bounded context)과 어카운트에 대한 또 다른 격리된 맥락을 가지고 있을 수 있다. 현실세계의 물리적인 물체는 물론 가격과 그것이 도착해야 할 장소를 둘 다 가지고 있을 것이다. 하지만 격리된 맥락은 당신의 애플리케이션이 그러한 물체들에 대해 생각하고 상호 작용하는 특정한 방법을 나타낸다. 일부 격리된 맥락이 둘 이상의 마이크로서비스를 포함할 수 있지만, 각 마이크로서비스는 하나의 격리된 맥락 내에 완전히 존재해야 한다.

마이크로서비스 vs 서비스 지향 아키텍처 vs 웹 서비스
IT 전문가라면 이 중 많은 부분이 친숙하게 들린다고 생각할 수도 있을 것이다. 작고 개별적인 프로그램이 함께 작동한다는 생각은 2000년대 웹 2.0 시절의 2가지 유행어인 SOA(서비스 지향 아키텍처)와 웹 서비스를 떠올리게 할 지도 모른다. 어떤 의미에서 이 세상에는 정말로 새로운 것이 없는 것이 사실이다. 그러나 이러한 개념과 마이크로서비스 사이에는 중요한 차이점이 있다. 

- 서비스 지향 아키텍처에서 개별 구성요소는 상대적으로 단단하게 결합되어 스토리지와 같은 자산을 공유하는 경우가 많으며, 엔터프라이즈 스토리지 버스라고 하는 전문 소프트웨어를 통해 통신한다. 마이크로서비스는 더 독립적이며, 더 적은 자원을 공유하고, 더 가벼운 프로토콜을 통해 통신한다. 마이크로 서비스는 SOA 환경에서 생겨났으며, 때때로 SOA의 일종, 또는 개념의 계승자로 간주된다는 점에 주목할 가치가 있다.

- 웹 서비스는 공개적으로 직면하는 기능성의 집합으로, 다른 애플리케이션들이 웹을 통해 접속할 수 있는 기능성이다. 아마도 가장 일반적인 예는 구글맵일 것이다. 구글맵은 레스토랑의 웹사이트가 고객들에게 찾아오는 길을 알려주기 위해 탑재시킬 수 있다. 이것은 마이크로서비스 아키텍처에서 볼 수 있는 것보다 훨씬 더 느슨한 연결이다.


X