次の方法で共有

Azure Kubernetes Service (AKS) での中小規模ワークロードのパフォーマンスとスケーリングに関するベスト プラクティス

  • [アーティクル]

Note

この記事では、中小規模のワークロードについて、一般的なベスト プラクティスを示します。 大規模なワークロードに固有のベスト プラクティスについては、「Azure Kubernetes Service (AKS) での大規模なワークロードのパフォーマンスとスケーリングに関するベスト プラクティス」をご覧ください。

AKS でクラスターをデプロイしメンテナンスする際は、次のベスト プラクティスを使用するとパフォーマンスとスケーリングの最適化に役立ちます。

この記事では、次の内容について説明します。

  • ワークロードの自動スケーリングの際のトレードオフと推奨事項。
  • ワークロード需要に基づいたノード スケーリングおよび効率の管理。
  • イングレス トラフィックとエグレス トラフィックについてのネットワーク考慮事項。
  • コントロール プレーンおよびノードのパフォーマンスの監視とトラブルシューティング。
  • 容量計画、急増シナリオ、クラスターのアップグレード。
  • データ プレーンのパフォーマンスについてのストレージとネットワークの考慮事項。

アプリケーションの自動スケーリングとインフラストラクチャの自動スケーリングの比較

アプリケーションの自動スケーリング

アプリケーションの自動スケーリングは、コストの最適化やインフラストラクチャの制限に対応する場合に便利です。 適切に構成されたオートスケーラーでは、コストを最小限に抑えながらアプリケーションの高可用性が維持されます。 需要に関係なく、可用性の維持に必要なリソースにのみ料金がかかります。

たとえば、既存のノードに領域はあるがサブネット内に十分な IP がない場合に、新しいノードの作成をスキップして代わりにすぐに新しいポッドでアプリケーションの実行を開始できます。

ポッド水平自動スケーリング

ポッド水平自動スケーリングの実装は、リソース需要が安定しており予測可能であるアプリケーションの場合に役立ちます。 Horizontal Pod Autoscaler (HPA) では、ポッド レプリカの数が動的にスケーリングされて、負荷が複数のポッドとノードに効率的に分散されます。 このスケーリング メカニズムは、通常は、並列で実行可能な複数の小さな独立したコンポーネントに分解できるアプリケーションの場合に最も役立ちます。

HPA では、既定でリソース使用率メトリックが提供されます。 カスタム メトリックの統合や、Kubernetes イベント ドリブン オートスケーラー (KEDA) (プレビュー) などのツールの利用もできます。 これらの拡張機能により、HPA で複数の分析観点と条件に基づいてスケーリングに関する決定を下せるようになり、アプリケーションのパフォーマンスをより包括的に把握できるようになります。 これは、変化する複雑なスケーリング要件があるアプリケーションの場合に特に役立ちます。

Note

アプリケーションの高可用性の維持が最優先事項である場合は、スケーリング時間を考慮して HPA の最小ポッド数のバッファーを少し多めに残しておくことをお勧めします。

ポッド垂直自動スケーリング

ポッド垂直自動スケーリングの実装は、リソース需要が変動し予測不可能であるアプリケーションの場合に役立ちます。 Vertical Pod Autoscaler (VPA) では、個々のポッドについて CPU やメモリなどのリソース要求を微調整でき、リソース割り当てを細かく制御できます。 このような細かい制御により、リソースの浪費が最小限に抑えられ、クラスター使用率の全体的な効率が高まります。 また、VPA では、リソース割り当てが自動化され重要タスク用にリソースが解放されて、アプリケーション管理が効率化されます。

警告

同じ CPU メトリックやメモリ メトリックで VPA を HPA と併用しないでください。 この組合せでは、両方のオートスケーラーが同じメトリックを使用して需要の変化に対応しようとするため、競合が発生する可能性があります。 ただし、CPU やメモリに VPA、カスタム メトリックに HPA という組合せで使用すると、重複がなくなり、各オートスケーラーでワークロード スケーリングの別々の側面を対象にできます。

