Ravelin の小売業向け低レイテンシ不正行為検出サービスで Cloud Bigtable が果たした役割

※この投稿は米国時間 2021 年 7 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、Ravelin 社でプリンシパル ソフトウェア エンジニアを務める Jono MacDougall 氏にお話をお伺いします。Ravelin は、市場をリードするオンライン不正行為検出および決済ソリューションをオンライン小売業者に提供しています。同社のクライアントには多くの大企業が名を連ねるようになっており、そのスケーリング、スループット、レイテンシの需要に応えるため、同社は Google Cloud とそのマネージド サービスのスイートに移行しました。これには、大規模ワークロード向けのスケーラブルな NoSQL データベースである Cloud Bigtable が含まれています。

オンライン小売業者向けに不正行為検出サービスを提供している当社では、クライアントが増えるたびに、安全な方法で保持しなければならない新しいデータや、分析対象となる新しい金融トランザクションが増加していきます。つまり、当社のデータ インフラストラクチャは非常にスケーラブルでなければならず、なおかつ低レイテンシを絶えず維持する必要があります。当社の目標は、このような新しい組織のビジネスに影響をおよぼすことなく、迅速にサービス提供を行えるようにすることです。当社はクライアントに精算フローを提供しているため、レイテンシが原因でそのプロセスが中断されないようにする必要があります。これは、急速に成長しているオンライン小売分野においてきわめて重要な問題です。

私たちが Cloud Bigtable を気に入っている理由は、大量のデータを迅速かつ安全に取り込んで処理できるからです。当社のソフトウェアは、不正行為の判断を下す際に毎回 Bigtable のデータにアクセスします。クライアントの顧客が商品を注文したとき、当社は不正行為を検出するためにその顧客の全履歴と顧客に関するできるだけ多くのデータを処理する必要があり、しかもそれらすべてをデータのセキュリティを維持しながら行う必要があります。Bigtable は、このようなデータに短い時間枠でアクセスして処理するという点で秀でています。顧客のキーを使ってデータにすばやくアクセスし、特徴抽出プロセスに取り込んで、当社のモデルやルール用の特徴を生成できます。Bigtable に保存されているデータは暗号化されたままであり、当社および顧客にセキュリティ面の不安は生じません。

Bigtable には、ダッシュボードを通じて顧客プロファイルを当社クライアントに提示する機能もあります。そのため、不正行為が検出された場合、クライアントは当社が使用しているのと同じデータソースを使用して不正行為を確認できます。

当社の Bigtable クラスタはプライベート ネットワーク内でのみアクセスできるように構成されており、ポッドによるアクセスはターゲット サービス アカウントを使用した場合に制限されています。そのため、コードの大部分は Bigtable にアクセスできず、読み取りと書き込みを行うコードだけが Bigtable へのアクセス権限を持ちます。

当社には余剰のキャパシティがあり、そこは高速で便利に使える場所なので、デバッグ、ロギング、トレースにも Bigtable を使用しています。

Bigtable に対する負荷テストも実施しました。まずは 1 秒間にリクエスト 10 件程度の低い負荷から開始し、絶対的なピーク時には読み取りと書き込みが混在したリクエストを 1 秒間に約 167,000 件発行しました。このテストの際に行った介入は、ボタンを押してデータベースのノードの数を増やしたことだけでした。それ以外の変更は加えていません。

本番環境システムへの実際のトラフィックについては、直近 6 週間のライブ環境における Bigtable へのリクエスト件数のピークは約 22,000 件/秒（読み取りと書き込みの両方を含む）でした。

Google Cloud へのシームレスな移行

多くのスタートアップと同様に、当社も最初は Postgres を使用していました。Postgres は簡単で、使い方をすでに知っていたというのがその理由でしたが、すぐにスケーリングが難しいことがわかりました。また、巨大な Postgres インスタンスを管理したくはありませんでした。クレイジーな JOINS や複雑な WHERE 句は使いたくなかったので、Key-Value ストアのようなものを探しました。顧客 ID を割り当て、その ID について保持されているすべての情報を得たいと考えていた当社にとって、Key-Value は最適な選択肢でした。

私は前の会社で Cassandra を使用していましたが、その管理のためだけにスタッフを数名雇用する必要がありました。Ravelin では、マネージド サービスに移行し、この頭痛の種をなくしたいと考えました。当時すでに BigQuery（Google Cloud のサーバーレスでスケーラブルなデータ ウェアハウス）のファンでありヘビーユーザーでもあった私たちは、Kubernetes も使ってみたいと思っていました。これは 5 年前のことで、今では相当な数のプロバイダが Kubernetes サービスを提供していますが、私たちは依然として Google Kubernetes Engine（GKE）を持つ Google Cloud がこのスタックの頂点に位置していると評価しています。Bigtable のバージョニング機能も秀逸で、アップサートが必要なユースケースに便利です。これらすべての特長を考慮して、Bigtable を選択しました。

特にダウンタイムが許されない小売業においては、移行は大変なプロセスです。当社は Postgres から Bigtable に移行するだけでなく、AWS から Google Cloud にも移行しようとしていました。準備のため、AWS で通常どおりに運用しながら、同時に API レベルでキューを設定してすべてのリクエストを Google Cloud にミラーリングしました。これらのリクエストでエラーが発生しないか確認し、結果と応答時間が AWS と同じかどうかを調べました。このような形の運用を 1 か月続け、その間に適宜微調整を加えました。

