Harunari Takata

image-1.png

Rui Hakamata

me.PNG

Engineer Team

Anri Nakamura

icon.JPG

Kakemu Fujii

image.png

Kento Kaseda

IMG_7153.jpg

Tsutomu Ikeda

IMG_r6zkvh.jpg

Reo Hakuta

T024HQQE3-U092QGQE6TD-6a515e5ed5a1-512.jpeg

Erika Sakurai

PL00879_櫻井絵理香.jpg

erikasakurai

Takaharu Nakamura

64473501.jpeg

Daichi Hachisuka

DSC04612_Original.jpg

Louis Avondet

PL00872_アボンデットルイ.jpg

Sota Sato

スクリーンショット2025-08-0410.34.30.png

Taira Ouchi

rami.png

Yuta Azumi

1000000936.jpg

Takahiro Hayashi

T024HQQE3-U05ECP8NVNC-90c78b4316d9-512.png

Kairi Ueno

2025-04-3019.32の画像.jpeg

Hiroki Tamiya

DSC01440@0.5x.jpg

Yugo Tsuchiya

登壇用.jpg

TomokiIchikawa

T024HQQE3-U05R70YBU2Z-bec7c6fdb311-512.jpeg

Yoshito Ikeda

IMG_3849_Original2.jpg

Haruki Tazoe

PL00808_田添春樹.jpg

Hajime Shiozawa

me_2.jpg

Kazuki Katsurada

PL788_桂田一輝.jpg

masashi kobayashi

LINE_ALBUM_夏合宿1日目_211219.jpg

lapla

qXlgxIG.JPG

Takehiko Okayama

ising.jpg

Kotaro Ito

IMG_5615.jpg

Yuhei Yasuda

yuhei.png

naoyashiga

1988660.jpeg

Takumi Ishii

ta9mi141.jpg

Sojiro Nishimura

icon.jpg

Katsumi Kobayashi

Kota Momoki

kF5sqT1m.jpg

Calloc

Shohei Shiraki

shiraki______.jpg

Takaaki Kanetsuki

IMG_4303.jpg

Yui Taniyama

profile_square.jpg

Kota Yatagai

icon.jpeg

Shuhei Kondo

DSC08585(3).jpg

kenshin tanaka

T024HQQE3-U05PBDAFRL6-979e9b2e96f8-512.jpg

KARTE Team

Security Team

Tomoya Koike

DSC02389.jpg

Haruki Tosa

DSC07358.jpg

Daiki Sakuma

スクリーンショット2022-09-1619.42.09.png

Takuma Shibuya

MCDV-G5y_400x400.jpeg

Takami Yamada

263231d5b255b21a5ccd1162caf4083d.jpg

Blocks Team

blocks_kaologo.png

Takanori Koga

iOSの画像.jpg

Takumi Katayama

me.jpeg

Yu Nishimura

unnamed.jpeg

Takuya Ogawa

akira.kasuga

Image-from-iOS--6------.jpg

Kosuke Oya

T024HQQE3-ULFR092SZ-a4325a429fda-512.jpeg

Yoshiyuki Komazaki

18051810.jpeg

mizchi

saboten.jpeg

Ryosuke Suzuki

myicon.jpg

koichi tanaka

Arnaud Avondet

githubprofile.png

6123322.png

kazupon

kazupon.jpg

daigo.isamatsu

-------.jpg

Jun Kusahana

kusahana.jun.jpg

Shinnosuke Ozawa

13511952_1732262680380481_2882139288629919103_n.jpg

Rei Ishikawa

rei_120.jpg

Hiroto Harada

profile_picture.jpg

Kei Tamiya

DSC06712_428.jpg

Nobuhiro Ito

itou.jpg

kazushi oohira

img_jobs_member_engineer31.jpg

Yohei Meguro

profile.jpg

Kazuto Kojima

kojimakazu.jpg

Tomoki Koga

photo_small.jpg

Kenichi Suzuki

11149348_10152861565996849_7684135567764915302_n.jpg

Takaaki Nakama

img_jobs_member_engineer24.jpg

Takahiro Tokunaga

Kohei Kadowaki

img_jobs_member_engineer21.jpg

kantetsu

img_jobs_member_engineer26.jpg

