42. service mesh & Istio

1. Service Mesh란?

Service Mesh는 마이크로서비스 간 통신이 매시 형태인 것에서 착안된, 마이크로서비스 간의 통신을 나타내는 개념입니다. 이는 여러 서비스 간의 통신을 관리하는 것을 도와줍니다. 
소프트웨어를 작은 단위로 나누어 개발하는 방식인 마이크로서비스에서는 각각의 서비스들이 서로 통신하여 기능을 수행하기 때문에 이러한 분산된 통신을 관리해 줄 도구가 필요해집니다. 

Service Mesh는 서로 다른 기능 간의 통신이 원활할 수 있도록 통신을 관리해 주고, 데이터를 안전하게 전송하고 저장할 수 있도록 해줍니다.
또한 서비스들의 동작을 계속해서 모니터링하여 이슈가 발생할 경우 알려줍니다. 

일반적으로, Service Mesh는 Kubernetes와 같은 컨테이너 오케스트레이션 환경 내에서 사이드카 형태의 프록시를 배치합니다.
그리고 이러한 프록시를 통해 트래픽 모니터링이나 트래픽 컨트롤을 수행합니다.

사이드카 형태의 프록시를 통해서 Service Mesh는 기존의 애플리케이션 코드를 수정하지 않고도 서비스 간 통신을 모니터링할 수 있고, 필요한 경우 로깅하여 시스템의 상태를 파악하고 문제를 진단할 수 있게 됩니다. 

이러한 Service Mesh를 구현하는 오픈 소스 소프트웨어로는 이스티오(Istio), 링커드(Linkerd), Kuma 등이 있습니다.
그 중 이스티오를 사용하여 이러한 Service Mesh를 구현하는 경우가 가장 많으며 아래에서 좀 더 자세히 설명하도록 하겠습니다.

• 한줄 요약 : 마이크로서비스 간의 통신(네트워크)를 담당하는 요소로서 Service Discovery, Fault Tolerance, Traffic Routing, Secruity 등의
                   통신 및 네트워크 기능을 비즈니스 로직과 분리한 네트워크 통신 인프라

 

 

1) 사이드카 형태란?
      애플리케이션 컨테이너와 독립적으로 동작하는 또 하나의 컨테이너를 붙이는 패턴을 의미합니다.
      즉, 메인 컨테이너 외 보조적인 기능을 추가하는 서브 컨테이너를 포함하는 패턴이 바로 사이드카 형태입니다. 
      애플리케이션 컨테이너(메인 컨테이너)와 독립적으로 동작하므로 사이드카 컨테이너에 장애가 발생하더라도 애플리케이션 컨테이너는 영향을 받지 않습니다. 

      또한 사이드카 컨테이너를 생성하고, 업데이트하고, 제거해야 하는 경우에도 기존 애플리케이션 컨테이너에 대한 코드는 수정을 할 필요가 없습니다. 

      Service Mesh를 구성하는 개별 프록시들은 마이크로서비스 내에서 실행되는 것이 아니라 마이크로서비스의 옆에서, 즉 사이드카 형태로 함께 실행됩니다. 

 

 

 

2. Service Mesh를 사용하는 이유는? 

마이크로 서비스는 여러 작은 서비스들로 구성되어 있기 때문에 서비스 간의 통신이 복잡합니다. 따라서 각 서비스 간의 통신을 추상화하여 더 쉽게 관리할 수 있도록 하기 위해 Service Mesh를 사용합니다.

통신을 추상화한다는 것이 정확히 무슨 뜻일까요? 추상화라는 의미 자체는 복잡한 세부 사항들 중 핵심적인 개념 또는 기능을 간추려 내는 것을 의미합니다. 

 

