[마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA를 위한 기술 - Service Mesh와 Istio

< Service Mesh와 Istio >

 

Service Mesh

service mesh

• Service
  • Microservices의 Service를 말한다
• Mesh
  • 그물망
  • (톱니바퀴 따위가) 딱 맞물리다
• 모든 Microservice의 Service간의 관계망이 Mesh처럼 연결되어 있다는 의미로 만들어진 단어이다
• Service 간의 네트워크 연결망에 초점을 둔 개념이다
• SW를 배포하는 클러스터와 함께 위치하는 추가적인 Layer
• MSA에서 서비스 간 통신을 관리/제어/모니터링하는 SW Infrastructure Layer

 

• Service Mesh Layer는 Pod 간의 통신을 중재하는 역할을 한다
• 모든 컨테이너(Pod)간의 통신이 Service Mesh Layer를 통해서 한다

 

• 모든 통신들을 Proxy를 통해서 하는 방식이 Service Mesh이다
• 또한 이 Proxy들을 관리하는 Master Node들이 추가적으로 존재한다
• 실제 Service Mesh의 핵심은 Proxy라고 할 수 있다

 

 

 

Service Mesh 특징

• Continer 및 Container Orchestration을 도입하면 많은 장점이 있다
• 대용량 클러스터의 Application 배포/운영에 대한 표준/자동화 된 방법을 제공한다
• 배포 및 클러스터 관리의 운영 Cost를 획기적으로 낮춘다
  • 다수의 Application에 대한 배포 작업
  • 수백 수천 개의 Container의 관리
• MSA의 핵심 중 하나는 Inter Service Communication이다
  • Inter Service Communication이 관리에 대한 표준적인 방법이 필요하다
  • Inter Service Communication에 대한 자동화된 제어가 필요하다
  • K8s는 기능을 제공하지 않는다
• 서비스 간 통신 관리에 필요한 요소들은 다음과 같다
  • Service Discovery
  • Local Balancing
  • Timeout
  • Retry
  • Routing
  • Curcuit Breaking
  • Metrics and Monitoring
  • 그러나 K8s는 위의 요소들을 제공하지 않는다
• 물론 Service Mesh가 제공하는 것들은 이전에 없던 패턴/기능들은 아니다
  • Service Discovery
    • Netflix Eureka
    • HashiCorp Consul
    • DNS
    • SOA UDDI
  • Circuit Breaking
    • Netflix Hystrix
  • Load Balancing
    • Load Balancer - L4, L7 LB
    • Cloud LB - ELB, ALB
    • Netflix Zuul
    • Spring Cloud Gateway
  • Routing
    • nginx
  • Timout/Retry
    • RestClient
    • Application Logic
  • Mertic and Monitoring
    • Spring Cloud Sleuth
    • Twitter Zlpkin
    • Spring Boot Actuator
    • Elastic Stack
• 서비스 간 통신 관리를 위한 기존의 방법들이 있다
  • Netflix OSS, Spring Cloud
• Code 레벨로 작성한다
  • circuit breaking 로직을 변경하면 코드 수정 후 재배포한다
• Language Dependent
  • 대부분의 훌륭한 라이브러리들이 Java/Spring 기반으로만 개발/공개되어 있다
  • 따라서 다른 언어로 개발하는 경우 기존의 방법들을 이용하기가 힘들다

 

 

 

* Neflix와 Spring

• MSA를 잘 개발/운영하기 위한 기능들을 Netflix에서 개발하였다
• Java 기반의 코드들을 오픈소스로 공개하였다
• 그 중 몇가지 프로젝트를 Spring Cloud와 통합하였다
• Java/Spring 기반 라이브러리
  • Spring Cloud Netflix Eureka
  • Spring Cloud Config
  • Spring Cloud Netflix Hystrix
  • Spring Cloud Netflix Zuul
  • Spring Cloud Netflix Ribbon
  • Spring Cloud Stream
  • Spring Cloud Sleuth
  • Spring Cloud Sidecar
  • Spring Cloud Consul
  • Spring Cloud Gateway

 

 

 

다시 Service Mesh로 돌아와서..!

• Java/Spring 기반이 아닌 프로젝트를 진행중이라면?
  • 위의 제공하는 기능들을 사용할 수 있는 방법이 재개발 외에는 다른 대안이 없었다
• 이를 위한 해결책은?
  • Application 레벨이 아닌 Infrastructure 레벨로 구현해보자!
  • => Service Mesh
• Application Code와 완전히 분리한 게층이다
• Language/Framework Independent

 

 

 

Istio

Istio의 핵심 기능

• Service Mesh를 구현하는 방법은 다양하다
  • Istio
  • Linkerd
  • Long
  • Conduit
  • AWS App Mesh
• Istio는 Service Mesh 구현체 중 하나이다
• Google, IBM, Lyft 등이 개발에 참여하였다
  • Google이 참여했기 때문에 쿠버네티스와 함께 사용하기 좋다
• Application Code를 거의, 전혀 수정하지 않고 다양한 기능을 추가할 수 있다
  • Load Balancing
  • Traffic Control – routing rule, failover, retry
  • Policy layer for access control, rate limit, quotas
  • Automatic Metrics, Logs, Traces
  • Service to service authentication and authorization
• Istio의 핵심 기능
  1. Traffic Management
  2. Obersvability
  3. Policies
  4. Security

 

 

 

Istoi Architecture

• 위의 구조는 Istio 버전에 따라 약간씩 상이하다
• Master Node와 일반 Node로 구분되는 k8s처럼, Istion 또한 Data Plane과 Control Plane으로 구분된다
• Data Plane
  • Node에서 Pod들이 위치하는 곳
• Control Plane
  • Data Plane을 제어하고 관리하는 영역
  • 여기에 있는 여러가지 컴포넌트를 통해 Proxy와 통신하며 Communication을 감시/관리한다

 

 

 

Envoy

• Lyft에서 개발하였고 오픈소스로 공개하였다
• 서비스 간 통신 Proxy 기능을 담당한다
• Istion의 핵심이 되는 모듈
• Istio 핵심 기능 중 대부분을 지원한다
  • Traffic Management
  • Telemetry
• 모든 서비스 간 호출은 Envoy Proxy를 통한다
• Sidecar container로 모든 Pod에 배포되고, 이는 Envoy에 의해 자동으로 주입된다
• Envoy는 K8s와는 독립적인 오픈소스 프로젝트이다
• K8s는 Envoy를 사용하는 하나의 환경 중 하나이다
• 다양한 기업/플랫폼에서 활용 중이다

 

 

 

Envoy 기능

• High Performance Server
  • nginx, haproxy
• Advanced Load Balancing
  • Client-Side Load Balancing
  • Automatic Retrying
  • Circuit Breaking
  • Rate Limiting
• Observability
  • Distributed Tracing
  • Metrics Gathering

 

 

 

Istio vs Envoy

Istio 없는 Envoy 설정

• Istio말고 Envoy만 사용하면 안되나?
• Envoy는 Low Level Tool이다
• 잘 사용하기 위해서는 고난이도의 설정 작업이 필요하다
• Istio = Envpy + Envoy를 쉽고 잘 사용하게 도와주는 여러 환경들이다
• Istio는 Envoy를 쉽게 사용할 수 있게 한다
• Istio + Kubernets 조합은 더욱 쉽게 사용이 가능하다
• Kubernetes CRD - Custom Resource Definition
• Kubernetes 리소스 yaml 파일을 사용하는 것과 동일한 인터페이스로 사용이 가능하다

 

 

 

Control Plane

• Envoy를 관리/제어하는 도구들의 모임

 

 

 

Galley

• Kubernetes manifest 파일을 Istio가 이해할 수 있는 구조로 변환하는 모듈이다
• Istio는 Kubernetes와 독립적인 기술이다
• 그러나, Istio와 Kubernetes와 가장 잘 통합되어 있다
• Istio는 HashiCorp Consul 등 과도 통합이 가능하다

 

 

 

Pilot

• 설정 정보를 Envoy Proxy가 이해할 수 있는 형태로 변환한다
• 설정 정보를 변환하여 Envoy Proxy 들에게 전파한다
• Envoy의 복잡한 설정에 대해서 사용자는 알 필요가 없어진다

 

 

 

Citadel

• TLS 인증서 관리의 역할
• 전체 클러스터에 TLS/SSL을 적용할 수 있다
• 클러스터 내부의 정책을 통일한다

 

 

 

Mixer

• 2개의 역할을 갖고 있다
  
  • Policy Check
  • Telemetry
  • 장기적으로 분리될 가능성이 존재한다
• Telemetry
  • Proxy에서의 다양한 지표를 수집
  • 통신에 시간이 얼마나 걸렸는지 등의 통계 정보 수집
• Policy Check
  • Rate Limiting – 특정 서비스에서는 초당 1건의 call로 제한
  • 서비스 호출에 대한 White List, Black List 설
• 다양한 백엔드를 연동할 수 있는 Adoper를 제공한다
• 수집되는 통계 지표들을 다른 백엔드와 연동한다
• Datadog, Promeheus, Zipkin 등과 연동이 가능하다

 

 

 

Traffic Management

• 서비스 간의 traffic, API call을 제어
• 하위 기능
  • circuit breaking
  • timeout
  • retry
  • percentage based traffic split
  • contents based traffic split

 

• 버전 별로 배포 후에 Percentage로 Traffic을 조정한다

 

• 컨텐츠 기반의 트래픽 분할
• HTTP 헤더 등의 컨텐츠에 따라 라우팅한다

 

 

 

Client Resilience

• 원격 자원의 장애에 대해 클라이언트를 보호하는 패턴이다
• Client-Side Load Balancing
  • 여러 개의 Proxy가 있을 때 Load Balancing을 Client 측에서 한다
  • 즉, 호출하는 Clinet가 여러 개의 Pod 중 누굴 선택할지 고르는 것이다
• Client-Side Health Checking
  • 주기적으로 호출해서 호출 당하는 Pod들이 정상인지 확인한다
• Retrying, Timeout, CircuitBreaking

 

 

 

보안

• 통신 보안
• Envoy Proxy를 통한 모든 통신은 TLS로 암호화된다
• 서비스 간 인증
  • 서비스간 인증은 인증서를 이용하여 양방향 TLS (Mutual TLS) 인증을 이용하여, 서비스가 서로를 식별하고 인증한다
• 서비스와 사용자 간의 인증
  • 사용자 클라이언트를 인증할 수 있는 기능
  • JWT 토큰을 이용해서 서비스에 접근할 수 있는 클라이언트를 인증

 

 

 

모니터링

• Envoy 간의 다양한 지표를 측정 후 수집한다 - Mixer
• Micer는 다양한 Logging을 Backend와 연동이 가능하다