서비스 메시 아키텍처 (Istio/Linkerd)

Source: Dev.to

그래, 마이크로‑서비스 혁명을 받아들였군요! 축하합니다! 모놀리스를 독립적으로 배포 가능한 서비스들의 눈부신 배열로 분해했으며, 각각은 고유한 전문 목적을 가지고 있습니다. 독립적인 구성 요소들의 아름다운 교향곡이죠, 맞나요? 음… 어쩌면 그렇지 않을 수도 있습니다.

마이크로‑서비스가 늘어남에 따라 몇 가지… 이상 현상을 눈치채게 될 겁니다:

• 서비스들이 서로를 찾기 힘들어함
• 요청이 신비롭게 타임아웃됨
• 디버깅이 분산 로그의 미로가 됨
• 보안이 요새에 얇은 자물쇠 같은 느낌

친구들, 여기서 Service Mesh의 마법이 등장해 하루와 여러분의 정신을 구합니다.

Service Mesh = 마이크로‑서비스 오케스트라를 지휘하는 보이지 않는 지휘자.
이것은 애플리케이션 코드를 다시 쓰는 것이 아니라 서비스 간 통신을 처리하는 전용 인프라 레이어를 추가하는 것입니다.

서비스 메시가 해결하는 근본적인 과제들

마치 작은 레고 블록(마이크로서비스)들이 서로 소통하여 멋진 성을 만들고자 하는 상황을 상상해 보세요.

이러한 기능들을 각각의 마이크로서비스에 직접 구현하려 하면 코드 중복, 구현 일관성 부족, 그리고 개발 악몽에 빠지게 됩니다. 바로 여기서 서비스 메시가 빛을 발합니다.

서비스 메시 아키텍처

주요 기능 (“컨덕터”가 제공하는 것)

1. 트래픽 관리 (A/B 테스트, 카나리 릴리스, 롤백)

Istio 예시 – VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

이 설정은 Istio에게 my-app의 v1 서브셋으로 트래픽의 90 %를, v2 서브셋으로 10 %를 보내도록 지시합니다.

Linkerd 예시 – ServiceProfile + TrafficSplit

# TrafficSplit 리소스 (Linkerd 버전에 따라 약간 차이가 있을 수 있음)
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: my-app-traffic
spec:
  service: my-app          # Kubernetes Service 이름
  backends:
    - service: my-app-v1   # v1에 해당하는 기본 Service
      weight: 900
    - service: my-app-v2   # v2에 해당하는 기본 Service
      weight: 100

Linkerd는 ServiceProfile(라우트 메타데이터용)과 TrafficSplit을 결합하여 유사한 가중 라우팅을 구현합니다.

2. 가시성 (메트릭, 분산 추적, 액세스 로그)

• 메트릭 – 요청 지연 시간, 성공/실패 비율, 요청량 등.
• 분산 추적 – 단일 요청이 여러 서비스에 걸쳐 어떻게 흐르는지 추적 (Jaeger, Zipkin 등).
• 액세스 로그 – 모든 서비스 간 통신에 대한 중앙 집중식·표준화된 로그.

Linkerd 예시 – 메트릭 보기

Linkerd는 대시보드에 기본 제공되는 서비스 메트릭 시각화 기능을 포함하고 있습니다. 동일한 데이터를 Prometheus를 통해 직접 조회할 수도 있습니다.

3. 복원력 (재시도, 타임아웃, 서킷 브레이킹, 헬스 체크)

Istio 예시 – 재시도 및 타임아웃 설정

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-retry
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: gateway-error,connect-failure,refused-stream
      timeout: 5s

(위 스니펫은 최대 3번 재시도하고, 각 시도당 2초 타임아웃을 적용하며, 전체 요청 타임아웃을 5초로 설정합니다.)

TL;DR – 서비스 메시를 사용하는 이유는?

VirtualService 예시

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app
    retries:
      attempts: 3
      timeout: 10s

마이크로서비스 보안

서비스 메시는 다음을 제공함으로써 보안을 단순화합니다:

• Mutual TLS (mTLS) – 서비스 간 통신을 암호화하고 클라이언트와 서버 모두의 신원을 검증합니다.
• Authorization Policies – 세밀한 접근 제어 규칙을 정의하여 어떤 서비스가 서로 통신할 수 있는지 지정합니다.

Istio Example (enabling mTLS)

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

이 정책은 default 네임스페이스 내 모든 통신에 대해 엄격한 mTLS를 적용합니다.

Istio vs. Linkerd

두 프로젝트 모두 동일한 문제를 해결하려고 하지만, 약간 다른 접근 방식을 취합니다.

Istio

Google, IBM, Lyft가 만든 성숙하고 기능이 풍부한 서비스 메시로, 데이터 플레인으로 Envoy를 사용합니다.

장점

