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