배포 후 Mendix Kubernetes에 대한 애플리케이션에서 수신된 트래픽은 예측할 수 없는 방식으로 변경될 수 있습니다. 앱을 항상 반응성 있게 유지하려면 어떻게 해야 합니까?

여기서 스케일링이 작용합니다. 트래픽 급증이든 일반 사용이든 클러스터가 부하를 우아하게 처리하기를 원합니다. Mendix Private Cloud는 수요에 맞게 포드 수를 동적으로 조정하여 이를 용이하게 합니다. Connected 제공에서 개발자 포털에서 수동으로 수행하거나 Kubernetes 클러스터에서 직접 Horizontal Pod Autoscaler를 활성화하여 수행할 수 있습니다. 꽤 멋지죠?

이 블로그에서는 자동 크기 조정을 구현하는 방법을 알아봅니다. Mendix 애플리케이션별 사용자 지정 메트릭을 기반으로 하는 애플리케이션입니다. Horizontal Pod Autoscaler와 Cluster Autoscaler를 조합하여 사용합니다. 하지만 잠깐만요, 더 많은 것이 있나요? 네, 멋진 Grafana 대시보드입니다. 재단사 을 통한 Mendix Private Cloud를 사용하면 모든 일이 실시간으로 발생하는 것을 시각화할 수 있습니다!

쿠버네티스의 자동 확장에는 무엇이 포함됩니까?

시작하기 위해, 쿠버네티스에서 "자동 확장"이라는 용어의 사용을 자세히 살펴보겠습니다. 쿠버네티스에서는 다음을 포함하여 여러 가지를 "자동 확장"이라고 합니다.

• 수평 포드 자동 스케일러(HPA) – 애플리케이션의 복제본 수를 조정합니다.
• 수직 Pod 자동 확장기(VPA)) – 컨테이너의 리소스 요청 및 제한을 조정합니다. VPA는 다음 맥락에서 권장되는 자동 확장 전략이 아니라는 점에 유의하세요. Mendix 강력히 권장하지 않습니다.
• 클러스터 자동 확장기(CA) – 클러스터의 노드 수를 조정합니다.

Mendix Private Cloud는 위의 모든 것을 지원하지만, 모두 매우 다른 사용 사례를 다루고 있으며 서로 다른 개념과 메커니즘을 사용합니다.

효과적인 확장을 위한 전략을 살펴보겠습니다.

스케일링 전략

주어진 수요에 대한 최적의 복제본 수를 어떻게 얻을 수 있습니까? 앱이 현재 겪고 있는 수요를 수치로 표시하면 좋지 않겠습니까?

확장을 위해 적합한 지표는 앱의 현재 부하를 나타내는 측정값입니다.
적합한 확장 측정 항목의 몇 가지 예는 다음과 같습니다.

• 각 복제본이 초당 수신한 요청 수입니다.
• 앱 프로세스의 CPU 및/또는 메모리 사용량.

(참고: Mendix 런타임은 메모리를 미리 할당하고 일반적으로 해제하지 않는 Java 기반이므로 메모리 기반 메트릭은 자동 크기 조정에 사용해서는 안 됩니다.)

여기서 핵심은 최적의 메트릭 값을 찾는 것입니다(이를 다음과 같이 부르겠습니다. 목표치) 애플리케이션이 과도하게 활용되거나 활용도가 낮지 않은 경우입니다. 안타깝게도 모든 애플리케이션이 다르게 동작하기 때문에 말하기는 쉽지만 실천하기는 어렵습니다.

예를 들어 최대 80% CPU 사용량을 지정하면 HPA 컨트롤러는 이 복제본 세트 내의 모든 포드의 평균 사용량이 80% 이상에 도달하자마자 포드를 추가합니다. 여기서 중요한 요소는 다음이 있는지 여부입니다. 올바르게 구성 포드에 대한 리소스 요청 및 제한. 그러면 우리의 스케일링 전략은 다음과 같아야 합니다.

• 관찰된 값이 목표 값보다 낮으면(즉, 앱이 과소 활용됨), 복제본 수를 줄여 각 복제본이 더 높은 활용도를 얻도록 해야 합니다. 이렇게 하면 메트릭 값이 증가하고 목표 값에 가까워집니다.
• 관찰된 값이 목표 값보다 높은 경우(즉, 앱이 과도하게 활용되는 경우), 복제본 수를 늘려 각 복제본이 전체 부하에서 차지하는 비중을 줄여야 합니다. 이렇게 하면 메트릭 값이 감소하고 목표 값에 가까워집니다.

