現実的なパフォーマンス目標をネゴシエートする

目的のユーザー エクスペリエンスを明確に把握します。 ベンチマークを作成し、設定したビジネス要件に対する進捗状況を測定します。

パフォーマンスの角度から、明確なパフォーマンス 目標で設計プロセスを開始することをお勧めします。 それらを設定するには、ビジネスニーズとワークロードが提供するサービスのレベルをしっかりと理解する必要があります。 ビジネス利害関係者と協力して、それらの期待を一緒に定義します。 技術的なメトリックに焦点を当てるのではなく、特に最も重要なフローについて、ユーザー エクスペリエンスに許容される影響の種類について考えてください。

ここには少しループがあります。 定義していないものを測定することはできません。また、何らかの測定なしでは多くを定義することはできません。 そのため、受け入れ可能なしきい値としてカウントされる内容に全員が同意するまで、ワークロードのパフォーマンスを追跡し続ける必要があります。

パフォーマンスと信頼性のターゲットが手に入る。 どちらも、パフォーマンス、可用性、回復性に関してサービスの品質を形成するのに役立ちます。 明確な定義がないと、パフォーマンスの測定、アラートの設定、テストの実行は困難です。 ターゲットを定義し、時間の経過に伴うテストを通じて実際の数値を把握したら、テストの自動化を開始して、それらのターゲットに対するチェックを続けることができます。

ターゲットを大まかに定義する場合は、最初に大まかな見積もりや範囲であっても、ベスト プラクティスに従います。

サンプル シナリオ

Contoso Bicycle は、米国を拠点とする消費者向け自転車ブランドです。 開発チームは、今後のモバイル バイク修理サービスをサポートするために、新しいアプリの作業を開始しました。 現在、アプリは概念実証 (POC) 段階にあります。 技術者はモバイル アプリを使用して、スケジュールの処理、作業指示の管理、支払いを行います。 顧客側には、ユーザーがサービスの予定を予約できる Web サイトがあります。 Web アプリ、モバイル アプリ、バックエンド API は、Azure App Service でホストされる可能性があります。

パフォーマンス目標をネゴシエートする準備をする

交渉の準備を整えるために、技術的な詳細を本当に理解し、持っているインフラストラクチャで何が可能かを調べ、自分が行った実践的なテストの結果に頼ることができます。 履歴データを使用して、使用パターンとボトルネックの場所をより明確に把握できます。 また、市場調査からの洞察、専門家からのアドバイス、業界標準に基づくガイダンスなど、外部の視点を取り入れるのも賢明です。

実際のエクスペリエンスから得られた分析情報に頼ることで、スマートな意思決定を行うことができます。

パフォーマンスはユーザー エクスペリエンスに重点を置き、現実的なもの、業界でベスト プラクティスと考えられているもの、現在市場で注目されている内容によって形成されます。

"Contoso の課題"

• チームがビジネス関係者とアプリについて話したとき、パフォーマンスはまだ出ていません。

• 開発チームは Azure を初めて使用するため、プラットフォームでのパフォーマンスとスケーリングの動作についてあまりよく知りません。

• 利害関係者からの明確な指示や、Azure でできることに関する実践的な経験がなければ、チームは、テスト用のインフラストラクチャをデプロイし、後で再構築する必要があることを少し神経質にしています。

• また、誰もが次に会うときに、現実的なパフォーマンス目標の外観について実際の会話をする準備ができていないことも懸念しています。

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

• Contoso Bicycle のビジネス アナリストと開発者は、懸念事項を通じて話し合い、計画を立ててきました。 ビジネス アナリストは、競争的な調査と非公式のポーリングを行うことでパフォーマンスの期待を掘り下げ、開発チームは Azure が何をできるかを調べ、さまざまな価格レベルを調査します。

• チームがビジネス利害関係者と一緒に戻ると、収集したすべてのデータを持ち込み、パフォーマンス目標に関する実際の会話の開始点として使用しました。 予想されるパフォーマンスの種類とコストがどのようなものかを説明した後、誰もが App Service がワークロードに適していると確信して立ち去りました。

パフォーマンス目標を効果的にネゴシエートする

ビジネスオーナーと協力して、特に品質や適用される可能性のある規制要件に関して、ユーザーに約束されていることを明確に把握してください。 今のところ、ビューを広く保ちます。 この時点で詳細を確認する必要はありません。 投資に基づいて、許容可能なパフォーマンスとして何がカウントされているかを事前に確認してください。 ビジネスの全体像と、成長が期待される場所を理解していることを確認します。

