Amazon Lookout for Metrics

解決する課題

売上、注文数、サインアップ率、アプリのエラー率といったビジネス指標は、突然落ち込んだり跳ね上がったりしたときに早く気づきたいものです。しかし固定しきい値のアラートは、季節変動や曜日変動を考慮できず、誤報や見逃しが起きやすくなります。Amazon Lookout for Metrics は、こうした時系列指標の異常を機械学習で自動的に検知することを狙ったフルマネージドサービスでした。

• 時系列のビジネス指標の異常（急落・急増）を、しきい値を手で決めずに検知する
• 異常が起きたとき、どのディメンション（地域・商品・チャネルなど）が強く寄与したかを示す
• 検知結果を SNS や Lambda に送り、調査や対応の自動化につなげる

機械学習の専門知識なしに時系列の異常検知を組み込める点が中心的な価値でしたが、現在は新規利用ができないため、新規設計では後述の代替サービスを選びます。

主要概念と用語

• ディテクター（Detector）: 異常検知の単位となるリソース。データセットを取り込み、指定した間隔で指標を監視し、異常を検出する
• データセット / メトリクスセット: 検知対象の時系列データの定義。どの列を測定値とし、どの列をディメンションや時刻とするかを指定する
• メジャー（Measure）: 異常を監視したい数値の列（売上、件数、率など）。実際に上下を見る対象
• ディメンション（Dimension）: 指標を切り分けるカテゴリ列（地域、商品カテゴリ、チャネルなど）。異常の寄与分析に使う
• 間隔（Interval / Frequency）: 指標を集計・評価する時間粒度。5分・1時間・1日などの周期で監視する
• バックテスト（Backtest）モード: 過去データに対して検知精度を試す実行方式
• 継続（Continuous）モード: 新しいデータが届くたびに継続的に異常を評価する実行方式
• アラート（Alert）: 異常検出時に SNS や Lambda へ通知を送る設定。重要度（重大度スコア）でフィルタできる
• 重大度スコア（Severity score）: 検出された異常の深刻さを表す指標。アラートのしきい値に使う
• 寄与分析 / 根本原因のヒント: どのディメンション値が異常に強く寄与したかを示す機能

仕様・制限・クォータ

• 入力データは時系列で、時刻・測定値・ディメンションの列を含むテーブル状の構造を取り込む
• データソースとしては Amazon S3、Amazon CloudWatch、Amazon RDS / Aurora、Amazon Redshift、Amazon AppFlow 経由の連携などが利用できた
• 実行方式は、過去データで試すバックテストと、新着データを継続評価する継続モードの二種類
• 検知の評価間隔（5分・1時間・1日など）を指定でき、間隔によって取り込み方法が異なる
• ディテクター数、データセットあたりのメジャー・ディメンション数、アラート数などにアカウント単位のクォータがあった
• 重要: サービス終了に伴い、これらの仕様・上限は新規には適用されない。最新状況は公式の終了告知を参照する

具体的な上限やデータ要件はサービス終了の対象であり、新規設計の根拠には使えません。代替サービス側の制限を確認してください。

内部の仕組み

利用者から見ると、時系列データと監視したいメジャー・ディメンションを指定すると、AWS 側のマネージドなモデルが季節性などを学習し、異常とその寄与を返す仕組みでした。

• データ取り込み: 指定したソース（S3 や RDS など）から、設定した間隔で時系列データを読み込む
• 学習と評価: 指標ごとの正常な変動パターン（トレンドや周期性）を学習し、そこから外れた点を異常として検出する。固定しきい値ではなくデータ駆動で判定する
• 寄与分析: 異常が起きたとき、各ディメンション値の寄与度を推定し、どの切り口が原因に近いかを提示する
• アラート連携: 重大度スコアがしきい値を超えた異常を SNS や Lambda に通知し、後続処理へ渡す

モデルの選定・学習基盤・スケーリングはすべて AWS 側が担う設計でした。

設計パターン / ベストプラクティス

新規には採用できないため、以下は概念理解と移行検討のための整理です。

• 指標とディメンションの設計: 監視したい数値（メジャー）と、原因を切り分ける軸（ディメンション）を分けて設計するという考え方は、代替サービスでも有効
• しきい値ではなく季節性を考慮: 曜日・時間帯・季節の変動を持つ指標は、固定しきい値より統計・機械学習ベースの異常検知が向く
• アラートを疎結合に: 検知結果は SNS や Lambda 経由で後続処理へ渡し、検知と対応を分離する
• 移行先の選定: 用途に応じて、メトリクス監視は CloudWatch の異常検知、ログ・検索基盤は OpenSearch、SQL ベースは Redshift ML、BI 上の異常検知は QuickSight、データ品質は Glue Data Quality を検討する

運用・監視

• 既存利用時、ディテクターの状態やアラートの実行は CloudWatch で監視できた
• API 操作の監査証跡は CloudTrail に記録された
• 検知結果やアラートを EventBridge や Lambda に連携し、運用フローへ組み込む構成が一般的だった
• 重要: サポート終了に伴い、運用中の利用者は代替への移行計画（データソースの再接続、アラート連携の付け替え）が必要になった

コスト

• 課金は主に、取り込んだ**指標の数（メトリクス単位）**に応じた従量制を中心とする構成だった
• ディテクターを稼働させている間や、データ取り込み・評価の量に応じて費用が発生した
• 重要: 新規契約はできないため、これから費用が発生することはない。移行先サービスの料金体系で見積もる

具体的な単価はサービス終了の対象であり、新規見積もりには使いません。代替サービスの料金ページで確認してください。

セキュリティ

• アクセス制御は IAM で行い、データソース（S3 バケットや RDS など）への最小権限のみを付与する設計だった
• 保存データはソース側の暗号化（KMS 管理鍵を含む）、転送は TLS で保護された
• 監視対象の指標に売上や顧客行動など機微な情報が含まれる場合、入力データの取り扱いとアクセス範囲を限定する必要があった
• 移行時は、新しいデータソース接続に対しても同様に最小権限と暗号化を適用する

関連サービス・比較

時系列メトリクスの異常検知は、現行では Amazon CloudWatch の異常検知（Anomaly Detection）が代表的な代替です。位置づけを比較します。

ハンズオン / CLI例

新規には利用できないため、以下は概念理解のための参考です。継続モードのディテクターを起動する旧 API 形を示します。

# 参考（サービス終了済み・新規利用不可）: ディテクターを起動して継続的な異常検知を開始する旧コマンド形
aws lookoutmetrics activate-anomaly-detector \
  --anomaly-detector-arn arn:aws:lookoutmetrics:ap-northeast-1:123456789012:AnomalyDetector:my-detector

# 現行の代替例: CloudWatch メトリクスに対する異常検知バンドを作成する
aws cloudwatch put-anomaly-detector \
  --namespace "AWS/ApplicationELB" \
  --metric-name "RequestCount" \
  --stat "Sum"