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

パフォーマンス効率は、需要の変化に合わせてワークロードを調整する機能です。 ワークロードは、 ユーザー エクスペリエンスを損なうことなく負荷の増加に対処できる必要があります。 逆に、 負荷が減少した場合、ワークロードはリソースを節約する必要があります。 リソースの可用性 (CPU とメモリ) を示す容量が重要な要因です。

ワークロード設計は、事前にプロビジョニングされた容量に依存するだけではなりません。これにより、一定の制限までのパフォーマンスが保証されます。 この制限を超えると、ワークロードにパフォーマンスの問題が発生したり、障害が発生したりする可能性があります。 負荷がその制限を超えると、リソースは不必要に実行され続け、コストが発生します。

時間の経過と同時にパフォーマンス目標を維持するための包括的な戦略が必要です。 パフォーマンスに関する考慮事項は、運用環境で問題が発生した場合にのみ対処するために、設計プロセスで後から考慮されるべきではありません。 代わりに、 設計の初期段階からパフォーマンスが重要な考慮事項である考え方を採用します。 最初は、特定のパフォーマンス ターゲットなしでシステムを構築します。 しかし、そこから、開発の各段階でパフォーマンスをテストして測定し、進行状況と有効性を確保します。 プロセス全体を通じてこれらのターゲットを継続的に最適化し、運用環境から学んだ教訓を組み込むことで、潜在的な問題を事前に大幅に軽減できます。

これらの設計原則は、予想される使用に関するビジネス要件を十分に満たすためにリソースの 容量を管理するための戦略を構築 するのに役立ちます。 また、オフピーク時の廃棄物を削減します。 戦略を決定したら、 パフォーマンス効率チェックリストを使用して設計を固めます。

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

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

目的のユーザー エクスペリエンスが定義されており、ベンチマークを開発し、事前に確立されたビジネス要件に対してターゲットを測定する戦略があります。

パフォーマンスの観点からは、設計プロセスを開始するために、適切に定義されたパフォーマンス ターゲットを設定するのが理想的です。 これらの目標を設定するには、ビジネス要件と、ワークロードが提供すると予想されるサービスの品質を十分に理解している必要があります。 ビジネス関係者と共同で期待を定義します。 技術的なメトリックだけに焦点を当てるのではなく、キー フローのユーザー エクスペリエンスに許容される影響を判断します。

循環依存関係があります。 定義していないものを測定することはできません。また、測定なしでは定義できません。 そのため、共同契約で 許容されるしきい値の十分な定義を達成するまで、ワークロードのパフォーマンスを測定 することも重要です。

パフォーマンスと信頼性のターゲットには強い相関関係があり、パフォーマンス、可用性、回復性の観点からサービスの品質を判断するのに役立ちます。 明確な定義がなければ、パフォーマンスの測定、アラートの生成、テストは困難です。 時間の経過に伴うテストを通じてターゲットを確立し、実際の数値を特定したら、これらのターゲットに対する継続的なテストのための自動化を実装できます。

マクロ レベルでターゲットを定義する際のベスト プラクティスに従います (おおよその場合でも範囲内であっても)。

