가상화ㆍ컨테이너

"클라우드 기반 애플리케이션의 미래" 마이크로서비스란 무엇인가?

Josh Fruhlinger  | InfoWorld 2024.01.31
대다수의 컴퓨터는 공유 리소스를 사용해서 여러 작업을 수행한다. 이러한 작업을 수행하는 코드 조각을 얼마나 긴밀하게, 또는 느슨하게 결합해야 하는지는 컴퓨터 프로그래밍의 오랜 질문 중 하나다. 이 질문에 대한 한 가지 답이 바로 마이크로서비스 아키텍처다. 개별적인 기능 뭉치로 구성되고 각 뭉치가 다른 개별 뭉치와 상호작용해서 더 큰 시스템을 형성한다. 여기서 각각의 뭉치가 마이크로서비스다.
 
연결된 구성요소 개념이 새로운 것은 아니지만 마이크로서비스는 클라우드 기반 애플리케이션에 잘 맞는 기반으로 인기를 얻었다. 또한 마이크로서비스 아키텍처는 새로운 기능을 빠르게, 지속적으로 배포하는 방식을 권장하는 데브옵스 원칙과도 잘 맞는다.
 
ⓒ Getty Images Bank
 
이 기사에서는 마이크로서비스 아키텍처로 마이그레이션할 때의 장단점을 포함해 마이크로서비스에 대해 소개한다.
 

마이크로서비스란?

마이크로서비스에서 "마이크로"는 작은 애플리케이션을 뜻한다. 그 말이 맞을 때도 있지만 더 정확한 이해는 특정한 한 가지 작업을 수행하거나 특정 문제를 해결하는 데 꼭 필요한 만큼의 크기라는 것이다. 여기서 문제는 기술적인 것이 아닌 개념적인 문제여야 한다. 마이크로소프트 애저 문서에 다음과 같이 대해 잘 설명돼 있다. "마이크로서비스는 데이터 액세스 또는 메시징과 같은 수평적 계층이 아니라 비즈니스 기능을 중심으로 설계되어야 한다."
 
마이크로서비스는 비교적 안정적인 API를 통해 다른 마이크로서비스 및 외부 사용자와 통신하여 더 큰 애플리케이션을 형성한다. 따라서 시스템의 나머지 부분에 영향을 미치지 않으면서 개별 마이크로서비스의 내부 기능을 조정하거나 전면적으로 업그레이드할 수 있다. 더 큰 애플리케이션의 특정 기능을 독립적으로 작동하는 개별 코드 조각으로 분할하면 데브옵스의 핵심인 CI/CD(지속적 통합 및 지속적 제공) 파이프라인을 더 쉽게 만들 수 있다. 또한 잘 정의된 API가 있으면 마이크로서비스를 자동으로 테스트하기도 더 쉬워진다.
 

마이크로서비스 아키텍처란?

마이크로서비스에 대한 이야기는 마이크로서비스 아키텍처 측면에서 하는 경우가 많다. 마이크로서비스 아키텍처라는 용어는 마이크로서비스 자체뿐만 아니라 이를 지원하기 위한 다음과 같은 인프라까지 포괄한다.
 
  • 서비스 관리 및 검색, 페일오버와 회복탄력성을 위한 자동화된 구성요소(이 용도로 가장 많이 사용되는 몇 가지 플랫폼에 대해서는 잠시 후에 설명)
  • 서비스 간 통신을 라우팅하기 위한 간단한 방법
  • 마이크로서비스와 외부 세계 간의 통신을 처리하는 API 게이트웨이

전체적인 목표는 장애 내성이 강하면서 전면적인 개조 없이 발전을 통해 변화하는 요구사항을 충족할 수 있는 아키텍처다.

마이크로서비스 vs. 모놀리식 아키텍처

마이크로서비스가 나오기 전에는 모놀리식이라는 한 가지 스타일의 아키텍처밖에 없었다. 모놀리식 아키텍처는 모든 코드가 하나의 큰 바이너리 실행 파일에 들어 있는 애플리케이션을 일컫는 일반화된 표현이다.
 
