クラウド管理におけるワークロードの運用Workload operations in cloud management

ワークロードには、ビジネスの成功に不可欠なものもあります。Some workloads are critical to the success of the business. このようなワークロードの場合、管理ベースラインは、クラウド管理に必要なビジネス コミットメントを満たすのに十分ではありません。For those workloads, a management baseline is insufficient to meet the required business commitments to cloud management. プラットフォーム運用でさえ、ビジネス コミットメントを満たすには不十分な場合があります。Platform operations might not even be sufficient to meet business commitments. このような重要性の高いワークロードのサブセットでは、ワークロードが機能するしくみとそれがサポートされるしくみに特に注目する必要があります。This highly important subset of workloads requires a specialized focus on the way the workload functions and how it is supported.

その結果、ワークロードの運用への投資によって、パフォーマンスの向上、業務が中断するリスクの低減、システム障害発生時の迅速な復旧が可能になります。In return, the investment in workload operations can lead to improved performance, decreased risk of business interruption, and faster recovery when system failures occur. この記事では、このような優先度の高いワークロードの継続的な運用に投資して、ビジネス コミットメントの改善を促進する方法について説明します。This article discusses an approach to investing in the continued operations of these high priority workloads to drive improved business commitments.

ワークロードの運用に投資するタイミングWhen to invest in workload operations

"パレート原則" ("80/20 ルール" とも呼ばれます) によると、結果の 80% は原因の 20% に由来しています。The Pareto principle (also known as the 80/20 rule) states that 80 percent of effects come from 20 percent of the causes. IT ポートフォリオが時間の経過と共に有機的に成長することを見込んでいる場合、IT ポートフォリオのレビューでこのルールがよい例になることがよくあります。When IT portfolios are allowed to grow organically over time, this rule is often illustrated in a review of the IT portfolio. 投資を必要とする効果に応じて原因は異なりますが、一般的な原則は当てはまります。Depending on the effect that requires investment, the cause can vary but the general principle holds true:

  • システム障害の 80 パーセントは、一般的なエラーまたはバグの 20 パーセントの結果である傾向があります。80 percent of system failures tend to be the result of 20 percent of the common errors or bugs.
  • ビジネス価値の 80% は、ポートフォリオ内のワークロードの 20% に由来する傾向があります。80 percent of business value tends to come from 20 percent of the workloads in a portfolio.
  • クラウドへの移行にかかる労力の 80% は、移行対象のワークロードの 20% に由来します。80 percent of the effort to migrate to the cloud comes from 20 percent of the workloads being moved.
  • クラウド管理作業の 80% は、サービス インシデントまたはトラブル チケットの 20% をサポートします。80 percent of cloud management efforts will support 20 percent of the service incidents or trouble tickets.
  • 障害からのビジネスへの影響の 80% は、障害の影響を受けるシステムの 20% に由来します。80 percent of business impact from an outage will come from 20 percent of the systems affected by the outage.

ワークロードの運用は、クラウド導入戦略、ビジネス成果、運用メトリックがそれぞれ十分に理解されている場合にのみ適用する必要があります。Workload operations should be applied only when the cloud adoption strategy, business outcomes, and operational metrics are each well understood. これは、IT の従来の考え方からのパラダイム シフトです。This is a paradigm shift from the classic view of IT. 従来、IT では、すべてのワークロードが同程度のサポートに直面し、同じレベルの優先度を必要としていることを想定していました。Traditionally, IT assumed that all workloads experienced the same degree of support and required similar levels of priority.

難解なワークロードの運用に投資する前に、IT とビジネスの両方で、業務上の正当な理由とクラウド管理への投資増大の期待を理解する必要があります。Before they invest in deep workload operations, both IT and the business should understand the business justifications and the expectations of increased investment in cloud management.

データから開始するStart with the data

ワークロードの運用は、ワークロードのパフォーマンスとサポート要件を深く理解することから始まります。Workload operations begin with a deep understanding of workload performance and support requirements. チームは、ワークロードの運用に投資する前に、ワークロードの依存関係、アプリケーション パフォーマンス、データベース診断、仮想マシンのテレメトリ、およびインシデント履歴に関する豊富なデータを集める必要があります。Before the team invests in workload operations, it must have rich data about workload dependencies, application performance, database diagnostics, virtual machine telemetry, and incident history.

