[DevOps] Istio: Circuit Breaker를 지원하는 Service Mesh의 구현체

Microservice

Microservice architecture 스타일은 작은 서비스들의 모음으로서 단일 애플리케이션을 개발하기 위한 접근 방식입니다. 각각의 애플리케이션은 자체 프로세스로 실행되며 http로 통신하게 됩니다. 이와 같이 mircroservice architecture 스타일은 다양한 언어를 지원할 수 있게 되고(polyglot) 배포 주기를 독립적으로 가져갈 수 있게 되고 각각의 서비스들이 독립적으로 존재하기 때문에 다른 서비스에 영향을 최소화할 수 있습니다. 하지만 모든 기술에 장점만 있는 것이 아니듯, 네트워크 보안에 더욱 신경을 써야 하고, 서비스들 간의 복잡도로 인해서 트러블 슈팅이 매우 어려워지게 됩니다. 또한 서비스 간의 access control 역시 쉬운 일이 아니죠.

 

또 만약 장애가 발생한다면 어떨까요? 앞서 monolithic architecture 스타일과 달리 mircrosevice는 독립적인 서비스들로 구성되어 있기 때문에 다른 서비스에 영향을 최소화 한다고 이야기했습니다. 하지만 실제로도 그럴까요? 대부분의 service들은 다른 service들에 의존성으로 묶여있고 전체 서비스 중 일부에 장애가 발생한다면 그와 관련된 다른 서비스들까지도 장애가 전파되게 됩니다. 그래서 흔히 MSA를 Death Star Architecture라고 이야기하곤 합니다. 이와 같이 microservice architecture style 역시 운영에 있어서 복잡도가 증가하게 되었습니다. 또 다른 문제의 시작이었죠.

Amazon과 Netflix MSA

Hystrix

하지만 개발자들은 또 다시 답을 찾아갑니다. Netflix에서 분산 환경을 위한 Hystrix 라이브러리를 개발합니다. Hystrix란 Latency and Fault Tolerance Sytem(지연 내성과 장애 내성을 갖춘 시스템)으로서 microservice에서 필수적으로 발생하는 의존성이 있는 서비스 간 발생 가능한 연속 장애 발생을 차단하는 circuit breaker를 도입합니다.

Netflix/Hystrix

circuit breaker란 쉽게 말해 일부 서비스에서 장애가 발생 했을 경우 의존성이 있는 서비스로 장애가 전파되지 않도록 차단하는 기술을 이야기합니다. Netflix의 Hystrix는 이를 사용하기 쉽게 구현해 뒀으며, mircroservice의 문제점을 해소하는 듯 보였습니다. 자바 진영에선 말이죠.

맞습니다. Hystrix는 Java 진영의 기술이기 때문에 다른 언어에서는 사용할 수 없다는 문제점이 있습니다. Java로 이루어진 애플리케이션에서는 문제가 없지만 polyglot이 적용된 microservice 전체에는 해당하지 않는 기술이죠.

 

개발자들은 또 다시 생각합니다. 언어에 종속적이지 않으며, microservice의 장점을 죽이지 않으며, 유기적으로 촘촘하게 엮여있는 service들을 관리할 수 있는 방법이 없을까?라고 말이죠.

 

이때 나온 개념이 바로 Service Mesh입니다. Service Mesh란 애플리케이션들이 데이터를 공유하는 방식을 제어하는 방법으로 애플리케이션에 구축된 인프라 계층입니다. 

 

Istio

Istio는 오픈소스로 공개되어 있는 가장 많이 사용하는 Service Mesh의 구현체 중 하나로, microservice의 많은 문제점들을 해결해줍니다. kubernetes 환경에서 business logic이 담긴 application과 하나의 pod로 묶여서 배포가 가능하며, application의 sidecar 역할을 하게 됩니다.

 

Istio는 몇 가지 특징을 가지고 있는데 그중 가장 중요한 특성 중 하나는 모든 microservice 앞단에서 proxy 역할을 하는 Envoy Proxy입니다. Envoy Proxy는 고성능 프락시로서 모든 microservice 앞단에서 트래픽을 가장 먼저 받는 역할을 하게 되는데, 이때 Hystrix의 Circuit Breakers 뿐 만아니라 dynamic service discovery, load balancing TLS termination, Health checks, Staged rollouts 등 다양한 역할을 수행하게 됩니다. traffic에 관한 다양한 metric을 수집할 수 있어서 prometheus와 grafana와 같은 모니터링 툴을 이용하여 각 서비스 간의 trafiic 흐름과 응답 시간과 같은 다양한 데이터를 수집할 수 있습니다.

 

Fine-grained traffic controls

Istio는 트래픽 흐름을 분리하고 A/B Test를 위한 동적 요청 라우팅이나 카나리 배포, 롤 아웃 등 다양한 트래픽 관리 기능을 제공합니다.

 

Fault recovery out of the box

microservice가 운영중에 가장 critical 한 문제점 중 하나는 network 문제입니다. 하나의 서비스에서 response가 너무 늦게 오는 경우 서비스 전체에 응답 지연이 발생하게 될 뿐 아니라 다른 network connection이 이루어지지 않게 되는 등 연쇄적인 문제가 발생합니다. 이를 방지하기 위해 Istio에서는 네트워크 문제가 발생했을 경우 Timeout, Retry rule이나 위에서 언급했던 circuit breakers와 같은 기능을 설정할 수 있습니다.

 

Fault injection tools

Istio에 아무리 많은 recovery 기능들이 있더라도 service mesh의 회복력을 테스트하는 것은 매우 중요한 역할입니다. Istio에는 Fault injection을 의도적으로 흘려 delay와 abort faults를 측정할 수 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata: ...
spec:
    http:
    - fault:
    	delay:
            percentage:
            	value: 0.1
            fixedDelay: 5s
    	abort:
       	    percentage:
            	value: 0.1
            httpStatus: 400
      route:
      - destination:
      	    host: ratings.prod.svc.cluster.lacal
            subset: v1

 

Easy Authentication, Encrytion

microservice는 service-to-service와 user-to-service와 같은 다양한 통신이 존재합니다. Istio에서는 손쉽게 mTLS(Mutual transport layer security)을 구현할 수 있습니다.

 

Authorization

Isio는 mesh에서 workload에 대한 access control를 제공합니다. 관리자는 Istio의 권한을 세부 화할 수 있습니다. 만약 User로부터 proxy에 request가 도착한다면, 권한 부여 엔진은 요청 콘텍스트를 평가하고 ALLOW 또는 DENY 중 하나를 return 하게 됩니다.

 

Observability

Istio는 proxy에서 traffic에 대한 metric을 생성하고 prometheus와 grafana와 같은 monitoring 툴을 이용해서 시각화 할 수 있습니다. 크게는 api 전체의 응답 시간부터 method의 호출시간까지 측정이 가능합니다. 이러한 기능은 장애 탐지에 유용하게 사용됩니다.

 

 

Default Metrics