プライベート クラウド インフラストラクチャを拡張する方法: 成長に対応するための戦略 | Mendix

メインコンテンツへスキップ

サイト内検索

営業担当者へ連絡
無料でお試し

プライベート クラウド インフラストラクチャを拡張する方法: 成長に対応するための戦略

コードがソース管理にコミットされてからクラウド環境にデプロイされるまでの間に、多くのことが起こります。単純なアプリケーションから始めても、将来の拡張性を考慮せずにインフラストラクチャ アーキテクチャを構築すると、アプリケーションが成長し始めたときにさまざまな問題が発生する可能性があります。

導入後 Mendix アプリケーションを Kubernetes に移行すると、受信トラフィックが予期しない形で変化する可能性があります。アプリの応答性を常に維持するにはどうすればよいでしょうか?

ここでスケーリングが役立ちます。トラフィックの急増であれ、通常の使用であれ、クラスターが負荷を適切に処理できるようにする必要があります。 Mendix for Private Cloud は、需要に合わせてポッドの数を動的に調整することでこれを実現します。Connected サービスでは、開発者ポータルから手動で行うことも、Kubernetes クラスターで Horizo​​ntal Pod Autoscaler を直接有効にすることもできます。とてもクールだと思いませんか?

このブログでは、自動スケーリングを実装する方法を学びます。 Mendix アプリケーション固有のカスタムメトリックに基づいてアプリケーションを分析する。Horizo​​ntal Pod AutoscalerとCluster Autoscalerを組み合わせて使用​​します。しかし、それだけではありません。Grafanaダッシュボードも便利です。 オーダーメイド の Mendix プライベート クラウドでは、すべてがリアルタイムで発生しながら視覚化されます。

Kubernetes の自動スケーリングには何が含まれますか?

まず、Kubernetes における「自動スケーリング」という用語の使用について詳しく見てみましょう。Kubernetes では、次のようなものが「自動スケーリング」と呼ばれています。

Mendix プライベート クラウドでは上記のすべてをサポートしていますが、それぞれ非常に異なるユース ケースに対応し、異なる概念とメカニズムを使用します。

効果的なスケーリングのための戦略を検討してみましょう。

スケーリング戦略

特定の需要に対して最適なレプリカ数を取得するにはどうすればよいでしょうか? アプリが現在経験している需要を数値で示す指標があれば便利だと思いませんか?

スケーリングの場合、適切なメトリックは、アプリの現在の負荷を表す測定値です。
適切なスケーリング メトリックの例は次のとおりです。

  • 各レプリカが 1 秒あたりに受信するリクエストの数。
  • アプリのプロセスの CPU および/またはメモリの使用量。

（注： Mendix ランタイムは Java に基づいており、メモリを事前に割り当てて通常は解放しないため、メモリベースのメトリックは自動スケーリングには使用しないでください。

ここで重要なのは、最適なメトリック値（これを 目標値) は、アプリケーションが過剰にも過少にも使用されていない状態を指します。残念ながら、アプリケーションの動作はそれぞれ異なるため、これは言うほど簡単ではありません。

たとえば、CPUの最大使用率を80%に指定した場合、HPAコントローラーは、このレプリカセット内のすべてのポッドの平均使用率が80%以上に達するとすぐにポッドを追加します。ここで重要な要素は、 正しく構成されている ポッドのリソース要求と制限。スケーリング戦略は次のようになります。

  • 観測値が目標値を下回っている場合 (つまり、アプリが十分に活用されていない場合)、レプリカ数を減らして各レプリカの使用率を高める必要があります。これにより、メトリック値が増加し、目標値に近づきます。
  • 観測値が目標値を超えている場合 (つまり、アプリが過剰に使用されている場合)、レプリカ数を増やして各レプリカが受け取る合計負荷の割合を減らし、メトリック値を減らして目標値に近づける必要があります。

リソース要求と制限の基本

Kubernetesでは、単一のPodに必要なCPU/RAMの量を指定し、特定のPodでのこれらのリソースの使用を制限することができます。 Mendix プライベートクラウドの場合、これは当社の 開発者ポータル または、当社のスタンドアロン製品をご利用のお客様の場合は、 編集 MendixCR オブジェクト。

リソース要求と制限の基本
Mendix プライベートクラウド – リソース要求と制限の編集

