データベースへの接続が増えすぎると、データの処理能力を使い切る前にサービスが停止することがあります。Metaが導入した「ZGateway」は、この問題に対応するためのプロキシ層です。FacebookやInstagramを運営する同社は、社内で広く使うキーバリューストア「ZippyDB」と、それを利用するアプリケーションの間に中継地点を設けました。狙いは、100万台を超えるクライアントホストから広がる接続を整理し、基盤側で管理できる構造に変えることです。

ZippyDBは、キーと値を組み合わせてデータを保存する仕組みです。Metaでは製品のメタデータ、カウンター、設定情報などを支え、毎秒数十億件の操作を処理しています。こうした用途では、一つの操作が小さくても、呼び出すサービスと接続先が増えるにつれて、通信を維持する負担が膨らみます。



Metaによると、ZGatewayは毎秒10億件を超える操作を処理し、ZippyDBのトラフィックの約40％を担っています。この割合は60％超に拡大する見込みとされ、平均的なユースケースでの計算資源の追加負荷は約6％です。すべての処理が同じ負荷で動くという意味ではなく、導入の規模とコストを把握するための目安です。

今回の発表の中心は、生成AIモデルの性能向上ではなく、データ基盤の運用設計です。生成AIを組み込む企業システムでも、周辺の設定や状態を扱う基盤は必要になります。ただし、ZGatewayが生成AI用途で検証されたという情報は示されていません。企業が注目すべき論点は、利用サービスが増えても安定して動くよう、接続と制御の責任をどこに置くかという点にあります。

従来の構成では、ZippyDBのクライアントが必要なデータベースホストへ直接接続していました。一つのクライアントが数万のシャードにアクセスすることもあり、その接続先は数十万台規模のホスト群に広がります。シャードとは、データを複数のまとまりに分割して保存・処理する単位です。分散によって処理を広く受け持てる反面、接続の組み合わせまで無制限に増やしてよいわけではありません。

Metaの環境では、典型的なクライアントとデータベースホストの双方が、数万本のTLS接続を抱えていました。TLSは通信を暗号化する仕組みですが、接続は待機している間も管理が必要です。メモリーやCPUに加え、OSが接続などを識別するためのファイルディスクリプターも消費します。問い合わせが少ない時間帯であっても、接続を維持する費用はなくなりません。



問題が表面化しやすいのは、多数のクライアントが一斉に再接続するときです。Metaでは、ファイルディスクリプターの枯渇やメモリー不足によるクラッシュが発生していました。ある障害では、経路制御の不具合によって各クライアントがシャードごとに接続を開き、サーバー群が再起動を繰り返す状態に陥っています。接続の回復動作そのものが、新たな負荷を生む構図です。

クライアント側の修正だけで解消するのも容易ではありませんでした。利用するクライアント群を数百のチームが管理していたためです。各チームに更新を依頼する方法では、対策を全体へ行き渡らせる調整が必要になります。ZGatewayの導入は、接続本数を削減する技術的な対策であると同時に、共通の問題を基盤チームがまとめて扱えるようにする責任分担の変更でもあります。

ZGatewayは、クライアントと、データベースを動かすZServer群の間に配置されます。地域ごとに設けた層を、Metaのサービス間通信基盤「ServiceRouter」を通じて見つける構成です。単純な中継を担うタイプと、読み取り用キャッシュを持つタイプがあります。内部では、機能を備えた既存のC++製ZippyDBクライアントが動作しており、クライアントの処理を共通サービスとして運用する形です。

アプリケーションからのリクエストは、同じ接続先を継続して使う接続を通じて、地域内のZGatewayホストへ送られます。そこでTLS接続を終端し、用途ごとのアクセス制御リストに照らして権限を確認します。その後、利用単位であるテナントごとに受け入れ量と流量を調整し、対象のシャードを特定する流れです。



キャッシュ付きの層では、保存済みの値で読み取りに応答できるかも確認します。データベースへ送る必要がある処理は、同じシャードに向かうほかの処理とまとめ、適切なレプリカへ転送します。レプリカは、データの複製を保持する接続先です。返ってきた応答は各リクエストに振り分けられ、用途別のメトリクス、処理経路の記録、割り当て枠の使用量も記録されます。

「ステートレス」という名称は、キャッシュを含めて一切の状態を持たないという意味に受け取るべきではありません。今回の構成ではデータベース本体と中継層を分けながら、中継層にも一時的なキャッシュや制御情報を置いています。設計上の要点は、各アプリケーションが個別に抱えていた複雑な処理を、管理された共通の層に集めることです。ただし、通過地点が増える分だけ処理コストも生じるため、集約の効果と追加負荷を合わせて評価する必要があります。

ZGatewayによる接続削減の説明では、実運用の処理量と、仮の構成を使った試算を区別する必要があります。Metaが示したモデルでは、20地域、データベースホスト50万台、プロキシホスト3万台、クライアント100万台、クライアント当たり5万シャードという数値を置いています。この条件で、ホスト当たりの接続数は約97〜98％減り、永続接続の総数は約19分の1になる計算です。

