ワークロードの信頼性を監視するためのアーキテクチャ戦略

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

信頼性の監視は、回復性と回復性に関して、システムが時間の経過と共にそのビジネス要件をどの程度満たしているかを測定する手法です。 適切に設計された監視システムは、プラットフォーム、インフラストラクチャ、およびワークロードレイヤー全体の可視性を確立することで、システム動作のリアルタイムビューと傾向を提供します。

これらの信号をコンポーネント間および時間の経過と同時に関連付けることで、監視により、インシデントと停止の迅速で確実な分析が可能になります。 分析情報が意味を持ち、アラートが適切なアクションを推進し、学習によってアーキテクチャと運用にフィードバックされるように構造化されたアプローチを作成します。

この記事の重要な戦略は、 監視システムを設計するための OE:07 アーキテクチャ戦略で説明されている、可観測性の基本的な運用方法に基づいて構築されています。 監視プラクティスの実装に関するガイダンスについては、 監視設計ガイドを参照してください。 まず、これらのリソースを確認することをお勧めします。

定義

ワークロード機能の監視

システムが実際に提供するものを監視します。 まず、重要なワークフローが正常に完了したかどうかを追跡し、有効な結果を生成します。 システムは正しくない出力や不完全な出力を生成している間でも正常に見えることがあるため、単に実行するだけでは十分ではありません。

たとえば、ワークロードで 6 時間ごとにレポートが生成される場合、監視では、ジョブがスケジュールどおりに実行されていることと、予想されるコンテンツとサイズを含む空でないレポートなど、有効な結果が生成されたことを確認する必要があります。 この種の検証は、システムが実行されるだけでなく、設計された機能を提供するのにも役立ちます。

ユーザー エクスペリエンスの監視

ビジネスとユーザーの観点から信頼性を監視します。 障害モード分析 (FMA) の一環として、主要なユーザー フローが既に特定されている必要があります。 各フローについて、コンポーネントまたは依存関係のエラーがユーザー エクスペリエンスに与える影響と、予想される結果がどのようになるかを追跡します。 たとえば、eコマース のチェックアウト フローでは、サービスの停止や支払いシステムや在庫システムの過負荷によって、顧客が購入を完了できなくなる可能性があります。

信頼性には、サービスの品質も反映されます。 チェックアウト フローでは、ユーザーは中断することなくエンドツーエンドで購入を完了できる必要があります。 p50、p95、p99 などのパーセンタイル ベースの待機時間メトリックを使用して実際のユーザー エクスペリエンスを理解し、パフォーマンスの問題が頻繁に最初に発生する末尾の待機時間に特に注意してください。

可用性ターゲットを追跡する

可用性、スループット、応答時間について、システムが定義されたターゲットをどの程度満たしているかを追跡します。 これらのターゲットは、多くの場合、サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) として形式化され、ユーザーに対して設定した期待を反映します。 それらに対する監視は、信頼性を実際のビジネス成果に合わせて維持します。 詳細については、「 信頼性ターゲット と サービス レベル アグリーメント」を参照してください。

これらのターゲットに貢献する主要なインジケーターに焦点を当て、時間の経過と同時にそれらを追跡します。 ** 特定の異常が発生した場合、関連するコンポーネントやサブシステムを詳細に調査できる必要があります。 冗長性やフェールオーバーによってマスクされた問題を含め、関連するすべてのシグナルをキャプチャして、実際に何が発生したかを理解し、繰り返し発生しないようにすることができます。

リアルタイム認識と履歴コンテキストを組み合わせます。 リアルタイムシグナルは、ターゲットが危険にさらされている場合に迅速に対応するのに役立ちますが、時間の経過に伴う傾向はパターンや繰り返し発生する問題を明らかにします。 ターゲット ミスの原因を分類し、これらのメトリックを集計することは、明確な SLA レポートをサポートし、継続的な改善のガイドにも役立ちます。

サプライヤーとプラットフォーム サービス (Microsoft など) によって提供される主要な SLA を監視します。 次の手順に従います。

• 潜在的な SLA 違反のインジケーターをリアルタイムで追跡する
• 違反が発生した場合に SLA 要求をサポートするために必要な証拠をキャプチャして保持する

回復性ターゲットを追跡する

すべてのテストと実際のインシデントを測定可能なイベントとして扱うことで、回復可能性を追跡します。 監視データを使用して、システムとチームが実際の条件下で定義済みの回復目標を満たすことができることを検証します。

データ損失の露出 (RPO) と共に、検出、応答、回復 (RTO) までの時間などの主要な信号を測定します。 フェールオーバーの準備と容量、フェールオーバーの成功率と実行時間、バックアップと復元の成功、レプリケーションのラグ、必要な手動介入の量などのインジケーターを含めます。

これらのメトリックでは、明確でない手順、決定の遅延、アクセスが困難なドキュメントなど、回復のパフォーマンスに影響を与える可能性がある運用上のギャップも強調表示されます。 これらの分析情報を使用して、システム設計とインシデント対応の両方のプラクティスを強化します。

正常性モデルを使用してアラートをアクション可能にする