Note

VPA は履歴データに基づいて動作します。 変更を適用するのは、推奨事項データを収集する時間を与えるために、VPA のデプロイ後 24 時間以上経過してからにすることをお勧めします。

インフラストラクチャの自動スケーリング

クラスターの自動スケール

クラスター自動スケーリングの実装は、新しいノードのスケールアップとプロビジョニングに役立つため、既存のノードに十分な容量がない場合に便利です。

クラスター自動スケーリングを検討している場合の、ノードを削除するタイミングの決定においては、リソース使用率の最適化とリソース可用性の確保を両立できません。 使用率の低いノードを排除するとクラスター使用率が向上しますが、それによって、新しいワークロードは、リソースがプロビジョニングされるまで待たないとデプロイできなくなる場合があります。 クラスターとワークロードの要件に合わせてこれら 2 つの要素のバランスを見いだし、それに応じてクラスター オートスケーラー プロファイル設定を構成することが重要です。

クラスター オートスケーラー プロファイル設定は、クラスター内のすべてのオートスケーラー対応ノード プールに例外なく適用されます。 つまり、あるオートスケーラー対応ノード プールで発生したスケーリング アクションが、別のノード プールでの自動スケーリング動作に影響する場合があります。 オートスケーラーが想定どおりに動作するように、関連するすべてのノード プールにわたり、一貫性のある同期されたプロファイル設定を適用することが重要です。

オーバープロビジョニング

オーバープロビジョニングは、すぐに利用できるリソースを余分に確保してアプリケーション負荷のリスクを軽減するために役立つ方法です。 この方法は、負荷が大きく変動するアプリケーションや、頻繁なスケールアップとスケールダウンを示すクラスター スケーリング パターンの場合に特に役立ちます。

オーバープロビジョニングの最適な量を判断するには、次の式を使用します:

1-buffer/1+traffic

たとえば、クラスターでの CPU 使用率が 100 % に達しないようにするとします。 安全マージンを確保するために 30 % のバッファーを選択するとします。 トラフィックの平均増加率が 40 % であると予想される場合は、次の式で計算したとおり、50 % のオーバープロビジョニングを検討できます:

1-30%/1+40%=50%

効果的なオーバープロビジョニング方法には、ポーズ ポッドの使用が関係しています。 ポーズ ポッドは低優先度のデプロイであり、高優先度のデプロイに簡単に置き換えることができます。 用途はバッファー領域の予約のみである、低優先度のポッドを作成します。 高優先度のポッドに領域が必要になると、その高優先度のポッドに対応するためにポーズ ポッドが削除され別のノードか新しいノードで改めてスケジュールされます。

次の YAML は、ポーズ ポッド マニフェストの例を示しています:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

ノード スケーリングと効率

ベスト プラクティスのガイダンス:

リソース使用率とスケジューリング ポリシーを注意深く監視して、ノードが効率的に使用されていることを確認してください。

ノード スケーリングでは、ワークロード需要に基づいて、クラスター内のノードの数を動的に調整できます。 クラスターに追加するノードを増やすことがパフォーマンス向上のための最良のソリューションであるとは限らないとわかっておくことが重要です。 最適なパフォーマンスを確保するには、リソース使用率とスケジューリング ポリシーを注意深く監視して、ノードが効率的に使用されていることを確認する必要があります。

ノード イメージ

ベスト プラクティスのガイダンス:

最新のノード イメージ バージョンを使用して最新のセキュリティ更新プログラムとバグ修正プログラムを確保してください。

最新のノード イメージ バージョンを使用すると、最適なパフォーマンス環境が実現されます。 AKS では、週次イメージ リリース内にパフォーマンス改善が含まれています。 最新のデーモンセット イメージは最新の VHD イメージにキャッシュされます。それにより、ノードのプロビジョニングとブートストラップのための待機時間が短くなります。 更新が遅くなるとパフォーマンスに悪影響を及ぼす場合があるため、バージョン間のギャップが大きくならないようにすることが重要です。

