Istio로 서비스 메쉬 아키텍처 마스터하기

1. 소개

서비스 메쉬 아키텍처의 마법을 발견하고 분산 시스템을 어떻게 슈퍼차지하는지 확인하세요.

Istio, 서비스 메쉬의 슈퍼스타에 깊이 잠수하여 Kubernetes 클러스터를 완벽하게 오케스트레이션하는 방법을 배워보세요.

2. 서비스 메쉬란?

모놀리식 애플리케이션은 더 작고 독립적인 서비스로 진화했습니다. 이 변화는 클라우드 네이티브 컴퓨팅과 마이크로서비스 아키텍처로 인해 엄청난 인기를 얻었습니다. Docker와 Kubernetes와 같은 도구는 이 트렌드를 가속화했습니다.

Kubernetes와 같은 플랫폼에서의 마이크로서비스는 많은 이점을 제공하지만 복잡성도 가져옵니다. 이러한 분산 서비스 간의 통신을 관리하려면 검색, 라우팅, 재시도 및 페일오버와 같은 요소를 신중하게 고려해야 합니다.

추가적인 과제로는 보안과 가시성이 있습니다.

이러한 프록시는 서비스에 대한 메쉬 네트워크를 형성하여 이름이 유래되었습니다. 서비스 메쉬는 서비스 간 통신의 모든 측면을 제어하여 분산 컴퓨팅의 여덟 가지 오류를 해결할 수 있습니다.

4. Istio 공개

IBM, Google, Lyft가 공동 개발한 오픈 소스 서비스 메쉬인 Istio는 트래픽 관리, 보안, 성능 인사이트로 분산된 애플리케이션을 보이지 않게 향상시킵니다.

온프레미스, 클라우드, Kubernetes, 가상 머신 등 유연하게 배포할 수 있으며, Istio는 Kubernetes에서의 마이크로서비스와 특히 잘 어울립니다. 플랫폼에 구애받지 않지만, 컨테이너화된 환경에 자연스럽게 적합합니다.

Istio의 핵심은 각 마이크로서비스 옆에 사이드카로 Envoy 프록시를 배포하는 것입니다:

이 프록시 네트워크는 Istio의 데이터 플레인을 형성하며, 컨트롤 플레인에 의해 오케스트레이션됩니다:

Istio의 적응력은 외부 로깅, 텔레메트리 및 정책 시스템과의 원활한 통합을 통해 빛을 발합니다.

5. Istio의 구성 요소 해부

Istio의 아키텍처는 데이터 플레인과 컨트롤 플레인의 역동적인 듀오입니다. 함께 Istio의 기능 뒤에 숨겨진 마법을 오케스트레이션합니다. 이제 이 뛰어난 플랫폼을 구동하는 핵심 구성 요소를 살펴보겠습니다.

Istio의 핵심 구성 요소의 세부 사항을 탐색할 준비를 하세요.

5.1. 데이터 플레인: Envoy의 중심

Istio의 데이터 플레인은 본질적으로 강화된 버전의 Envoy 프록시입니다. 이 오픈 소스 기적은 네트워크 복잡성을 처리하여 애플리케이션이 핵심 비즈니스에 집중할 수 있도록 합니다. 애플리케이션은 복잡한 네트워크 인프라를 알 필요 없이 원활하게 상호 작용합니다.

Envoy는 OSI 모델의 레이어 3과 4에서 작동하는 네트워크 마법사입니다. 유연한 네트워크 필터 체인을 사용하여 연결을 능숙하게 관리합니다. 그뿐만 아니라, Envoy의 L7 레이어 필터는 HTTP 트래픽을 능숙하게 처리할 수 있게 합니다. 그리고 이것이 전부가 아닙니다 - HTTP/2 및 gRPC 프로토콜과도 자연스럽게 어울립니다.

Istio의 뛰어난 기능 중 많은 부분은 실제로 Envoy의 내장 능력에서 물려받은 슈퍼파워입니다:

• 트래픽 제어: Envoy는 HTTP, gRPC, WebSocket 및 TCP 트래픽을 세밀하게 제어하여 정확하게 라우팅합니다.
• 네트워크 탄력성: 내장된 자동 재시도, 서킷 브레이킹 및 오류 주입으로 확고한 네트워크 신뢰성을 보장합니다.
• 보안: 강력한 보안 정책, 액세스 제어 및 속도 제한으로 통신을 보호합니다.