마이크로 서비스는 Service Mesh를 이용하여 각 서비스 간 통신을 추상화 함으로써 개별 서비스 내에 통신 관련 로직을 직접 구현하지 않게 됩니다.
또한 같은 맥락으로 서비스는 다른 서비스의 구체적인 세부 정보를 알 필요가 없어집니다. Service Mesh를 통해 통신하기 때문에 다른 서비스를 신경 쓰지 않고 자신의 로직에만 집중할 수 있게 됩니다. 

이 외에도 통신 보안이나 모니터링과 같은 기능을 Service Mesh가 제공하기 때문에 개발자가 이에 대해 직접 구현할 필요가 없어집니다.

또한 Service Mesh는 서비스들의 수가 증가하더라도 쉽게 확장할 수 있도록 구성되어 있습니다.
(ex. 사이드카 패턴) 이뿐만 아니라 로드 밸런싱, 트래픽 제어, 오류 처리 등의 기능도 함께 제공하기 때문에 서비스들의 성능과 안정성을 향상하는 역할도 합니다. 

서비스 간 통신의 모든 부분을 모니터링할 수 있기 때문에 문제를 손쉽게 인식하고 진단할 수 있으며 장애가 발생한 서비스에 대한 요청을 다시 라우팅 할 수 있도록 해주기 때문에 애플리케이션 복구 능력 역시 향상됩니다.  

Service Mesh를 사용하지 않을 경우 서비스 간의 통신을 직접 구현하거나 관리해야 하기 때문에 복잡성이 증가할 수 있습니다.
각 서비스마다 다른 방식으로 통신을 관리하게 되면 유지 보수와 디버깅, 그리고 병목 현상과 같은 네트워크 이슈에 대한 트러블 슈팅이 어려워지게 됩니다. 

따라서, Service Mesh는 복잡한 마이크로 서비스 아키텍처에서 필수적인 도구라고 할 수 있습니다. 

 사용 vs 미사용

 

3. Istio란? 

Istio는 기존 분산 애플리케이션에 투명하게 layering 되는 오픈 소스 Service Mesh입니다.
마이크로 서비스들을 보호하고, 연결하고, 모니터링하는 균일하고 효율적인 방법을 제공합니다.
서비스 코드에 대한 최소한의 변경을 통해 또는 서비스 코드 변경 없이 로드 밸런싱, 서비스 간 인증 및 모니터링을 위한 경로(path)가 됩니다. 

Istio는 Control Plane과 Data Plane 이 두 가지 요소로 구성되어 있습니다. 

먼저 Istio의 Control Plane은 TLS 암호화, ID 기반 인증 및 권한 부여를 통해 클러스터에서 서비스 간 통신을 보호합니다. 
또한 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 로드 밸런싱을 제공하고 다양한 라우팅 규칙, 재시도(retries), 장애조치(failover) 등을 통해 트래픽을 세밀하게 제어합니다. 
클러스터의 ingress 및 egress를 포함한 클러스터 내의 모든 트래픽에 대해 자동화된 메트릭, 로그 및 추적 기능도 제공합니다. 

Data Plane은 서비스 간 통신 자체를 나타냅니다.
Service Mesh는 전송되는 트래픽의 유형, 출처를 확인하기 위해 프록시를 사용하여 모든 네트워크 트래픽을 확인합니다.

 

정리하자면, 
Data Palne은 각 프록시들로 이루어져 config에 따라 트래픽을 관리하는 부분을 의미합니다. 
이 경우 서비스가 증가하게 되면 프록시 수도 증가하게 됩니다. 프록시가 증가하게 되면 당연히 관리 포인트도 증가하기 때문에 이 부분을 중앙에서 관리할 필요성이 생깁니다. 
config 값들을 저장하고 각 프록시들에게 이에 대해 전달하는 것이 Control Plane의 역할입니다.

 