Azure Linux

AKS 上の Azure Linux コンテナー ホストでは、ネイティブ AKS イメージが使用され、Linux 開発用の単一の場所が提供されます。 すべてのパッケージはソースから構築されて検証され、実証済みのコンポーネントでサービスが確実に実行されるようにします。

Azure Linux は軽量であり、コンテナー ワークロードの実行に必要な一連のパッケージのみが含まれています。 これにより、攻撃面が減少し、不要なパッケージのパッチ適用とメンテナンスが排除されます。 そのベース レイヤーには、Microsoft によって強化された、Azure 用にチューニングされたカーネルがあります。 このイメージは、パフォーマンスの影響を受けるワークロードや、AKS クラスターのフリートを管理するプラットフォーム エンジニアまたはオペレーターにお勧めです。

Ubuntu 2204

Ubuntu 2204 イメージは、AKS の既定のノード イメージです。 これは、コンテナー化されたワークロードを実行するために最適化された軽量で効率的なオペレーティング システムです。 つまり、これはリソース使用量の減少と全体的なパフォーマンスの向上に役立ちます。 このイメージには、ワークロードを脆弱性から保護するために役立つ、最新のセキュリティ更新プログラムと更新プログラムが含まれています。

Ubuntu 2204 イメージは、Microsoft、Canonical、Ubuntu コミュニティによって十分にサポートされており、コンテナー化されたワークロードのパフォーマンスとセキュリティの向上に役立ちます。

仮想マシン (VM)

ベスト プラクティスのガイダンス:

VM を選択するときは、OS ディスクと VM SKU のサイズおよびパフォーマンスに大きな違いがないことを確認してください。 サイズやパフォーマンスの違いが原因で、パフォーマンス問題とリソース競合が発生する可能性があります。

アプリケーションのパフォーマンスは、ワークロードで使用する VM SKU と密接な関係があります。 一般に、VM が大規模で強力であるほど、パフォーマンスが向上します。 ミッション クリティカルなワークロードや運用ワークロードの場合は、少なくとも 8 コア CPU を備えた VM を使用することをお勧めします。 v4 や v5 などの新しいハードウェア世代の VM も、パフォーマンスの向上に役立ちます。 作成とスケーリングの待機時間は、使用する VM SKU によって異なる場合があることに注意してください。

専用システム ノード プールの使用

スケーリングのパフォーマンスと信頼性のために、専用システム ノード プールを使用することをお勧めします。 この構成では、専用システム ノード プールで、システム OS デーモンなどの重要なシステム リソース用の領域が予約されます。 その後、アプリケーションに割り当て可能なリソースの可用性を高めるために、アプリケーション ワークロードをユーザー ノード プールで実行できます。 この構成は、システムとアプリケーションの間のリソース競合のリスクを軽減するためにも役立ちます。

操作の作成

作成のプロビジョニングの間に有効にした、拡張機能とアドオンを確認してください。 拡張機能やアドオンにより、作成操作の全期間に加えて待機時間が発生する可能性があります。 拡張機能やアドオンが必要ない場合は、作成の待機時間を短縮するためにそれを削除することをお勧めします。

より高いレベルの可用性を提供してハードウェア障害や計画メンテナンス イベントから保護するために、複数の可用性ゾーンを使用することもできます。 AKS クラスターでは、基になる Azure インフラストラクチャの論理セクション間でリソースが分散されます。 可用性ゾーンでは、1 つの障害がアプリケーションの可用性に影響を与えないようにするために、ノードが他のノードから物理的に分離されます。 可用性ゾーンは、一部のリージョンでのみ使用できます。 詳細については、Azure の Availability Zones に関するページをご覧ください。

Kubernetes API サーバー

LIST 操作と WATCH 操作

Kubernetes では、Kubernetes API サーバーとの対話や、クラスター リソースに関する情報の監視のために、LIST 操作と WATCH 操作が使用されます。 これらの操作は、Kubernetes でのリソース管理実行方法には欠かせません。

