Kubernetes Korea Group에서 진행하는 Istio 스터디에 참여하며 공부한 내용을 바탕으로 작성한 글입니다.
Introduction
1. Monolithic Service
- Monolithic Service는 가장 고전적인 방식이다.
- 서비스를 개발해오는 방식으로, 각기 다른 역할을 하는 서비스들이 하나의 프로젝트를 이루는 형태이다. - 규모가 커질수록, 서비스가 점점 복잡해져 작은 하나의 기능을 추가하는데 많은 빌드 및 배포 시간이 소요되어 기능 수정 및 추가가 어렵다.
2. MicroService
- Monolithic Service의 문제를 개선하기 위해 나온 구조이다.
- 여러 개의 서비스가 모여 하나의 시스템을 제공한다.
- 기능 추가 및 수정의 용이성이나, 빌드 및 배포 시간이 짧다는 장점이 있다.
- MicroService끼리 통신을 하거나 테스트하기가 매우 복잡하다.
- MicroService가 많아질수록 구조가 너무 복잡해져 관리가 힘들어질 수 있다.
-> Netflix Micro Service 구조
Service Mesh
1. Service Mesh란
- Kubernetes에서 동작하는 다양한 app이 서로 데이터를 공유하거나, 인증 및 라우팅하는 것을 지원하는 기술이다.
- 네트워크 형태가 mesh 형식으로 구성되는 경우가 많아 service mesh라고 명명되었다.
- 위 그림에서 보이듯이 실제 서비스(microservice)는 사용자가 구축한 어플리케이션이고, 내부 통신은 sidecar를 통해서 이루어진다.
- Service mesh는 이 side car에 통신과 관련된 많은 기능들을 제공하여, 어플리케이션 코드의 변경없이 다양한 네트워크 구성(인증, 라우팅, 보안 등)을 적용할 수 있도록 한다.
2. Why Service Mesh?
- Kubernetes 환경에서 MicroService의 확산으로 기존 monolitic Service의 단순한 구성에서 수백개의 복잡한 서비스의 연결로 늘어나게 되었다.
이로 인하여 수많은 app간의 통신이 복잡해지고, 관리 및 추적하기 어려운 상황이 많이 발생하게 되었다.
-> MicroService에서 겪는 관리의 어려움을 해결하기 위해 나온 아키텍처다.
-> Service Mesh 없이 Microservice 구성시 고려할 네트워크 문제가 많다.
-> Server Mesh는 내부 네트워크의 복잡성을 단순화(Sidecar를 통한 네트워크 제어)하고, 배포/운영이 쉽게 도와준다.
3. Proxy 호출 방식
- 기존 아키텍처에서는 Service A가 Service B를 직접 호출하는 방식이었다면, Servive Mesh에서는 Service Sidecar 형태로 떠 있는 Proxy가 다른 서비스의 Sidecar Proxy를 호출하는 방식이다.
- 서비스 트래픽을 네트워크단에서 제어가 가능하다.
- 로깅과 tracing도 용이하게 가능하다.
- 다만, Service 갯수가 늘어날수록 Proxy 갯수도 비례하여 늘어나므로 중앙에서 통제가 필요하다.
- Servcie Mesh 구현체는 여러 개가 있지만 가장 대표적인 구현체로 istio가 있다.
-> proxy끼리 통신
=> prxoy를 중앙에서 control할 주체가 필요! -> Istio control plane이 수행
4. API Gateway vs Service Mesh
API Gateway는 외부(External)의 요청을 내부 서비스로 전달하는 역할을 하며, 나머지 기능적인 측면은 거의 유사하다.
Service Mesh는 API Gateway를 통해 들어온 내부 네트워크를 관리하는데 초점을 맞추고있다.
- 특히 기존 어플리케이션 영역(Business Logic)과 네트워크 영역을 분리(Sidecar 추가)하여 네트워크의 변경 및 적용을 분리된 영역에서 처리하게 되므로, 네트워크의 다양한 변경에도 어플리케이션에 영향이 없이 적용 가능하다
// serveice Mash는 Kubernetes에 종속(관련)된 기술이 아니라 소프트웨어로 네트워크 설정을 쉽게 할 수 있도록 해당 cluster에 추가되는 별도의 소프트웨어 레이어다.
- Kubernetes에서는 별도 namespace에 설치된다.
sidecar Pattern
"하나의 컨테이너에는 하나의 책임만 가지고 있어야 한다."
-
서로 다른 역할을 하는 서비스를 각각의 컨테이너로 분리를 해주어야 할 때 사용하는 패턴이다.
-> Sidecar에 네트워크 관련 기능을 분리하여, app에 종속되지 않고 네트워크 구성 가능하다.
pod안의 메인 컨테이너를 확장하고 향상시키며 개선시키는 역할을 하는 컨테이너를 Sidecar Container라고 하며, 해당 패턴을 Sidecar Pattern이라고 한다. -
위 그림에서는 Web Server가 메인 컨테이너가 되며 같은 파일시스템을 공유하는 로그수집기가 사이드카 컨테이너가 되는 구조다.
이렇게되면 웹서버를 바꾸더라도 로그수집기는 수정하지 않아도 된다.
컨테이너의 재사용성이 증가하게 되는 것이다.
// MicroService Architecture에서 container를 다루는 디자인 패턴이다.
// 최근 Kubernetes에서 Service Mesh를 지원하는 오픈소스는 sidecar 구조로 많이 제공된다.
