GKE에서 Cloud Service Mesh 확장 권장사항

이 가이드에서는 Google Kubernetes Engine에서 관리형 Cloud Service Mesh 아키텍처의 확장 문제를 해결하기 위한 권장사항을 설명합니다. 이러한 권장사항의 기본 목표는 마이크로서비스 애플리케이션이 성장함에 따라 최적의 성능, 안정성, 리소스 활용을 보장하는 것입니다.

확장성 제한사항을 알아보려면 Cloud Service Mesh 확장성 제한사항을 참고하세요.

GKE의 Cloud Service Mesh 확장성은 두 가지 기본 구성요소인 데이터 영역과 컨트롤 플레인의 효율적인 작동에 따라 달라집니다. 이 문서에서는 주로 데이터 영역 확장에 중점을 둡니다.

제어 영역과 데이터 영역 확장 문제 식별

Cloud Service Mesh에서는 컨트롤 플레인 또는 데이터 영역에서 확장 문제가 발생할 수 있습니다. 다음은 발생한 확장 문제의 유형을 파악하는 방법입니다.

제어 영역 확장 문제의 증상

느린 서비스 검색: 새 서비스 또는 엔드포인트를 검색하고 사용할 수 있게 되기까지 시간이 오래 걸립니다.

구성 지연: 트래픽 관리 규칙 또는 보안 정책을 변경하는 데 시간이 오래 걸립니다.

컨트롤 플레인 작업의 지연 시간 증가: Cloud Service Mesh 리소스 생성, 업데이트, 삭제와 같은 작업이 느려지거나 응답하지 않게 됩니다.

Traffic Director 관련 오류: Cloud Service Mesh 로그 또는 컨트롤 플레인 측정항목에 연결, 리소스 소진 또는 API 제한과 관련된 오류가 표시될 수 있습니다.

영향 범위: 제어 영역 문제는 일반적으로 전체 메시에 영향을 미쳐 광범위한 성능 저하를 일으킵니다.

데이터 영역 확장 문제의 증상

서비스 간 통신 지연 시간 증가: 메시 내 서비스에 대한 요청에서 지연 시간 또는 시간 초과가 발생하지만 서비스 컨테이너의 CPU/메모리 사용량은 증가하지 않습니다.

Envoy 프록시의 높은 CPU 또는 메모리 사용량: CPU 또는 메모리 사용량이 높으면 프록시가 트래픽 부하를 처리하는 데 어려움을 겪고 있음을 나타낼 수 있습니다.

지역화된 영향: 데이터 영역 문제는 일반적으로 Envoy 프록시의 트래픽 패턴 및 리소스 사용량에 따라 특정 서비스 또는 워크로드에 영향을 미칩니다.

데이터 영역 확장

데이터 영역을 확장하려면 다음 기법을 시도해 보세요.

워크로드에 수평형 포드 자동 확장 (HPA) 구성

수평형 포드 자동 확장 처리 (HPA)를 사용하여 리소스 사용률에 따라 추가 포드로 워크로드를 동적으로 확장합니다. HPA를 구성할 때 다음 사항을 고려하세요.

  • --horizontal-pod-autoscaler-sync-period 매개변수를 사용하여 kube-controller-manager를 조정하여 HPA 컨트롤러의 폴링 속도를 조정합니다. 기본 폴링 레이트는 15초이며 트래픽 급증이 더 빨리 발생할 것으로 예상되는 경우 이 값을 더 낮게 설정하는 것이 좋습니다. GKE에서 HPA를 사용해야 하는 경우에 관한 자세한 내용은 수평형 포드 자동 확장을 참고하세요.

  • 기본 확장 동작으로 인해 한 번에 많은 수의 포드가 배포 (또는 종료)되어 리소스 사용량이 급증할 수 있습니다. 확장 정책을 사용하여 포드를 배포할 수 있는 속도를 제한해 보세요.

  • EXIT_ON_ZERO_ACTIVE_CONNECTIONS를 사용하여 스케일 다운 중에 연결이 끊어지지 않도록 합니다.

HPA에 관한 자세한 내용은 Kubernetes 문서의 수평형 포드 자동 확장을 참고하세요.

Envoy 프록시 구성 최적화

Envoy 프록시 구성을 최적화하려면 다음 권장사항을 고려하세요.

리소스 한도

