次の方法で共有

パフォーマンス効率の設計原則

パフォーマンス効率とは、ワークロード リソースを効果的に使用することにです。 適切な戦略がないと、ユーザーの要求を予測して満たすことができなくなる可能性があります。 長期的な予測に基づいて容量を事前プロビジョニングするアプローチに頼る必要がある場合があり、クラウド プラットフォームを最大限に活用することはできません。

パフォーマンス効率は、ユーザー エクスペリエンスに影響を与えずに負荷の増加に対応するようにスケールアップし、需要の少ない間にリソースを節約するためにスケールダウンすることで、変化する需要に適応するワークロードの能力です。 容量は中心的な役割を果たしますが、事前にプロビジョニングされたリソースのみに依存すると、負荷が高くなり、使用率が低い場合は不要なコストでパフォーマンスの問題が発生する可能性があります。

パフォーマンスを後の考えとして扱うのではなく、最初から重要な考慮事項にします。 厳密なパフォーマンス目標がない場合でも、早い段階から始め、開発全体を通じてテストと調整を行います。 この継続的な最適化は、実際の使用によって通知され、将来の問題を防ぎ、一貫したパフォーマンスを確保するのに役立ちます。

適切に計画された戦略は、無駄を最小限に抑えながら、リソース容量をビジネス ニーズに合わせて調整するのに役立ちます。 アプローチを定義したら、 パフォーマンス効率チェックリスト を使用して設計を検証します。 プロアクティブな戦略がないと、静的予測に依存し、スケーラブルなクラウド インフラストラクチャの利点をすべて失うリスクがあります。

現実的なパフォーマンス目標を交渉する

目標アイコン 想定されるユーザー エクスペリエンスは定義されており、あらかじめ設定されたビジネス要件に対してベンチマークを策定し、目標を評価するための戦略があります。

パフォーマンスの観点からは、パフォーマンス目標を適切に定義してから設計プロセスを開始するのが理想的です。 そのような目標を設定するには、ビジネス要件を十分に理解し、ワークロードが提供することが期待されるサービスの品質を予想済みである必要があります。 ビジネス利害関係者と協力して、期待されるものを定義します。 技術的メトリックに焦点を当てるだけではなく、主要なフローについて許容できるユーザー エクスペリエンスへの影響を決定します。

そこには循環依存の関係が存在します。 定義していないものを測定することはできず、測定なしで定義することはできません。 したがって、集合契約で 許容できるしきい値の定義が十分に得られるまで、ワークロードのパフォーマンスを測定 することも重要です。

パフォーマンス目標と信頼性目標の間には強い相関関係があり、パフォーマンス、可用性、回復性の観点からサービスの品質を決定するのに役立ちます。 明確な定義がないと、パフォーマンスの測定、警戒、テストは困難になります。 テストに時間をかけて目標を確立し、実際の数値を特定したら、それらの目標に対して継続的なテストを行うための自動化を実装できます。

目標を定義する際は、概算であっても範囲内であっても、マクロ レベルでベスト プラクティスに従います。

方法 メリット
技術的なオプションを理解し、設計の可能性を探り、実験結果を適用して、効果的なネゴシエーションを準備します。

履歴データを使用して、使用パターンとボトルネックを特定します。 意思決定を導くために、市場分析、業界標準、専門家の意見からの洞察を組み込みます。		 実用的な分析情報によって情報に基づいた意思決定を行うことができます。

パフォーマンス目標は、実現可能な内容、業界のベスト プラクティス、および現在の市場動向に基づくユーザー エクスペリエンスに基づいています。
投資レベルを考慮して、ユーザーの期待とパフォーマンス標準に関するビジネス所有者と一致させます。

より広範なビジネス コンテキストと成長計画を念頭に置きながら、設計の初期段階で詳細な詳細を確認することは避けてください。		 誤った仮定を回避し、チーム内の明確さと動機を促進し、トレードオフに関する情報に基づいた設計上の決定を行います。

また、パフォーマンス目標が将来のニーズを考慮し、現在の作業を長期的なビジネス目標に合わせることも保証されます。
パフォーマンスへの影響に基づいて、アーキテクチャ内の重要なフローに優先順位を付けます。

理想的なものから許容できないフローまで、各フローのパフォーマンス許容範囲を定義します。 使用頻度、重要度、複雑さを考慮して、入退出ポイントを評価します。		 フローに優先順位を付けることで、ユーザーとビジネス成果に最も大きな影響を与える重要な領域にリソースを集中させることができます。

システムを各パーツと依存関係に分割することで、各コンポーネントの機能とパフォーマンスへの影響を理解できます。 また、潜在的な問題に気付くこともできます。

