Service Mesh 에 대하여

들어가기 앞서 ...

쿠버네티스를 하는데 왜 서비스 메시를 알아야하지? 라는 의문점을 갖으실 수 있습니다.

실제 쿠버네티스만 운영하기 위해서는 모르셔도 상관은 없습니다. 하지만 쿠버네티스는 MSA 패턴으로 나온 모델이고 이에 MSA의 고질적인 문제들도 함께 담고 있습니다.

그 고질적인 문제를 해결 하기 위해 나온 것들이 여러 있는데 그 중 하나가 서비스 메시이며, 고도화된 MSA 패턴을 운영 하기 위해서는 필수적으로 학습되어야 생각되서 길게 잡았습니다.

서비스 메시가 필요한 이유

지금까지 실습해오며 쿠버네티스 오브젝트인 서비스(service)를 대량으로 운영하지 않았습니다.

하지만 이 service들이 많이 늘어나게 된다면 이들 간에 잦은 트랜잭션 때문에 낮은 지연과 상당한 대역폭이 필요할 수도 있을 겁니다. 또한 이런 얽혀있는 상태에서 하나라도 장애가 발생 했을 경우 끝단에 있는 app이 동작 안할 수도 있고 뿐더러 추적이 어려울 수도 있습니다.

위와 같은 MSA의 고질적인 문제들을 해결하려고 나온것이 서비스 메시(Service Mess) 입니다.

서비스 메시(Service Mesh)란?

위 그림은 서비스 메시의 대표적 SW인 Istio 아키택쳐 입니다. 컨트롤 플레인을 특이한 점은 컨트롤 플레인을 둬서 Proxy를 관리 하는 구조를 갖습니다 그럼 왜 이런 구조를 가졌나 알아보겠습니다.

서비스(소프트웨어)에서 구성할 문제들을 인프라 측면에서 proxy를 사용한다면 네트워크 레이어 에서 트래픽에 대한 통제를 통하여 여러 문제를 해결할 수가 있습니다. 예를들어 앞에 서비스가 응답이 없을 때 프록시에서 이 연결을 끊어서 장애가 전파되지 않도록 하면 됩니다.

이런 Proxy들을 사용하면 기존에 가지고 있던 문제점이 해결되지만 새로운 문제점이 생깁니다.

바로 많은 Proxy들이 생겨나 관리가 어려워 이것을 해결하기 위해 서비스 메시가 등장 하였습니다. 앞서 말했듯 컨트롤 플레인을 둬서 앞서 말했던 Proxy들을 관리하는 겁니다.

서비스 메시가 할 수 있는 것

앞서 말씀 드렸던 내용은 서비스 메시가 등장한 이유와 단순히 Proxy의 관리를 편하게 한다 라고 말씀을 드렸는데 이제는 왜 써야 하는지 설명드리겠 습니다.

위 사진은 서비스 메시가 가지고 있는 능력 입니다. 데이터 플레인과 컨트롤 플레인 구조로 나눠져 있어 여러가지 기능들을 제공합니다.

이 구조를 갖는 이상 수 많은 기능들이 파생되어 나오게 되는데 이에 따른 대표적인 기능 몇가지를 알아 보겠습니다.

• 로드벨런싱 기능
• 헬스 체크 기능
• 인증 및 보안 기능
• 트리픽 매니지먼트 및 라우팅
• 서비스 디스커버리
• 신호 차단 및 장애 조치 정책 수립
• 각 Proxy 별 메트릭 측정
• 결함 주입으로 인한 신뢰성 평가 기능

쿠버네티스를 지원하는 서비스 메시 종류

---

지금 쿠버네티스 생태계는 정말 빠르게 변하고 있습니다. 이에 따라 몇 년전에 아무리 최고의 서비스 라고 생각했던 것들도 금방 확고한 모티베이션을 가지고 나온 서비스들에게 밀릴 수 밖에 없습니다.

저는 쿠버네티스 운영에 있어 이러한 것을 알아보는 것이 매우 중요하다고 생각됩니다. 지금 쿠버네티스 생태계는 사용자에 맞는 더 좋은 서비스를 골라서 쓰는 시대 이거든요.

다양한 서비스 매시 알아보는 URL : https://kubedex.com/collection/service-mesh/

서비스 메시에도 여러 종류가 나왔지만 2021년 10월 기준으로 가장 많이 사용되고 있는 서비스 2개를 설명 드릴려고 합니다. 바로 이스티오와 링커드2 입니다.

둘다 쿠버네티스 애플리케이션에 안정성, 보안 및 관찰 가능성을 추가하는 유사한 목표를 가지고 있습니다. 두 프로젝트 모두 애플리케이션 인스턴스와 함께 투명한 "사이드카 프록시"를 추가하고 이러한 프록시를 통해 기능을 제공하여 작동합니다.

아스티오와 링커드2의 성능 비교