Istio란 무엇인가?
Istio는 여러 서비스들을 서로 연결하고, 보호하며, 모니터링하는 기능을 제공하는 오픈소스 도구입니다. 간단하게 말하면, 여러 서비스들 사이에서 통신하는 방식을 효과적으로 관리해주는 도구입니다.
Istio는 어떻게 동작하나요?
Istio는 크게 두 가지 주요 부분으로 구성됩니다.
- 데이터 평면(Data Plane): 서비스들 간의 통신을 관리하는 부분입니다. 'Envoy'라는 특별한 프록시가 이 부분에서 활동하며, 이 Envoy는 서비스들 사이에서 데이터를 전송하는 도로와 같은 역할을 합니다. 또한, 이 데이터를 기록하고 분석해주기도 합니다.
- 제어 평면(Control Plane): Envoy 프록시를 제어하는 부분입니다. 어떤 서비스로 데이터를 보낼지, 어떻게 데이터를 보낼지 등을 결정합니다.
Istio Architecture
아래 그림은 Data/Controle plane을 구성하는 다양한 요소를 보여준다.
Istio의 주요 기능
Traffic management: 트래픽 관리
Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간의 트래픽을 쉽게 제어할 수 있습니다. Istio는 트래픽 라우팅과 폴리시 설정을 통해 미세한 트래픽 제어와 실험 실행을 가능하게 합니다. 이를 통해 circuit breakers, 타임아웃, 재시도, Intelligently control 등의 고급 기능을 간단하게 설정하여 A/B 테스팅, 카나리 배포, 그리고 비율 기반의 트래픽 분할 등을 수행할 수 있습니다.
예를 들어, 서비스 A의 일부 사용자만 서비스 B의 새로운 버전을 보게 하거나, 서비스 C가 문제가 발생했을 때 재시도하는 횟수를 제한하는 등의 기능을 쉽게 설정할 수 있습니다.
Observability: 관찰 가능성
서비스 메시 내 모든 통신에 대한 telemetry를 생성하여 운영자가 서비스 동작을 관측하고 문제 해결, 유지 관리 및 최적화를 할 수 있도록 지원하는 Istio 기능입니다.
대부분의 telemetry 정보를 얻을 수 있으며, 애플리케이션 변경이 필요하지 않습니다. Istio를 통해 운영자는 모니터링된 서비스가 상호 작용하는 방식을 철저히 이해할 수 있습니다.
Security: 보안
인증서 통신이 defualt, RBAC 보다 상위의 authentication입니다.
마이크로서비스에서는 man-in-the-middle attacks, 액세스 제어, 감사 도구, TLS 보호 등의 보안 요구 사항이 있습니다.
Istio는 이러한 문제를 해결하기 위한 포괄적인 보안 솔루션을 제공하며, 강력한 식별, 정책, 권한 부여 및 감사 도구를 제공하여 서비스 및 데이터를 보호합니다.
Istio의 보안 모델은 기본적으로 보안으로 설정되어 있으며, 신뢰할 수 없는 네트워크에서도 보안 지향 애플리케이션을 배포할 수 있도록 깊이 있는 방어 기능을 제공합니다.
Envoy Proxy (Forward, Reverse Proxy)
특징
- Proxy는 네트워크 아키텍처의 중개 구성 요소로, Envoy 프록시는 애플리케이션 요청 경로에 삽입되어 서비스 검색, 로드 밸런싱, 헬스 체크 등의 기능을 제공하며, 로드 밸런싱 및 바이트 및 패킷을 전송하는 등의 기능을 수행할 수 있다.
- L7에서 동작하여 L4보다는 성능이 떨어진다.
| Layer | 동작 |
| L7, HTTP Proxy |
전체 요청(Request)을 파싱하고 헤더 정보를 확인한 후 응답(Response)을 백엔드에서 읽어와 클라이언트에게 전송해야 한다. 이를 위해 CPU 연산이 필요하다. |
| L4, TCP Proxy | IP와 Port정보를 체크해서 통신 허용여부를 결정 |
주요 기능
Envoy는 특히 분산 시스템에서의 통신에 있어 다양한 문제를 해결하는 기능을 제공합니다. 특히, 복잡한 네트워크 토폴로지와 다양한 통신 프로토콜을 지원하면서도 빠른 성능을 보장합니다.
- L7 프록시가 주요 기능이지만 핵심 부분은 L3/L4 프록시
- HTTP L7 라우팅과 HTTP L7 필터 레이어를 제공
- HTTP/2를 기본으로 지원 (물론, HTTP/1.1도 지원)
- gRPC를 지원
- MongoDB/DynamoDB L7을 지원
- 서비스 디스커버리(Service Discovery)와 설정을 동적으로 변경하는 것이 가능
- 헬스 체크를 지원
- 자동 재시도, 서킷 브레이킹, 전역 비율 제한, 요청 셰도잉, 이상 탐지 등을 제공
- 프론트/엣지 프록시를 지원
- 관리용으로 다양한 통계 정보를 제공
Forward Proxy VS Reverse Proxy
이 두 가지 프록시는 네트워크 구성과 통신의 흐름에 따라 서로 다른 역할을 합니다.
- Forward Proxy는 트래픽 흐름에 추가 기능을 추가하는 중간 서버이다.
- 캐시 기능(속도 향상), 화이트리스트 연결
- Reverse Proxy는 클라이언트로부터 백엔드 토폴로지를 숨기고 트래픽을 공정하게 분산시키는 알고리즘을 구현할 수 있다.(로드밸런싱)
- Reeverse Proxy는 내부 서버에서 데이터를 받은 후 Client에게 전달
- DMZ 등 네트워크 분리
- 캐시 기능(e.g. CDN)
코드 중심 솔루션의 한계점 - Code oriented frameworks
코드 중심의 솔루션은 빠른 개발 속도와 직관적인 접근 방식을 제공하지만, 일정 규모 이상의 프로젝트나 복잡한 시스템에서는 한계점이 있습니다.
- 소스에서는 비기능적인 요소가 변경될 때 소스가 재배패포 되어야 한다.
- e.g. Rate Limiting(canary), Circuit Breaker, Inteligent Routing
- 언어에 초점을 맞춘 구현 방식
- 오류 발생 가능성이 높다.
- 시스템 규모가 커질수록 각 마이크로서비스 업그레이드가 어렵다.
- 개발팀에 기술적인 도전과 책임을 부여한다.
- 같은 조직 내의 다른 팀은 서로 다른 구현 방식을 가질 수 있다.
- 각 팀은 자신의 구현 방식을 유지해야 한다.
Kubernetes Infrastructure Container 역할
Kubernetes에서의 Infrastructure Container는 Pod의 안정성과 일관성을 보장하기 위한 중요한 역할을 합니다.
- Kubernetes Pod에 항상 포함되는 컨테이너
- Pod 안의 모든 컨테이너가 동일한 네트워크와 리눅스 네임스페이스를 공유할 수 있도록 지원하는 컨테이너
- Pod 안의 사용자 정의 컨테이너는 Infrastructure Container의 네임스페이스를 사용하도록 설정된다.
- 컨테이너가 다시 시작되더라도 Infrastructure Container의 네임스페이스를 사용하기 때문에 동일한 IP를 유지할 수 있다.
Sidecar Pattern
Sidecar Pattern은 마이크로서비스 아키텍처에서 특히 각각의 서비스의 기능성과 비기능성을 분리하면서도 높은 응집도를 유지하게 해주는 패턴입니다.파드안의 컨테이너들은 네트워크 네임스페이스를 공유한다.
- Pod를 올리면 컨테이너 A, B 외에도 (pause,pod infrastructure container)가 생성한 namepsace 를 같이 사용한다.
- 여기에 비기능적인 요소의 컨테이너를 심을 수 있다.
- 비기능적인 요소 분리가 가능하다.
- 애플리케이션 코드 수정 없이 더 많은 기능을 추가할 수 있다.
- API 서버에 직접 통신하는 대신, main 컨테이너의 애플리케이션은 HTTPS 대신 HTTP를 통해 ambassador 컨테이너에 연결하고, 보안 역할을 담당하는 엠배서더 프록시가 들어오고 나가는 모든 트래픽을 HTTPS 연결로 처리한다.
- Pod의 모든 컨테이너는 동일한 루프백 네트워크 인터페이스를 공유하므로, 애플리케이션은 localhost의 포트를 통해 프록시에 액세스할 수 있다.
- 애플리케이션 컨테이너와 독립적으로 동작하는 별도의 컨테이너를 붙이는 패턴
- 비기능 적인 요소를 처리해주는 proxy container
- 서비스 A → B로 향할때 proxy를 먼저 거치게 해준다.
장점
Sidecar Pattern은 특히 클라우드 네이티브 어플리케이션에서 활용도가 높습니다.
- 상호 의존성을 줄일 수 있다.
- 사이드카 장애 시 애플리케이션이 영향을 받지 않는다.. (isolation)
- 사이드카 적용/변경/제거 등의 경우에 애플리케이션은 수정이 필요하지 않습니다.
- 애플리케이션과 사이드카를 다른 언어로 만들 수 있습니다.
- Pod에서 사이드카 컨테이너는 원래 애플리케이션 컨테이너 옆에 삽입되고 두 컨테이너는 스토리지, 네트워크 등 기타 리소스를 공유한다.
단점
- 애플리케이션이 너무 작으면 배보다 배꼽이 더 커질 수 있다.
- 프로세스 간 통신이 많고 최적화가 필요한 경우, 애플리케이션에서 함께 처리하는 것이 좋을 수 있다.
'Cloud-native > Istio' 카테고리의 다른 글
| [Istio]Traffic Management - 무슨 일이 발생하는 건가?(envoy xDS Sync 이해하기) (0) | 2023.05.06 |
|---|---|
| [Istio]Traffic Management - Request Routing(동적 요청 라우팅 구성하기) (0) | 2023.05.06 |
| [Istio]Traffic Management - Overview (0) | 2023.05.06 |
| [Istio]Deploy bookinfo sample application to demonstrate various Istio features (0) | 2023.04.23 |
| [Istio]Install Istio with istioctl (0) | 2023.04.23 |
