ライブ パフォーマンスの問題に対応するためのアーキテクチャ戦略

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

このガイドでは、ライブ パフォーマンスの問題に対応するためのベスト プラクティスについて説明します。 ライブ パフォーマンスの問題は、ワークロードの最適な機能を妨げる可能性があるリアルタイムの課題とボトルネックを指します。 これらの問題に迅速に対処すると、パフォーマンスの問題の即時検出と修正が容易になるだけでなく、ワークロードがそのパフォーマンス ベンチマークを一貫して満たすことが保証されます。 それらに対処しないと、速度低下、クラッシュ、システムの応答不能など、複雑になり、ユーザー エクスペリエンスが低下する可能性があります。 また、ユーザーが効率的にタスクを完了するのを防ぎ、組織の評判を損なうこともできます。

定義

ライブ パフォーマンスの問題が発生した場合は、適切なデータと問題に対応するための計画を準備する必要があります。 この計画には、明確なコミュニケーションと責任が含まれている必要があります。 主な目的は、通常の運用に迅速に戻り、インシデントからの分析情報を提供するソリューションを実装することです。 予防策をワークフローに統合することは、極めて重要な戦略です。 目標は、同じ問題が再び発生しないようにするか、防止できない場合にパフォーマンスへの影響を軽減することです。

問題の準備

ライブ サイトのパフォーマンスの問題に対する理想的な応答は、正確かつ迅速です。 パフォーマンス修復の精度と速度には準備が必要です。 ライブ パフォーマンスの問題に効果的に対応するには、主要なパフォーマンス メトリックを監視し、問題の根本原因を特定し、適切なソリューションまたは最適化を実装することが重要です。 これらの手順を実行するには、ワークロード ログの分析、パフォーマンス テストの実施、コードまたは構成の最適化、リソースのスケーリングが必要になる場合があります。 次の例では、いくつかの重要な準備領域の概要を示します。

• 正確なアーキテクチャ図を作成します。 アーキテクチャダイアグラムには、すべてのコンポーネントを含め、それらがどのように相互作用するかを示す必要があります。 視覚的な表現は、パフォーマンスの低下や使用不能につながる可能性のあるボトルネックや単一障害点を特定するのに役立ちます。 問題が発生する前にこれらの問題をキャッチして削除することが理想的ですが、up-to-date ダイアグラムを使用すると、ストレスの高い瞬間の問題を特定するのに役立ちます。

• データ アクセスを確認します。 監視プロセスからのデータとログは、パフォーマンスの問題にリアルタイムで対応し、根本原因分析を行うために重要です。 ただし、データの整合性と機密性を維持することが重要です。 多くの場合、ライブ サイトのパフォーマンスの問題に対応するには、通常アクセスできない可能性がある基になるデータへのアクセスが必要です。 問題が発生したときに必要なデータに担当者がアクセスできるようにする必要があります。 ただし、時間制限付きの最小特権アクセスのみを付与し、そのアクセスを承認された担当者に制限する必要があります。

• 自動アラートを設定します。 アラートは、問題が発生するとすぐに特定して対処するのに役立ちます。 ワークロードのパフォーマンスがパフォーマンス ベースラインから逸脱すると、アラートによって通知が生成されます。 時間の経過と同時に、通知の生成が多すぎたり少なすぎたりしないように、アラートの構成を調整する必要があります。 使用する監視ソリューションでは、アラートを生成するのに十分なデータを収集する必要があります。 これらのアラートは、パフォーマンス目標と確立されたベースラインと一致している必要があります。 目標に関連する問題に関するアラートが生成されないようにする必要があります。 アラートの例としては、CPU 使用率、メモリ、応答時間、データベース パフォーマンスの低下などがあります。

トリアージ プランを作成する

