Istio는 애플리케이션 네트워크 기능을 유연하고 쉽게 자동화할 수 있는 투명한 언어 독립적 방법을 제공하는 현대화된 서비스 네트워킹 레이어인 서비스 메시입니다.
구글 클라우드에선 이렇게 얘기하지만 간단하게 말하면
분산형 MSA(Micro Service Architecture)기반의 앱을 어디서나 실행할 수 있도록 지원하는 오픈소스 서비스 메시
이다.
그렇다면 서비스 메시라는 건 또 뭘까??
애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법
특히 App의 트래픽을 관리, 추적하고 보안성을 강화하기 위해서 플랫폼 레이어에 구성되는 네트워크를 제어하는 방법이다.
Istio 서비스 메시를 활용하면
- 일관된 서비스 네트워킹의 운영
- Istio 이점을 통한 서비스의 보호
- 애플리케이션의 성능 향상
이 3가지의 효과를 얻을 수 있다.
쿠버네티스 각각의 Pod안에 Istio의 경우 메인 프록시인 Envoy proxy container를 띄워서 필요한 로직들과 함께 배포하는 방식을 사용한다.
이를 Sidecar Pattern이라고 해서 이 proxy container들을 Pod안에 삽입을 하는데 이걸 Sidecar Injection이라고 한다.
모양을 보면 독립적으로 동작하는 별도의 컨테이너를 붙이는 형태라서 그런듯 하다!
이런 식으로 애플리케이션과 독립적으로 작동하기 때문에 사이드카에 문제가 발생하거나 적용 및 변경, 제거 시에 애플리케이션엔 수정이 필요가 없어 매우 좋다.
또한 서비스 메시를 활용하면 기존 서비스 메시가 없이 개발하는 환경에서는 서비스 간 커뮤니케이션을 통제하는 로직으로 코딩을 직접 해야해서 비즈니스 로직을 제대로 집중하지 못하게 되지만 서비스 메시를 통해서 성능 메트릭을 통해서 관리하기가 훨씬 수월해지게 된다.
흔히 배웠던 API Gateway랑의 차이점을 생각해보면 좋은데 API Gateway의 경우 중앙 집중 제어라서 외부의 트래픽 제어를 담당하는 반면에 이 서비스 메시의 경우 내부 트래픽 제어를 담당한다고 간단히 생각하면 된다.
API Gateway의 경우 일반적으로 Gateway proxy pattern을 사용하고 이는 Consumer가 구현 내용을 모르고 Gateway를 호출하는 법을 알면 Gateway가 알아서 수행하는 방식이고
Service Mesh의 경우 위에서 언급했던 Sidecar proxy pattern이기에 Consumer의 코드에 Provider의 주소찾는법, Failover와 관련된 코드의 내용이 들어가 App코드에 내장되는 것이 아닌 Sidecar로 별도로 관리가 된다.
좋은 정보 감사합니다