アプローチ	メリット
技術的な概念を理解し、使用可能なインフラストラクチャで設計の可能性を調び、具体的な実験の結果を使用して、効果的なネゴシエーションを準備します (可能な場合)。 履歴データを使用して 、使用パターンとボトルネックを可視化します。 市場分析、専門家、業界標準からの入力など、外部要因から分析情報を得ることができます。	実用的な分析情報に基づいて 、情報に基づいた意思決定 を行うことができます。 パフォーマンス目標は、実現可能なもの、業界のベスト プラクティス、および現在の市場動向に基づくユーザー エクスペリエンスに重点を置きます。
必要に 応じて、品質と規制コンプライアンスの観点から、ビジネス所有者と協力してユーザーの約束を理解します。 広い視野を維持 し、この段階で詳細な詳細に飛び込まないようにします。 投資に基づいて、 許容可能なパフォーマンスを表すものについて明示的に指定します。 ビジネス コンテキストと 予想される成長を理解します。	ビジネス目標と一致しない可能性のある 仮定を行 わないようにします。 また、ワークロード チーム内の明確さと動機も促進されます。 機能要件と非機能要件に関するビジネス コンテキストがあると、他の Azure Well-Architected の柱の設計変更が明らかにされ、 情報に基づいたトレードオフを行うのに役立つ場合があります。 早い段階でパラメーターを定義すると、後で潜在的なソリューションの再設計に関連するコストを回避できます。 これにより、 パフォーマンス目標が将来の予測に確実に対応できるため、現在の取り組みを長期的な目標に合わせて調整できます。
ワークロード フローを特定 し、アーキテクチャ図のフローに優先順位を付けます。 各フローのパフォーマンス許容度 を、熱望から許容できないパフォーマンスまでの範囲として定義します。 パスの重要度、使用頻度、アーキテクチャの強度を考慮して、各フローのエントリ ポイントと終了ポイントを評価します。	フローに優先順位を付けることで、ユーザーとビジネスの成果に最も影響を与える 重要な領域にリソースを集中 させることができます。 システムをパーツと依存関係に分割することで、各コンポーネントの機能を理解し、パフォーマンスに影響を与えます。 また、潜在的な問題に気付くこともあります。 これは、パフォーマンス ベースラインを確立し、最適化を推進するのに役立ちます。
パフォーマンス モデルの構築を開始する 使用パターンに季節的なバリエーションと日単位のバリエーションのどちらを示すかを検討します。 ビジネスに対するコスト、運用、重要度を考慮します。 業界標準を使用して、パー センタイルの使用など、メトリックと集計方法を定量化します。 ビジネス上の制約によって課される需要と供給の期待と制限を評価します。 成長の見通しを組み込む。	パフォーマンス モデルは、 リソースの最適な使用に関する分析情報 を提供し、戦略的計画に役立ちます。 業界標準はベンチマークに役立ちます。 将来の校正により、パフォーマンス目標が引き続き関連し、変更に適応できるようになります。

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

予想される需要に対応するのに十分な供給を提供します。

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

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

アプローチ	特長
特定されたフローの弾力性の需要を評価します。 アプリケーションと基になるコンピューティングレイヤーとデータ レイヤーを考慮して、テクノロジ スタック全体に実装できる設計パターンについて説明します。	より多くの容量を必要とする既存のコンポーネントと、負荷を分散するために追加のコンポーネントが必要な領域に スケーラビリティ要件を定義 できます。 待機時間とシステム負荷を減らすキャッシュ機能の追加など、システム内の潜在的なボトルネックと 、補正制御を設計していることを認識しています。
テクノロジ スタック全体で適切なリソースを選択します。これにより、パフォーマンス目標を達成し、システムと統合できます。 スケーラビリティ要件を満たすことができる機能を検討してください。 予期しないサージを効率的に処理するために、リソースの割り当てとシステム要件の適切なバランスを見つけます。	リソースのさまざまな機能を分析することで、各コンポーネントが システムの全体的な機能とパフォーマンスに貢献することを確認できます。 スケーリング操作を自動的にトリガーする 組み込み機能を利用 できます。 リソースのサイズを適切に設定すると、過剰プロビジョニングなしで需要の変化を満たすことができるため、コスト削減につながります。
需要と選択したリソースの機能に基づいて容量計画を行い、パフォーマンス モデルを強化します。 予測モデリング手法を使用して、 予測可能な予期しない変更で発生する可能性がある容量の予想される変化を予測します。 技術的な要件に変換できるパフォーマンス目標を定義します。	過剰プロビジョニングなしで リソースを効率的に使用 し、需要を満たすことができるため、不要なコストを回避できます。 設計の選択がパフォーマンスに与える影響を理解します。
技術的な要件と設計の選択を検証する概念実証を実装します。	概念実証は、システムがパフォーマンス目標を満たすことができるかどうか、およびそれらのターゲットが現実的かどうかを判断するために 設計を検証 する際に重要です。 予想される負荷に基づいて、予想される容量がパフォーマンス目標を満たすことができるかどうかを検証できます。 また、設計の選択によるコストへの影響を確認します。
パフォーマンス テスト戦略を文書化します。 ユース ケース、さまざまな手法、テスト計画の頻度を含めます。 パフォーマンス テスト計画で概説されている操作のプロセスを定義します。 計画のテスト ケースをトリアージして優先順位を付けます。 パフォーマンス 目標に関する貴重な分析情報を提供し、容量計画を調整するケースに焦点を当てます。	システムの適切な 側面がテストされていることを確認します。 リソースを効果的に割り当て、ビジネスの優先順位と要件に合った方法でテストを実施できます。
パフォーマンス監視戦略を文書化します。 特定されたフローごとに異なる抽象化レベルでメトリックを評価します。	開発サイクル全体を通じて、パフォーマンス目標の 達成に向けた進捗状況を追跡 できます。

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

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

