서비스 메시 란 무엇입니까? 더 쉬운 컨테이너 네트워킹

디지털 변환의 기치 아래 IT에서 발생하는 변화 중 하나는이 microservices에 큰 모 놀리 식 애플리케이션의 분해이다 - 용기의 기능 - 실행되는 작은, 개별 단위 - 서비스의 코드와 종속 그 캔을 모두 포함하는 소프트웨어 패키지 격리되고 한 서버에서 다른 서버로 쉽게 이동할 수 있습니다.

이와 같은 컨테이너화 된 아키텍처는 쉽게 확장하고 클라우드에서 실행할 수 있으며 개별 마이크로 서비스를 빠르게 롤아웃하고 반복 할 수 있습니다. 그러나 이러한 마이크로 서비스 간의 통신은 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행됨에 따라 점점 더 복잡해집니다. 서비스 메시는 관리 및 프로그래밍 오버 헤드를 줄이는 방식으로 이러한 마이크로 서비스를 동적으로 연결하는 것을 목표로하는 새로운 아키텍처 형태입니다.

서비스 메시 란 무엇입니까?

가장 넓은 의미에서 서비스 메시는 Red Hat이 설명하는 것처럼 "애플리케이션의 여러 부분이 서로 데이터를 공유하는 방식을 제어하는 ​​방법"입니다. 하지만이 설명은 여러 가지를 포함 할 수 있습니다. 사실 대부분의 개발자가 클라이언트-서버 응용 프로그램에서 익숙한 미들웨어처럼 들립니다.

서비스 메시를 고유하게 만드는 것은 분산 마이크로 서비스 환경의 고유 한 특성을 수용하도록 구축되었다는 것입니다. 마이크로 서비스로 구축 된 대규모 애플리케이션에는 다양한 로컬 또는 클라우드 서버에서 실행되는 특정 서비스의 여러 인스턴스가있을 수 있습니다. 이러한 모든 움직이는 부분은 분명히 개별 마이크로 서비스가 통신해야하는 다른 서비스를 찾기 어렵게 만듭니다. 서비스 메시는 인간 개발자와 개별 마이크로 서비스가 필요하지 않도록 순간적으로 서비스를 검색하고 연결하는 작업을 자동으로 처리합니다.

서비스 메시를 OSI 네트워킹 모델의 레벨 7에 대한 소프트웨어 정의 네트워킹 (SDN)과 동등하다고 생각하십시오. SDN이 추상화 계층을 생성하여 네트워크 관리자가 물리적 네트워크 연결을 처리 할 필요가없는 것처럼 서비스 메시는 상호 작용하는 추상 아키텍처에서 애플리케이션의 기본 인프라를 분리합니다.

서비스 메시에 대한 아이디어는 개발자가 진정으로 방대한 분산 아키텍처의 문제를 해결하기 시작하면서 유기적으로 발생했습니다. 이 분야의 첫 번째 프로젝트 인 Linkerd는 트위터 내부 프로젝트의 파생물로 탄생했습니다. 주요 기업 지원을받는 또 다른 인기있는 서비스 메시 인 Istio는 Lyft에서 시작되었습니다. (이 두 프로젝트에 대해서는 잠시 후에 자세히 살펴 보겠습니다.)

서비스 메시 부하 분산

서비스 메시가 제공하는 주요 기능 중 하나는로드 균형 조정 입니다. 일반적으로로드 밸런싱을 네트워크 기능으로 생각합니다. 하나의 서버 또는 네트워크 링크가 트래픽으로 압도되는 것을 방지하여 그에 따라 패킷을 라우팅합니다. 서비스 메시는 Twain Taylor가 설명하는 것처럼 애플리케이션 수준에서 유사한 작업을 수행하며 서비스 메시가 애플리케이션 계층에 대한 소프트웨어 정의 네트워킹과 비슷하다고 말할 때 의미하는 바를 잘 이해할 수 있습니다.

