EC2 ユースケースおよびアーキパターン

EC2 ユースケースおよびアーキテクチャパターン

この資料は、実務での具体的なシナリオと判断基準を中心に、EC2の活用方法を解説します。

1. Webアプリケーション（スタートアップ → スケーリング）

シナリオ: ECサイトを立ち上げる

状況:

企業: 新規ECサイトを立ち上げたスタートアップ
課題:
- 初期は月間1万PV程度の見込み
- 将来的には100万PV以上を想定
- セール時のトラフィックスパイクに対応したい
- 初期コストは抑えたい

問題のある構成:

問題のあるアプローチ:
- 大規模トラフィックを想定してc6i.4xlargeを最初から起動
- 単一EC2インスタンスのみ（障害時に全停止）
- Auto Scalingなし（手動でスケール）

影響:
- 無駄なコスト（月額 $500以上）
- 単一障害点
- スケーリングの遅延
- 深夜対応の発生

解決策: 段階的スケーリング戦略

フェーズ1（立ち上げ期 〜10万PV/月）:
  構成:
    - ALB: 1台（冗長化）
    - EC2: t3.small × 2台（Reserved Instances）
    - RDS: db.t3.small（Multi-AZ）
  コスト: 月額 $80〜

フェーズ2（成長期 10万〜100万PV/月）:
  構成:
    - ALB: 同上
    - EC2: t3.medium × 2〜5台（Auto Scaling）
      - ベースライン: Reserved Instances × 2
      - スパイク: On-Demand Auto Scaling
    - RDS: db.r6i.large（Multi-AZ）
  コスト: 月額 $300〜

フェーズ3（拡大期 100万PV/月〜）:
  構成:
    - ALB: 同上
    - EC2: c6i.large × 5〜20台（Auto Scaling）
      - ベースライン: Reserved Instances × 5
      - スパイク: Spot Instances混在
    - RDS: db.r6i.2xlarge（Multi-AZ）
    - ElastiCache: redis.r6g.large
  コスト: 月額 $1,000〜

実務での判断ポイント:

初期: t3インスタンスで小さく始める（バースト性能で十分）
Reserved Instances: ベースライン分のみ購入（1年契約で54%削減）
Auto Scaling: CPU使用率60%でスケールアウト開始
Spot Instances: 本番では慎重に（API系は避ける、バッチ処理のみ）

2. バッチ処理（コスト最適化シナリオ）

シナリオ: 毎日の大量データ処理

状況:

企業: SaaS企業のデータ分析基盤
課題:
- 毎晩、数億レコードの集計処理
- 処理時間: 6時間（深夜2時〜8時）
- 処理失敗時の再実行が必要
- コスト削減が急務

問題のある構成:

問題のあるアプローチ:
- c6i.8xlarge × 10台を常時起動（24時間課金）
- On-Demandインスタンスのみ
- 処理完了後も起動したまま

影響:
- 月額コスト: $4,800（18時間分は無駄）
- 年間 $57,600の無駄なコスト

解決策: Spot Instances + スケジューリング

最適化後の構成:
  インスタンス:
    - c6i.8xlarge × 10台（Spot Fleet）
    - 複数インスタンスタイプ混在（c6i, c6a, c5）
    - スケジュール起動（深夜2時）
    - 処理完了後自動停止

  中断対策:
    - チェックポイント保存（S3）
    - Spot中断シグナル検知
    - 自動再開処理

  コスト削減:
    - Spot割引: 最大90%削減
    - 使用時間削減: 6時間のみ課金
    - 月額コスト: $120〜（96%削減）

実装コード例（Auto Scalingスケジュール）:

ScheduledActionScaleOut:
  Type: AWS::AutoScaling::ScheduledAction
  Properties:
    AutoScalingGroupName: !Ref BatchASG
    DesiredCapacity: 10
    Recurrence: "0 2 * * *"  # 毎日深夜2時

ScheduledActionScaleIn:
  Type: AWS::AutoScaling::ScheduledAction
  Properties:
    AutoScalingGroupName: !Ref BatchASG
    DesiredCapacity: 0
    Recurrence: "0 9 * * *"  # 毎日朝9時

実務での判断ポイント:

Spot Instances: バッチ処理には最適（中断しても再実行可能）
混在戦略: 複数インスタンスタイプ指定（中断リスク分散）
チェックポイント: 1時間ごとに保存（中断時の再実行コスト削減）

3. データベースサーバー（RDS vs EC2）

シナリオ: PostgreSQLデータベースの選択

状況:

企業: エンタープライズ業務システム
課題:
- PostgreSQL 15を使用
- 特殊な拡張機能（PostGIS, TimescaleDB）が必要
- RDSでは対応していない拡張機能
- 高可用性が必須

判断基準:

RDSを選ぶべきケース:
  - 標準的なPostgreSQL機能のみ
  - 運用負荷を最小化したい
  - Multi-AZ自動フェイルオーバーが必要
  → RDS推奨

EC2を選ぶべきケース:
  - 特殊な拡張機能が必須
  - カーネルパラメータのカスタマイズが必要
  - ライセンスコスト削減（Oracle BYOL）
  → EC2自前構築

EC2でのPostgreSQL構築例:

構成:
  Primary:
    - インスタンス: r6i.2xlarge
    - EBS: io2 1TB（16,000 IOPS）
    - プライベートサブネット（AZ-a）

  Standby:
    - 同構成（AZ-c）
    - ストリーミングレプリケーション

  バックアップ:
    - EBS スナップショット（日次）
    - WALアーカイブ（S3）
    - Point-in-Time Recovery

  モニタリング:
    - CloudWatch: CPU、メモリ、IOPS
    - PostgreSQL logs → CloudWatch Logs
    - 死活監視 → SNS通知

実務での判断ポイント:

RDS優先: 特別な理由がない限りRDSを選択
EC2選択時: 運用負荷が2〜3倍になることを覚悟
バックアップ: EBSスナップショット + WALアーカイブ両方必須
Multi-AZ: Standbyは同じスペック（フェイルオーバー時のパフォーマンス低下を防ぐ）

4. 機械学習トレーニング（GPU利用シナリオ）

シナリオ: 深層学習モデルのトレーニング

状況:

企業: AI画像認識スタートアップ
課題:
- 大規模画像データセット（100万枚）
- トレーニング時間: GPU 8台で24時間
- 月1回の再トレーニング
- GPUコストが高額

問題のある構成:

問題のあるアプローチ:
- p4d.24xlarge（8x A100 GPU）を常時起動
- On-Demandインスタンス
- 月額コスト: $24,480（24時間 × 30日）

影響:
- 実際のトレーニング: 24時間/月のみ
- 無駄なコスト: 99%（720時間中696時間がアイドル）

解決策: オンデマンドトレーニング + Spot

最適化構成:
  トレーニング時のみ起動:
    - p4d.24xlarge × 1台（Spot Instances）
    - トレーニング期間: 24時間/月
    - S3: データセット保存
    - チェックポイント: 2時間ごと

  コスト削減:
    - Spot割引: 70%削減
    - 使用時間削減: 1/30
    - 月額コスト: $245（99%削減）

実装の流れ:

1. S3からデータセット取得
2. トレーニング開始
3. 2時間ごとにチェックポイント保存（S3）
4. Spot中断シグナル検知時:
   - チェックポイント保存
   - 新しいSpotインスタンスで再開
5. トレーニング完了後:
   - モデル保存（S3）
   - インスタンス自動停止

実務での判断ポイント:

SageMaker Training vs EC2: 小規模ならSageMaker、大規模カスタマイズならEC2
Spot Instances: トレーニングには最適（チェックポイントで中断対応）
分散トレーニング: 8 GPU以上ならマルチノード検討

5. CI/CDビルドサーバー（オンデマンドスケーリング）

シナリオ: GitHubからのビルド自動化

状況:

企業: 開発チーム30名
課題:
- 1日50回のビルド実行
- ピーク時: 同時10ビルド
- ビルド時間: 平均15分
- Jenkins常時起動でコスト高

解決策: Lambda + EC2 オンデマンド起動

構成:
  トリガー:
    - GitHub Webhook → Lambda
    - Lambda: EC2インスタンス起動

  ビルドサーバー:
    - c6i.2xlarge（Spot Instances）
    - Docker + Jenkins エージェント
    - ビルド完了後自動停止

  キャッシュ:
    - EBS: ビルドキャッシュ保存
    - S3: アーティファクト保存

  コスト:
    - 1ビルド: 15分 × $0.20/時間 = $0.05
    - 月50ビルド × 22日 = $55/月

  従来（常時起動）:
    - c6i.2xlarge × 24時間 × 30日 = $4,320/月
    - 削減率: 98.7%

実務での判断ポイント:

GitHub Actions vs 自前Jenkins: 小規模ならGitHub Actions、大規模カスタマイズなら自前
Spot Instances: ビルド中断はGitHubが再実行するので問題なし
キャッシュ戦略: EBS永続化でビルド時間短縮

まとめ: EC2選択の実務判断フロー

スタートアップ期:
  → t3インスタンス + Reserved（小さく始める）
  → Auto Scalingは後から追加

成長期:
  → Reserved（ベースライン） + On-Demand（スパイク）
  → Multi-AZ、Auto Scaling必須

拡大期:
  → Reserved + Spot混在
  → ElastiCache、RDS Read Replica追加

バッチ処理:
  → Spot Instances優先（90%削減）
  → スケジュール起動/停止

ML/GPU:
  → Spot Instances + チェックポイント
  → SageMaker Trainingと比較検討

実務での失敗パターン:

過剰スペック: 最初から大きすぎるインスタンス選択
常時起動: バッチ処理を24時間起動
On-Demandのみ: Spotを避けすぎてコスト高
単一AZ: 障害時の全停止リスク