리소스 요청 및 제한 기본 사항

쿠버네티스를 사용하면 단일 Pod에 필요한 CPU/RAM 양을 지정하고 주어진 Pod에 대한 이러한 리소스 사용을 제한하는 방법을 지정할 수 있습니다. Mendix 개인 클라우드의 경우 이를 통해 쉽게 구성할 수 있습니다. 개발자 포털 또는 독립 실행형 서비스를 사용하는 고객의 경우 편집 MendixCR 목적.

메모리 유닛

• 메모리 단위는 일반적으로 바이트로 표현되지만, 단순화를 위해 Kubernetes에서는 메가바이트(MB)나 기가바이트(GB)와 같이 사람이 더 읽기 쉬운 형식을 사용할 수 있습니다.
• 다음 접미사를 사용하여 메모리 단위를 나타낼 수 있습니다.
  • "Mi"는 메비바이트(2^20바이트)를 의미합니다.
  • 기비바이트(2^30바이트)를 의미하는 "Gi"
  • "M"은 메가바이트를 의미합니다.
  • "G"는 기가바이트를 의미합니다.

CPU 유닛

• Kubernetes의 CPU 단위는 CPU 코어의 일부인 "밀리코어"로 측정됩니다.
• 1개의 CPU 코어는 1000개의 밀리코어와 같습니다.
• "m" 접미사를 사용하여 밀리코어를 나타내면 CPU 요청 및 제한을 지정할 수 있습니다.

예

• 100m은 100개의 밀리코어를 나타내며, 이는 CPU 코어 0.1개입니다.
• 500m은 500개의 밀리코어를 나타내며, 이는 CPU 코어 0.5개입니다.

CPU는 절대적인 단위입니다. 즉, 노드에 코어가 몇 개 있든 1개의 CPU는 동일합니다.

Mendix 애플리케이션 배포는 다음과 같은 소형 템플릿 값으로 구성됩니다.

• CPU 요청 100m
• 512Mi의 메모리 요청

자동 확장 시뮬레이션

이 게시물의 목적은 다음과 같습니다.

• 수신된 트래픽의 증가를 시뮬레이션합니다. Mendix Kubernetes 클러스터에 호스팅된 애플리케이션입니다.
• 수평 Pod 자동 확장기를 구성하여 Pod 수를 확장합니다. Mendix 라이브에서의 애플리케이션 복제본 Mendix Kubernetes 환경에서 실행 중 Mendix Private Cloud Connected 모드를 위한 것입니다.
• 클러스터 자동 확장기를 구성하여 새 복제본을 할당하기 위해 클러스터 노드 수를 확장합니다. Mendix 응용 프로그램.

이 예제 환경에서는 내가 호스팅할 것입니다. Mendix Azure AKS의 클러스터. 다른 지원되는 Mx4PC 클러스터 유형의 경우 CA 기능을 구성하는 공급업체의 권장 방법을 따르세요.

배포 방법에 대한 자세한 내용은 Mendix 신청서를 작성하려면 이 가이드를 확인하세요: https://docs.mendix.com/developerportal/deploy

시작하기 전에 몇 가지 전제 조건을 검토하는 것이 좋습니다. 다음을 수행해 보세요.

• 활성화된 수평 Pod 자동 확장기 귀하의 Mendix 환경?
• 클러스터 자동 확장 기능을 활성화하셨나요?
• Kubernetes 메트릭 서버 설치됨 귀하의 클러스터에는?

수평 Pod 자동 확장기 구성

HPA를 활성화하고 메트릭을 CPU 사용률 임계값 80%로 설정해 보겠습니다.

# kubectl -n mendix-app autoscale mendixapp blogapp1-master --cpu-percent=80 --min=1 --max=3
horizontalpodautoscaler.autoscaling/blogapp1 autoscaled

클러스터 자동 확장기(CA) 구성

CA를 활성화할 수 있습니다 명령 줄에서 또는에서 Azure 포털. 이 예에서는 최대 노드 수를 3으로 설정합니다.

트래픽을 생성합니다!

다음 비디오에서 왼쪽 상단에서 내가 직접 트래픽을 생성하는 것을 볼 수 있습니다. Mendix 1000분 동안 XNUMX개의 동시 연결을 보내어 응용 프로그램을 만듭니다. 이 도구를 임시 포드 안에 있지만, 똑같은 일을 할 수 있는 다른 포드도 많이 있습니다!

