この記事では、Azure Kubernetes Service (AKS) クラスターでの多層アプリケーションデプロイの高可用性 (HA) について説明します。 Kubernetes HA のメカニズムとコンストラクトについて説明し、HA 障害の単一ポイントを特定して排除するためのチェックリストとガイドラインを提供します。
AKS アプリケーションの HA を実装するための基本的なタスクは 2 つあります。
- アプリケーション内のすべての単一障害点を特定します。
- 単一障害点を排除します。
単一障害点を排除するには、HA ソリューションが必要です。
4 つの HA の柱
高可用性システムには、次の 4 つの HA の柱が表示されます。
- Redundancy
- 監視
- 復元
- チェックポイント機能
トラフィックがビジネス ロジック層に到着し、データ層が状態を保持し、アプリケーションがユーザーに応答を返す、次の多層 AKS アプリケーションについて考えてみましょう。
単一障害点を特定する
単一障害点を特定するには、まず、クライアント要求とそれらの要求を処理するコンポーネントの間のクリティカル パスを決定します。 4 つの HA の柱に従って管理されていないこのパス上のコンポーネント、またはチェックポイント処理のないステートレス コンポーネントの場合は 3 つの柱は、単一障害点です。 レプリケートされたコンポーネントであっても、監視されていない場合は単一障害点と見なされます。エラーは自動的に検出されないためです。
単一障害点を排除する
単一障害点を排除するには、アプリケーションをデプロイしてクリティカル パス コンポーネントをレプリケートし、ロード バランサー、監視、復旧メカニズムを採用します。 Kubernetes は、これらすべてのアクティビティを処理できます。
この図の Visio ファイル をダウンロードします。
レプリケートされたアプリケーションの場合:
- パフォーマンスとワークロードに応じて、コンポーネントごとにさまざまな数のレプリカを使用してビジネス層コンポーネントをレプリケートします。
- また、ロード バランサーの背後にデータ層をレプリケートします。
Kubernetes には、負荷分散やライブネス プローブなど、HA の柱の実装に役立ついくつかのコンストラクトとメカニズムが用意されています。 次のチェックリストと説明では、これらのコンストラクトとメカニズムを、4 つの HA の柱にマップするカテゴリに分割します。
Kubernetes HA チェックリスト
状態管理以外に、Kubernetes はアプリケーション HA を維持する優れたジョブを実行します。 HA チェックリストには、Kubernetes HA 管理を最適化するために使用できる一般的な構成が一覧表示されます。 チェックリストを使用するには、次のメカニズムとコンストラクトに対して Kubernetes のデプロイを評価し、不足している場合は実装します。
| HAの柱 | ソリューション |
|---|---|
| Redundancy | ☐ Kubernetes コントローラーの種類 ☐ レプリカの数 ☐ アンチアフィニティのスケジュール設定 |
| 監視 | ☐ 生存確認プローブ ☐ 準備プローブ ☐ 起動時プローブ |
| 復元 | ☐ サービスの種類 ☐ リーダーの選挙 ☐ 再起動ポリシー ☐ ストップ前フック |
| チェックポイント機能 | ☐ 永続ボリューム要求 ☐ 永続ボリューム |
Redundancy
冗長性により、単一障害点が軽減されます。 アプリケーションのすべての層で冗長性が必要です。 冗長性を実現するには、1 つ以上の同一のレプリカを使用して、特定の層のコンポーネントをレプリケートします。
コントローラーの種類。 設定:
kind: Deployment。 Kubernetes には、アプリケーションのポッドのライフサイクルを管理できるコントローラーがいくつか用意されています。 最も一般的なコントローラーはDeploymentです。Statefulset別のコントローラーは、復旧後にポッド ID を維持する必要がある場合に便利です。Replicasetsなどの他のコントローラーでは、ロールバックなど、Deploymentと同じ便利な機能が提供されません。レプリカの数。 構成:
spec.replicas。 レプリカの数を 1 つだけに設定すると、コールド スタンバイ モデルが構成されます。 コールド スタンバイ モデルを使用する場合、障害が発生すると、新しいインスタンスが最初から開始され、可用性に影響します。 このモデルは、ボリュームの少ないワークロードを持つコンポーネントで機能する可能性がありますが、ステートレスで大量のコンポーネントをレプリケートすることを検討してください。リソース要求の制限
spec.containers[].resources指定すると、 ポッドの水平自動スケール (HPA) を追加できます。これにより、Kubernetes は、定義したリソース使用率のしきい値に基づいてレプリカの数を自動的にスケールアップまたはスケールダウンできます。 HPA を使用すると、負荷が急増して、過負荷のためにアプリケーションが要求を提供できなくなるシナリオを回避できます。アンチアフィニティのスケジューリング。 構成:
spec.affinity.podAntiAffinity。 一般的な運用レベルの Kubernetes クラスターには、複数 の可用性ゾーンにノードが分散されており、topologyKeyを使用して構成します。 同じデプロイのポッドは、互いに好ましいかソフトなアンチアフィニティを持っている必要があります。 この構成により、ポッドが異なるアベイラビリティゾーンに属するノードにスケジュールされることが保証されます。AKS クラスターには 複数のノード プールを含めることができます。それぞれに異なる 仮想マシン スケール セットのサイズと仕様があります。 たとえば、高速ソリッドステート ドライブ (SSD) を持つノードでデータベース ポッドをホストし、 グラフィックス処理装置 (GPU) を持つノードで機械学習ポッドをホストできます。
監視
アプリケーションを監視しないと、冗長性が無効になる可能性があります。 ワークロードが正常なレプリカに到達することを確認するには、一定の監視メカニズムが必要です。
liveness プローブ の設定
spec.containers.livenessProbeは、Pod の健全性を監視します。 コンテナーが失敗または終了した場合、Kubernetes はそれを検出できます。 ライブネスが失敗すると、Kubernetes によってコンテナーが再起動されます。準備プローブ、構成
spec.containers.readinessProbe、ポッドにトラフィックを送信するかどうかを決定します。 デプロイのポッドの準備ができていない場合は、デプロイを抽象化する Kubernetes サービスのエンドポイントに含まれないため、役に立ちません。 準備プローブは再起動をトリガーしませんが、準備ができるまでポッドがトラフィックを受信しないように分離するために使用されるため、準備プローブを慎重に設定することが重要です。スタートアップ プローブ、構成
spec.containers.startupProbe。主に、起動が遅いアプリケーションでの準備とライブ性に対する誤検知を防ぎます。 スタートアップ プローブが成功すると、ライブネス プローブが開始されます。
Azureでは、クラスターの正常性に基づいてアラートを設定できる、より詳細な分析情報が提供されます。
復元
監視の主な目的は、障害が検出されたときに回復をトリガーするためです。 復旧プロセスには、次の 3 つのフェーズが含まれます。
- 分離とリダイレクト: 障害のあるレプリカがトラフィックを受信していないことを確認し、そのワークロードを正常なレプリカに転送します。
- 修復: 障害のあるレプリカを再起動します。 これにより、一時的なエラーが修復される可能性があります。
- 復帰： 修復後、監視によってレプリカが正常と見なされた場合は、レプリカを他のレプリカに再び参加してワークロードを処理します。
Kubernetes には、これらのフェーズを実装するための次のメカニズムが用意されています。
サービスの種類。 構成:
spec.type。 サービスを介したポッドの公開は、冗長性または復旧として分類できます。 ただし、場合によっては、単一レプリカのデプロイを採用することがあります。 負荷分散がない場合でも、サービスを介してポッドを公開することには、引き続き利点があります。サービスを使用する主な利点は、ドメイン ネーム システム (DNS) エントリが Kubernetes サービス エンドポイントで自動的に更新される点です。 準備プローブが失敗したコンテナーがあるポッドは、AKS 経由でトラフィックを受信しません。 Kubernetes クラスター IP サービスの負荷分散機能は基本的な機能ですが、ヘッドレス サービスとイングレスまたはその他のサービス メッシュ ソリューションを組み合わせて負荷分散のバランスを取ることができます。
外部トラフィックが AKS クラスターに到達するメカニズムは、Kubernetes の範囲外です。 Azure Application Gatewayなどのサービスを使用して、外部トラフィックを処理できます。
リーダーの選挙。 一部のコンポーネントは、シングルトンとして最適にデプロイされます。 2 つのアクティブなスケジューラが互いに競合する可能性があるため、スケジューラはこのようなコンポーネントです。 シングルトンを使用すると、アプリケーションがコールド スタンバイの問題にさらされます。 ポッドのウォーム スタンバイを有効にするには、リーダーの選択を使用できます。この場合、リーダーである 1 つのポッドのみが要求を処理します。
再起動ポリシー 構成:
spec.restartPolicy。 再起動ポリシーは、ポッド内のすべてのコンテナーに適用されます。 この属性をNeverに設定するには、正当な理由が必要です。 一部のコンテナーは、起動するたびにライセンス サーバーに接続するため、過剰な再起動の追加コストを回避したい場合があります。事前停止フック。 構成:
spec.containers.lifecycle.preStop。 事前停止フックは、SIGTERMシグナルがコンテナーに送信される前に実行されます。 事前停止スクリプトは、30 秒のスリープ コマンドと同じくらい簡単です。たとえば、HPA によって管理されているアプリケーションがスケール ダウンしている場合、アプリケーションが終了する前に要求の処理を完了する
SIGTERMハンドラーがない限り、進行中の要求が突然終了する可能性があります。 事前停止フックは、ポッド エンドポイント、つまり DNS エントリをサービス エンドポイントから削除します。 停止前フックの実行中は、ポッドに新しい要求を送信できません。 停止前フックを使用すると、ポッドは、新しい要求を受信することなく、進行中の要求の処理を完了できます。 事前停止フックは、アプリケーション コードを変更せずに破棄された要求を最小限に抑える簡単な方法です。
チェックポイント機能
最新のアプリケーションには多くのステートレス コンポーネントが含まれていますが、完全にステートレスなアプリケーションはまだまれです。 ほとんどのアプリケーションは、その状態をデータレイヤーにチェックポイントとして保存します。 Kubernetes では、アプリケーションの状態を処理するためのメカニズムが意図的に提供されていません。 状態管理は、コンテナー管理の一部ではない複雑なタスクです。
アプリケーションの状態は、次の 3 つのレベルで保持できます。
データ レコード レベルでは、データベースにデータが格納されます。 各データベース レコードは、複数のデータベース インスタンスにレプリケートできます。 データベース レコードは、特にAzure Cosmos DBなどのマネージド クラウド データベースにおいて、状態永続化の主要な形式です。
通常、ファイル システム レベルでは、先書きログ (WAL) ファイルなどのデータ ファイルがレプリケートされます。 ほとんどのクラウド プロバイダーは、ソリューション用のプラグインを提供しています。 たとえば、Azure Filesはプラグインを提供します。
ディスク レベルはブロック レベルでデータを保持するため、Azure Disk Storageのように、使用するファイル システムを柔軟に定義できます。
Kubernetes ボリューム、永続ボリューム、および永続ボリューム要求は、 ファイル システムまたはディスク レベルでアプリケーションの状態を保持できます。 状態を格納する最も一般的なパターンは、引き続きデータ レコード レベルです。
HA と DR
HA とディザスター リカバリー (DR) の両方で、ネットワーク トポロジと 負荷分散ソリューションの 選択が重要です。
ただし、DR では、Azure リージョン間の負荷分散ソリューションを使用して、サービス レベル全体でマルチリージョン サービスをデプロイする必要があります。 アプリケーションは複数のリージョンにデプロイされるか、アプリケーション インスタンス全体が各リージョンにデプロイされます。 選択は、アプリケーションの種類、アプリケーション アーキテクチャ、コンポーネント間の待機時間の許容範囲によって異なります。
HA は、複数のリージョンを使用する代わりに、Azure リージョン内のマルチゾーン デプロイの利点があります。 次の図は、HA と DR の可用性ゾーンとリージョンの違いを示しています。
このアーキテクチャのVisio ファイルをダウンロードしてください。
この記事では、1 つの AKS クラスター内のアプリケーション レベルでの HA に焦点を当てます。 AKS マルチクラスター デプロイでの DR の詳細については、 マルチリージョン クラスターの AKS ベースラインに関する説明を参照してください。
その他の考慮事項
アプリケーション HA を維持するには、API サーバーやコントローラー マネージャーを含む Kubernetes コントロール プレーンが高可用性であることを確認します。 HA を確保するには、 Standard または Premium の価格レベル を使用します。
リソース統合戦略は、HA 冗長性の柱に直接反します。 そのため、冗長性のコストを慎重に分析する必要があります。 Azure料金計算ツールが役立ちます。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要著者:
- アリカンソー |プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- Ayobami Ayodeji | シニア プログラム マネージャー
- キンシュマン・パトラ |パートナー グループ エンジニアリング マネージャー
- オスカー L プラ アルバレス |ドメイン ソリューション アーキテクト
- カルティック サンカラ スブラマニアン |ソフトウェア エンジニア II
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。