View
Service Mesh
기존 모놀리스 시스템을 도메인, 운영등의 여러 기준에 따라 분할해놓은 MSA(MicroService Architecture)는 비즈니스 서비스를 제공하기 위해 수많은 마이크로 서비스들이 내-외부간 네트워크 통신을 하게 된다.
수많은 서비스들간의 네트워크 통신을 관리하기위해 가시화하고 통신에 대한 보안, 추적, 장애방지 등을 관리하기 위해 나온것이 Service Mesh 개념이다. 위 그림에서 볼 수 있는 Amazon, Netflix의 서비스간 네트워크 연결을 보면 알수 있듯이 이러한 수많은 연결이 현재 어떻게 이루어져 있으며 어디서 문제가 발생했는지, 그 문제가 어디까지 전파되고 있는지 또는 서비스 인스턴스가 골고루 사용되고 있는지, 보안연결은 정상적으로 제공되고 있는지에 대한 문제를 Service Mesh의 챌린지이다.
Istio Concept
현재 Istio는 Service Mesh의 주요 기능을 구현한 오픈소스 프로젝트이다. Istio이 제공해주는 주요 기능은 아래와 같다.
- Service Discovery : 준비가 된 새로운 서비스 인스턴스를 목록에 추가하고 사용이 불가능해진 서비스 인스턴스를 삭제하는 등의 서비스 인스턴스 목록 관리하고 서비스의 요청을 어떤 인스턴스로 보낼지, 보내지 않을 지에 대해 결정한다.
- Routing
- Load Balancing : Round Robin, Weight, Random 등 다양한 방법으로 로드 밸런싱을 지원
- Health Check : 노드의 가용성 및 서비스들의 상태를 지속적으로 확인
- Automatic Deployment : 배포 유형에 따라 가중치를 적용해 트래픽을 새로운 노드로 유도
- Resilience : 애플리케이션과 독립적인 서비스 요청의 timeout, retry등을 제어
- Security : TLS 암호화 지원, 엑세스 제어
- Telemetry : 네트워크 추적, 메트릭 수집
Istio는 위와 같은 기능을 제공하기 위해 사이드카 패턴을 기반으로 개별 서비스 인스턴스를 제어하는데, 거의 대부분의 경우 Envoy를 사용해서 사이드카 패턴을 구현한다. 사이드카 패턴은 일종의 개념이고 이 개념의 기능을 수행하기 위한 구현체로써 Envoy를 사용하는 것이다.
Netflix에서 공개한 Spring Cloud Netflix, Google의 Stubby등 애플리케이션 레벨에서 구현한 몇몇 Service Mesh가 있음에도 Istio가 주목받는 이유는, 애플리케이션에서 이러한 주요 개념을 구현할 때 각각의 프레임워크마다 구현체가 달라 생기는 러닝커브, 비즈니스 로직에 Service Mesh관련 내용의 코드를 추가함으로써 생기는 복잡성등의 단점이 발생할 수 있다. 이와같은 단점을 보완하기 위해 Istio와 같이 Service Mesh를 위한 별개의 네트워크 레이어를 구성하여 애플리케이션과의 독립성을 보장하고 MSA의 폴리글랏 구조에서 다양한 프레임워크에 대응할 수 있도록 유연한 구조를 구축할 수 있게 된다.
Sidecar Pattern
실제 Sidecar처럼 서비스 인스턴스에 붙어 일종의 proxy 역할을 수행하며 네트워킹, 모니터링, 로깅과 같은 기능을 제공한다.
사이드카는 담당하는 서비스 인스턴스와 라이프 사이클을 공유하며, 인스턴스와 1:1관계로 단독으로 확장될 수 없는 구조를 가진다. 또한 인스턴스가 주고받는 모든 트래픽을 proxy한다. 이런 사이드카 패턴의 장점은 위 Primary Application에 해당하는 부분인 기존 서비스 로직부분에대한 변경 없이도 서비스 인스턴스가 외부와 주고받는 모든 네트워크를 컨트롤할 수 있다는 점이다. 이는 Istio를 써야하는 주요 중 하나를 뒷받침해준다.
Envoy
사이드카 패턴을 구현한 L7 Proxy, Communication bus 이다.
Envoy의 아키텍쳐 구성요소
- Port Listener : Envoy가 네트워크 트래픽을 리스닝(관리)하는 포트를 관리. TCP 기반의 리스너만 지원. 여러 리스너로 구성된 단일 인스턴스 실행을 권장
- Filter : 수신된 메세지를 라우팅, 프로토콜 변환, 통계 생성 등과 같은 다양한 작업을 수행할 수 있는 Filter Set을 구성. 각 리스너는 고유의 필터 세트를 구성하고 있음. 다양한 기본 필터 셋을 가지고 있으며 분류는 아래와 같음
- Listener Filter : TLS 검사 또는 서비스 원격 대상 등을 담당. 원시 데이터에 엑세스 한 후 L4의 메타데이터를 조작
- Network Filter : 애플리케이션 권한 부여, 속도 제한, TLS 인증 등 작업 수행. 통계 수집, 엑세스 제어등을 위한 Mysql, MongoDB와 같은 애플리케이션별 프로토콜에 관한 필터도 있음.
- HTTP Filter : 다양한 HTTP 필터 셋이 제공됨. gzip 압축, grpc -> json 변환 등 다양한 작업 수행 가능. Envoy Proxy가 받은 HTTP request를 조작
- Cluster : Envoy가 연결하는 논리적 호스트 그룹. 정적으로 구성하거나 내장된 Service Discovery를 사용해서 동적으로 생성할 수 있음
Envoy가 제공하는 서비스 목록
- EDS, Endpoint Discovery Service : 클러스터에 서비스를 추가/제거할 수 있는 서비스. DNS 역할을 하며 DNS 병목 현상을 해결하는데 활용
- CDS, Cluster Discovery Service : 라우팅에 사용되는 애플리케이션 클러스터를 동적으로 검색할 수 있는 서비스. 클러스터를 추가, 업데이트, 제거한다.
- RDS, Router Discovery Service : HTTP 필터 체인을 동적으로 동적으로 생성
- LDS, Listener Discovery Service : HTTP 필터의 리스너 체인을 동적으로 생성
- SDS, Secret Discovery Service : TLS 인증서, Private Key와 같은 애플리케이션 Secret 검색. 공개 인증서 제공
Architecture
Data Plane
서비스와 사이드카로 배포된 Proxy(Envoy)로 구성되어있는 셋의 집합이다. 자기자신이 담당하는 서비스의 모든 network in/out 패킷을 변환, 전달, 모니터링한다.
Control Plane
Data Plane으로 부터 서비스의 상태를 전달받아 현재 가용 가능한 서비스 목록을 지속적으로 관리하며 전체 네트워크 트래픽을 제어한다. 또한 Circuit Breaker, 로드 밸런싱, timeout, security 등의 기본 구성 정보를 저장한다. Control Plane은 트래픽을 담당하는 Pilot, 암호화을 담당하는 Citadel, 환경 설정 저장/사용자 구성 검증 등의 기본적인 Control Plane 기능을 제공하는 Galley로 구성되어 있다.
- Pilot
트래픽을 라우팅하며 Service Discovery, timeout, retry, Circuit Breaker 운영을 관리한다. Istio는 모든 팟의 사이드카로 Envoy Proxy를 사용하여 Service Mesh를 구성, 처리하는데 파일럿이 설정된 정보를 바탕으로 Envoy를 구성해 런타임 때 구성한 Envoy를 배포한다.
- Citadel
Istio 내의 요청을 암호화하고 메시 내 서비스에 관한 RBAC(Role Based Access Control)을 제공한다. 이 구성은 Pilot에 의해 Envoy로 푸쉬된다. - Galley
기본 환경, 사용자 구성을 관리한다.
Feature
Istio가 제공하는 핵심 기능은 크게 3가지로 나누어진다.
- Traffic Management : 네트워크 트래픽의 룰을 설정하여 트래픽을 컨트롤한다. Circuit Break 패턴을 사용해서 서비스 인스턴스간 장애 확산을 최소화하고 timeout, retry 등을 제어하며, 백분률기반의 트래픽 분할을 활용해 A/B 테스트, Canary rollout, staged rollout등이 가능하도록 설정할 수 있다.
- Secure : 메쉬 네트워크상에서 발생하는 네트워크 통신에 대한 보안 통신 채널을 제공하고 인증, 권한, 암호화를 관리한다. 애플리케이션에선 네트워크 통신 보안이슈를 Istio에 위임할 수 있다.
- Observability : 네트워크 추적, 모니터링, 로깅을 제공한다.
Conclusion
기존 모놀리스 형식 프로그램에서 발생하던 도메인간 내부 라이브러리(코드) 호출이 마이크로서비스 아키텍쳐로 변하면서 수많은 서비스 인스턴스간 네트워크 API 호출로 변화되었다. 이전보다 더 복잡해진 네트워크 통신으로 인해 발생하는 다양한 문제점, 개념들을 Service Mesh라는 개념으로 묶고, 이를 해결하기위해 Istio에서 네트워크 가시성, 보안, 암호화, 트래픽 라우팅, 장애 확산 방지 등 다양한 Service Mesh 기능들을 제공한다.
Reference
Martin Fowler - CircuitBreaker
Envoy Document - What is Envoy
ProgrammerSought - Envoy architecture, terminology and basic configuration analysis
Layer5.io - Service mesh Landscape
분산된 환경에서 서비스간의 네트워크 관리는 매우 중요하다. 네트워크에 대한 감시를 포함하여 특정 서비스가 문제가 발생했을 때 그 서비스를 사용하는 다른 서비스로의 오류 전파를 막고 피해를 최소화하도록 Infrastructure Layer이다.
서비스의 오류 전파, 확산를 막기 위해 회로 차단기가 모티브된 Circuit Breaker Pattern이 기본 개념으로 많이 사용된다.
- Closed : 오류 없이 정상적으로 동작하는 상태. 지속적으로 모니터링하며 특정 임계치를 초과할 경우 Open으로 상태를 변환
- Open : 오류가 발생해서 오류를 반환하는 상태
- Half-Open : 특정 시간이 지난 후 여전이 오류상태인지 확인하고 오류 여부에 따라 Open 또는 Closed로 변환하는 상태
Circuit Breaker Pattern을 개발 프레임워크 레벨에서 구현한 구현체로는 Spring Netflix OOS, Stubby, Finagle등이 있다. 하지만 이런 프레임워크 레벨의 구현체를 쓰면 애플리케이션이 인프라스트럭쳐와 결합도가 높아진다. 예를들어 특정 프레임워크가 필요한 기능을 지원하지 않는다면 대처할 방법이 없어 유연성이 낮아질 수 있고, 개발 프레임워크가 변경될 경우 해당 프레임워크가 구현해놓은 Circuit Breaker Pattern을 학습하기 위한 러닝커브가 발생할 수 있다.
인프라스트럭쳐에서 Circuit Breaker Pattern을 구현한 프로젝트로는 대표적으로 오픈소스 Istio가 있고, 몇몇 상용 클라우드 시장에선 대표적으로 GCP에서는 Anthos(이것도 istio 기반으로 보임)가 있다.
Service Mesh는 OSI 5 Layer인 Session Layer에서 동작하여 애플리케이션과 decoupling 상태에서 동작한다. Service Mesh의 주요 기능은 아래와 같다.
- 트래픽 제어 : 7 Layer(Application Layer)의 헤더를 조회하여 특정 인스턴스로 라우팅하는 등의 제어. 서비스 업데이트 등에 활용 가능
- 보안(Security) : 서비스의 인스턴스간 트래픽에 대한 보안 정책 적용, 속도제한 등
- 분석 : 서비스 인스턴스간 요청 로깅, 시각화, 메트릭 수집
'Cloud' 카테고리의 다른 글
Google Cloud StudyJam - [Coursera]Architecting with Google Kubernetes Engine: Foundations/Worload/Productions (0) | 2022.10.02 |
---|---|
AWS - 인증, IAM (0) | 2022.02.02 |
Docker Daemon 외부 포트 오픈 (0) | 2021.03.02 |
Rook-Ceph Concept, Install (0) | 2021.02.24 |