はじめに
機械学習アプリケーションエンジニアの@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つあります。
SalesforceやGoogle Analytics、Zendeskなどからシームレスに接続できます。
カスタマイズしたアラートを送信することができます。
分析としては、複数のパラメーターの関連を見た異常検知や、複数項目を同時に異常検知することも可能な点が嬉しい点です。
例えば、地域と時間帯から店舗収益の異常を検知したり、アクセス数と収益を同時に異常検知する、といったことができます。
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を押下し、分析器の作成画面を開きます。
分析器の作成画面では、
①分析器の名前
②分析のインターバル
を設定します。
分析のインターバルとは、分析の細かさを示します。
ここでは、1 hourを指定しています。
1 dayにすれば1日単位で粗く分析でき、10 minuteにすれば10分単位の細かい分析が可能になります。
後述しますが、与えられたデータを学習用とテスト用に分けて検証するBacktestモードでは、interval x 285(1dayなら285日分)のデータが必要になる点は注意が必要です。
分析のインターバルによって、利用料金が変動することはありません。(コストについては記事後半で解説しています。)
設定が完了したら、「Create」を押します。
2. データセットを作成 / Detectorの有効化
続いて、データセットを作成します。ここで設定するのは、2つの項目です。
① 分析対象のデータソース
② 分析対象のフィールド
まず始めに、「Add a dataset」からデータセット作成画面を開きます。
データセット作成画面は、以下のようになっています。
設定が必要な項目は、
①データセットの名前
②分析対象データソースの指定
③分析対象データソースのフォーマット設定
④認証情報
です。
ここでは、Amazon S3上のCSVファイルを分析対象データソースとしています。
また、分析のモードが2つ選択できます。 モードの違いによる、コストのかかり方に違いはありません。
| モード | 説明 | 用途 |
|---|---|---|
| Backtest | 指定したデータを学習用と検証用に分割して検証を行う。 古い70％が学習に利用され、最新の残り30％をバックテストで利用（※interval x 285 のデータが必要になる。） |
検証 |
| Continuous | 新しく取り込まれるデータを利用し、推論精度を向上させていく。 | 運用 |
続いて、分析対象のフィールドを設定します。
「Measure」で指定するのは、異常を検知する対象のフィールドです。 「Demensions」で指定するのは、Measureをどのフィールドでカテゴライズするか、というものです。 例えば、プラットフォーム毎の閲覧数を見たい場合、「Measure」に「views(閲覧数)」を、「Demensions」に「platform(利用デバイス/利用媒体 )」を指定します。
最後にTimestamp情報がどういった形式で表されているかを指定します。
「Next」を押すと、設定情報確認画面が出てきます。
「Save and active」を押すと、データセットが作成され、分析が始まります。
3. 分析結果の確認
「View annomalies」から異常を確認してみましょう。
発生した異常は、以下のようにリストで表示されます。
このリストは、どのメトリクスに、何時に異常が発生したかのリストです。 「Severity score」でソートすれば、異常度の大きさで並び替えできます す。「Time detected」でソートすれば、異常が発生した時間でソートできます。
そのうちの一つを開くと、以下のような画面になります。
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)
③アラートチャンネル
です。
アラートチャンネルは、Amazon SNSの他に、AWS Lambda、Skack、Webhooksなどが選択できます。
使用感
以上で、Lookout for Metricsを使った分析は完了です。使用感として、使いやすい点と注意点をまとめてみます。
使いやすい点
注意が必要な点
コスト
ここまで、分析が簡単にできることは分かりましたが、実際使うとなると、利用コストが気になるところかと思います。
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ヶ月ごとに課金される計算になります。
請求ダッシュボードを見ても、計算通りの課金が発生していました。
メトリクスごとの課金となるため、BacktestモードとContinuousモードでの課金体系に差分はありません。
1ヶ月動かし続けても、1時間だけ動かしても、料金は変わらない点は注意が必要です。
また、検出された異常の保持、閲覧による課金は発生しません。
他方、Amazon SNS によるカスタムアラートや AWS Lambda を利用したカスタムアクションには別途課金が発生します。
コスト試算には、AWS公式Githubで提供されているJupyter Notebookを利用できます。
さいごに
以上で、Lookout for Metricsを使った分析は完了です。
時系列データの異常を検知したいけど、難しいことはしたくない、というニーズに応えるサービスだと思いました。 機械学習を利用した時系列分析が、ここまで簡単に利用できるのは、Lookout for Metricsの魅力ですね。
今回は深く触れませんでしたが、データ連携の容易さやアラートのカスタマイズ性も、実運用するにあたり重要になってくるポイントかと思います。
Acroquest Technologyでは、キャリア採用を行っています。少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- Elasticsearch等を使ったデータ収集／分析／可視化
- マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
