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

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

　大規模なデータを扱う解析サービスにおいて、データベースの性質の理解や選定、配置、活用方法などはクリティカルな問題であり、サービスとして大きく差をつくる要素にもなります。本稿では考慮すべきデータベースの性質の違いから始め、解析サービスにおける考え方や活用のテクニック、構成方法について紹介したいと思います。

解析サービスにおける重要な2つの仕事

　ここでは大量のデータを収集する解析サービスの仕事の中でも、重要な2つの仕事についてフォーカスして話を進めていこうと思います。

　一つ目は、データを単に収集し、スケーラビリティの高いデータベース（または分散ファイルシステム）に格納し、あとで（管理画面から、もしくはスケジュールバッチなどで）Aggregateするものです。こちらは解析サービスと言われるサービスの多くが行なっている仕事と考えられます。

　二つ目は、データによって振る舞いを変える、リアクションするサービスにおいて重要な仕事です。つまり、データを収集し、その場でデータを評価（Aggregateなど）する、よりリアルタイムな仕事です。こちらは必ずしも解析サービスだからと言って必要な仕事ではありませんが、鮮度の高いデータの活用方法であり、一つ目のように“見るだけ”で終わらない結果に直結する良さがあります。そのため、KARTEのようにパーソナライズ機能を持つ場合には必要な仕事です。

　それに対して一つ目の利点は、スケジュールやアドホックなクエリによって、データボリュームがあっても比較的柔軟に見方を変更できることです。

　一つ目をBatch Aggregate、二つ目をRealtime Calculationとして念頭に置き、データベースの性質や構成について考えていくことにします。

考えるべきデータベースの3つの性質

　データベースはアプリケーション側での仕事内容によって評価されるポイントは異なります。ここでは上で説明したような2つの仕事に関する性質のみを考えることとします。もちろんKARTEにおいてもアカウントや各種設定、決済、トランザクションに関わるデータベースはありますが、ここでは解析データに関するデータベースの議論に絞り、それらについては議論しません。

　このような仕事の場合、クエリに対する自由度、Get/Putに対するレイテンシ、データ規模に対するスケーラビリティの3つを考えるとデータベースの特性をうまく扱えます^[1]。

　データベースを組み合わせたり、特性上得意なところに配置することにより、長所を最大限生かしてアプリケーション設計することが可能です。そのような考え方からKARTEでは主に特性の異なる5つのデータベースMongoDB、Redis、Cloud BigTable、BigQuery、Cloud Spannerを併用して利用しています。

MongoDB

　MongoDBは広く使われるドキュメント指向DBです。クエリの柔軟性がある代わりに水平シャーディングによるスケーラビリティは少し安定性にかけるため（よくやられることかと思いますが）KARTEでは自前でハッシュを計算して管理をしています。インメモリにデータが格納されるサイズにしておくと書き込み／読み込みともにそこそこのパフォーマンス（レイテンシ／スループット）が出る印象です。その代わりそこまでのデータサイズを格納しない用途に使われることが多いと思います。

Redis

　Redisはこちらも広く使われているインメモリのKVSで、特殊なデータタイプとコマンドを用意しているのが特徴です。インメモリなので巨大なデータを入れることには適さない代わりに、高速な読み書きに利用できます。

Cloud BigTable

　Cloud BigTableはGoogleが社内利用していた分散型の列指向DBをオープンにしたもので、大容量のデータでも低レイテンシ、高スループットを維持できるのが最大の魅力です。こちらに関しては本連載で詳細に説明する回があります。

BigQuery

　BigQueryもGoogleが社内利用していたプロダクトをGCPでオープンにしたもので、テラバイトであれば数秒、ペタバイトであっても数分でスキャンできると豪語するフルマネージドなデータウェアハウスです。こちらに関しても本連載で詳細に説明する回があります。

Cloud Spanner

　Cloud Spannerは分散型のリレーショナルデータベースで、整合性を確保しつつ、スケーラビリティも良い、こちらもなかなか魅力的なプロダクトになります。プレイドではまだ検証段階ですが、一部利用しているので、本連載で少し触れる予定です。

　検証中のSpannerを除いた4つのデータベースを3つの性質でマッピングして見ると次のようになります。

データベースの性能比較

　もちろん上記以外のさまざまなデータベースを組み合わせることが可能です。その場合にも上のような特性をバラけさせたStackを組むと良い場合が多いと思います。

　さて、解析サービスでは大量のデータを捌く必要があるため、スケーラビリティに特徴を持つデータベースを中心に設計することになります。その点、GCPには、その用途におあつらえ向きなBigTableとBigQueryという素晴らしいプロダクトがあります。そのため、この2つのプロダクトの長所を生かし、どのように短所をカバーするか、が重要なテクニックになります。

注

[1] もちろんconsistencyやatomicityなど他の性質も時と場合によって考慮する必要があります。乱暴な議論であることは重々承知ですが話を単純化するために、この3点にフォーカスすることにします。