Envoy의 진정한 잠재력은 Istio와 함께할 때 빛납니다. WebAssembly로 구동되는 확장성은 사용자 지정 정책 시행 및 텔레메트리에 혁신을 가져옵니다. 또한 Istio의 Proxy-Wasm 샌드박스 API는 더욱 많은 Envoy 커스터마이즈에 문을 열어줍니다.

5.2. 컨트롤 플레인: Istiod의 지휘

Istio의 컨트롤 플레인 오케스트라의 지휘자인 istiod를 만나보세요. 이 마에스트로는 고수준의 라우팅 규칙과 트래픽 관리 지침을 Envoy 친화적인 구성으로 변환하여 사이드카에 원활하게 배포합니다.

Istio의 이전 아키텍처에서의 개별 구성 요소를 기억하시나요? 간단히 하기 위해 이러한 구성 요소는 통합된 istiod로 합쳐졌습니다. 하지만 걱정 마세요, 핵심 기능은 그대로입니다.

핵심은 istiod가 이전 구성 요소와 동일한 코드와 API를 활용한다는 것입니다. 예를 들어 Pilot은 사이드카가 이해할 수 있는 보편적인 언어로 플랫폼별 세부 정보를 변환하여 서비스 검색의 지휘자로 계속 활동합니다. 이 유연성은 Istio가 Kubernetes나 가상 머신과 같은 다양한 환경과 조화를 이루게 합니다.

istiod는 또한 보안을 담당하여 Istio의 상호 TLS 솔루션을 사용하여 강력한 서비스 간 및 최종 사용자 인증을 설정합니다. 서비스 ID 기반으로 세분화된 보안 정책을 쉽게 시행할 수 있습니다. 또한 istiod는 신뢰할 수 있는 인증 기관(CA)으로 작동하여 서비스 간의 통신을 상호 TLS(MTLS)를 사용하여 보호하기 위해 인증서를 발급합니다.

6. Istio의 작동 원리

분산 마이크로서비스 아키텍처의 일반적인 문제를 관리하는 서비스를 살펴보았고 Istio의 아키텍처와 핵심 구성 요소를 해부했습니다. 이제 Istio가 이러한 기능을 핵심 구성 요소를 사용하여 어떻게 제공하는지 알아보겠습니다.

앞서 살펴본 동일한 기능 범주를 다시 방문하겠습니다.

6.1. 트래픽 관리

Istio의 트래픽 관리 API는 서비스 메쉬 트래픽에 대한 세밀한 제어를 제공합니다. 이러한 API를 사용하여 트래픽 구성을 조정하고 Kubernetes 사용자 정의 리소스 정의(CRD)로 API 리소스를 정의합니다. 트래픽 라우팅을 위한 핵심 API 리소스는 가상 서비스와 대상 규칙입니다:

가상 서비스는 Istio 메쉬 내의 서비스로의 요청이 어떻게 라우팅되는지를 지정합니다. 하나 이상의 라우팅 규칙으로 구성되며 순차적으로 평가됩니다. 가상 서비스 라우팅 후에 대상 규칙이 적용되어 대상에 대한 트래픽을 제어합니다. 예를 들어 서비스 인스턴스를 버전별로 그룹화합니다.

6.2. 보안

Istio의 보안 기초는 모든 서비스에 대한 강력한 ID입니다. Envoy 프록시와 함께 각 서비스에 있는 Istio 에이전트는 istiod와 협력하여 키 및 인증서 회전을 자동화합니다:

Istio는 두 가지 인증 유형을 지원합니다: 피어 인증과 요청 인증. 피어 인증은 Istio의 상호 TLS 솔루션으로 서비스 간 통신을 보호합니다. 요청 인증은 사용자 정의 인증 제공자나 OpenID Connect(OIDC) 제공자를 사용하여 JSON 웹 토큰(JWT) 검증을 통해 최종 사용자 인증을 처리합니다.

Istio는 권한 부여 정책을 적용하여 서비스 액세스 제어를 시행합니다. 이러한 정책은 메쉬, 네임스페이스 및 서비스 수준에서 인바운드 트래픽을 규제하여 액세스 제어를 제공합니다.

6.3. 가시성

Istio는 메쉬 내의 모든 서비스 통신에 대해 포괄적인 텔레메트리를 생성합니다. 여기에는 메트릭, 분산 추적 및 액세스 로그가 포함됩니다. 이 텔레메트리는 프록시 수준, 서비스 지향 및 컨트롤 플레인 메트릭을 포함합니다.