포드 사양에서 Envoy 사이드카의 리소스 요청 및 한도를 정의할 수 있습니다. 이렇게 하면 리소스 경합을 방지하고 일관된 성능을 보장할 수 있습니다.

리소스 주석을 사용하여 메시의 모든 Envoy 프록시에 기본 리소스 한도를 구성할 수도 있습니다.

Envoy 프록시에 가장 적합한 리소스 한도는 트래픽 양, 워크로드 복잡성, GKE 노드 리소스와 같은 요인에 따라 다릅니다. 서비스 메시를 지속적으로 모니터링하고 미세 조정하여 최적의 성능을 보장합니다.

중요 고려사항:

  • 서비스 품질 (QoS): 요청과 한도를 모두 설정하면 Envoy 프록시의 서비스 품질을 예측할 수 있습니다.

서비스 종속 항목 범위 지정

Sidecar API를 통해 모든 종속 항목을 선언하여 메시의 종속 항목 그래프를 다듬어 보세요. 이렇게 하면 특정 워크로드로 전송되는 구성의 크기와 복잡성이 제한되며, 이는 대규모 메시에 매우 중요합니다.

다음은 온라인 부티크 샘플 애플리케이션의 트래픽 그래프입니다.

리프가 많은 Online Boutique 샘플 애플리케이션 트래픽 그래프 트리

이러한 서비스의 대부분은 그래프의 리프이므로 메시의 다른 서비스에 대한 이그레스 정보가 필요하지 않습니다. 다음 예와 같이 이러한 리프 서비스의 사이드카 구성 범위를 제한하는 사이드카 리소스를 적용할 수 있습니다.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

이 샘플 애플리케이션을 배포하는 방법에 관한 자세한 내용은 Online Boutique 샘플 애플리케이션을 참고하세요.

사이드카 범위 지정의 또 다른 이점은 불필요한 DNS 쿼리를 줄이는 것입니다. 서비스 종속 항목의 범위를 지정하면 Envoy 사이드카가 서비스 메시의 모든 클러스터 대신 실제로 통신할 서비스에 대해서만 DNS 쿼리를 실행합니다.

사이드카의 구성 크기가 큰 문제에 직면한 대규모 배포의 경우 메시 확장성을 위해 서비스 종속 항목의 범위를 지정하는 것이 적극적으로 권장됩니다.

모니터링 및 미세 조정

초기 리소스 제한을 설정한 후에는 Envoy 프록시가 최적으로 작동하는지 모니터링하는 것이 중요합니다. GKE 대시보드를 사용하여 CPU 및 메모리 사용량을 모니터링하고 필요에 따라 리소스 한도를 조정합니다.

Envoy 프록시에 리소스 한도 증가가 필요한지 확인하려면 일반적인 트래픽 조건과 최대 트래픽 조건에서 리소스 사용량을 모니터링합니다. 다음 사항을 확인해 보세요.

  • CPU 사용량이 높음: Envoy의 CPU 사용량이 한도에 지속적으로 접근하거나 한도를 초과하면 요청을 처리하는 데 어려움이 있어 지연 시간이 늘어나거나 요청이 삭제될 수 있습니다. CPU 한도를 늘려보세요.

    이 경우 가로 확장을 사용하여 확장하고 싶을 수 있지만, 사이드카 프록시가 애플리케이션 컨테이너만큼 빠르게 요청을 처리하지 못하는 경우 CPU 한도를 조정하면 최상의 결과를 얻을 수 있습니다.

  • 메모리 사용량이 많음: Envoy의 메모리 사용량이 한도에 근접하거나 한도를 초과하면 연결이 끊어지거나 메모리 부족 (OOM) 오류가 발생할 수 있습니다. 이러한 문제를 방지하려면 메모리 한도를 늘리세요.

  • 오류 로그: 업스트림 연결 오류, 헤더 전에 연결 해제 또는 재설정, 열려 있는 파일 수가 너무 많음 오류와 같이 리소스 소진과 관련된 오류가 있는지 Envoy 로그를 검사합니다. 이러한 오류는 프록시에 더 많은 리소스가 필요함을 나타낼 수 있습니다. 확장 문제와 관련된 다른 오류는 확장 문제 해결 문서를 참고하세요.

  • 실적 측정항목: 요청 지연 시간, 오류율, 처리량과 같은 주요 실적 측정항목을 모니터링합니다. 높은 리소스 사용량과 관련된 성능 저하가 발생하면 한도를 늘려야 할 수 있습니다.

데이터 영역 프록시의 리소스 제한을 적극적으로 설정하고 모니터링하면 GKE에서 서비스 메시를 효율적으로 확장할 수 있습니다.

복원력 구축

다음 설정을 조정하여 제어 영역을 확장할 수 있습니다.

이상점 감지

이상점 감지는 업스트림 서비스의 호스트를 모니터링하고 특정 오류 기준점에 도달하면 부하 분산 풀에서 호스트를 삭제합니다.

  • 키 구성:
    • outlierDetection: 부하 분산 풀에서 비정상 호스트 제거를 제어하는 설정입니다.
  • 이점: 부하 분산 풀에 정상적인 호스트 집합을 유지합니다.

자세한 내용은 Istio 문서의 이상치 감지를 참고하세요.

재시도

실패한 요청을 자동으로 재시도하여 일시적인 오류를 완화합니다.

  • 키 구성:
    • attempts: 재시도 횟수입니다.
    • perTryTimeout: 재시도당 제한 시간입니다. 전체 제한 시간보다 짧게 설정합니다. 각 재시도 시도에 대해 대기할 시간을 결정합니다.
    • retryBudget: 최대 동시 재시도 수입니다.
  • 이점: 요청 성공률이 높아지고 간헐적인 실패의 영향이 줄어듭니다.

고려해야 할 요소:

  • 멱등성: 재시도되는 작업이 멱등성을 갖는지 확인합니다. 즉, 의도하지 않은 부작용 없이 반복할 수 있어야 합니다.
  • 최대 재시도 횟수: 무한 루프를 방지하기 위해 재시도 횟수를 제한합니다 (예: 최대 3회 재시도).
  • 회로 차단: 재시도를 회로 차단기와 통합하여 서비스가 지속적으로 실패할 때 재시도를 방지합니다.

자세한 내용은 Istio 문서의 재시도를 참고하세요.

제한 시간

제한 시간을 사용하여 요청 처리에 허용되는 최대 시간을 정의합니다.

  • 키 구성:
    • timeout: 특정 서비스의 요청 제한 시간입니다.
    • idleTimeout: 연결이 닫히기 전에 유휴 상태로 유지될 수 있는 시간입니다.
  • 이점: 시스템 응답성 개선, 리소스 누수 방지, 악의적인 트래픽에 대한 강화

고려해야 할 요소:

  • 네트워크 지연 시간: 서비스 간의 예상 왕복 시간 (RTT)을 고려합니다. 예기치 않은 지연에 대비해 여유를 두세요.
  • 서비스 종속 항목 그래프: 체이닝된 요청의 경우 호출 서비스의 제한 시간이 종속 항목의 누적 제한 시간보다 짧아야 연쇄 실패를 방지할 수 있습니다.
  • 작업 유형: 장기 실행 작업에는 데이터 검색보다 훨씬 긴 제한 시간이 필요할 수 있습니다.
  • 오류 처리: 제한 시간은 적절한 오류 처리 로직(예: 재시도, 대체, 회로 차단)을 트리거해야 합니다.

자세한 내용은 Istio 문서의 제한 시간을 참고하세요.

모니터링 및 미세 조정

제한 시간, 이상치 감지, 재시도의 기본 설정으로 시작하여 특정 서비스 요구사항 및 관찰된 트래픽 패턴에 따라 점진적으로 조정하는 것이 좋습니다. 예를 들어 서비스가 응답하는 데 일반적으로 걸리는 시간에 관한 실제 데이터를 살펴보세요. 그런 다음 각 서비스 또는 엔드포인트의 특정 특성에 맞게 제한 시간을 조정합니다.

원격 분석

원격 분석을 사용하여 서비스 메시를 지속적으로 모니터링하고 구성을 조정하여 성능과 안정성을 최적화합니다.

  • 측정항목: 포괄적인 측정항목, 특히 요청 수, 지연 시간, 오류율을 사용합니다. 시각화 및 알림을 위해 Cloud Monitoring과 통합합니다.
  • 분산형 추적: Cloud Trace와 분산형 추적 통합을 사용 설정하여 서비스 전반의 요청 흐름에 대한 심층적인 통계를 얻습니다.
  • 로깅: 액세스 로깅을 구성하여 요청 및 응답에 관한 세부정보를 캡처합니다.

추가 자료