[다.인.서] Dive into Service Mesh | Service Mesh의 구성 요소와 동작 과정

개요

서비스 기업 채용 공고에서 쉽게 보이는 우대사항들이 있다.

대용량 트래픽 처리 경험, 서비스 메시, 무중단 배포 등등

실제 서비스를 다루면서 배우면 좋겠지만, 그 경험도 쉽게 얻을 수 있는 경험은 아니다.

하지만 나에겐 인터넷과 책이라는 세상의 선배가 있으니 간접 경험을 해보고자 (+ 약점 극복)

이 시리즈를 작성하게 되었다.

목표

Service Mesh는 Interface의 구현체만 있으면 동일한 동작을 수행할 수 있다.

따라서 구성 요소는 내부 구현에 따라 다르지만 동작은 동일하다.

오늘은 대표적으로 사용되는 Istio를 기준으로 Service Mesh가 어떻게 구성되고 동작하는지 알아보도록 하자.

(이 글은 도서 이스티오 첫걸음을 참고하여 작성하였습니다.)

---

여정

Service Mesh의 구성요소

Service Mesh는 일반적으로 Control Plane과 Data Plane으로 나뉜다.

(일부에서는 인프라 시스템에 따라 관리 플레인이 존재하기도 한다.)

 

Calico를 개발한 Tigera에서 그린 Service Mesh의 간략한 구성도

 

 

Control Plane은 다음과 같은 역할을 수행한다.

• Service Mesh가 어떻게 동작할 지에 관한 정책 및 구성을 제공
• Service Proxy를 위한 단일 관리 지점으로, 네트워크 패킷을 건드리지 않고 동작
• 인증서 발급 및 교체, 네트워크 경계 및 접근 방법, 라우팅 구성 등의 기능을 담당

Data Plane은 다음과 같은 역할을 수행한다.

• 상태 확인, 라우팅, Load Balancing, 인증, 권한 부여, 관측 가능성 기능을 담당
• iptables 규칙을 통해 요청된 네트워크 패킷을 가로채고 Service Proxy로 전달
• Application은 Data Plane의 존재를 알 수 없음.

 

각각의 Plane들은 여러 컴포넌트를 두어 그 역할을 분리하여 동작한다.

이 컴포넌트들은 Service Mesh 구현체마다 다르다.

 

우리는 가장 널리 사용되는 Service Mesh인 Istio를 기준으로 살펴보려고 한다.

먼저 Control Plane부터 차근차근 살펴보자!

Istio Architecture

 

• Control Plane 구성 요소 
  • 파일럿(Pilot) : 트래픽 관리 역할
    • Service Discovery 기능 제공 → Data Plane 내 Service Proxy들에게 트래픽 규칙과 구성 변경을 알려줌
    • Data Plane의 Service 실행 상태 추적, 동기화 → 재시도, 서킷 브레이커, 타임아웃 등을 세밀한 구성 가능
  • 갤리(Galley) : 설정 검증 및 전달 역할
    • Istio의 설정을 검증하고 다른 컴포넌트로 설정 데이터를 전달함.
  • 시타델(Citadel) : 인증 및 권한 부여 역할
    • Service to Service, Service to End-User에 대해 mTLS(상호 전송 계층 보안)을 사용해 인증 기능을 제공.
    • 시타델 에이전트가 보낸 CSR(인증서 서명 요청)을 승인 및 서명할 수 있음.
    • 키 및 인증서 생성, 배포, 교체할 수 있음.
  • 믹서(Mixer) : 모니터링 지표 수집 역할 → Deprecated ( Pilot과 Envoy Proxy에 통합됨 )

• Data Plane 구성 요소
  • 데이터 플레인은 기존 어플리케이션에 Sidecar를 주입함으로써 동작.
    • 즉, 기존 코드를 다시 디자인하거나 작성할 필요 없이 기능을 추가 할 수 있음.
    • 또한, 어플리케이션들은 Sidecar의 존재를 인식할 수 없다!
  • Service Proxy (Envoy)
    • 프록시 간의 통신으로 실제 서비스 메시를 형성.
    • 기본 설정은 Envoy Proxy이며, 사용자 정의 Proxy도 사용 가능.
    • Service Discovery, Load Balancing, TLS 처리, 프로토콜 프록싱, Circuit Breaker, Health Check, Metric 제공, 백분율 기반 트래픽 분할 등 다양한 기능을 보유.
    • 어플리케이션에 붙는 Sidecar 외에도 Mesh로 들어오고 나가는 트래픽에 대해서 Gateway 역할을 수행한다. (= Ingress Gateway, Egress Gateway도 Service Proxy로 구성되어 있다.)

---

Istio 동작 프로세스

• Sidecar 주입
  • 모든 워크로드에 Sidecar를 주입하여 Traffic을 Gateway로 일원화한다.
  • Kubernetes에서 Sidecar 주입은 MutatingWebHook을 이용하여 동작한다.
  • 특정 Namespace에 istio-injection=enable 레이블이 있다면 해당 Namespace 내Pod들에게 Sidecar를 주입한다. (istioctl의 kube-inject명령을 통해 수동으로도 주입할 수 있다!)
• 모든 워크로드에 ID 발급
  • 모든 워크로드에 ID를 발급하여 주체를 식별한다.
  • 접근 제어 시스템인 Citadel은 주체가 객체에 관해 작업을 수행할 수 있는가? 를 묻는다.
    • 다음과 같이 생각하면 이해하기 쉽다.
      • 주체 = 사용자
      • 객체 = 데이터, 이미지, URL 등
      • 작업 = 읽기, 쓰기, 실행, 삭제 등
    • 이는 Service Mesh의 경계를 형성한다는 뜻으로 이해할 수 있다.
  • Citadel Node Agent는 각 Node에 배포되어 새 워크로드가 스케줄링될 때 API를 사용해 CSR을 Citadel로 보낸다.
    • Citadel Node Agent는 자체로 검증은 지원하지 않고 워크로드 대신 인증서를 요청하거나 탐색할 수 있도록 CA 서비스에 연결하는 어댑터 역할을 한다.
    • Citadel을 대신하여 각 Node에 배포되어 동작하는 구조는 수 많은 워크로드에 대응할 수 있는 이점을 제공한다.
  • Citadel은 이에 응답하여 특정 호스트나 네트워크 ID가 아니라 워크로드에 ID를 발급한다.
    • 이는 네트워크에 종속적이지 않고 토폴로지 변경에도 안정적으로 서비스 간 통신에 대해 정책을 수행할 수 있게 한다.
    • 이 때, SPIFFE(Secure Production Identity Framework for Everyone) 사양을 사용하여 ID를 발급하게 된다.
      • 수명이 짧은 X.509 SVID 인증서를 발행 (주로 1시간 단위 만료)
      • 서비스를 설명하는 URI로 소유자 대체이름(SAN, Subject Alternative Name)을 사용
        • 이 때, 소유자 대체 이름은 Istio가 실행되는 플랫폼에서 지정해준다.
        • Kubernetes의 경우 Pod의 Service Account가 소유자 대체 이름이 된다.
        • 예를 들어, Namespace가 test이고 Service Account가 default의 경우spiffe://cluster.local/ns/test/sa/default로 ID가 인코딩된다.
• Service Registry 생성 및 트래픽 제어
  • Pilot Service Registry를 형성하고 서비스 메시 환경 및 배포 상태 모델을 만든다.
    • 메시 구성 + 네트워킹 구성 + 서비스 발견
  • 서비스 프록시 인스턴스가 클러스터에 배포된다.
  • 파일럿이 서비스 프록시를 그룹화하여 xDS(Discovery Service) 응답을 생성한다.
  • 서비스 프록시가 연결되면 파일럿은 현재 상태와 환경을 반영한 응답을 전송한다.

---

Q & A

• Service Mesh를 잘 사용하려면 어떤 성과 지표(KPI)를 봐야할까요?

널리 사용되는 지표는 크게 3가지 이다.

• USE : 사용률(Utilization), 포화도(Saturation), 오류(Error)
• RED : 속도(Rate), 오류(Error), 기간(Duration)
• 4 Golden-Signals (Google에서 사용하는 4가지 황금 신호 지표)
  • 응답속도(Latency) : 사용자 요청에 응답하는 소요 시간
  • 트래픽(Traffic) : 서비스 사용량 (예. HTTP requests per second)
  • 장애(Errors) : 단순 에러 이 외 내부 응답 목표 시간인 10초 이상 지연된 요청을 포함한 전체 장애 건수
  • 포화도(Saturation) : 트래픽 증가 혹은 노드 장애 등의 상황 시 예비 노드에서 처리 가능한 시스템 자원 사용률

공통적으로 요청, 대기 시간 및 오류를 선정하고 있는 것을 눈 여겨볼 만 하다.

---

마무리

오늘은 Service Mesh의 구성요소와 동작과정에 대해 알아보았다.

다음 시간에는 Service Mesh를 실제 어떻게 사용할 수 있을지 코드를 통해 알아볼 것이다.

실제 Kubernetes에서 사용할 수 있는 YAML 예시와 함께 다양한 상황을 고민해보도록 하자.

---

참고자료

Istio / Architecture 

Do you really need a service mesh? (tigera.io)