서비스 메쉬(service mesh)란?

서비스 메쉬는 소프트웨어 애플리케이션 내에서 서비스 간의 커뮤니케이션을 전담 처리하는 인프라 계층입니다. 서비스 메쉬는 트래픽 라우팅, 보안, 관측성 및 복구 기능을 처리하는 동시에 개별 서비스에서 이러한 복잡성을 추상화할 수 있습니다.

현대적인 애플리케이션은 서로 간에 커뮤니케이션하는 서비스에 의존합니다. 최근 온라인 스토어를 방문했던 때를 떠올려 보세요. 제품을 검색하기 위해 사이트에 있는 검색창을 사용했을 것입니다. 이러한 검색이 하나의 서비스가 됩니다. 또는 관련 제품 추천을 보았거나 장바구니에 상품을 추가하기도 했을 것입니다. 이러한 것들 역시 서비스입니다. 인벤토리 데이터베이스와 커뮤니케이션하는 서비스는 제품 웹 페이지와 커뮤니케이션해야 하며, 이 웹 페이지는 사용자의 온라인 장바구니와 커뮤니케이션해야 합니다. 해당 업체에 사용자에게 애플리케이션 내 제품 추천을 제공하는 서비스도 있을 수 있습니다. 이 서비스는 제품 태그 데이터베이스와 커뮤니케이션하여 제품을 추천하고, 또한 제품 페이지에서 필요로 하는 동일한 인벤토리 데이터베이스와도 커뮤니케이션해야 합니다.

현대적인 애플리케이션은 종종 이와 같은 원리로 각각 특정 기능을 수행하는 서비스 네트워크로 분류됩니다. 기능을 실행하기 위해 서비스는 여러 개의 다른 서비스들로부터 데이터를 요청해야 할 수 있습니다. 하지만 소매업체의 인벤토리 데이터베이스처럼 일부 서비스에 요청이 과도하게 몰리면 어떻게 될까요? 바로 이 지점에서 서비스 메쉬가 등장합니다. 서비스 메쉬는 서비스 간의 커뮤니케이션을 관리하여 모든 요소가 함께 작동하는 방식을 최적화합니다.

서비스 메쉬는 마이크로서비스 아키텍처 패턴으로 볼 수 있습니다. 마이크로서비스란 독립적인 서비스들의 모음이 경량화 API(애플리케이션 프로그래밍 인터페이스, Application Programming Interface)를 통해 커뮤니케이션하는 애플리케이션 아키텍처의 한 유형을 말합니다. 마이크로서비스 아키텍처는 하나의 애플리케이션 내에 있는 각 핵심 기능이 독립적으로 존재할 수 있도록 소프트웨어를 구축하는 클라우드 네이티브 접근 방식입니다. 다른 아키텍처에서의 애플리케이션 개발과 달리 개별 마이크로서비스는 자체 툴과 코딩 언어를 선택할 수 있는 유연성을 갖는 소규모 팀에 의해 구축될 수 있습니다. 마이크로서비스는 독립적으로 구축되고 서로 커뮤니케이션하며, 장애가 개별적으로 발생하므로 애플리케이션 전체의 운영 중단으로 확대되지 않습니다.

서비스 간 커뮤니케이션이 바로 마이크로서비스를 가능하게 하는 핵심입니다. 마이크로서비스가 증가함에 따라 관리가 더 복잡해집니다. 하나의 애플리케이션 내에서 수십 개 또는 수백 개의 서비스가 상호작용한다면 네트워크 오류, 모니터링 및 추적, 트래픽 부하 분산, 서로 다른 마이크로서비스 간의 커뮤니케이션 보안과 관련된 문제가 발생합니다. 오로지 사용자 정의 코드를 통해 이러한 문제를 해결하는 것은 비효율적입니다. 서비스 메쉬는 개별 서비스의 코드를 변경할 필요 없이 이러한 문제를 해결할 수 있는 일관된 솔루션을 제공합니다.

서비스 메쉬는 데이터 플레인과 컨트롤 플레인을 사용하여 서비스 간의 커뮤니케이션을 관리합니다. 서비스 메쉬는 애플리케이션 실행(runtime) 환경에 새로운 기능을 도입하지 않습니다. 아키텍처 내의 애플리케이션에는 요청이 A 지점에서 B 지점으로 전달되는 방식을 지정하는 룰이 항상 필요합니다. 서비스 메쉬의 차이점은 개별 서비스로부터 서비스 간 커뮤니케이션을 통제하는 로직을 통해 인프라 계층에 추상화한다는 점입니다.