Kubernetes 클러스터의 수평 Pod 자동 확장기 뷰

Grafana 대시보드에서 동일한 시퀀스가 ​​어떻게 보이는지 살펴보겠습니다.

Grafana 대시보드의 수평 Pod 자동 확장기 보기

우리가 1000개의 동시 요청을 보내기 시작하면 Mendix 응용 프로그램에서 우리는 다음 사항을 관찰합니다:

1. CPU 사용량 블로그앱1-마스터 응용 프로그램은 8m에서 100m 이상까지 가능합니다(오른쪽 상단 화면).
2. 따라서 수평형 포드 자동 크기 조정기 Pod 확장을 시작합니다.
3. 두 개의 Pod가 더 생성됩니다.
4. Pod 중 하나가 보류 중이므로 배포할 수 없습니다. 기존 노드에 Pod를 하나 더 할당할 공간이 충분하지 않습니다.
5. 몇 분 후 클러스터 자동 확장 처리 트리거되고 클러스터에 새 노드가 생성됩니다(오른쪽 하단 화면)
6. 따라서 대기중 Pod가 배포되었습니다.

자동 확장 리드 타임 탐색

모든 것이 어떻게 서로 연결되는지 이해하면서 마무리해 보겠습니다.

1. 수평형 Pod 자동 확장기 반응 시간.
   • 기본적으로, pod의 CPU 및 메모리 사용량은 kubelet에 의해 10초마다 스크래핑됩니다..
   • 매분마다 Metrics Server는 해당 메트릭을 집계합니다. 그리고 이를 Kubernetes API의 나머지 부분에 노출합니다.
   • 기본적으로 수평 Pod 자동 확장기는 15초마다 Pod 메트릭을 확인합니다..
   • 최악의 경우, Horizontal Pod Autoscaler가 자동 크기 조정을 시작하는 데 최대 1분 10초가 걸릴 수 있습니다(즉, 60초 + 15초 + XNUMX초).
2. 클러스터 자동 확장기 반응 시간.
   • 클러스터 자동 확장기 10초마다 클러스터에서 예약되지 않은 Pod를 확인합니다..
   • 각각 최대 30개의 포드가 있는 100개 이하의 노드가 있는 클러스터에서는 전체 프로세스가 약 30초 정도 걸립니다.
3. 노드 프로비저닝 시간입니다.
   • 그리고, 노드 프로비저닝 시간은 주로 클라우드 제공자에 따라 달라집니다.
   • 새로운 컴퓨팅 리소스가 3~5분 내에 프로비저닝되는 것은 일반적입니다.
4. Mendix Pod 생성 시간.
   • 시작 중 Mendix 일반적으로 런타임은 30초 이상 걸리지 않습니다.

최악의 경우 총 지연은 최대 7분까지 될 수 있습니다. 나쁘지 않죠? 하지만, 더 많은 포드를 받기 전까지 7분 동안 갑자기 교통량이 급증하는 것을 처리할 수 있나요?

자동 크기 조정을 조정하여 크기 조정 시간을 줄일 수 있는 방법이 있나요?

다음 기본값 중 일부를 조정해보세요.

• HPA의 기본 새로 고침 시간은 다음에 의해 제어됩니다. 수평-포드-자동 크기 조정기-동기화 기간 (기본값 15초).
• Metrics Server에서 메트릭 스크래핑을 위한 간격은 다음에 의해 제어됩니다. 메트릭 해상도 플래그 (기본값 60초).
• 할당되지 않은 Pod에 대한 클러스터 자동 확장기 반응 시간은 다음에 의해 제어됩니다. 스캔 간격 플래그 (기본값 10초).

마무리 단어

Kubernetes 클러스터에서 확장 및 성장 처리가 처음에는 어려운 작업처럼 보일 수 있지만 올바른 전략과 제공되는 기능을 활용하면 가능합니다. Mendix 프라이빗 클라우드의 경우, 당신은 이 흥미로운 여정을 탐색할 준비가 되어 있습니다. 핵심은 더 많은 노드를 추가하는 것과 당신이 가진 노드를 최적화하는 것 사이의 달콤한 지점을 찾는 것입니다.

현명한 사람들에게 마지막 한마디 –  Mendix 앱은 앱 컨테이너 집약형에 비해 상대적으로 데이터베이스를 집약적으로 사용하는 경향이 있으므로 데이터베이스도 (자동) 확장해야 합니다.

즐거운 스케일링 되세요!