機械学習でのリアルタイム予測提供におけるレイテンシの最小化

この記事では、機械学習(ML)モデルから予測を提供するための Google Cloud 上の一般的なアーキテクチャと、ML システムの予測提供におけるレイテンシを最小化するための手法について説明します。ML モデルは、デプロイし予測を行う準備を整えて初めて役立ちます。適応型 ML サービス システムを構築するには次のことが必要です。

  • 予測提供をリアルタイムとオフラインのどちらで行う必要があるかどうかを判断する。
  • モデルの予測性能と予測レイテンシとの間でバランスを取る。
  • 読み取りレイテンシが低いルックアップ ストアのモデルに必要とされる入力特徴を管理する。
  • 少なくとも予測の一部をオフラインで事前計算してオンラインで提供できるかどうかを検討する。

この記事では、上記の点について詳しく説明します。ここでは、BigQueryDataflowCloud StorageAI Platform に精通していることを前提としています。

機械学習による予測

機械学習(ML)モデルは、トレーニング、評価、調整を行ってから、予測を提供するように本番環境にデプロイします。ML モデルが予測を提供する方法は 2 種類あります。

  • オフライン予測。予測のリアルタイム提供が必要とされない、大量のデータポイントに対するバッチ スコアリング ジョブで ML モデルが使用される場合です。オフライン予測の推奨では、たとえば商品アイテムに関するお客様の取引履歴情報のみを使用して予測を行うことができ、オンライン情報を必要としません。通常、離脱する可能性が高い(活発ではない)お客様を対象とする維持キャンペーン、プロモーション キャンペーンなどで実施されます。
  • オンライン予測。運用システムやアプリからのオンライン リクエストに基づいて、ML システムを使ってリアルタイムで予測を提供する場合です。オフライン予測とは対照的に、オンライン予測の推奨では、履歴情報だけでなく、アプリケーションを使用しているお客様の現在のコンテキストを必要とします。このコンテキストには、日時、ページビュー、目標到達プロセス、表示されたアイテム、買い物カゴにある商品アイテム、買い物カゴから削除された商品アイテム、使用中のデバイス、デバイスの位置情報などの情報が含まれます。

オフライン(バッチ)予測

オフライン予測では、データポイントを受け取った後にモデルを呼び出すことはありません。代わりに、データレイクまたはデータ ウェアハウス内のデータポイントを収集し、バッチ予測ジョブですべてのデータポイントについての予測を一度に行います。バッチ予測ジョブは、スケジュールされたバッチ抽出、変換、読み込み(ETL)プロセスの一部であり、毎日、毎週、毎月といった周期で実行できます。バッチ予測の一般的なユースケースを次に示します。

  • 需要予測: 在庫と補充の最適化のために、店舗ごとに商品の需要を毎日推測する。
  • セグメントの分析: お客様のセグメント、新興セグメント、セグメント間で移行するお客様を毎月特定する。
  • 感情分析とトピック マイニング: お客様からのフィードバックを分析し、ソーシャル メディアから巷で話題になっているトピックを抽出することにより、商品やサービスに関する全体的な感情を毎週把握する。

図 1 は、オフライン バッチ予測を行うための典型的な Google Cloud アークテクチャの概要を示しています。

Google Cloud でのバッチ予測アーキテクチャ
図 1. Google Cloud でのバッチ予測アーキテクチャ

スコアリング用のデータソースが、エンタープライズ データ ウェアハウスとして BigQuery にあることを前提とします。バッチ予測では次のことを行います。

  1. データを Cloud Storage にエクスポートします。これには bq コマンドライン ツールやDataflow を使用します。後者は、データをバッチ パイプラインで前処理する必要がある場合に適しています。
  2. AI Platform のバッチ予測ジョブを送信します。このジョブは、Cloud Storage のトレーニング済み TensorFlow モデルを使って前処理済みデータのスコアリングを行います(Dataflow パイプライン内で直接モデル予測を行う方法の詳細については、Dataflow パイプラインでの予測のための機械学習モデルの比較をご覧ください)。
  3. バッチ予測ジョブの出力は、Cloud Storage から BigQuery のデータ ウェアハウス、または Cloud SQL などの部門データマート(キャンペーン用、在庫用など)にインポートされます。この出力を利用して、機能に基づくビジネス上の決定を導き出すことが可能です。