Makoto Kataigi

0404f91a9221606863b30a9472cbde90.jpg

Tatsuya Monoi

T024HQQE3-U1TBZVDEV-10a0922337c3-192.png

Jumpei Ikegami

ikegami.png

Masahiro Yamauchi

1666877493439_2.jpg

Shinji Eto

icon_eto.jpg

Yuta Nishimura

nishimura.yuta.jpg

Hideyuki Okada

IMG_8569-1.jpg

Wataru Ikarashi

20.png

Naoto Kato

kato02_480.png

Yuki Makino

img_makino.jpg

Atsushi Fujikawa

50065592145_352030691b55e725600d_1024.png

Naohiko Takemura

plaid_takemura.jpg

Daikichi Sasamori

13315227_1049838825099360_5485113047721634423_n.jpg

Atsushi Kobayashi

koba.png

Naoki Shibayama

c2c65af5b873f0db61c538c89284c9ad.jpg

Daiki Matsui

ikemonn.jpeg

Yohei Noda

profile2.jpeg

plaidinc

cover-image.png

cover-image

内製OLAP DBとBigtable Authorized Viewの活用

私たちが提供するKARTEでは、日々膨大な量のユーザーの行動データが取得され、取得したデータに対して分析が行われます。現在、毎月1ペタバイト（PB）強のデータがインサートされており、総データ量は8PB、月間解析量は180PBに達しています。

この膨大なデータを高速に分析するため、私たちはユーザーの行動データ分析に特化した内製OLAP DB「mila」を開発しています。

解析対象のデータは、弊社のリアルタイム解析基盤を通じてBigQueryに保存後、独自のパイプラインにより専用のフォーマットに変換されmilaのデータソースに永続化されます。

私たちは、このパイプラインの中間部分で使用する分散QueueとしてBigtableを使用しております。また、milaはマルチテナントなシステムであり、その中でデータの混在や権限面での事故を防ぐため、アプリケーション層ではなくインフラ層でのテナント分離を注力して行っています。(例えば、milaはGKE上でホスティングされており、k8sのnamespaceを利用してGKE上でのテナント分離を実現しています。)

そのため、Bigtableの使用においても、前述のような大量のデータ書き込み・読み取り性能を維持しつつ、数百規模のテナント間で分離されていることが求められます。これらを実現するアプローチとして、私たちはBigtable Authorized Viewの利用を検討しました。

本記事では、Bigtable Authorized Viewを用いたテナント分離の実現と、パフォーマンスの検証結果についてご紹介します。

データ同期パイプラインの全体像

まず初めに、Bigtableの使用箇所とユースケースを明らかにするため、データ同期パイプラインの全体についてお話しします。下の図がパイプラインの概略図になります。
図には、Google Cloudのリソースに加えて、二つのmilaのコンポーネントが存在しています。(BigQueryからのデータを受け取るIngester、データフォーマットの変換と永続化を行うIndexer)

データは以下の流れでBigQueryからmilaに同期されます。

ここで、IngesterとIndexerでの実際のデータの受け渡しとIndexerでの処理の失敗に備えた永続化のための分散QueueとしてBigtableを使用しています。

また、Bigtable以外のテナント分離についてですが、Google Cloudのリソースは基本的には別々で管理・作成し、データと権限の分離を行っています。milaのIngesterとIndexerに関しては、GKE上のnamespaceで隔離されたテナント間で異なるPodが動いています。

Bigtable Authorized Viewを用いたテナント分離

マルチテナント環境において、テナントごとに物理的なテーブルを作成する方法は、テーブル数が増加した際のパフォーマンス劣化や管理コストの増大から非推奨とされています。[1]

そのため、私たちは全てのテナントのデータを単一のBigtableテーブルに保存し、テナントごとに異なるBigtable Authorized Viewを用いてテナント分離を実現しました。

ここでは、分散QueueとしてBigtableを利用する行キーの設計について述べたのち、テナント分離のためのAuthorized Viewの活用についてお話しします。

内製OLAP DBとBigtable Authorized Viewの活用



私たちが提供するKARTEでは、日々膨大な量のユーザーの行動データが取得され、取得したデータに対して分析が行われます。現在、毎月1ペタバイト（PB）強のデータがインサートされており、総データ量は8PB、月間解析量は180PBに達しています。

