마이크로서비스를 위한 서비스 메시 기술 ‘이스티오’가 뜨는 이유

2018년 05월 26일        

 ⓒ ITWorld, Diogenes Rettori | InfoWorld

작년 이스티오(Istio) 서비스 메시 기술에 대한 관심과 움직임은 확실히 흥미로웠다. 사실 이스티오의 버전은 아직 0.8인데, KubeCon/CloudNativeCon 이벤트에서 계속 뜨거운 화두가 됐다. 이유가 무엇일까?

이스티오의 인기 이유를 살펴보기 전에 서비스 메시부터 소개해 보자. 다소 포괄적인 용어인 서비스 메시는 예를 들어 다양한 무선 디바이스 간 통신 방법을 정의하거나 개별 애플리케이션이 다른 애플리케이션과 직접 통신할 수 있는 시스템을 나타내는 등 여러 가지 맥락에서 사용된다. 최근에는 애플리케이션 또는 마이크로서비스 네트워크, 그리고 이러한 요소 간의 관계와 상호 작용을 나타내는 데 사용되고 있다. 여기서는 후자에 초점을 맞춘다.

레드햇이 클라우드 네이티브와 마이크로서비스 영역에 참여해왔다는 사실, 특히 레드햇 오픈시프트(OpenShift)가 약 4년 전에 쿠버네티스와 도커에서 택한 방향을 보면 서비스 메시 기술, 특히 이스티오의 중요성을 이해하는 데 도움이 된다. 필자가 생각하는 이스티오가 인기를 끄는 네 가지 이유는 다음과 같다.

마이크로서비스와 트랜스포메이션

코드를 작성한 시점과 이 코드가 프로덕션에 배포되는 시점 사이의 간격이 너무 길어 개발자는 이미 다른 프로젝트로 이동했고 피드백 루프는 비생산적이거나 관련성이 없는 상황은 이 분야에서 흔히 겪게 되는 일이다. 지금 그런 상황에 처해 있는 사람도 있을 것이다. 이 ‘리드 시간’을 단축하기 위해 일부 기업은 몸집이 큰 애플리케이션을 함수 또는 마이크로서비스와 같은 작은 조각으로 나눠 효율성을 개선하는 방법을 택한다. 많은 기능을 가진 하나의 애플리케이션(패키지)이 각각 독립적으로 업데이트가 가능한 개별 패키지로 분할된다.

물론 이런 방식도 가치가 있지만, 이러한 시나리오는 개별 서비스와 그 사이의 인터페이스에 대한 더 많은 관리 필요성을 수반한다는 점도 감안해야 한다. 예를 들어 애플리케이션 내의 API 호출의 일부로 정의됐던 관계가 이제 네트워크를 따라 이동해야 한다.

크리스티나 포스타의 프레젠테이션 “마이크로서비스의 가장 어려운 부분 : 서비스 호출”은 중요한 점을 지적한다. API를 호출할 때 개발자는 A-B 직접 통합(아래 그림 1)을 다룬다고 생각할 수 있다. 그러나 컴퓨터 네트워크는 직접 통신에 최적화되도록 설계되지 않았으며(그림 2), 특히 클라우드 환경을 고려 또는 사용 중인 경우 통제 범위를 벗어난 많은 실제 및 가상 네트워크 디바이스를 필연적으로 다루게 된다. 예를 들어 이런 디바이스 중 하나의 성능이 저하되는 경우 전체 애플리케이션 응답 시간이 영향을 받는다(그림 3).

마이크로서비스 개척자와 넷플릭스 OSS

클라우드에 적극적인 일부 기업은 클라우드에서 탄력적인 서비스를 제공하기 위해서는 애플리케이션이 환경의 이상 현상으로부터 스스로를 보호해야 한다는 사실을 일찌감치 파악했다.

넷플릭스는 회로 차단, 에지 라우팅, 서비스 검색, 로드밸런싱 등의 기능을 위해 자바를 주축으로 하는 일련의 기술을 만들어 이후 오픈소스화했다. 이러한 기능은 애플리케이션에 더 많은 통신 제어 기능을 부여하고, 이는 다시 전체적인 가용성을 높이는 역할을 한다. 넷플릭스는 애플리케이션의 탄력성을 테스트하고 확인하기 위해 카오스 엔지니어링도 사용한다. 다양한 실제 문제를 네트워크 애플리케이션에 주입하고 아무 시점에나 워크플로우를 방해해 보는 것이다. 넷플릭스는 여러 기술을 개발해 그 조합으로 애플리케이션을 애플리케이션 중심의 네트워크에 넣었으며 이것이 곧 서비스 메시다.

