スケーリングを見据えた技術選定: モノリスからマイクロサービスへの段階的移行

はじめに

プロダクトの成長に伴い、システムのスケーリングは避けて通れない課題です。しかし、最初からマイクロサービスで設計すべきでもなく、モノリスで限界を迎えてから慌てるのも問題です。本記事では、段階的なスケーリング戦略と、各段階での技術選定の判断基準を解説します。

身近な例えで理解するスケーリング

スケーリングは「お店の拡大」に似ています。

• フェーズ1（個人経営） = モノリス。1人で全部やる。効率は良いが、キャパシティに限界がある
• フェーズ2（従業員を雇う） = 垂直スケーリング。より大きなサーバーを使う
• フェーズ3（支店を出す） = 水平スケーリング。同じ構成のサーバーを増やす
• フェーズ4（専門店に分割） = マイクロサービス化。機能ごとに独立したサービスに分割
• フェーズ5（フランチャイズ展開） = グローバル分散。世界中にサービスを展開

スケーリングの段階

段階一覧

Stage 0: シンプルモノリス（0-100ユーザー）

アーキテクチャ

[ユーザー]
    |
    v
[Next.js / Rails / Django]
    |
    v
[PostgreSQL]
    |
    v
[S3 (ファイル保存)]

技術選定のポイント

この段階でやるべきこと

• コア機能の開発に集中する
• ユーザーフィードバックを集める
• パフォーマンスモニタリングの基盤を作る（Sentry、PostHog等）

この段階でやるべきでないこと

• マイクロサービス化
• 複数DBの導入
• Kubernetes
• カスタムインフラの構築

Stage 1: モノリス + キャッシュ（100-10,000ユーザー）

アーキテクチャ

[ユーザー]
    |
    v
[Next.js / Rails / Django]
    |
    +-- [Redis (キャッシュ)]
    |   |-- セッション管理
    |   |-- 頻繁にアクセスされるデータのキャッシュ
    |   +-- レートリミット
    |
    v
[PostgreSQL]
    |
    v
[S3 + CloudFront (CDN)]

キャッシュ戦略

キャッシュ導入の効果

[キャッシュなし]
DBクエリ: 1,000回/秒
レスポンスタイム: 200ms

[キャッシュあり（ヒット率80%）]
DBクエリ: 200回/秒（80%削減）
レスポンスタイム: 20ms（90%短縮）

この段階での判断基準

Stage 2: Read Replica + CDN（10,000-100,000ユーザー）

アーキテクチャ

[ユーザー]
    |
    v
[CloudFront (CDN)]
    |
    v
[ALB (ロードバランサー)]
    |
    +--------+--------+
    |        |        |
[App 1]  [App 2]  [App 3]  (水平スケーリング)
    |        |        |
    +--------+--------+
             |
    +--------+--------+
    |                 |
[Redis           [PostgreSQL
 Cluster]         Primary]
                      |
              +-------+-------+
              |               |
         [Read Replica 1] [Read Replica 2]

読み書き分離

注意: レプリケーション遅延

Read Replicaにはミリ秒〜数秒の遅延がある。ユーザーが投稿した直後に「自分の投稿が見えない」という問題が発生し得る。対策として、自分自身のデータはPrimaryから読み取る（Read Your Own Writes）パターンを採用する。

水平スケーリングの条件

アプリケーションを水平スケーリングするには、アプリケーションがステートレスである必要がある。

Stage 3: モジュラーモノリス / サービス分離開始（100,000-1,000,000ユーザー）

アーキテクチャ

[ユーザー]
    |
    v
[CloudFront + WAF]
    |
    v
[ALB]
    |
    +-- [API サーバー群 (モジュラーモノリス)]
    |   |
    |   +-- [ユーザーモジュール]
    |   +-- [商品モジュール]
    |   +-- [注文モジュール]
    |   +-- [通知モジュール] --> 分離候補
    |   +-- [検索モジュール] --> 分離候補
    |
    +-- [非同期処理ワーカー]
    |   |
    |   +-- [SQS] --> [Lambda / ECS Task]
    |
    v
[データストア]
    +-- [Aurora PostgreSQL (Primary + Replica x 2)]
    +-- [ElastiCache Redis Cluster]
    +-- [OpenSearch (検索)]
    +-- [S3 + CloudFront]

モジュラーモノリスとは

モジュラーモノリスは、単一のアプリケーション内で機能をモジュールに分割し、モジュール間の依存関係を厳密に管理するアーキテクチャ。

[モノリス vs モジュラーモノリス vs マイクロサービス]

モノリス:
+---------------------------+
| すべてが密結合            |
| ユーザー←→商品←→注文←→通知 |
+---------------------------+