LIST 操作では、特定の条件に適合するリソースの一覧が取得されます (特定の名前空間にあるすべてのポッドや、クラスター内のすべてのサービスなど)。 この操作は、クラスター リソースの概要を取得する場合や、一度に複数のリソースを操作する必要がある場合に便利です。

LIST 操作では、大量のデータを取得できます (特に、複数のリソースがある大規模なクラスターの場合)。 LIST 呼び出しを無制限または頻繁に実行すると API サーバーに大きな負荷がかかり応答時間が終了する可能性があることに注意してください。

WATCH 操作では、リアルタイムのリソース監視が実行されます。 リソースに WATCH を設定した場合は、そのリソースに変更があるたびに、API サーバーから更新が送信されます。 これは、望ましいリソース状態を維持するために WATCH に依存するコントローラー (ReplicaSet コントローラーなど) にとって重要です。

変化しやすいリソースが多すぎるか、同時 WATCH 要求が多すぎると、API サーバーが過度に使用され、リソースが過剰に消費される可能性があることに注意してください。

潜在的な問題を防ぎ Kubernetes コントロール プレーンの安定性を確保するためには、次の方法を使用できます:

リソース クォータ

リソース クォータを実装して、特定のユーザーや名前空間がリストまたは監視できるリソースの数を制限し、過剰な呼び出しを防ぎます。

API Priority and Fairness

Kubernetes では、API 要求の優先度付けと管理のために API Priority and Fairness (APF) の概念が導入されました。 Kubernetes で APF を使用して、クラスターの API サーバーを保護し、クライアント アプリケーションで表示される HTTP 429 Too Many Requests 応答の数を減らすことができます。

カスタム リソース 主な機能
PriorityLevelConfigurations • API 要求に対してさまざまな優先度レベルを定義します。
• 一意の名前を指定し、優先度レベルを表す整数値を割り当てます。 優先度レベルが高いほど整数値が小さくなり、重要度が高いことを示します。
• 複数使用して、要求をその重要度に基づいてさまざまな優先度レベルに分類できます。
• 特定の優先度レベルの要求をレート制限の対象にするかどうかを指定できます。
FlowSchemas • API 要求を要求属性に基づいてさまざまな優先度レベルに設定する方法を定義します。
• API グループ、バージョン、リソースなどの条件に基づいて、要求に適合するルールを指定します。
• 指定されたルールに要求が適合すると、その要求は、関連する PriorityLevelConfiguration で指定されている優先度レベルに設定されます。
• 複数の FlowSchemas が 1 つの要求に適合するときの評価の順序を設定して、特定のルールが優先されるようにするために使用できます。

PriorityLevelConfigurations と FlowSchemas を使用して API を構成すると、重要度の低い要求よりも重要な API 要求を優先できるようになります。 これにより、低優先度の要求が原因で必須操作がリソース不足になり遅延が発生することがなくなります。

ラベル付けとセレクターの最適化

LIST 操作を使用するときは、ラベル セレクターを最適化して、クエリを実行するリソースの範囲を絞り込み、返されるデータの量と API サーバーの負荷を減らします。

Kubernetes においては、CREATE 操作と UPDATE 操作は、クラスター リソースを管理および変更するアクションのことを指しています。

CREATE 操作と UPDATE 操作

CREATE 操作では、Kubernetes クラスター内に新しいリソースが作成されます (ポッド、サービス、デプロイ、構成マップ、シークレットなど)。 CREATE 操作の間には、クライアント (kubectl やコントローラーなど) から、新しいリソースを作成するための要求が Kubernetes API サーバーに送信されます。 API サーバーでその要求が検証され、受付制御ポリシーに準拠していることが確認されてから、そのクラスターの望ましい状態でリソースが作成されます。

UPDATE 操作では、リソース仕様 (レプリカの数、コンテナー イメージ、環境変数、ラベルなど) の変更を含め、Kubernetes クラスター内の既存のリソースが変更されます。 UPDATE 操作の間には、クライアントから、既存のリソースを更新するための要求が API サーバーに送信されます。 API サーバーでその要求が検証され、変更内容がリソース定義に適用されて、クラスター リソースが更新されます。

