継続的なパフォーマンス最適化に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。

PE:12 パフォーマンスを継続的に最適化します。 データベースやネットワーク機能など、時間の経過と伴うパフォーマンスの低下を示すコンポーネントに焦点を当てます。

このガイドでは、継続的なパフォーマンスの最適化に関する推奨事項について説明します。 継続的なパフォーマンス最適化は、パフォーマンス効率を常に監視、分析、改善するプロセスです。 パフォーマンス効率は、需要の増加と減少に適応します。 パフォーマンスの最適化は、ワークロードの有効期間を通じて継続的なアクティビティである必要があります。 ワークロードのパフォーマンスは、多くの場合、時間の経過と伴って低下したり過剰になったりします。考慮すべき要因には、使用パターン、需要、機能、技術的負債の変更が含まれます。

定義

期間 定義
データの階層化 アクセス頻度に基づいてデータを分類し、それに応じてストレージ層に格納するストレージ戦略。
技術的負債 コードをより迅速に提供するために、開発プロセス中に意図的に取られた、非効率性、最適ではない設計の選択、またはショートカットの蓄積。
Time-To-Live データの有効期限を設定するメカニズム。

主要な設計戦略

パフォーマンス効率は、ワークロードの容量が実際の使用量と一致する場合です。 パフォーマンスが高いワークロードは、パフォーマンスが低いワークロードと同じくらい問題です。 トレードオフは異なります。 パフォーマンスの超過はコストの最適化に影響します。 パフォーマンスが低下すると、ユーザーに影響します。 パフォーマンス効率の鍵となるのは、時間の経過に伴う監視、調整、テストです。 ワークロードが効率的であることを確認するには、パフォーマンス メトリックを定期的に確認し、必要に応じて調整する必要があります。 パフォーマンス目標に到達するには、実装前と実装後のすべての変更をテストする必要があります。

パフォーマンス カルチャを開発する

パフォーマンス カルチャは、継続的な改善が期待され、チームが運用環境から学習する環境です。 パフォーマンスの最適化には、特殊なスキルが必要です。 ワークロード チームは、需要の増加と減少を満たすためにパフォーマンスを最適化するために適切なスキルとマインドセットを必要とします。 また、パフォーマンスの問題が発生した場合に必要な監視と修復をサポートするために、時間を割り当てる必要もあります。 これらのチームには明確な期待が必要です。 たとえば、パフォーマンス目標、ベースライン、偏差しきい値 (ベースラインから許容される距離) は、高い目に見え、ソーシャル化する必要があります。

トレードオフ: 継続的なパフォーマンス最適化には、パフォーマンスの問題を見つけて修正するための適切なスキルと時間を持つチームが必要です。 パフォーマンスに人員を専念すると、運用コストが高くなります。 人事リソースが限られている場合、継続的なパフォーマンスの最適化は、他の運用タスクから時間がかかる可能性があります。

新しいプラットフォーム機能を評価する

新しいプラットフォーム機能の評価には、最適化されたストレージ ソリューション、キャッシュ メカニズム、リソース管理ツールなど、パフォーマンス効率を向上できるプラットフォームの新しい機能とツールを調べることが含まれます。 新しいプラットフォーム機能は、パフォーマンス効率を向上させる手段を開くことができます。 プラットフォームとツールを最新の状態に保ち、最新のイノベーションとベスト プラクティスを確実に使用できるようにします。 これらの新しい追加からのフィードバックとパフォーマンス メトリックを一貫して監視して、アプローチを絞り込みます。

最適化作業に優先順位を付ける

パフォーマンスを事前に最適化することは、パフォーマンスの問題が発生する前に、ワークロードのパフォーマンスを向上および向上させるための予防的な対策を講じることを意味します。 プロアクティブな対策を使用するには、潜在的なボトルネックを特定し、パフォーマンス メトリックを監視し、ワークロードが効率的に動作し、目的のパフォーマンス目標を満たすように最適化を実装する必要があります。 劣化するコンポーネント、重要なフロー、技術的負債の分析に基づいて、各領域に固有のパフォーマンス最適化を実装できます。 改善には、コードの変更、インフラストラクチャの調整、または構成の更新が含まれる場合があります。

