ビジネス要件の設計

完了
目的とするワークロードの実用性に重点を置き、ビジネス要件を集めます。

ビジネス要件は、ビジネスの利害関係者とワークロード アーキテクト間の共同作業を通して定義されます。 ワークロードが満たす必要がある信頼性目標に適切に取り組みつつも、合意された要件が現実的で達成可能であるようにするには、双方で妥協を行う必要があります。 要件は、ワークロードに固有のユーザー エクスペリエンス、データ、ワークフロー、特性をカバーする必要があります。 要件プロセスの結果では、期待値を明確に述べる必要があります。 目標は、規定された投資の下で、達成可能かつチームと交渉されたものである必要があります。 これらは、技術的な選択、実装、運用を推進するために文書化する必要があります。

サンプル シナリオ

Contoso Insurance は、保険契約者の要求を処理するための Web アプリケーションを開発する初期の設計段階にいます。 コア ユーザー フローとシステム フローの大部分が決定され、ワークロード チームは、次に示すアプリを構成するいくつかの Azure サービスを特定しました。Azure App Service、Azure SQL Database、Azure AI サービス、Azure Event Grid、Azure Logic Apps。

信頼性目標を特定する

個々のコンポーネント、システムおよびユーザー フロー、システム全体に関するインジケーターに目標を設定して、成功度合を定量化します。

メトリックは期待値を定量化します。 これによって、複雑性を理解し、複雑性の下流コストが投資の制限内に収まるかどうかを判断できます。

目標値は理想的な状態を表します。 この値を、目標状態からの逸脱と、目標状態に戻るまでにかかる時間を検出するのに役立つテストしきい値として使用できます。

コンプライアンス要件には、スコープ内フローに関する予測可能な結果も含める必要があります。 これらのフローに優先順位を付けると、最も重要な領域に注意が向けられます。

"Contoso の課題"

  • ワークロード チームは、ワークロードの信頼性を高めるためのリソースの消費方法が最適化されていることを確かめたいと考えています。
  • チームは、ワークロードをフローに分解し、それぞれの重要度に基づいてフローを評価しました。

"アプローチの適用と結果"

  • 要求の送信と承認のフローの可用性には医師と患者が依存しているため、このフローはワークロードに対する最も高い信頼性要件を持つことになるとチームは判断します。
  • ワークロード チームは、このフローをサポートするコンポーネントを特定し、目標の達成に必要となる信頼性の尺度を決定します。

プラットフォーム コミットメントを理解する

クラウド プラットフォームによって提供される保証された信頼性メトリックを理解し、サービスの制限、クォータ、容量の制約を検討します。

サービス レベル アグリーメント (SLA) はサービスによって異なります。 すべてのサービスと機能が均等にカバーされるわけではありません。 カバー範囲と制限をよく理解しておくことは、ドリフトを検出し、回復性と復旧のメカニズムを構築するのに役立ちます。

"Contoso の課題"

  • ワークロード チームと利害関係者は、アプリのデータには、要求の送信と承認のフローの重要度に対応するために、30 秒を超えてはいけない保証復旧時間目標 (RTO) が必要であると判断しました。

"アプローチの適用と結果"

  • Microsoft が公開した SLA を確認した後、チームは、この RTO 目標を達成するためには、Business Critical レベルとアクティブ geo レプリケーションをデプロイする必要があることを発見します。

依存関係とそれらの回復性への影響を特定する

ワークロードをコンポーネントに分解する場合は、すべての依存関係を文書化したことを確認し、それがビジネスにとって内部的であれ外部的であれ、依存関係の誤動作がフローにどのように影響を与える可能性があるかを特定します

依存している他のチームまたはサード パーティによって開発されたインフラストラクチャ、サービス、API、および機能を追跡することは、それらの依存関係がない状態でワークロードが動作できるかどうかを判断するのに役立ちます。 また、連鎖障害を理解し、下流工程を改善するのにも役立ちます。 障害の影響を受けやすい可能性のある外部サービスを使用する場合、開発者は、回復性がある設計パターンを実装して起こり得る障害に対処することができます。

"Contoso の課題"

  • 要求の送信と承認のフローは、Contoso Insurance 内の別の部署によってホストされ管理されている小さな参照データセットに依存しています。
  • このデータセットは、通常の営業時間中に 1 日複数回更新されます。
  • このアプリは、参照データが多少古くなっても耐えられるように設計されていますが、データは常にアプリにとって利用可能である必要があります。

"アプローチの適用と結果"

  • ワークロード チームは、参照データセットをサポートしているチームと連携し、データセットの信頼性目標が、それを使用するフローの信頼性目標よりも低いことを確認します。
  • チームは、データセットのローカル キャッシュと、キャッシュを毎晩更新するバックグラウンド ジョブを追加するための設計タスクをバックログに追加します。 この設計で許容される古さの許容範囲はこのソリューションによっては違反されません。

自分の知識をチェックする

1.

信頼性目標を定義するべきワークロードの側面として適切でないのは、以下のうちどれですか?

2.

ワークロードをコンポーネントに分解する場合、信頼性設計のために考慮するべき側面は以下のうちどれですか?

3.

Contoso Insurance のワークロード チームは、さまざまな Azure App Service SKU の保証アップタイムについて知りたいと考えています。 この情報はどこで調査するべきですか?