[이렇게 사용하세요!] #1 네이버 클라우드 플랫폼에서 Istio를 이용하여 Service Mesh 구현하기
안녕하세요!
네이버 클라우드 플랫폼 Tech Evangelist 송창안입니다.
오늘부터 세 편에 걸쳐 ‘네이버 클라우드 플랫폼의 ‘Istio’ 서비스를 이용하여 Service Mesh를 구현하는 과정’에 대해서 알아보도록 하겠습니다.
첫 번째 편에는 기본 개념에 대해 알아보는 시간을 가져보겠습니다. :)
그리고 두 번째 편으로 ‘네이버 클라우드 플랫폼의 Kubernetes Service와 Istio 시나리오’, 마지막 편에 실제로서 실습 데모가 예정되어 있습니다.
먼저 오늘은 기본 바탕부터 알아보도록 해요!
개념에 대한 설명 부분, 즉 마이크로 서비스 아키텍처와 서비스 매쉬, Istio 와 Envoy의 설명 부분은 조대협 님의 아래 부분을 부분 발쵀하였습니다.
Istio #1 — 마이크로 서비스와 서비스 매쉬
Istio #2 — Envoy proxy
Istio #3- Istio에 대한 소개
그러면 이제 시작하겠습니다.
Overview
- Service Mash란?
‘Istio(이스티오)’와 같은 서비스 매쉬의 개념을 이해하기 위해서는 왜 이것이 필요하게 되었는지 배경에 대한 이해가 필요합니다.
흔히 마이크로 서비스 아키텍처에서 각 서비스 단위로 잘게 나누어지면 전체 시스템이 구성되면서 점점 서비스가 많아지고
결과적으로 서비스들 간의 서비스들에 대한 연결이 복잡해지는 이슈가 발생할 수 있습니다.
서로 간의 서비스가 문제가 없는 경우에는 아래 그림과 같이 3개의 서비스가 있고 외부에서 API Call과 같은 요청이 들어오더라도 서비스가 원활히 운영됩니다.
하지만 서비스가 멈추어진 상태이거나 응답이 늦어지는 경우가 발생하는 상태, 즉 서비스를 처리하지 못하는 경우에는 각 서비스 별로 Thread가 생성되어 각각 대기 상태가 되고,
결국 시스템의 Thread가 계속 발생하면서 전체적인 서비스에 영향을 주는 현상이 일어납니다.
그래서 이런 이슈를 해결하기 위해 ‘서킷 브레이커’라는 디자인 패턴이 도입되었으며, 인프라 측면에서 외부 API Call에 대해 서비스가 응답이 없는 경우 연결을 끊어 장애가 발생하는 부분이 전체적인 서비스에 영향을 끼치지 않도록 하는 방법이 고안되었습니다.
하지만 서비스 하나 당 Proxy 서킷 브레이커를 두는 경우, 마이크로 서비스는 하나가 아닌 여러 개가 발생하게 되며 수 천 개 이상의 프록시에 대한 설정을 하려고 할 때 어려움이 발생합니다.
이런 상황에서 중앙에서 관리하는 구조가 필요하며 각 프록시에 이루어져 있는 트래픽을 설정된 값으로 지정하는 부분을 ‘데이터 플레인’이라고 합니다.
또, 프록시들의 설정값을 전달하는 컨트롤러 역할 부분이 필요하게 되는데 이것을 ‘컨트롤 플레인이라고 합니다.
서비스 매쉬는 대체적으로 앞서 설명한 구조로 구현이 됩니다.
- Envoy 란?
앞에서 설명한 서비스 매쉬에서 다양한 기능을 수행하기 위해서는 L7 계층의 지능형 라우팅에 대한 필요성이 증대되었고, Istio에 사용되는 ‘Envoy(엔보이)’도 역시 간단하게 익혀 두어야 합니다.
이것은 Layer 7 계층 프록시 기능을 지원하며 http L7 필터 레이어와 기존 프록시 L4 기능·L7 기능도 지원하면서 HTTP뿐만 아니라 HTTP 2.0, TCP, gRPC까지 다양한 프로토콜을 지원합니다.
리스너, 필터, 클러스터 이렇게 총 세 개의 구성요소로 나뉩니다.
Listener
클라이언트로부터 프로토콜을 받는 부분으로 TCP Listener, HTTP Listener 등이 있습니다.
Filter
Listener로부터 많은 메시지를 중간 처리하는 부분으로, 압축이나 들어오는 Traffic에 제한 작업 등을 한 후에 라우터를 통해서 적절한 클러스터로 메시지를 라우팅 하는 역할을 수행합니다.
Cluster
실제로 라우팅이 될 대상 서버(서비스)를 지정하게 됩니다.
- Istio 란?
엔보이만으로만 구현되는 마이크로 서비스에 대해서 서비스 매쉬 형태를 구현하기 위해서는 엔보이로 구성된 데이터 플레인을 컨트롤할 솔루션이 필요하다고 앞서 설명드렸습니다.
이스티오는 엔보이를 데이터 플레인으로 사용하고 이를 컨트롤해주는 오픈 소스 솔루션입니다.
데이터 플레인은 Envoy(엔보이) 서비스 옆에 위치해 사이드카 형식으로 배포가 되며 서비스로 들어오고 나가는 트래픽을 엔보이를 통해서 통제하게 됩니다.
또, 컨트롤 플레인은 데이터 플레인에 배포된 Envoy를 컨트롤하는 부분으로 파일럿(Pilot), 믹서(Mixer), 시타델(Citadel) 총 3개의 모듈로 구성되어 있습니다.
Pilot (파일럿)
파일럿은 Envoy에 대한 설정을 관리하는 역할을 합니다. 서비스들의 엔드 포인트(End Point) 주소를 얻을 수 있는 디스커버리 기능을 제공합니다. Istio의 유용한 기능 중 하나가 트래픽 경로를 컨트롤하는 기능인데, 서비스에서 서비스로 호출하는 경로를 컨트롤할 수 있습니다.
이외에도 서비스를 안정적으로 제공하기 위해 서비스 간 호출이 발생할 경우 재시도(Retry), 서비스 장애를 막기 위한 서킷 브레이커(Circuit Breaker), Timeout 등의 기능을 제공합니다.
Mixer (믹서)
믹서가 하는 일은 액세스 컨트롤, 정책 통제 그리고 각종 모니터링 지표의 수집입니다.
예를 들어서 서비스의 총 처리량을 정책으로 지정하여 그 처리량 이상으로 요청을 못 받게 하거나 특정 헤더 값이 일치해야 요청을 받을 수 있게 설정하는 등 다양한 정책을 정의하고 컨트롤할 수 있습니다. 또한 서비스의 응답 시간이나 평균 처리량과 같은 다양한 지표를 수집하고 저장합니다.
Citadel (시타델)
시타델은 보안에 관련된 기능을 담당하는 모듈입니다. 서비스를 사용하기 위한 사용자 인증 (Authentication)과 인가(Authorization)을 담당합니다. 또한 Istio는 통신을 TLS(SSL)을 이용하여 암호화할 수 있는데, TLS 암호화나 또는 사용자 인증에 필요한 인증서(Certification)을 관리하는 역할을 수행합니다.
오늘은 실습을 진행해보기 전에 기본부터 단단히 하는 시간을 가져보았습다.
기본 개념을 숙지하시고 난 후 2편, 3편으로 이동하시면 더 빠르게 이해가 될 거라고 생각합니다.
끝까지 읽어주셔서 감사합니다. 2편에서 찾아뵙겠습니다.
