서비스 메시(Service Mesh) 해설: 오픈소스 메시가 마이크로서비스 통신을 단순화하는 방법

마이크로서비스 아키텍처로 개발할 때 DevOps 팀이 구성해야 할 많은 개별 구성 요소가 있습니다. 마이크로서비스가 함께 작동하려면 정보 공유와 데이터 전송을 위한 확립된 통신 채널이 필요합니다.

서비스 간 통신을 관리하고 모니터링하는 한 가지 방법은 서비스 메시를 사용하는 것입니다.

서비스 메시(Service Mesh)란 무엇인가?

서비스 메시는 마이크로서비스 아키텍처에 추가되는 전용 인프라 계층입니다. 주요 역할은 빠르고 안전한 서비스 간 통신을 보장하는 것입니다. 이 저지연 도구는 서비스 간 통신과 데이터 공유를 관리하고 모니터링합니다.

개발자가 네트워킹 계층에 특정 규칙과 정책을 구현하는 컨트롤 플레인(control plane)으로 구성됩니다. 컨트롤 플레인은 데이터 플레인과 직접 작동하는데, 데이터 플레인은 서비스와 함께 실행되는 사이드카 프록시(sidecar proxies) 모음입니다. 이 프록시들은 서비스 간 모든 통신을 담당합니다. 또한 전체 애플리케이션 성능에 대한 귀중한 통찰을 모니터링하고 제공하여 잠재적 문제를 찾고 다운타임을 피하는 데 도움을 줍니다.

프록시들은 다음과 같은 가치 있는 기능을 제공합니다:

• 동적 서비스 발견
• 로드 밸런싱
• 상태 확인
• 암호화
• 관찰 가능성
• 서킷 브레이커
• 백분율 기반 트래픽 분할을 통한 단계적 롤아웃
• 인증
• 풍부한 메트릭
• 권한 부여

서비스 메시 아키텍처의 부상

서비스 메시가 어떻게 작동하는지 완전히 이해하려면 왜 그런 도구가 개발되었는지 살펴봐야 합니다. 서비스 메시 아키텍처의 부상은 마이크로서비스와 관련된 여러 문제의 해결책으로 등장했습니다.

많은 개발 팀이 모놀리식 애플리케이션 개발에서 마이크로서비스 아키텍처로 전환했습니다. 이는 애플리케이션을 모놀리식 단위에서 함께 작동하는 개별 서비스 시스템으로 분할했습니다. 애플리케이션은 고유한 기능을 가진 여러 자율 서비스로 구성됩니다.

이러한 애플리케이션 개발의 어려움은 이 서비스들이 서로 통신하는 최적의 방법을 구성하는 것입니다. 애플리케이션 성능은 서비스가 함께 작동하고 데이터를 공유하여 최상의 사용자 경험을 제공하는 데 달려 있습니다. 예를 들어, 웹 스토어는 로그인 서비스로 구성될 수 있으며, 이는 구매 서비스와 통신하고 이는 다시 인벤토리 데이터베이스의 정보를 필요로 하는 식입니다.

마이크로서비스가 API를 통해 통신하므로 발견(Discovery)과 라우팅(Routing)을 해결할 최적의 솔루션을 찾는 것이 중요했습니다. 또한 개발자는 시스템 내 통신이 안전한지 확인해야 했습니다. 방화벽이 외부 공격으로부터 애플리케이션을 보호했지만, 마이크로서비스 아키텍처 내부에는 평평하고 개방된 네트워크가 있었습니다.

메시 서비스 아키텍처 이전에는 이 작업이 로드 밸런서에 의해 처리되었습니다. 하지만 특히 대규모에서는 배포와 비용 문제로 실용적인 솔루션이 아니었습니다. 서비스 메시는 위에 언급된 모든 문제에 대한 궁극적인 솔루션으로 개발되었습니다. 중앙 집중식 레지스트리(컨트롤 플레인)를 가진 네트워킹 계층을 제시했으며, 이는 사이드카 프록시로 모든 서비스를 관리했습니다. 이들은 로드 밸런서보다 구성하고 확장하기 훨씬 쉽습니다. 개발자는 필요에 따라 프록시를 스케일 업/다운하고 서비스를 수정하지 않고 라우팅 규칙을 변경할 수 있습니다.

