서비스 메시란 무엇인가?

서비스 메시 소개

서비스 메시는 마이크로서비스 시스템의 서비스 간 통신을 관리하기 위해 사용되는 구성 가능한 인프라입니다. 이는 마이크로서비스 간의 트래픽, 즉 동-서 트래픽을 처리하는 것을 목표로 합니다.

클라우드 네이티브 애플리케이션에서는 하나의 애플리케이션이 수백 개의 서비스로 구성될 수 있습니다. 각 서비스는 여러 인스턴스를 가질 수 있으며, 이러한 인스턴스들은 지속적으로 변경될 수 있습니다. 이러한 복잡한 실행 환경에서 사용자에게 안정적인 접근을 제공하고 서비스가 안정적으로 실행되도록 유지하는 것은 큰 도전이 되었습니다. 이에 따라 서비스 메시라는 솔루션이 등장했습니다.

서비스 메시는 마이크로서비스 간의 TCP/IP와 같으며, 네트워크 호출, 속도 제한, 모니터링 등과 같은 서비스 간 기능을 처리합니다. 주로 Kubernetes 플랫폼에서 서비스 메시를 적용하며, 가장 전형적인 패턴은 사이드카라고 불립니다. 이 패턴은 몇 가지 일반적인 기능을 사이드카 컨테이너로 추상화하고 서비스 컨테이너와 함께 동일한 pod에 마운트합니다. 아래 이미지는 이를 서비스 메시라고 부르는 이유를 보여줍니다.

사이드카는 서비스 메시를 적용하는 유일한 패턴이 아닙니다. 그 외에도 DaemonSet 패턴과 Ambient 메시 패턴이 있습니다:

DaemonSet 패턴과 사이드카 패턴의 차이점은 DaemonSet 패턴은 Kubernetes 클러스터의 각 노드에서 하나의 pod만 실행할 수 있으며, 이 pod는 사이드카 프록시로 작동합니다. 사이드카 패턴에 비해 DaemonSet 패턴은 기계 리소스를 훨씬 적게 사용하지만, 격리성이 떨어지고 리소스 호출 예측이 어렵다는 단점이 있습니다. 이에 대한 더 많은 차이점은 이 글에서 확인할 수 있습니다: Sidecars and DaemonSets: Battle of containerization patterns.
Ambient 메시는 Istio가 2022년 9월 7일에 도입한 새로운 데이터 플레인 모드입니다. 메시 인프라와 배포의 결합 문제를 해결하기 위해 Ambient 메시는 데이터 플레인 프록시를 애플리케이션 pod에서 분리하여 별도로 배포할 수 있도록 합니다.

Ambient 메시는 데이터 플레인을 보안 오버레이 계층과 L7 처리 계층으로 분할합니다: 보안 오버레이 계층은 TCP 라우팅, 모니터링 메트릭, 접근 로깅, mTLS 터널링과 같은 기능을 처리하며, L7 처리 계층은 보안 오버레이 계층의 모든 기능 외에도 HTTP 라우팅을 통한 트래픽 제어, 관측 가능성, 풍부한 L7 인증 정책 등을 제공합니다.

또한, Ambient 메시는 **ztunnel (제로 트러스트 터널)**이라는 공유 에이전트를 사용하며, 이는 Kubernetes 클러스터 내부의 모든 노드에서 실행되어 메시 내부의 워크로드를 안전하게 연결하고 인증합니다. Ambient 메시 모드에 대한 자세한 내용은 이 글을 참조하세요: Introducing Ambient Mesh

왜 서비스 메시가 필요한가?

서비스 메시가 인기를 끌기 전에는 많은 마이크로서비스 아키텍처의 서비스 거버넌스가 마이크로서비스 프레임워크와 제어 플랫폼의 협력을 통해 이루어졌습니다. 그러나 이 방법에는 다음과 같은 문제가 있습니다:

프레임워크와 서비스 간의 긴밀한 결합으로 인해 전체 유지보수 난이도와 복잡성이 매우 높아집니다. 또한, 개발자들은 공용 라이브러리를 이해해야 하므로 서비스 구현에 집중할 수 없습니다.
다중 언어 프레임워크를 유지해야 하므로 유지보수 비용이 증가합니다.
마이크로서비스의 업그레이드 비용이 높으며, 업그레이드 중에 서비스를 재시작해야 하는 경우가 많습니다.
다양한 온라인 버전의 프레임워크가 존재하여 복잡한 호환성을 고려해야 합니다.

이러한 문제를 해결하기 위해, 이전 Twitter 엔지니어이자 Linkerd의 창립자 중 한 명인 Willian Morgan은 "서비스 메시"라는 개념을 제안했습니다. 서비스 메시는 사이드카 패턴을 사용하여 애플리케이션에 영향을 주지 않고 인프라와 서비스 로직을 분리하며, 언어 통합 업그레이드와 운영 및 유지보수를 가능하게 합니다.

Microservices Framework to Service Mesh

서비스 메시는 트래픽 제어, 관측 가능성, 안전한 통신과 같은 기능을 기본 구성 요소로 이동시킵니다. 따라서 개발자들은 통신 계층과 서비스 관리의 구체적인 구현에 대해 걱정할 필요가 없습니다. 개발자들은 통신과 관련된 모든 번거로운 작업을 서비스 메시에 맡기고 서비스 개발에 집중할 수 있습니다. 이러한 특징을 바탕으로 서비스 메시는 앞서 언급한 문제들을 해결하는 데 도움을 줄 수 있습니다.

서비스 메시는 어떻게 작동하는가?

서비스 메시는 애플리케이션의 실행 환경에 새로운 기능을 추가하지 않으므로, 프레임워크 내의 모든 애플리케이션은 여전히 A에서 B로 요청을 보내는 방법을 지정하는 규칙이 필요합니다. 차이점은 서비스 메시가 로직 관리의 서비스 간 통신을 추출하여 이를 인프라 계층으로 추상화한다는 점입니다.

현재 대부분의 서비스 메시는 데이터 플레인 + 제어 플레인 아키텍처를 사용하며, 이는 아래와 같습니다:

제어 플레인

제어 플레인은 데이터 플레인을 관리하고 구성하며, 서비스 실행 중에 전략을 수행합니다. 단일 서비스 메시 내의 모든 인스턴스는 동일한 구성 리소스를 공유합니다.

제어 플레인은 보안, 관측 가능성, 트래픽 제어와 같은 전달 및 전략에 더 중점을 둡니다. 또한, 데이터 플레인의 원격 측정 데이터를 수집하여 DevOps가 이를 사용할 수 있도록 합니다.

데이터 플레인

데이터 플레인은 일반적으로 프록시로 작동하며, 많은 사이드카 프록시로 구성됩니다. 사이드카는 서비스 인스턴스와 병렬로 실행되며, 서비스 데이터 흐름을 가로채어 서비스 애플리케이션의 트래픽을 제어합니다.

앞서 언급했듯이, 서비스 메시는 Kubernetes에 사이드카 패턴을 구현하고 이를 컨테이너로 래핑하여 달성됩니다. 사이드카는 메인 컨테이너를 확장하고 강화하기 위해 추가 컨테이너를 사용하는 것을 제안하며, 이 추가 컨테이너는 사이드카 컨테이너라고 불리며 서비스 컨테이너와 동일한 pod에 할당됩니다. 반면, 서비스 메시는 이러한 사이드카 프록시로 구성된 메시 네트워크입니다.

서비스 메시의 응용

마이크로서비스 아키텍처에서 엔지니어들은 일반적으로 노출된 공용 서비스를 암호화하거나 접근을 제한하여 서비스를 보호하지만, 클러스터 내부의 통신 안전성을 간과하는 경우가 많습니다. 지금까지도 많은 마이크로서비스 애플리케이션은 서비스 간 통신 암호화가 부족하며, 클러스터 내부 트래픽은 원시 데이터 형식으로 전송됩니다. 결과적으로 내부 트래픽은 도청 공격과 MITM (Man-in-the-middle attack)에 매우 취약합니다.

