シェアードナッシング

シェアードナッシングとは

シェアードナッシング (Shared-Nothing Architecture) は、各ノードが独立した CPU、メモリ、ストレージを持ち、ノード間で状態を共有しないアーキテクチャである。ノードの追加だけで水平スケールでき、単一障害点がない。

シェアードナッシング vs シェアードエブリシング

観点	シェアードナッシング	シェアードエブリシング
状態の共有	なし	共有ストレージ/メモリ
スケーラビリティ	高い (ノード追加)	限定的 (共有リソースがボトルネック)
障害の影響	局所的	全体に波及
例	Lambda, DynamoDB	共有 DB の RDS

Lambda はシェアードナッシング

リクエスト 1 → Lambda インスタンス A (独立したメモリ)
リクエスト 2 → Lambda インスタンス B (独立したメモリ)
リクエスト 3 → Lambda インスタンス C (独立したメモリ)

各 Lambda インスタンスは独立した実行環境を持ち、メモリを共有しない。状態は DynamoDB や S3 に外部化する。

DynamoDB のパーティション

DynamoDB テーブル:
  パーティション A (独立したストレージ + コンピュート)
  パーティション B (独立したストレージ + コンピュート)
  パーティション C (独立したストレージ + コンピュート)

各パーティションが独立してリクエストを処理するため、パーティション数に比例してスループットがスケールする。

設計原則

アプリケーションに状態を持たないステートレス設計が基本で、状態は DB、キャッシュ、S3 に外部化する。同じリクエストを何度処理しても同じ結果になる冪等性を確保し、ノード間の依存を排除して独立性を保つ。

シェアードナッシングが難しいケース

ケース	理由	対策
セッション管理	ユーザーの状態を保持	DynamoDB or ElastiCache に外部化
ファイルアップロード	ローカルディスクに保存	S3 に直接アップロード
WebSocket	接続状態を保持	API Gateway WebSocket + DynamoDB

Twelve-Factor App との関係

Twelve-Factor App の第 6 原則「プロセスはステートレス」はシェアードナッシングの実践。プロセスのメモリやファイルシステムに状態を保存せず、外部サービスに委譲する。

シェアードナッシングについては関連書籍でも詳しく扱われている。