서비스 메시 이점

서비스 메시의 가장 중요한 이점은 다음과 같습니다:

• 향상된 보안(Improved security) – 마이크로서비스 아키텍처에 서비스 메시를 구현하면 전반적인 보안이 향상됩니다. 이 네트워크 계층은 자동 권한 부여(Authorization), 인증(Authentication), 암호화(Encryption), 정책 시행(Policy Enforcement)을 도입합니다. 모든 서비스 간 통신이 안전한지 보장하기 위해 상호 TLS(mTLS)를 사용합니다. 서비스는 TLS 인증서로 자신을 식별하여 연결을 설정합니다. 신원을 검증하면 데이터 공유를 위한 암호화된 채널을 설정합니다.
• 트래픽 제어 및 가시성(Traffic control and visibility) – 서비스 메시의 주요 기능 중 하나는 트래픽 제어를 제공하는 것입니다. 동서 트래픽과 서비스 간 트래픽을 관리합니다. 모든 통신은 컨트롤 플레인이 관리하는 사이드카 프록시를 통해 이루어집니다. 트래픽이 투명하게 라우팅되어 개발자가 모든 데이터 교환을 더 잘 파악할 수 있습니다. 애플리케이션 성능에 대한 더 명확한 통찰로 시스템 내 잠재적 문제를 더 쉽게 발견할 수 있습니다.
• 관찰 가능성(Observability) – 플랫폼이 모든 트래픽을 관리하므로 트래픽 행동과 사용자 상호작용에 대한 귀중한 통찰을 수집합니다. 이러한 대량의 데이터로 비즈니스 분석가는 애플리케이션 개선 전략을 계획할 수 있습니다.
• 개발자가 네트워킹 대신 앱 개발에 집중(Developers focusing on app development instead of networking) – 개발 팀이 전체 네트워킹 계층을 설정하고 관리하는 대신 서비스 메시를 아키텍처에 구현할 수 있습니다. 플랫폼이 초기 구성을 필요로 하지만, 네트워크 관리와 관련된 시간 소모적인 작업을 자동화합니다. 이는 개발자가 마이크로서비스에 집중할 수 있게 합니다. 서비스 메시가 서비스 간 상호작용을 관리하도록 맡김으로써 시간과 비용을 절약하면서 생산성도 향상시킵니다.
• 탄력성(Resiliency) – 서비스 메시는 탄력적인 마이크로서비스 애플리케이션을 만드는 데 도움이 되는 기능을 제공합니다. 그런 기능 중 하나는 장애와 지연 급증을 감지하는 서킷 브레이커 패턴입니다. 또한 서비스 메시는 서비스 발견과 마이크로서비스 네트워크 전반의 트래픽 라우팅을 위해 로드 밸런싱을 사용합니다. 재시도, 타임아웃, 데드라인 같은 다른 기능들도 탄력성을 더합니다.
• 더 빠른 테스트 및 배포 주기(Faster testing and deployment cycles) – 파드 간 통신에 사이드카 프록시를 사용하는 것이 훨씬 간단하고 빠르게 설정됩니다. 각 서비스에 중복 기능을 코딩하는 대신 프록시를 배포하고 서비스에 연결합니다. 이는 전반적인 개발 및 테스트 주기를 가속화합니다.

오픈 소스 서비스 메시 목록

여러 오픈 소스 서비스 메시가 있습니다. Istio, Linkerd, Consul이 가장 널리 사용됩니다.

아래에서 각 플랫폼에 대한 더 자세한 내용을 확인하세요.

Istio

Istio는 Google, IBM, Lyft가 설계한 오픈 소스 인프라입니다. 가장 초기의 서비스 메시 플랫폼 중 하나입니다. 운영과 서비스 메시 구성을 위한 여러 구성 요소(Pilot, Citadel, Mixer)로 구성된 컨트롤 플레인인 Istiod를 사용합니다. 데이터 플레인은 C++로 개발된 Envoy 프록시로 구성됩니다. HTTP/TCP 연결은 Istio의 로드 밸런서인 Gateway가 관리합니다. VirtualService와 DestinationRules가 라우팅 규칙과 정책을 정의합니다.

Linkerd

