[이렇게 사용하세요!] #2 네이버 클라우드 플랫폼에서 Istio를 이용하여 Service Mesh 구현하기

안녕하세요, 저번 포스팅에서는 Istio와 관련된 개념을 배워보았습니다.

오늘은 네이버 클라우드 플랫폼의 Kubernetes Service와 Istio 시나리오에 대해 이어서 말씀드리겠습니다.

네이버 클라우드 플랫폼의 Kubernetes Service와 Istio 시나리오

저번 1편에서 설명드렸던 개념인 ‘이스티오’와 네이버 클라우드 플랫폼 Kubernetes Service의 연동을 통해 사용자들은 어떤 것을 할 수 있을까요?

지금부터 시나리오를 설명해드리겠습니다. Istio의 기능에 대해서 체험을 하기 위해 여러 가지 Sample 프로젝트에 코드를 구현해 두었으며 아래 예제를 통해 사용자들은 자신의 서비스에 맞게 디자인하고 구성을 가늠해볼 수 있습니다. 제공한 프로젝트 중 Bookinfo Application을 데모로 활용하도록 하겠습니다.

1. Bookinfo Application

Istio의 구조에서 컨트롤 플레인과 데이터 플레인이 각각 나누어져 있습니다.

Istio Data Plan에는 총 6개의 서비스가 구성되어 있으며, 각각의 서비스에는 엔보이가 사이드카 형태로 옆에 있습니다.

유저는 처음에 Book Page라는 곳에 접근하게 되며, 현재 정책을 적용한 적이 없기 때문에 요청 때는 순차적으로 페이지를 확인할 수 있습니다.

​흐름을 눈으로 보기 위해 ‘Kiali(키알리)’라는 GUI 도구를 사용해보았습니다.

이 도구를 활용하면, 사용자가 웹 페이지 호출할 시 위와 같은 그림이 보입니다.​

이것은 예제를 통해 확인하는 방법을 보여드릴 예정이며, 그림과 같이 순차적으로 페이지에 대한 순서가 보이는 것을 확인할 수 있습니다. 현재 그림에서는 회색 표시만 보이게 되지만 실제적으로 호출된 부분은 녹색으로 표시되며 이를 통해 호출 순서를 알 수 있습니다.

2. 카나리아 테스트를 위한 ’50 / 50' 분배혹은 로드 밸런싱

라우팅 툴을 통해 사용자가 Bookpage에 접근하면 Review-v1 페이지 50%와 Review-v2 페이지를 50%씩 접근이 가능하도록 구성하여 용이하게 설계할 수 있습니다.

이 기능을 통해 카나리아 테스트와 같은 사용자 일부(5% 정도)를 새로운 릴리즈 버전으로 서비스하여 이상이 없는지 확인(테스트) 한 후 전체(100%)로 확대하는 배포 방식을 선택적으로 구현할 수 있습니다.

지금은 50:50으로 나누어지는 그림으로 보이지는 않으며 아래 사진과 같이 현재의 흐름만 파악할 수 있습니다.

​3. V2를 ‘Jason’이라는 유저에게만 제공하기

이 배포방식은 특정한 유저에 대해서도 적용할 수 있습니다. Envoy가 L7 계층의 지능형 라우팅으로 기능해서 User에 대한 필터링이 가능하기 때문입니다. 사용자 추가 권한에 대한 서비스 구현은 불필요하며 정책을 설정하면 쉽고 안전하게 구성할 수 있습니다.

현재는 ‘특정 유저가 어떤 페이지를 호출하였다’보다는 단순히 호출 흐름에 대한 내용을 파악할 수 있습니다. 다음 포스팅에서 진행될 데모에서는 ‘일반 유저가 접속했을 때의 흐름’과 ‘특정 유저가 접속했을 때의 흐름’을 주제로 잡고 설명드릴 예정이니 참고 부탁드립니다.

​4. V1 연결하기

다음은 모든 페이지를 리뷰 버전 v1으로 연결하는 내용이며, 레이팅 서비스에 대해서는 호출하지 않는 구성으로 진행할 수 있습니다.

여러 버전의 서비스를 구성하면서 선택적으로 구축할 수 있으며, 프로덕션 페이지에서 v1의 구성으로 연결되는 것을 예제를 통해 확인할 수 있습니다.

Istio와 Kubernetes Service를 함께 사용하면 어떤 이점이 있을까?

Istio를 사용하면서 네이버 클라우드 플랫폼의 쿠버네티스 서비스와 연동하는 경우 사용자들은 다음과 같은 이점을 가지게 됩니다.

Connect

먼저 서비스 간의 트래픽 및 API 호출 흐름을 지능적으로 제어할 수 있고 다양한 테스트 수행이 가능한 ‘Red / Black’ 배포를 통해 점진적이 업그레이드를 할 수 있기 때문에 사용자들은 안정적으로 서비스를 운영할 수 있습니다.

Secure

각 서비스 간의 관리 인증 및 권한 부여 그리고 서비스 간의 통신 암호화를 통해 서비스 개발자들은 별도의 인프라를 구축할 필요가 없습니다.

Control

중앙에서 정책에 대한 적용 및 시행이 가능하기에 자원을 고르게 분배할 수 있습니다.

Observe

운영하는 모든 서비스에 대한 자동 추적 및 로깅 발생 상황을 확인할 수 있기 때문에 서비스 간의 호출 관계, 서비스의 응답시간, 처리량 등의 다양한 지표를 수집하여 손쉬운 모니터링이 가능합니다.

글을 마치며…

이스티오와 서비스 매쉬 관련 기본 개념을 배웠던 저번 시간에 이어 오늘은 네이버 클라우드 플랫폼 Kubernetes Service와 Istio의 시나리오, 그리고 함께 사용하면 얻을 수 있는 이점들을 살펴보았습니다.

다음번 글에서는 배웠던 개념과 시나리오를 바탕으로 실제 데모를 진행해보도록 하겠습니다. 감사합니다.