Service Mesh 란 무엇인가?

최근에는 클라우드 환경에서 애플리케이션을 개발하고 배포하는 것이 매우 일반적입니다. 이러한 환경에서는 애플리케이션 개발자들은 애플리케이션 로직 구현에만 집중하고, 인프라 관리나 네트워크 설정 등에 대해서는 그다지 신경쓰지 않아도 되는 장점이 있습니다. 하지만, 이러한 편리함에도 불구하고, 서비스간의 통신이 복잡해지면서 관리가 어려워지는 문제가 발생하고 있습니다. 이러한 문제를 해결하기 위해 등장한 기술 중 하나가 ‘ Service Mesh ‘입니다. 이번 포스트에서는 Service Mesh가 무엇인지, 어떤 문제를 해결하는지, 그리고 어떻게 동작하는지에 대해서 알아보겠습니다.

목 차

1. Service Mesh란 ?
2. Service Mesh의 구성 요소 서비스 및 기능
3. Service Mesh 아키텍처의 사용 사례

1. Service Mesh 란 ?

Service Mesh는 API( Application Programming Interface )를 사용하여 애플리케이션 인프라 서비스 간에 대량의 네트워크 기반 프로세스 간 통신을 처리하도록 설계된 구성이 가능하고 대기 시간이 짧은 인프라 계층입니다. Service Mesh는 컨테이너화되고 종종 일시적인 애플리케이션 인프라 서비스 간의 통신이 빠르고 안정적이며 안전하도록 보장합니다. Service Mesh 는 Service Discovery, 로드 밸런싱, 암호화, 관측 가능성, 추적 가능성, 인증 및 권한 부여, 회로 차단기 패턴 지원을 포함한 중요한 기능을 제공합니다.

Service Mesh는 일반적으로 각 서비스 인스턴스에 대해 사이드카(Sidecar)라고 하는 프록시 인스턴스를 제공하여 구현됩니다. 사이드카는 서비스 간 통신, 모니터링 및 보안 관련 문제, 즉 개별 서비스에서 추상화할 수 있는 모든 것을 처리합니다. 이러한 방식으로 개발자는 서비스의 애플리케이션 코드에 대한 개발, 지원 및 유지 관리를 처리할 수 있습니다. 운영 팀은 Service Mesh를 유지 관리하고 앱을 실행할 수 있습니다.

Google, IBM 및 Lyft가 지원하는 Istio는 현재 가장 잘 알려진 Service Mesh아키텍처입니다. 원래 Google에서 설계한 Kubernetes는 현재 Istio에서 지원하는 유일한 컨테이너 오케스트레이션 프레임워크입니다. 공급업체는 Istio의 지원되는 상용 버전을 빌드하려고 합니다. 오픈소스 프로젝트에 추가 할 수 있는 값을 보는 것은 흥미로울 것입니다.

Istio가 유일한 옵션은 아니며 다른 Service Mesh 구현도 개발 중입니다. 사이드카 프록시(Sidecar Proxy) 패턴은 Buoyant, HashiCorp, Solo.io 등의 프로젝트에서 볼 수 있듯이 가장 많이 사용되고 있습니다. 대체 아키텍처도 존재합니다. Netflix의 기술 제품군은 애플리케이션 라이브러리(Ribbon, Hysterix, Eureka, Archaius) 및 Azure Service Fabric과 같은 플랫폼에서 Service Mesh 기능을 애플리케이션 프레임워크에 포함하는 Service Mesh 기능을 제공하는 접근 방식 중 하나입니다.

2. Service Mesh의 구성 요소 서비스 및 기능