開発は 1 回限りの作業ではありません。 これは進行中のプロセスです。 機能の変化に合ったパフォーマンスの変化を期待します。 ユーザー パターンとプロファイルには差異があり、他の Azure Well-Architected の柱の最適化からの変化も含まれます。 変更を行うと、ワークロード リソースが圧迫される可能性があります。

システムを変更から保護 して、パフォーマンス 目標に戻らないようにします。 開発プロセスでテストと監視を統合します。 実稼働時のシステムのパフォーマンスを実際の負荷でテストし、実稼働前の自動テストでその負荷をシミュレートします。 どちらの場合も、検証目的で監視プラクティスを実施する必要があります。

開発ライフサイクル全体を通じて、 さまざまな段階でさまざまな種類のテストを実施します。 初期段階では、概念実証をテストして、パフォーマンスの結果が完全に予期しない結果ではないことを確認します。 開発が進むにつれて 、手動の低労力テストを 実施してベンチマークを確立します。 ビルド ステージで、待機時間、ストレス レベル、負荷容量、およびテスト 計画で定義されているその他の特性を評価する 自動ルーチン パフォーマンス テストの開発を開始します。

監視は、分離された演習ではなく、その作業の不可欠な部分である必要があります。 システムとそのリソースの経時的なパフォーマンスを確認できます。その後、それらを微調整して価値を最大限に高め、パフォーマンス標準を引き続き満たすことができます。

パフォーマンスの目標は、変化に応じて時間の経過と同時に変化する点に注意してください。 テスト済みおよび監視対象のメトリックに基づいてパフォーマンス モデルを更新します。 フローのパフォーマンスに対する増加、減少、または影響がないことを明確に示します。

常に、ビジネス利害関係者との再ネゴシエーションと期待のリセットを行う準備を整える。

アプローチ	特長
Azure Pipelines で定期的なパフォーマンス テストを統合します。 テストを統合できるパイプラインを選択します。 逆に、パイプラインに統合できるテスト ツールを選択します。	自動テストにより、時間を節約し、 回帰や改善点を簡単に検出できる一貫性が提供されます。 これらの成果物を使用すると、時間の経過に伴う逸脱やドリフトを継続的に監視できるため、一貫したパフォーマンスと品質を維持できます。
リリースの昇格と運用環境への最終的なデプロイを承認または拒否できる品質ゲートとして、パフォーマンス テストを正式化します。	これらのチェックポイントを使用すると、次に進む前 に、デプロイの各ステージが必要なパフォーマンス標準を満たしていることを 確認できます。 チェックポイントは、意図しないパフォーマンスの低下を防ぐのに役立ちます。 たとえば、パフォーマンスが予想を大幅に下回っている場合は、改善が行われるまでリリースをブロックできます。
運用環境の実際のトランザクションとパフォーマンス 目標に対する逸脱を監視するための反復可能なプロセスを設定します。 運用環境で代理トランザクションを使用します。 パフォーマンスの低下に関する監視アラートを設定します。	テストでシミュレートできなかった 実際の負荷の下でのシステムの実際のパフォーマンス に関する分析情報が必要です。 その後、潜在的なボトルネック、使用率の低いリソース、その他の懸念事項など、問題と改善の領域を事前に特定できます。
パフォーマンス テストの結果を確認し、データ を細心の注意を払って監視し、パフォーマンス目標を満たすまで最適化します。 これらのレビューから派生したアクションに優先順位を付け、計画的な実行のためにバックログに追加します。	テスト結果に基づいて、 データをキャプチャして比較し 、傾向の分析を開始できます。 最適化作業はデータドリブンです。
パフォーマンスに重点を置くコーディング スキルを構築します。 パフォーマンス駆動型のコーディング パターンを例示するコーディング標準を用意します。	パフォーマンスの問題がないコードでは、 テストをより 重要な問題に集中できるため、テスト サイクルの効率を高めることができます。 コーディング パターンは、手戻りを回避し、コーディング スタイルの一貫性を維持するのに役立ちます。
使用の増加、機能の変化、およびデータの蓄積に伴うパフォーマンスの低下に対処して、パフォーマンスを維持します。 微調整によって短期的なメリットしかない場合は、期待をリセットし、新しいターゲットを確立します。	パフォーマンスの低下が許容できる範囲を超えてユーザー エクスペリエンスに悪影響を与える問題に発展する前に 、パフォーマンスの状態を維持 できます。 ターゲットを変更するとパフォーマンス モデルがリセットされ、既に容量に達しているシステムの最適化に時間を無駄にすることはありません。