このアプローチを使用すると、ビジネスが実際に必要とするものに合わない可能性のある仮定を明確にするのに役立ちます。 また、ワークロード チームにより明確さとエネルギーをもたらします。

機能要件と非機能要件の両方を含むビジネス コンテキストを理解すると、Azure Well-Architected Framework の他の領域で設計を調整する機会が見つかる場合があります。 このような分析情報は、よりスマートなトレードオフを実現するのに役立ちます。

これらのパラメーターを早い段階で定義すると、後でソリューションを再設計する必要があるコストと手間を省くことができます。 また、パフォーマンスの目標が今日だけではないことも確認します。 ワークロードが将来どこに向かうかをサポートするように設定されているため、現在の作業は長期的な目標に沿った状態を維持します。

"Contoso の課題"

• アーキテクチャ チームには、受け入れられる可能性のあるものについての一般的な感覚がありますが、まだ具体的な情報はありません。 アプリケーション プラットフォームの選択が手戻りを避けるのに役立つと確信していますが、さらに具体的な詳細があれば、より良い感じがします。

• これまで、パフォーマンスの会話は、「Web サイトは高速である必要がある」など、かなりあいまいでした。その分析情報は、設計上の意思決定に関しては非常に役に立ちません。

• より明確にしないと、設計者は、安全であるためにソリューションを過剰にエンジニアリングしたり、運用リリースを押し戻す可能性のある遅延に陥ったりする可能性があることを心配しています。

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

• ビジネス パートナーと技術チームは、一般的で現実的なパフォーマンス目標と、絶対に避ける必要があるいくつかのハード制限について合意しました。 その明確さにより、アーキテクトは初期の設計作業の一環として POC を進めることができます。 その結果、アプリケーション プラットフォームの選択を検証し、パフォーマンスと価格に関する早期の調査結果を共有することができます。

• 会議の大きなポイントの 1 つは、Contoso Bicycle が最初の 1 年間に米国南西部でのみ運用する予定で、2 年目に全国に拡大する予定であることを学ぶことでした。 この種の詳細は非常に役に立ち、間違いなく設計に組み込まれます。

フロー中心で設計する

ワークロード内のさまざまなフローをマップし、最も重要なフローを把握します。 アーキテクチャ図でこれらのフローを強調表示します。 フローごとに、理想的に望むものから、まったく許容できないものまで、パフォーマンスの範囲を定義します。 各フローの開始位置と終了位置を詳しく見てみましょう。 そのパスがどれだけ重要であるか、どのくらいの頻度で使用されているか、アーキテクチャの観点から見て複雑であるかを考えてください。

ワークロード フローに優先順位を付けると、時間とリソースが、ユーザー エクスペリエンスとビジネス結果に本当に影響する領域に向かっていることを確認できます。

システムをその部分に分割し、相互に依存する方法を理解すると、各コンポーネントの動作とパフォーマンスへの影響を確認するのに役立ちます。 また、問題が発生する可能性のある場所に関する情報も提供します。

この種の分析は、優れたパフォーマンス ベースラインを設定するのに役立ち、改善を行う明確な開始点を提供します。

"Contoso の課題"

• これまで、技術チームは利害関係者と協力して、いくつかの高レベルのパフォーマンス 目標について合意してきましたが、特定のフローにまだ焦点を当てていないのです。 設計チームがサービス ロケーターや支払いフローなどのフローを掘り下げるには、それぞれに何が期待されているかを把握する必要があります。

• これらの詳細がないと、実際に重要なフローに十分なリソースを与えないか、重要ではないフローのオーバービルドによって、設計がマークを見逃すリスクがあります。

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

• ビジネス チームと共にユーザー フローを進めた後、アーキテクチャ チームには、それぞれについて明確で詳細なターゲットが書き留めることができるようになりました。 熱望的な範囲から許容できない範囲まで、各フローに対するパフォーマンスの期待を完全に反映する方法でワークロードを分割しました。

• 設計者は、システムが成長し、後で新機能をサポートする余地を持っているので、設計でこれらの願望的な目標を目指しています。 同時に、コストやその他の機能以外の要件を念頭に置いているため、意味のあるいくつかのトレードオフを行っています。

• これらのターゲットがロックされた状態で、設計が完了しました。 これらの制限に準拠し、ターゲットが現在の設計に到達しにくくなるものに達した場合は、実装チームが声を上げる必要があります。