OPS08-BP04 ワークロードメトリクスのベースラインを設定する
ワークロードメトリクスのベースラインを設定すると、ワークロードの正常性とパフォーマンスの把握につながります。ベースラインを使用すると、パフォーマンスが低下しているか過剰になっているアプリケーションとコンポーネントを特定できます。ワークロードのベースラインを設定することにより、問題がインシデントになる前に軽減できるようになります。ベースラインは、アクティビティのパターンを開発し、メトリクスが期待値から逸脱した場合の異常検出を実装するための基盤となります。
期待される成果:
-
通常の状況におけるワークロードのベースラインレベルのメトリクスが設定されており、
-
ワークロードが正常に機能しているかどうかを判断できます。
一般的なアンチパターン:
-
新しい機能のデプロイ後、リクエストのレイテンシーの急激なドロップが発生しました。処理済みのリクエストと全体的なレイテンシーの複合メトリクスのベースラインは設定されておらず、変更により改善がみられたのか、エラーが発生したのかを判断することができません。
-
ユーザーアクティビティの突然なスパイクが発生しましたが、メトリクスのベースラインは設定されていません。このアクティビティのスパイクは、徐々にアプリケーションでのメモリーリークにつながり、最終的にワークロードがオフラインになってしまいます。
このベストプラクティスを活用するメリット:
-
主要なコンポーネントとアプリケーションのメトリクスを使用して、ワークロードのアクティビティの通常のパターンを把握できます。
-
ワークロード、ワークロードのアプリケーションとコンポーネントが正常に動作しているか、介入が必要かどうかを判断できます。
このベストプラクティスを確立しない場合のリスクレベル: 中
実装のガイダンス
履歴データを使用して、ワークロードのアプリケーションとコンポーネントのワークロードメトリクスのベースラインを設定します。メトリクスのベースラインをメトリクスのレビューミーティングとトラブルシューティングで活用します。ワークロードのパフォーマンスを定期的に確認し、ベースラインをアーキテクチャの進化に合わせて調整します。
お客様事例
AnyCompany Retail では、すべてのコンポーネントとアプリケーションのベースラインが設定されています。AnyCompany Retail は、履歴データを使用して、2 か月のメトリクス期間にわたるワークロードメトリクスのベースラインを作成しました。AnyCompany Retail では、2 か月ごとにベースラインを再評価して、実際のデータに基づいて調整をおこなっています。
実装手順
-
履歴データを使用して、ワークロードのメトリクスからさかのぼって、主要なコンポーネントとアプリケーションのメトリクスのベースラインを設定します。コンポーネントまたはアプリケーションごとのメトリクス数を制限して、モニタリング疲れを回避します。
-
Amazon CloudWatch Metrics Insights を使用して、大規模なメトリクスをクエリして、傾向とパターンを特定します。
-
Amazon CloudWatch 異常検出は、機械学習アルゴリズムを使用して、メトリクスの動作パターンを特定し、ベースラインを決定し、異常を検出します。
-
Amazon DevOps Guru は、機械学習を使用して、ワークロードの運用上の問題を検出する機能を提供します。
-
Enterprise Support を利用している場合は、テクニカルアカウントマネージャーに、Building a Monitoring Strategy Workshop
(モニタリング戦略策定ワークショップ) を申し込むことができます。このワークショップは、ワークロードのオブザーバビリティ戦略策定の支援となります。
-
-
特に重要なビジネスイベントの前に、ワークロードのメトリクスのベースラインを定期的に確認するメカニズムを導入します。少なくとも四半期に 1 回、履歴データを使用してワークロードのメトリクスのベースラインを評価します。メトリクスレビューミーティングでは、このベースラインを使用します。
実装計画に必要な工数レベル: 低。ワークロードのメトリクスが定まったら、ベースラインを設定するうえで、通常の動作パターンを特定するために十分なデータを収集する必要がある場合があります。
リソース
関連するベストプラクティス:
-
OPS08-BP02 ワークロードのメトリクスを定義する - ベースラインを設定する前に、まずワークロードのメトリクスを決定する必要があります。
-
OPS08-BP03 ワークロードメトリクスを収集および分析する - メトリクスのベースラインを設定する前に、ワークロードのメトリクスを収集して分析する必要があります。
-
OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る - このベストプラクティスは、ベースラインを基盤に構築され、使用傾向を明らかにします。
-
OPS08-BP06 ワークロードの結果にリスクがある場合に警告する - しきい値の特定とアラートの作成には、メトリクスのベースラインが必要となります。
-
OPS08-BP07 ワークロードの異常が検出された場合に警告する - 異常検出には、メトリクスのベースラインが設定されている必要があります。
関連するドキュメント:
-
AWS Observability Best Practices - Alarms
(AWS のオブザーバビリティのベストプラクティス - アラーム) -
How to set up CloudWatch Anomaly Detection to set dynamic alarms, automate actions, and drive online sales
(CloudWatch 異常検出をセットアップして、動的アラームを設定し、アクションを自動化し、オンライン販売を促進する方法) -
Operationalizing CloudWatch Anomaly Detection
(CloudWatch 異常検出を運用化する)
関連動画:
-
AWS re:Invent 2020: Monitoring production services at Amazon
(AWS re:Invent 2020: Amazon における本稼働サービスのモニタリング) -
AWS re:Invent 2021- Get insights from operational metrics at scale with CloudWatch Metrics Insights
(AWS re:Invent 2021- CloudWatch Metrics Insights を使用して、大規模に運用メトリクスからインサイトを取得する) -
AWS re:Invent 2022 - Developing an observability strategy (COP302)
(AWS re:Invent 2022 - オブザーバビリティ戦略を策定する (COP302)) -
AWS Summit DC 2022 - Monitoring and observability for modern applications
(AWS Summit DC 2022 - モダンアプリケーションのモニタリングとオブザーバビリティ) -
AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310)
(AWS Summit DC 2022 - AWS を使用したフルスタックオブザーバビリティとアプリケーションモニタリング (COP310))
関連する例:
-
AWS CloudTrail and Amazon CloudWatch Integration Workshop
(AWS CloudTrail と Amazon CloudWatch の統合ワークショップ)
関連サービス: