Cloud Bigtableのアーキテクチャを理解しよう！

概要
Bigtableとは？
1. 特徴
アーキテクチャ
データ構造
スキーマ設計
まとめ

概要

こんにちはKIYONOのエンジニアの西園です。

今回はBigtableのアーキテクチャについて簡単に解説してみたのでご覧ください。

Bigtableとは？

Bigtableとは、端的に言うと大量のデータをリアルタイムで処理することに優れているNoSQLのデータベースです。

つまりポイントは下記3つです。

大量データ処理
リアルタイム処理
NoSQLデータベース

これでほぼBigtableをわかったも同然ですね。（はい、冗談です。。。）

気を取り直して、使用用途は下記のようなものがあります。

時系列データ。複数のサーバーにおける時間の経過に伴う CPU とメモリの使用状況など。

マーケティングデータ。購入履歴やお客様の好みなど。

金融データ。取引履歴、株価、外国為替相場など。

IoT（モノのインターネット）データ。電力量計と家庭電化製品からの使用状況レポートなど。

グラフデータ。ユーザー間の接続状況に関する情報など。

引用：公式ドキュメント

これだけ見ると「へ〜そうなんだ」で終わります。しかしKIYONOのエンジニアはここから一歩へ。

ということでもっと読者のみなさんがイメージしやすい事例を探してきました！

みなさん知っていますか？

調べたい言葉を入れると適切な情報を提供してくれる代物を。

そう!

Google検索エンジンです!!

実はGoogleの検索エンジンにもBigtableが使用されています。

何十億ものユーザーから大量に送られてくるリクエストをリアルタイムで処理をして結果を返さないといけないので、

まさにBigtableの特性が非常にマッチしています。

特徴

Bigtableの特徴は大きく分けて3つあります

高スループット → 単位時間あたりに処理できるデータ量が多い
低レイテンシ → 通信の遅延時間が少ない
フルマネージド → 特に管理の手間がいらない

アーキテクチャ

Bigtableのアーキテクチャはそこまで複雑ではありません。

抑えるべき要点は下記のたったの3つです

クラスタ
ノード
タブレット

もっと簡単に表すと

クラスタ = 作業スペース
ノード = 作業する人たち
タブレット = 作業に必要なものを収める倉庫

正確にはもっと細かいものも含まれていますが、この3つさえ理解していれば大丈夫です。

アーキテクチャ図

引用：公式ドキュメント

クラスタ

クラスタとはアーキテクチャ図の中間に位置している部分のことで、ここは主にノード（後ほど解説します。）を配置する領域になります。

クラスタ自体が何か処理を行ったりということはしません。先ほど記載した通り単なる作業場です

大きな特徴としてはゾーンに1つのみ配置できるということです。

ノード

ノードはクラスタ内で処理を担ってくれるコンピュータリソースです。つまり作業する人です。

ここは、書き込みや読み込みなどが発生した場合に一生懸命に働いてくれます。

また各ノードは特定のタブレットと紐づいていて、その紐づいたタブレットに対して書き込みや読み込みの処理を行います。

設定によっては負荷に応じて自動的に数を増加させたり、管理の手間を省くこともできます。

タブレット

タブレットはアーキテクチャ図の下部に位置するSSTableと記載されている部分です。

SSTableとはデータの格納方式のことでここではあまり重要ではないので割愛します。

ここはデータの倉庫です。ここからデータを読み込んだり、ここにデータを書き込んだりします。

Bigtableは基本的に1つのテーブルにデータを集約して使用します。その集約したテーブルがタブレットとして分割されて各ノードと紐づいています。

データ構造

次にデータ構造について説明していきます。

Bigtableは基本的に下記の3つで構成されています。

行キー（Row key）
列ファミリー（Column family）
列（Column）
セル

データ構造は下記のような形です。

引用：公式ドキュメント

行キー（Row key）

基本的にこの行キーを使用してデータを探索します。行キーはスキーマを設計する上でパフォーマンスの観点から非常に重要となります。