トリアージ計画を作成するには、ライブ サイトのパフォーマンスの問題を特定、エスカレート、分析、優先順位付け、および通信するための構造化されたアプローチを考案する必要があります。 トリアージ 計画は、ライブ パフォーマンスの問題に対応するための戦略です。 これにより、明確な役割と手順を使用して、パフォーマンスの中断に迅速かつ効果的に対処できます。 ほとんどのパフォーマンスの問題はディザスター リカバリー プロトコルにはメリットはありませんが、トリアージ計画を必要とするのに十分なワークロード機能に影響を与える可能性があります。 適切に文書化されたトリアージ計画により、すべてのチーム メンバーが確実に調整され、迅速に行動できるため、ユーザーとワークロードへの影響を最小限に抑えることができます。 トリアージ 計画には、次のコンポーネントを含める必要があります。

• 識別と監視: パフォーマンスの問題をリアルタイムで識別して監視するシステムを実装します。 決定を下したり、問題をより高いレベルにエスカレートしたりできるユーザーの連絡先情報の一覧が必要です。 この計画では、役割と責任も特定する必要があります。 保護された情報にアクセスできるアカウントと期間を文書化する必要があります。

• エスカレーション プロセス: 明確なエスカレーション プロセスを定義して、パフォーマンスの問題が適切なチームまたは個人にタイムリーにエスカレートされるようにします。 プロセス定義には、問題をエスカレートするための連絡先情報とガイドラインが含まれている必要があります。

• 根本原因分析: 根本原因分析を実行して、各パフォーマンスの問題の根本的な原因を特定するプロセスを開発します。 このプロセスには、ログとパフォーマンス メトリックの分析と、各問題の原因を特定するための診断テストの実施が含まれている必要があります。

• 優先順位付け: パフォーマンスの問題の重大度を決定し、ワークロードとユーザーへの影響に基づいて優先順位を付ける優先順位付けフレームワークを確立します。

• コミュニケーション: パフォーマンスの問題の状態とその解決の進行状況について関係者に通知し続けるコミュニケーション計画を作成します。 定期的な更新、状態レポート、明確な通信チャネルを検討します。

• ドキュメント: すべての手順、プロセス、ベスト プラクティスを含むトリアージ計画を文書化します。 このドキュメントは、パフォーマンスの問題への対応に関与するチーム メンバーが簡単にアクセスできる必要があります。

問題を特定して解決する方法を開発する

ライブ パフォーマンスの問題を解決するには、ライブ ワークロードでパフォーマンスの低下や非効率性を引き起こす可能性のある要因を特定して対処する必要があります。 監視中に収集するデータは、パフォーマンス関連のインシデントを調査して解決する際に非常に重要です。 このデータは、パフォーマンス メトリックの履歴レコードを提供します。 監視データを使用できる場合は、根本原因を分析し、要因を特定できます。 各パフォーマンスの問題を理解して修正するには、関連するすべての監視データを使用する必要があります。

根本原因分析を使用する

根本原因分析には仮説検定が必要です。 監視データを確認したら、パフォーマンスの問題の潜在的な原因を一覧表示し、テストする必要があります。 ライブ パフォーマンスの問題に関する根本原因分析を実行するには、次の手順に従います。

1. 情報を収集します。 パフォーマンスの問題に関するできるだけ多くの情報を収集します。 たとえば、エラー メッセージ、ログ、パフォーマンス メトリック、その他の関連データがあります。

2. 問題を定義します。 問題の症状と、問題がワークロードまたはユーザーに及ぼす影響を特定して、問題を明確に定義します。

3. 考えられる原因を調査します。 パフォーマンスの問題が発生しているワークロードの特定のコンポーネントまたは領域を特定して、分析の範囲を絞り込みます。 収集された情報に基づいて、パフォーマンスの問題の潜在的な原因を特定します。 このプロセスには、コード、構成設定、インフラストラクチャ、または外部の依存関係の分析が含まれる場合があります。

4. データを関連付ける。 収集されたデータをさらに詳しく調べて、パフォーマンスの問題に寄与する可能性のあるパターン、異常、または相関関係を特定します。 データの相関関係は、パフォーマンスの問題と原因を特定するための鍵となります。 ログの確認、パフォーマンス メトリックの分析、テストの実施が含まれる場合があります。

