MSA 관리를 위한 Service Mesh : ISTIO - 1

Service Mesh란 무엇일까?

- Service mesh 개요

Service mesh라는 용어는 microservice를 구현할 때 service에 해당되는 application에 대한 구조, 그들간의 네트워크를 이야기할 때 항상 등장한다. 이 Service mesh는 각 커뮤니티에서 원하는 요구에 따라 정의가 바뀌는데, 이 모든 이야기 중의 공통점은 서비스의 크기와 복잡성이 올라감에 따라 관리가 어려워 진다는 것이다.

Service mesh를 이루는 요소로는 service discovery, load balancing, failure recovery, metrics, monitoring 등의 도구와 좀 더 복잡해진 운영 프로세스인 A/B testing, canary releases, rate limiting, access control 그리고 end-to-end authentication 등이 있다.

* 본 글에서는 이 service mesh의 종류 중, 구글이 주도적으로 개발하고 가장 활발한 커뮤니티를 가지고 있는 오픈소스 Istio에 대한 이야기를 해보겠다.

- Service mesh(Istio) 특징

• Traffic Management. 각 서비스간 트래픽 및 API 호출을 제어하고 호출을 보다 안정적으로 만들며 네트워크 구간의 효율화를 극대화한다.
• 
  
• Observability. 서비스와 서비스 간의 종속성을 관리하며 트래픽 간의 특성 및 흐름을 파악하여 이슈를 신속하게 파악할 수 있다.
• 
  
• Policy Enforcement.  서비스 간 상호 작용에 대해 access, role 등의 정책을 설정하여 리소스가 각 서비스에게 공정하게 분배되도록 제어한다. 이 정책 변경에 대한 부분은 application 소스를 직접 수정하는 것이 아니라 mesh로 제어가 된다.
• 
  
• Service Identity and Security. 유일한 값인 ID를 각 mesh에 매핑시켜 서비스를 보호하고 신뢰성을 유지하여 서비스 트래픽의 안정성을 높인다.
• 
  

• Platform Support. Istio는 Cloud, On-premise, Kubernetes, Mesos 등 다양한 기반 환경에서 실행할 수 있도록 설계되었다. 현재는 Kubernetes에 중점을 두고 있지만, 곧 다른 환경을 지원하기 위해 커뮤니티가 진행되고 있다.
• 
  
• Integration and Customization. 정책 집행이 가능한 영역을 확장하기 위하여 mesh의 연결에 대한 부분을 커스터마이징하여 ACLs, Logging, Monitoring, quotas, auditing 등의 기존 솔루션과 통합할 수 있다.
• 
  

위와 같은 기능들은 Application의 코드, 기존의 플랫폼 및 정책과 결합을 보다 쉽게 만들어준다. 이 것은 전체 서비스 구현을 용이하게 할 뿐만 아니라 운영자가 서비스에 대한 배치 및 관리를 더 쉽게 행할 수 있게 해준다. 결과적으로 service mesh가 적용 된 Application은 본질적으로 이식성이 높아진다.

- 트래픽이란?

한 가지를 짚고가자면, 기존 Infra 영역에서 사용하던 traffic이라는 용어가 service mesh 영역으로 들어오면서 좀 더 깊어졌다. 단순 request 기반 네트워크 통신 패킷만이 아닌 각 서비스를 호출하는 end to end client를 관리할 수 있게 되었다. 예를 들어 Istio의 Pilot을 이용하여 특정 서비스에 대한 트래픽의 5%를 카나리아 배포로 보내거나 A/B testing 같이 요청 내용에 따라 특정 버전으로 트래픽을 보내도록 지정할 수 있다.

Istio란 무엇일까?

- Istio Details

Istio service mesh는 논리적으로 Data Plane과 Control Plane으로 나뉜다.

Data Plane은 Microservice 사이의 모든 네트워크 통신을 조정하고 제어하는 Kubernetes의 Application pod에 사이드카 컨테이너로 배치 된 Envoy 프록시로 구성된다.

Control Plane은 Pilot, Mixer, Istio-Auth로 구성되어 런타임에 정책을 시행 할뿐만 아니라 트래픽을 라우팅하기 위해 프록시를 관리 및 구성한다.

다음 다이어그램은 각 Plane을 구성하는 다양한 모듈을 보여준다.

- Istio 구성 요소

Envoy

Envoy는 C++로 개발된 고성능 프록시 사이드카로서 service mesh의 모든 서비스에 대한 inbound/outbound 트래픽을 처리한다. Envoy에는 dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers, health checks, %-based traffic split, fault injection 그리고 rich metrics 등의 기능을 포함한다.

Envoy는 동일한 Kubernetes pod의 Application 서비스에 사이드카로 배치된다. 이를 통해 Istio는 트래픽 동작에 대한 데이터를 attribute으로 추출 할 수 있고 Mixer에서 정책을 관리하는데 사용할 수 있으며, 모니터링 시스템(Prometheus, Grafana 등)에 보내져 전체 mesh의 동작에 대한 정보를 관리할 수 있다.

Mixer

Mixer는 service mesh 전체 영역에서 액세스 제어 및 사용 정책을 정의하고 Envoy 프록시 및 기타 서비스에서 데이터를 원격에서 수집하는 독립 모듈이다. Envoy는 request level attribute를 추출하여 평가를 위해 Mixer로 데이터를 보낸다.

Pilot

Pilot은 Envoy 사이드카에 대한 서비스 검색, 지능형 라우팅 (예 : A/B 테스트, Canary 배치 등) 및 Resiliency (timeout, retries, circuit breakers 등)을 위한 트래픽 관리 기능을 제공한다. 특정 트래픽 정책을 Envoy 사이드카 컨테이너로 전달하여 라우팅 규칙들을 적용시켜준다. Pilot은 플랫폼에 종속되지 않고 Envoy Data Plane을 준수하는 모든 사이드카에 표준 포멧으로 통합시킨다.

Istio-Auth

Istio-Auth는 mesh를 관리하기 위한 ID 및 서비스 authentication을 위해 TLS를 사용한 service-to-service enduser 인증을 제공한다. 이는 service mesh에서 암호화되지 않은 트래픽을 전송하는 데 사용할 수 있으며 운영자는 네트워크 컨트롤 대신 service ID를 기반으로 정책을 시행 할 수 있다.

* 마지막으로 아래 보이는 비교 그림은 기존 Netflix OSS 기반의 Microservice 관리와 Kubernetes와 Service mesh를 이용한 Microservice 관리가 어떻게 다른지 보여주는 예시이다. Netflix 계열 OSS를 사용하기 위해선 동작을 위한 Application 소스를 사용해야만 했는데, 이젠 소스코드 관리나 기존 정책을 바꿀 필요가 없어졌다. 

그야말로 차세대 MSA 관리를 위한 플랫폼이라고 할 수 있다.

다음 글에선 Service Mesh의 실제 설치 후 어떻게 각종 정책을 동작하는지에 대해 알아볼 것이다.