解析サービスにおける重要な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点にフォーカスすることにします。