Linkerd는 Cloud Native Computing Foundation(CNCF) 프로젝트에서 개발한 경량 오픈 소스 서비스 메시입니다. 추가 구성 없이 모든 플랫폼에서 Kubernetes 클러스터에 설치하기 간단합니다. 구성 없음은 작은 클러스터 작업 시 이롭습니다. 그러나 대규모 프로젝트는 클러스터의 모든 서비스를 성공적으로 관리하기 위해 구성 가능성이 필요합니다.

사이드카 프록시는 Rust로 작성되었습니다. Linkerd는 컨트롤 플레인에 Controller를, 대시보드에 Web Deployment를 사용합니다. 또한 메트릭 탐색과 저장에 Prometheus를, 대시보드 렌더링과 표시에 Grafana를 활용합니다.

Consul Connect

Consul은 처음에 서비스 발견 도구로 설계되었다가 나중에 서비스 메시로 진화했습니다. Linkerd와 달리 Consul Connect는 많은 구성을 포함하여 네트워크 환경에 대한 더 많은 제어권을 제공합니다. 따라서 Linkerd보다 사용하기 더 어렵습니다. 이 오픈 소스 서비스 메시는 플랫폼에 구애받지 않아 Kubernetes나 Nomad를 요구하지 않습니다. 여전히 Nomad는 Consul을 통한 마이크로서비스 통신 관리를 단순화합니다.

Microsoft의 Open Service Mesh

Open Service Mesh(OSM)는 동적 마이크로서비스 애플리케이션을 관리하고 보호하기 위해 서비스 메시 인터페이스를 구현하는 CNCF Envoy 프로젝트입니다. 사이드카 컨테이너로 Envoy xDS를 사용합니다. 주요 기능으로는 트래픽 시프팅, 인증서 관리, mTLS 활성화, 자동 사이드카 주입, 접근 제어 정책이 있습니다.

Kuma

Kuma는 Kubernetes와 서비스 메시 내에서 실행되는 VM을 위한 오픈 소스 컨트롤 플레인입니다. L4+L7 정책 아키텍처를 가지고 있어 서비스 발견, 라우팅, 제로 트러스트 보안, 관찰 가능성 같은 기능을 구현합니다. 플랫폼은 높은 확장성과 쉬운 설정을 자랑합니다.

OpenShift Service Mesh Red Hat

Red Hat은 마이크로서비스 애플리케이션 관리를 위해 OpenShift Service Mesh를 개발했습니다. 네트워킹을 위한 여러 인터페이스와 보안 컨텍스트 제약(Security Context Constraint)을 통한 강화된 보안을 제공합니다. Jaeger로 성능을 측정하고 Kiali로 서비스 간 상호작용을 관찰합니다. 또한 더 나은 API 보안을 위해 Red Hat 3scale Istio Mixer Adapter를 포함합니다.

AWS App Mesh

Amazon은 마이크로서비스 아키텍처 내 모든 서비스를 관리하는 무료 서비스 메시 소프트웨어인 App Mesh를 개발했습니다. 마이크로서비스 애플리케이션에 대한 고가용성과 엔드투엔드 가시성을 제공합니다. AWS App Mesh는 AWS Fargate, Amazon ECS, Amazon EC2, Amazon EKS, Kubernetes, AWS Outposts와 통합됩니다. 모니터링 도구로 모니터링 데이터를 자동으로 내보냅니다.

Network Service Mesh

Network Service Mesh는 오픈 소스 CNCF Sandbox 프로젝트입니다. 간단한 API 세트를 사용하여 연결을 촉진하는 하이브리드/멀티 클라우드 IP 서비스 메시입니다. 컨테이너 내부에서 실행되는 서비스와 외부 엔드포인트 간의 연결을 설정합니다. 구현 시 Kubernetes에 최소한의 변경만 필요합니다.

결론(In Conclusion)

서비스 메시는 마이크로서비스 아키텍처를 사용하여 개발된 애플리케이션의 관리와 유지보수를 단순화합니다. 마이크로서비스 아키텍처 내 전반적인 보안을 개선하고 트래픽 흐름의 가시성과 관찰 가능성을 보장합니다. 전반적으로 서비스 메시 기능은 성능을 향상시키고 개발 주기를 가속화합니다. 다양한 오픈 소스 솔루션이 제공되므로 애플리케이션 요구에 가장 적합한 것을 찾으세요.