본문 바로가기

Cloud/Oracle Cloud Infrastructure (OCI)

OCI상에서 ISTIO를 활용하여 구현한 Service Mesh - #1. Overview

Oracle Cloud Infrastructure (OCI) 에서 이스티오(ISTIO)를 활용한 서비스 메쉬(Service Mesh)에 대한 기술 정리 및 이를 데모로 구현한 내용을 정리합니다.

 

글 순서

1. Overview

2. 이스티오 작동 방식

3. 이스티오 데모 - 사전 준비

4. 이스티오 데모 - 쿠버네티스 대쉬보드 설치/설정

5. 이스티오 데모 - 이스티오 설치, 엔보이 프록시 주입

6. 이스티오 데모 - 샘플 어플리케이션 (Bookinfo) 배포

7. 이스티오 데모 - 카나리 배포

8. 이스티오 데모 - 결함 주입(Fault Injection)

9. 이스티오 데모 - 서비스 시각화 (프로메테우스)

10. 이스티오 데모 - 서비스 시각화 (그라파나)

11. 이스티오 데모 - 서비스 시각화 (키알리)

12. 이스티오 데모 - 서비스 시각화 (예거)

 

REFERENCES

아래 도서 및 사이트를 참조하여 작성한 문서입니다.

  • 도메인 주도 설계로 시작하는 마이크로 서비스 개발 (위키북스)
  • 쿠버네티스 완벽 가이드 (길벗)
  • Istio로 시작하는 서비스 메시 (에이콘)
  • Isitio Documentation

 

OVERVIEW

마이크로서비스 (Microservice)

마이크로서비스 아키텍처는 시스템의 개별 기능을 서비스 단위로 잘라서 서비스끼리 API로 연계하여 시스템 전체를 구성하는 느슨한 결합 (loose coupling) 아키텍처입니다.

 

마이크로서비스 아키텍처의 장점은 서비스끼리의 연결하는 RESTful API는 gRPC와 같은 인터페이스 사양이 결정되어 있다면, 사양을 맞추는 것 외에는 각 서비스 프로그램밍 언어나 프레임웍 등의 기술을 자유롭게 선정할 수 있다는 것입니다. 서비스 간 느슨한 결합을 유지하고 있기 때문에 서비스별로 개발 규모나 성능을 확장시킬 수 있으며, 서비스별로 독립적인 업데이트가 가능하기 때문에 배포 사이클을 단축할 수 있고, 장애 영향 범위를 해당 서비스에 한정시킬 수 있다는 장점도 있습니다.

기존 재사용 가능한 컴포넌트를 모아 비즈니스적으로 의미있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)와는 다음 두가지 측면에서 차별점을 가지고 있습니다.

  • 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화. 다른 서비스의 저장소에 접근하는 수단은 API 밖에 없음
  • RESTful API 같은 개방형 표준을 사용해서 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용 가능

 

마이크로서비스 구현상의 이슈

기존 모노리식(Monolithic) 아키텍처를 여러 조각의 마이크로 서비스로 나눌때 직면하는 여러 문제점들, 즉 추적, 모니터링, 로깅, 인증, 탐색, 유연성, 탄력성 등의 이슈들을 초기 마이크로서비스에서는 오픈소스 소프트웨어나, 특히 유연성과 같이 수평확장이 푤요한 요소는 클라우드 서비스를 이용해서 해결했습니다.

이러한 초기 마이크로서비스의 접근 방식은 API 게이트웨이, 서비스 레지스트리, 컨피그 서비스와 같은 운영 관리를 위한 여러개의 기반 서비스를 각각 만들어야 한다는 점과, 업무 처리 마이크로서비스에 라이브러리를 비즈니스 로직과 함께 탑재해야하는 과제를 남겼습니다. 또한 언어에 따라 지원하지 않는 기능이 있는 점도 문제가 되었습니다.

 

이후 쿠버네티스나 오픈쉬프트(Openshift) 같은 제품이 나오면서 오픈소스 기반의 여러 서비스로 처리했던 문제들을 묶어서 하나의 기술로 해결할 수 있게 되었습니다. 하지만 서킷 프레이크이라든지, 카나리 배포 테스트 구현 등은 여전히 쿠버네티스만으로는 쉽지는 않습니다.

또한 마이크로서비스 간의 의존 관계 등을 파악하는 것과 마이크로서비스 간의 트래픽 레이턴시나 에러를 모니터링하는 것이 쉽지 않습니다.

 

서비스 메시(Service Mesh), 이스티오(Istio)

마이크로서비스 아키텍처의 서비스 디스커버리, 서킷 브레이크, 트레이싱, 로드 밸런싱 등을 비즈니스 로직과 분리해서 네트웍 인프라 계층에서 수행하게하는 서비스 메시를 통해 초기 마이크로서비스의 문제점들을 보다 쉽게 해결할 수 있습니다.

서비스 메시는 어플리케이션이 배포되는 컨테이너에 완전히 격리되어 별도의 컨테이너로 배포되는 사이드카(Sidecar) 패턴을 적용해서 서비스 디스커버리, 라우팅, 로드 밸런싱, 로깅, 모니터링, 보안, 트레이싱 등의 기능을 제공합니다.

 

이러한 서비스 메시를 구현하는 오픈소스 소프트웨어로 이스티오(Istio), 링커드(Linkerd) 등이 있습니다. 이스티오와 링커드의 기본적인 구조는 파드 간 통신 경로에 프록시를 놓고 트래픽 모니터링이나 트래픽 컨트롤을 하게 됩니다.

이스티오는 쿠버네티스 클러스터에 서비스 메시를 구현하지만, 쿠버네티스 클러스터 외부에 있는 VM이나 물리서버로 확장도 할 수 있습니다.

 

  • Data Plane: 사이드카로 배포된 프록시(Envoy)들로 구성. Envoy 프록시는 마이크로서비스간의 모든 네트웍 통신을 중재/제어하며 모든 메시 트래픽에 대한 측정치를 수집 및 리포트
  • Control Plane: 프록시를 관리 및 설정하여 트래픽을 라우팅
  • Envoy: 이스티오는 오픈소스 프록시인 Envoy의 확장 버전을 이용. 서비스 메시 내 모든 서비스들에 대한 인바운드, 아웃바운드 트래픽을 중재하는 역할. C++ 언어로 개발된 고성능 프록시. 서비스 디스커버리, 로드 밸런싱, TLS Termination, 서킷 브레이크, 헬쓰 체크, 폴트 인젝션(Fault Injection) 등을 수행
  • Istiod: 서비스 디스커버리, 이스티오 설정, 인증서 관리 등을 담당.

 

<END>