モジュラーモノリス:
+---------------------------+
| [ユーザー] | [商品]       |
|     ↓ API  |    ↓ API     |
| [注文]     | [通知]       |
| モジュール間はAPIで通信    |
+---------------------------+
同一プロセス内だが、モジュール間の境界が明確

マイクロサービス:
[ユーザー]  [商品]  [注文]  [通知]
各サービスが独立したプロセス/コンテナ

サービス分離の判断基準

最初に分離する候補

Stage 4: マイクロサービス（1,000,000-10,000,000ユーザー）

アーキテクチャ

[ユーザー]
    |
    v
[CloudFront + WAF]
    |
    v
[API Gateway / BFF]
    |
    +-- [ユーザーサービス] --> [Aurora (Users DB)]
    |
    +-- [商品サービス] --> [Aurora (Products DB)]
    |
    +-- [注文サービス] --> [Aurora (Orders DB)]
    |                        |
    |                        +-- [SQS] --> [在庫サービス]
    |
    +-- [検索サービス] --> [OpenSearch]
    |
    +-- [通知サービス] --> [SQS] --> [SES/SNS]
    |
    +-- [分析サービス] --> [Redshift/BigQuery]
    |
    v
[共通基盤]
    +-- [Redis Cluster (キャッシュ)]
    +-- [Kafka (イベントストリーミング)]
    +-- [Jaeger (分散トレーシング)]
    +-- [Prometheus + Grafana (監視)]

マイクロサービスで必要になるインフラ

データベースの分割（Database per Service）

Stage 5: グローバル分散（10,000,000+ユーザー）

アーキテクチャ

[グローバルユーザー]
    |
    v
[Route 53 (Geo DNS)]
    |
    +-- [東京リージョン]
    |   +-- [CloudFront]
    |   +-- [ECS/EKS クラスター]
    |   +-- [Aurora Global Database (Primary)]
    |   +-- [ElastiCache]
    |
    +-- [北米リージョン (us-east-1)]
    |   +-- [CloudFront]
    |   +-- [ECS/EKS クラスター]
    |   +-- [Aurora Global Database (Replica)]
    |   +-- [ElastiCache]
    |
    +-- [欧州リージョン (eu-west-1)]
        +-- [CloudFront]
        +-- [ECS/EKS クラスター]
        +-- [Aurora Global Database (Replica)]
        +-- [ElastiCache]

グローバル分散の課題

データベースシャーディング

シャーディングとは

データベースのデータを複数のDB（シャード）に分散して格納する技術。1つのDBでは処理しきれないデータ量/リクエスト量に対応する。

シャーディング戦略

シャーディング導入のタイミング

[シャーディング導入の判断]

以下の全てを試した後に検討する:
1. クエリの最適化（インデックス、クエリ改善）
2. Read Replicaの追加
3. キャッシュの強化
4. 接続プーリングの最適化
5. パーティショニング（テーブル分割）

それでもDBがボトルネックなら → シャーディング検討

CDNとキャッシュ戦略

CDN活用のレベル

キャッシュ戦略の全体像

[リクエストの流れ]

[ブラウザキャッシュ] (TTL: 5分)
    ↓ miss
[CDN (CloudFront)] (TTL: 1-5分)
    ↓ miss
[アプリケーションキャッシュ (Redis)] (TTL: 5-60分)
    ↓ miss
[データベース]

各段階でのコスト概算

スケーリングのアンチパターン

判断フローチャート

[スケーリング判断]
    |
    v
[現在のボトルネックは?]
    |
    +-- DBの読み取り
    |   → Redis キャッシュ、Read Replica
    |
    +-- DBの書き込み
    |   → 非同期処理（SQS）、最終的にはシャーディング
    |
    +-- アプリサーバーのCPU/メモリ
    |   → 水平スケーリング（インスタンス追加）
    |
    +-- 静的コンテンツの配信
    |   → CDN（CloudFront）
    |
    +-- 開発チームの生産性
    |   → モジュラーモノリス、サービス分離
    |
    +-- グローバルなレイテンシ
        → マルチリージョン展開

まとめ

スケーリングの鉄則

各段階の推奨アクション

大半のプロダクトはStage 2-3で十分。Stage 4以上が必要になるのは、グローバル展開する大規模サービスのみ。過度なスケーリング設計は避け、プロダクトの成長に合わせて段階的に進化させることが最も効率的なアプローチである。

参考リンク

• Martin Fowler: MonolithFirst
• AWS Well-Architected Framework
• Sam Newman: Building Microservices
• High Scalability
• AWS Architecture Blog