これは、パフォーマンス ベースラインを確立し、最適化を推進するのに役立ちます。
初期パフォーマンス目標を計算するために、使用パターン、ビジネスへの影響、運用コストを考慮したパフォーマンス モデルの開発を開始します。 業界標準を使用して主要なメトリックを定義および測定し、将来の成長を考慮しながら、ビジネスの制約内での需要と供給を評価します。

これは反復的なプロセスとして扱い、テストと運用中に実行中のソリューションから収集された実際の観察とメトリックによって通知されるターゲットを絞り込みます。 アプリケーションのライフサイクル全体にわたって意味のある使用状況の分析情報を得るテスト ケースに優先順位を付けます。		 パフォーマンス モデルは、戦略的なリソースの計画と最適化に役立ち、業界標準によるベンチマークをサポートし、パフォーマンス目標が時間の経過と同時に適応可能で関連性のあるものに保たれるようにします。

これらの進化する目標に基づいて、正確な容量計画を実行し、ソリューションのライフサイクル全体にわたって関連性のあるパフォーマンス ベースラインを確立することができます。

容量要件を満たすように設計する

目標アイコン 予想される需要に対応するのに十分な供給を提供します。

パフォーマンスをプロアクティブに測定することが重要です。 パフォーマンスを測定するには、 ベースラインを測定 し、システムのどのコンポーネントが課題となる可能性が高いかを事前に理解する必要があります。 これは、完全なパフォーマンス テストを実行したり、きめ細かな最適化を行ったりすることなく実現できます。 これらの初期の手順を実行することにより、開発ライフサイクルの早い段階で、効果的なパフォーマンス管理のための基礎が確立されます。

個々のコンポーネントに焦点を絞るのではなく、システムを全体として調べます。 この段階での微調整は避けます。 きめ細かなパフォーマンスの向上を行うと、他の領域でトレードオフが発生します。 ライフサイクルを進め、ユーザー受け入れテストを開始したり、運用環境に移行したりしていくうちに、さらに最適化が必要な領域をすばやく識別できるようになります。

方法 メリット
使用要件に基づいて、優先順位付けされたフローの動的スケーリングのニーズを評価します。 予想される需要パターンを理解し、それらの要件を満たすために各フローを柔軟にする必要がある方法を決定します。 より多くの容量を必要とする既存のコンポーネントと、負荷を分散するために追加のコンポーネントが必要な領域に対してスケーラビリティ要件を定義できます。
適切なリソースを選択し、テクノロジ スタック全体で適切にサイズ変更することで、パフォーマンス目標を達成できます。

スケーラビリティ要件を満たすことができる機能を検討してください。		 システム全体は、定義されたターゲットに従って実行されます。 必要に応じて自動的にスケーリングする組み込み機能を使用できます。 また、オーバープロビジョニングを回避し、需要の変化を処理しながらコストを節約するのにも役立ちます。
パフォーマンス モデルと選択したリソースの機能に基づいて容量計画を実行します。

予測モデリング手法を使用して、容量の予想される変化を予測します。		 システムは、将来の需要に備えながら、パフォーマンス目標を満たすことができます。 予測モデリングは、リソース不足やオーバープロビジョニングを回避して、信頼性とコスト効率を向上させる、事前に計画するのに役立ちます。
技術的な要件を満たすために、概念実証を実装し、提案された設計の選択肢を検証します。 概念実証は、設計がパフォーマンス目標と予想される負荷を満たすことができるかどうかを検証するのに役立ちます。

パフォーマンスの達成と維持

目標アイコン システムの使用中および進化に伴うパフォーマンスの低下から保護します。

開発は、一度きりの作業ではありません。 継続して行うプロセスです。 機能が変更されたら、パフォーマンスの変更も想定しておきましょう。 ユーザーのパターンやプロファイルはさまざまですが、他の Azure Well-Architected の柱の最適化からの変更もさまざまです。 変更が行われると、ワークロード リソースに負担が生じかねません。

システムがパフォーマンス 目標にスライディング バックしないように保護します。 実負荷を使用して運用環境でのシステムのパフォーマンスをテストし、運用前の自動テストでその負荷をシミュレートします。 どちらの場合も、検証に向けた監視プラクティスの実施が必要です。

パフォーマンス目標は、変更に応じて、時間の経過とともに変わってゆくことを念頭に置いておきましょう。 テスト済みで監視対象のメトリックに基づいて、パフォーマンス モデルを更新します。 増加、減少、影響なしなど、フローのパフォーマンスに対する影響を明確に示します。

ビジネス関係者との再交渉や期待値の再設定については、常に準備を整えておきましょう。

方法 メリット
パフォーマンス テスト戦略を定義します。

手動の低労力テストを含むさまざまな種類のテストを実施し、ベンチマークを見直します。