劣化するコンポーネントに優先順位を付ける

ワークロードには、多くの場合、データベースやネットワーク コンポーネントなどのコンポーネントがあり、時間の経過と同時にパフォーマンスが低下する傾向があります。 ワークロードが進化し、使用パターンが変化すると、多くの場合、これらの変更はワークロード内の個々のコンポーネントのパフォーマンスに影響します。 データベース内のデータが増加すると、クエリの実行時間が長くなり、データ取得が遅くなる可能性があります。 使用パターンが変更されると、最適ではないクエリ設計が発生する可能性があります。 かつて効率的だったクエリは、ワークロードの進化に伴って非効率的になる可能性があります。 非効率的なクエリでは、過剰なリソースが消費され、データベースのパフォーマンスが低下する可能性があります。 ワークロードの使用量が増加すると、ネットワーク トラフィックが増加し、輻輳と待機時間の問題が発生する可能性があります。

これらのコンポーネントのパフォーマンスを最適化するために継続的に取り組む必要があります。 ワークロードのパフォーマンスの問題を事前に特定して対処します。 既知の悪化しているコンポーネントの優先順位を付けることで、潜在的なパフォーマンスの問題に積極的に対処し、ワークロードの円滑な運用を確保できます。 パフォーマンス チューニング手法の実装、リソース割り当ての最適化、必要に応じてハードウェアまたはソフトウェア コンポーネントのアップグレードが含まれる場合があります。

重要なフローに優先順位を付ける

クリティカル フローは、ワークロード内で最も重要で優先度の高いプロセスまたはワークフローです。 これらの重要なフローに優先順位を付けることで、ワークロードの最も重要な部分がパフォーマンスのために最適化されます。 どのフローが重要かを知ることは、最適化作業の優先順位付けに役立ちます。 アプリケーションの最も重要な領域のパフォーマンス効率を最適化すると、投資収益率が最も高くなります。 重要なフローと最も一般的なページを監視する必要があります。 より効率的にする方法を探します。

パフォーマンスの最適化を自動化する

自動化により、反復的で時間のかかる手動プロセスを排除し、効率的に実行できます。 自動化により、人的エラーの可能性が減り、最適化タスクの実行の一貫性が確保されます。 これらのタスクを自動化することで、ユーザーを解放して、より複雑なアクティビティや、価値を高めるアクティビティに集中することもできます。 パフォーマンス テスト、デプロイ、監視など、さまざまなタスクに自動化を適用できます。

  • 自動パフォーマンス テスト: JMeter、K6、Selenium などの自動パフォーマンス テスト ツールを使用して、さまざまなワークロードとシナリオをシミュレートします。

  • 自動デプロイ: 自動化されたデプロイ プロセスを実装して、一貫性のあるエラーのないデプロイを確保します。 CI/CD ツールを使用してデプロイ プロセスを自動化します。 これらのツールを使用すると、エンドポイントに対してテストしたり、HTTP 状態をチェックしたり、データの品質やバリエーションを検証したりするときに、パフォーマンスのボトルネックを特定するのに役立ちます。

  • 監視とアラート: 自動監視およびアラート システムを設定して、パフォーマンス メトリックを継続的に監視し、逸脱や異常を検出します。 パフォーマンスの問題が検出されると、自動アラートをトリガーして、適切なチームまたは個人に通知できます。

  • インシデント管理: アラートを受信し、チケットを作成し、適切なチームにチケットを割り当てて解決できる自動インシデント管理システムを実装します。 これらの手順は、パフォーマンスの問題に迅速に対処し、適切なリソースに割り当てるのに役立ちます。

  • 自動診断: パフォーマンス データを分析し、パフォーマンスの問題の根本原因を特定できる自動診断ツールまたはスクリプトを開発します。 これらのツールは、パフォーマンスの問題を引き起こしているシステムの特定の領域またはコンポーネントを特定するのに役立ちます。

  • 自動修復アクション: 特定のパフォーマンスの問題が検出されたときにトリガーできる自動修復アクションを定義して実装します。 これらのアクションには、サービスの再起動、リソース割り当ての調整、キャッシュのクリア、その他のパフォーマンス最適化手法の実装が含まれます。

  • 自己復旧システム: 既知のパフォーマンスの問題に対する回復プロセスを自動化することで、システムに自己復旧機能を構築します。 この機能には、システム構成を自動的に修正または調整して、最適なパフォーマンスを復元する必要があります。

