서비스 메시 핵심 아키텍처: Istio·Linkerd 데이터 플레인

💡 핵심 요약 (Executive Summary)

본 가이드는 serviceMesh 핵심 가이드 및 실전 아키텍처의 핵심 개념, 실전 구성 명령어 및 아키텍처 베스트 프랙티스를 다룹니다. 클라우드 네이티브 및 인프라 엔지니어링 실무에 즉시 활용 가능하도록 체계적으로 정리했습니다.

📑 Table of Contents
서비스 메시 개요
서비스메시를 사용하는 이유 요약
  1. API게이트웨이는 외부에서 서비스로의 요청에 초점, 서비스메시는 인프라내 애플리케이션 간 통신에 초점
  2. 가시성: 로그, 메트릭, 트레이싱을 기본적으로 제공함.
  3. 트래픽 관리: Config변경시 실시간으로 반영 (Header변경, L7라우팅 등)
  4. 보안: mTLS(Mutual TLS) 설정을 간편하게 할 수 있어서 Policy 설정을 통하여 어플리케이션 코드변경 없이 보안을 강화할 수 있음
  5. 계층: 애플리케이션 완전히 분리된 채로 구동되는 레이어이므로 서비스메시변경, 애플리케이션 추가, 보안설정 변경 등에 있어서 고려할 점이 줄어듦
잘 알려진 솔루션들 비교 with GPT4

Istio (CNCF, Apache License 2.0)

  • 특징: Istio는 가장 널리 사용되는 서비스 메시 중 하나로, 풍부한 기능 세트를 제공해. Envoy 프록시를 사용하여 트래픽을 관리하며, 트래픽 라우팅, 정책 설정, 서비스 간의 보안 통신, 관찰 가능성 등을 포함한 광범위한 기능을 제공해.
  • 장점: 강력한 트래픽 관리 기능, 포괄적인 보안 기능, 높은 확장성.
  • 단점: 비교적 복잡한 설정과 러닝 커브, 리소스 사용량이 많을 수 있음.

Linkerd (CNCF, Apache License 2.0)

  • 특징: Linkerd는 성능과 단순성에 중점을 둔 경량의 서비스 메시 솔루션으로, Go와 Rust로 작성되었어. Istio에 비해 설치와 사용이 간단하며, 자동화된 mTLS(상호 TLS 인증), 트래픽 분할, 관찰 가능성 등의 기능을 제공해.
  • 장점: 설치와 사용이 간단하며 리소스 사용량이 적음, 빠른 성능.
  • 단점: Istio에 비해 기능이 다소 제한적일 수 있음.

Consul (HashiCorp, Mozilla Public License 2.0)

  • 특징: Consul은 HashiCorp에 의해 개발된 멀티 플랫폼 서비스 메시 솔루션으로, 서비스 발견과 구성을 위한 도구로 시작했어. 서비스 메시 기능 외에도, 서비스 발견, 헬스 체크, 키/값 저장소, 멀티 데이터센터 지원 등 다양한 기능을 제공해.
  • 장점: 넓은 기능 범위, 멀티 데이터센터 지원, 다양한 플랫폼과의 통합.
  • 단점: 다른 옵션에 비해 사용과 관리가 복잡할 수 있음, 서비스 메시 기능이 다른 도구에 비해 상대적으로 덜 강조됨.
서비스 메시와 API Gateway 무엇이 다른가요?
  • 적용되는 위치

API Gateway는 중앙 집중식 제어 영역으로 외부에서 들어오는 트래픽에 대한 제어를 담당합니다.

(외부망과 내부망 사이)

서비스 메시는 애플리케이션 기능을 인프라 계층에 의해 관리되는 마이크로 서비스로 분리하는 방법입니다.

서비스 메시는 서비스 내부의 통신에 대한 제어를 담당합니다.

(내부망 Kubernetes 클러스터)

  • 아키텍처

API Gateway가 중앙집중형 아키텍처여서 SPOF(Single Point of Failure)을 생성한다면 서비스 메시는 분산형 아키텍처를 취하기 때문에 SPOF를 생성하지 않고 확장이 용이합니다.

  • 패턴

API Gateway는 일반적으로 Gateway proxy pattern을 사용합니다.

Consumuer(호출자)는 구현 내용을 알 필요 없이 Gateway를 호출하는 방법만 알면 Gateway가 알아서 수행하는 방식입니다.

Service Mesh는 일반적으로 Sidecar proxy pattern을 사용합니다.

Consumuer(호출자)의 코드에는 Provider(공급자)의 주소를 찾는 방법, failover와 관련된 코드 등의 내용이 들어가게 됩니다. 다만 호출자의 코드는 애플리케이션 코드에 내장되는 것이 아니라 sidecar 형태로 별도로 관리됩니다.

API게이트웨이와 서비스 메시를 함께 사용하면 서비스 메시 아키텍처의 중재자 역할을 할 수 있습니다.

따라서 보안과 속도가 좋아집니다.

주요 항목 서비스 메시 API Gateway
목적 내부 엔터프라이즈 시스템 및 마이크로 서비스 내의 이식성을 개선하도록 설계 내부/외부 및 심지어 데이터베이스 엑세스 위한 API 호출까지도 라우팅 할 수 있도록 설계
동작방법 내부 엔터프라이즈 서비스 범위 내에서 운영 회사 외부에 있는 애플리케이션에서의 연계를 위한 라우팅을 지원
API 역할 API는 규모에 맞는 서비스 메시를 보호하는 데 사용 API 게이트웨이는 API를 관리하고 보호하는 데 사용
디지털 트랜스포메이션 마이크로 서비스를 관리하여 제공 시간을 단축하지만 보안 문제가 발생할 수 있음 특히 서비스 메시와 함께 사용할 경우 출시 시간을 단축하고 보안을 보장
복잡성 엔드포인트가 비즈니스에 따라 확장됨에 따라 복잡성 가중 엔드포인트를 쉽게 관리하고 API를 확장하여 서비스 메시를 관리
기술 성숙도 신기술 성숙한 기술
보안 수동 프로세스에 의한 보안 정책 적용 자동화된 보안 정책 및 기능

위의 표를 보면 서비스 메시의 단점들을 API Gateway가 보완해주는 것 같습니다.

그리고 API Gateway 입장에서는 서비스 메시는 디테일을 관리하는 것 같습니다.

참고자료

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *