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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. 日経のリアルタイムデータ基盤  ● 2016年に開発した「Atlas」は分析におけるリアルタイム性とデータの「即時利用」を目指したデータ基盤です。   ● 今日、Atlasはコンテンツとアプリケーションの継続的な改良や、一人一人のお客様に対する理解の深化を支え、よりよいサービスの開発、そしてメールマーケティングをはじめとするコミュニケーションの自動化に活用されています。   5 収集拡張分析施策インタラクションデータ ● レコメンデーション ● マーケティング施策 ● レポート ● 編集業務リアルタイム処理

Slide 6

Slide 6 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. リアルタイムの先を目指したい  ● リアルタイムにデータを集め、処理し、レコメンデーションやマーケティングなどの施策に即時反映することは実現できましたが、より迅速に適したメッセージを誰にでも届けられるようになりたいと考えています。   ● そのためには、過去データを扱うまでのタイムラグ（latency）をゼロに近づけるだけでなく、推定や予測を迅速に行うことでタイムラグをマイナス側に動かそうと考えるようになりました。   6 0秒 1日タイムラグ Data Latency 市販ツールからAtlasへの移行により実績値の処理は日次バッチが 200ミリ秒に精緻な閲読実績（事後処理）お客様像

Slide 7

Slide 7 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. リアルタイムの先を目指したい  ● リアルタイムにデータを集め、処理し、レコメンデーションやマーケティングなどの施策に即時反映することは実現できましたが、より迅速に適したメッセージを誰にでも届けられるようになりたいと考えています。   ● そのためには、過去データを扱うまでのタイムラグ（latency）をゼロに近づけるだけでなく、推定や予測を迅速に行うことでタイムラグをマイナス側に動かそうと考えるようになりました。   7 0秒 1日 - ?時間タイムラグ Data Latency 市販ツールからAtlasへの移行により実績値の処理は日次バッチが 200ミリ秒に推定・予測によってお客様を理解し、利便性や心地よさの個別化を極めたい精緻な閲読実績（事後処理）およその予測値（事前処理）お客様像

Slide 8

Slide 8 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. どんなことを推定・予測したいのか？  ● 2021年9月時点で、月間5,271万ユニークブラウザからのアクセスがあり、その内「日経ID」を持つお客様は89万人でした。多くの「日経IDを持たない」ユーザーに対しても、どんなシーンで日経のサービスをお使いなのか理解できれば、より良い体験を創ることができると考えます。  ● 忙しいときの一瞬の接触なのか、じっくり調べ事をしているのか？次の記事へ進むのか、会員登録して頂けるのか？こういった「次のニーズ」を推定できれば、コンテンツの見せ方やキャンペーンのオファーを最適化できます。   8 ？初めての訪問者についてユーザー像の解像度を上げる読まれ方に応じてコンテンツの見せ方を変えるインタラクションの期待値に基づきUIを調整する

Slide 9

Slide 9 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. 実行環境がありませんでした  ● 2019年頃にはまだ用途に適した実行環境がありませんでした。   ● 当時、予測に基づくマーケティング施策といえば、バッチ処理などで予め計算しておくか、ヒトとカネを投入して予測用APIをホストする必要がありました。  9 予測APIをホスティング DWを用いた事前処理 ● 負荷：数百万人のお客様について、要不要を問わず予め処理しようとするとデータ量が多すぎる。 ● 鮮度：バッチベースでは直近のインタラクションを反映できず、ニュースメディアの特性に適合しない。 ● 運用：速報などの予期しないトラフィックスパイクが発生するがスケーラビリティの確保が難しい。 ● 工数：簡単なAPIが増えるだけでもインフラを維持するための工数は決して小さくなく気軽に増やすことは難しい。

Slide 10

Slide 10 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. クライアントサイドか、サーバーサイドか  ● 一人一人に対して都度予測する場合、計算をクライアントサイドかサーバーサイドの2つでした。   ● クライアントサイドは、環境毎に予測モデルを展開する必要があり工数が嵩み、モデル更新も容易ではありません。   ● サーバーサイドの場合、スパイク耐性や応答速度などビジネス要件とは別の観点で運用工数がかかります。   10 サーバーサイドクライアントサイド JS ● 予測モデルをJavaScriptやSwiftなどクライアント環境毎に作成しWebやアプリに組み込む。 ● 計算負荷はクライアントが担ってくれる。 ● ビジネスロジックがフロントに露出する。 ● モデル更新に際してキャッシュ制御が必要。 ● 予測用APIをホストし引数を渡して結果を得る。 ● ビジネスロジックは秘匿できる。 ● 予測のためだけにインフラの保守業務が発生する。 ● スケーラビリティが重要。 ● サーバーレスだとコールドスタート問題がある。

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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のエッジ上でプログラムを動作させるので、エッジがリクエストに即応することになります。

Slide 13

Slide 13 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. Compute@Edge がAPI構築に向いている点  ● Fastly Compute@Edge を利用すれば、インフラの運用保守にリソースを割かずに、ビジネスロジックなどの秘匿性を保ちながらもクライアントの近くで計算処理が行えます。   ● アプリケーションを更新したい場合も、CLIでの更新やパージ操作など、Fastlyおなじみの操作を踏襲できます。   13 JS サーバーサイドクライアントサイド Compute@Edge ● インフラはFastlyが維持してくれ、トラフィックスパイクを気にする必要が無い。 ● 新バージョンのデプロイやキャッシュパージは慣れ親しんだFastlyのVCL運用とほとんど同じ。

Slide 14

Slide 14 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. エッジサーバー補足：2つのエッジコンピューティング  ● 「エッジコンピューティング」というとIoT領域で、デバイス上での計算処理を指すことがあります。   ● Compute@Edgeの場合、デバイス上での処理ではなく、デバイスに近いFastlyのエッジでの処理を指します。   14 Fastly Compute@Edge デバイスクラウドDBなど IoT機器やニューラルエンジン

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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を利用することを前提に進めました。 ● 機械学習そのものにフォーカスした取り組みではありません。本来は目的に応じたアルゴリズムやライブラリを選択すべきです。

Slide 17

Slide 17 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. モデルを構築し書き出す  ● TensorFlowを用いた学習プロセスは通常と変わりません。   ● 特徴量エンジニアリングで変数を増やすと、C@Eで呼び出すAPIでも同じ前処理が必要になる点は配慮が必要です。   17 モデル構築 JS用に変換 REST API化コンパイル C@Eへデプロイデータ準備、Train/Test分割、学習、評価などを行う。機械学習のモデル構築の一般的な流れと変わらない。最後にモデルを保存する。

Slide 18

Slide 18 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. モデルを構築し書き出す  ● tensorflowとは別にtensorflowjsをインストールします。ここに変換ツールが含まれます。   ● tensorflow_converter コマンドを用いて先ほど保存したモデルをポータブル型に変化します。   18 モデル構築 JS用に変換 REST API化コンパイル C@Eへデプロイ tensorflowjs をインストールし、変換ツールを利用可能にする。 tensorflowjs_converter を用いて書き出したモデルをポータブル形式に変換する。

Slide 19

Slide 19 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. TensorFlow.jsでモデルを読み込む  ● Pythonで学習し、ポータブル型に変換したモデルはファイルまたはhttpから読み込めます。   ● （手元では file:// が動作しなかったのでhttpでアクセスできる場所にモデルファイルを配置しました）   19 モデル構築 JS用に変換 REST API化コンパイル C@Eへデプロイ tf.loadLayersModel() または tf.loadGraphModel() を用いてリモートにあるモデルファイルを読み込む。

Slide 20

Slide 20 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. C@Eで動くREST APIを組み立てる  ● URLをパースし、GETパラメータから予測に用いる変数を取得します。   ● 作成済みモデルを用いて予測を計算し、最後に結果をJSONで返すようにしました。   20 モデル構築 JS用に変換 REST API化コンパイル C@Eへデプロイ URLからパラメータを取得する。予測を実行する。結果を成形してJSON形式で返す。

Slide 21

Slide 21 text

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へのコンパイルができます。

Slide 22

Slide 22 text

Copyright ⓒ 2021 Nikkei Inc. All rights reserved. C@Eへデプロイする  ● 最後に、C@E環境にデプロイします。   ● ビルド〜デプロイが成功すると公開/更新されたサービスのURLが表示されます。   22 モデル構築 JS用に変換 REST API化コンパイル C@Eへデプロイ npm run deploy または fastly compute deploy

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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にも対応していました。

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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の発展・普及に期待！