Azure Well-Architected フレームワークのワークロード
Azure Well-Architected フレームワークのコンテキストでは、ワークロードという用語は、定義されたビジネス成果を達成するために連携して機能するアプリケーション リソース、データ、サポート インフラストラクチャのコレクションを指します。 ワークロードを構成する要素には、コンポーネントだけでなく、開発および運用の手順も含まれます。
アーキテクトがワークロードを設計し、ワークロード チームがワークロードを実装します。 ワークロードは、機能的および非機能的なビジネス要件を実現するために設計および実装されます。 ワークロードは、さまざまな種類に分類できます。
ワークロード分類の一般的な条件は、次のとおりです。
Web アプリケーション、バッチ処理、リアルタイム分析など、ワークロードのユーティリティ、特性、使用パターン。
テクノロジ プラットフォームや業界との連携など、主要な影響力を持つ促進要因。
対象ユーザー。 さまざまな対象ユーザーを含むソリューションの例としては、企業内の内部基幹業務アプリケーション、購入した独立系ソフトウェア ベンダー (ISV) ソリューション、または一般用途向けのマルチテナントのサービスとしてのソフトウェア (SaaS) ソリューションがあります。
同じクラス内にあるワークロードは、対象ユーザー、コンプライアンス要件、テクノロジ スタックなどの類似点を共有できます。 Well-Architected フレームワークの 5 つの重要な要素、これらの原則、チェックリスト、トレードオフは、すべてのワークロード クラスに関連しています。
Well-Architected フレームワークのワークロード ガイダンスでは、特定のワークロード クラスに関連する一般的な優先順位とトレードオフについて説明します。 ワークロード ガイダンスでは、重要な要素のガイダンスは、ワークロードの優先順位を表す技術的な設計原則と設計領域に当てはまります。 推奨事項に従い、成功につながるワークロードを設定し、Well-Architected フレームワークに合わせて調整してください。
Well-Architected フレームワークのワークロードとは
ワークロードの設計と運用では、信頼性、セキュリティ、コスト最適化、オペレーショナル エクセレンス、パフォーマンス効率という 5 つのアーキテクチャの重要な要素に対処する必要があります。
 成功につながるワークロードを作成するには、次の理想に基づいた Well-Architected フレームワークの原則に従って開発します。 |