アラートを、アクションを取る価値があることを明確に示すよう設計し、正常、機能低下、異常といった単純な状態でシステムを示す健康モデルに基づけます。

個々のコンポーネントからシステム全体まで、正常性モデルを階層的に構成して、問題をソースにすばやくトレースできるようにします。 サービス レベル目標 (SLO) を使用してしきい値を定義し、メトリック、ログ、トレース、合成チェックなどのシグナルを組み合わせて、システムの正常性の信頼性の高い画像を作成します。 これにより、オペレーターは、何が機能し、何が機能せず、生データを掘り下げずにどこで行動すべきかを明確に確認できます。 詳細については、 正常性モデリングに関する設計ガイドを参照してください。

エンド ツー エンドのエクスペリエンスと重要なトランザクションに焦点を当てることで、実際の条件に合わせてアラートを調整し、実際のユーザーへの影響を反映させます。 一時的な変動を計算し、分離されたブリップやスパイクではなく、意味のある正常性状態の変化をトリガーすることで、ノイズを軽減します。 リアルタイムアラートとトレンド分析情報を組み合わせて、即時の問題と段階的な低下の両方をキャッチし、チームが迅速に対応し、集中し続けるのに役立ちます。

リスク: 正常性モデリングでは、システム全体で意味のあるシグナルを収集する必要があります。 CPU やメモリなどの単純なメトリックのみに依存すると、実際に重要なものを見逃す可能性があります。 ユーザー エクスペリエンス データと合成チェックを含め、完全なビューを取得します。 "正常" を定義するとアライメントが必要になり、調整の不十分なしきい値によってノイズが発生し、有効性が低下する可能性があります。

システムのすべてのレイヤーを監視する

システム、アプリケーション、データ/ストレージ、およびネットワークの各層を監視して、信頼性信号の完全なビューを維持します。

アプリケーション層で、ログ、メトリック、正常性プローブを使用して、成功、失敗、待機時間を追跡します。 関連付け ID を使用して、サービス間の要求に従い、トラブルシューティングを容易にします。 要求のパフォーマンスに影響を与えないようにログを非同期で収集し、明確にするために診断ログと監査ログを分離します。 シンセティックトランザクションとエンドポイントプローブを追加して、顧客が実際に何を経験しているのかを確認します。

トレードオフ。 非同期ログと同期ログの選択には、テレメトリのパフォーマンスと信頼性のバランスが必要です。

• 非同期ログはクリティカル パスからログを記録し続け、待機時間を短縮し、システム パフォーマンスを向上させます。 ただし、ログがフラッシュまたは永続化される前にエラーが発生した場合は特に、テレメトリの損失のリスクが発生します。

• 同期ログにより、処理が続行される前にログが確実に書き込まれるため、データの持続性と監査性が向上します。 トレードオフは、待機時間の増加と、アプリケーションのパフォーマンスとログ システムの間の緊密な結合です。

ほとんどのシナリオでは、パフォーマンスへの影響が最小限であるため、非同期ログ記録が推奨されるアプローチです。 ただし、厳しく規制されている環境や監査に依存する環境では、重要なイベントが確実にキャプチャされることを保証するために同期ログ記録が必要になる場合があります。

データ層とストレージ層では、可用性、書き込みの成功率、クエリの待機時間、タイムアウト、ロック、リソース負荷に重点を置きます。 時間の経過に伴う傾向を見て、増加するボトルネックを特定し、有効期間の短い問題と持続的な低下を区別します。

ネットワーク 層で、接続、待機時間、パケット損失、帯域幅、トラフィック パターンを監視します。 フロー ログ、エンドポイント チェック、合成テストを組み合わせて、ルーティングの問題、異常、またはセキュリティ関連の動作を確認します。 これらのシグナルをアプリケーションとプラットフォームのデータに接続して、問題の発生元を把握します。

操作ログは、問題の診断、パフォーマンスの追跡、システム動作の理解に役立ちます。 これらは、ビジネス イベント、監査、または規制レポートの信頼できるソースとして機能するようには設計されていません。通常は、より強力な追跡性が必要です。

各レイヤーについて詳しく監視する内容については、「 監視設計ガイド」を参照してください。

スタンプ容量の定義と監視

各デプロイ ユニットまたはスタンプの明確な容量制限を定義し、それらを注意深く監視します。 すべてのスタンプは、同時ユーザーの最大数、スループット、またはリソース使用率のしきい値に関係なく、有限の上限内で動作します。 そのため、これらの制限を明示的にすると、意思決定のための信頼性の高いベースラインが得られます。

この可視性は、スタンプが信頼性に影響を与える前に、いつ飽和状態に近付いているのか特定するのに役立ちます。 また、新しいスタンプの追加や負荷の再配分など、タイムリーなスケールアウトの決定もサポートし、設計に従ってトラフィックが流れることを確認します。

これらの制限の定義は、必ずしも簡単ではありません。 容量は、特にスケーリング特性が異なる複数の基になるサービスに依存する場合に、測定が困難な場合があります。 Microsoft Azure からのクォータや制限などのプラットフォーム ガイダンスを出発点として使用する必要があります。 実際には、容量は、多くの場合、正確な事前モデリングではなく、ロード テスト、観察、反復チューニングによって決定されます。

