ミリ秒未満の読み取りレイテンシを実現する新しい Bigtable インメモリ階層

※この投稿は米国時間 2026 年 5 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

デジタル インフラストラクチャの成否が大きく問われる世界では、スピードは単なる指標ではなく、価値そのものです。Google Cloud Next ‘26 で発表した Bigtable インメモリ階層は、フルマネージドのクラウド データベース サービスに次のような画期的な機能をもたらします。

• ミリ秒未満の読み取りレイテンシで時間的制約があるデータを処理

• 1 ドルあたりのポイント読み取りスループットが最大 10 倍向上、TCO を大幅に削減

• ホットスポット耐性により、単一行に対して最大 120,000 クエリ/秒を手間なくサポート

詳しくは、Bigtable のパフォーマンスに関するドキュメントをご覧ください。次に、Bigtable インメモリ階層がワークロードのパフォーマンスと運用プロセスに与える影響を見てみましょう。

キャッシュミスの悪夢: よくあるケース

午前 2 時に、プロモーション キャンペーンが一気に拡散され、トラフィックが急増していると仮定します。あいにく、データベース アーキテクチャはトランプの家のように脆く不安定なため、プライマリ データベースは処理が追いつかず、別のキャッシュ レイヤがシールドとして機能している状態です。

そこに突然、アクセス集中の問題が発生しました。拡散された同じコンテンツに皆がアクセスしようとしています。キャッシュ ノードは飽和状態になっています。より大きなノードにアップグレードするか、リードレプリカを追加するしかありません。チーム全員、疲れ切っています。2 つの異なるシステムを管理し、複雑なキャッシュ アサイドのロジックを維持する（そしてキャッシュ内のデータがデータベースと同期していることを祈る）だけでなく、実際のインシデントに対応する必要もあります。そのために、ピーク負荷に対応できるように CPU をオーバープロビジョニングし、すべてがメモリに収まるように RAM を追加し、キャッシュ アサイドの複雑さを回避します。これにより、実際にはメモリに保存する必要のないウォームデータに対して、高額な料金を支払うことになります。理論上の 1 ドルあたりのスループットは高いように見えますが、実際にはリソースの 90% がほとんどの時間アイドル状態になっています。

Bigtable のインメモリ階層の登場

Bigtable インメモリ階層はこのサイクルを断ち切ります。RAM、SSD、HDD にまたがるデータ階層化を、ハイブリッド ストレージ アーキテクチャを備えた単一の統合サービスで実現することで、「仲介役」が不要になります。

その結果、キャッシュの元々のスループットと速度に、Bigtable が設計された目的である耐久性とスケーラビリティが加わります。拡散によりアクセスが急増すると、Bigtable はアクセスが集中している行を自動的にメモリに移動して負荷を処理します。CPU スパイクが発生することも、パフォーマンスが低下することもありません。トラフィックが増加すると、Bigtable クラスタも増加し、インメモリ読み取り能力が向上します。これでアイドル状態の RAM やキャッシュノードに過剰な料金を支払う必要はなくなります。Bigtable がデータをインテリジェントに管理し、ホットデータのみをメモリに保持して、インメモリ階層と SSD ストレージ間のデータ整合性を確保します。

TCO のメリットは明らかですが、おそらく最も重要なのは、それによって得られる安心感です。これはかけがえのないものです。

舞台裏のご紹介

ほぼすべてのデータベース サーバーは、CPU がインデックスや Bloom フィルタなどのレイテンシの影響を受けやすい、頻繁にアクセスされるデータに高速にアクセスできるようにするために、メモリを使用しています。では、この発表のどこが特別なのでしょうか。

その秘密は、リモート ダイレクト メモリ アクセス（RDMA）にあります。これは、システムのオペレーティング システムも CPU も関与せずに、コンピュータがあるマシンのメモリから別のマシンのメモリに直接データを転送できる高性能ネットワーキング テクノロジーです。Google のアーキテクチャは、RDMA を使用してサーバーメモリに高速に直接アクセスできるようにします。その結果、インメモリ階層のスループットとレイテンシは、サーバー CPU による制限を受けることがなくなり、大きなメリットにつながります。Data Boost が ML トレーニングなどの負荷の高いワークロードに対してディスクへの直接アクセスを可能にするのと同様に、RDMA はリアルタイム処理においてメモリへの高速な直接アクセスを実現します。

よく利用されているソーシャル メディアサイトを運営しているとします。ユーザーの 98% はフォロワー数 250 人未満ですが、最も人気のあるユーザーはフォロワー数 1 億人以上です。ユーザーの 60% は投稿が週 1 回未満で、上位 10% のユーザーがコンテンツの 80% を生成しています。一般的な投稿の表示回数は 500 回ほどですが、人気のある投稿では数千万回に達します。

このユースケースに効率的に対処するために、次のようなデータ階層化を必要としています。

• メモリ: フォロワー数の多いユーザーのプロファイルからのコンテンツ