|---|
Well-Architected フレームワークのワークロードの特性は、次のとおりです。
- 目標を達成するために定義および優先順位付けされた機能要件と非機能要件がある。
- リソースを使用し、設計パターンとトレードオフを組み込むことで、これらの要件を達成できるように設計されている。
- 設計と目的の仕様に応じて構築および運用されている。
- 目的をどれくらい適切に達成できるかに基づいて測定される。
- 目的の改善または変更に合わせて適応できる。
- 必要に応じた信頼性を確保できる。
- 必要に応じたセキュリティを確保できる。
- 十分な投資収益率を実現できる。
- 責任を持って開発および運用されている。
- 許容範囲内の期間内に目的を達成できる。
ワークロード チームと組織の中央チーム間のコラボレーションでは、上記の特性を備えたワークロードを作成する必要があります。 次のセクションでは、これらのチームとその機能について説明します。
ワークロード チーム
幅広い技術的規範とビジネス規範を備えたチーム メンバーがいるワークロード チームを作成します。 すべてのチーム メンバーの主な焦点の対象が、ワークロードの成功である必要があります。
| ワークロードのチーム メンバーの例 | |
|---|---|
| アプリケーション セキュリティ エンジニア 業務の利害関係者 クラウド開発者またはソフトウェア エンジニア クラウド ソリューション アーキテクト データ サイエンティストまたはアナリスト データベース管理者 |
DevOps のエンジニア インフラストラクチャ エンジニア 製品マネージャーまたは所有者 品質保証 (QA) エンジニア サポート チーム メンバー |
一元化されたチームと利害関係者
一元化されたチームは多くの場合、ワークロード チームをサポートします。 一元化されたチームは、サポート機能を提供し、組織内の多くまたはすべてのクラウド ワークロードにガバナンスを適用します。 一元化されたチームは、組織の成功に重点を置きます。この成功の一部は、組織のワークロードの成功によって達成されます。 一元化されたチームは、ワークロードのサービス、ガイダンス、ガードレールを提供します。
| 一元化されたチームとチーム メンバーの例 | |
|---|---|
| ビジネス インテリジェンス アナリスト 業務の利害関係者 クラウドのセンター オブ エクセレンス (CCoE) 委員会 クラウド プラットフォーム チーム サイバーセキュリティ アナリスト データベース管理者 エンタープライズ アーキテクト |
財務アナリスト インフラストラクチャ エンジニア 法務責任者とコンプライアンス責任者 ネットワーク エンジニア 調達スペシャリスト プロジェクト マネージャー |
Well-Architected フレームワークのワークロード チームは、ワークロードの成果に重点を置きます。 このチームは、一元化されたチーム メンバーによる特別なサポートと連携し、その恩恵を受けます。
共同責任モデル
価値を実現するには、ワークロードをデプロイして使用する必要があります。 あなたには、ワークロード チームの一員として、組織にとって価値を生み出す方法でワークロードを設計、実装、デプロイする責任があります。
ワークロードは、組織のコンテキストの中に存在します。 組織は多くの場合、管理と権限の役割を規制しています。 ワークロード チームには、組織の基盤内でワークロードを設計、実装、デプロイする責任があります。
Azure 向けのクラウド導入フレームワークに従って、ワークロードのクラウド リソースを標準化します。 標準化を厳密に適用して、ワークロード チームのオンボードに役立つ管理されたプラットフォームを実現します。 組織のクラウド運用モデルに従って、このガバナンスを適用します。
Azure ランディング ゾーンを使用すると、標準化の実行に役立ちます。 Azure では、プラットフォーム ランディング ゾーンと、プラットフォーム ランディング ゾーンを利用できます。 ワークロードは、アプリケーション ランディング ゾーンにデプロイしてください。
組織には、厳密に形式化された、Azure ランディング ゾーンと完全に一致するクラウド プラットフォーム オファリングが用意されている場合があります。 また、組織には、異なる導入戦略を持っている場合や、実装がない場合があります。 実装がない場合、ワークロード チームは、ほぼ完全に自律型のエンティティです。
組織が使用しているプラットフォームとガバナンスについては、Well-Architected フレームワークの原則をワークロードに適用する必要があります。 Well-Architected フレームワークは多くの場合、Azure ランディング ゾーンを参照しますが、特定のプラットフォームの実装には依存しません。 Well-Architected フレームワークの重要な要素、原則、チェックリスト、ガイドは、すべてのクラウド プラットフォームとほとんどのワークロードの種類を対象としています。
要件の対応
コアとなる重要な要素やワークロードのガイダンスなど、Well-Architected フレームワーク全体にわたって、推奨事項はワークロードの義務と一致します。 推奨事項には通常、どのようなチーム メンバーまたはチームがこれらの義務を促進するかは示されていません。 誰が各アクションを実行する必要があるかは、あなたが決定できます。 ワークロードレベルのマッピングを実行して、トポロジ、ワークロードの種類、重要度に関連するチームの役割と責任を決定してください。
直接ワークロード チームは、大半のワークロード要件を処理します。 一部の要件は、一元化されたチームとの共同作業として扱われます。 たとえば、実装の選択肢は、一元化されたチームが設定したガードレールに基づいている場合があります。 また、一元化されたチームが、実装の選択肢のみを処理する場合もあります。
ワークロード チームは、ワークロードの目標を協力して実現するのを支援するために、その他のチームとの作業関係を構築する必要があります。 コンポーネントまたは責任を外部委託する場合は、それらの義務を首尾よく履行する必要があります。
制約の詳細
一元化されたチームは、チームのコア機能とコア インフラストラクチャに基づいて多様なワークロードをサポートします。 一元化されたチームは、このサポートを組織規模で提供するために、提供されるサービスまたはインフラストラクチャに対して統一性と制約を実装する場合があります。 あなたがワークロードを設計する際は、これらの制約を理解し、可能であれば、それらの制約を把握しているエンタープライズ アーキテクトと提携することが重要です。 以前の実装から可能な限り学習してください。
プラットフォーム ガバナンスの実装はそれぞれ異なりますが、次の制約が多くのワークロードにおいて一般的です。
- クラウド リソースに関する許可リスト
- クラウド リソースに関する構成の権限
- クラウド リソースとクロスプレミス接続の可用性に関するリージョンの許可リスト
- 営業時間外のプラットフォームのサポートの制限またはサポートなし
- 修正プログラムの要件
- ドメイン ネーム システム (DNS) とプライベート エンドポイントの実装を促進する特定のハブスポーク実装
- サプライ チェーン制御の要件
要件の明示的な伝達
ワークロードの要件が、コア機能またはインフラストラクチャ オファリングを明確に定義していない制約またはサービス レベル アグリーメント (SLA) に直面している場合、その状況をリスクとして扱います。 このリスクに対処するには、ワークロード チームが、その懸念がワークロードにどのように影響するかについて、その他のチームに明確に伝える必要があります。 ワークロードの要件、設計、または実装を変更したり、インフラストラクチャ オファリングを変更したりする必要がある場合があります。
組織の指示に関連するプラットフォーム チームの義務とワークロード チームの義務を理解したら、ワークロードの要件と共に現実的な期待事項と推奨事項を伝えることができます。
一般的なワークロード要件の伝達
プラットフォームのパートナーシップはそれぞれ異なりますが、共有責任に関する会話では、次の領域が共通のトピックとなります。
- コンプライアンス要件と法務要件
- 静的なイングレスまたはエグレス IP アドレスの必要性などのネットワークの詳細
- 有効なライブ サイトトリアージを提供するための監視要件
- ネットワーク スループット、クラウド リソースの可用性、リージョンの可用性などのパフォーマンス要件
- エグレスとイングレスの観点からのパブリック インターネット アクセスに関する期待事項
- ワークロードのユーザーに提供されるサービス レベル目標 (SLO) または SLA
- テクニカル サポートの可用性
統合的な成果の追求
共同責任は、トレードオフ、制約、侵害に関するものだけではありません。 プラットフォーム チームには多くの場合、高度に特化されたスキルと専用の予算があり、これらは個々のワークロード チームが維持できる範囲を超えて拡張できます。 次の例を考えてみます。
セキュリティ スペシャリスト。 ワークロードには、安全な開発ライフサイクルがある場合があります。 一元化されたセキュリティ チームは、組織全体にわたって安全な開発タスクを大規模に実行するため、取り組みの範囲を超えた日常的な侵入テストを実行する場合があります。 また、インシデント応答戦略の計画と実行を支援する場合もあります。
エンタープライズ アーキテクチャ ガイダンス。 エンタープライズ アーキテクチャ チームは既にプロセスを合理化しているため、このチームのパターンとプラクティスに合わせて調整すると、時間と労力を節約できます。 また、パートナーシップ内で交渉なしでソリューションを実現することが不可能な場合は、再作業を防ぐことができます。
高額な支出。 プラットフォーム チームは多くの場合、個々のワークロード チームにとっては高額すぎたり管理範囲が広すぎたりするコンポーネントやサービスをホストします。 プラットフォーム チームは、ワークロード間でコストを分割するため、これらのコンポーネントとサービスを提供するだけの余裕があります。
多くの場合、これらのサービスまたは一元化されたプラットフォームは単なるショーバックとして提供されるため、ワークロードのコストの最適化を維持する上で役に立ちます。 また、これらは、チャージバックとして提供される場合はたいてい、スケールと一元化の経済性のため、低コストになります。
プラットフォーム チームは多くの場合、さまざまなアクティビティを対象としてワークロード チームにセルフサービス オプションを提供します。 次に例を示します。
- セルフガイド付き教育用のドキュメント リポジトリの提供
- 特定のリソースのタグ付けを介したコスト管理へのオンボーディング
- 正式なサブスクリプションの自動販売プロセスを介したサブスクリプションの提供
ワークロードに適している可能性があるセルフサービスとプラットフォームのエンジニアリング オプションについてご確認ください。
成功と課題の共有
その他のチームと責任を共有することは、ワークロードの成功と課題を共有することも意味します。 ワークロードがその義務を満たし、意図した価値を得た場合は、それをパートナー チームと共有します。 パートナー チームがワークロードの成功にどのように貢献したかを伝えます。 ワークロードが義務を果たしていない場合は、何がうまくいかなかったのかを共有し、共同作業と再調整を行い、再び軌道に乗れるようにします。
プラットフォーム チームには、義務と成功基準もあります。 ワークロードがオファリングとうまく連携しているかどうか、または迷惑な存在になる危険性があるかどうかを、パートナーから伝えてもらえることを期待する必要があります。
継続的改善のための懸命な努力
Well-Architected フレームワークの重要な要素すべてにわたるのテーマの 1 つが、継続的な改善です。 進歩的な考え方を採用してください。 既存の問題に対する新しいアプローチに対処する場合、新しいテクノロジを採用する場合、新しい要件に対処する場合、新しい制約の下で業務を遂行する場合などがあります。 ワークロードが時間の経過と同時に改善されるにつれて、パートナー チームも同じ考え方になることを期待してください。 ただし、改善の機会はすべて変更も意味するため、適切な管理プロセスによってサポートされる必要があります。
ワークロード チームには、プラットフォーム チームのサービスに影響を与える可能性がある、ワークロード要件に対して提案された変更をプラットフォーム チームに伝える義務があります。 同様に、プラットフォーム チームには、ワークロード パートナーを変更制御プロセスに加えて、影響を受けるプラットフォームの変更を明確に伝える義務があります。 製品の進化について学習し、それを共有するために、パートナーとの定期的なコミュニケーションを確立してください。
成功につながる結果の達成
ワークロードには、ユーザー、株主、規制機関、従業員、センター オブ エクセレンス、最高エクスペリエンス責任者から多くの期待が寄せられます。 さまざまな期待のために、ワークロードの向かう方向が定まらない場合があります。 このようなときに、Well-Architected フレームワークを使用して、成功につながる結果を達成するためにアーキテクチャ上の決定を明示的に合理化することで、設計と実装に関する明確さを実現できます。 成功につながるワークロードを開発し、その成功を組織内で共有してください。