넷플릭스 OSS 스택이 만들어진 당시에는 가상머신이 클라우드에서 애플리케이션 실행하기 위해 사실상 유일한 방법이었다. 따라서 넷플릭스는 서비스 메시 기능을 위한 언어 플랫폼으로 자바를 선택했다.

자바에 치중된 측면 외에 넷플릭스 OSS 스택의 또 다른 과제는 서비스 메시 기능을 위해서는 개발자가 애플리케이션에 자바 라이브러리를 포함하고 코드에 관련 구성 요소를 사용하는 프로비저닝을 추가해야 한다는 점이었다. 당시 이러한 기술 사용을 강제하고자 한 기업들은 플랫폼 수준에서는 그렇게 할 수 없었다.

쿠버네티스가 등장하면서 서비스 검색, 로드밸런싱과 같은 기능이 플랫폼의 일부가 되어 사용된 언어에 관계없이 모든 애플리케이션에서 활용할 수 있게 됐다. 쿠버네티스는 선언과 능동적 상태 관리를 통해 응답하지 않는 애플리케이션을 자동으로 재시작함으로써 전체적인 애플리케이션 가용성도 높일 수 있었다. 오늘날의 환경에서 쿠버네티스와 컨테이너는 마이크로서비스 애플리케이션을 실행하는 데 있어 사실상의 표준이다.

쿠버네티스에서 애플리케이션은 하나 이상의 컨테이너로 구성되는 “팟(pod)”에서 실행된다. 여러 컨테이너를 하나의 팟에서 실행하기 위한 방법 중 하나인 “사이드 카(side-car)”는 기본적으로 주 애플리케이션과 동일한 격리된 공간(팟)에서 실행되는 또 다른 소프트웨어 조각이다.

쿠버네티스는 이스티오와 같은 기술의 부상에 유리한 조건을 형성했다. 차량 공유 업체인 리프트(Lyft)는 마이크로서비스 배치에서 원했던 탄력성과 동적 라우팅 기능을 제공하기 위해 이미 엔보이(Envoy)라는 지능형 프록시를 개발 중이다. 사이드 카 컨테이너와 엔보이를 통해 기업은 모든 애플리케이션 인스턴스에 가벼운 프록시를 연결해서 서비스 검색, 로드밸런싱, 회로 차단, 추적을 비롯한 서비스 메시의 다양한 기능을 지원할 수 있다. 여기에 엔보이 인스턴스의 구성 및 관리에 거버넌스를 더하는 제어 플레인과 결합한 결과가 바로 이스티오다.

분산 아키텍처 수용
결국 이스티오와 서비스 메시의 핵심은 분산 컴퓨팅의 잘못된 생각을 “포용”하는 것이다. 달리 말하면 이스티오를 통해 애플리케이션은 네트워크의 안정성, 속도, 보안, 불변성, 분산 컴퓨팅의 잘못된 생각이 완전히 잘못된 것은 아님을 전제할 수 있다. 이스티오와 쿠버네티스가 이러한 문제를 모두 해결한다고 말하기는 어렵지만 이와 같은 잘못된 생각을 무시하는 것은 기업이 저지를 수 있는 가장 큰 실수 중 하나다. 기업은 여러 개의 마이크로서비스와 함수가 상호작용하는 환경을 사용 중이라면 그것이 곧 분산 시스템이라는 사실을 받아들여야 한다.

분선 컴퓨팅의 틀린 생각과 그에 대한 이스티오의 대응 목록은 다음과 같다.
 

필자는 오픈시프트 고객과 대화하면서 이들이 넷플릭스가 개발한 것과 동일한 패턴을 자체적으로 구현했음을 발견하는 경우가 많다. 그러한 기능의 필요성을 이해했기 때문이다. 또한 전체 팀이 이러한 기능에 집중한다는 점도 흥미롭다. “우리는 회로 차단 팀” 또는 “우리는 서비스 검색 팀”이라는 말을 자주 듣는다.

자체 서비스 메시 기능을 만드는 데 투자한 기업은 현재 쿠버네티스와 이스티오를 사용할 기회를 확보했다. 이러한 오픈소스 기술을 기반으로 표준화하면 더 큰 커뮤니티에 의해 생성된 기능, 지식, 사용 사례에 액세스하고 더 탄력적인 애플리케이션을 만들고 훨씬 더 낮은 비용으로 상품화 시간을 더 앞당기기 위한 여정을 촉진할 수 있다. 

※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지

[원문출처 : http://www.itworld.co.kr/insight/109449]