클러스터 내부 트래픽에 대한 공격을 방지하기 위해, 우리는 mTLS를 사용하여 트래픽 데이터를 암호화합니다. mTLS는 서비스 메시 내의 마이크로서비스 간 통신 안전성을 보장합니다. 이는 암호화 기술을 사용하여 각 마이크로서비스를 인증하고 서비스 간 트래픽을 상호 암호화합니다.

마이크로서비스 내부에서 직접 통신 안전 전략을 정의하고 신원 인증 및 암호화를 구현할 수 있지만, 각 마이크로서비스에서 동일한 기능을 개별적으로 구현하는 것은 매우 비효율적입니다. 새로운 기능을 추가하려면 서비스의 코드를 수정하고 서비스 로직을 침범해야 합니다. 더욱이, 새로운 기능을 구현할 수 있다 하더라도, 이후의 반복, 업그레이드 및 테스트는 개발자들이 더 많은 시간을 유지보수에 투자해야 하므로 개발자들이 서비스 기능 개발에 집중할 수 없게 됩니다.

대신, 서비스 메시를 사용하면 원래 서비스가 인식하지 못하는 상태에서 mTLS 통신을 제공할 수 있습니다. 따라서 서비스 메시에서는 모든 통신 관련 기능을 사이드카 프록시로 이동시킵니다.

두 마이크로서비스가 통신해야 할 때, 사이드카 프록시는 먼저 mTLS 연결을 구축하고, 이 mTLS 연결을 통해 암호화된 트래픽을 전송합니다. 사이드카는 인증 기관을 통해 인증서를 교환하고 서로를 인증합니다. 연결 전에, 사이드카는 제어 플레인에서 전송된 인증 전략을 검토하여 마이크로서비스가 통신할 수 있는지 여부를 결정합니다. 통신이 허용되면, 사이드카는 생성된 통신 키를 사용하여 안전한 연결을 구축하고 마이크로서비스 간 통신 데이터를 암호화합니다. 전체 과정에서 서비스 애플리케이션은 영향을 받지 않으므로 개발자들의 번거로움을 줄입니다.

이 시나리오를 통해 모든 사람이 서비스 메시가 현재 서비스에 영향을 주지 않고도 현재 기능을 확장할 수 있는 이유를 이해할 수 있습니다. 그러나 물론, mTLS와 유사한 내부 트래픽 안전 구성 기능을 달성하는 것 외에도, 서비스 메시는 제어 플레인의 구성을 수정하여 트래픽 제어, 관측 가능성, 코덱 프로토콜과 같은 기능을 빠르게 확장할 수 있습니다.

결론

이 글은 서비스 메시의 기본 개념, 작동 원리 및 우리에게 가져다주는 이점을 간략히 소개했습니다. 서비스 메시는 마이크로서비스 아키텍처를 혁신하고 개발자들이 복잡한 마이크로서비스 실행 환경에서 벗어나 서비스 기능 개발에 집중할 수 있도록 도와줍니다.

서비스 메시가 마이크로서비스 아키텍처의 많은 문제점을 해결했음에도 불구하고, 여전히 한계가 있습니다. 소프트웨어 개발의 복잡성은 영원하며, 단지 한 부분에서 다른 부분으로 전달될 뿐입니다. 서비스 관리를 별도의 계층으로 추상화할 때, 우리는 추가적인 운영 및 유지보수 어려움과 트래픽 링크의 증가에 직면해야 합니다. 더욱이, 서비스 메시는 클라우드 네이티브 환경에서 사용되어야 하므로 DevOps의 전문 능력과 엔지니어링 경험에 대한 요구 사항이 더 높아집니다. 이것이 바로 기술은 문제를 해결하기 위한 도구일 뿐이며, 우리는 서비스 메시가 가져다주는 이점을 실제 응용에 따라 저울질해야 한다고 말하는 이유입니다.

클라우드 네이티브의 폭발적인 발전과 서비스 메시의 최적화로 인해, 서비스 메시는 미래에 마이크로서비스 아키텍처를 완전히 대체하고 각 회사의 마이크로서비스 및 클라우드 네이티브 재구성 아키텍처의 첫 번째 선택이 될 가능성이 높습니다.

API 관리에 대해 더 알고 싶다면, 언제든지 연락주세요: https://api7.ai/contact.