この膨大なデータを高速に分析するため、私たちはユーザーの行動データ分析に特化した内製OLAP DB「mila」を開発しています。

解析対象のデータは、弊社のリアルタイム解析基盤を通じてBigQueryに保存後、独自のパイプラインにより専用のフォーマットに変換されmilaのデータソースに永続化されます。

私たちは、このパイプラインの中間部分で使用する分散QueueとしてBigtableを使用しております。また、milaはマルチテナントなシステムであり、その中でデータの混在や権限面での事故を防ぐため、アプリケーション層ではなくインフラ層でのテナント分離を注力して行っています。(例えば、milaはGKE上でホスティングされており、k8sのnamespaceを利用してGKE上でのテナント分離を実現しています。)

そのため、Bigtableの使用においても、前述のような大量のデータ書き込み・読み取り性能を維持しつつ、数百規模のテナント間で分離されていることが求められます。これらを実現するアプローチとして、私たちはBigtable Authorized Viewの利用を検討しました。

本記事では、Bigtable Authorized Viewを用いたテナント分離の実現と、パフォーマンスの検証結果についてご紹介します。

データ同期パイプラインの全体像



まず初めに、Bigtableの使用箇所とユースケースを明らかにするため、データ同期パイプラインの全体についてお話しします。下の図がパイプラインの概略図になります。
図には、Google Cloudのリソースに加えて、二つのmilaのコンポーネントが存在しています。(BigQueryからのデータを受け取るIngester、データフォーマットの変換と永続化を行うIndexer)



データは以下の流れでBigQueryからmilaに同期されます。





リアルタイム解析基盤を通じて解析対象のデータがBigQueryに格納されます。



その後、新しいレコードはBigQueryのContinuous Queryによりインクリメンタルに抽出され、IngesterがSubscribeするPub/SubのTopicに転送されます。



Pub/Subからデータを受け取ったIngesterは、次のコンポーネントであるIndexerに中継します。この時、書き込みをIndexerに知らせるために2で使用したPub/Subとは異なるPub/Subを用いています。



Indexerは受け取った行データをmilaの内部フォーマットに変換し(Indexing処理)、データの本体をGoogle Cloud Storage、メタデータをSpannerにそれぞれ格納します。

ここで、IngesterとIndexerでの実際のデータの受け渡しとIndexerでの処理の失敗に備えた永続化のための分散QueueとしてBigtableを使用しています。

また、Bigtable以外のテナント分離についてですが、Google Cloudのリソースは基本的には別々で管理・作成し、データと権限の分離を行っています。milaのIngesterとIndexerに関しては、GKE上のnamespaceで隔離されたテナント間で異なるPodが動いています。

Bigtable Authorized Viewを用いたテナント分離



マルチテナント環境において、テナントごとに物理的なテーブルを作成する方法は、テーブル数が増加した際のパフォーマンス劣化や管理コストの増大から非推奨とされています。[1]

そのため、私たちは全てのテナントのデータを単一のBigtableテーブルに保存し、テナントごとに異なるBigtable Authorized Viewを用いてテナント分離を実現しました。

ここでは、分散QueueとしてBigtableを利用する行キーの設計について述べたのち、テナント分離のためのAuthorized Viewの活用についてお話しします。

行の設計

milaでは、全てのデータはテナントごとに分離されテナント内では特定のキー(ユーザーのIDなど)でシャーディングされ保存されます。

行キーの設計としては、特定テナントのデータアクセスの集中によるホットスポットを避けるため、以下のようにテナントのIDに加えて、シャードの値を入れたハッシュ値をプレフィックスに用いています。

Hash(tenantId + shard + tableId)::tenantId::tableId::shard::timestamp

シャード内でアクセスが集中した場合は、ホットスポットを避けることはできませんが、KARTEでは特定のユーザーで大量のデータが生成されるケースは、システムのバグを除き存在しないため上記のキーの設計で問題ありません。

Authorized View 活用とテナント分離方法

Authorized Viewでは、セキュリティとデータ分離を実現するために、以下の3つの方法でアクセス可能なデータの範囲を限定できます。[2]





行キーの接頭辞



列修飾子の接頭辞 または列修飾子



行キー接頭辞と列修飾子を組み合わせたもの

ここで、テナントIDを行キーの接頭辞（Keyの先頭）に使用してしまうと、前述の通り、特定のテナントにアクセスが集中した場合にホットスポットが発生する可能性があります。

そのため、私たちはこのリスクを避け、列修飾子の接頭辞を用いることでテナント分離を実現することにしました。これにより、Key全体は均等に分散されたままで、各テナントは自身のデータのみに安全にアクセスすることができるようになります。

Bigtable Authorized Viewの有無におけるパフォーマンスの検証



以上の構成を用い、Bigtable Authorized Viewを使用した場合と、使用しない通常アクセスの場合でパフォーマンスにどのような差が生じるかを検証しました。特に、想定される数百規模のテナントが同時にアクセスする環境下での影響を評価しています。

ワークロードの設定

複数のスレッドから各テナントのAuthorized Viewを経由したアクセス(書き込み/読み取り)と、Bigtableへの直接のアクセスをそれぞれ実行します。検証では同じインスタンスにアクセスを行い、Authorized Viewの有無によってアクセスするテーブルを分離しています。

ワークロードの数値は本番の状況を模したものであり、詳細は以下のとおりです。





対象テナント数: 300



1テナントあたりのスループット: 300 rows/sec （システム合計: 90k rows/sec）



1テナントあたりのリクエスト: 50 req/sec （システム合計: 15k req/sec）



1行当たりのデータサイズ: 0.5 KB

計測結果

Cloud Monitoringを用いて、CPU使用率およびレイテンシの分析を行った結果を示します。なお、レイテンシについてはp99(99パーセンタイル)の数値を採用しています。

メトリクスには、Cloud Monitoringの以下の指標を使用しました。





CPU使用率: bigtable.googleapis.com/cluster/cpu_load



レイテンシ: bigtable.googleapis.com/client/operation_latencies

次のグラフにおけるラベルは、それぞれ以下の測定対象を示しています。





bt-bench-auth : Authorized Viewを経由したBigtableへのアクセス



bt-bench-raw : Bigtableへの直接アクセス

CPU 使用率



Authorized Viewの有無によるCPU使用率において顕著な差は見られませんでした。負荷のスパイクも発生しておらず、Authorized Viewの導入がCPUの負荷に与える影響は軽微であると考えられます。

レイテンシ (Read / Write)





読み取り・書き込みともにAuthorized Viewを経由した方がわずかにレイテンシが高い、またはほぼ同等のパフォーマンスを示すことが確認できました。
双方の環境において局所的なレイテンシのスパイクが見えますが、その発生頻度や挙動に有意な差はありません。そのため、Authorized Viewの使用がレイテンシの安定性に影響を及ぼしていないと考えられます。

まとめ



本記事では、Bigtable Authorized Viewを用いたスケーラブルなテナント分離について、具体的なユースケースとパフォーマンス検証を交えて紹介しました。私たちは、データ同期パイプラインにおける分散キューとしてBigtableを採用し、マルチテナント環境での安全なデータ分離を実現するためにAuthorized Viewを活用しました。

パフォーマンス検証の結果、想定される数百規模(300テナント)の環境下においてもAuthorized ViewによるCPU使用率やレイテンシの劣化はほとんど見られませんでした。権限制御に伴うオーバーヘッドをほぼ無視して、数百規模のテナント分離を高いパフォーマンスのまま実現できる点は、非常に使いやすいと感じました。

また、追加の課金も発生しない点に加え、Authorized Viewを利用した権限制御は複数の方法で行うことができます。そのため、今回のテナント分離以外にも、細かいアクセス制御が求められるユースケースにおいてBigtable Authorized Viewは適していると考えます。

[1] https://docs.cloud.google.com/bigtable/docs/schema-design?hl=ja#multi-tenancy

[2] https://docs.cloud.google.com/bigtable/docs/authorized-views?hl=ja#view-definition

Bigtable Authorized Viewを用いたスケーラブルなテナント分離アーキテクチャ

Engineer Blog

Recent Article

プレイドのエンジニアブログを始めました！

Popular Articles

Popular Tags

Archives

Writers