冗長インスタンス間の負荷分散を監視する

異なるリージョンまたはゾーンにインスタンスを分散させる場合など、複数の冗長インスタンス間でワークロードを実行する場合は、それらのインスタンス間でトラフィックとリソースの使用量のバランスを維持する必要があります。

ルーティングの問題、構成の問題、または依存関係の制約を頻繁に示す不均衡を見つける必要があります。 また、フェールオーバー ターゲットが必要に応じてトラフィックを吸収するのに十分な容量を確保し、安定状態の操作と障害の両方のシナリオで冗長性メカニズムが期待どおりに動作することを確認します。

障害モードの検出

障害モード分析 (FMA) 演習の一環として、潜在的な障害点を特定する必要があります。

信頼性の監視プラクティスでは、これらの点を継続的に監視します。 まず、一時的な障害などのより単純な信号に焦点を当てます。 再試行の動作と一時的な障害率を監視して、実際の運用条件下での依存関係と基になるサービスの動作を理解します。 これらの信号は、発生しつつある不安定性の早期の見通しを提供します。 これらは、再試行パターンが予想される標準から誤差するタイミングを認識し、システムが負荷の下で正常な状態を維持しているかどうかを把握し、依存関係または外部サービスがユーザー エクスペリエンスに影響を与える前に、いつ低下し始めるかを特定するのに役立ちます。

Azure リージョン全体をオフラインにする地域の障害や、インフラストラクチャの一部に影響を与える可用性ゾーンの障害、サービスの停止などの大きな影響を与える障害も含めてください。 DDoS やその他の悪意のあるアクティビティ、コンポーネントの構成ミス、パフォーマンスの問題などのセキュリティ シナリオも監視します。これは、それぞれのシナリオがソリューションの全体的な信頼性に影響を与える可能性があるためです。

FMA の詳細については、「 障害モード分析のアーキテクチャ戦略」を参照してください。

プラットフォームの信頼性ステータスに関する情報

信頼性を効果的に管理するには、プラットフォームの正常性に関する明確な分析情報が必要です。 この認識は、問題がワークロードまたは基になるクラウド プラットフォームで発生したかどうかを迅速に判断するのに役立ちます。

Azure Service Health は、Azure の状態を可視化します。 プラットフォームの状態が変化したときに通知を受け取るように、Service Health でアラートを構成します。 影響を受けているリソースに関するアクティブな停止、影響を与える可能性のある計画メンテナンスイベント、リージョンまたはサービス固有の低下に関する最新情報を受け取ります。

Azureファシリテーション

• 次のようなクラウド プラットフォームの監視およびアラート サービスを組み込みます。

  • Azure Service Health などのプラットフォーム レベルの正常性。

  • リソース レベルの正常性 (Azure Resource Health など)。

• Azure Monitor は、クラウドとオンプレミスの環境からの監視データを収集し、分析し、それに対応するために使用される包括的な監視ソリューションです。

• Log Analytics は、Azure portal のツールであり、Log Analytics ワークスペース内のデータに対するログ クエリの編集と実行に使用されます。

• Application Insights は、Azure Monitorの拡張機能です。 アプリケーション パフォーマンス監視 (APM) 機能が用意されています。

• Azure Monitor の分析情報は、仮想マシン、アプリケーション サービス、コンテナーなどの Azure サービスの監視に役立つ高度分析ツールです。 分析情報は、Azure Monitor と Log Analytics の上に構築されています。

• Azure Monitor for SAP solutions は、Azure で実行している SAP ランドスケープ向けの Azure ネイティブの監視製品です。

• 接続モニター は、Azure リソース全体のネットワーク接続とパフォーマンスを継続的に追跡するためのツールです。 合成テストを実行し、エラーを早期に検出するためのリアルタイムのアラートと診断を提供します。 カスタム ブックを作成して、接続の正常性と集計されたパフォーマンス メトリックを視覚化できます。

• 仮想ネットワーク フロー ログをワークロード間で有効にして、ネットワーク トラフィックを監視できます。 トラフィック分析を 使用すると、これらのフロー ログを分析して強化し、ブロックされたトラフィック、悪意のあるフロー、インターネットに公開されているアクティブなポートなどの分析情報を表示できます。 ブックを作成すると、チームはライブ トラフィックの動作を監視し、アラートを受け取ることができます。 タイムライン ビューとトポロジの視覚化を使用して、パフォーマンスの低下やセキュリティの脅威を示す可能性のあるトラフィック パターンを簡単に監視できます。

• 複数のワークスペースのベスト プラクティスについては、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。

Example

実際の監視ソリューションの例については、Azure 上の Web アプリケーションの監視と Azure Kubernetes Service クラスターのベースライン アーキテクチャに関する記事を参照してください。

コミュニティ リンク

• Azure Monitor Baseline Alerts (AMBA) は、顧客とパートナーがAzure Monitorの導入を通じて監視エクスペリエンスを向上させるために使用できるアラート定義の中央リポジトリです。

信頼性チェックリスト

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