最適化による効率の向上

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

初期フェーズで設定されるターゲットは、さまざまな制約を考慮して、妥当なレベルのユーザー エクスペリエンスに基づいています。 エクスペリエンスをさらに向上させるために、ターゲットを再評価して調整する必要があります。 エクスペリエンスをさらに強化するには、システムの使用方法、システムがどのように進化したか、プラットフォームまたはテクノロジが時間の経過とともにどのように変化したかを明確に理解する必要があります。 監視、最適化、テスト、デプロイのサイクルは、継続的なプロセスです。

効率の最適化の取り組みにより、ワークロードはリソースの消費量を減らすことができます。 これにより、ワークロードが予備容量を持つオーバープロビジョニング状態になる可能性があります。 その容量を使用して、システムの信頼性を向上させます。 システムのコストを改善するための容量を排除します。 または、既存のリソースで新しい製品機能をサポートするために容量を再利用します。

システムの効率が向上したら、新しいパフォーマンス目標を設定して維持する機会を得ることができます。

アプローチ	特長
機能領域の非機能要件と最適化に対処するために、パフォーマンス最適化用の専用サイクルを割り当てます。 この最適化のターゲットは、リソース、コード、データ保持、データベース クエリなどです。	パフォーマンス主導の最適化のカルチャを構築できます。 パフォーマンス パターンを事前に監視し、アプリケーションを微調整する責任をチームに保持します。
時間や予算が限られているため、以前は考慮していなかった方法で、パフォーマンスを向上させる新しい設計パターンとコンポーネントを使用してアーキテクチャを強化します。	新しい設計とコンポーネントによってシステムが最適化され、 ユーザー エクスペリエンスが向上します。 たとえば、キャッシュを使用したり、コンテンツ配信ネットワーク コンポーネントを追加したりできます。 また、長期的なコストメリットにつながる可能性もあります。
監視ツールを使用して、過去の傾向を分析 し、パフォーマンスの最適化作業の恩恵を最も受けるフローとコード実装パスを特定します。 この目的のために、アプリケーション パフォーマンス監視 (APM) ツールとプロファイラーをお勧めします。 操作ホット パスと、システム内のその他の潜在的なボトルネックを特定します。	繰り返し発生する問題のある領域を特定すると、チームは 利益が最も高い場所に集中できます。
最新の情報を入手し、パフォーマンスを向上させるテクノロジのイノベーション を常に最新の状態に保ちます。 依存するフレームワークとライブラリ用にリリースされた新しいバージョンを利用します。 同様に、プラットフォーム リソースの更新と修正プログラムの適用時に、プラットフォーム リソースの新機能を使用します。	多くの場合、新しいテクノロジを採用することが 、改善の機会を探す動機となる要因になります。 過去に遅かった可能性のあるコードは、これらの更新によって高速になる可能性があります。 また、特定の更新プログラムがパフォーマンスにどのように悪影響を及ぼすかを認識する必要もあります。

次の手順

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