이전에 Mixer는 Istio의 텔레메트리 아키텍처의 중심 구성 요소였습니다. 그러나 Telemetry v2는 Envoy 프록시 플러그인으로 Mixer's 기능을 대체합니다:

Istio는 Envoy 프록시를 통해 분산 추적을 생성하고 Zipkin, Jaeger, Lightstep, Datadog과 같은 다양한 추적 백엔드를 지원합니다. 추적 생성 샘플링 비율은 구성 가능합니다. 또한 Istio는 서비스 트래픽에 대한 액세스 로그를 사용자 정의 가능한 형식으로 생성합니다.

7. Istio 체험하기

배경은 충분하니, 이제 Istio를 실제로 사용해 봅시다! Kubernetes 클러스터에 Istio를 설치하고 간단한 마이크로서비스 앱을 사용하여 그 강력함을 보여주겠습니다.

7.1 설치

Istio는 다양한 방법으로 설치할 수 있지만, 최신 릴리스를 OS(예: Windows)에 맞게 다운로드하고 압축을 푸는 것이 가장 쉽습니다. 추출된 패키지에는 bin 폴더에 istioctl 클라이언트가 포함되어 있습니다. istioctl을 사용하여 Kubernetes 클러스터에 Istio를 설치하세요:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

여기서는 kubectl을 사용하고 있으며, Kubernetes 클러스터(예: Minikube)와 Kubernetes CLI kubectl이 설정되어 있다고 가정합니다.

7.2 샘플 애플리케이션

이 데모를 위해 간단한 온라인 주문 앱을 상상해보세요. 주문을 처리하기 위해 함께 작업하는 세 개의 마이크로서비스로 구성됩니다:

마이크로서비스의 세부 사항에 깊이 들어가지 않겠지만, Spring Boot와 REST API로 쉽게 만들 수 있습니다. 중요한 것은 이러한 마이크로서비스에 대한 Docker 이미지를 만들어 Kubernetes에 배포하는 것입니다.

7.3 배포

컨테이너화된 워크로드를 Kubernetes 클러스터(예: Minikube)에 배포하는 것은 간단합니다. Deployment 및 Service 리소스를 사용하여 워크로드를 선언하고 액세스합니다. 일반적으로 YAML 파일에 이를 정의합니다:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

기본 네임스페이스에 대한 Envoy 사이드카 프록시의 자동 주입을 활성화했으므로 모든 것이 처리됩니다. 또는 istioctl의 kube-inject 명령을 사용하여 수동으로 Envoy 사이드카 프록시를 주입할 수 있습니다.

7.4 애플리케이션 액세스

Istio는 주로 메쉬 트래픽을 처리합니다. 기본적으로 메쉬 외부로의 트래픽은 차단됩니다. Istio는 게이트웨이를 사용하여 메쉬로의 인바운드 및 아웃바운드 트래픽을 관리하여 무엇이 들어오고 나가는지 정확하게 제어할 수 있습니다. Istio는 사전 구성된 게이트웨이 프록시 배포인 istio-ingressgateway와 istio-egressgateway를 제공합니다.

앱을 위해 게이트웨이와 가상 서비스를 만드세요:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 일반적인 Istio 사용 사례

Kubernetes에 간단한 앱을 Istio로 배포했습니다. 이제 Istio의 강력한 기능을 탐색하고 애플리케이션을 어떻게 향상시킬 수 있는지 알아보겠습니다.

8.1 요청 라우팅

shipping-service와 같은 마이크로서비스의 여러 버전을 배포한다고 가정해보세요. 모든 사용자에게 영향을 주지 않고 새로운 기능을 점진적으로 도입하고 싶습니다. 요청 라우팅을 통해 최신 버전으로의 트래픽 일부를 전달할 수 있습니다.

이를 위해 가상 서비스 라우팅 규칙을 사용하세요.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

라우팅 규칙은 헤더나 다른 속성을 기반으로 트래픽을 필터링할 수도 있습니다. destination 필드는 일치하는 요청의 대상 서비스를 지정합니다.

8.2 서킷 브레이킹

연쇄적인 실패를 방지하려면 서킷 브레이커를 사용하세요. 이 패턴은 오류를 감지하고 실패한 서비스로의 트래픽을 일시적으로 중지하여 애플리케이션의 전체적인 건강을 보호합니다.

Istio의 DestinationRule을 사용하여 inventory-service에 대한 서킷 브레이킹 동작을 구성하세요.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

최대 연결 수, 대기 중인 요청 수 및 연결당 요청 수를 제한하여 효과적으로 트래픽을 관리하고 과부하를 방지할 수 있습니다.

8.3 상호 TLS 활성화

상호 TLS는 양쪽 모두가 인증을 요구하여 서비스 간 통신을 보호합니다. Istio는 서비스에 대한 사이드카 프록시를 사용하는 서비스를 위해 자동으로 상호 TLS를 활성화합니다.

Istio는 프록시된 서비스 간의 상호 TLS를 시행하지만, 프록시가 없는 서비스로의 평문 텍스트 트래픽은 여전히 도달할 수 있습니다. PeerAuthentication 정책을 사용하여 전체 메쉬에 대해 상호 TLS를 시행하세요.

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

메쉬, 네임스페이스 또는 서비스 수준에서 상호 TLS를 적용할 수 있습니다. 서비스별 정책은 네임스페이스 전반의 설정을 재정의합니다.

8.4 JWT를 통한 액세스 제어

JSON 웹 토큰(JWT)은 사용자 정보를 안전하게 전송하기 위한 표준입니다. 인증 및 권한 부여에 널리 사용됩니다.

Istio의 AuthorizationPolicy를 사용하여 booking-service에 대한 액세스를 JWT 클레임에 기반하여 제어하세요.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

특정 클레임을 가진 유효한 JWT를 요구하여 허가된 액세스를 제공합니다. Istio는 JWT의 발급자와 주체 클레임에서 requestPrincipal 속성을 생성합니다.

9. 최종 생각

Istio는 분산 마이크로서비스 아키텍처의 일반적인 문제를 손쉽게 해결해줍니다. 하지만 그 복잡성은 배포에 추가적인 부담을 줄 수 있습니다. 모든 도구가 그렇듯이, Istio도 만능 열쇠가 아니므로 신중한 판단이 필요합니다.

9.1. 서비스 메쉬가 항상 필요한가요?

서비스 메쉬는 이점을 제공하지만, 다음과 같은 단점을 고려하세요:

서비스 메쉬는 이점을 제공하지만, 애플리케이션의 복잡성을 신중하게 평가하는 것이 중요합니다. 이점과 추가된 복잡성을 비교하세요.

9.2. Istio 대안

업계 리더들의 지원으로 인기를 끌고 있는 서비스 메쉬, Istio. 그러나 선택지는 그것뿐만이 아닙니다. 이제 Linkerd와 Consul의 흥미로운 대안을 소개합니다.

Linkerd Linkerd는 Kubernetes에 최적화된 오픈 소스 서비스 메쉬로, 최근 주목받고 있습니다. CNCF 인큐베이팅 프로젝트인 Linkerd는 TCP 프록시를 활용하여 Istio와 유사한 방식으로 작동합니다. Rust로 개발된 Linkerd의 마이크로 프록시는 Linkerd-proxy라고 불립니다.

Kubernetes에 집중한 Linkerd는 일반적으로 Istio보다 더 단순하고 직관적입니다. 하지만 기능은 Istio와 밀접하게 닮았으며, 핵심 아키텍처도 유사합니다. Linkerd는 사용자 인터페이스, 데이터 플레인, 컨트롤 플레인으로 구성되어 있습니다.

Consul Consul은 HashiCorp의 오픈 소스 서비스 메쉬로, 다양한 HashiCorp 인프라 도구와의 통합이 특징입니다. Consul의 데이터 플레인은 프록시와 네이티브 통합 모델을 모두 지원하며, 내장된 프록시를 제공하지만 Envoy와도 호환됩니다.

Consul은 Kubernetes를 넘어 Nomad와 같은 다양한 플랫폼을 지원합니다. 각 노드에서 에이전트를 활용하여 상태 확인을 수행하고, 데이터 저장 및 복제를 위해 Consul 서버와 소통합니다. 표준 서비스 메쉬 기능을 제공하지만, 배포와 관리 측면에서 Consul은 더 복잡할 수 있습니다.

10. 마무리

이번 튜토리얼에서는 서비스 메쉬 아키텍처의 기본과 Istio의 강력한 기능을 탐색했습니다. Istio의 핵심 구조, 구성 요소 및 실용적인 응용에 대해 깊이 살펴보았습니다. 이로써 Istio를 설치하고 일반적인 시나리오에서 활용하는 방법을 잘 이해하셨을 것입니다.