この Azure Well-Architected Framework のパフォーマンス効率チェックリストの推奨事項に適用されます。
PE:12 | パフォーマンスを継続的に最適化します。 データベースやネットワーク機能など、時間の経過と伴うパフォーマンスの低下を示すコンポーネントに焦点を当てます。 |
---|
このガイドでは、継続的なパフォーマンス最適化に関する推奨事項について説明します。 継続的なパフォーマンスの最適化は、パフォーマンス効率を常に監視、分析、および改善するプロセスです。 パフォーマンス効率は、需要の増加と減少に適応します。 パフォーマンスの最適化は、ワークロードの有効期間を通じて継続的なアクティビティである必要があります。 ワークロードのパフォーマンスは、多くの場合、時間の経過と伴って低下したり過剰になったりします。考慮すべき要因には、使用パターン、需要、機能、技術的負債の変化が含まれます。
定義
任期 | Definition |
---|---|
データの階層化 | アクセス頻度に基づいてデータを分類し、それに応じてストレージ層に格納するストレージ戦略。 |
技術的負債 | コードをより迅速に提供するために、開発プロセス中に意図的に行われた非効率性、最適ではない設計の選択、またはショートカットの蓄積。 |
Time-to-Live | データの有効期限を設定するメカニズム。 |
パフォーマンス効率は、ワークロードの容量が実際の使用状況に合わせて調整される場合です。 オーバーパフォーマンスのワークロードは、パフォーマンスが低いワークロードと同じくらい問題になります。 トレードオフは異なります。 パフォーマンスの超過はコストの最適化に影響します。 パフォーマンスの低下はユーザーに影響します。 パフォーマンス効率の鍵となるのは、時間の経過に伴う監視、調整、テストです。 ワークロードが効率的であることを確認するには、パフォーマンス メトリックを定期的に確認し、必要に応じて調整する必要があります。 パフォーマンス目標を達成するには、実装前と実装後のすべての変更をテストする必要があります。
パフォーマンス カルチャを開発する
パフォーマンス カルチャは、継続的な改善が期待され、チームが運用環境から学習する環境です。 パフォーマンスの最適化には、特殊なスキルが必要です。 ワークロード チームは、需要の増加と減少を満たすためにパフォーマンスを最適化するために適切なスキルと考え方を必要とします。 また、パフォーマンスの問題が発生した場合に必要な監視と修復をサポートするために、時間を割り当てる必要があります。 これらのチームには明確な期待が必要です。 たとえば、パフォーマンス目標、ベースライン、偏差のしきい値 (ベースラインから許容される距離) は、高い表示とソーシャル化が必要です。
トレードオフ: パフォーマンスの継続的な最適化には、パフォーマンスの問題を見つけて修正するための適切なスキルと時間を持つチームが必要です。 パフォーマンスに担当者を専念すると、運用コストが増えます。 人材リソースが限られている場合、パフォーマンスの継続的な最適化は、他の運用タスクから時間がかかる可能性があります。
新しいプラットフォーム機能を評価する
新しいプラットフォーム機能を評価するには、最適化されたストレージ ソリューション、キャッシュ メカニズム、リソース管理ツールなど、パフォーマンス効率を向上させることができるプラットフォームの新しい機能とツールを調べることが含まれます。 新しいプラットフォーム機能は、パフォーマンス効率を向上させる手段を開くことができます。 プラットフォームとツールを最新 up-to維持し、最新のイノベーションとベスト プラクティスを確実に使用できるようにします。 これらの新しい追加からのフィードバックとパフォーマンス メトリックを一貫して監視して、アプローチを調整します。
最適化作業の優先順位付け
パフォーマンスを事前に最適化することは、パフォーマンスの問題が発生する前に、ワークロードのパフォーマンスを向上および強化するための予防的な対策を講じることを意味します。 プロアクティブな対策を使用するには、潜在的なボトルネックの特定、パフォーマンス メトリックの監視、最適化の実装を行い、ワークロードが効率的に動作し、目的のパフォーマンス目標を満たしていることを確認します。 劣化するコンポーネント、重要なフロー、技術的負債の分析に基づいて、各領域に固有のパフォーマンス最適化を実装できます。 改善には、コードの変更、インフラストラクチャの調整、または構成の更新が含まれる場合があります。
劣化するコンポーネントに優先順位を付ける
ワークロードには、多くの場合、データベースやネットワーク コンポーネントなどのコンポーネントがあり、時間の経過と同時にパフォーマンスが低下する傾向があります。 ワークロードが進化し、使用パターンが変わると、多くの場合、これらの変更はワークロード内の個々のコンポーネントのパフォーマンスに影響します。 データベース内のデータが増加すると、クエリの実行時間が長くなり、データの取得が遅くなる可能性があります。 使用パターンを変更すると、クエリの設計が最適でない可能性があります。 かつては効率的だったクエリは、ワークロードの進化に伴って非効率的になる可能性があります。 非効率的なクエリでは、過剰なリソースが消費され、データベースのパフォーマンスが低下する可能性があります。 ワークロードの使用量が増加すると、ネットワーク トラフィックが増加し、輻輳と待機時間の問題が発生する可能性があります。
これらのコンポーネントのパフォーマンスを最適化するために継続的に努力することが重要です。 ワークロードのパフォーマンスの問題を事前に特定して対処します。 既知の劣化しているコンポーネントの優先順位を付けることで、潜在的なパフォーマンスの問題に事前に対処し、ワークロードの円滑な運用を確保できます。 パフォーマンス チューニング手法の実装、リソースの割り当ての最適化、必要に応じてハードウェアまたはソフトウェア コンポーネントのアップグレードが含まれる場合があります。
重要なフローに優先順位を付ける
重要なフローは、ワークロード内で最も重要で優先度の高いプロセスまたはワークフローです。 これらの重要なフローに優先順位を付けることで、ワークロードの最も重要な部分がパフォーマンスのために最適化されていることを確認できます。 どのフローが重要かを把握することは、最適化作業に優先順位を付けるのに役立ちます。 アプリケーションの最も重要な領域のパフォーマンス効率を最適化すると、投資収益率が最も高くなります。 重要なフローと最も人気のあるページを監視する必要があります。 それらをより効率的にする方法を探します。
パフォーマンスの最適化を自動化する
自動化により、反復的で時間のかかる手動プロセスを排除し、効率的に実行できます。 自動化により、人為的エラーの可能性が減り、最適化タスクの実行における一貫性が確保されます。 これらのタスクを自動化することで、ユーザーを解放して、価値を高めるより複雑なアクティビティやアクティビティに集中することもできます。 パフォーマンス テスト、デプロイ、監視など、さまざまなタスクに自動化を適用できます。
自動パフォーマンス テスト: 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 Application Insights などのツールは、パフォーマンスを最適化するための分析情報と推奨事項を提供します。
修復を自動化するには、自動化ツールまたはスクリプトを使用して、アラートがトリガーされたときに修復アクションを自動的に実行します。 Azure Automation、Azure Functions、またはカスタム オートメーション ソリューションを使用できます。
Azure では、パフォーマンス テストを使用して、さまざまなユーザー シナリオとワークロードをシミュレートできます。 自動テストは、パフォーマンスのボトルネックを特定し、それに応じてシステムを最適化するのに役立ちます。 Azure DevOps などのツールでは、パフォーマンス テストを自動化できます。
データベースの最適化: SQL 製品ファミリには、SQL データベースのパフォーマンスを監視および修復できる多くの 組み込み機能 があります。 これらの機能を使用して、データベースのパフォーマンスを維持する必要があります。 Azure SQL Database には、クエリを継続的に監視および改善する 自動チューニング 機能があります。 この機能を使用して、SQL クエリを自動的に改善する必要があります。
Azure Cosmos DB の機能を使用して 、インデックス作成ポリシーをカスタマイズ できます。 ワークロードのパフォーマンス ニーズを満たすようにポリシーをカスタマイズします。
データ効率の最適化: データ階層化を使用すると、アクセス頻度と重要度に基づいて異なる層にデータを格納できます。 ストレージのコストとパフォーマンスを最適化するのに役立ちます。 Azure には、BLOB データ用のホット層、クール層、アーカイブ層など、さまざまなストレージ層が用意されています。 ホット層は頻繁にアクセスされるデータ用に最適化され、クール層はアクセス頻度の低いデータ用であり、アーカイブ層はアクセス頻度の低いデータ用です。 データに最適なストレージ アクセス層を使用することで、効率的なデータストレージと取得を実現できます。
関連リンク
- クエリのパフォーマンスを向上させてリソースの消費を削減するためにインデックスのメンテナンスを最適化する
- Azure Advisor を使用して Azure アプリケーションのパフォーマンスを向上させる
- Azure SQL Database と Azure SQL Managed Instance での自動チューニング
- Azure Cosmos DB のインデックス作成ポリシー
パフォーマンス効率チェックリスト
完全なレコメンデーションのセットを参照してください。