Taste of Tech Topics

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

AWSでお手軽時系列データの異常検知 ~Lookout for Metricsを試してみた~

はじめに

機械学習アプリケーションエンジニアの@yktmです。
本記事では、2020年12月のAWS re:Inventでアナウンスされ、2021年3月にGAとなった、
Amazon Lookout for Metricsを、実際に利用してみて、使い勝手を確認してみたいと思います。

Amazon Lookout for Metricsの特徴、実際の使い方をお伝えできればと思います。

Amazon Lookout for Metricsとは

概要

Amazon Lookout for Metricsは、機械学習を使った時系列データ分析を、機械学習の知識なしに簡単に始められるサービスです。

例えば、ECサイトトラフィックに発生した異常な外れ値を検知し、アラートを出す、という仕組みを簡単に構築することができます。

特徴

Lookout for Metricsの大きな特徴は、3つあります。

  • 機械学習による分析
  • Lookout for Metricsは機械学習に基づく分析を、機械学習の知識なしに使える点が最大の特徴です。
  • 柔軟なデータ連携
  • 分析対象とするデータは、S3、RDSなどのAWS関連サービスのほかに、
    SalesforceGoogle Analytics、Zendeskなどからシームレスに接続できます。
  • アラートのカスタマイズ性
  • Amazon SNSAWS Lambdaはもちろん、Slack、Datadog、WebHookなどに対しても、
    カスタマイズしたアラートを送信することができます。

    分析としては、複数のパラメーターの関連を見た異常検知や、複数項目を同時に異常検知することも可能な点が嬉しい点です。
    例えば、地域と時間帯から店舗収益の異常を検知したり、アクセス数と収益を同時に異常検知する、といったことができます。

    Amazon Lookout for Metricsを使った分析

    次に、Lookout for Metricsを使い、いかに手軽に分析できるかを見ていきたいと思います。

    検証データセット

    利用するデータセットは、AWS公式Githubで提供されているE-Commerceのサンプルデータを利用していきます。 zipファイルダウンロード・解凍し、backtest/input.csvが利用するファイルです。

    CSVの中身は、プラットフォームと利用国ごとの、閲覧数・収益を1時間おきに記録した履歴データになります。 期間は、2021/01/01から2021/09/30までです。

    カラムは以下の5つとなっています。

    カラム名 説明
    platform 利用デバイスと利用媒体 (pc_web, mobile_web, mobile_appの3パターン)
    marketplace 利用国 (us, uk, de, fr, es, it, jpの7パターン)
    timestamp タイムスタンプ
    views 閲覧数
    revenue 収益

    このデータから、閲覧数と収益の異常を見つけ、どのプラットフォーム・利用国で、何時に異常が発生したかを分析していきたいと思います。

    設定手順

    以下の順に設定していきます。
    1. Detector(分析器)の作成
    2. データセットを作成 / Detectorの有効化
    3. 分析結果の確認
    4. アラート設定

    1. Detector(分析器)を作成

    AWS コンソールで、Amazon Lookout for Metricsを開きます。 Create Detectorを押下し、分析器の作成画面を開きます。

    f:id:yktm31:20210930064417p:plain:w700

    分析器の作成画面では、
    ①分析器の名前
    ②分析のインターバル
    を設定します。

    分析のインターバルとは、分析の細かさを示します。 ここでは、1 hourを指定しています。
    1 dayにすれば1日単位で粗く分析でき、10 minuteにすれば10分単位の細かい分析が可能になります。
    後述しますが、与えられたデータを学習用とテスト用に分けて検証するBacktestモードでは、interval x 285(1dayなら285日分)のデータが必要になる点は注意が必要です。 分析のインターバルによって、利用料金が変動することはありません。(コストについては記事後半で解説しています。)

    f:id:yktm31:20210923172703p:plain:w700

    設定が完了したら、「Create」を押します。

    2. データセットを作成 / Detectorの有効化

    続いて、データセットを作成します。ここで設定するのは、2つの項目です。
    ① 分析対象のデータソース
    ② 分析対象のフィールド

    まず始めに、「Add a dataset」からデータセット作成画面を開きます。

    f:id:yktm31:20210923173346p:plain:w700

    データセット作成画面は、以下のようになっています。

    f:id:yktm31:20211115000438p:plain:w700 f:id:yktm31:20211128111651p:plain:w700 f:id:yktm31:20211115000528p:plain:w700

    設定が必要な項目は、
    ①データセットの名前
    ②分析対象データソースの指定
    ③分析対象データソースのフォーマット設定
    ④認証情報
    です。

    ここでは、Amazon S3上のCSVファイルを分析対象データソースとしています。

    また、分析のモードが2つ選択できます。 モードの違いによる、コストのかかり方に違いはありません。

    モード 説明 用途
    Backtest 指定したデータを学習用と検証用に分割して検証を行う。
    古い70%が学習に利用され、最新の残り30%をバックテストで利用(※interval x 285 のデータが必要になる。)
    検証
    Continuous 新しく取り込まれるデータを利用し、推論精度を向上させていく。 運用

    続いて、分析対象のフィールドを設定します。

    f:id:yktm31:20211114235934p:plain:w700

    「Measure」で指定するのは、異常を検知する対象のフィールドです。 「Demensions」で指定するのは、Measureをどのフィールドでカテゴライズするか、というものです。 例えば、プラットフォーム毎の閲覧数を見たい場合、「Measure」に「views(閲覧数)」を、「Demensions」に「platform(利用デバイス/利用媒体 )」を指定します。

    最後にTimestamp情報がどういった形式で表されているかを指定します。

    「Next」を押すと、設定情報確認画面が出てきます。

    「Save and active」を押すと、データセットが作成され、分析が始まります。

    f:id:yktm31:20210923175757p:plain:w700

    3. 分析結果の確認

    「View annomalies」から異常を確認してみましょう。

    f:id:yktm31:20210923180648p:plain:w700

    発生した異常は、以下のようにリストで表示されます。

    このリストは、どのメトリクスに、何時に異常が発生したかのリストです。 「Severity score」でソートすれば、異常度の大きさで並び替えできます す。「Time detected」でソートすれば、異常が発生した時間でソートできます。

    f:id:yktm31:20211128021445p:plain:w700

    そのうちの一つを開くと、以下のような画面になります。

    f:id:yktm31:20211128015108p:plain:w700

    Anomaly overviewを見ると、2021/09/04 00:00(GMT時間)に発生した異常の詳細であることがわかります。

    続いて、Dimension valuesを確認します。 Dimension valuesは、検知した異常に対し、どのDimensionの影響が大きかを表しています。

    ここでは、以下のような影響度になっています。

    Dimension Dimensionの値 影響度
    Marketplace De(ドイツ) 71%
    Marketplace Uk(イギリス) 28%
    Platform Mobile_web 100%

    ここから、Marketplaceが「De(ドイツ)」Platformが「Mobile_web」のrevenue(収益)に、より大きな異常が出ていることが読み取れます。

    Metric graphsには、それぞれの異常箇所がグラフとして表示されます。
    まず、9/3の21:00 ~ 9/4の1:00の間(赤枠部分)で異常が検知されていることが確認できます。 「De(ドイツ)のMobile_web」と、「Uk(イギリス)のMobile_web」を比較すると、確かに、「De(ドイツ)のMobile_web」の収益が0になっており、異常度が大きいと言えそうです。

    もし、異常と検知された部分が、予想の範囲内である場合、「Is this relevant?」(緑枠部分)でラベル付けしてアルゴリズムにフィードバックすることで、異常検知の精度を向上させることが可能です。

    4. アラート設定

    最後に、アラートを設定しましょう。 設定項目は、
    ①アラート名
    閾値(threshold)
    ③アラートチャンネル
    です。

    f:id:yktm31:20210923181010p:plain:w700

    アラートチャンネルは、Amazon SNSの他に、AWS Lambda、Skack、Webhooksなどが選択できます。

    使用感

    以上で、Lookout for Metricsを使った分析は完了です。使用感として、使いやすい点と注意点をまとめてみます。

    使いやすい点

  • Lookout for Metrics が、複数のアルゴリズムから適切なものを自動で選択してくれる
  • アルゴリズムを意識することなく使えるので、機械学習の知識・経験がない人にとっても使いやすいと思いました。
  • 異常のデータがなくても異常を検出できる
  • 教師なし学習という方法で異常データなしで分析を開始でき、データの準備が楽なところは嬉しいですね。
  • 誤判定を、アルゴリズムに簡単にフィードバックできる
  • 検知した異常を簡単に再ラベリングでき、アルゴリズムを再学習できるところは、運用しながら精度を向上できる、嬉しい部分だと感じました。

    注意が必要な点

  • 全体の傾向が見れない
  • 例えば、過去1ヶ月に起きた異常を、まとめて一つのグラフに表示する、という使い方はできないようです。今回のデータでは、異常発生から遡って約72時間分のデータのみ見ることができました。
  • 複数のMesureの異常を同時に見ることができない
  • 複数の分析軸(=Dimension)から異常を分析できることに対し、複数の分析対象(=Mesure)を同時に比較することはできないようです。
  • 設定の変更が柔軟にできない
  • 分析の時間単位(Interval)や、Measure/Dimensionを後から変更できない点は、注意が必要だと思いました。設定を変更するためには、新たに分析器を1から作成する必要があるため、とにかくランダムにパラメータを変えるという使い方は避けた方がよいと思いました。

    コスト

    ここまで、分析が簡単にできることは分かりましたが、実際使うとなると、利用コストが気になるところかと思います。

    Lookout for Metricsは従量課金制で、メトリクスと呼ばれる単位で課金が発生します。

    メトリクスは、Measureの数 × Demensionsがもつユニークな値の数から算出されます。 例えば、1時間あたりのオンライン注文数、1日あたりのウェブサイト訪問数などが例として挙げられています。

    したがって、ユニークな値を大量に持つ可能性があるフィールドを「Demensions」に設定すると、メトリクスが大きくなり料金が肥大化することに繋がります。 この点は注意が必要です。



    ここで、今回実施した分析を例にコスト試算してみたいと思います。

    まず、「Measure」には、views(閲覧数)とrevenues(収益)を指定したので、Measureの数は2です。

    続いて、「Demensions」には、platform(利用デバイス)とmarketplace(利用国)を指定しました。 それぞれのユニーク値は以下のようになっています。

    カラム名 ユニーク値 カウント
    platform pc_web, mobile_web, mobile_app 3
    marketplace us, uk, de, fr, es, it, jp 7

    上記より、Demensionsには3 x 7 = 21個のユニーク値が存在します。

    つまり、Measureの数 × Demensionsがもつユニークな値の数という式に当てはめると、 2 Measure × 21 Demensions = 42メトリクス となります。

    以下の料金表に基づき、最初の1000メトリクスでは 42 * 0.75USD = 31.5USD(約3500円) が1ヶ月ごとに課金される計算になります。

    f:id:yktm31:20211001072831p:plain:w700
    (出典: 料金 - Amazon Lookout for Metrics | AWS)

    請求ダッシュボードを見ても、計算通りの課金が発生していました。

    メトリクスごとの課金となるため、BacktestモードとContinuousモードでの課金体系に差分はありません。 1ヶ月動かし続けても、1時間だけ動かしても、料金は変わらない点は注意が必要です。
    また、検出された異常の保持、閲覧による課金は発生しません。 他方、Amazon SNS によるカスタムアラートや AWS Lambda を利用したカスタムアクションには別途課金が発生します。

    コスト試算には、AWS公式Githubで提供されているJupyter Notebookを利用できます。

    さいごに

    以上で、Lookout for Metricsを使った分析は完了です。

    時系列データの異常を検知したいけど、難しいことはしたくない、というニーズに応えるサービスだと思いました。 機械学習を利用した時系列分析が、ここまで簡単に利用できるのは、Lookout for Metricsの魅力ですね。

    今回は深く触れませんでしたが、データ連携の容易さやアラートのカスタマイズ性も、実運用するにあたり重要になってくるポイントかと思います。

    Acroquest Technologyでは、キャリア採用を行っています。
    • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
    • Elasticsearch等を使ったデータ収集/分析/可視化
    • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
    • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
      少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com