Istio는 Envoy 프록시를 사용합니다. 
Envoy 프록시는 Lyft사에서 개발한 프록시로 MSA 내 각 서비스를 위해 설계된 고성능 분산 프록시입니다.
기존 L3, L4 기반의 프록시들로는 다양한 요건들을 처리하기 힘들기 때문에 MSA 환경에서는 L7 기능을 갖춘 프록시의 필요성이 대두되었습니다. 
Envoy 프록시는 L7 기반의 프록시로 HTTP, TCP, gRPC까지 다양한 프로토콜을 지원합니다. 
앞서 말한 Istio가 Service Mesh로서 제공하는 기능이 모두 Istio의 메인 프록시인 Envoy를 통해 제공된다고 보시면 됩니다. 

 

 

 

 

Istio는 마이크로서비스 아키텍처에서 서비스 간 통신을 효과적으로 관리하고, 가시성 및 보안성을 높여주는 오픈소스 서비스메쉬(Service Mesh) 플랫폼입니다. 대표적으로 Kubernetes 환경에서 많이 사용되며, 서비스 간의 데이터 흐름을 세부적으로 제어할 수 있게 해줍니다.

---

주요 특징

• 트래픽 관리:
  Canary 배포, A/B 테스트, 트래픽 분할 및 라우팅 등 다양한 트래픽 정책을 지원합니다.
• 보안:
  서비스 간 통신에 대한 인증, 권한 부여, 암호화(TLS)를 제공합니다.
• 가시성 및 모니터링:
  서비스 간 데이터 흐름, 호출 지연, 에러율, 요청 수 등 다양한 메트릭을 수집하고 외부 모니터링 툴(Prometheus 등)과의 연동이 가능합니다.
• 정책 적용:
  Rate Limiting, 인증/인가 정책, 장애 조치, 서킷 브레이커 등 다양한 정책을 쉽게 적용할 수 있습니다.

---

주요 구성 요소

 

Envoy Proxy	각 서비스 파드에 사이드카 형태로 배포되어 프록시 역할 수행
Pilot	트래픽 제어, 서비스 메시에 대한 설정 관리 및 배포
Citadel	인증서 관리 및 서비스간 보안통신 지원
Galley*	설정 검증 및 서비스와의 연동 (v1.5 이후 Istiod에 통합됨)
Istiod	Istio의 핵심 컨트롤 플레인 컴포넌트(위의 기능 통합)

---

작동 방식

1. Sidecar 프록시:
   애플리케이션 파드마다 Envoy Proxy가 사이드카 컨테이너로 함께 배포됩니다.
2. 트래픽 제어:
   모든 서비스 간 트래픽은 이 프록시를 거쳐가며, 이를 컨트롤 플레인에서 실시간으로 관리합니다.
3. 중앙정책 관리:
   네트워크 정책, 인증, 모니터링 등은 중앙에서 일괄적으로 관리 및 적용할 수 있습니다.

---

활용 사례

• 트래픽의 점진적 전달(Canary 배포 등)
• 마이크로서비스의 보안 강화 및 통신 암호화
• 장애 시 빠른 장애 감지 및 자동화된 장애 처리
• 복잡한 마이크로서비스 환경에서 네트워크 가시성 확보

---

1. 트래픽 제어 및 장애 격리

• 서킷 브레이커 (Circuit Breaker)
  • 특정 서비스의 응답 실패가 일정 횟수 이상 누적되면 자동으로 요청을 차단하여 장애가 확산되는 것을 방지합니다.
• 리트라이(Retry) 및 타임아웃(Timeout)
  • 서비스 응답이 실패하면 지정된 횟수만큼 자동 재시도를 하거나, 응답이 일정 시간 내 없으면 쿼리를 종료하여 장애 감지를 빠르게 할 수 있습니다.

2. 트래픽 분산과 장애 복구

• 로드 밸런싱(Load Balancing)
  • Istio는 Envoy Proxy를 통해 라운드로빈, 무작위, 최소 연결 수 등 여러 방법으로 요청을 분산시켜 무중단 서비스 운영을 지원합니다.
• 장애 조치(Failover) 및 헬스 체크
  • 프록시는 비정상 서비스를 자동으로 감지, 요청을 정상 인스턴스로 전달하여 장애 복구를 신속히 할 수 있습니다.

3. 트래픽 정책 적용으로 문제 전파 방지

• Rate Limiting(요청 속도 제한)
  • 이상 트래픽 발생 시 서비스 과부하를 방지하기 위해 요청 수를 제한합니다.
• Fault Injection(장애 주입)
  • 인위적으로 지연이나 오류를 발생시켜 실제 장애 상황을 시뮬레이션하고 시스템 회복력을 테스트할 수 있습니다.

4. 관찰 및 모니터링

• 분산 트레이싱(Distributed Tracing)과 메트릭 수집
  • 통신 경로, 지연, 실패율 등 주요 데이터를 수집하여, 장애나 병목 지점을 빠르게 탐지하고 대응할 수 있습니다.

5. 안전한 통신 보장

• mTLS(상호 TLS) 적용
  • 서비스 간 통신을 자동으로 암호화하여 중간자 공격이나 데이터 유출을 방지합니다.
• 정책 기반 접근 제어
  • 인증 및 권한 부여 정책을 정의해 비인가 서비스 접근을 차단합니다.

요약

Istio는 다음과 같은 기능 조합으로 MSA 환경에서 통신 안정성을 보장합니다.

서킷 브레이커, 리트라이/타임아웃	장애 확산 방지 및 자동 복구
로드 밸런싱, 장애 조치	안정적인 트래픽 분산과 장애 대응
Rate Limiting, Fault Injection	비정상 트래픽 통제 및 복원력 점검
모니터링 및 분산 트레이싱	신속한 장애 탐지 및 원인 분석
mTLS·정책기반 접근제어	안전하고 신뢰성 있는 통신 환경

 

 

 

[문제]

ABC 기업은 다양한 서비스를 Kubernetes 클러스터 환경에서 마이크로서비스 아키텍처(MSA)로 운영 중입니다. 최근 모든 서비스 트래픽을 한 곳에서 모니터링하고, 보안 정책을 통합적으로 적용하며, 장애 발생 시 자동으로 트래픽을 우회하는 능력이 필요해졌습니다. 개발팀은 각 애플리케이션의 코드 수정 없이 네트워크 트래픽의 세밀한 제어, 모니터링, 인증, 권한 부여를 일관성 있게 처리할 수 있는 ‘Service Mesh’를 도입하기로 했습니다.

도입 과정에서 아래와 같은 상황이 있었고, 개발팀은 ‘Istio Service Mesh’에서 제공하는 아키텍처와 컴포넌트별 역할에 대해 파악해야 했습니다.

시나리오

• 각 마이크로서비스 파드에 ‘특정 프록시 컨테이너’가 함께 배치되어 네트워크 트래픽이 반드시 이 프록시를 통해 전달됩니다.
• 신규 보안 정책이나 트래픽 우회 정책 적용 시, 개별 프록시가 아닌 하나의 중앙 관리 컴포넌트에서 정책 설정을 바꿔야 반영됩니다.
• 서비스 간 통신은 암호화되어 있고, 네트워크 트래픽의 세부 정보(예: HTTP 헤더, URI 등)까지 정밀하게 가시화·통제되고 있습니다.
• 대규모 트래픽 시에도 서비스 코드에 직접 트래픽 제어나 로깅 로직을 넣지 않아도 됩니다.

질문:
ABC 기업의 위 시나리오에서 사용되는 Service Mesh 및 관련 구성 요소에 관한 설명으로 가장 올바른 것을 고르시오.

A) 각 마이크로서비스에 삽입된 프록시는 Istio Control Plane에 직접적으로 모든 네트워크 트래픽을 전송하여, 중앙에서만 트래픽 제어가 이루어진다.

B) Istio의 Data Plane은 정책 정보와 트래픽 관리를 모두 책임지며, Control Plane은 프록시로서 직접 네트워크 트래픽을 우회시킨다.