オンライン(リアルタイム)予測

オンライン予測では通常、モデルが呼び出し元から単一のデータポイントを受け取り、このデータポイントに対する予測を(ほぼ)リアルタイムで提供することが期待されます。オンライン予測の一般的なユースケースを次に示します。

  • 予測メンテナンス: センサーのリアルタイム データを基に、N 分以内に特定の機械部品に不具合が発生するかを同期的に予測する。
  • リアルタイム ビッダー(RTB): 入札リクエストを受信したときに広告を同期的に推奨し、入札を最適化する。この情報は、リアルタイムで広告参照を返すために使用されます。
  • 予測メンテナンス: 過去 30 分間のセンサーデータの平均値をもとに、N 分以内に特定の機械部品に不具合が発生するかを非同期に予測する。
  • 過去 30 分間のエリア内の平均配達時間、材料、リアルタイムの交通情報に基づいて、食品の配達にかかる時間を非同期的に推測する。

リアルタイム予測をコンシューマ(ユーザー、アプリ、システム、ダッシュボードなど)に配信する方法は複数あります。

  • 同期。予測のリクエストとレスポンス(予測)は、呼び出し元と ML モデルサービスの間で順番に行われます。つまり、呼び出し元は、ML サービスから予測を受信するまで、それ以降のステップの実行を保留にします。
  • 非同期。データをストリーミングするイベントに基づく予測やそれ以降の動作は、予測のリクエストとは無関係にコンシューマに提供されます。次の操作が含まれます。

    • push。モデルは予測を生成し、それらを通知として呼び出し元またはコンシューマに push します。例として、不正取引の可能性があるときに他のシステムにも対応を求める通知を送る、不正検出機能が挙げられます。
    • ポーリング。モデルは予測を生成し、読み取りレイテンシが低いデータベースに格納します。呼び出し元またはコンシューマは、利用可能な予測についてデータベースを定期的にポーリングします。例として、対象を絞ったマーケティングが挙げられます。このユースケースでは、プロモーションのメールと維持を目的としたクーポンのどちらを送信するか決定するために、リアルタイムで予測された活発なお客様の傾向スコアがチェックされます。

図 2 は、オンライン(リアルタイム)予測のための Google Cloud 上のシンプルな同期アーキテクチャを示しています。

Google Cloud 上のシンプルなオンライン予測アーキテクチャ
図 2. Google Cloud 上のシンプルなオンライン予測アーキテクチャ

リアルタイム予測では次のことを行います。

  1. オンライン アプリケーションから ML モデルに HTTP リクエストが送信されます。このモデルはマイクロサービスとしてデプロイされ、予測のために REST API を公開します。AI Platform を使用して、HTTP エンドポイントとしてモデルをデプロイできます。
  2. モデルが予測を生成するとすぐに、呼び出し元アプリケーションはレスポンスを受け取ります。

システムの一部としてアプリのバックエンドにロジックを実装する必要があることがあります。たとえば、アプリ バックエンドでは、ML モデルを呼び出す前に入力データポイントの前処理が必要な場合や、呼び出し元にレスポンスを返す前に出力予測の後処理が必要な場合があります。このタイプのバックエンド処理は ML ゲートウェイです。これは、1 つ以上の ML モデルと前処理ロジック / 後処理ロジックのラッパーとして機能します。

ML ゲートウェイのアーキテクチャでは、App Engine や AI Platform などのマネージド サービスを使用して、自動スケーリングやセキュア エンドポイントを介した負荷分散などの機能を利用します。必要に応じて、Google Kubernetes Engine(GKE)Kubeflow などの他のテクノロジーを使ってさらにカスタマイズできます。

図 3 は、メッセージングとストリーム処理パイプラインを使用して非同期に行われるオンライン予測のための別の一般的なアーキテクチャを示しています。このタイプのアーキテクチャは、予測を行う前にいくつかの特徴を動的に計算する必要がある場合に役立ちます。