• 광범위한 기능 – 고급 트래픽 관리, 보안 정책, 장애 주입, 분산 추적 등.
• 강력한 정책 적용 – 라우팅, 보안, 가시성을 위한 세밀한 정책 제공.
• 큰 생태계 통합 – 다른 CNCF 프로젝트 및 클라우드‑네이티브 도구와 잘 연동.
• 성숙하고 널리 채택 – 큰 커뮤니티와 강력한 채택 기반.

단점

• 복잡성 – 학습 곡선이 가파르고, 작은 팀이나 단순한 사용 사례에선 운영 부담이 큼.
• 리소스 집약적 – Linkerd에 비해 CPU와 메모리 사용량이 높음.
• 큰 발자국 – 컨트롤 플레인 구성 요소가 더 무거움.

Linkerd

Buoyant가 개발한 경량 메시로, 단순성, 성능, 사용 편의성에 중점을 둡니다.

장점

• 단순함 및 사용 편의성 – 설치·설정·운영이 빠르고 쉬워, 초보자에게 적합.
• 성능 및 효율성 – 낮은 지연 시간과 최소 리소스 사용을 제공하는 고성능 Rust 프록시 사용.
• 핵심 기능 집중 – 사용자를 압도하지 않는 필수 메시 기능 제공.
• 우수한 즉시 사용 가능한 가시성 – 다듬어진 대시보드 포함.

단점

• 고급 기능 부족 – 매우 복잡한 트래픽 라우팅이나 세밀한 권한 부여 시나리오에선 한계가 있을 수 있음.
• 작은 기능 세트 – 모든 가능한 기능을 원한다면 Istio가 더 적합할 수 있음.

서비스 메시 시작하기

전제 조건

• 컨테이너 오케스트레이션 플랫폼 – 대부분의 메시는 Kubernetes 위에서 실행되므로 작동하는 클러스터가 필요합니다.
• 애플리케이션 아키텍처 이해 – 어떤 서비스가 서로 통신하는지, 어떻게 배포되는지 파악하세요.
• 기본 Kubernetes 지식 – Deployments, Services, Namespaces, 그리고 kubectl에 익숙해야 합니다.
• 정신적 안정을 위한 욕구 – 선택 사항이지만 도움이 됩니다!

설치 개요

두 메시는 설치를 위한 CLI 도구를 제공합니다.

Istio (간소화)

# Download the Istio CLI
curl -L https://istio.io/downloadIstio | sh -

# Navigate to the downloaded directory
cd istio-*

# Install Istio with a profile (e.g., 'default' or 'demo')
bin/istioctl install --set profile=demo

Linkerd (간소화)

# Download the Linkerd CLI
curl -sL https://linkerd.io/install | sh

# Install Linkerd
linkerd install | kubectl apply -f -

네임스페이스에 메시 적용하기

• Istio – 네임스페이스에 라벨을 지정합니다:

  kubectl label namespace default istio-injection=enabled

• Linkerd – 네임스페이스를 인젝션 정책에 추가합니다 (예시 명령):

  linkerd inject --enable-per-pod-explicit-annot

Istio와 Linkerd 선택하기

다음 경우 Istio를 선택하세요:

• 복잡한 트래픽 관리, 보안 및 가시성을 위한 포괄적인 고급 기능이 필요할 때.
• 복잡한 통신 패턴을 가진 대규모 분산 시스템을 운영할 때.
• 보다 복잡한 시스템을 다룰 수 있는 팀이 있을 때.
• 쿠버네티스 생태계에 크게 투자했으며 깊은 통합을 원할 때.

다음 경우 Linkerd를 선택하세요:

• 간단하고 성능이 뛰어나며 운영이 쉬운 서비스 메시를 원할 때.
• 서비스 메시에 처음이며 부드러운 입문을 선호할 때.
• 신뢰할 수 있는 통신, 기본 트래픽 제어 및 좋은 가시성을 우선시할 때.
• 높은 자원 효율성을 요구할 때.

최종 생각

마이크로서비스 아키텍처는 엄청난 유연성과 확장성을 제공하지만, 서비스 간 통신 관리에 대한 도전 과제도 동반합니다. Istio와 Linkerd 같은 서비스 메시는 단순한 유행어가 아니라, 분산 시스템의 혼란을 정리해 주는 강력한 솔루션입니다. 이들은 다음을 제공합니다:

• 지능형 트래픽 관리
• 강력한 보안 (예: mTLS, 권한 정책)
• 깊은 가시성

서비스 메시를 도입하면 네트워크 복잡성에 얽매이지 않고 비즈니스 로직 구축에 집중할 수 있습니다. 기능이 풍부한 Istio의 파워든, Linkerd의 우아한 단순함이든 선택하든, 보다 탄력적이고 안전하며 관리하기 쉬운 마이크로서비스 애플리케이션을 구축하는 중요한 발걸음을 내딛는 것입니다.

앞으로 나아가 마이크로서비스 사육장을 길들여 보세요—당신의 지휘자가 기다리고 있습니다!