Compute@Edge で機械学習モデルを動かす

トラフィック変化が激しいウェブサービスでにおいて、機械学習による予測モデルを用いてユーザー体験を改善しようとするとき、どこでプログラムを動かすべきかが課題となる。
ソリューションとしてCompute@Edgeが適していると考え、コンセプトを検証した。

Transcript

1. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   Compute@Edge で機械学習モデルを動かす

   日本経済新聞社

   DX推進室・戦略グループ

   佐野 玄

   1
   

   View Slide

2. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   プロジェクトメンバー

   2
   佐野 玄
   日本経済新聞社 DX推進室・戦略グループ
   Shinyaigeek
   Web Developer
   日本経済新聞社 長期インターン
   （林 仁）
   

   View Slide

3. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   自己紹介

   3
   佐野 玄 （さの はじめ）
   日本経済新聞社 DX推進室・戦略グループ
   ● エンジニア / コンサルタント / ポストセールス と異なる立場から
   「データ」と「マーケティング」の重なる領域を約20年経験。
   ● 2016年〜2019年の在籍時にリアルタイムアナリティクスや
   リアルタイムマーケティングオートメーションの基盤「Atlas」の開発をリード。
   ● 2020年12月に日経に戻り、データ活用によるマーケティングの全社的な進化に取り組んでいる。
   

   View Slide

4. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   マーケティング施策リアルタイム化の先を目指して

   4
   

   View Slide

5. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   日経のリアルタイムデータ基盤

   ● 2016年に開発した「Atlas」は分析におけるリアルタイム性とデータの「即時利用」を目指したデータ基盤です。
   

   ● 今日、Atlasはコンテンツとアプリケーションの継続的な改良や、一人一人のお客様に対する理解の深化を支え、よりよいサービスの
   開発、そしてメールマーケティングをはじめとするコミュニケーションの自動化に活用されています。
   

   5
   収集 拡張
   分析
   施策
   インタラクションデータ
   ● レコメンデーション
   ● マーケティング施策
   ● レポート
   ● 編集業務
   リアルタイム処理
   

   View Slide

6. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   リアルタイムの先を目指したい

   ● リアルタイムにデータを集め、処理し、レコメンデーションやマーケティングなどの施策に即時反映することは実現できましたが、より
   迅速に適したメッセージを誰にでも届けられるようになりたいと考えています。
   

   ● そのためには、過去データを扱うまでのタイムラグ（latency）をゼロに近づけるだけでなく、推定や予測を迅速に行うことでタイムラグ
   をマイナス側に動かそうと考えるようになりました。
   

   6
   0秒
   1日
   タイムラグ
   Data Latency
   市販ツールからAtlasへの移行により
   実績値の処理は日次バッチが 200ミリ秒に
   精緻な閲読実績
   （事後処理）
   お客様像
   

   View Slide

7. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   リアルタイムの先を目指したい

   ● リアルタイムにデータを集め、処理し、レコメンデーションやマーケティングなどの施策に即時反映することは実現できましたが、より
   迅速に適したメッセージを誰にでも届けられるようになりたいと考えています。
   

   ● そのためには、過去データを扱うまでのタイムラグ（latency）をゼロに近づけるだけでなく、推定や予測を迅速に行うことでタイムラグ
   をマイナス側に動かそうと考えるようになりました。
   

   7
   0秒
   1日 - ?時間
   タイムラグ
   Data Latency
   市販ツールからAtlasへの移行により
   実績値の処理は日次バッチが 200ミリ秒に
   推定・予測によってお客様を理解し、
   利便性や心地よさの個別化を極めたい
   精緻な閲読実績
   （事後処理）
   およその予測値（事
   前処理）
   お客様像
   

   View Slide

8. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   どんなことを推定・予測したいのか？

   ● 2021年9月時点で、月間5,271万ユニークブラウザからのアクセスがあり、その内「日経ID」を持つお客様は89万人でした。多くの「日
   経IDを持たない」ユーザーに対しても、どんなシーンで日経のサービスをお使いなのか理解できれば、より良い体験を創ることがで
   きると考えます。

   ● 忙しいときの一瞬の接触なのか、じっくり調べ事をしているのか？ 次の記事へ進むのか、会員登録して頂けるのか？ こういった「次
   のニーズ」を推定できれば、コンテンツの見せ方やキャンペーンのオファーを最適化できます。
   

   8
   ？
   初めての訪問者について
   ユーザー像の解像度を上げる
   読まれ方に応じてコンテンツの
   見せ方を変える
   インタラクションの期待値に基づ
   きUIを調整する
   

   View Slide

9. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
   実行環境がありませんでした

   ● 2019年頃にはまだ用途に適した実行環境がありませんでした。
   

   ● 当時、予測に基づくマーケティング施策といえば、バッチ処理などで予め計算しておくか、ヒトとカネを投入して予測用APIをホストす
   る必要がありました。

   9
   予測APIをホスティング
   DWを用いた事前処理
   ● 負荷：数百万人のお客様について、要不要を問わず予め
   処理しようとするとデータ量が多すぎる。
   ● 鮮度：バッチベースでは直近のインタラクションを反映でき
   ず、ニュースメディアの特性に適合しない。
   ● 運用：速報などの予期しないトラフィックスパイクが発生す
   るがスケーラビリティの確保が難しい。
   ● 工数：簡単なAPIが増えるだけでもインフラを維持するた
   めの工数は決して小さくなく気軽に増やすことは難しい。
   

   View Slide

10. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    クライアントサイドか、サーバーサイドか

    ● 一人一人に対して都度予測する場合、計算をクライアントサイドかサーバーサイドの2つでした。
    

    ● クライアントサイドは、環境毎に予測モデルを展開する必要があり工数が嵩み、モデル更新も容易ではありません。
    

    ● サーバーサイドの場合、スパイク耐性や応答速度などビジネス要件とは別の観点で運用工数がかかります。
    

    10
    サーバーサイド
    クライアントサイド
    JS
    ● 予測モデルをJavaScriptやSwiftなどクライアント環境毎
    に作成しWebやアプリに組み込む。
    ● 計算負荷はクライアントが担ってくれる。
    ● ビジネスロジックがフロントに露出する。
    ● モデル更新に際してキャッシュ制御が必要。
    ● 予測用APIをホストし引数を渡して結果を得る。
    ● ビジネスロジックは秘匿できる。
    ● 予測のためだけにインフラの保守業務が発生する。
    ● スケーラビリティが重要。
    ● サーバーレスだとコールドスタート問題がある。
    

    View Slide

11. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Fastly Compute@Edge がソリューションに

    11
    

    View Slide

12. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Compute@Edgeとは？

    ● Fastlyのエッジコンピューティング環境で、CDNのエッジ上でプログラムを動かすことができます。
    

    ● コードの起動時間が「34.5マイクロ秒」でウォームアップを気にせず常に高速に応答できます。
    

    ● Rustに加えて、JavaScriptでも開発可能になりました。（デプロイ時にWebAssemblyにコンパイルします）
    

    12
    https://www.fastly.com/jp/products/edge-compute/serverless
    従来、APIを公開する場合は自身で環境をホスト（オリジン）し、
    Fastlyを通して高速化を行うことが多いと思います。
    C@Eではオリジン無しで、 Fastlyのエッジ上でプログラムを動作させるの
    で、エッジがリクエストに即応することになります。
    

    View Slide

13. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Compute@Edge がAPI構築に向いている点

    ● Fastly Compute@Edge を利用すれば、インフラの運用保守にリソースを割かずに、ビジネスロジックなどの秘匿性を保ちながらもク
    ライアントの近くで計算処理が行えます。
    

    ● アプリケーションを更新したい場合も、CLIでの更新やパージ操作など、Fastlyおなじみの操作を踏襲できます。
    

    13
    JS
    サーバーサイド
    クライアントサイド Compute@Edge
    ● インフラはFastlyが維持してくれ、
    トラフィックスパイクを気にする必要が無い。
    ● 新バージョンのデプロイやキャッシュパージは
    慣れ親しんだFastlyのVCL運用とほとんど同じ。
    

    View Slide

14. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    エッジサーバー
    補足：2つのエッジコンピューティング

    ● 「エッジコンピューティング」というとIoT領域で、デバイス上での計算処理を指すことがあります。
    

    ● Compute@Edgeの場合、デバイス上での処理ではなく、デバイスに近いFastlyのエッジでの処理を指します。
    

    14
    Fastly
    Compute@Edge
    デバイス クラウドDBなど
    IoT機器 や
    ニューラルエンジン
    

    View Slide

15. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    予測モデルの構築からデプロイまで

    15
    

    View Slide

16. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    全体の流れ

    ● 今回はコンセプト実証として、「GETパラメータで変数を受け取り、予測結果を返す」ことをC@Eで試しました。
    

    ● データセットには「Iris Species 」を用いています。（ユーザーデータではありません）
    

    ● モデル構築はPython版TensorFlowを、API化の時点でJavaScriptのTensorFlow.jsを利用しました。
    

    16
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    ● 今回はコンセプト実証という位置付けで、本番環境への導入はしていません。
    ● ライブラリが整っているTensorFlow.jsを利用することを前提に進めました。
    ● 機械学習そのものにフォーカスした取り組みではありません。
    本来は目的に応じたアルゴリズムやライブラリを選択すべきです。
    

    View Slide

17. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    モデルを構築し書き出す

    ● TensorFlowを用いた学習プロセスは通常と変わりません。
    

    ● 特徴量エンジニアリングで変数を増やすと、C@Eで呼び出すAPIでも同じ前処理が必要になる点は配慮が必要です。
    

    17
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    データ準備、Train/Test分割、学習、評価などを行う。
    機械学習のモデル構築の一般的な流れと変わらない。
    最後にモデルを保存する。
    

    View Slide

18. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    モデルを構築し書き出す

    ● tensorflowとは別にtensorflowjsをインストールします。ここに変換ツールが含まれます。
    

    ● tensorflow_converter コマンドを用いて先ほど保存したモデルをポータブル型に変化します。
    

    18
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    tensorflowjs をインストールし、変換ツールを利用可能にする。
    tensorflowjs_converter を用いて書き出したモデルをポータブル形式に変換する。
    

    View Slide

19. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    TensorFlow.jsでモデルを読み込む

    ● Pythonで学習し、ポータブル型に変換したモデルはファイルまたはhttpから読み込めます。
    

    ● （手元では file:// が動作しなかったのでhttpでアクセスできる場所にモデルファイルを配置しました）
    

    19
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    tf.loadLayersModel() または tf.loadGraphModel() を用いてリモートにあるモデルファイルを読み込む。
    

    View Slide

20. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    C@Eで動くREST APIを組み立てる

    ● URLをパースし、GETパラメータから予測に用いる変数を取得します。
    

    ● 作成済みモデルを用いて予測を計算し、最後に結果をJSONで返すようにしました。
    

    20
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    URLからパラメータを取得する。
    予測を実行する。
    結果を成形してJSON形式で返す。
    

    View Slide

21. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    コンパイルする

    ● FastlyがGitHubで公開しているテンプレートはWebpackでのバンドル化、wasmファイルへのコンパイルなどの操作が一通り定義され
    ており、基本的にそのまま利用できます。
    

    https://github.com/fastly/compute-starter-kit-javascript-default
    

    21
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    prebuildでwebpack、buildでwasmへのコンパイルができます。
    

    View Slide

22. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    C@Eへデプロイする

    ● 最後に、C@E環境にデプロイします。
    

    ● ビルド〜デプロイが成功すると公開/更新されたサービスのURLが表示されます。
    

    22
    モデル構築 JS用に変換 REST API化 コンパイル C@Eへデプロイ
    npm run deploy
    または
    fastly compute deploy
    

    View Slide

23. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    最終的なアウトプット

    ● 当該サービスのURLで花弁と萼の大きさを渡すことで、3種類のアヤメそれぞれに対し可能性を返すことができました。
    

    23
    APIへ渡した変数
    各種類に対する可能性を計算した結果
    

    View Slide

24. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    検証から分かったこと

    24
    

    View Slide

25. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Compute@Edgeの可能性に期待！

    25
    ● 任意の処理をエッジで実行できます。
    ○ VCLでは実現が難しい処理
    ○ （クライアントサイドの）JS等で露出したくないビジネスロジックを含む処理
    ● Fastlyであることの良さがあります。
    ○ サーバーレスでありながらコールドスタート問題がない
    ○ 最寄りのエッジが応答するのでレスポンス速度が速い
    ○ インフラを気にすることなくスケーラビリティの高い実行環境が利用できる
    ○ モデル更新に際してプログラムの更新とキャッシュパージが迅速に行える
    ● 予測モデルの実行に適した「場所」です。
    ○ スケーラビリティ、応答速度、ビジネスロジックの秘匿の点でエッジは最適な選択肢
    ○ （あくまで場所としては優れるものの、JSで動く機械学習ライブラリが少ない点は否めない）
    

    View Slide

26. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    その他所感

    26
    ● ブラウザやNode.jsとは勝手が違う部分も
    ○ JavaScriptではあるが、普段Webエンジニアが触っているものとは異なる点があります。
    ○ リモートファイルを扱う場合、FastlyのBackend登録が必要でした。
    ● プログラムのサイズ、メモリー消費の制限やパフォーマンスへの影響が分からない
    ○ メモリー消費30MBくらいは普通に動いていました。
    ● JavaScriptでの機械学習が厳しい
    ○ これはC@EではなくJavaScriptに関する感想ですが…
    ○ Pythonが使えたら便利かもしれません。
    ● Fastly Fiddle がJavaScriptにも対応
    ○ 最近、Fastly FiddleがC@EのJavaScriptにも対応していました。
    

    View Slide

27. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Key Takeaways

    27
    

    View Slide

28. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Key Takeaways

    28
    1. Fastly Compute@Edge のエッジコンピューティングは、予測
    APIを建てるのに適した場所でした
    2. TensorFlow.js を使うことで、Pythonで学習してJSで予測する、ということが可能です
    3. Fastlyのスケーラビリティやパフォーマンスそのままに、
    JavaScriptが動くC@Eの発展・普及に期待！
    

    View Slide

29. Copyright ⓒ 2021 Nikkei Inc. All rights reserved.
    Thank you!

    29
    

    View Slide