大規模解析サービスのためのデータベース構成 ～BigTable／BigQueryの弱点をどう補うか？

大規模解析サービスを支えるGCP活用事例 第3回

Realtime CalculationでのDB構成

　二つ目の仕事は、リアクションシステムのためのリアルタイムでの評価計算です。KARTEではパーソナライズ（ユーザーの行動履歴の解析結果によってサーバーのレスポンスを変更すること）を実現するために、リクエストごとに必要なAggregation等の計算結果を、高速に読み書きできるBigTableに格納し、利用しています。下記にKarteでのざっくりとした構成図を示します。

　trackプロセスは、よりシビアにレイテンシをコントロールするため、Google Pub/SubではなくRedisを利用しています。そこからAggregationなどの評価計算を行うanalyzerプロセスが数百ms以内にBigTableに書き込みます^[2]。その情報をtrackプロセスは読み出し、パーソナライズされたレスポンスを返します。

　また、これらの解析結果（KARTEでは主に「ユーザー」として扱われます）は、trackにおいては単純に一つの結果を取得できれば良いですが、管理画面ではさまざまな見方をしたくなります。ですが、BigTableは単純なクエリ以外は書くことができません。そこで、BigTableにデータ本体を書き出す際、同時にMongoDBの方に管理画面で使うクエリに合わせたIndexのみのCollectionを、TTLを設定して書き出しておきます。こうすることで、高速な読み書きの要求と、複雑なクエリーの要求の両方に対応することが可能です。

注

[2] analyzerプロセスは低レイテンシのセミバッチMapReduce処理を行うKARTEのコア機能ですが、本連載では範囲外なので説明しません。

全体でのDB構成

　最後に全体のDB構成をまとめてみます。

　かなり簡略化しましたが、案外スッキリシンプルに構成できることがわかるかと思います。面白いのは右（Realtime）も左（Batch）もスケーラビリティをBigTableとBigQueryで確保しつつ、クエリの柔軟性やレイテンシを他のデータベースで補完していることです。また、負荷コントロールにQueueを利用しているところも一緒です。

まとめ

　本稿では大規模解析サービスのためのデータベース構成について紹介しました。解析サービスにおける重要な2つの仕事Batch AggregationとRealtime Calculationについて紹介し、それぞれに合ったデータベース構成の1例を紹介しました。また、その時に考慮すべきデータベースの特性と組み合わせによってスケーラビリティが高いデータベースの短所をカバーするテクニックを紹介しました。

　一般論からはみ出た議論も多かったと思いますが、KARTEの開発で培ったデータベースの活用法の面白い部分の一端を紹介できたのではないかと思います。BigQueryにおけるスキーマの自動管理、RedisのBitmapを利用したaggregationなど、ここでは紹介できなかったテクニックもあります。これらはプレイドのエンジニアブログなどで紹介できれば、と思います。