iamminji
commented
2 years ago Service Mesh
MSA 아키텍쳐에서 하나의 마이크로서비스가 다른 마이크로서비스로 요청할 때 다양한 챌린지가 생겼다.
- Timeout
- Circuit Breaker
- Retry
- Encryption
- Authentication & Authorization
- Metrics
- Logs
다양한 Service Mesh implementation
Istio, Linkerd, Kuma, AWS App Mesh 등등이 있다. 체감상 Istio 와 Linkerd 가 가장 유명한 솔루션인 것 같다. 둘 중 어떤 것을 선택할 것인지는...(이런 글도 있다. https://www.infracloud.io/blogs/service-mesh-comparison-istio-vs-linkerd/)
Service Mesh Features
-
Routing Complex routing for A/B testing & Canary releasing
-
Resilience Retry, Circuit Breaker
-
Security Authorization, Authentication
-
Observability
Istio
Istio 가 왜 생겼나?
마이크로 서비스 아키텍쳐가 생겨나면서 여러가지 시스템 디자인 패턴들이 생겨났다. 그 중에 하나가 바로 장애 전파에 관한 것으로 흔히들 서킷 브레이커와 같은 이름으로 서비스의 장애 전파를 막는 패턴을 사용하고 있다. 그러나 해당 기술은 주로 소프트웨어 단에서 구현되어져있고 이는 러닝커브가 상당하다. (공부할게 너무 많아진다!)
그래서 (이를 자동화했으면 좋겠다는 의견이 나왔고) 해당 기술이 소프트웨어 단이 아닌 인프라단으로 오게 되었다.
Envoy
일반적인 프록시이다. (HaProxy나 Nginx 같은 프록시이다.) 근데 되게 똑똑한 프록시이다. L4 뿐만 아니라 L7 단 프록시도 제공을 해서 들어오는 트래픽 양을 조절하거나, 인증 받은 트래픽, HTTP2, gRPC, WebSocket, 서킷브레이커 등등 지원한다.
Envoy 를 이용해 문제를 해결할 수 있지만 진짜로, 제대로 MSA 문제를 해결하려면 Envoy가 진짜 많아야 한다. 그래서 중앙 컨트롤이 가능한 솔루션에 대한 니즈가 나왔고 이게 바로 Istio 이다.
Istio
Istio 프레임워크는 어플리케이션 옆에 프록시가 항상 같이 배포 하는 방식이다. 사이드카 형식으로 Envoy가 항상 붙어 있는 것이다. (Envoy가 어플리케이션 앞에서 컨트롤 해줌, 프록시이기 때문에)
Istio 의 구성은 다음과 같다.
Pilot
provides service discovery for Envoy sidecar, 똑똑한 트래픽 라우팅 (A/B 테스트, 카나리 배포 등), fault tolerance(timeout, retries, circuit breaker) 을 제공한다. (프록시에 대한 configuration 을 담당한다.)
Mixer
정책 확인, 로그 수집 등을 담당한다. 서비스 트래픽을 받을 때 초당 얼마나 받는지, 나를 호출할 수 있는 서비스의 종류가 무엇인지 등에 대한 정책을 확인한다.
Citadel
보안 관련을 담당한다. 이스티오는 양방향 (들어오는, 나가는) 통신을 모두 SSL 통신하는데 그걸 담당한다.
결론
그래서! 코딩 없이! 프록시가 있기 때문에 트래픽 비율을 서비스 별로 제어할 수 있게 해주는게 이스티오이다. Istio 를 잘 몰랐을 때, API Gateway 를 쓰면 되는데 왜 써야 하나 싶었는데 (정확히는 Service mesh) 트래픽 조절과 서비스 간 강력한 (??) 보안 기능 때문에 쓰는 듯