この数字を、自社環境にそのまま当てはめることはできません。実際の削減幅は、クライアントがどれだけ多くのシャードにアクセスするか、接続先がどの程度重なるかといった条件に左右されます。重要なのは削減率の大きさだけでなく、クライアントの増加がデータベース側の接続数にどう波及するかです。



直接アクセスでは、利用するクライアントが増えるほど、データベース側が受け入れる接続も増えていきます。中継層を置くと、複数のクライアントから来た処理が集約され、データベース側への接続を共有できます。Metaのモデルでは、データベース側に集まる接続数は、クライアント総数ではなく、主に地域数とホスト当たりのシャード密度に応じて決まる構造になります。

企業の基盤設計でも、この違いは判断材料になります。新しいサービスを追加するたびに、既存のデータベースへ接続の負担が積み上がる構造なのか。それとも、基盤側で規模を管理する中継層に吸収できるのか。検証の出発点は、クエリーの処理時間だけを見ることではありません。ホスト当たりの接続数、待機接続の資源消費、再接続時の増加量を確認すれば、自社で対処すべき問題がデータ処理能力にあるのか、接続管理にあるのかを切り分けやすくなります。

共通の中継層には、異なるサービスのリクエストが集まります。接続を整理できても、一部の利用者が大量の処理を送ることで全体が詰まれば、運用上の問題は残ります。ZGatewayが取り入れた「Discriminant Load Shedding（DLS）」は、過負荷時に処理を選別し、影響を利用単位ごとに閉じ込めるための仕組みです。負荷の高い利用者を意味する「ノイジーネイバー」の影響を抑える役割を持ちます。

DLSでは、テナントと優先度に応じてリクエストの待機先を分け、それぞれから順番に処理を取り出します。大量のリクエストを送ったテナントは、自分の待機枠を埋めることになります。全利用者が一つの待機列を共有する場合と比べ、特定の利用者による集中が、ほかの利用者の処理枠を圧迫しにくくなる設計です。



Metaが実施した制御された過負荷試験では、CPU使用率が90％を超える条件で、約1,350のテナント用バケットのうち、負荷制限を受けたのは大量の処理を発生させた6テナントでした。ほかのテナントではリクエストの99.9％が実行され、拒否は発生しなかったと報告しています。有効な処理の割合を表すgoodputは約97〜98％を維持し、この制御機構にはCPUの約8％が使われました。

これらは特定条件での試験結果であり、あらゆる障害に対する保証ではありません。また、DLSのCPUコスト約8％と、平均的な用途でのZGatewayの追加負荷約6％は、対象と条件が異なるため、単純に足したり比較したりできません。企業が参考にできるのは、過負荷時にも守るべき利用者や処理を明確にする考え方です。全体の成功率だけでなく、どのテナントが拒否され、ほかの利用者へ影響が及んだかまで測ることが、共有基盤の品質評価につながります。

ZGatewayでは、接続集約に加えて、読み取りキャッシュ、負荷分散、地域をまたぐ切り替えも共通層で扱います。キャッシュに値がない場合はキーごとに取得処理を制御し、同じデータを同時に取りに行く集中を抑えます。データ変更を通知する仕組みでキャッシュを更新し、古い値を許容する範囲を定めて鮮度を管理します。すべての読み取りに無条件でキャッシュを使うのではなく、業務が許容できる鮮度を判断する必要がある設計です。

CPUの負荷に応じた振り分けも行っています。約26コアから126コアまで能力の異なるホストが混在するため、制御側が各ホストの直近のCPU負荷を見て、ServiceRouterの配分を調整します。地域内の層が飽和した場合に、近隣の健全な処理能力へ切り替える仕組みも備えています。共通化する対象は、単なるリクエストの転送にとどまりません。



導入時の切り戻し手段も参考になります。Metaはサービスやシャードの接頭辞単位で設定を分け、対象トラフィックの割合、対象地域、全体を停止するスイッチを用意しました。トランザクションに必要なクライアント側の管理処理もゲートウェイへ移し、9段階で全トラフィックを移行しています。この移行では信頼性の悪化はなかったと報告していますが、同じ段階数がほかの企業にも適するとは限りません。

ZGatewayは、社外でそのまま導入できる製品として提供されているわけではありません。日本企業にとっての実用的な価値は、既存の基盤で分散している責任を見直す手掛かりにあります。生成AIを含む新しいアプリケーションの追加を検討する際にも、接続管理、過負荷制御、キャッシュの鮮度管理を、各開発チームと共通基盤のどちらが担うかを整理できます。最初の一歩として、接続数が多いサービスを一つ選び、平常時と再接続時の負荷を測定し、許容する追加負荷と切り戻し条件を決めるところから始めるのが現実的です。