5. 仮説をテストします。 特定した潜在的な原因に基づいて仮説を立てる。 仮説を検証または反論するためのテストを実施します。 テスト環境を使用して、エラーをレプリケートできるかどうかを確認する必要があります。

6. ソリューションを実装します。 根本原因を特定したら、パフォーマンスの問題に対処するためのソリューションを開発して実装します。

7. 監視と検証。 ソリューションを実装したら、ワークロードを継続的に監視して、パフォーマンスの問題が解決されていることを確認します。 パフォーマンス メトリックとユーザー フィードバックを監視して、ソリューションの有効性を検証します。

トレードオフ: 考えられる原因の特定、仮説のテスト、分析の文書化など、根本原因分析の手順には時間がかかる場合があります。 パフォーマンスの問題を関連付けるためには、データを収集して格納する必要もあります。 必要な時間とインフラストラクチャにより、運用チームに多大な作業が追加され、ワークロードにコストが発生する可能性があります。

リスク: 適切なセキュリティ ガードレールなしで根本原因分析を実行すると、ログとデータへのアクセスを提供するときに機密情報が公開されるリスクがあります。

ベンダーサポートを利用する

ベンダーサポートは、継続的なパフォーマンスの問題に対処する際に不可欠なステップです。 ベンダーには、製品に関する問題の解決に役立つ専門知識、ツール、リソース、経験があります。 仕入先とのサポート契約によって、ベンダーが提供するサポートのレベルが決まります。

多くの場合、ベンダーと並行して作業することをお勧めしています。 一部のチーム メンバーがベンダー のサポートと共同作業を行い、他のチーム メンバーはパフォーマンスの問題を引き続きトリアージして修正するように計画を作成する必要があります。 ベンダー サポート チームは、同様のイベントへの応答を防止および自動化する方法について提案することもできます。

担当者が連絡先情報を入手できるようにする必要があります。 ベンダーは、問題解決に効果的に取り組むには、データへのアクセスが必要になる場合もあります。 監視データにアクセスするために、外部アカウントまたはゲスト アカウントを認証および承認するためのプランを用意する必要があります。

結果から学ぶ

ライブ サイトのパフォーマンスの問題を修正したら、何が起こったかを確認する必要があります。 目標は、問題を特定するだけでなく、パフォーマンスの問題から学習することです。 学習する最善の方法は、ドキュメントを使用する方法です。 各問題を文書化し、修正方法を説明します。 ベンダーが支援を受けた場合は、ベンダーと協力してドキュメントを強化し、チームをトレーニングし、それに応じてワークロードを変更します。

ドキュメントでは、各問題が再び発生しないようにする方法を示す必要があります。 繰り返し発生する問題を回避する方法の 1 つは、一般的な問題に対応するための自動化を導入することです。 自動化では、ワークロードに自己復旧と自己防止の品質を追加する必要があります。 自動化に加えて、パフォーマンスの問題インジケーターに早期に対応するのに役立つ詳細なアラートを作成できます。

Azure ファシリテーション

問題を特定して解決する方法の開発: Azure には、ライブ パフォーマンスの問題に対応するためのツールがいくつか用意されています。

• Azure Monitor は、アプリケーションとインフラストラクチャのパフォーマンスと正常性に関する分析情報を提供する包括的な監視ソリューションです。 モニターには、パフォーマンスの問題の監視と診断に役立つメトリック、ログ、アラート、ダッシュボードなどの機能が用意されています。

• Application Insights は、開発者と DevOps の専門家がライブ アプリケーションを監視するのに役立つアプリケーション パフォーマンス管理 (APM) サービスです。 パフォーマンスの異常を自動的に検出し、アプリケーション レベルのログとイベントを収集し、問題を診断するための分析ツールを提供します。

• Log Analytics は、アプリケーション、仮想マシン、Azure リソースなど、さまざまなソースからログ データを収集して分析するサービスです。 Log Analytics を使用すると、ログ データのクエリと分析を行って、アプリケーションのパフォーマンスと動作に関する分析情報を得ることができます。

関連リンク

• 自己治癒と自己保存に関する推奨事項

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

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