• SSD: 最近のコンテンツ、アクティブなユーザー プロファイル

• HDD: 古いコンテンツ、非アクティブなユーザー プロファイル

幸いなことに、Bigtable ではこれを非常に簡単に行うことができます。クラスタでインメモリを有効にして、データベース リクエストを発行する際にメモリ対応のアプリケーション プロファイルを使用するだけで、ホットデータのライフサイクルを自動的に管理できます。また、エージベースのポリシーを設定して、コールドデータをアクセス頻度の低い階層に分類することもできます。この設定では、コンテンツが読み取られると、そのコンテンツは永続ストレージからメモリ階層に昇格され、それより後に読み取られたアイテムの保存場所を確保するために削除されるまでそこに留まります。この作業に手を煩わせることはありません。5 年前の投稿が突然再浮上して拡散されたとしても、心配無用です。

しかし、キャッシュ保存するものをより細かく制御したい場合はどうすればよいでしょうか。人気のあるコンテンツ クリエイターのリストがあり、そのごく一部の投稿にのみメモリ使用量を制限したいとします。そのためには、それらのユーザーに対するトラフィックはメモリ対応のアプリ プロファイル経由でルーティングし、他のコンテンツに対してはメモリ対応でないアプリ プロファイルを使用するだけです。

キャッシュミスの悪夢を再現

キャッシュミスのシナリオを再現してみましょう。ただし、今回は Bigtable のインメモリ階層を有効にしています。日曜日の午前 2 時に、プロモーション キャンペーンが急速に拡散され、トラフィックが急増しています。今から 1 時間以内に 1 秒あたり 8 万回の読み取りを追加で処理できるようにする必要があります。しかし、通知が来ることはなく、午前 11 時に鳥のさえずりで目覚め、穏やかな朝食と素晴らしい天気で 1 日を始めます。午前 2～3 時の間にトラフィックが急増したことを示す唯一の証拠は、請求額が 0.40 ドル増えていることです。

幅広い業界においてアプリケーションに対するリクエストの分布はべき乗則に従うため、このようなシナリオはソーシャル メディアに限定されません。たとえば、証券取引所では数千の証券が取引されますが、最も活発に取引される上位 30 銘柄が通常、1 日の総取引量の 40% 以上を占めています。同時に、最新のデータポイント（最終取引、売値 / 買値）は頻繁にリクエストされ、低レイテンシのレスポンスが期待されますが、過去のデータへのアクセスははるかに頻度が低く、レイテンシの許容範囲は比較的広くなります。この例のデータを Bigtable のデータ階層に分類してみましょう。

• メモリ: 最も人気の高い株式の直近の証券価格

• SSD: 最近の履歴、集計指標（時間単位、日単位、月単位など）

• HDD: 古いデータ、個々の取引などの未加工のイベント

この機能のユースケースは多岐にわたります。自動取引システムはメモリから最新の価格にアクセスし、個人投資家は SSD のデータからローソク足チャートを作成し、クオンツは Data Boost を使用して HDD の過去のデータにアクセスしてモデルをバックテストします。すべてが 1 つのデータベースに格納されており、互いに干渉することはありません。金融時系列をテレメトリー データ、センサー ネットワーク、デジタルツインに置き換えても、ストーリーはそれほど変わりません。

また、Bigtable のインメモリ階層を使用しても、高可用性、スケーリング、監査、ガバナンス、アクセス制御などの他のエンタープライズ機能が妨げられることはありません。これらの機能は通常、大きなオーバーヘッドを発生させます。このような企業要件を満たしながら、ミリ秒未満のレイテンシを実現していることは非常に印象的です。また、クライアントとネットワークを最適化することで、p50 SSD レイテンシを 2 ミリ秒未満に短縮することもできました。

Bigtable Enterprise Plus を使ってみる

Bigtable インメモリ階層は、新しい Bigtable Enterprise Plus エディションでのみご利用いただけます。このエディションは、多くの追加機能を備えており、最高レベルのパフォーマンスと管理効率を求める組織向けに設計されています。

今すぐスタックを Bigtable Enterprise Plus とインメモリ機能にアップグレードして、インフラストラクチャの管理をやめ、未来の構築を始めましょう。

詳細

• Bigtable Enterprise Plus エディションと、そのインメモリ階層以外の機能の詳細をご覧ください。Google Cloud コンソールにアクセスして、新しいクラスタを作成したり、既存のクラスタをアップグレードしたりして、ぜひお試しください。

• Bigtable を初めてご利用になる方は、新しい Bigtable 無料トライアルで Google の先駆的な NoSQL データベースをご体験いただけます。専用の Enterprise Edition ノード、500 GB のストレージ、Bigtable の使い方ガイドをご利用ください。

• 利用開始方法、技術仕様、リージョン別の提供状況について詳しくは、Bigtable の公式プロダクト ページをご覧ください。

- Bigtable、シニア プロダクト マネージャー、Anton Gething

- Bigtable、エンジニアリング マネージャー、Sudarshan Kadambi