CREATE 操作と UPDATE 操作は、次の条件下では Kubernetes API サーバーのパフォーマンスに影響を与える可能性があります:

  • 高い同時実行性: 複数のユーザーまたはアプリケーションが同時に CREATE または UPDATE 要求を発行すると、同時にサーバーに到着する API 要求が急増する可能性があります。 これにより、API サーバーの処理能力に圧力がかかり、パフォーマンスの問題が発生する可能性があります。
  • 複雑なリソース定義: リソース定義が過度に複雑な場合や、入れ子になったオブジェクトがリソース定義に複数含まれている場合は、CREATE 要求と UPDATE 要求を API サーバーで検証し処理するためにかかる時間が長くなり、パフォーマンスが低下する可能性があります。
  • リソースの検証と受付制御: Kubernetes では、受信する CREATE 要求と UPDATE 要求に対して、さまざまな受付制御ポリシーと検証チェックが適用されます。 大規模なリソース定義 (大量の注釈や構成が含まれているリソース定義など) では、より多くの処理時間が必要になる場合があります。
  • カスタム コントローラー: リソースでの変更点を監視するカスタム コントローラー (Deployments コントローラーや StatefulSet コントローラーなど) では、スケーリングやロールアウトの変更が発生すると多数の更新が生成される可能性があります。 これらの更新により、API サーバーのリソースに過度に負荷がかかる可能性があります。

詳しくは、「Azure Kubernetes Service での API サーバーと etcd の問題のトラブルシューティング」をご覧ください。

データ プレーンのパフォーマンス

Kubernetes のデータ プレーンは、コンテナーとサービスの間のネットワーク トラフィックを管理する役割を担います。 データ プレーンに関する問題が原因で、応答時間が長くなり、パフォーマンスが低下し、アプリケーションのダウンタイムが発生する可能性があります。 コンテナ化されたアプリケーションがスムーズかつ効率的に実行されるように、ネットワーク待機時間、リソース割り当て、コンテナー密度、ネットワーク ポリシーなど、データ プレーン構成を注意深く監視し最適化することが重要です。

ストレージの種類

AKS では、エフェメラル OS ディスクが推奨されており、既定で使用されます。 エフェメラル OS ディスクは、ローカル VM ストレージで作成され、マネージド OS ディスクのようにリモートの Azure Storage には保存されません。 それらは再イメージ化と起動にかかる時間がより短いため、クラスター操作がより迅速になります。また、それらによって、AKS エージェント ノードの OS ディスクでの読み取り/書き込み待機時間がより短くなります。 エフェメラル OS ディスクは、ステートレス ワークロードに適しています。この場合、アプリケーションは個々の VM 障害には耐性がありますが、VM のデプロイ時間や個々の VM 再イメージ化インスタンスには影響を受けます。 特定の VM SKU のみでエフェメラル OS ディスクがサポートされているため、必要な SKU の世代およびサイズとの互換性があることを確認する必要があります。 詳しくは、Azure Kubernetes Service (AKS) でのエフェメラル OS ディスクに関するページをご覧ください。

ワークロードでエフェメラル OS ディスクを使用できない場合、AKS では、既定で Premium SSD OS ディスクが使用されます。 Premium SSD OS ディスクにワークロードとの互換性がない場合、AKS では、既定で Standard SSD ディスクが使用されます。 現在は、使用可能なその他の OS ディスクの種類は Standard HDD のみです。 詳しくは、「Azure Kubernetes Service (AKS) でのアプリケーションのストレージ オプション」をご覧ください。

次の表に、AKS でサポートされている OS ディスクについて、おすすめの使用事例の概要を示します:

OS ディスクの種類 主な機能 おすすめの使用事例
エフェメラル OS ディスク • 再イメージ化と起動にかかる時間の短縮。
• AKS エージェント ノードの OS ディスクでの読み取り/書き込み待機時間の短縮。
• 高いパフォーマンスと可用性。		 • SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite など、要求の厳しいエンタープライズ ワークロード。
• 高い可用性と短い待機時間が要件であるステートレスな運用ワークロード。
Premium SSD OS ディスク • 一貫したパフォーマンスと短い待機時間。
• 高可用性。		 • SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite など、要求の厳しいエンタープライズ ワークロード。
• 入出力 (IO) 集中型のエンタープライズ ワークロード。
Standard SSD OS ディスク • 一貫したパフォーマンス。
• Standard HDD ディスクに比べて高い可用性と短い待機時間。		 • Web サーバー。
• 1 秒あたりの入出力操作数 (IOPS) が少ないアプリケーション サーバー。
• 使用量の少ないエンタープライズ・アプリケーション。
• 開発/テスト ワークロード。
Standard HDD ディスク • 低コスト。
• パフォーマンスと待機時間に変動がある。		 • バックアップ ストレージ。
• アクセス頻度の低い大容量ストレージ。

IOPS とスループット

1 秒あたりの入出力操作数 (IOPS) とは、ディスクで 1 秒間に実行可能な読み取りおよび書き込み操作の数のことです。 スループットとは、特定の期間に転送できるデータの量を指します。

OS ディスクはオペレーティング システムとその関連ファイルの格納を担当し、VM はアプリケーションの実行を担当します。 VM を選択するときは、OS ディスクと VM SKU のサイズおよびパフォーマンスに大きな違いがないことを確認してください。 サイズやパフォーマンスの違いが原因で、パフォーマンス問題とリソース競合が発生する可能性があります。 たとえば、OS ディスクが VM よりもかなり小さい場合は、アプリケーション データ用に使用できる領域が制限され、システムのディスク領域が不足する可能性があります。 OS ディスクのパフォーマンスが VM よりも低い場合は、それがボトルネックになり、システムの全体的なパフォーマンスが制限される可能性があります。 Kubernetes で最適なパフォーマンスを確保するために、必ずサイズとパフォーマンスのバランスを取ってください。

次の手順を使用すると、Azure portal で OS ディスクの IOPS と帯域幅の測定を監視できます:

  1. Azure Portal に移動します。
  2. [Virtual Machine Scale Sets] を見つけ、ご使用の仮想マシン スケール セットを選択してください。
  3. [監視] で [メトリック] を選びます。

エフェメラル OS ディスクではアプリケーションに動的な IOPS とスループットを提供できるのに対し、マネージド ディスクでは IOPS とスループットが制限されています。 詳細については、「Azure VM のエフェメラル OS ディスク」を参照してください。

Azure Premium SSD v2 は、ミリ秒未満のディスク遅延と高い IOPS およびスループットを低いコストで実現する必要がある、IO 負荷の高いエンタープライズ ワークロード向けに設計されています。 SQL Server、Oracle、MariaDB、SAP、Cassandra、MongoDB、ビッグ データ/分析、ゲームなど、幅広いワークロードに適しています。 このディスク種類は、永続ボリュームで現在使用できる最もパフォーマンスの高いオプションです。

ポッドのスケジューリング

VM に割り当てられているメモリおよび CPU リソースは、VM で実行されているポッドのパフォーマンスに直接影響します。 ポッドが作成されると、アプリケーションの実行に使用される一定量のメモリおよび CPU リソースがそれに割り当てられます。 VM に十分なメモリおよび CPU リソースがない場合は、ポッドが低速になる可能性があり、クラッシュする可能性さえあります。 VM に使用可能なメモリまたは CPU リソースが多すぎると、ポッドが非効率的に実行されて、リソースが浪費され、コストが増える可能性があります。 スケジューリングの予測可能性とパフォーマンスを最大限に高めるために、ワークロード全体にわたるポッド要求の合計数を割り当て可能リソースの合計数と対照して監視することをお勧めします。 --max-pods を使用して容量計画に基づいてノードあたりの最大ポッド数を設定することもできます。