最新のアプリケーション プラットフォーム クラスターを管理する

  • [アーティクル]

クラウド導入フレームワークでは、非依存という意味で、クラウドの運用管理プロセスを定義するための中核的な手法が提供されます。 そのガイダンスは、運用管理ベースラインや、運用のその他の特殊なレイヤーを確立するために役立ちます。 このガイダンスは、サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、コンテナー化されたワークロードを混在して使用している組織にも引き続き適用される可能性があります。 この記事では、コンテナー管理を準備するために既存の運用に統合する必要があるものの概要について説明します。 また、Azure Kubernetes Service (AKS) をコンテナー管理戦略に統合する利点についても強調しています。

運用管理のニーズに合わせたビジネスの整合

コンテナーによって、インフラストラクチャのいくつかのレイヤーへの依存関係が削除されるため、運用管理機能が強化されます。 これらの運用の機能強化を実現するには、ビジネスの整合から始めて、クラウド管理戦略全体を変更することが必要になる場合があります。

適切な運用管理方法を確立するには、クラウド導入計画でコンテナーがどのように使用されるか、およびこのコンテナー化されたワークロードへのシフトからどのような利点を実現したいかを理解する必要があります。

  • クラウド プラットフォームで、コンテナー、IaaS、PaaS などの複数のテクノロジ ソリューションを管理しますか?
  • 一元化されたチームは、コンテナーまたは AKS プラットフォームの運用と管理をサポートしますか? このアカウンタビリティは個々のワークロード チームにシフトしますか?
  • 一元化されたチームは、各コンテナーまたはポッドで実行されているワークロードの運用と管理をサポートしますか? このアカウンタビリティは個々のワークロード チームにシフトしますか?
  • ミッション クリティカルなワークロードにコンテナーを使用していますか?
  • コストを削減するために、重要性の低いワークロードやユーティリティ ワークロードにのみコンテナーを使用していますか?
  • 個々のワークロードのパフォーマンスと信頼性はどれくらい重要ですか?
  • コンテナー内のアプリケーションはステートレスですか? コンテナー内のワークロードを保護および回復するために状態を保持する必要がありますか?

これらの基本的な質問によって、コンテナーと AKS を運用管理戦略に最適に統合する方法が形づくられます。

運用ベースライン

運用ベースラインを実装すると、クラウド環境内のすべての資産を運用および管理するために必要なツールへの一元化されたアクセスが提供されます。 コンテナー化されていない資産のための運用ベースラインがない場合は、管理手法で定義された運用ベースラインを実装できます。

運用ベースラインには、可視性、監視、運用のコンプライアンス、最適化、保護と回復を提供するためのツールと構成を含める必要があります。

運用管理ベースライン

上記の記事に概要が示されている運用ベースラインでは、コンテナーまたは AKS プラットフォームに対するサポートは提供されません。 ただし、Azure Monitor、Azure Backup やその他のツールなど、コンテナーをサポートするように拡張できるツールの基礎が提供されます。

クラウド内のほとんどのポートフォリオがコンテナーでホストされている場合は、次のセクションにある特殊なプラットフォーム運用を運用ベースラインに含めることを検討してください。

プラットフォームの運用

この実装がクラウドへの組織の最初または唯一のデプロイでない限り、運用ベースラインが用意されているはずです。 このセクションでは、コンテナーまたは AKS デプロイの管理に役立てるために含めたくなる可能性があるいくつかのツールを識別します。

インベントリと可視性

コンテナーと AKS クラスターの監視では、運用ベースラインに含まれているツール、ダッシュボード、アラートを使用します。 ただし、コンテナーから運用監視ツール (Azure Monitor for containers など) にデータを取得するには、追加の構成を行うことが必要になる場合があります。 コンテナーと AKS プラットフォームの運用を運用ベースラインに追加するために必要なデータを収集するには、Azure Monitor for containers の概要に関するページを参照してください。

コンテナー上のデータを収集するように Azure Monitor を構成したら、一元化された管理プロセスの一部として次の領域を監視できます。

  • さまざまなリージョンで実行されている (理想的にはサービス ツリーのエントリに関連付けられた) クラスターを識別し、これらのクラスターに関する重要事項を識別します。
    • これらのクラスターのクラスター ノード プール、ネットワーク、ストレージ トポロジを識別します。
    • AKS バージョンとノード イメージ バージョンの階層化を識別します。
  • クラスター ノードのリソース使用率 (プロセス、メモリ、ストレージ) を識別します。
  • ノード上で実行されているコンテナーと、それらのノード使用率への寄与を識別します。
  • 平均および最大の負荷の下でのクラスターの動作を把握します。 この知識は、容量ニーズを特定し、クラスターが維持できる最大負荷を判断するのに役立ちます。
  • ノードまたはコンテナー上の CPU およびメモリ使用率がしきい値を超えたときや、インフラストラクチャまたはノードの正常性ロールアップ時にクラスターで正常性状態の変化が発生したときにユーザーに事前に通知するか、または記録するようにアラートを構成します。
  • クエリを使用して、アラート、ダッシュボード、詳細な実行の詳細な分析の共通セットを作成します。

このデータはまた、コンテナー化されたプラットフォーム上で実行されているワークロードに関する詳細情報を提供することによって、ワークロード運用チームによってもサポートされます。

  • ポッドをサポートする標準プロセスと関連のない、ホスト上で実行されているワークロードのリソース使用率を確認します。
  • アプリケーション メトリックを表示するには、Prometheus と統合します。
  • オンプレミスの AKS エンジンおよび Azure Stack の AKS エンジンにデプロイされたコンテナー ワークロードを監視します。
  • Azure Red Hat OpenShift にデプロイされたコンテナー ワークロードを監視します。
  • Azure Arc 対応 Kubernetes (プレビュー) にデプロイされたコンテナー ワークロードを監視します。