パイプラインで適切に動作するツールを使用して、定期的なパフォーマンス テストをパイプラインに追加します。		 リソースが効果的に割り当てられていることを確認し、容量計画に従ってメトリックを検証できます。

自動化された定期的なパフォーマンス テストは、待機時間、ストレス、負荷容量などの主要な要因を一貫して評価するのに役立ち、問題を早期に検出し、時間の経過と同時にパフォーマンスを安定して維持することが容易になります。
パフォーマンス テストを品質ゲートとして形式化します。 これらのチェックポイントにより、デプロイの各ステージがパフォーマンス標準を満たしていることを確認してから、次に進みます。 問題を早期にキャッチするのに役立ち、質の高い意思決定を行うことができます。 たとえば、パフォーマンスが予想を下回った場合にリリースをブロックします。
エンド ツー エンドのビジネス トランザクションと、CPU、待機時間、1 秒あたりの要求などの技術的メトリックの両方を追跡するパフォーマンス監視プロセスを設定します。

運用環境で実際のトランザクションと代理トランザクションを使用していることを確認します。

パフォーマンスの低下に関する監視アラートを設定します。		 システムのすべての部分を監視することで、明確な可視性が得られ、インフラストラクチャとアプリケーションの両方の問題をすばやく検出できます。 パフォーマンス標準を維持し、進行状況を追跡したり、早期に問題を特定したりするために、リソースを微調整するのに役立ちます。
使用状況が増加し、運用環境のシステムにデータが蓄積されると、パフォーマンス テストの結果と監視データを細心の注意を払って確認します。

パフォーマンスの低下に対処するアクションに優先順位を付け、計画的な実行のためにバックログに追加します。		 データを使用してパフォーマンスの傾向を追跡および比較すると、ユーザー エクスペリエンスに影響を与える前に、情報に基づいた最適化の決定を行い、問題を早期にキャッチするのに役立ちます。

また、容量が既に存在するシステムを過剰に最適化していないことを保証します。
アプリケーションと基になるコンピューティング層とデータ レイヤーを考慮して、テクノロジ スタック全体のパフォーマンスを微調整できる設計パターンについて説明します。 ボトルネックに対処し、補正制御を実装して待機時間とシステム負荷を減らすことができます。
パフォーマンスに重点を置いてコーディング スキルを構築し、効率的なコーディング パターンを促進する標準に従います。 適切に記述された高パフォーマンスのコードは、問題を減らすことでテストを高速化し、コードの一貫性を維持しながら、やり直しを回避するのに役立ちます。

長期的な改善のための最適化

目標アイコン 定義されたパフォーマンス目標の範囲内でシステム効率を向上させ、ワークロードの価値を高めます。

初期パフォーマンス目標は、既知の制約内で妥当なユーザー エクスペリエンスを提供することを目的とします。 システムが進化するにつれて、 実際の運用データを使用してこれらのターゲットを再評価し 、使用パターン、プラットフォームの変更、潜在的な利益をより深く理解し、最適化作業が適切なタイミングで効果的であることを保証します。 多くの場合、早期の決定を回避するために、このデータが使用可能になるまで、主要な最適化を遅らせるのが最善です。

パフォーマンス チューニングは、監視、最適化、テスト、デプロイの継続的なサイクルです。 効率の向上により、リソースの使用量が削減され、オーバープロビジョニングにつながる場合があります。 この追加容量を使用すると、インフラストラクチャを追加することなく、信頼性の向上、コストの削減、新機能のサポートを行うことができます。

方法 メリット
開発ライフサイクル全体を通して定期的なプラクティスとして、パフォーマンス最適化のための専用の時間を確保します。 パフォーマンス主導のカルチャでは、このアプローチは、チームが積極的に監視し、システムパフォーマンスを継続的に向上させるアカウンタビリティを強化します。
設計パターンとコンポーネントを改善してアーキテクチャを強化するために、運用環境の過去の傾向を分析して、非機能要件を再検討し、新しい目標を確立します。 キャッシュや CDN などの新しい設計とコンポーネントにより、システムが最適化され、ユーザー エクスペリエンスが向上します。
最新の状態を取得し、パフォーマンスを向上させるテクノロジのイノベーションを常に最新の状態に保つ。

依存するフレームワークとライブラリ用にリリースされた新しいバージョンを利用します。

同様に、プラットフォーム リソースの更新と修正プログラムの適用時に、プラットフォーム リソースの新機能を使用します。		 パフォーマンス目標は、新しいテクノロジを採用するための正当な理由を提供します。

これらの更新プログラムでは、過去に低速だった可能性のあるコードが高速になる可能性があります。 また、特定の更新プログラムがパフォーマンスに与える悪影響を認識する必要もあります。

次のステップ

パフォーマンス効率チェックリスト