2.18. 성능 및 확장
기본 ServiceMeshControlPlane
설정은 프로덕션용이 아닙니다. 이 설정은 리소스가 매우 제한된 환경인 기본 OpenShift Container Platform 설치 시 성공적으로 설치되도록 설계되었습니다. SMCP 설치에 성공했는지 확인한 후 SMCP 내에 정의된 설정을 사용자 환경에 맞게 수정해야 합니다.
2.18.1. 컴퓨팅 리소스에 제한 설정
기본적으로 spec.proxy
설정은 cpu: 10m
및 memory: 128M
입니다. Pilot을 사용하는 경우 spec.runtime.components.pilot
의 기본값이 동일합니다.
다음 예의 설정은 초당 1,000개의 서비스 및 1,000개의 요청을 기반으로 합니다. ServiceMeshControlPlane
에서 cpu
및 memory
값을 변경할 수 있습니다.
프로세스
-
OpenShift Container Platform 웹 콘솔에서 Operator
설치된 Operator를 클릭합니다. - 프로젝트 메뉴를 클릭하고 Service Mesh Control Plane을 설치한 프로젝트(예: istio-system )를 선택합니다.
-
Red Hat OpenShift Service Mesh Operator를 클릭합니다. Istio Service Mesh Control Plane 열에서
ServiceMeshControlPlane
의 이름을 클릭합니다(예:basic
). 독립형 Jaeger 인스턴스의 이름을
ServiceMeshControlPlane
에 추가합니다.- YAML 탭을 클릭합니다.
ServiceMeshControlPlane
리소스에서spec.proxy.runtime.container.resources.cpu
,spec.proxy.runtime.container.resources.requests.memory
,components.kiali.container
,components.global.oauthproxy
의 값을 설정합니다.버전 2.6 ServiceMeshControlPlane 예
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.6 proxy: runtime: container: resources: requests: cpu: 600m memory: 50Mi limits: {} runtime: components: pilot: container: resources: requests: cpu: 1000m memory: 1.6Gi limits: {} kiali: container: resources: limits: cpu: "90m" memory: "245Mi" requests: cpu: "30m" memory: "108Mi" global.oauthproxy: container: resources: requests: cpu: "101m" memory: "256Mi" limits: cpu: "201m" memory: "512Mi"
- Red Hat OpenShift 분산 추적 플랫폼(Jaeger)의 값을 설정하려면 "분산 추적 플랫폼 Jaeger 구성 및 배포"를 참조하십시오.
- 저장을 클릭합니다.
검증
-
다시 로드 를 클릭하여
ServiceMeshControlPlane
리소스가 올바르게 구성되었는지 확인합니다.
추가 리소스
2.18.2. 로드 테스트 결과
업스트림 Istio 커뮤니티 로드 테스트 메시는 초당 70,000개의 메시 전체 요청이 있는 1000개의 서비스와 2000개의 사이드카로 구성됩니다. Istio 1.12.3을 사용하여 테스트를 실행하면 다음 결과가 생성됩니다.
- Envoy 프록시는 프록시를 통과하는 초당 1000개의 요청당 0.35 vCPU 및 40MB 메모리 를 사용합니다.
- Istiod는 1개의 vCPU 및 1.5GB 메모리를 사용합니다.
- Envoy 프록시는 2.65ms 를 90번째 백분위 대기 시간에 추가합니다.
-
레거시
istio-telemetry
서비스(기본적으로 Service Mesh 2.0에서 비활성화됨)는 Mixer를 사용하는 배포에 대해 초당 1,000 개의 메시 전체 요청마다 0.6 vCPU를 사용합니다. 데이터 플레인 구성 요소인 Envoy 프록시는 시스템을 통과하는 데이터를 처리합니다. Service Mesh Control Plane 구성 요소 Istiod는 데이터 플레인을 구성합니다. 데이터 플레인과 컨트롤 플레인에는 별도의 성능 문제가 있습니다.
2.18.2.1. 서비스 메시 컨트롤 플레인 성능
Istiod는 사용자가 승인한 구성 파일 및 시스템의 현재 상태를 기반으로 사이드카 프록시를 구성합니다. Kubernetes 환경에서 CRD(Custom Resource Definitions)와 배포는 시스템의 구성 및 상태를 구성합니다. 게이트웨이 및 가상 서비스와 같은 Istio 구성 오브젝트는 사용자 인증된 구성을 제공합니다. 프록시에 대한 구성을 생성하기 위해 Istiod는 Kubernetes 환경과 사용자 인증된 구성에서 결합된 구성 및 시스템 상태를 처리합니다.
Service Mesh Control Plane은 수천 개의 서비스를 지원하며 유사한 수의 사용자 인증된 가상 서비스 및 기타 구성 오브젝트를 사용하여 수천 개의 Pod에 분산됩니다. Istiod의 CPU 및 메모리 요구 사항은 구성 수와 가능한 시스템 상태에 따라 확장됩니다. CPU 사용량은 다음과 같은 요인에 따라 확장됩니다.
- 배포 변경 비율.
- 구성 변경 비율.
- Istiod에 연결된 프록시 수.
그러나 이 부분은 기본적으로 수평 확장할 수 있습니다.
2.18.2.2. 데이터 플레인 성능
데이터 플레인 성능은 여러 요인에 따라 달라집니다. 예를 들면 다음과 같습니다.
- 클라이언트 연결 수
- 대상 요청 속도
- 요청 크기 및 응답 크기
- 프록시 작업자 스레드 수
- 프로토콜
- CPU 코어 수
- 프록시 필터, 특히 telemetry v2 관련 필터의 수 및 유형입니다.
대기 시간, 처리량, 프록시 CPU 및 메모리 사용은 이러한 요인의 기능으로 측정됩니다.
2.18.2.2.1. CPU 및 메모리 사용
사이드카 프록시는 데이터 경로에서 추가 작업을 수행하므로 CPU와 메모리를 사용합니다. Istio 1.12.3부터 프록시는 초당 1000개의 요청당 약 0.5 vCPU를 사용합니다.
프록시의 메모리 사용은 프록시가 보유하고 있는 총 구성 상태에 따라 달라집니다. 다수의 리스너, 클러스터 및 경로를 통해 메모리 사용량을 늘릴 수 있습니다.
프록시는 일반적으로 통과된 데이터를 버퍼링하지 않기 때문에 요청 속도는 메모리 소비에 영향을 미치지 않습니다.
2.18.2.2.2. 추가 대기 시간
Istio가 데이터 경로에 사이드카 프록시를 삽입하기 때문에 대기 시간이 중요합니다. Istio는 인증 필터, telemetry 필터 및 메타데이터 교환 필터를 프록시에 추가합니다. 모든 추가 필터는 프록시 내부의 경로 길이를 추가하고 대기 시간에 영향을 미칩니다.
Envoy 프록시는 응답이 클라이언트에 전송된 후 원시 telemetry 데이터를 수집합니다. 요청을 위해 원시 Telemetry를 수집하는 데 소요되는 시간은 해당 요청을 완료하는 데 걸리는 총 시간에 기여하지 않습니다. 그러나 작업자가 요청을 처리하느라 바쁘기 때문에 작업자는 즉시 다음 요청 처리를 시작하지 않습니다. 이 프로세스는 다음 요청의 대기열 대기 시간에 추가되며 평균 및 테일 대기 시간에 영향을 미칩니다. 실제 정확한 대기 시간은 트래픽 패턴에 따라 달라집니다.
메시 내부에서 요청은 클라이언트 측 프록시를 통과한 다음, 서버 측 프록시를 통과합니다. Istio 1.12.3(즉, Telemetry v2가 있는 Istio)의 기본 구성에서 두 프록시는 기준 데이터 플레인 대기 시간에서 각각 약 1.7ms 및 2.7ms를 90번째 및 99번째 백분위 대기 시간에 추가합니다.