次に大きな一歩を踏み出し、構成フラグを切り替えて Google Cloud をメインのリクエスト処理先としました。それと同時に、キューを AWS に振り向け、移行元の環境にも引き続きトラフィックが送られるようにしました。そうすることで、何か問題が発生した場合にデータを取り逃がすことなくフェイルバックできるよう備えました。この運用を 1 か月ほど行いましたが、フェイルバックしなければならない事態は 1 回も起こりませんでした。最終的に、Google Cloud へのシームレスなオンライン移行を問題なく成し遂げることができました。

Bigtable の柔軟な機能

データベース構造に関しては、当初はすべての情報を複数の行に分散させ、顧客 ID のハッシュを接頭辞として使用していました。これで、注文やトランザクションなどの履歴の各レコードをスキャンできました。しかしやがて顧客の数が増え、スキャン速度が許容されないレベルまで低下しました。そのため、すべての顧客データを 1 行に収める形に切り替え、履歴を列に格納しました。各セルには、異なるレコード、注文、支払い方法、トランザクションが含まれます。その結果、現在では 1 行を高速に検索し、その顧客の必要なすべての詳細情報が得られるようになっています。当社クライアントの一部からは、商品を注文した検証対象の顧客が 1 分間に数件の割合で送られてくるため、行サイズに制限を課さずに膨大な量のデータを引き出そうとすると、あっという間に問題になります。ガベージ コレクションは、データ量の多い顧客のデータを簡単にクリーンアップできる便利な機能です。

当社では、信頼性、アトミック性、整合性を向上させるために Bigtable レプリケーションも使用しています。当社サービスでは、同じスコープ内で複数の Bigtable リクエストを発行するため、API への単一のリクエストのコンテキスト内で強整合性を保証しなければなりません。そのため、あるリクエスト内では常に同じ Bigtable のレプリカを使用し、エラーが発生した場合はリクエスト全体を再試行します。これにより、レプリカといくらかの整合性の保証を利用できます。これは、どこで整合性を持たせるかを選択できるちょっとしたトレードオフです。

当社ではさらに、BigQuery と Bigtable を組み合わせて、複雑な WHERE 句を使った顧客レコードまたはクエリに関するトレーニングを行っています。Bigtable にデータを格納するとき、ストリーミング挿入を使用して BigQuery にも同じデータを非同期に格納します。これにより、データ サイエンティストが、考えられるあらゆる方法でそれらのデータへのクエリを行い、モデルを構築して、パターンを調べることができます。その際、クエリエンジンの制限について心配する必要はありません。Bigtable 本番環境クラスタは完全に分離されているため、BigQuery に対してクエリを行っても応答時間には影響しません。数年前は Postgres を分析とリアルタイム トラフィックの両方に使用していましたが、これは当社にとって最適なソリューションではありませんでした。他にも、ダッシュボードのテキスト検索を強化するために Elasticsearch を使用しています。

Bigtable の使用を検討している方のために私たちがおすすめする特長は、次の 3 つです。

• Key Visualizer。Bigtable でレイテンシまたはエラーが発生した場合、真っ先に見るのは Key Visualizer です。そのような場合は、ホットキーまたはワイド行が生じている可能性があります。Visualizer を見ると、注意を要する状況を把握し、そのキーが存在する正確なキー範囲または問題となっている行を知ることができます。問題の箇所がわかったら、そのレベルで問題を修復します。Bigtable へのデータのヒット状況を示すマップは非常に便利です。また、アンチパターンが使用されていないか、あるいはクライアントのトラフィック パターンの変化が問題に拍車をかけているかどうかを知ることも、トラブルシューティングに役立ちます。

• ガベージ コレクション。ガベージ コレクション ポリシーによって行サイズを制限することで、行の巨大化の問題を防ぐことができます。

• セル バージョニング。Bigtable のデータ構造は、行、列、セルからなる 3 次元配列です。個々のセルはそれぞれ異なるバージョンを示します。このバージョニングを利用して、特定の値の履歴を取得したり、ある行内の時系列を作成したりすることができます。Bigtable での単一行の取得は非常に高速なので、その行のデータ量を抑制している限り、セルバージョンを利用することは強力かつ高速なオプションです。ドキュメントには、すぐには気づかない有用なパターンがあります。たとえば、タイムスタンプ（現在では MAXINT64）を反転させることは便利な手法の一つです。必要な場合にセルバージョンの並べ替えを逆にすると、最新バージョンの代わりに最も古いバージョンを取得できます。

Google Cloud と Bigtable は、急成長しているオンライン小売分野で求められている低レイテンシの需要に応え、BigQuery などの他の Google Cloud サービスとの迅速かつ容易な統合も兼ね備えています。そのマネージド サービスのおかげで当社は管理業務から解放され、イノベーションに意識を集中してますます大規模化する顧客のニーズに応えられるようになりました。

Ravelin と Bigtable の詳細については、それぞれのリンクをご覧ください。また、Google の最新ブログ、Cloud Bigtable の規模もお読みください。

-Ravelin 社ソフトウェア エンジニア兼共同創業者 Jono MacDougall 氏