Service Mesh에는 구성 요소 서비스 및 기능에 대한 자체 용어가 함께 제공됩니다.

  • 컨테이너 오케스트레이션 프레임워크 – 점점 더 많은 컨테이너가 애플리케이션의 인프라에 추가됨에 따라 컨테이너 집합을 모니터링하고 관리하기 위한 별도의 도구(컨테이너 오케스트레이션 프레임워크)가 필수적이 되었습니다. Kubernetes는 주요 경쟁업체인 Docker Swarm 및 Mesosphere DC/OS와 함께 이 시장을 장악한 것으로 보이며 대안으로 Kubernetes와의 통합을 제공합니다.
  • 서비스 및 인스턴스(Kubernetes Pod) – 인스턴스는 마이크로서비스의 실행 중인 단일 복사본입니다. 때때로 인스턴스는 단일 컨테이너입니다. Kubernetes에서 인스턴스는 작은 그룹의 상호 의존적인 컨테이너( Pod 라고 함 )로 구성됩니다. 클라이언트는 인스턴스나 Pod에 직접 액세스하는 경우가 거의 없습니다. 오히려 확장 가능하고 내결함성이 있는 동일한 인스턴스 또는 Pod(복제본) 집합인 서비스에 액세스합니다
  • 사이드카 프록시(Sidecar Proxy) – 사이드카 프록시는 단일 인스턴스 또는 Pod와 함께 실행됩니다. 사이드카 프록시의 목적은 함께 실행되는 컨테이너로 트래픽을 라우팅하거나 프록시하는 것입니다. 사이드카는 다른 사이드카 프록시와 통신하며 오케스트레이션 프레임워크에 의해 관리됩니다. 많은 Service Mesh 구현에서는 사이드카 프록시를 사용하여 인스턴스 또는 Pod에 대한 모든 수신(Ingress) 및 송신(Egress) 트래픽을 가로채고 관리합니다.
  • 서비스 검색(Service Discovery) – 인스턴스가 다른 서비스와 상호 작용해야 하는 경우 다른 서비스의 건전하고 사용 가능한 인스턴스를 찾아야 합니다. 일반적으로 인스턴스는 이 목적을 위해 DNS 조회를 수행합니다. 컨테이너 오케스트레이션 프레임워크는 요청을 수신할 준비가 된 인스턴스 목록을 유지하고 DNS 쿼리에 대한 인터페이스를 제공합니다.
  • 로드 밸런싱 – 대부분의 오케스트레이션 프레임워크는 이미 계층 4(전송 계층) 로드 밸런싱을 제공합니다. Service Mesh는 더 풍부한 알고리즘과 더 강력한 트래픽 관리를 통해 더 정교한 레이어 7(애플리케이션 레이어) 로드 밸런싱을 구현합니다. 로드 밸런싱 매개변수는 API를 통해 수정할 수 있으므로 Blue-Green 또는 Canary 배포(Deployment)를 조율할 수 있습니다.
  • 암호화(Encryption) – Service Mesh는 요청과 응답을 암호화하고 해독하여 각 서비스에서 부담을 제거할 수 있습니다. 또한 Service Mesh는 기존 영구 연결의 재사용에 우선 순위를 지정하여 성능을 개선할 수 있으므로 계산 비용이 많이 드는 새 연결을 생성할 필요성이 줄어듭니다. 트래픽 암호화를 위한 가장 일반적인 구현은 PKI(공개 키 인프라)가 사이드카 프록시에서 사용할 인증서와 키를 생성하고 배포하는 상호 TLS(mTLS)입니다.
  • 인증 및 승인(Authentication and Authorization). – Service Mesh는 앱 외부와 내부에서 생성된 요청을 승인하고 인증하여 검증된 요청만 인스턴스로 보낼 수 있습니다.
  • 회로 차단기 패턴(Circuit breaker)을 지원합니다. Service Mesh는 비정상 인스턴스를 격리한 다음 보증되는 경우 조금씩 정상 인스턴스 풀로 다시 가져오는 회로 차단기 패턴 을 지원할 수 있습니다.

인스턴스 간의 네트워크 트래픽을 관리하는 Service Mesh 애플리케이션의 일부를 Data Plane이라고 합니다. Data Plane의 동작을 제어하는 ​​구성 생성 및 배포는 별도의 Control Plane을 사용하여 수행됩니다. Control Plane은 일반적으로 앱 관리를 위한 API, 명령줄 인터페이스 및 그래픽 사용자 인터페이스를 포함하거나 연결하도록 설계되었습니다.

Service Mesh Control Plane

Service Mesh의 Control Plane은 Data Plane의 사이드카 프록시에 구성을 배포합니다.

3. Service Mesh 아키텍처의 사용 사례

Service Mesh 아키텍처의 일반적인 사용 사례는 컨테이너 및 마이크로서비스를 사용할 때 매우 까다로운 운영 문제를 해결하는 것입니다. 마이크로서비스의 선구자에는 Lyft, Netflix 및 Twitter와 같은 회사가 포함되며, 이들은 각각 전 세계 수백만 명의 사용자에게 강력한 서비스를 제공합니다. 덜 까다로운 애플리케이션 요구 사항의 경우 더 단순한 아키텍처로 충분할 수 있습니다.

Service Mesh 아키텍처가 모든 애플리케이션 운영 및 전달 문제에 대한 답이 될 가능성은 없습니다. 설계자와 개발자는 매우 많은 도구를 가지고 있으며 그 중 하나만 망치이고 많은 유형의 문제를 해결해야 하며 그 중 하나만 못이 됩니다. 예를 들어 NGINX 마이크로서비스 참조 아키텍처에는 마이크로서비스를 사용하여 문제를 해결하는 연속적인 접근 방식을 제공하는 여러 가지 모델이 포함되어 있습니다.

아키텍처 접근 방식으로서의 NGINX, 컨테이너, Kubernetes 및 마이크로서비스와 같은 Service Mesh 아키텍처에서 함께 제공되는 요소는 Non-Service Mesh 구현에서 생산적으로 사용되고 있습니다. 예를 들어 Istio는 완전한 Service Mesh 아키텍처로 개발되었지만 모듈식 설계는 개발자가 필요한 구성 요소 기술을 선택하고 선택할 수 있음을 의미합니다.이를 염두에 두고 Service Mesh 애플리케이션을 완전히 구현할지 여부와 시기가 확실하지 않더라도 Service Mesh 개념을 확실하게 이해하는 것이 좋습니다.

NGINX Service Mesh (NSM)를 직접 사용해 보십시오! 무료로 다운로드하여 개발 및 테스트 환경에서 사용하거나 최신 소식을 빠르게 전달받고 싶으시다면 아래 뉴스레터를 구독하세요.