모놀리식 아키텍처가 잘 맞는 부분도 있다. 모놀리식 애플리케이션은 일반적으로 마이크로서비스에 비해 확장과 개선이 어렵지만 관리가 그다지 많이 필요하지 않다. 또한 데이터 저장 측면에서도 모놀리식 애플리케이션이 더 간단하다. 마이크로서비스 아키텍처의 개별 구성요소는 보통 자체 데이터를 직접 유지하므로 각 마이크로서비스마다 자체 데이터베이스가 있다. 모놀리식 애플리케이션은 모든 데이터 작업에 하나의 데이터베이스만 사용한다.
 

'마이크로서비스'의 의미는 무엇인가?

앞에서 이야기한, 마이크로서비스는 한 가지 특정 작업을 수행해야 한다는 말을 잠깐 되짚어 보자. 말로는 쉽지만 기능적인 구분은 생각보다 어렵다. 도메인 분석과 도메인 중심 설계는 큰 작업을 마이크로서비스가 해결할 수 있는 개별 문제로 쪼개는 데 도움이 되는 이론적 접근 방식이다. 이 프로세스에 대해서는 마이크로소프트 블로그에 연재된 글에서 자세히 알아볼 수 있다. 첫 번째 단계는 비즈니스 도메인의 추상 모델을 만드는 것이다. 이 모델을 사용해서 기능을 그룹화하는 경계 컨텍스트(bounded context)를 찾을 수 있다.
 
배송 애플리케이션을 예로 들어 보자. 실제의 물리적 사물에는 가격과 목적지가 있으므로 계정을 위한 경계 컨텍스트와 배송을 위한 경계 컨텍스트가 있을 것이다. 만드는 각 마이크로서비스는 전적으로 하나의 경계 컨텍스트 내에 존재해야 하지만 둘 이상의 마이크로서비스에 걸쳐 존재하는 경계 컨텍스트도 있다.
 

마이크로서비스 vs. SOA 및 웹 서비스

이 분야의 경력이 어느정도 긴 사람이라면 작은 여러 프로그램이 함께 작동한다는 개념을 듣고 아마 SOA(서비스 지향 아키텍처)와 웹 서비스를 떠올렸을 것이다. 이 둘은 2000년대 초반 웹 2.0이 득세했던 시절에 유행했던 용어다. 어차피 이 세계에서 완전히 새로운 것은 없다고 하지만, 세 가지 접근 방식에는 다음과 같은 중요한 차이점이 있다.
 
  • SOA 대 마이크로서비스 : 서비스 지향 아키텍처에서 개별 구성요소는 비교적 긴밀하게 결합되며 많은 경우 스토리지와 같은 자산을 공유하고 엔터프라이즈 스토리지 버스라는 특수한 소프트웨어를 통해 통신한다. 이에 비해 마이크로서비스는 더 독립적이고 공유하는 리소스도 더 적으며 더 가벼운 프로토콜을 통해 통신한다. 마이크로서비스는 SOA의 한 종류 또는 SOA의 후속 개념으로 통하기도 한다.
  • 웹 서비스 대 마이크로서비스 : 웹 서비스는 다른 애플리케이션이 웹을 통해 액세스할 수 있는 공개 기능 모음으로, 가장 대표적인 예가 구글 맵이다. 여러 업체가 고객에게 길안내를 제공하기 위해 자체 웹사이트에 구글 맵을 집어넣는다. 마이크로서비스와 달리 웹 서비스는 다른 서비스와 꼭 연결될 필요는 없다. 마이크로서비스 아키텍처에 비해 더 느슨하게 연결된다.
 

마이크로서비스의 통신 방법

마이크로서비스 아키텍처에 대해 자주 듣는 이야기는 똑똑한 엔드포인트와 멍청한 파이프로 구성되어야 한다는 것이다. 다르게 말하면, 마이크로서비스는 매우 단순하고 잘 정립된 통신 방법을 사용하는 것을 목표로 해야 한다.
 
일반적으로 마이크로서비스 간의 통신은 코드 스레드가 응답을 기다리는 동안 차단되지 않는다는 의미에서 비동기적이어야 한다(HTTP와 같은 동기 통신 프로토콜을 사용해도 되지만 AMQP(Advanced Message Queuing Protocol)와 같은 비동기 프로토콜 역시 흔히 사용됨). 마이크로서비스 아키텍처는 이와 같은 느슨한 결합 덕분에 네트워크의 개별 구성요소 또는 일부분에 장애가 발생하는 경우 더 유연하게 대처할 수 있다.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.