メッセージングを使用する Google Cloud 上のオンライン予測アーキテクチャの概要
図 3. メッセージングを使用する Google Cloud 上のオンライン予測アーキテクチャの概要

デプロイされたモデルの REST API を直接呼び出す代わりに、システムのフローは次のようになります。

  1. オンライン アプリケーションが、フルマネージド リアルタイム メッセージング サービスである Pub/Sub にイベントを送信します。イベントはリアルタイムで使用され、Dataflow ストリーム処理パイプラインによって処理されます。
  2. 処理パイプラインが予測のためにモデルを呼び出し、予測を別の Pub/Sub トピックに送信します。
  3. 予測やレコメンデーションなどを格納した Pub/Sub メッセージが、オンライン アプリケーションに返されるか、ダウンストリーム システムによってモニタリングやリアルタイムでの意思決定のために使用されます。

予測の作成と提供

リアルタイムのユースケースでは、予期されるアクションは即座に発生しなければならないため、予測の提供までのレイテンシを最小限に抑えることが重要です。通常、提供のレイテンシは 2 つのレベルで向上できます。

  • モデルのレベル。モデルがデータポイントで呼び出されたときに予測にかかる時間を最小限に抑えます。これには、小規模なモデルの構築、モデルの提供のためのアクセラレータの使用が含まれます。
  • 提供レベル。システムがリクエストを受け取ったときにシステムが予測を行うためにかかる時間を最小限にします。これには、読み取りレイテンシが低いルックアップ データ ストアへの入力特徴の格納、オフライン バッチスコアリング ジョブでの予測の事前計算、予測のキャッシュ保存が含まれます。

予測モデルの読み取りレイテンシを低くするために最適化しても、それだけでは本番環境へのデプロイ時に、サービスの全体的なレイテンシが短縮されない場合があります。予測の提供レベルでは一般的に、その他の課題も発生します。たとえば、バックエンドのデータストアからの入力特徴の取得を迅速化する必要や、モデルが入力特徴として使用するリアルタイム値の計算と管理を行う必要が生じます。さらに、こうした予測を事前計算してオンラインで提供するためにキャッシュに保存する場合は、予測を高速化するためにモデルを最適化しても意味がない場合があります。

以下のセクションでは、こういったアプローチについて詳しく説明します。

提供のためのモデルの最適化

予測モデルの読み取りレイテンシを低くするために最適化するには、次の方法を試してください。

  • 入力特徴数の削減やモデルの簡素化によって、モデルのサイズを縮小する。例としては、ニューラル ネットワーク内の非表示のユニット、ディシジョン ツリーのレベル、ブーストされたツリー内のツリーの数の減少が挙げられます。
  • 提供用のモデルから未使用な部分、冗長な部分、無関係な部分を取り除く。このステップは通常、モデルをトレーニング モードから予測モードに昇格させるときに必要です。

たとえば、ニューラル ネットワーク(NN)の次の特性について検討します。

  • レイヤが多いほど、またレイヤあたりのユニット数が多いほど、モデルはデータ内の複雑な関係を捉えることができるため、予測の有効性が高くなります(過剰適合を慎重に避けることが前提)。ただし、モデルが大きいほど、予測にかかる時間が長くなります。
  • 一方、小規模な NN モデル(レイヤ、ユニット、入力特徴が少ない)を使用すると、予測レイテンシが短縮されます。ただし、このモデルでは、大規模なモデルの予測精度には及ばない可能性があります。

つまり、モデルの予測有効性と予測レイテンシにはトレードオフの関係があります。そのため、ユースケースに応じて、2 つの指標を指定する必要があります。

  1. モデルの最適化の指標。精度、適合率、平均二乗誤差といったモデルの予測有効性が反映されます。この指標の値が大きいほど、モデルは優れています。
  2. モデルの充足指標。予測レイテンシなど、モデルが満たす必要がある運用上の制約が反映されます。レイテンシのしきい値を特定の値(たとえば、200 ミリ秒)に設定した場合、しきい値を満たさないモデルは受け入れられません。充足指標の別の例に、モデルのサイズがあります。これは、モデルを低スペックのハードウェア(モバイル デバイスや組み込みデバイスなど)にデプロイする場合に必要です。

最適化指標と充足指標のしきい値を決定したら、モデルの予測レイテンシのしきい値に達するまで、モデルをより複雑にしてモデルの予測力を向上させることができます。

最適化指標と充足指標のバランスをとることによってモデルを最適化した後、次のアクセラレータをサービス インフラストラクチャで使用して、モデルのレスポンス時間を短縮できます。

  • GPU は並列スループット向けに最適化されています。Compute Engine、GKE、AI Platform など、Compute Engine 全体でいくつかの GPU タイプを使用できます。詳細については、TensorRT 5 と NVIDIA T4 GPU を使用した TensorFlow 推論ワークロードの大規模な実行をご覧ください。
  • Cloud TPU は Google が開発したテクノロジーで、機械学習のワークロードに対して最適化されています。Compute Engine や AI Platform などの Google Cloud プロダクトで使用できるポッドとして提供されています。TPU は通常、大規模なディープ ラーニング モデルがあり、バッチサイズが大きい場合にのみ使用します。

さらに、保存されたモデルをデプロイする前に(未使用の部分を削除するなどして)最適化すると、予測のレイテンシを短縮できます。TensorFlow モデルをトレーニングしている場合は、グラフ変換ツールを使用して SavedModel を最適化することをおすすめします。詳細については、Optimizing TensorFlow Models for Serving というブログ投稿をご覧ください。

入力特徴ルックアップの管理

データポイントが指定されたときに ML モデルが予測を提供するために、データポイントにモデルが予期するすべての入力特徴を含める必要があります。予期される特徴はモデルをトレーニングするために使用されます。たとえば、大きさ、場所、築年数、部屋数、方角を考慮して家の価格を推定するモデルをトレーニングする場合、トレーニングされたモデルが推定価格を提供できるように、こうした特徴を入力値に含める必要があります。ただし、多くのユースケースでは、こうした入力特徴が呼び出し元から提供されることはありません。この場合、データストアからリアルタイムで読み込むことになります。

予測用のモデルを呼び出すためにリアルタイムで取得される入力特徴には 2 つのタイプがあります。

  • 静的参照特徴。予測が必要とされるエンティティの静的またはゆっくり変化する属性です。
  • 動的リアルタイム特徴。リアルタイム イベントに基づいて動的に取得されて計算される値です。

実際のオンライン予測では、ユーザー指定の特徴、静的参照特徴、リアルタイムで計算された特徴が併用されます。

静的参照特徴の処理

静的特徴には、お客様のユーザー属性の情報などの説明的属性が含まれます。また、購入間隔、頻度、購入合計など、お客様の購入行動の指標などの要約属性も含まれます。このような静的参照データは、以下のユースケースで利用します。

  • お客様が特定のサービス プロモーションに反応する傾向の予測。広告を表示する前に、お客様のユーザー属性と購入履歴の情報が考慮されます。
  • 住宅価格の見積もり。学校や商業施設の有無、交通機関の利便性、地域の平均住宅価格などが加味されます。
  • お客様が現在見ている商品の属性を考慮した、類似商品の推奨。

こうしたタイプの特徴は通常、データ ウェアハウスまたはマスターデータ管理(MDM)システムで使用できます。ML ゲートウェイは、特定のエンティティに対する予測リクエストを受け取ると、そのエンティティに関連する特徴を取得し、オンライン予測のための入力としてモデルに渡します。

BigQuery などの分析データストアは、結果が多数の列がある単一行になる、レイテンシが低いシングルトン読み取りオペレーション用には設計されていません。このようなクエリの例として、「特定のお客様 ID に対して複数のテーブルから 100 列を選択する」操作が挙げられます。こうしたタイプの静的参照特徴は、収集、準備された後、シングルトン ルックアップ オペレーションのために最適化された Datastore などの NoSQL データベースに格納されます(特徴のルックアップに最適な NoSQL データベースの選択については、このドキュメントの後半の NoSQL データベースの選択で説明します)。

図 4 は、モデル予測のために入力特徴として参照データを格納し、提供するためのアーキテクチャの概要を示しています。

参照データを格納して提供するためのアーキテクチャの概要
図 4. 参照データを格納して提供するためのアーキテクチャの概要

このアーキテクチャでは、次の処理が行われます。

  1. アプリケーションが、予測が必要なエンティティ識別子(customer_idproduct_idproperty_idmovie_id)を受け取ります。
  2. アプリケーションが Datastore からエンティティの参照データを検索します。このデータには、モデルに必要な属性が含まれています。
  3. アプリケーションがエンティティ属性を受信すると、入力特徴として取得された属性の値を使用して、デプロイされた AI Platform モデルを呼び出します。
  4. モデルから受け取った予測が後処理され、クライアント アプリケーションに返されます。

こうしたタイプの特徴は、値がリアルタイムで変更されないため、静的と呼ばれます。これらの値は通常、まとめて更新されます。図 4 に示すように、Dataflow を使用して参照データの準備プロセスを実装できます。このプロセスでは、スケジュールに従って次の処理が行われます。

  1. データウェアハウス(BigQuery)から、場合によってはデータレイク(Cloud Storage)から、エンティティに関連するデータを読み取ります。
  2. さまざまなフィードを結合し、必要なレコードを除外した後、いくつかの指標(各エンティティのリピート間隔、頻度、強度など)を計算します。最後に、モデルに必要な特徴エンジニアリングを行うことで、データを処理します。
  3. 作成した特徴を Datastore に保存して、リアルタイムでのルックアップとして使用します。

ビジネス エンティティ用に作成した特徴が多くのユースケースに関連し、複数の ML モデルに役立つ場合は、そのようなエンティティ ID や特徴のディクショナリを企業全体の一元化された検出可能な特徴ストアにすることができます。組織で次のように取り組みます。

  • 特徴の作成。あるチームが、特徴ストア内のエンティティの特徴セット(お客様のユーザー属性の情報など)を作成、公開、管理する作業を担当します。
  • 特徴の検出。他のチームが、さまざまな ML モデルの特徴ストアからこうした特徴を利用します。見つけやすくするために、エンティティとその特徴に関連するメタデータの記述に中央リポジトリを使用します。

特徴ストアの構築の詳細については、特徴: 機械学習用のオープンソースの特徴ストアをご覧ください。

動的リアルタイム特徴の処理

リアルタイムの特徴は、通常はイベント ストリーム処理パイプラインでオンザフライで計算されます。図 3 に示すリアルタイムの特徴とバッチ アプローチの違いは、リアルタイムの特徴では、特定の期間内の値の総計ではなく、その期間内の時間枠(固定、スライディング、またはセッション)の集計値のリストが必要であるという点です。動的リアルタイム データは、次のようなユースケースに関連しています。

  • 過去 30 分間の 1 分ごとの最高気温、最低気温、平均気温、気圧、振動などのリアルタイム センサー データを使用して、エンジンが今後 1 時間以内に故障するかどうかを予測する。
  • 現在のセッション中にユーザーが最後に閲覧した N 個の記事のリストに基づいて、別のニュース記事を推奨する。
  • 過去 1 時間に発行された 1 分あたりの未処理注文数などの関連データと、受注リストに基づいて食品の配送にかかる時間を見積もる。

このようなユースケースでは、Dataflow ストリーミング パイプラインを使用できます。動的な特徴を作成するために、パイプラインはリアルタイムでイベントを取得して集計し(合計、カウント、平均、最大、最後など)、レイテンシが低い読み取り / 書き込みデータベースに格納します。予測を生成するために、パイプラインはデータベースから動的に作成された特徴(一連の集計値)を取得し、モデルへの入力特徴として使用して予測を行います。Cloud Bigtable は、特徴値用のレイテンシの低い読み取り / 書き込みデータベースに適しています。