技術的負債に対処する

技術的負債とは、パフォーマンスに影響を与える可能性がある開発プロセス中に行われた、累積された非効率性、最適ではない設計の選択、またはショートカットを指します。 技術的負債、不明確なコード、過度に複雑な実装により、パフォーマンス効率の達成が困難になる可能性があります。 技術的負債に対処するには、ワークロードの全体的なパフォーマンスと保守性を向上させるために、これらの問題を特定して解決する必要があります。 この作業には、コードのリファクタリング、データベース クエリの最適化、アーキテクチャ設計の改善、ベスト プラクティスの実装などがあります。 期限を迎えるために技術的負債を導入したかもしれませんが、時間の経過と同時にパフォーマンス効率を最適化するために技術的負債に対処する必要があります。

データベースを最適化する

データベースを継続的に最適化するには、最適化を特定して実装し、データベースが読み込みを処理し、応答時間を短縮し、リソース使用率を最小限に抑える必要があります。 データベースを定期的に最適化することで、アプリケーションのパフォーマンスを向上させ、ダウンタイムを短縮し、全体的なユーザー エクスペリエンスを向上させることができます。

  • データベース クエリを最適化する: SQL ステートメントの記述が不適切な場合、データベースのパフォーマンスが低下する可能性があります。 非効率的な JOIN 条件では、不要なデータ処理が発生する可能性があります。 複雑なサブクエリ、入れ子になったクエリ、および過剰な関数を使用すると、実行速度が低下する可能性があります。 取得するデータが多すぎるクエリは書き換える必要があります。 最も一般的または重要なデータベース クエリを特定し、最適化する必要があります。 この最適化は、クエリの高速化に役立ちます。

  • インデックスを維持する: インデックス作成戦略を評価して、インデックスが適切に設計および保守されていることを確認します。 インデックスのメンテナンスには、未使用または冗長なインデックスの識別と、クエリ パターンに合ったインデックスの作成が含まれます。 データベース インデックスは、データ取得操作を高速化するのに役立ちます。 リレーショナル データベースの場合は、インデックスの断片化を監視する必要があります。 インデックスは定期的に再構築または再構成する必要があります。 非リレーショナル データベースの場合は、ワークロードに適したインデックス作成ポリシーを選択する必要があります。 使用可能な場合は、データベースで自動チューニングを使用します。 これらの機能には、不足しているインデックスの自動作成、未使用のインデックスの削除、プラン修正が含まれます。 詳細については、「 パフォーマンスを向上させるためのインデックスの保守」を参照してください。

  • モデルの設計を確認する: データ モデルを確認して、アプリケーションの特定の要件に合わせて最適化することを確認します。 クエリのパフォーマンスとデータ取得の向上には、非正規化、パーティション分割、またはその他の手法が含まれる場合があります。

  • データベース構成の最適化: メモリ割り当て、ディスク I/O、コンカレンシー設定などのデータベース構成設定を最適化して、パフォーマンスとリソースの使用率を最大化します。

データ効率を最適化する

