서비스 메시 아키텍처
이스티오를 포함한 서비스 메시 아키텍처는 일반적으로 컨트롤 플레인과 데이터 플레인으로 구성되며, 세번째(관리) 플레인은 기존/인프라 시스템에 존재할 수 있다.
[플레인]
ㅇ 데이터 플레인
이스티오 데이터 플레인은 요청의 모든 패킷을 가로채며 상태 확인, 라우팅, 로드 밸런싱, 인증, 권한 부여 및 관찰 가능한 신호 생성을 담당한다.
대역 내에서 작동하면 서비스 프록시가 투명하게 추가되고 애플리케이션에서 서비스 간 호출을 수행할 때 애플리케이션은 데이터 플레인의 존재를 인식하지 못한다.
데이터 플레인은 클러스터 내 통신뿐만 아니라 인바운드(인그레스)와 아웃바운드(이그레스) 클러스터 네트워크 트래픽을 담당한다. 트래픽이 메시에 들어오든 나가든 관게없이 애플리케이션 서비스 트래픽은 먼저 처리를 위해 서비스 프록시로 전달된다.
이스티오를 사용하면 iptables 규칙을 사용해 트래픽을 투명하게 가로채고 서비스 프록시로 리다이렉트한다.
이스티오 데이터 플레인은 시스템의 모든 패킷/요청을 처리하며 서비스 검색, 상태 확인, 라우팅, 로드 밸런싱, 인증, 권한 부여와 관찰 가능성을 담당한다.
ㅇ 컨트롤 플레인
이스티오 컨트롤 플레인은 서비스 프록시를 위한 단일 관리 지점을 제공하는데, 서비스 프록시는 효율적으로 관리하려면 프로그래밍 방식의 구성이 필요하며 서비스가 환경 전체에서 다시 스케줄링 될 때 구성이 실시간으로 업데이트 돼야 한다.
컨트롤 플레인은 메시의 서비스를 위한 정책 및 구성을 제공하고 격리된 상태 비저장 프록시 세트를 사용해 서비스 메시로 전환한다.
컨트롤 플레인은 메시의 네트워크 패킷을 직접 건드리지 않는다.
컨트롤 플레인은 대역 외에서 작동한다.
컨트롤 플레인은 일반적으로 상호작용 가능한 CLI 및 사용자 인터페이스를 가지며 각 인터페이스는 프록시 동작을 전체적으로 제어하기 위한 중앙 집중식 API에 대한 접근을 제공한다.
컨트롤 플레인 API를 통해(예: CI/CI 파이프라인) 컨트롤 플레인 구성의 변경을 자동화할 수 있으며, 실제로는 구성이 가장 자주 버전 제어되고 업데이트된다.
이스티오 컨트롤 플레인은 다음을 수행한다.
* 운영자가 원하는 라우팅/복원성 동작을 지정할 수 있도록 API를 통한 메시의 서비스에 관한 정책 및 구성 제공
* 격리된 상태 비저장 사이드카 프록시 세트를 서비스 메시에 결합
- 로컬화된 구성을 사용하기 위한 데이터 플레인용 API
- 데이터 플레인용 서비스 검색 추상화
* 할당량 및 사용제한을 통해 사용 정책을 지정하기 위해 API를 사용
* 인증서 발급과 교체를 통한 보안 제공
* 워크로드 ID를 할당
* 라우팅 구성 처리
* 시스템의 패킷/요청을 건드리지 않는다.
* 네트워크 경계 및 접근 방법 지정
* 원격 측정 수집 통합
[이스티오 컨트롤 플레인 구성 요소]
ㅇ 파일럿
이스티오 메시로 만든 배의 머리.
데이터 플레인에 대한 서비스 실행 상태와 위치를 추적하고 표시해 기반 플랫폼(예: 쿠버네티스)과 동기화 상태를 유지한다.
파일럿은 환경의 서비스 발견 시스템과 인터페이스하고 데이터 플레인 서비스 프록시에 대한 구성을 생성한다.
(나중에 istio-proxy를 데이터 플레인 구성 요소로 검토)
이스티오가 발전함에 따라 파일럿의 더 많은 부분이 확장 가능한 프록시 구성 제공에 초점을 둘 것이고 기반 플랫폼과의 인터페이스에는 덜 집중할 것이다.
파일럿은 다양한 소스의 구성 및 엔드포인트 정보를 통합하고 이를 xDS 개체로 변환해 Envoy 호환 구성을 제공한다.
다른 구성 요소인 갤리는 결국 기본 플랫폼과 직접 인터페이스해야 한다.
ㅇ 갤리
갤리는 이스티오의 구성 집계와 배포 구성 요소
갤리의 역할이 발전함에 따라 구성 수집과 유효성 검사를 통해 기본 플랫폼 및 사용자가 제공한 구성과 다른 이스티오 구성 요소를 격리시킨다.
갤리는 메시 구성 프로토콜(MCP, Mesh Configuration Protocol)을 구성 제공하거나 배포 메커니즘으로 사용한다.
ㅇ 믹서
믹서는 이스티오의 Stackdriver 또는 New Relic 등의 인프라 백엔드가 나머지 부분과 독립적으로 동작할 수 있도록 인프라 백엔드를 추상화 하는 컨트롤 플레인 구성 요소
믹서는 전제 조건 확인, 할당량 관리 및 원격 분석 보고에 대한 책임을 진다. 믹서는 다음을 수행한다.
* 플랫폼 및 환경 이동성을 지원함
* 정책 평가 및 원격 분석 보고를 담당해 운영 정책 및 원격 분석을 세부적으로 제어함
* 풍부한 구성 모델을 가짐
* 인텐트 기반 구성(intent-based configuration)으로 추상화해 대부분의 인프라 문제를 해결
apstra.com/ko/best-practices-intent-based-networking-network-management-systems-or-both/
네트워크 모니터링 모범 사례. 인 텐트 기반 네트워킹, 네트워크 관리 시스템 또는 둘 다? | 압 스
네트워크 모니터링에 가장 적합한 방법을 결정할 때 사람들이 사용할 수있는 많은 도구가 있습니다. 많은 사람들이 고민하는 문제는 인 텐트 기반 네트워킹, 네트워크 관리 시스템…
apstra.com
서비스 프록시 및 게이트웨이는 믹서를 호출 해 요청을 진행할 수 있는지 사전 검사하고(확인), 발신자와 서비스 간의 통신이 허용되는지 혹은 할당량을 초과했는지를 확인하고 요청이 완료된 후 원격 분석을 보고하기 위한 사전 조건 검사를 수행(리포팅)
믹서는 기본 및 서드파티 어댑터 세트를 통해 인프라 백엔드에 인터페이스한다. 어댑터 구성에 따라 어떤 원격 측정이 어떤 백엔드로 언제 전송될지 결정된다.
서비스 메시 운영자는 믹서의 어댑터가 속성처리 및 라우팅 엔진으로 작동한다면 어댑터를 인프라 백엔드와 통합 및 중개 지점으로 사용할 수 있다.
ㅇ 시타델
시타델은 이스티오가 ID 및 자격증명 관리 기능이 내장된 상호 전송 계층 보안(mTLS, mutual Transport Layer Security)을 사용해 강력한 서비스 대 서비스 및 최종 사용자 인증을 제공 가능하도록 한다.
시타델의 CA 구성 요소는 시타델 에이전트가 보낸 인증서 서명 요청 CSR(Certificate-Signing Request)을 승인하고 서명하며 키 및 인증서 생성, 배포, 교체 및 해지를 수행한다.
시타델은 CA 프로세스 중 ID 디렉터리와 상호작용 가능한 선택적 기능을 제공한단.
시타델은 자체 생성된 자체 서명 키와 인증서를 사용해 워크로드 인증서에 서명하지 않고도 다른 CA를 사용할 수 있는 플러그 가능한 아키텍처를 갖는다. 이스티오의 CA 플러그인 기능은 다음을 가능하게 한다.
* 조직의 공개 키 인프라(PKI, Public KEY Infrastructure) 시스템과 통합한다.
* (동일한 신뢰 루트를 공유해) 이스티오와 이스티오 외의 레거시 서비스 간 통신을 보호한다.
* CA 서명키를 잘 보호된 환경에 저장해 보안을 유지한다.
ㅇ 서비스 프록시
서비스 메시 프록시는 들어오는 네트워크 트래픽, 서비스 간 트래픽 및 서비스에서 나가는 트래픽을 조절할 수 있다. 이스티오는 서비스와 클라이언트간 프록시를 사용한다.
서비스 프록시는 일반적으로 파드에 사이드카로 배포된다. 프록시 간 통신이 실제로 메시를 형성한다. 본질적으로 애플리케이션이 메시에서 동작하게 하려면 다음 그림과 같이 애플리케이션과 네트워크 사이에 프록시가 존재해야 한다.
사이드카는 컨테이너를 변경하지 않고 컨테이너에 동작을 추가한다. 그런 의미에서 사이드카와 서비스는 단일하고 향상된 단위로 작동한다. 파드는 사이드카와 서비스를 단일 단위로 호스팅 한다.
[이스티오 데이터 플레인 구성 요소]
ㅇ Envoy
이스티오는 C++로 개발된 고성능 프록시 Envoy의 확장 버전을 사용해 서비스 메시의 모든 서비스에 대한 모든 인바운드와 아웃바운드 트래픽을 중재한다.
이스티오는 동적 서비스 발견, 로드 밸런싱, TLS 처리, HTTP/2 및 gRPC 프록싱, 서킷 브레이커, 헬스 체크, 백분율 기반 트래픽 분할을 통한 단계적 출시, 결함 주입 및 풍부한 메트릭 등의 Envoy 기능을 활용한다.
Envoy는 관련 서비스와 동일한 쿠버네티스 파드에 서비스에 대한 사이드카로 배포된다. 이스티오는 이를 통해 트래픽 행동에 대한 풍부한 신호를 속성으로 추출할 수 있으며, 이를 통해 믹서에게 정책 결정을 시행하고 모니터링 시스템으로 전송해 전체 메시의 행동에 대한 정보를 제공할 수 있다.
ㅇ 주입
사이드카 프록시 모델을 사용하면 코드를 다시 디자인하거나 다시 작성할 필요 없이 기존 배포에 이스티오 기능을 추가할 수 있다. 이것은 이스티오 사용의 중요한 매력이다.
애플리케이션 코드를 변경하거나 Deployment 메니페스트를 변경하지 않고도 최상위 서비스 메트릭에 대한 즉각적인 확인, 트래픽에 대한 세부 제어, 모든 서비스간의 자동 인증 및 암호화를 약속한다.
이스티오의 표준 샘플 애플리케이션 Bookinfo를 사용하면 서비스 프록시가 어떻게 작동하고 메시를 형성하는지 명확히 알수 있다.
쿠버네티스의 자동 프록시 주입은 쿠버네티스 API 서버와 변경 승인 Webhook 컨트롤러(mutating admission webhook controller)를 사용해 webhoo으로 구현된다.
webhook은 인젝션 템플릿, 메시 구성 컨피그맵 및 인젝트 대상 파드 개체에만 의존하며 상태 비저장이다. 따라서 배포 객체를 통해 수동으로 또는 수평 파드 자동 스케일러(HPA, Horizontal Pod Autoscaler)를 통해 자동으로 쉽게 수평확장 할 수 있다.
새로 생성된 파드에 사이드카 프록시를 주입하려면 webhook 자체를 실행하는 데 평균 1.5㎲(마이크로 벤치마크당)가 걸린다. 네트워크 대기 시간 및 API 서버 처리 시간을 고려하면 총 주입 시간이 더 늘어난다.
이스티오는 "균질하고 안정적이며 변화가 없는 네트워크는 존재하지 않는다." 라는 잘 알려진 분산 시스템의 문제를 해결한다. 이는 애플리케이션 컨테이너와 네트워크 사이에 배포된 경량 프록시 배포를 통해 이뤄진다.
아래는 이스티오 전체 아키텍처를 구성하는 컨트롤 플레인 및 데이터 플레인과 각각의 요소를 설명한다. 전체 메시 배포는 인그레스 및 이그레스 서비스 게이트웨이도 포함한다.
ㅇ 게이트웨이
이스티오 0.8에서 인그레스 및 이그레스 게이트웨이 개념이 도입됐다. 대칭적으로 유사한 인그레스 및 이그레스 게이트웨이는 트래픽이 메시로 들어오고 나가는 트래픽에 관해 각각 역방향(reverse)과 전달(forward) 프록시 역할을 한다.
다른 이스티오 구성 요소와 마찬가지로 이스티오 게이트웨이의 동작도 구성을 통해 정의하거나 제어되므로 서비스 메시에 허용 혹은 차단할 트래픽, 속도 등을 제어할 수 있다.
인그레스
인그레스 게이트웨이를 구성하면 서비스 메시로 유입되는 트래픽이 통과하는 입구를 정의할 수 있다.
메시에 트래픽을 유입시키는 것은 전통적인 웹 서버 로드 밸런싱과 유사한 역방향 프록시와 동일한 상황이라고 생각해야 한다. 메시 밖으로 트래픽을 나각 하는 구성은 메시 밖으로 나가는 트래픽과 라우팅할 위칠르 식별하는 포워드 프록시 상황이다.
예를 들어 다음 게이트웨이 구성은 수신을 위해 포트 80 및 9080(HTTP), 443(HTTPS) 및 포트 2379(TCP)를 노출시키는 로드 밸런서 역할을 하도록 프록시를 설정한다.
게이트웨이는 라벨 app: my-gateway-controller와 함께 파드에서 실행되는 프록시에 적용된다.
이스티오가 이 포트들에서 수신 대기하도록 프록시를 구성하더라도 메시에서 이 포트들로 외부 트래픽 유입이 허용되도록 하는 것은 사용자 책임이다.
apiVersion: networking.istio.io/v1alpha3
kind: Gateay
metadata:
name: my-gateway
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
httpsRedirect: true # http 요청에 관해 301 리다이렉트를 보냄
- port:
number: 443
name: https
protocol: HTTS
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
mode: SIMPLE #이 포트들에 HTTPS를 적용
serverCertificate: /etc/certs/servercert.pem
privateKey: /etc/certs/rivatekey.pem
- port:
number: 9080
name: http-wildcard
protocol: HTTP
hosts:
- "*"
- port:
number: 2379 # 내부 서비스를 포트 2379로 노출
name: mongo
protocol: MONGO
hosts:
- "*"
이그레스
트래픽은 두 가지 방식으로 서비스 메시에서 나갈 수 있다. 사이드카에서 직접 나가거나 혹은 정책을 적용할 수 있는 장소인 이그레스 게이트웨이 깔때기를 통과하는 방식이다.
서비스 프록시에서 직접 트래픽이 나가는 경우
외부 소스로 향하는 트래픽이 이그레스 게이트웨이를 우회하게 하려면 istio-sidecar-injector의 ConfigMap에 구성하면 된다. 사이드카 인젝터에서 다음 구성을 설정하면 클러스터 로컬 네트워크를 식별하고 다른 모든 대상의 트래픽을 외부로 전달하는 동안 메시 내에서 로컬 트래픽이 전송되도록 한다.
--set global.proxy.includeIPRanges="10.0.0.1/24"
이 구성을 적용하고 이스티오 프록시가 업데이트 되면 외부 요청이 사이드카를 우회하고 원하는 대상으로 직접 라우팅된다. 이스티오 사이드카는 클러스터 내의 내부 요청만 가로채고 관리한다.
이그레스 게이트웨이를 통한 경로
클러스터 프라이빗 IP 주소 공간, 모니터링 또는 클러스터 간 연결에서 연결을 제공하려면 이그레스 게이트웨이가 필요할 수 도 있다.
이그레스 게이트웨이를 사용하려면 메시를 나가는 트래픽에 이스티오 모니터링 및 경로 규칙 적용 가능하다. 또한 노드에 퍼블릭 IP 주소가 없는 클러스터에서 실행되는 애플리케이션 간 통신을 용이하게 하며, 메시의 애플리케이션이 인터넷에 접근하지 못하게 한다.
이그레스 게이트웨이를 정의한 다음 모든 이그레스 트래픽이 게이트웨이를 통과하게 하고 퍼블릭 IP를 이그레스 게이트웨이 노드에 할당하면 노드가 아래 그림에 표시된 것처럼 제어된 상태에서 외부 서비스 접근이 가능하다.
[확장성]
일부 서비스 메시의 목표와는 다르지만 이스티오는 사용자 정의 가능하도록 설계됐다. 확장 가능한 플랫폼으로서 통합은 두가지 기본 형태, 즉 교환 가능한 사이드카 프록시와 원격 측정/권한 부여 어댑터로 제공된다.
ㅇ 사용자 정의 가능 사이드카
이스티오는 Envoy가 기본 서비스 프록시 사이드카지만 사이드카에 다른 서비스 프록시를 사용할 수 있다. Envoy를 넘어 생태계에는 여러 서비스 프록시가 존재하지만 현재 Linkerd와 NGINX 두 개만 이스티오 통합 방법을 보여준다.
Linkerd2는 현재 범용 프록시로 설계되지 않았다. 오히려 경량화에 중점을 두고 있고, 그 다음 관심사로 gRPC 플러그인을 통한 확장 기능을 제공하는 것에 중점을 둔다.
Linkerd2는 다른 서비스 메시를 모두 지원하기로 선택했을 가능성이 높지만 다음과 같은 대체 가능한 서비스 프록시 중 하나와 함께 이스티오를 사용하기를 원할 것이다.
Linkerd
이미 Linkerd를 실행 중이고 동작을 수행하기 전에 승인 또는 거절을 수행하는 Check Request와 같은 이스티오 제어 API를 채택할 경우 이 기능을 사용할 수 있다.
NginX
NginX 운영에 관한 전문성과 실저 테스트 프록시의 필요에 따라 NginX를 선택할 수 도 있다. 캐싱, 웹 애프리케이션 방화벽 또는 NginX Plus에서 제공하는 기타 기능도 필요할 것이다.
Consul Connect
배포의 용이성과 요구의 단순함 때문에 Consul Connect를 배포할 수도 있다.
ㅇ 확장 가능 어댑터
이스티오의 믹서 컨트롤 플레인 구성 요소는 서비스 메시 전체에서 접근 제어 및 사용 정책을 시행하고 사이드카 프록시에서 원격 측정 데이터를 수집한다.
이스티오 확정성의 주요 포인트인 믹서는 아래 그램에서 표시된 대로 소비 데이터 유형을 기준으로 어댑터를 분류한다.
믹서 어댑터의 프로세스 내 어댑터(In-Process Adapter) 작성 모델은 이제 이스티오에서 더 이상 사용되지 않는 개념이다. 이전의 다른 오픈소스 프로젝트와 마찬가지로 이스티오는 어댑터를 트리 내로 편리하게 통합하기 시작했다.
이스티오가 발전하고 성숙함에 따라 이 모델은 핵심 프로젝트 팀의 부담을 제거하고 일반적으로 다른 백엔드에 대한 통합용 어댑터를 만들던 개별 개발 팀의 오너십을 장려하기 위해 어댑터를 기본 프로젝트와 분리하는 모델로 변환 했다.
향후 확장성을 위해 HSM을 위한 보안 키 저장소와 분산 추적 인프라 백엔드 교체에 대한 지원 향상 등이 지원될 예정이다.
ㅁ 규모와 성능
서비스당 프록시를 실행하고 각 패킷을 가로채려면 일정량의 연속 오버헤드가 발생한다. 데이터 및 컨트롤 플레인을 통해 비용을 분석할 수 있다.
이스티오의 기능수에 따라 필요한 리소스가 다르며( https://oreil.ly/9puvE )
Performance and Scalability
Istio performance and scalability summary.
istio.io
일부 비용/자원은 다음과 같다.
* 접근 로깅을 사용하는 사이드카 프록시로 초당 최대 1,000회 요청당 1개의 가상 CPU(vCPU) 및 동일한 조건에서 접근 로깅을 사용하지 않으면 0.5vCPU가 필요하다. 노드에 Fluentd를 설치하면 로그 캡처와 업로드로 인해 해당 비용이 크게 증가한다.
* 믹서 검사에 대한 일반적인 캐시 적중률(>80%)을 가정하면 믹서 파드에 대한 초당 최대 1,000회 요청당 0.5 vCPU가 필요하다.
* 90번째 백분위 수(90th percentile latency) 대기 시간에 약 8ms가 추가된다.
* mTLS 비용은 CPU 및 대기 시간 측면에서 AES-NI 지원 하드웨어에서는 무시할 수 있다.
ㅁ 배포 모델
서비스 메시는 다양한 모양과 크기로 제공된다. 다른 메시 배포 모델을 살펴 보려면 서비스 메시 아키텍처의 엔터프라이즈 경로 ( https://oreil.ly/70pu7 )를 참조하라.
https://layer5.io/books/the-enterprise-path-to-service-mesh-architectures/?utm_source=iur&utm_medium=book&utm_campaign=up_run
layer5.io