C) 사이드카 프록시는 서비스 코드 내부에 탑재되어 동작하며, 서비스 확장 시 프록시 모듈을 코드에 삽입해 줘야 한다.

D) Istio의 Control Plane은 정책 및 구성 정보를 관리하며, 개별 Envoy 프록시에 이를 전달하여, 네트워크 트래픽의 실질적 흐름은 각 사이드카 Envoy 프록시에서 이루어진다.

E) Envoy 프록시는 L3(Layer 3) 기반의 네트워크 트래픽만 처리할 수 있고, HTTP 등의 L7 트래픽은 별도의 프록시가 필요하다.

 

 정답 및 해설

정답 및 해설

정답: D

해설:

• Istio의 Data Plane은 각 마이크로서비스 옆에 ‘사이드카’ 형태로 주입되는 Envoy 프록시로 구성되며, 이들이 실제 네트워크 트래픽을 처리(모니터링, 트래픽 관리 등)한다.
• Control Plane은 구성 정보(정책, 인증 등)를 중앙에서 관리·배포하며, 개별 프록시들에게 이를 전달한다.
• 프록시는 서비스 코드와 별도의 컨테이너 ‘사이드카’ 패턴으로 배치되고, 서비스 코드에는 직접 관련 로직을 넣지 않는다.
• Envoy 프록시는 L7 레벨(HTTP, gRPC 등)까지 지원한다.
• A, B, C, E는 모두 잘못된 설명이다.
  • A: 실제 트래픽은 Control Plane을 통하지 않고 Data Plane(프록시)에서 처리됨.
  • B: 정책 관리와 프록시 역할이 뒤바뀜.
  • C: 사이드카는 코드가 아닌 별도의 컨테이너임.
  • E: Envoy는 L3~L7 다 지원한다.

 

• 2. 서비스메쉬(Service Mesh)의 주요 목적은 무엇인가?
   정답 및 해설

  [정답]

  B) 마이크로서비스 간 통신 제어 및 가시성 확보

• A) 애플리케이션의 UI 설계
  B) 마이크로서비스 간 통신 제어 및 가시성 확보
  C) 데이터베이스 백업 자동화
  D) 서버 하드웨어 업그레이드

 

• 3. Istio에서 트래픽 관리, 서비스 디스커버리, 로드 밸런싱을 담당하는 프록시의 이름은?
   정답 및 해설

  [정답]

  B) Sidecar

• A) Ambassador
  B) Sidecar
  C) Kubernetes Ingress
  D) Linkerd

 

• 4. Istio에서 사용할 수 있는 네트워크 진단 및 시각화 도구는?
   정답 및 해설

  [정답]

  B) Kiali

• A) Istioctl
  B) Kiali
  C) Kubecost
  D) cAdvisor

 

• 5. Istio에서 트래픽을 버전별로 분기하는 방식 중, 새 버전으로 일부 트래픽만 보내보고 안정성 확인 후 100% 전환하는 방식은?
   정답 및 해설

  [정답]

  C) Canary Release

• A) Blue-Green Deployment
  B) A/B Testing
  C) Canary Release
  D) Rolling Update

 

• Istio Sidecar 프록시는 일반적으로 어떤 네트워크 계층에서 동작하는가?
   정답 및 해설

  [정답]

  C) 4계층(Layer 4, Transport layer) 및 7계층(Layer 7, Application layer)

• A) 2계층(Layer 2, Data link layer)
  B) 3계층(Layer 3, Network layer)
  C) 4계층(Layer 4, Transport layer) 및 7계층(Layer 7, Application layer)
  D) 1계층(Layer 1, Physical layer)

 

• 4. Istio에서 사용할 수 있는 네트워크 진단 및 시각화 도구는?
• A) Istioctl
  B) Kiali
  C) Kubecost
  D) cAdvisor