データ効率を最適化することは、データが可能な限り最も効率的な方法で格納、処理、およびアクセスされるようにするプロセスです。 データの階層化と TIME-to-Live (TTL) の使用は、データ効率を最適化するために使用できる手法です。 これらの手法は、データベース、ファイル システム、オブジェクト ストレージなど、さまざまなデータ ストレージ シナリオに適用できます。

  • データ階層化の使用: データ階層化では、アクセスの重要性または頻度に基づいてデータを分類し、それに応じて異なる層にデータを格納します。 データ階層化を設定すると、ストレージ リソースをより効率的に使用でき、パフォーマンスが向上します。 頻繁にアクセスされるデータや重要なデータは高パフォーマンスレベルに格納できますが、アクセス頻度が低いデータや重要度の低いデータは低コストのレベルに格納できます。 目標は、時間の経過と同時にデータの使用状況を確認して、データが正しい層にあることを確認することです。 データの優先順位が変わると、データは 1 つの層から別の層に移動する必要があります。

  • Time-to-Live を実装する: Time-to-Live は、データの有効期限を設定するメカニズムです。 Time-to-Live を使用すると、データを一定期間後に自動的に削除またはアーカイブできるため、ストレージ要件が減り、データ管理が向上します。 適切な有効期間を設定することで、不要なデータを削除し、ストレージ領域を解放し、全体的な効率を向上できます。 セッション データ、一時ファイル、キャッシュ データは、有効期間の頻繁なターゲットです。 データベース エントリには、有効期間を設定することもできます。

リスク: 時間が短すぎると、パフォーマンスの問題が発生する可能性があります。

Azure ファシリテーション

パフォーマンスの最適化の自動化: Azure Advisor では、ワークロード テレメトリに基づく自動 パフォーマンスに関する推奨事項 が提供されます。 これらの推奨事項を定期的に確認して対処する必要があります。 Azure Monitor では、システムのパフォーマンスに関するリアルタイムの分析情報が提供され、特定のパフォーマンス メトリックに基づいてアラートを設定できます。 Azure Log Analytics では、収集されたログとメトリックに対する自動診断と分析が提供されます。 Azure アプリケーション Insights などのツールは、パフォーマンスを最適化するための分析情報と推奨事項を提供します。

修復を自動化するには、自動化ツールまたはスクリプトを使用して、アラートがトリガーされたときに修復アクションを自動的に実行します。 Azure Automation、Azure Functions、またはカスタム自動化ソリューションを使用できます。

Azure では、パフォーマンス テストを使用して、さまざまなユーザー シナリオとワークロードをシミュレートできます。 自動テストは、パフォーマンスのボトルネックを特定し、それに応じてシステムを最適化するのに役立ちます。 Azure DevOps などのツールでは、パフォーマンス テストを自動化できます。

データベースの最適化: 製品の SQL ファミリには、SQL データベースのパフォーマンスを監視および修復できる多くの 組み込み機能 があります。 これらの機能を使用して、データベースのパフォーマンスを維持する必要があります。 Azure SQL Database には、クエリを継続的に監視および改善する自動チューニング機能があります。 SQL クエリを自動的に改善するには、この機能を使用する必要があります。

Azure Cosmos DB の機能を使用して 、インデックス作成ポリシーをカスタマイズ できます。 ワークロードのパフォーマンス ニーズを満たすようにポリシーをカスタマイズします。

データ効率の最適化: データ階層化を使用すると、アクセス頻度と重要度に基づいて異なる層にデータを格納できます。 これは、ストレージのコストとパフォーマンスを最適化するのに役立ちます。 Azure には、BLOB データのホット層、クール層、アーカイブ層など、さまざまなストレージ層が用意されています。 ホット層は、頻繁にアクセスされるデータ用に最適化され、クール層はアクセス頻度の低いデータ用であり、アーカイブ層はアクセス頻度の低いデータ用です。 データに最適なストレージ アクセス層を使用することで、効率的なデータストレージと取得を確保できます。

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

推奨事項の完全なセットを参照してください。

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