이를 위해 서비스 메쉬는 네트워크 프록시의 배열로서 애플리케이션에 구축됩니다. 프록시는 널리 알려진 개념입니다. 업무용 컴퓨터에서 이 웹 페이지에 액세스하고 있다면 프록시를 사용했을 것입니다. 그 작동 원리는 다음과 같습니다.

1. 이 페이지에 대한 사용자의 요청이 전송되면 사용자의 회사 웹 프록시가 이를 수신합니다.
2. 요청이 프록시 보안 조치를 통과하면 이 페이지를 호스팅하는 서버로 전송됩니다.
3. 다음으로 이 페이지가 프록시로 돌아가고 보안 조치를 통해 요청이 다시 점검됩니다.
4. 그 후 프록시에서 사용자로 요청이 전송됩니다.

서비스 메쉬에서는 각 서비스 인스턴스가 각 서비스와 나란히 실행되는 '사이드카' 프록시와 쌍을 이루고 모든 수신 및 발신 네트워크 트래픽을 가로챕니다. 각 사이드카 프록시는 마이크로서비스와 나란히 위치하며 다른 프록시와의 사이에 요청을 라우팅합니다. 프록시는 트래픽 라우팅, 부하 분산, 보안 정책 적용, 텔레메트리 데이터 수집과 같은 작업을 수행합니다. 서비스는 서로 간에 직접 커뮤니케이션하는 대신 사이드카를 통해 요청을 전송합니다. 사이드카는 서비스 간 커뮤니케이션을 처리합니다. 이 모든 것이 데이터 플레인을 구성하는 요소입니다.

컨트롤 플레인은 데이터 플레인 전반에서 구성과 정책 배포를 관리합니다. 그 외에도 트래픽 라우팅 룰을 배포하고, 서비스 간 보안 인증서를 관리하고, 정책 적용을 위한 구성 요소를 구성하고, 텔레메트리를 수집합니다.

서비스 메쉬가 없다면 서비스 간 커뮤니케이션을 통제하는 로직을 사용하여 각 마이크로서비스를 코딩해야 합니다. 이 경우 서비스 간 커뮤니케이션을 통제하는 로직이 각 서비스 내부에 숨겨져 있기 때문에 커뮤니케이션 장애를 진단하기가 더 어려워집니다.

마이크로서비스에 대해 자세히 알아보기

Istio는 마이크로서비스가 서로 간에 데이터를 공유하는 방식을 제어하는 오픈소스 서비스 메쉬 플랫폼입니다. Istio는 마이크로서비스 환경 내에서 트래픽 흐름을 관리하고, 정책을 적용하고, 커뮤니케이션을 모니터링합니다. 여기에는 Istio를 임의의 로깅 플랫폼, 텔레메트리 또는 정책 시스템에 통합할 수 있는 API가 포함됩니다. Istio는 다양한 온프레미스 및 클라우드 환경, 컨테이너화된 환경, 가상화된 환경에서 실행 가능합니다.

Istio의 아키텍처는 데이터 플레인과 컨트롤 플레인으로 구성됩니다. Istio는사이드카로 배포되어 서비스 메쉬 내 모든 서비스의 트래픽을 중개하는 고성능 프록시인 Envoy 프록시를 사용합니다. 데이터 플레인에서는 개발자가 환경 내에 사이드카 프록시를 배포하여 서비스에 Istio 지원을 추가할 수 있습니다.

Istio의 서비스 메쉬에는 새로운 앰비언트 모드(ambient mode)가 포함되어 있어 서비스 메쉬에서 사이드카 프록시를 사용할 필요를 없앱니다. 이 모드에서 사이드카 프록시는 노드 수준의 프록시와 웨이포인트(waypoint)라고 불리는 중간 게이트웨이로 대체됩니다. 웨이포인트 프록시는 애플리케이션 포드 외부에서 실행되며 애플리케이션과 독립적으로 관리됩니다.

Red Hat Developer에서 Istio에 대해 자세히 알아보기

