IT 관리 / 가상화ㆍ컨테이너 / 개발자 / 클라우드

서비스 메시의 의미와 서비스 메시 프로젝트들

Josh Fruhlinger | InfoWorld 2019.06.18
IT에서 디지털 트랜스포메이션이라는 깃발 아래에 일어나고 있는 변화 가운데 하나는 대규모의 모놀리식 애플리케이션을 마이크로서비스(microservices)로 쪼개는 일이다. 마이크로서비스는 격리 가능하고 한 서버에서 다른 서버로 손쉽게 이동이 가능한, 모든 서비스 코드와 종속성이 포함된 소프트웨어 패키지인 컨테이너에서 실행되는 작은 개별적 기능 단위다.
 
ⓒ Getty Images

이와 같이 컨테이너화된 아키텍처는 손쉽게 확장이 가능하고 클라우드에서 실행할 수 있으며 개별 마이크로서비스는 신속한 롤아웃과 반복이 가능하다. 그러나 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 이러한 마이크로소프트 간의 통신은 점점 더 복잡해진다. 서비스 메시(service mesh)는 최근 부상하는 아키텍처 형식으로, 관리 및 프로그래밍 오버헤드를 낮추는 방식으로 마이크로서비스를 동적으로 연결하는 데 목표를 둔다.


서비스 메시란 무엇인가

가장 넓은 의미에서 레드 햇(Red Hat)의 설명을 옮기자면 "서비스 메시는 애플리케이션의 여러 부분에서 상호 데이터를 공유하는 방법을 통제하는 수단"이다. 그러나 이 설명은 지나치게 포괄적이기도 하다. 설명만 보면 대부분의 개발자가 클라이어언트-서버 애플리케이션에서 익숙한 미들웨어와 거의 비슷하다.

서비스 메시의 고유한 부분은 분산 마이크로서비스 환경의 특성을 포용한다는 점이다. 마이크로서비스로 빌드된 대규모 애플리케이션에는 특정 서비스의 여러 인스턴스가 다양한 로컬 또는 클라우드 서버에서 실행될 수 있다. 움직이는 부분이 많은 만큼 개별 마이크로서비스가 통신야 하는 상대방 서비스를 찾기도 당연히 더 어렵다. 서비스 메시는 매 순간 서비스를 찾고 연결하는 과정을 자동으로 처리하므로 인간 개발자와 개별 마이크로서비스에서 직접 이 작업을 할 필요가 없다.

서비스 메시는 OSI 네트워킹 모델 7계층을 위한 SDN(Software-Defined Networking)과 같다고 생각하면 된다. 네트워크 관리자가 물리적 네트워크 연결을 직접 다룰 없도록 SDN이 추상화 계층을 만들 듯이, 서비스 메시는 애플리케이션의 기반 인프라를 사용자가 다루는 추상적 아키텍처로부터 분리한다.

서비스 메시의 개념은 개발자들이 방대한 규모의 분산 아키텍처와 관련된 문제와 씨름하기 시작하면서 처음 등장했다. 이 분야의 첫 프로젝트인 링커디(Linkerd)는 트위터 내부 프로젝트에서 파생됐다. 또 다른 인기있는 서비스 메시인 이스티오(Istio)는 리프트(Lyft)에서 처음 탄생했다(이 두 프로젝트에 대해서는 조금 후에 상술할 것이다). 


서비스 메시 부하 분산

서비스 메시가 제공하는 핵심 기능 가운데 하나는 부하 분산(load balancing)이다. 보통 부하 분산을 네트워크 기능이라고 생각하는 경우가 많다. 부하 분산은 어느 한 서버 또는 네트워크 링크에 트래픽이 과도하게 집중되는 것을 방지하기 위해 적절히 패킷 경로를 설정하는 것이다. 서비스 메시는 애플리케이션 수준에서 이와 비슷한 기능을 한다. 이 점을 이해하면 ‘서비스 메시는 애플리케이션 계층을 위한 소프트웨어 정의 네트워킹과 비슷하다’는 말이 무슨 의미인지 감이 잡힐 것이다.

기본적으로 서비스 메시가 하는 일 가운데 하나는 인프라 전역에 분산된 다양한 마이크로서비스 인스턴스를 추적해 어느 인스턴스가 가장 건강한 상태인 지를 파악하는 것이다. 인스턴스를 폴링해서 상태를 확인하거나, 서비스 요청에 느리게 응답하는 인스턴스를 식별해서 후속 요청을 다른 인스턴스로 보낸다. 

