現実的なパフォーマンス目標をネゴシエートする
 意図するユーザー エクスペリエンスを定義します。ベンチマークを開発し、事前に確立したビジネス要件に対して目標を測定するための戦略があります。 |
|---|
パフォーマンスの観点からは、パフォーマンス目標を適切に定義してから設計プロセスを開始するのが理想的です。 そのような目標を設定するには、ビジネス要件を十分に理解し、ワークロードが提供することが期待されるサービスの品質を予想済みである必要があります。 ビジネス利害関係者と協力して、期待されるものを定義します。 技術的メトリックに焦点を当てるだけではなく、主要なフローについて許容できるユーザー エクスペリエンスへの影響を決定します。
そこには循環依存の関係が存在します。 定義していないものを測定することはできず、測定なしで定義することはできません。 したがって、許容できるしきい値について、共同の同意によって満足のいく定義が得られるまでワークロードのパフォーマンスを測定することも重要です。
パフォーマンス目標と信頼性目標の間には強い相関関係があり、パフォーマンス、可用性、回復性の観点からサービスの品質を決定するのに役立ちます。 明確な定義がないと、パフォーマンスの測定、警戒、テストは困難になります。 テストに時間をかけて目標を確立し、実際の数値を特定したら、それらの目標に対して継続的なテストを行うための自動化を実装できます。
目標を定義する際は、概算であっても範囲内であっても、マクロ レベルでベスト プラクティスに従います。
サンプル シナリオ
Contoso Bicycle は、米国の自転車直接販売ブランドです。 その開発チームでは、計画されている Contoso のモバイル自転車修理サービスをサポートするアプリの構築に取り組み始めました。 アプリは現在、概念実証フェーズにあります。 技術者はモバイル アプリを使って各自のスケジュールと作業指示書を管理し、支払いを受けます。 顧客は Web サイトを使ってサービスのスケジュールを設定します。 Web アプリ、モバイル アプリ、バックエンド API は、すべて Azure App Service 上でホストする予定です。
パフォーマンス目標をネゴシエートする準備をする
技術的な概念を理解し、使用できるインフラストラクチャでの設計の可能性を探り、可能な場合は具体的な実験の結果を使用して、効果的なネゴシエーションを準備します。 過去のデータを使って使用パターンとボトルネックを把握します。 外部要因から分析情報を得ます。たとえば市場分析、エキスパート、業界標準からの情報などです。
実用的な分析情報によって情報に基づいた意思決定を行うことができます。
パフォーマンス目標の焦点はユーザー エクスペリエンスに置かれ、それは何が実現可能か、業界のベスト プラクティス、現在の市場動向に基づきます。
"Contoso の課題"
- ビジネス利害関係者とのアプリケーションに関するディスカッションにおいて、パフォーマンスがまだ議論されていません。
- 開発チームは初めて Azure を使用するため、このプラットフォームのパフォーマンスとスケーリング機能に精通していません。
- 利害関係者からの助言と何が可能かについての実用的な知識がないので、チームではテスト用にインフラストラクチャをデプロイし、後でリビルドしなければならなくなるのではないかと心配しています。
- また、チームでは、次に会うときに現実的なパフォーマンス目標について話せる人がいないのではないかと心配しています。
"アプローチの適用と結果"
- Contoso のビジネス アナリストと開発者は懸念事項について話し合い、次のような計画を立てます。ビジネス アナリストは、競合分析と非公式のアンケートによってパフォーマンスの期待値を調査します。開発チームは、Azure のさまざまな価格レベルの機能とオプションを調査します。
- チームは、集めたデータを携えてビジネス利害関係者と再会し、そのデータをパフォーマンス目標に関するネゴシエーションの根拠として使用します。 潜在的なパフォーマンス機能と関連するコストについてのディスカッションを通じて、すべての関係者がワークロードに App Services を使用することについて満足します。
パフォーマンス目標を効果的にネゴシエートする
ビジネス所有者と協力して、品質と該当する場合は規制コンプライアンスの観点から、ユーザーと約束することを把握します。 この段階では広い視野を維持し、細かい詳細には踏み込まないようにします。 投資に基づき、何が許容可能なパフォーマンスを表すかを明確にし、ビジネス コンテキストと予想される成長を把握します。
このアプローチを採用することで、ビジネス目標に合わない可能性のある憶測を避けることができます。 また、ワークロード チーム内での明瞭さとモチベーションが促進されます。
機能要件と非機能要件に関するビジネス コンテキストが得られると、Azure Well-Architected の他の柱における設計変更が明らかになる可能性があり、情報に基づいたトレードオフを行うのに役立ちます。
早期にパラメーターを定義することは、後ほど発生する可能性があるソリューションの再設計に関連するコストを回避するのに役立ちます。パフォーマンス目標が将来の予測にも対応することを保証できるため、現在の取り組みを長期的な目標に合わせて調整できます。
"Contoso の課題"
- アーキテクチャ チームは、許容可能な内容についての大まかなアイデアを持っていますが、まだ詳細はわかっていません。 アーキテクトは、一般にアプリケーション プラットフォームの選択によって再作業を回避できるようにする必要があると感じていますが、これまでに得られた情報よりももう少し具体的な情報があれば、より自信を持つことができるでしょう。
- 現時点まで、パフォーマンスに関するディスカッションはあいまいであり、「Web サイトは速くする必要がある」といった意見が出ています。
- アーキテクトは、もう少し具体的な情報が得られないと、パフォーマンスのために設計をオーバーエンジニアリングしたり、遅延が発生して運用環境へのリリースが延期されたりするかもしれないと心配しています。
"アプローチの適用と結果"
- ビジネス パートナーと技術チームが集まって、全般的ですが現実的な目標と、絶対に避けなければならないいくつかの制限事項について合意を得ます。 それらに基づき、アーキテクトは初期設計の一環として概念実証を行い、アプリケーション プラットフォームに関する大筋での合意を得て、パフォーマンスと価格に関するいくつかの調査結果を提示することができます。
- この会議の成果の 1 つは、Contoso Bicycle が最初の 1 年間は米国南西部だけで運用し、2 年目から全国展開することを計画していることがわかったことです。 この情報は設計の考慮に入れられます。
フロー中心で設計する
ワークロード フローを特定し、アーキテクチャ図の各フローに優先順位を付けます。 各フローのパフォーマンス許容範囲を、野心的なパフォーマンスから許容できないパフォーマンスまで定義します。 各フローの入口と出口を、そのパスの重要度、使用頻度、アーキテクチャの強度を考慮して評価します。
フローに優先順位を付けることで、ユーザーとビジネス成果に最も大きな影響を与える重要な領域にリソースを集中させることができます。
システムを各パーツと依存関係に分割することで、各コンポーネントの機能とパフォーマンスへの影響を理解できます。 また、潜在的な問題に気付くこともできます。
これは、パフォーマンス ベースラインを確立し、最適化を推進するのに役立ちます。
"Contoso の課題"
- これまで、技術チームは利害関係者と協力して大まかなパフォーマンス目標を特定してきましたが、個々のフローにはまだ焦点を当てていませんでした。 サービス ロケーターや支払いフローなど、設計チームがフローについてより深く掘り下げられるようにするには、それらのフローの要件を理解する必要があります。
- そのような具体的な要件がないと、主要なフローに割り当てるリソースが少なすぎたり、優先順位の低いフローに割り当てるリソースが多すぎたりする設計上のリスクが発生します。
"アプローチの適用と結果"
- アーキテクチャ チームは、ビジネスのユーザー フローを確認した後、フローごとに非常に具体的な目標を文書化しました。 ワークロードの分解では、フローごとに野心的から許容不可までの範囲が考慮されるようになりました。
- アーキテクトは、設計によって野心的な目標を達成し、システムが時間の経過と共に追加機能で発展できる余地を与えながら、コストやその他の非機能要件を制御するためにある程度妥協することに努めます。
- チームは、合意された目標に従って設計を完成させることができます。次に、実装チームは、これらの制限事項を必ず守り、作業元の設計上守れないという場合は懸念を提起することについて責任を負います。