図 5 は、ストリーム処理パイプラインのアーキテクチャの概要を示しています。

予測に使用されるリアルタイム データを維持するためのアーキテクチャの概要
図 5. 予測に使用されるリアルタイム データを維持するためのアーキテクチャの概要

このアーキテクチャでは、次の処理が行われます。

  1. Dataflow ストリーミング パイプラインが時間ウィンドウ集計を使用して、Pub/Sub からリアルタイム イベントを取り込みます。
  2. リアルタイムで計算された集計が Cloud Bigtable に蓄積され、維持されます。
  3. Cloud Bigtable の値が、予測用に AI Platform のモデルを呼び出すための入力特徴として使用されます。
  4. 生成された予測は、Datastore に保存されてダウンストリーム システムで使用されるか、Pub/Sub トピックとして保存されます。このトピックは、後処理された後、リアルタイムでの通知、広告といった形式で呼び出し元に返されます。

事前計算とキャッシュ予測

オンライン予測のレイテンシを改善するもう 1 つの方法は、オフラインのバッチ スコアリング ジョブで予測を事前計算し、オンライン サービス用に MemorystoreDatastore などの読み取りレイテンシが低いデータストアに格納することです。このような場合、クライアント(モバイル、ウェブ、データ パイプライン ワーカー、バックエンド、またはフロントエンド API)は、オンライン予測用のモデルを呼び出しません。代わりに、クライアントは予測が存在すると仮定して、データストアから事前計算された予測を取得します。この処理は次のように機能します。

  1. データが取り込まれて処理され、Key-Value ストアに格納されます。
  2. トレーニングされてデプロイされたモデルが、準備されたデータに対してバッチ予測ジョブを実行し、入力データ用の予測を作成します。各予測はキーによって識別されます。
  3. データ パイプラインが、キーによって参照される予測を、シングルトン読み取り用に最適化されたレイテンシが低いデータストアにエクスポートします。
  4. クライアントが、固有のキーによって参照される予測リクエストを送信します。
  5. ML ゲートウェイがエントリキーを使用してデータストアから読み取り、対応する予測を返します。
  6. クライアントが予測レスポンスを受け取ります。

図 6 にこのフローを示します。

リアルタイム サービスのための事前計算とキャッシュ予測のための機能アーキテクチャ
図 6. リアルタイム サービスのための事前計算とキャッシュ予測のための機能アーキテクチャ

予測リクエストは、次の 2 つのカテゴリの検索キーに使用できます。

  • 特定のエンティティ。予測は、お客様、商品、場所、デバイスなど、ID に基づく単一のエンティティに関連しています。次のように、特定のエンティティ予測のユースケースがあります。

    • ユーザーのセッション開始時に、固有のユーザー ID に対してプロモーション、おすすめ、特典などを準備する。
    • 関連商品のおすすめを作成するために、人気のある商品の類似商品(映画、記事、曲など)を見つける。
  • 入力特徴の特定の組み合わせ。予測は時間的に一意であり、単一のエンティティ ID に基づくことはできないエンティティに対するものです。代わりに、特徴値の組み合わせでエンティティのコンテキストを定義します。コンテキストを表すキーは、特徴値の固有の組み合わせです。予測は通常、頻度が高い特徴値の組み合わせに対して計算されます。特定の特徴の組み合わせのユースケースは次のとおりです。

    • 受け取った入札リクエストに対するリアルタイム入札における入札価格の最大化。入札リクエストには時間内で一意の ID がありますが、リクエストのコンテキスト(ウェブサイトのカテゴリ、ユーザーの分類、広告の掲載結果の組み合わせなど)は繰り返し発生する可能性があります。
    • 匿名のお客様または新規のお客様がウェブサイトで何かを購入する可能性があるかどうかの予測。場所、カート内の商品数、UTM データの組み合わせに基づいて判断されます。

エンティティごとの予測処理