運用コンプライアンス

修正プログラムの適用、チューニング、サイズ設定は、コンテナー化された環境内のいくつかの異なるレベルで発生します。 オペレーターは、望ましい運用のアプローチに応じて、いくつかの異なるチームに属する可能性があります。 運用コンプライアンスを維持するために、オペレーターは使用状況を監視し、資産のサイズを変更してパフォーマンスとコストのバランスを取り、基になるシステムに修正プログラムを適用して、リスクや構成のずれを最小限に抑えます。 中央の IT 組織は、IaaS および PaaS ソリューションのための運用ベースラインの一部としてこれらのタスクを提供する傾向があります。

Azure のクラスター環境では、これらのタスクは AKS クラスター、ノード イメージ、ノード OS という複数のレベルで実行されます。 これらの運用タスクはすべて、クラスター内または個々のノード プール上で実行されている各ワークロードの理解と連携に基づく関係にますます依存するようになります。 次のステートメントは、コンテナー環境を運用するために何を行いたいか、また実際にそうしたいかどうかを評価するために役立ちます。

  • AKS クラスター、ノード イメージ、またはノード OS のサイズ設定や修正プログラム適用がアプリケーションのデプロイ パイプラインの一部として提供されているか、あるいはアプリケーションのアーキテクチャまたは構成に依存している場合は、きめ細かい制御のために運用のコンプライアンスをワークロード チームにシフトすることをお勧めします。 ワークロードは多くの場合、オーケストレーション機能への依存関係があるため、最も一般的なパターンとして、予期しない AKS バージョンの変更またはノード イメージの変更がワークロードやそのランタイム ツールにとって致命的になることがあります。
  • ワークロードとさまざまなアプリケーションのポートフォリオをサポートしている、あまり一般的ではない一元化されたクラスターの場合は、一元化された運用チームが運用のコンプライアンス タスクに引き続き責任を負っている可能性があり、これらのタスクをクラスターにまたがって配信するために次のガイドが役立ちます。 これらのタスクを定期的に実行すると、プラットフォーム固有の運用が徐々に形づくられます。 一元化された運用のアプローチには注意すべきリスクが存在するため、明確で、かつ予定メンテナンスに従った実稼働前環境でのアップグレードの慎重なテストと、準拠していないワークロードに対するコンティンジェンシー計画をすべて整えておく必要があります。 1 つの不適切なアップグレードが単一障害点や同様の状態になる場合があります。あるワークロードをアップグレードできないと、クラスターがサポート対象外になることがあります。 マルチテナント クラスターは相当の注意を払って計画および管理してください。

どちらのクラスターの種類の場合でも、アップグレード、ノード イメージ、ノード OS の更新に関する次のガイダンスに従ってください。

保護と復旧

AKS ノードは本質的に一時的であるため、個別に復元できる方法ではバックアップされません。 インシデントからの回復には、そのインシデントのスコープに応じて、新しいノード プールまたは新しいクラスター全体へのワークロードの再展開が必要になる可能性があります。

  • クラスターにアップタイム SLA を追加することを選択します。
  • SLA を向上させるには、追加の保護を提供するためにマルチリージョン BCDR のベスト プラクティスを検討することもできます。
  • クラスターには状態を含めないでください。外部の状態の復元は、既存の運用ベースライン ガイダンスを使用して処理されます。 クラスターに状態を含めている場合は、ストレージに関するオペレーターのベスト プラクティスに従い、特定のワークロードに関してこのデータをバックアップおよび復元する方法を計画します。 Velero などのツールの使用は、運用ベースラインを拡張したプラットフォーム固有の運用の例です。
    • アプリケーションのポートフォリオのために状態が一貫性のない方法で適用される場合は、中央の運用チームが両方のソリューションを管理しないようにする必要があります。 代わりに、すべてのコンテナーについて望ましい状態のツールチェーンを標準としますが、代替の回復ソリューションに関する責任をワークロード運用チームにシフトします。 このアプローチにより、開発者には設計の自由が許され、中央のコストが低い状態に維持されると共に、ワークロード チームには標準に従ってコストを削減するというインセンティブが与えられます。

ワークロードの運用

上記の「プラットフォームの運用」セクションでは、AKS クラスターを管理する場合の一般的な会話を示しています。 Kubernetes クラスターは、一元的に管理されるテクノロジ プラットフォームですか? あるいは、各ワークロードを所有するチームで管理されるべきワークロード ツールですか? その質問は、組織によって異なります。 ほとんどの組織で変わらず見られることとして、コンテナーと AKS が、ワークロード チームに各ワークロードを運用する方法でのより高い柔軟性を提供するように設計されており、アプリケーションの所有者や顧客にメリットを与えるためにこれらのワークロードがそれぞれのアーキテクチャで使用する特定の機能を提供するという点があります。

ワークロード運用は、既存の運用ベースラインとプラットフォーム固有の運用に基づいて構築できます。 また、完全に分散化されたワークロード運用を使用して AKS クラスターを安全に運用することもできます。 どちらの場合も、特定のワークロードの特定の成果に重点を置くために運用を昇格させる必要がある場合は、Azure Well-Architected Framework と Microsoft Azure Well-Architected Review を使用して、ワークロードのために使用する運用プロセスとツールの種類に関してきわめて固有の方法を選択できます。

次のステップ: 次の移行の繰り返し

最新のアプリケーション プラットフォームの移行が完了したら、クラウド導入チームは次のシナリオ固有の移行を開始できます。 あるいは、移行する追加のプラットフォームがある場合は、この記事シリーズをもう一度使用して、次の最新のアプリケーション プラットフォームの移行またはデプロイを開始できます。