애플리케이션에 추가되는 모든 새로운 서비스 또는 컨테이너에서 실행되는 기존 서비스의 새로운 인스턴스는 커뮤니케이션 환경을 복잡하게 하고 새로운 장애 지점을 유발합니다. 복잡한 마이크로서비스 아키텍처 내에서 서비스 메쉬 없이는 문제를 찾기가 거의 불가능합니다.

서비스 메쉬를 사용하면 다음과 같은 장점이 있습니다.

• 보안 강화. 서비스 메쉬는 상호 전송 계층 보안(mutual Transport Layer Security, mTLS)을 사용하여 서비스 간의 커뮤니케이션을 안전하게 암호화하고 민감한 사용자 데이터를 보호합니다. 이 방식은 각 서비스에 추가 암호화를 수동으로 추가할 필요 없이 추가적인 보안 계층을 제공합니다. 서비스 메쉬는 API 보안을 위한 RBAC(역할 기반 액세스 제어, Role-based Access Control) 및 정책을 개선할 수 있으며, 인증서 관리와 키 순환을 자동화할 수 있습니다.
• 정책 실행. 서비스 메쉬는 할당량, 속도 제한, 인증 및 권한 부여와 같은 서비스 정책에 대한 중앙화된 구성을 포함합니다. 이는 액세스 정책을 통한 서비스 상호작용 제어를 제공합니다. 정책은 프록시 수준에서 적용되어 서비스 간 일관성 유지를 돕습니다.
• 트래픽 관리. 서비스 메쉬는 애플리케이션이 부하 조건, 버전, 사용자별 룰을 기반으로 개별 서비스에 대한 트래픽을 관리하는 데 도움을 줄 수 있습니다. 예를 들어 인벤토리 서비스의 새 버전을 배포하는 경우 카나리아(Canary) 배포(소규모 테스트 배포를 의미)를 사용하여 트래픽의 5%만 새로운 서비스에 전송할 수 있습니다. 이 방법이 유효한 경우 트래픽을 늘릴 수 있습니다.
• 상태 점검 및 관측성. 마이크로서비스가 상호작용하는 방식을 실시간으로 파악하기는 어려울 수 있습니다. 하지만 서비스 메쉬를 사용하면 분산 추적 및 메트릭 수집과 같은 빌트인 관측성 툴을 구현할 수 있습니다. 서비스 메쉬 내의 사이드카는 메트릭(요청 수, 대기 시간, 오류 발생률)을 수집하여 컨트롤 플레인 또는 모니터링 툴로 전송할 수 있습니다.
• 내결함성 및 향상된 복구 능력. 마이크로서비스에서 오류가 발생하는 경우 서비스 메쉬는 재시도와 폴백을 자동화하여 복구를 도울 수 있습니다. 서비스가 실패하거나 응답하지 않는 경우, 서비스 메쉬는 사전 정의된 룰을 기반으로 재시도하고 대체 서비스로 트래픽을 리라우팅할 수 있습니다. 즉, 서비스를 사용할 수 없는 경우 애플리케이션이 오류를 원활하게 처리하여 사용자에게 여전히 만족스러운 경험을 제공할 수 있습니다. 또한 서비스 메쉬는 재시도가 성공하기까지 걸린 시간에 관한 데이터도 수집합니다. 이 데이터는 향후 최적의 대기 시간에 관한 룰을 결정하는 데 유용한 정보를 제공할 수 있으며, 이를 통해 불필요한 재시도로 인한 시스템 과부하를 방지할 수 있습니다.

개발 팀과 운영 팀은 서비스 메쉬를 사용하여 모놀리식 애플리케이션에서 클라우드 네이티브 애플리케이션(작고 독립적이며 느슨하게 연결된 마이크로서비스 애플리케이션의 모음)으로의 마이그레이션을 더욱 원활하게 수행할 수 있습니다. 

조직이 서비스 메쉬를 구현하는 과정에서 다음과 같은 과제를 해결해야 할 수 있습니다.

• 복잡성과 기존 시스템과의 통합. 서비스 메쉬를 설정 및 관리하고 기존 시스템과 통합하기 어려울 수 있습니다. 멀티클라우드와 온프레미스 시스템에 걸쳐 분산된 방대한 환경에서 작업하거나 이전에 환경에서 서비스 메쉬를 사용해 본 적이 없는 조직은 어려움을 겪을 수 있습니다.
• 리소스 요구 사항과 운영 오버헤드. 서비스 메쉬는 애플리케이션 관리의 운영 오버헤드를 늘릴 수 있습니다. 각 서비스 인스턴스에 이제 사이드카 프록시가 있어 CPU 및 메모리 사용이 늘어나기 때문입니다. 관리와 트러블슈팅이 복잡할 수 있으며 대규모 배포인 경우 특히 그럴 가능성이 높습니다. 따라서 성능과 규모를 유지 관리하기가 더 어려울 수 있습니다.
• 기술 격차. 팀이 서비스 메쉬의 기능과 구성, 모범 사례를 이해할 수 있으려면 교육이 필요합니다. 오류를 디버깅하는 작업은 매우 까다로울 수 있으며, 복잡한 라우팅 룰 또는 mTLS 구성 오류로 인해 문제가 발생하는 경우 특히 그렇습니다. 많은 조직이 기존 팀의 서비스 메쉬 기술에 대한 전문성 부족을 경험하고 있으며, 이는 서비스 메쉬를 효과적으로 시작하고 사용하는 데 걸림돌이 될 수 있습니다.

 API 게이트웨이는 클라이언트와 백엔드 서비스 컬렉션 사이에 위치하는 API 관리 툴입니다. 이 경우, 클라이언트는 사용자의 기기에 있는 애플리케이션이며 백엔드 서비스는 엔터프라이즈 서버에 있는 서비스입니다. API 게이트웨이는 클라이언트 인터페이스를 백엔드 구현 환경에서 분리할 수 있는 방법입니다. 클라이언트가 요청을 하면 API 게이트웨이가 클라이언트의 요청을 여러 개의 요청으로 나누어 적절한 위치로 전달하고, 응답을 생성하며, 모든 상황을 추적합니다.

서비스 메쉬는 내부 서비스 커뮤니케이션을 안전하게 보호하는 동시에 API 게이트웨이를 통해 외부 트래픽을 허용합니다. 서비스 메쉬와 API 게이트웨이를 함께 사용하면 모든 내부 서비스에 정책을 일관되게 적용할 수 있습니다. 

Red Hat 3scale API Management에 대해 자세히 알아보기

Red Hat은 통합된 API 관리, 서비스 메쉬, 인프라 플랫폼 제품을 제공하여 통합 서비스 관리 아키텍처를 구축할 수 있도록 돕습니다. Red Hat® OpenShift® Service Mesh는 마이크로서비스 기반 애플리케이션을 일관된 방식으로 연결, 관리, 관측할 수 있도록 지원합니다. Red Hat OpenShift Service Mesh는 사용자의 서비스 메쉬에서 네트워크화된 마이크로서비스에 대한 행동 기반 인사이트와 제어 기능을 제공합니다.

오픈소스 Istio 프로젝트로 구축된 OpenShift Service Mesh는 Istio 커뮤니티 주요 구성원과의 협업을 지원하는 Kiali(Istio 콘솔) 및 Jaeger(분산 추적)와 같은 기타 오픈소스 프로젝트를 비롯한 추가 기능을 제공합니다. OpenShift Service Mesh는 개발자가 애플리케이션 코드를 변경하거나 언어별 라이브러리를 통합하지 않고도 커뮤니케이션 정책을 통합함으로써 생산성을 높일 수 있도록 지원합니다.

Red Hat OpenShift Service Mesh는 Red Hat OpenShift용으로 테스트되고 최적화되어 사전 설치되는 서비스 메쉬입니다. 이는 오퍼레이터, 지속적 통합 및 지속적 제공(Continuous Integration and Continuous Delivery, CI/CD) 파이프라인과 같은 OpenShift 고유 기능과의 호환성을 제공합니다. 또한 Red Hat의 엔터프라이즈 지원을 제공하며 보안과 안정성을 위해 정기적으로 업데이트되고 패치가 적용됩니다. OpenShift Service Mesh는 다양한 Red Hat OpenShift 클러스터에서 작동하여 하이브리드 클라우드 및 멀티클라우드 환경 전반에서 일관성을 유지합니다.