ライブ パフォーマンスの問題に対応するための推奨事項
この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。
| PE:11 | ライブ パフォーマンスの問題に対応します。 明確なコミュニケーションと責任を組み込むことで、パフォーマンスの問題に対処する方法を計画します。 問題のある状況が発生した場合は、学習した内容を使用して予防措置を特定し、ワークロードに組み込みます。 同様の状況が発生した場合に通常の操作にすばやく戻るメソッドを実装します。 |
|---|
このガイドでは、ライブ パフォーマンスの問題に対応するためのベスト プラクティスについて説明します。 ライブ パフォーマンスの問題は、ワークロードの最適な機能を妨げる可能性があるリアルタイムの課題とボトルネックを指します。 これらの問題に迅速に対処すると、パフォーマンスの問題の即時検出と修正が容易になるだけでなく、ワークロードがパフォーマンス ベンチマークを一貫して満たされるようになります。 対処に失敗すると、速度低下、クラッシュ、システムの応答不能など、複雑になり、ユーザー エクスペリエンスが低下する可能性があります。 また、ユーザーがタスクを効率的に完了するのを防ぎ、organizationの評判を損なうこともできます。
定義
| 期間 | 定義 |
|---|---|
| データの関連付け | ワークロードのさまざまな部分からのログ、メトリック、およびイベントを調整して、基になる原因を特定します。 |
| 根本原因分析 | 問題の原因となる基になる要因を特定するためのプロセス。 |
| 自己復旧 | 人間の介入なしに問題を自動的に修復する機能。 |
| 自己防止 | 潜在的な問題や障害を防ぐためのワークロード内の実装。 |
主要な設計戦略
ライブ パフォーマンスの問題が発生した場合は、適切なデータと問題に対応するための計画を用意する必要があります。 この計画には、明確なコミュニケーションと責任を含める必要があります。 主な目的は、通常の運用への迅速な復帰を容易にし、インシデントからの分析情報を提供するソリューションを実装することです。 予防措置をワークフローに統合することは、極めて重要な戦略です。 目標は、同じ問題が再び発生しないようにするか、防止できない場合はパフォーマンスへの影響を軽減することです。
問題の準備
ライブ サイトのパフォーマンスの問題に対する理想的な対応は、正確かつ迅速です。 パフォーマンス修復の精度と速度には準備が必要です。 ライブ パフォーマンスの問題に効果的に対応するには、主要なパフォーマンス メトリックを監視し、問題の根本原因を特定し、適切なソリューションまたは最適化を実装することが重要です。 これらの手順を実行するには、ワークロード ログの分析、パフォーマンス テストの実施、コードまたは構成の最適化、リソースのスケーリングが必要になる場合があります。 次の例では、いくつかの重要な準備領域の概要を示します。
正確なアーキテクチャ図を作成します。 アーキテクチャ図には、すべてのコンポーネントを含め、それらがどのように相互作用するかを示す必要があります。 ビジュアル表現は、パフォーマンスの低下や使用不能につながるボトルネックや単一障害点を特定するのに役立ちます。 問題が発生する前にこれらの問題をキャッチして削除するのが理想的ですが、最新の図を使用すると、ストレスの高い状況で問題を特定するのに役立ちます。
データ アクセスを確認します。 監視プロセスからのデータとログは、パフォーマンスの問題にリアルタイムで対応し、根本原因分析を行うために重要です。 ただし、データの整合性と機密性を維持することが重要です。 多くの場合、ライブ サイトのパフォーマンスの問題に対応するには、通常はアクセスできない可能性がある基になるデータにアクセスする必要があります。 問題が発生したときに必要なデータに担当者がアクセスできるようにする必要があります。 ただし、時間制限付きの最小特権アクセスのみを許可し、そのアクセスを承認された担当者に制限する必要があります。
自動アラートを設定します。 アラートは、問題が発生するとすぐに特定して対処するのに役立ちます。 ワークロードのパフォーマンスがパフォーマンス ベースラインから逸脱すると、アラートによって通知が生成されます。 時間の経過と同時に、通知の生成が多すぎたり少なすぎたりしないように、アラートの構成を調整する必要があります。 使用する監視ソリューションでは、アラートを生成するのに十分なデータを収集する必要があります。 これらのアラートは、パフォーマンス目標と確立されたベースラインと一致している必要があります。 目標に関連する問題に関するアラートが生成されないようにする必要があります。 アラートの例としては、CPU 使用率、メモリ、応答時間、データベース パフォーマンスの低下などがあります。
トリアージ プランを作成する
トリアージ 計画を作成するには、ライブ サイトのパフォーマンスの問題を特定、エスカレート、分析、優先順位付け、伝達するための構造化されたアプローチを考案する必要があります。 トリアージ 計画は、ライブ パフォーマンスの問題に対応するための戦略です。 これにより、明確な役割と手順を使用して、パフォーマンスの中断に迅速かつ効果的に対処できます。 ほとんどのパフォーマンスの問題はディザスター リカバリー プロトコルにはメリットはありませんが、トリアージ計画を必要とするほどワークロードの機能に影響を与える可能性があります。 十分に文書化されたトリアージ計画により、すべてのチーム メンバーが連携し、迅速に行動できるため、ユーザーとワークロードへの影響を最小限に抑えることができます。 トリアージ 計画には、次のコンポーネントが含まれている必要があります。
識別と監視: パフォーマンスの問題をリアルタイムで特定して監視するシステムを実装します。 意思決定を行ったり、問題をより高いレベルにエスカレートしたりできるユーザーの連絡先情報の一覧が必要です。 この計画では、役割と責任も特定する必要があります。 保護された情報にアクセスできるアカウントと期間を文書化する必要があります。
エスカレーション プロセス: 明確なエスカレーション プロセスを定義して、パフォーマンスの問題が適切なチームまたは個人にタイムリーにエスカレートされるようにします。 プロセス定義には、問題をエスカレートするための連絡先情報とガイドラインが含まれている必要があります。
根本原因分析: 各パフォーマンスの問題の根本原因を特定するための根本原因分析を実行するプロセスを開発します。 このプロセスでは、ログとパフォーマンス メトリックを分析し、各問題の原因を特定するための診断テストを実施する必要があります。
優先度設定: パフォーマンスの問題の重大度を判断し、ワークロードとユーザーへの影響に基づいて優先順位を付ける優先順位付けフレームワークを確立します。
コミュニケーション: パフォーマンスの問題の状態と解決の進行状況について関係者に情報を提供するためのコミュニケーション計画を作成します。 定期的な更新、状態レポート、明確な通信チャネルを検討します。
ドキュメント: すべての手順、プロセス、ベスト プラクティスを含むトリアージ計画を文書化します。 このドキュメントは、パフォーマンスの問題への対応に関与しているチーム メンバーが簡単にアクセスできる必要があります。
問題を特定して解決する方法を開発する
ライブ パフォーマンスの問題を解決するには、ライブ ワークロードでパフォーマンスの低下や非効率性を引き起こす可能性のある要因を特定して対処する必要があります。 監視中に収集するデータは、パフォーマンス関連のインシデントを調査して解決するときに非常に重要です。 このデータは、パフォーマンス メトリックの履歴レコードを提供します。 監視データを使用できる場合は、根本原因を分析し、要因を特定できます。 関連するすべての監視データを使用して、各パフォーマンスの問題を理解して修正する必要があります。
根本原因分析を使用する
根本原因分析には仮説検定が必要です。 監視データを確認したら、パフォーマンスの問題の潜在的な原因を一覧表示し、テストする必要があります。 ライブ パフォーマンスの問題に対して根本原因分析を実行するには、次の手順に従います。
情報を収集します。 パフォーマンスの問題に関するできるだけ多くの情報を収集します。 たとえば、エラー メッセージ、ログ、パフォーマンス メトリック、その他の関連データが含まれます。
問題を定義します。 問題がワークロードまたはユーザーに及ぼす症状と影響を特定して、問題を明確に定義します。
考えられる原因を調査します。 パフォーマンスの問題が発生しているワークロードの特定のコンポーネントまたは領域を特定して、分析の範囲を絞り込みます。 収集された情報に基づいて、パフォーマンスの問題の潜在的な原因を特定します。 このプロセスには、コード、構成設定、インフラストラクチャ、または外部依存関係の分析が含まれる場合があります。
データを関連付けます。 収集されたデータについて詳しく調べるには、パフォーマンスの問題に寄与する可能性があるパターン、異常、または相関関係を特定します。 データの相関関係は、パフォーマンスの問題と原因を特定するための重要な要素です。 ログの確認、パフォーマンス メトリックの分析、テストの実施が含まれる場合があります。
仮説をテストします。 特定した潜在的な原因に基づいて仮説を作成します。 仮説を検証または反論するためのテストを実施します。 テスト環境を使用して、エラーをレプリケートできるかどうかを確認する必要があります。
ソリューションを実装する。 根本原因を特定したら、パフォーマンスの問題に対処するためのソリューションを開発して実装します。
監視と検証。 ソリューションを実装したら、ワークロードを継続的に監視して、パフォーマンスの問題が解決されていることを確認します。 パフォーマンス メトリックとユーザー フィードバックを監視して、ソリューションの有効性を検証します。
トレードオフ: 考えられる原因の特定、仮説のテスト、分析の文書化など、根本原因分析の手順には時間がかかる場合があります。 パフォーマンスの問題を関連付けるには、データを収集して格納する必要もあります。 必要な時間とインフラストラクチャにより、運用チームに多大な作業が追加され、ワークロードにコストが増加する可能性があります。
リスク: 適切なセキュリティ ガードレールなしで根本原因分析を実行すると、ログとデータへのアクセスを提供するときに機密情報が公開されるリスクがあります。
ベンダーサポートを利用する
ベンダーサポートは、継続的なパフォーマンスの問題に対処する際に不可欠なステップです。 ベンダーは、製品に関する問題の解決に役立つ専門知識、ツール、リソース、経験を持っています。 サプライヤーとのサポート契約によって、ベンダーが提供するサポートのレベルが決まります。
多くの場合、ベンダーと並行して作業することをお勧めしています。 一部のチーム メンバーがベンダー サポートと共同作業を行い、他のチーム メンバーが引き続きパフォーマンスの問題のトリアージと修正を行う計画を作成する必要があります。 ベンダー サポート チームは、同様のイベントへの応答を防止および自動化する方法について提案することもできます。
担当者が連絡先情報を利用できるようにする必要があります。 ベンダーは、問題解決に効果的に取り組むには、データへのアクセスが必要になる場合もあります。 監視データにアクセスするために、外部アカウントまたはゲスト アカウントを認証および承認するための計画を立てる必要があります。
結果から学習する
ライブ サイトのパフォーマンスの問題を修正したら、何が起こったかを確認する必要があります。 目標は、問題を特定するだけでなく、パフォーマンスの問題から学ぶことです。 学習する最善の方法は、ドキュメントを使用する方法です。 各問題を文書化し、修正方法を説明します。 ベンダーが支援を受けた場合は、ベンダーと協力してドキュメントを強化し、チームをトレーニングし、それに応じてワークロードを変更します。
ドキュメントでは、各問題が再び発生しないようにする方法を示す必要があります。 繰り返し発生する問題を回避する方法の 1 つは、一般的な問題に対応するための自動化を導入することです。 自動化では、ワークロードに自己復旧と自己防止の品質を追加する必要があります。 自動化に加えて、パフォーマンスの問題インジケーターに早期に対応するのに役立つ、洗練されたアラートを作成できます。
Azure ファシリテーション
問題を特定して解決する方法の開発: Azure には、ライブ パフォーマンスの問題に対応するのに役立ついくつかのツールが用意されています。
Azure Monitor は、アプリケーションとインフラストラクチャのパフォーマンスと正常性に関する分析情報を提供する包括的な監視ソリューションです。 監視には、パフォーマンスの問題の監視と診断に役立つメトリック、ログ、アラート、ダッシュボードなどの機能が用意されています。
Application Insights は、開発者と DevOps の専門家がライブ アプリケーションを監視するのに役立つアプリケーション パフォーマンス管理 (APM) サービスです。 パフォーマンスの異常を自動的に検出し、アプリケーション レベルのログとイベントを収集し、問題を診断するための分析ツールを提供します。
Log Analytics は、アプリケーション、仮想マシン、Azure リソースなど、さまざまなソースからログ データを収集して分析するサービスです。 Log Analytics を使用すると、ログ データのクエリと分析を行って、アプリケーションのパフォーマンスと動作に関する分析情報を得ることができます。
関連リンク
パフォーマンス効率のチェックリスト
推奨事項の完全なセットを参照してください。