서비스 메시는 네트워크 경로에 대해서도 비슷한 작업을 수행할 수 있다. 즉, 메시지가 목적지에 도달하기까지 지나치게 오래 걸리는 경우 이를 인지하고 다른 경로를 사용해 보상한다. 메시지 전달 속도가 저하되는 원인은 기반 하드웨어의 문제일 수도 있고 단순히 과도한 요청으로 서비스에 과부하가 일어나거나 처리 용량의 한계에 이른 경우일 수도 있다. 

중요한 점은 서비스 메시가 동일한 서비스의 다른 인스턴스를 찾아서 이 인스턴스로 트래픽을 라우팅함으로써 전체적인 애플리케이션 용량을 가장 효율적으로 사용할 수 있게 해준다는 것이다.


서비스 메시와 쿠버네티스와의 비교 

컨테이너 기반 아키텍처에 어느 정도 익숙하다면, 인기있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 아키텍처의 어느 부분에 들어가는지 궁금해질 것이다. 결국 쿠버네티스의 목적은 컨테이너가 상호 통신하는 방식을 관리하는 데 있지 않은가. 

커블러(Kublr) 측이 회사 블로그에서 말했듯이, 쿠버네티스의 '서비스' 리소스는 서비스 검색 및 순차 순환 대기(round-robin) 방식의 요청 분산을 제공하므로 서비스 메시의 아주 기초적인 한 종류라고 생각하면 된다. 그러나 완전히 구성된 서비스 메시는 보안 정책 및 암호화 관리, 응답이 느린 인스턴스로의 요청을 중단하기 위한 “회로 차단”, 앞서 설명한 부하 분산 등 훨씬 더 많은 기능을 제공한다.

대부분의 서비스 메시에는 실제로 쿠버네티스와 같은 오케스트레이션 시스템이 필요하다는 점에 유의해야 한다. 서비스 메시는 대체가 아닌 확장된 기능을 제공한다.


서비스 메시와 API 게이트웨이와의 비교 

각 마이크로서비스는 다른 서비스에서 해당 마이크로서비스와 통신하기 위한 수단이 되는 API(Application Programming Interface)를 제공한다. 이 부분에서 서비스 메시와 API 게이트웨이 등의 다른, 더 전통적인 API 관리 형태 사이의 차이점에 대한 의문이 들 수 있다. 

IBM이 설명한 바에 따르면, API 게이트웨이는 마이크로서비스 그룹과 "외부" 세계 사이에 위치하면서 필요에 따라 서비스 요청을 라우팅한다. 요청자는 자신이 마이크로서비스 기반 애플리케이션을 다루고 있다는 사실을 알 필요가 없다. 반면 서비스 메시는 마이크로서비스 앱 "내부"에서 요청을 중재하며, 다양한 구성요소는 자신의 환경을 완전히 인식한다.

또 다른 시각은 저스틴 워렌이 포브스에 게재한 대로, 서비스 메시는 클러스터 내의 동-서 트래픽을 처리하고 API 게이트웨이는 클러스터 안팎을 드나드는 남-북 트래픽을 처리한다는 것이다. 그러나 서비스 메시라는 개념 자체가 아직 초기이며 유동적이다. 많은 서비스 메시(링커디와 이스티오 포함)가 이제 남-북 기능도 제공한다.


서비스 메시 아키텍처

서비스 메시 개념은 지난 2년 사이에 부상한 비교적 새로운 개념이며 “서비스 메시” 문제, 즉 마이크로서비스의 통신 문제를 해결하기 위한 접근 방법은 여러 가지다. 아스펜 메시(Aspen Mesh)의 앤드류 젠킨스는 서비스 메시에 의해 생성되는 통신 계층의 위치에는 다음과 같은 세 가지 선택안이 있다고 말했다.

- 각 마이크로서비스가 가져오는 라이브러리
- 특정 노드의 모든 컨테이너에 서비스를 제공하는 노드 에이전트
- 애플리케이션 컨테이너와 함께 실행되는 사이드카 컨테이너