본질적으로 서비스 메시의 작업 중 하나는 인프라에 분산 된 다양한 마이크로 서비스의 어떤 인스턴스가 "가장 정상"인지 추적하는 것입니다. 어떤 인스턴스가 서비스 요청에 느리게 응답하는지 추적하고 후속 요청을 다른 인스턴스로 보내기 위해 폴링 할 수 있습니다. 서비스 메시는 네트워크 경로에 대해 유사한 작업을 수행하여 메시지가 목적지에 도달하는 데 너무 오래 걸리는 경우이를 인식하고 다른 경로를 사용하여 보상 할 수 있습니다. 이러한 속도 저하는 기본 하드웨어의 문제 또는 단순히 서비스가 요청으로 과부하되거나 처리 용량에서 작동하기 때문일 수 있습니다. 중요한 것은 서비스 메시가 동일한 서비스의 다른 인스턴스를 찾아 대신 라우팅하여 전체 애플리케이션의 용량을 가장 효율적으로 사용할 수 있다는 것입니다.

서비스 메시 대 Kubernetes

컨테이너 기반 아키텍처에 어느 정도 익숙하다면 인기있는 오픈 소스 컨테이너 오케스트레이션 플랫폼 인 Kubernetes가이 그림에 적합한 지 궁금 할 것입니다. 결국 컨테이너가 서로 통신하는 방식을 관리하는 것이 Kubernetes의 핵심이 아닙니까? Kublr 팀이 회사 블로그에서 지적했듯이 Kubernetes의 "서비스"리소스는 서비스 검색 및 요청의 라운드 로빈 밸런싱을 제공하므로 매우 기본적인 종류의 서비스 메시로 생각할 수 있습니다. 그러나 완전한 기능을 갖춘 서비스 메시는 보안 정책 및 암호화 관리, 느리게 응답하는 인스턴스에 대한 요청을 일시 중단하는 "회로 차단", 위에서 설명한로드 밸런싱 등과 같은 훨씬 더 많은 기능을 제공합니다.

대부분의 서비스 메시에는 실제로 Kubernetes와 같은 오케스트레이션 시스템이 있어야합니다. 서비스 메시는 대체가 아닌 확장 된 기능을 제공합니다.

서비스 메시 대 API 게이트웨이

각 마이크로 서비스는 다른 서비스와 통신하는 수단으로 사용되는 애플리케이션 프로그래밍 인터페이스 (API)를 제공합니다. 이로 인해 서비스 메시와 API 게이트웨이와 같은보다 전통적인 형태의 API 관리 간의 차이점에 대한 의문이 제기 됩니다. IBM이 설명했듯이 API 게이트웨이는 마이크로 서비스 그룹과 "외부"세계 사이에 서서 필요에 따라 서비스 요청을 라우팅하므로 요청자가 마이크로 서비스 기반 애플리케이션을 처리하고 있다는 사실을 알 필요가 없습니다. 반면 서비스 메시는 다양한 구성 요소가 환경을 완전히 인식하면서 마이크로 서비스 앱 "내부"요청을 중재합니다.

저스틴 워렌이 Forbes 에서 쓴 것처럼 이에 대해 생각하는 또 다른 방법 은 서비스 메시가 클러스터 내에서 동서 트래픽을위한 것이고 API 게이트웨이가 클러스터로 들어오고 나가는 남북 트래픽을위한 것이라는 것입니다. 그러나 서비스 메시에 대한 전체 아이디어는 아직 초기 단계이며 유동적입니다. Linkerd 및 Istio를 포함한 많은 서비스 메시는 이제 남북 기능도 제공합니다.

서비스 메시 아키텍처

서비스 메시에 대한 아이디어는 지난 몇 년 동안 만 등장했으며 "서비스 메시"문제를 해결하기위한 다양한 접근 방식, 즉 마이크로 서비스를위한 통신 관리가 있습니다. Aspen Mesh의 Andrew Jenkins는 서비스 메시에 의해 생성 된 통신 계층이 위치 할 수있는 위치와 관련하여 세 가지 가능한 선택 사항을 식별합니다.

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

사이드카 기반 패턴은 가장 인기있는 서비스 메시 패턴 중 하나입니다. 그래서 어떤면에서는 일반적으로 서비스 메시와 동의어가되었습니다. 엄밀히 말하면 사실은 아니지만 사이드카 접근 방식은 너무 많은 견인력을 얻었 기 때문에 이것이 우리가 더 자세히 살펴볼 아키텍처입니다.