特定のエンティティの予測を事前計算すると、次のような状況に直面する可能性があります。

  • 管理可能な数のエンティティがある(カーディナリティが低い)ため、すべてのエンティティの事前計算予測が可能。その場合は、エンティティを前処理して、すべてを Key-Value ストアに保存することをおすすめします。例として、店舗が数百または数千しかない場合の店舗別の日々の売上予測が挙げられます。

  • エンティティが多すぎる(カーディナリティが高い)ため、限られた時間内に予測を事前計算するのは困難。例として、何十万、何百万もの商品がある場合の商品別の毎日の売上予測が挙げられます。その場合、最もアクティブなお客様や最も多く閲覧されている商品など、上位 N 位のエンティティの予測を事前計算するハイブリッド アプローチを採用できます。その後、残りのロングテール エンティティのオンライン予測にモデルを直接使用できます。

図 7 は、このフローのアーキテクチャを示しています。

Datastore と Memorystore を使用したオンライン サービスの事前計算とキャッシュ予測のためのアーキテクチャの概要
図 7. Datastore と Memorystore を使用したオンライン サービスの事前計算とキャッシュ予測のためのアーキテクチャの概要

エンティティが多数あり(たとえば、数百万曲)、ML タスクが類似性の一致(類似性のある曲の推奨)として取り組むことができる場合は、次の操作を行えます。

  1. オフライン ML プロセスでアイテムの表現(埋め込み)を事前計算します。
  2. 階層的クラスタリング方法を使用して類似のアイテムをグループ化し、読み取りレイテンシが低いデータストアに格納されるインデックスを作成します。
  3. インデックスを使用して、特定のアイテム(たとえば、現在表示中のアイテム)に最も近いアイテムを取得します。
  4. 新しいアイテム、アイテムとユーザーとのやり取りのデータを使用して、通常のオフライン プロセスでインデックスを更新します。

特徴値の組み合わせに対する予測処理

特定のエンティティ ID ではなく、入力特徴値の組み合わせに対して予測を事前計算する場合は、以下が必要です。

  • キー。可能性のあるすべての入力特徴のハッシュされた組み合わせ。組み合わせは順列ではありません。つまり、整合性を確保するために、特徴を同じ順序で使用しながらキーを構築していく必要があります。
  • 。予測。

簡単な例として、匿名のお客様または新規のお客様がウェブサイトで何かを買うかどうかを予測します。大まかには、次の表に一覧表示されているような特徴から開始できます。

特徴名 説明 カーディナリティの例
origin_continent 5~9 の間で可変 6
mobile yes / no 2
category_most_visited 店舗の在庫に合わせてカスタマイズ 10

次に、以下の操作を行います。

  1. キー文字列を作成するときに特徴の順序を決定します。たとえば、europe_yes_female_sporteurope_female_sport_yes と同じ予測ですが、2 つのキーのハッシュ値は異なります。
  2. 120 個の可能性があるすべての組み合わせ(この例では 6 x 2 x 10)についてオフラインで予測を計算します。
  3. 次の要素を使用して、予測を読み取りレイテンシが低いデータベースに格納します。

    • hash(europe_yes_female_sport) のようなキー。
    • 予測の値(たとえば、0.82345)。

図 8 は、このフローを示しています。

Cloud Bigtable を使用したオンライン サービスの事前計算とキャッシュ予測のためのアーキテクチャの概要
図 8. Cloud Bigtable を使用したオンライン サービスのための事前計算とキャッシュ予測のためのアーキテクチャの概要

このデータストアの設計は、縦長(多数のレコード)で幅が狭く(少数の列)なります。事前計算によってレイテンシのメリットがをもたらされますが、次のことも考慮に入れる必要があります。

  • 可能性のある特徴の組み合わせをすべて作成すると、データによっては数百万から数十億のレコードが作成される可能性があります。すべての特徴がそのまま意味を成し、すべての組み合わせが必要であると仮定すると、それらを格納するには、最小限のレイテンシで単一のレコードを提供できるスケーラブルなデータストアが必要です。
  • average_price のような連続値は、可能性が無限になる場合があるため、可能な組み合わせの一部として使用できません。したがって、モデルの有効性に影響を与えることに注意しながら、適切にバケット化する必要があります。バケットサイズはハイパーパラメータにできます。
  • postal_codes などの一部のカテゴリ特徴に高いカーディナリティを持たせることが可能で、それらを組み合わせると、可能性のある組み合わせを何十億も作成できます。各組み合わせに関連性があるかどうかを調べます。また、郵便番号の精度レベルを下げるかハッシュ バケットを使用することによって、モデルの有効性をあまり失わずにカーディナリティを減らせるか判断する必要があります。

NoSQL データベースの選択

Google Cloud では、レイテンシ、負荷、スループット、サイズのあらゆる要件に対応するために、いくつかのデータストアを用意しています。

図 9 は、Google Cloud のマネージド データストアのオプションを示しています。事前計算された予測と同様に、特徴のルックアップでもシングルトン読み取り、またはミリ秒単位の少数のレコードの読み取りに特化されたストアを使用する必要があります。

Google Cloud での NoSQL データストア オプション
図 9. Google Cloud での NoSQL データストア オプション

読み取りのレイテンシが短いため、この記事で説明している戦略との関連性が最も高いマネージド データストアは次のとおりです。

  • Memorystore。Memorystore は、マネージド インメモリ データベースです。その Redis 対応機能を使用すると、サブミリ秒の読み取りアクセス用に中間データを格納できます。キーはバイナリセーフな文字列で、値はさまざまなデータ構造になります。Memorystore の一般的なユースケースは次のとおりです。

    • サブミリ秒の検索時間を必要とするリアルタイム入札におけるユーザー特徴のルックアップ。
    • 事前計算済みの予測を使用するメディアとゲーム アプリケーション。
    • 入力特徴を作成するためのリアルタイム データ パイプライン用の中間データの格納。
  • Datastore。Datastore は、自動スケーリング、高パフォーマンス、容易なアプリケーション開発を実現するために構築された、フルマネージドのスケーラブルな NoSQL ドキュメント データベースです。Datastore のデータ オブジェクトをエンティティと呼びます。エンティティには 1 つ以上の名前付きプロパティがあり、モデルに必要な特徴値を格納します。Datastore の典型的なユースケースは、ログインしているユーザーの情報に基づく e コマースサイトでの商品推奨です。

  • Cloud Bigtable. Cloud Bigtable は、高スループットとレイテンシが低いワークロード向けに設計された、非常にスケーラブルな NoSQL データベース サービスです。数ミリ秒程度のレイテンシでの毎秒数百万回の読み取りと書き込みによって、ペタバイト単位のデータを処理できます。データは並べ替えられた Key-Value のマップとして構造化されます。Cloud Bigtable は、ノード数に比例して増減します。詳細については、Bigtable のパフォーマンスについてをご覧ください。Cloud Bigtable の一般的なユースケースは次のとおりです。

    • 動的に集計された値を利用した不正行為の検出。Fintech と Adtech のアプリケーションは通常、大量の読み取りと書き込みの対象となります。
    • すべての広告リクエストと履歴データに対して動的に集計された値を利用する広告予測。
    • お客様ベース全体での最近の予約に基づく予約の推奨。

ほとんどの場合、こうした店舗のデータには次のものがあります。

  • 固有のレコードキー。システムが予測を提供する際に必要とする、ユーザー ID、マシン ID、またはその他の固有の文字列です。
  • 複数のデータポイントを表せる特徴値。たとえば、IoT デバイスが計測した直近の 1 分間の最高気温と平均気圧、旅行予約サイトにおける過去 10 分間の予約件数とページビュー数などがあります。値の格納方法は、選択したデータストアによって異なります。

要約すると、

  • 変化の激しい少量のデータを、数千ものクライアントを介してミリ秒未満のレイテンシで取得する場合は、Memorystore を使用します。
  • ほとんど変化しないデータを自動スケーリングするストレージからミリ秒単位のレイテンシで取得する場合は、Datastore を使用します。
  • 比較的変化の激しいデータを、読み書きの負荷の増大に合わせてスケーリングできるストアからミリ秒単位のレイテンシで取得する場合は、Cloud Bigtable を使用します。

次のステップ