データ分析

「ノイジーネイバー」問題の解決: シャーディングアーキテクチャがマルチテナントプラットフォームを守る方法

2026年8月21日

Sri Harshini Donthineni

Cloud Data Engineer, Google Cloud

Abdullateef Abdulsalam

Cloud Data Consultant, Google Cloud

Gemini を今すぐお試しください

職場での AI 活用、その入り口に

今すぐ試す

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

マルチテナントの SaaS プロバイダ、社内データプラットフォームを管理する大企業、混合ワークロードのデータ処理を扱う企業のいずれであっても、共有インフラストラクチャ環境を管理するということは、「ノイジーネイバー」という共通の脅威に直面することを意味します。単一のテナントで大量のデータバーストやデータベースインスタンスの障害が発生した場合、環境内の他のテナントをダウンさせ、複数の重要なデータパイプラインにわたって大幅なバックログの蓄積やグローバル規模でのサービスレベル契約（SLA）違反を引き起こす可能性があります。

モノリシックアーキテクチャから、シャーディングを取り入れたハブアンドスポークパターンに移行して、プラットフォームの復元力を確保する方法をご紹介します。

課題: モノリシックのボトルネック

従来の一般的なアーキテクチャでは、すべてのテナントとビジネスドメインのデータを 1 つの巨大なストリームで処理します。パイプラインが統合されているため、特定のデータベーステナントインスタンスでパフォーマンスの問題が発生すると、バックプレッシャーが発生し、プラットフォーム上の他のすべてのテナントのパフォーマンスが低下します。

痛手となる影響:

100% の影響範囲: 1 つのデータベース障害で、すべての処理が停止する可能性があります。
非効率的なスケーリング: 多くの場合、「最悪のケース」のテナントに合わせてリソースをスケールする必要があるため、無駄な支出が多くなります。
SLA の不安定性: 1 つの大規模なテナントがシステム全体を遅延させる可能性がある場合、グローバル規模の SLA を維持することはほぼ不可能です。

解決策: シャーディングによるハブアンドスポークアーキテクチャ

この課題を解決するには、処理をルーティング用の「ハブ」と、分離された実行用の「スポーク」に分けます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_AstMUiw.max-1400x1400.png

1. ハブ: ルーターパイプライン

ハブは、トラフィックコントローラとして機能する軽量の Dataflow ジョブです。統合されたソーストピックから読み取り、テナント ID またはビジネスドメインを解析して、データを分離されたバッファにファンアウトします。これにより、エントリーポイントがシンプルかつ堅牢になります。

2. バッファ: 永続的な分離

ハブとスポークの間に Pub/Sub トピックを導入します。これらは永続的な緩衝器として機能し、低速なダウンストリームシンクが元のソースをバックアップするのを防ぎます。

3. スポーク: 分離された実行

1 本の巨大なパイプラインではなく、複数の小規模な Dataflow インスタンスをデプロイして、ワークロードごとに分類します。

ティア 1（優先度高）: 重要なテナント向けにリソース割り当てを多くした専用パイプライン。
共有ティア: 小規模なテナント向けにパイプラインをグループ化して費用を最適化。
ドメイン固有: コードの複雑さを分離するために、複雑なロジック（異なるビジネスドメインの分離など）に特化したパイプライン。

メリットの比較

機能	モノリシック（従来）	ハブアンドスポーク
フォールトトレランス	1 つの DB の障害ですべてが停止	障害は特定のスポークに限定
影響範囲	100%	5% 未満（1 つのスポークに限定）
リソースのスケーリング	「最悪のケース」を想定してスケーリング	テナントの負荷ごとに独立したスケーリング
メンテナンス	グローバルなアップデートが全体に影響	他のドメインに影響を与えずに 1 つのドメインを更新

実装に関する活用のヒント

このアーキテクチャへの移行は、単に構成図の中でボックスを移動するだけではありません。最大限の安定性を確保するためには、追加で「スポーク」レベルを最適化することが推奨されます。

デッドレターキュー（DLQ）の実装: 単一の SQL 例外によってパイプラインが停止しないようにします。失敗したレコードをストレージ（BigQuery や Google Cloud Storage など）にルーティングして、後で調査します。
厳格な接続プール: データベースには接続制限があります。スレッドセーフなシングルトンパターンを使用し、ワーカーあたりの MaximumPoolSize を低く（1～2 などに）設定して、自動スケーリング中にデータベースを使い果たさないようにします。
非同期 I/O: GroupIntoBatches 変換を使用して書き込みをバッファリングすることで、データベースに起因するレイテンシのトリガーとなることが多い接続オーバーヘッドを削減します。