AWS ステートフルサービスでオンボーディング52日→7日に短縮したハイブリッドマルチテナントアーキテクチャの実践解説

はじめに：セルラアーキテクチャのジレンマ

AWSで大規模なステートフル（状態保持型）サービスを運用されている方であれば、「セルラアーキテクチャ（Cellular Architecture）」という言葉をご存じでしょう。テナントごとにAWSアカウント、VPC、ALB、ECSクラスタを丸ごと割り当てる方式です。分離レベルは確かですが、運用効率は著しく低下します。

実際の広告配信インフラの事例では、衝撃的な数値が報告されています。

• CPU使用率3％、メモリ使用率19％ → サーバが98％以上を「待機」に費やしている
• 新規テナントのオンボーディングに52日（アカウント作成2週間、VPC/ネットワーク3週間、IAM 1週間、結合テスト2週間）
• 同時ライブイベント不可 → トラフィックを別システムに迂回
• ノイジーネイバー問題 → 同じインフラを共有すると性能低下

これらの課題を解決するために登場したのが、ハイブリッドマルチテナントアーキテクチャです。AWS公式ブログで紹介されたこの設計は、テナント分離を維持しながらオンボーディング時間を86％も削減した革新的なものです。

本記事は、AWS Architecture Blogの原文をもとに、実務ですぐに活用できるポイントを抽出してまとめました。

核となる設計：3階層構造

このアーキテクチャの最重要ポイントは、「依存関係の設定とテナントオンボーディングの分離」です。従来はテナントが追加されるたびにVPC、IAM、PrivateLinkを新規作成していましたが、本設計ではTier作成時点ですべてのダウンストリーム接続を事前構成します。

3階層の定義

1. Tier（ティア） – テナントを論理的にグループ化する最上位単位。High TPS / Standard TPS / Low TPSなどトラフィックパターンで分類します。
2. Cell（セル） – AWSアカウント単位の水平スケール単位。1アカウントがENIやVPCエンドポイントの制限に達したら新規セルを追加します。
3. Infra Group（インフラグループ） – 実際のインフラが動作する単位。VPC 1つ、ALB 1つ、ECSクラスタN個で構成されます。

この構造の利点は、2つの独立したスケールレバーを提供することです。

• ALBターゲットグループ上限（約50）に到達 → インフラグループ追加（同一アカウント内）
• AWSアカウント上限（ENI、VPCエンドポイント）に到達 → セル追加（新規アカウント）

Route 53加重ルーティング

すべてのトラフィックはRoute 53の加重ルーティング（Weighted Routing）によって複数のALBに分散されます。テナント側のDNS変更は一切不要で、拡張時にクライアント修正が発生しません。

# Route 53加重レコード作成例（AWS CLI）
aws route53 change-resource-record-sets \
  --hosted-zone-id Z35S****K \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "tier-1.us-east-1.example.com",
          "Type": "A",
          "SetIdentifier": "account-1",
          "Weight": 50,
          "AliasTarget": {
            "HostedZoneId": "Z35S****K",
            "DNSName": "dualstack.account-1-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

テナント専用ECSクラスタ

各テナントは自分だけのECSクラスタを持ちます。クラスタ名にはTier、Cell、Infra Group、テナント識別子をすべて含め、運用中の混乱を防ぎます。

# ECSクラスタ作成例（AWS CLI）
aws ecs create-cluster \
  --cluster-name tier-1-cell-1-ig-1-tenant-a \
  --capacity-providers FARGATE

ECSタスク定義ではテナントIDを環境変数として渡し、アプリケーション起動時に該当テナントのデータのみをロードするようにします。

{
  "family": "tier-1-tenant-a-task",
  "containerDefinitions": [
    {
      "name": "ad-server",
      "image": "your-ecr-image:latest",
      "environment": [
        {
          "name": "TENANT_ID",
          "value": "tenant-a"
        }
      ]
    }
  ]
}

AWS PrivateLinkで共有依存関係を接続

このアーキテクチャの真髄は、Tier作成時にPrivateLinkエンドポイントを事前構築しておくことです。テナントがオンボーディングされると、自動的にこのエンドポイントを経由してダウンストリームサービスにアクセスできます。

# VPCインターフェースエンドポイント作成例
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678

費用はエンドポイントあたり月額約$7.30＋データ転送料($0.01/GB)で、50テナントで共有すればテナントあたり15セント程度と無視できる水準です。

日本市場での適用における考慮点

このアーキテクチャは大規模グローバルサービスに最適化されていますが、日本の環境でも応用可能です。ただし、いくつか注意すべき点があります。

日本での適用コンテキスト

• アカウント制限の緩和：日本でもAWS Organizations + SCPを活用すればアカウント作成の自動化は可能です。ただし、50アカウント以上を運用する企業はまだ稀なため、セル拡張よりもインフラグループ拡張を優先的に検討するのが現実的です。
• PrivateLinkのコスト：東京リージョン(ap-northeast-1)のPrivateLink価格はus-east-1と同程度ですが、トラフィック量が少ない場合はVPC PeeringやTransit Gatewayの方が安価なケースがあります。トラフィックパターンに応じて選択しましょう。
• オンボーディング自動化：52日→7日に短縮した鍵は「設定ベースのオンボーディング」です。日本でもTerraformやAWS CDKでインフラをコード化すれば、同様の効果が得られます。

本技術の限界と注意点

• ステートフルサービス特化：このアーキテクチャはインメモリデータをロードするステートフルサービス（広告配信、ゲームサーバ、リアルタイム分析など）に最適化されています。ステートレスサービスではオーバーエンジニアリングになる可能性があります。
• 運用複雑性：3階層構造はスケーラビリティに優れますが、初期構築と運用に相応の工数がかかります。テナント数が10未満であれば、ECS Service ConnectやApp Meshといったシンプルな代替案を先に検討してください。
• コスト追跡：テナントごとに専用ECSクラスタを使用するため、共有クラスタよりEC2インスタンスコストが増加する可能性があります。ビンパッキング分析により、一部テナントを同一インスタンスに配置する最適化を検討すべきです。

次のステップとしての学習方向

1. AWS Well-Architected Framework – SaaS Lensを読み、マルチテナント設計の原則を学びましょう。
2. TerraformまたはAWS CDKで本アーキテクチャをコード化してみてください。実際にプロビジョニングすることが最良の学習です。
3. Amazon ECS AnywhereやEKSを用いたハイブリッド環境への拡張方法も研究してみるとよいでしょう。

まとめ：52日かかっていた作業を7日にした秘訣

このハイブリッドマルチテナントアーキテクチャが教えてくれる教訓は明確です。

「依存関係の設定をテナントオンボーディングから分離せよ」

PrivateLink接続、IAMロール、リモートキャッシュエンドポイントをTier作成時に事前構成しておけば、オンボーディングは単なる設定変更に変わります。その結果：

• オンボーディング時間：52日→7日（86％削減）
• インフラ設定ステップ：80％削減
• エンジニアリング工数：80％削減
• 機能リリース時間：2～3日→1日

1つのAWSアカウントで最大100テナントを強力な分離レベルで運用できるようになりました。

導入をご検討の際は、小規模なパイロット（Tier 1つ、テナント2～3）から始め、2～4週間のモニタリングを経て段階的に拡張することをお勧めします。

合わせて読みたい記事

• TorchTPU：GoogleがPyTorchをTPUでネイティブ動作させるために開発した秘密兵器
• Python 3.15プレビュー：JIT強化、UTF-8デフォルトエンコーディングなど主要変更

参考資料

• AWS Well-Architected Framework – SaaS Lens
• Amazon ECS Best Practices Guide
• Multi-tenant SaaS Patterns on AWS