사이드카 기반 패턴은 가장 보편적인 서비스 메시 패턴으로, 어떤 면에서 서비스 메시라는 말과 동의어처럼 사용되기도 한다. 엄격히 말해 둘이 동일한 개념은 아니지만 사이드카 방식이 워낙 보편적으로 사용되는 만큼 이 아키텍처에 대해 더 자세히 살펴보자.


서비스 메시의 사이드카

사이드카 컨테이너가 애플리케이션 컨테이너와 “나란히 실행”된다는 것은 무슨 의미일까. 레드햇에 따르면, 이 형태의 서비스 메시에서 모든 마이크로서비스 컨테이너에는 각자에 대응하는 다른 프록시 컨테이너가 있다. 서비스 대 서비스 통신에 필요한 모든 논리는 마이크로서비스에서 추출되어 사이드카로 주입된다.

얼핏 복잡해 보일 수 있다. 사실상 애플리케이션의 컨테이너 수를 두 배로 늘리는 것이기 때문이다. 그러나 여기에는 분산된 앱을 간소화하기 위한 핵심인 설계 패턴이 사용된다는 점에도 주목해야 한다. 즉, 모든 네트워킹 및 통신 코드를 별도의 컨테이너에 배치해 인프라의 일부로 만든 덕분에 개발자가 애플리케이션에서 직접 구현할 필요가 없다.

결국 비즈니스 논리에만 온전히 초점을 맞출 수 있는 마이크로서비스가 남게 된다. 마이크로서비스는 복잡다단한 환경의 다른 서비스와 통신하는 방법을 알 필요가 없다. 사이드카와 통신하는 방법만 알면 되고 나머지는 사이드카가 다 알아서 해준다.


서비스 메시 프로젝트, 링커디, 엔보이, 이스티오, 콘설

그렇다면 지금 사용 가능한 서비스 메시는 무엇일까. 구매 후 바로 사용할 수 있는 형태의 상품은 아직 존재하지 않는다. 대부분의 서비스 메시는 다소 손을 봐야 하는 오픈소스 프로젝트다. 주요 프로젝트는 다음과 같다.

- 링커디(linker-d): 2016년에 릴리스된, 가장 오래된 프로젝트다. 링커디는 트위터에서 개발된 라이브러리에서 파생됐다. 이 분야의 또 다른 유력 프로젝트인 콘듀잇(Conduit)이 링커디 프로젝트와 합쳐져 링커디 2.0의 기반이 됐다.

- 엔보이(Envoy): 리프트(Lyft)에서 만들어진 엔보이는 서비스 메시에서 "데이터 평면" 부분을 담당한다. 완전한 서비스 메시를 제공하려면 "제어 평면"과 쌍을 이뤄야 한다.

- 이스티오(Istio): 리프트, IBM, 구글의 협력으로 개발된 이스티오는 엔보이와 같은 서비스 프록시에 대한 제어 평면이다. 이스티오와 엔보이가 기본 쌍이지만 각각 다른 플랫폼과 쌍이 될 수도 있다.

- 해시코프 콘설(HashiCorp Consul): 콘설 1.2에 도입된 커넥트(Connect)라는 기능은 서비스 검색 및 구성을 위한 해시포크의 분산 시스템에 서비스 암호화와 ID 기반 승인을 추가해 완전한 서비스 메시로 만들어준다.

자신에게 맞는 서비스 메시는 무엇일까. 각 서비스 메시의 비교는 이번 주제의 범위를 벗어나지만 한 가지 확실한 것은 앞의 모든 제품은 대규모의 까다로운 환경에서 검증됐다는 점이다. 링커디와 이스티오의 기능이 가장 광범위하지만 모든 제품이 빠른 속도로 발전 중이다. 링커디, 엔보이, 이스티오의 기능에 대한 조지 미란다의 세부적인 설명을 참고할 만하다. 다만 미란다의 문서는 콘듀잇과 링커디가 힘을 합치기 전에 작성된 것임을 감안해야 한다.

또한 새로운 영역인 만큼 언제든 새로운 경쟁자가 나타날 수 있다. 예를 들어 아마존은 2018년 11월부터 AWS 서비스 메시의 공개 프리뷰를 제공하기 시작했다. 아마존 퍼블릭 클라우드를 사용하는 기업의 수를 감안하면 AWS 앱 메시(AWS App Mesh)의 파급력도 상당할 것이다. editor@itworld.co.kr 

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

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

Copyright © 2024 International Data Group. All rights reserved.