SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

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

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

次のページ
BigTable/BigQueryの弱点をカバーする

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
大規模解析サービスを支えるGCP活用事例連載記事一覧

もっと読む

この記事の著者

柴山 直樹(株式会社プレイド)(シバヤマ ナオキ)

 東京大学工学部にて神経科学、同大学院にて分散環境における機械学習の研究に従事。2009年未踏本体採択。2013年同大学院博士をドロップアウトし、CTOとして参画。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10455 2017/11/01 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング