クラウド管理におけるワークロードの運用

  • [アーティクル]

ワークロードには、ビジネスの成功に不可欠なものもあります。 このようなワークロードの場合、管理ベースラインは、クラウド管理に必要なビジネス コミットメントを満たすのに十分ではありません。 プラットフォーム運用でさえ、ビジネス コミットメントを満たすには不十分な場合があります。 このような重要性の高いワークロードのサブセットでは、ワークロードが機能するしくみとそれがサポートされるしくみに特に注目する必要があります。

その結果、ワークロードの運用への投資によって、パフォーマンスの向上、業務が中断するリスクの低減、システム障害発生時の迅速な復旧が可能になります。 この記事では、このような優先度の高いワークロードの継続的な運用に投資して、ビジネス コミットメントの改善を促進する方法について説明します。

ワークロードの運用に投資するタイミング

"パレート原則" ("80/20 ルール" とも呼ばれます) によると、結果の 80% は原因の 20% に由来しています。 IT ポートフォリオが時間の経過と共に有機的に成長することを見込んでいる場合、IT ポートフォリオのレビューでこのルールがよい例になることがよくあります。 投資を必要とする効果に応じて原因は異なりますが、一般的な原則は当てはまります。

  • システム障害の 80 パーセントは、一般的なエラーまたはバグの 20 パーセントの結果である傾向があります。
  • ビジネス価値の 80% は、ポートフォリオ内のワークロードの 20% に由来する傾向があります。
  • クラウドへの移行にかかる労力の 80% は、移行対象のワークロードの 20% に由来します。
  • クラウド管理作業の 80% は、サービス インシデントまたはトラブル チケットの 20% をサポートします。
  • 障害からのビジネスへの影響の 80% は、障害の影響を受けるシステムの 20% に由来します。

ワークロードの運用は、クラウド導入戦略、ビジネス成果、運用メトリックがそれぞれ十分に理解されている場合にのみ適用する必要があります。 これは、IT の従来の考え方からのパラダイム シフトです。 従来、IT では、すべてのワークロードが同程度のサポートに直面し、同じレベルの優先度を必要としていることを想定していました。

難解なワークロードの運用に投資する前に、IT とビジネスの両方で、業務上の正当な理由とクラウド管理への投資増大の期待を理解する必要があります。

データから開始する

ワークロードの運用は、ワークロードのパフォーマンスとサポート要件を深く理解することから始まります。 チームは、ワークロードの運用に投資する前に、ワークロードの依存関係、アプリケーション パフォーマンス、データベース診断、仮想マシンのテレメトリ、およびインシデント履歴に関する豊富なデータを集める必要があります。

このデータが、ワークロード運用に関する決定を後押しする分析情報の基になります。

継続的な観察

初期データと現行のテレメトリは、ワークロードのパフォーマンスに関する理論の策定とテストに役立ちます。 ただし、現行のワークロードの運用は、アプリケーションとデータのパフォーマンスに重点的に注目した、ワークロード パフォーマンスの継続的かつ広範な観察に基づきます。

オートメーションをテストする

アプリケーション レベルでのワークロードの運用の最初の要件は、詳細なテストへの投資です。 ワークロードの運用を通じてサポートされるアプリケーションの場合、テスト計画を策定し、アプリケーション全体で機能およびスケールのテストが行われるよう定期的に実行する必要があります。

通常のテスト テレメトリを使用すると、ワークロードの運用に関するさまざまな仮説を即座に検証できます。 運用パターンとアーキテクチャ パターンの向上は、実行してテストすることができます。 結果として得られる差分は、継続的な投資の指針となる明確な影響分析として利用できます。

リリースを理解する

リリース サイクルとリリース パイプラインを明確に理解することは、ワークロードの運用の重要な要素です。

サイクルを理解することで、潜在的な中断に備えることができ、運用に悪影響を及ぼす可能性があるすべてのリリースに対してチームが事前に対処できるようになります。 また、このような理解により、クラウド管理チームは、導入チームと協力して、継続的に製品の品質を向上させたり、安定性に影響する可能性のあるすべてのバグに対処したりできるようになります。

さらに重要な点として、リリース パイプラインを理解することで、ワークロードの目標復旧時点 (RPO) を大幅に向上させることができます。 多くのシナリオにおいて、アプリケーションを復旧するための最も速く正確な方法がリリース パイプラインです。 新しいリリースが発生した場合のみに変更されるアプリケーション レイヤーについては、従来のバックアップ プロセスからのアプリケーションの復旧よりもパイプラインの最適化により多くの投資を行うことをお勧めします。

デプロイ パイプラインが復旧への最速の方法ですが、修復への最速の方法でもあります。 高速かつ効率的で信頼性の高いリリース パイプラインがアプリケーションにある場合、クラウド管理チームは、自動修復の一種として新しいホストへのデプロイを自動化することができます。

修復と復旧についてはより高速かつ効果的なメカニズムがほかにも多数存在するかもしれません。 ただし、既存のパイプラインの使用がビジネス コミットメントを達成し、既存の DevOps 投資を活用できる場合、既存のパイプラインは実行可能な代替手段になる可能性があります。

ワークロードに対する変更を明確に伝える

どのワークロードに対する変更もワークロードの運用にとっては最大のリスクの 1 つです。 クラウド管理チームは、クラウド管理のワークロード運用レベルのすべてのワークロードについて、クラウド導入チームと緊密に連携して、各リリースから生じる変更を理解する必要があります。 積極的な理解へのこの投資は、運用の安定性に直接的なプラスの影響を与えます。

結果を改善する

ワークロードへのデータと通信の投資により、次の 3 つの領域のいずれかで進行している運用を改善するための提案が得られます。

  • 技術的負債の解決
  • 自動修復
  • 強化されたシステム設計

技術的負債の解決

最善のワークロード運用計画であっても、修復が必要になります。 クラウド管理チームは、導入の労力とリリースを理解するためにつながりを保とうとするほか、定期的に修復要件を共有して、技術的負債とバグが引き続き開発チームの優先事項となるようにする必要があります。

自動修復

パレート原則を適用すると、ビジネスへの悪影響の 80% はサービス インシデントの 20% に由来する可能性が高いと言えます。 通常の開発サイクルでこれらのインシデントに対処できない場合、修復の自動化に投資することでビジネスの中断が大幅に低減される可能性があります。

強化されたシステム設計

技術的負債の解決と自動修復の場合、システムの欠陥がほとんどのシステム停止の一般的な原因になります。 いくつかの設計原則に従うと、ワークロードの運用全体に最大の影響を及ぼす可能性があります。

  • 拡張性: 増加した負荷を処理するシステムの能力です。
  • 可用性: システムが機能し、動作している時間の割合。
  • 回復性: 障害から回復して動作を続行するシステムの能力です。
  • 管理: 運用環境でシステムを継続的に動作させる運用プロセスです。
  • セキュリティ: 脅威からアプリケーションとデータを保護することです。

Microsoft Azure Well-Architected Framework では、全体的な運用の改善を支援するために、これらの重要な要素への準拠について特定のワークロードを評価するアプローチを提供します。 プラットフォームの運用とワークロードの運用の両方に、重要な要素を適用します。

次のステップ

クラウド導入フレームワーク内の管理手法を十分に理解できたので、クラウド管理の原則を実装できるようになりました。 運用環境内でこの手法を実行可能にする方法について説明します。

この手法を適用する