大局的に考える: Ricardo が BigQuery を補完するために Bigtable を選んだ理由
Google Cloud Japan Team
※この投稿は米国時間 2021 年 1 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。
370 万人以上の会員を擁する Ricardo は、スイスで最も信頼度の高い便利な大手オンライン マーケットプレイスです。当社は、2019 年にオンプレミスから Google Cloud への移行に成功しました。この移行により、解決が必要な新しいユースケースも発生しました。オンプレミスのデータセンターを閉鎖するにあたり、こうしたユースケースのソリューションを見つけなければならない期限が迫っていたのです。そこでまず検討したのがデータ ストリーム プロセスです。そして、Google Cloud の Cloud Bigtable と Dataflow 両方を使用したソリューションを見つけました。本稿では、当社がそのソリューションを決定、実装した方法と、ロードマップの将来のユースケースについてご紹介します。
データのユースケースを探る
当社は従来、分析に Microsoft SQL データ ウェアハウスを使用していましたが、Google Cloud のエンタープライズ データ ウェアハウスである BigQuery に切り替えることにしました。この切り替えにより、すべてのワークロードを BigQuery に push することも必要になったため、Apache Beam を介して Kafka から BigQuery へのインポートとバッチ読み込みを行うことにしました。
また、社内チームが顧客情報ポータルを通じて不正検出作業を行えるようにし、不正な商品の販売や盗難 ID の使用から顧客を保護できるようにしたいと考えていました。
さらに当社のエンジニアは、別々のシステムに保存されていた 2 つの主要なデータのストリームを移動するという課題に迅速に対処する必要がありました。1 つ目のストリームは品目（プラットフォームに掲載する販売商品）、もう 1 つはその品目のさまざまな説明を含むアセットのためのものです。以前は、ストリームを BigQuery に挿入してから JOIN を行なっていました。ここでの課題の一つは、Ricardo がかなり前から存在しているため、2006 年以降に保存されていない品目や再掲載された品目があり、アセット ストリームの一部の情報が欠落している場合があることです。
「どのソリューションを使用すべきか？」という問題
データ ストリームの問題解決のために調査を行っているときに、Google Cloud 公式ブログである投稿を見つけました。それには、Dataflow（Google Cloud の統合ストリームとバッチ処理サービス）の一般的な使用パターンのガイドとストリーミング モードの大規模ルックアップ テーブルに関するセクションが掲載されていました。当社は、品目ストリームに加えて、アセットを含む約 400 GB の大きなルックアップ テーブルを保有していますが、品目のアセットを検索する必要がありました。このガイドでは、列指向システムがこの種のクエリにミリ秒単位で応答でき、Dataflow パイプラインで使用してルックアップとテーブル更新の両方を行えることが示唆されていました。
そこで、当社のユースケースを解決するために 2 つの選択肢を検討しました。私たちは、オープンソースのワイドカラム型ストアである NoSQL データベース管理システムの Apache Cassandra でプロトタイプを試しました。これは、Apache Beam を使用して BigQuery からストリーミングし、過去のデータをプリロードできます。
Datastax がオープンソースとしてリリースしている CASS Operator を使用して、Google Kubernetes Engine（GKE）上に新しい Cassandra クラスタを構築しました。インデックス構造を作成し、全体を最適化して、いくつかのベンチマークを行ったところ、すべてが機能しました。この新しい Cassandra クラスタによって、パイプラインはアセットと品目を消費し、アセットは保存されている Cassandra ストアから検索されるようになりました。
しかし、日常のタスクや面倒な運用についてはどうでしょうか？当社のデータ インテリジェンス（DI）チームは、完全に自分たちだけで作業する必要があります。当社は小規模の会社であるため迅速な行動を必要としており、すぐに使われなくなるシステムを構築する余裕はありません。
私たちはすでに BigQuery のマネージド サービスを使用し、気に入っていました。そのため、フルマネージドで低レイテンシのワイドカラム NoSQL データベース サービスである Bigtable を使用することは、良い選択肢のように思えました。
Bigtable により純費用を 13% 削減
Bigtable と比較して、Cassandra は予算の面で難がありました。Cassandra では、可用性を確保するには 3 つのノードが必要であることがわかりました。しかし Bigtable では、Apache Flink でフォールト トレラントなデータ パイプラインや Apache Beam パイプラインを実行できます。また、可用性が低い場合でもフォールト トレランスを実現できるため、3 つのノードを実行する必要はありません。ルックアップ テーブルに使用する過去のデータを BigQuery から Bigtable に取り込んだ際、当社はあらかじめ 18 ノードを確保していましたが、このルックアップ テーブルは 1 秒あたり 10,000 件ものリクエストを処理できたため、すぐに 2 つまたは 1 つのノードにスケールダウンできました。Bigtable ではバックグラウンドで可用性と耐久性が維持されるため、1 つのノードでも確実に対応できます。
この実体験から、Bigtable ソリューションは Cassandra よりも管理が簡単で、費用対効果も高いことが明らかになりました。当社の小さなチームで Cassandra-on-GKE ソリューションに必要な運用学習費用、ダウンタイム、技術サポートを考慮に入れた場合、8 CPU GM のかなり小さい E2 ノードクラスタを 3 倍必要とする Cassandra-on-GKE ソリューションに比べ、1 つの Bigtable インスタンスで 1 TB を使用した方がすでに可用性が高くなるのです。使いやすさ、処理速度、費用のすべてで優れているものが Bigtable でした。ルックアップ クエリを Bigtable に移行することで、最終的に BigQuery の費用を 13% 節約できました（これは正味の節約で、Bigtable を実行するための追加費用はすでに考慮済みです）。
この新しいソリューションを使い始めてすぐ、別のワークロードを Bigtable に移動し、そこでカスタマー ケア チームのために Zendesk チケットからのデータを統合しました。また、顧客情報の統合にも取り組み、Zendesk データにリンクされたプロダクト キー ルックアップを Bigtable で利用できるようにして、顧客情報がカスタマー ケア エージェントに即座に提示されるようにしました。
Google Cloud ツールの緊密な統合によるメリット
当社のような小規模企業の場合、データにアクセスしやすいデータ インフラストラクチャを構築することが最優先事項です。私たちにとって Bigtable は、サービスで使う処理済みデータを利用可能にするストレージです。Bigtable、BigQuery、Dataflow 間でサービスを統合することで、このデータを簡単に利用できるようになります。
Google Cloud のプラットフォームが優れていると思った別の理由は、Dataflow と BigQuery を使用してすばやく調整できることです。たとえば、ある朝、私は進行中のプロジェクトについて考えていたとき、品目 ID を逆にする必要があることに気付きました。ホットスポット化を防ぐために、通常の文字列ではなく逆の文字列を使用する必要があったのです。早速 20 の Bigtable ノードと 50 の Dataflow ワーカーをスケールアップし、バッチジョブによって BigQuery から読み取ったデータを Bigtable で新しく作成されたスキーマに書き込みました。これらの作業をすべて 25 分で完了しました。Bigtable を導入する前だったら、このような調整に数日かかっていたでしょう。
Bigtable の Key Visualizer によって開かれる機会
品目 ID を逆にするというアイデアは、Bigtable の Key Visualizer から思いつきました。この方法は以前のセットアップよりも優れていて、使用も簡単です。緊密に統合されていますが、人に説明するのは簡単です。
私たちは SSD ノードを使用しています。懸念材料となる唯一の構成はノード数で、レプリケーションが必要かどうかで左右されます。しかし、ノード数の調整はステレオの音量調整と同じくらい簡単で、本当に驚きました。スケールアップとスケールダウンも非常にすばやく行われます。Dataflow を使用することで、作業に影響が出ることはなく、事前にウォームアップする必要もありません。スケジュール設定し、実行しながら共有できます。このように簡単なスケーリングはこれまで見たことがありません。
Bigtable の将来のユースケースを考慮する
私たちは将来のユースケースに備えて、機械学習（ML）を使った不正検出プロジェクトの改善に取り組んでおり、これを Bigtable に移行したいと考えています。現在、Cloud Composer で Airflow によって 1 時間ごとにトリガーされるプロセスがあります。このプロセスでは、過去 1 時間の BigQuery のデータを取得して調査します。その際、読み込まれたモデルで実行された Python コンテナがデータを入力として受け取ります。アルゴリズムによって品目が 100% 不正であると確実に判断されると、その品目はブロックされます。ブロックを解除するには、カスタマーケアからの手動リクエストが必要になります。アルゴリズムによる判断が確実でない場合、その品目は、エージェントが確認できるよう、カスタマーケアの受信トレイに送られてフラグが付けられます。
現在このプロセスに欠けているのは、カスタマー ケア エージェントが「これは不正ではない」と返答した場合の学習調整を行う自動フィードバック ループです。アクションを実行するためのコードを実際に記述することもできますが、必要としているのは、より迅速なソリューションです。学習モデル用に Bigtable から直接パイプでこれを取得する方が理にかなっています。
将来的には、すべての重要なトピックについて、Dataflow パイプラインで BigQuery と Bigtable に同時に書き込めるようにすることも考えています。このようにして取得したユースケース用のデータは、BigQuery ではなく Bigtable から直接提供することで、ほぼ「リアルタイム」の処理を実現できます。
BigQuery の費用を 13% 節約できただけでなく、Bigtable などの Google Cloud マネージド サービスがすべて緊密に統合されていることで、当社の小規模でありながらも粘り強い DI チームは、データ プラットフォームの煩わしい運用作業から解放されました。これにより、その時間を将来のユースケースなどのソリューション開発に充てることができます。
Ricardo.ch の商品情報をご覧ください。クラウドネイティブの Key-Value ストアである Bigtable の詳細については、Google のサイトをご確認ください。
-Ricardo データ インテリジェンス チーム所属データ エンジニア Tobias Kaymak