서비스 메시의 사이드카

사이드카 컨테이너가 애플리케이션 컨테이너와 "나란히 실행"된다는 것은 무엇을 의미합니까? Red Hat은 꽤 좋은 설명을 가지고 있습니다. 이 유형의 서비스 메시에있는 모든 마이크로 서비스 컨테이너에는 이에 해당하는 또 다른 프록시 컨테이너가 있습니다. 서비스 간 통신에 필요한 모든 논리는 마이크로 서비스에서 추상화되어 사이드카에 배치됩니다.

이것은 복잡해 보일 수 있습니다. 결국 애플리케이션의 컨테이너 수를 두 배로 늘리는 것입니다! 하지만 분산 된 앱을 단순화하는 데 핵심적인 디자인 패턴도 사용하고 있습니다. 모든 네트워킹 및 통신 코드를 별도의 컨테이너에 넣음으로써이를 인프라의 일부로 만들고 개발자가이를 애플리케이션의 일부로 구현할 수 없게되었습니다.

본질적으로 남은 것은 비즈니스 로직에 집중할 수있는 마이크로 서비스입니다. 마이크로 서비스는 작동하는 거친 환경에서 다른 모든 서비스와 통신하는 방법을 알 필요가 없습니다. 나머지를 처리하는 사이드카와 통신하는 방법 만 알면됩니다.

서비스 메시 : Linkerd, Envio, Istio, Consul

그렇다면 사용할 수있는 서비스 메시는 무엇입니까? 글쎄요, 거기에 정확히 기성품 상업용 제품은 없습니다. 대부분의 서비스 메시는 구현하는 데 약간의 시간이 걸리는 오픈 소스 프로젝트입니다. 큰 이름은 다음과 같습니다.

  • Linkerd ( "linker-dee"로 발음)-2016 년에 출시되었으며 이러한 제품 중 가장 오래된 Linkerd는 Twitter에서 개발 한 라이브러리에서 분리되었습니다. 이 공간의 또 다른 헤비 타자 인 Conduit이 Linkerd 프로젝트에 참여하여 Linkerd 2.0의 기반을 형성했습니다.
  • Envoy—Lyft에서 생성 된 Envoy는 서비스 메시의 "데이터 플레인"부분을 차지합니다. 전체 서비스 메시를 제공하려면 다음과 같이 "제어 플레인"과 쌍을 이루어야합니다.
  • Istio—Lyft, IBM 및 Google이 공동으로 개발 한 Istio는 Envoy와 같은 서비스 프록시를위한 제어 계획입니다. Istio와 Envoy는 기본 쌍이지만 각각 다른 플랫폼과 쌍을 이룰 수 있습니다.
  • HashiCorp Consul—Consul 1.2에 도입 된 Connect라는 기능은 서비스 검색 및 구성을 위해 HashiCorp의 분산 시스템에 서비스 암호화 및 ID 기반 인증을 추가하여 완전한 서비스 메시로 전환했습니다.

귀하에게 적합한 서비스 메시는 무엇입니까? 비교는이 기사의 범위를 벗어나지 만 위의 모든 제품이 크고 까다로운 환경에서 입증되었음을 주목할 가치가 있습니다. Linkerd와 Istio는 가장 광범위한 기능 세트를 가지고 있지만 모두 빠르게 진화하고 있습니다. George Miranda의 Linkerd, Envoy 및 Istio 기능에 대한 분석을 확인하고 싶을 수 있지만, 그의 기사는 Conduit과 Linkerd가 합병하기 전에 작성되었습니다.

또한이 공간은 새롭고 언제든지 새로운 경쟁자가 나타날 수 있음을 명심하십시오. 예를 들어 2018 년 11 월 Amazon은 AWS 서비스 메시의 공개 미리보기를 제공하기 시작했습니다. Amazon의 퍼블릭 클라우드를 사용하는 상점 수를 고려할 때 AWS App Mesh는 큰 영향을 미칩니다.