このデータが、ワークロード運用に関する決定を後押しする分析情報の基になります。This data seeds the insights that drive workload operations decisions.

継続的な観察Continued observation

初期データと現行のテレメトリは、ワークロードのパフォーマンスに関する理論の策定とテストに役立ちます。Initial data and ongoing telemetry can help formulate and test theories about the performance of a workload. ただし、現行のワークロードの運用は、アプリケーションとデータのパフォーマンスに重点的に注目した、ワークロード パフォーマンスの継続的かつ広範な観察に基づきます。But ongoing workload operations are rooted in a continued and expanded observation of workload performance, with a heavy focus on application and data performance.

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

アプリケーション レベルでのワークロードの運用の最初の要件は、詳細なテストへの投資です。At the application level, the first requirements of workload operations, is an investment in deep testing. ワークロードの運用を通じてサポートされるアプリケーションの場合、テスト計画を策定し、アプリケーション全体で機能およびスケールのテストが行われるよう定期的に実行する必要があります。For any application that's supported through workload operations, a test plan should be established and regularly executed to deliver functional and scale testing across the applications.

通常のテスト テレメトリを使用すると、ワークロードの運用に関するさまざまな仮説を即座に検証できます。Regular test telemetry can provide immediate validation of various hypotheses about the operation of the workload. 運用パターンとアーキテクチャ パターンの向上は、実行してテストすることができます。Improving operational and architectural patterns can be executed and tested. 結果として得られる差分は、継続的な投資の指針となる明確な影響分析として利用できます。The resulting deltas provide a clear impact analysis to guide continued investments.

リリースを理解するUnderstand releases

リリース サイクルとリリース パイプラインを明確に理解することは、ワークロードの運用の重要な要素です。A clear understanding of release cycles and release pipelines is an important element of workload operations.

サイクルを理解することで、潜在的な中断に備えることができ、運用に悪影響を及ぼす可能性があるすべてのリリースに対してチームが事前に対処できるようになります。An understanding of cycles can prepare for potential interruptions and allow the team to proactively address any releases that might produce an adverse effect on operations. また、このような理解により、クラウド管理チームは、導入チームと協力して、継続的に製品の品質を向上させたり、安定性に影響する可能性のあるすべてのバグに対処したりできるようになります。This understanding also allows the cloud management team to partner with adoption teams to continuously improve the quality of the product and address any bugs that might affect stability.

さらに重要な点として、リリース パイプラインを理解することで、ワークロードの目標復旧時点 (RPO) を大幅に向上させることができます。More importantly, an understanding of release pipelines can significantly improve the recovery point objective (RPO) of a workload. 多くのシナリオにおいて、アプリケーションを復旧するための最も速く正確な方法がリリース パイプラインです。In many scenarios, the fastest and most accurate path to the recovery of an application is a release pipeline. 新しいリリースが発生した場合のみに変更されるアプリケーション レイヤーについては、従来のバックアップ プロセスからのアプリケーションの復旧よりもパイプラインの最適化により多くの投資を行うことをお勧めします。For application layers that change only when a new release happens, it might be wise to invest more heavily in pipeline optimization than on the recovery of the application from traditional back-up processes.

デプロイ パイプラインが復旧への最速の方法ですが、修復への最速の方法でもあります。Although a deployment pipeline can be the fastest path to recovery, it can also be the fastest path to remediation. 高速かつ効率的で信頼性の高いリリース パイプラインがアプリケーションにある場合、クラウド管理チームは、自動修復の一種として新しいホストへのデプロイを自動化することができます。When an application has a fast, efficient, and reliable release pipeline, the cloud management team has an option to automate deployment to a new host as a form of automated remediation.

修復と復旧についてはより高速かつ効果的なメカニズムがほかにも多数存在するかもしれません。There might be many other faster, more effective mechanisms for remediation and recovery. ただし、既存のパイプラインの使用がビジネス コミットメントを達成し、既存の DevOps 投資を活用できる場合、既存のパイプラインは実行可能な代替手段になる可能性があります。However, when the use of an existing pipeline can meet business commitments and capitalize on existing DevOps investments, the existing pipeline might be a viable alternative.

ワークロードに対する変更を明確に伝えるClearly communicate changes to the workload

どのワークロードに対する変更もワークロードの運用にとっては最大のリスクの 1 つです。Change to any workload is among the biggest risks to workload operations. クラウド管理チームは、クラウド管理のワークロード運用レベルのすべてのワークロードについて、クラウド導入チームと緊密に連携して、各リリースから生じる変更を理解する必要があります。For any workload in the workload operations level of cloud management, the cloud management team should closely align with the cloud adoption teams to understand the changes coming from each release. 積極的な理解へのこの投資は、運用の安定性に直接的なプラスの影響を与えます。This investment in proactive understanding will have a direct, positive impact on operational stability.

結果を改善するImprove outcomes

ワークロードへのデータと通信の投資により、次の 3 つの領域のいずれかで進行している運用を改善するための提案が得られます。The data and communication investments in a workload will yield suggestions for improvements to ongoing operations in one of three areas:

  • 技術的負債の解決Technical debt resolution
  • 自動修復Automated remediation
  • 強化されたシステム設計Improved system design

技術的負債の解決Technical debt resolution

最善のワークロード運用計画であっても、修復が必要になります。The best workload operations plans still require remediation. クラウド管理チームは、導入の労力とリリースを理解するためにつながりを保とうとするほか、定期的に修復要件を共有して、技術的負債とバグが引き続き開発チームの優先事項となるようにする必要があります。As your cloud management team seeks to stay connected to understand adoption efforts and releases, the team likewise should regularly share remediation requirements to ensure that technical debt and bugs are a continued priority for your development teams.

自動修復Automated remediation

パレート原則を適用すると、ビジネスへの悪影響の 80% はサービス インシデントの 20% に由来する可能性が高いと言えます。By applying the Pareto principle, we can say that 80 percent of negative business impact likely comes from 20 percent of the service incidents. 通常の開発サイクルでこれらのインシデントに対処できない場合、修復の自動化に投資することでビジネスの中断が大幅に低減される可能性があります。When those incidents can't be addressed in normal development cycles, investments in remediation automation can significantly reduce business interruptions.

強化されたシステム設計Improved system design

技術的負債の解決と自動修復の場合、システムの欠陥がほとんどのシステム停止の一般的な原因になります。In the cases of technical debt resolution and automated remediation, system flaws are the common cause of most system outages. いくつかの設計原則に従うと、ワークロードの運用全体に最大の影響を及ぼす可能性があります。You can have the greatest impact on overall workload operations by adhering to a few design principles:

  • 拡張性: 増加した負荷を処理するシステムの能力です。Scalability: The ability of a system to handle increased load.
  • 可用性: システムが機能し、動作している時間の割合。Availability: The percentage of time that a system is functional and working.
  • 回復性: 障害から回復して動作を続行するシステムの能力です。Resiliency: The ability of a system to recover from failures and continue to function.
  • 管理: 運用環境でシステムを継続的に動作させる運用プロセスです。Management: Operations processes that keep a system running in production.
  • セキュリティ: 脅威からアプリケーションとデータを保護することです。Security: Protecting applications and data from threats.

Microsoft Azure Well-Architected Framework では、全体的な運用の改善を支援するために、これらの重要な要素への準拠について特定のワークロードを評価するアプローチを提供します。To help improve overall operations, the Microsoft Azure Well-Architected Framework provides an approach to evaluating specific workloads for adherence to these pillars. プラットフォームの運用とワークロードの運用の両方に、重要な要素を適用します。Apply the pillars to both platform operations and workload operations.

次のステップNext steps

クラウド導入フレームワーク内の管理手法を十分に理解できたので、クラウド管理の原則を実装できるようになりました。With a full understanding of the manage methodology within the Cloud Adoption Framework, you are now armed to implement cloud management principles. 運用環境内でこの手法を実行可能にする方法について説明します。Learn how to make this methodology actionable within your operations environment.