メモリユニット

  • メモリ単位は通常バイトで表されますが、簡潔にするために、Kubernetes ではメガバイト (MB) やギガバイト (GB) などのより人間が読みやすい形式を使用できます。
  • メモリ ユニットを表すには、次のサフィックスを使用できます。
    • 「Mi」はメビバイト（2^20バイト）
    • 「Gi」はギビバイト（2^30バイト）を表します。
    • 「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 アプリケーションのデプロイメントは、次の小規模テンプレート値で構成されます。

  • 100mのCPUリクエスト
  • 512Mi のメモリ要求

Kubernetes コンピューティング リソース

自動スケーリングのシミュレーション

この投稿の目標は次のとおりです。

  • 受信トラフィックの増加をシミュレートする Mendix Kubernetes クラスターでホストされるアプリケーション。
  • Horizo​​ntal Pod Autoscalerを設定して、 Mendix ライブアプリケーションレプリカ Mendix Kubernetes環境が稼働中 Mendix プライベートクラウド接続モードの場合。
  • クラスタオートスケーラーを設定して、クラスタノードの数をスケーリングし、新しいレプリカを割り当てます。 Mendix アプリケーション。

この例の環境では、 Mendix Azure AKS のクラスター。サポートされているその他の Mx4PC クラスターの種類については、ベンダーが推奨する CA 機能の構成方法に従ってください。

導入方法の詳細については、 Mendix アプリケーションの詳細については、このガイドを参照してください。 https://docs.mendix.com/developerportal/deploy

始める前に、いくつかの前提条件を確認することをお勧めします。次のことを確認してください。

水平ポッドオートスケーラーの設定

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 クラスターからの水平ポッドオートスケーラービュー

同じシーケンスが Grafana ダッシュボードでどのように見えるかを見てみましょう。

Grafana ダッシュボードからの水平ポッドオートスケーラービュー

1000件の同時リクエストを送信し始めると、 Mendix アプリケーションでは、次のことがわかります。

  1. CPU使用率 blogapp1マスター アプリケーションは 8 m から 100 m 以上まで移動します (右上の画面)。
  2. 当学校区の 水平ポッドオートスケーラー ポッドのスケーリングを開始します。
  3. さらに 2 つのポッドが作成されます。
  4. ポッドの 1 つが保留中であるため、デプロイできません。既存のノードのどちらにも、さらに 1 つのポッドを割り当てるための十分なスペースがありません。
  5. 数分後、 クラスターオートスケーラー トリガーが実行され、クラスター内に新しいノードが作成されます (画面右下)
  6. 当学校区の 保留中 ポッドがデプロイされました。

自動スケーリングのリードタイムの​​調査

最後に、すべてがどのように結びついているのかを理解しましょう。

  1. 水平ポッドオートスケーラーの反応時間。
  2. クラスター オートスケーラーの反応時間。
  3. ノードのプロビジョニング時間。
    • 次に、ノードのプロビジョニング時間がありますが、これは主にクラウド プロバイダーによって異なります。
    • 新しいコンピューティング リソースが 3 ～ 5 分でプロビジョニングされるのは標準的なことです。
  4. Mendix ポッドの作成時間。
    • 起動 Mendix 通常、実行時間は 30 秒以内です。
リードタイム
リードタイム自動スケーリング

最悪の場合、合計で7分ほどの遅延が発生することがあります。悪くないですよね？しかし、 ポッドを追加する前に、7 分間のトラフィックの急増に対処できますか?

自動スケーリングを調整してスケーリング時間を短縮する方法はありますか?

次のデフォルト値のいくつかを調整してみてください。

閉じた言葉

Kubernetesクラスタのスケーリングと成長への対応は、最初は困難な作業のように思えるかもしれませんが、適切な戦略とKubernetesが提供する機能を活用することで、 Mendix プライベート クラウドの場合、このエキサイティングな旅をうまく進めるための準備は万端です。鍵となるのは、ノードの追加と既存のノードの最適化の間の最適なバランスを見つけることです。

最後に賢者への一言 –  Mendix アプリは、アプリ コンテナーを集中的に使用するよりも、比較的データベースを集中的に使用する傾向があるため、データベースも (自動) スケーリングするようにしてください。

スケーリングを楽​​しんでください！

言語を選択してください