列ファミリー（Column family）

列ファミリーとは関連する列をグループ化するものです。

列（Column）

列はカラム名のことです。たとえば、user_idやageなど様々です。

セル

セルは行と列が交わる個々のデータが格納されるところです。

特徴的なのは値を更新した際に古いデータは削除されるのではなく、タイムスタンプによりセル内で保存される点です。

つまり更新すればするほどセル内にデータが溜まっていきます。

これを解消するためにガベージコレクションを利用します。

ガベージコレクション

ガベージコレクションとはセル内に保存されている古いデータを削除することができる設定です。

ガベージコレクションポリシーで詳細を設定することができます。

削除方式は2種類下記の2種類です

期限切れ値の設定 = タイムスタンプベースで削除する方式
1. ex) 何日以前のデータを削除
バージョン数 = データ保持数を決めることで、削除する方式
1. ex) 保持数を5個に設定した場合、順次溢れた古いデータは削除

特徴

Bigtableのデータ構造は行指向です。つまりデータをスキャンする際に行単位でスキャンします。

その構造から基本的には横長のテーブルにすることでスキャン効率が良くなります。

しかし、すべてが横長のテーブルにすればいいわけではありません。

たとえば下記の時系列データのように何か特定の値をタイムスタンプごとに格納する場合、無限に横長にデータが増えてしまいます。（※テーブルは簡易的に列ファミリーを省略して記載しています。）

行キー\列	2022-0101-1200	2022-0102-1201	2022-0103-1202	・・・
tokyo#temperature	14	8	8	・・・

ここで抑えとくべきポイントはBigtableの一行のデータ量は100MB以下にすることがパフォーマンスの観点から望ましいということです。（最大は256MB）

したがって例に挙げたような時系列データのように何か特定の値を時間ごとに格納する場合は下記のように縦長に設計した方が良いです。

行キー\列	temperature
tokyo#2022-0101-1200	14
tokyo#2022-0102-1201	8
tokyo#2022-0103-1202	8
・	・
・	・

上記のように設計することで一行のデータ量は100MB以下という用件を満たすことができるのでパフォーマンスの低下を防ぐことができます。

またデータの並び順には2つ大きな特徴があります。

行キーの辞書順にデータが並ぶ
列ファミリーの中で列は辞書順に並ぶ

辞書順に並ぶという特徴から行キーの設定次第でパフォーマンスに大きく影響します。

スキーマ設計

いよいよ来ましたスキーマ設計！Bigtableにおいてはパフォーマンスの観点からこのスキーマ設計が非常に肝になります。

そもそもスキーマ設計って何やねんという人のために軽く解説します。

スキーマ設計とは

端的に表現すると、データベースにおけるデータ構造を設計することです。

Bigtableでいうところの先程記載した行キー、列ファミリー、列にどういった値を設定するかを決めることです。

スキーマ設計の流れ

まずスキーマを設計するときの流れが公式ドキュメントに記載されています。簡単に紹介します。

流れとしては下記のように実施していきます。

デザインの決定 → テストの実施 → 調査 → デザインの再定義 → テスト → ・・・

この流れを繰り返し、適切なスキーマ設計を実現していきます。

それではそれぞれいったい何をやるのかっていうところを解説していきます。

1. デザインの決定

最初は初期スキーマを決めます。

つまり、行キー、列ファミリー、列にどういった値を設定するのかを暫定的に決めます。

なおここでは後ほど記載する避けるべき行キー設計に基づいて設計します。

2. テストの実施

設計したスキーマによってパフォーマンスを測定します。

具体的には、下記のように行っていきます。

1. 設計したスキーマを元にテーブルを作成
2. 30GB以上のデータを用意してテーブルに読み込む
3. 高負荷テストを数分間実施
4. 読み取りと書き込みについて1時間のシミュレーションを実施
5. Key VisualizerやCloud Monitoringを使用してシミュレーション結果を確認

<備考>