ストーリー
田
田中VPoE
配置先の判断基準を学んだ。次は実際にワークロードを移行するパターンだ。「6つのR」を知っているか？
あなた
Rehost、Replatform…AWSの移行戦略ですよね
あ
田
田中VPoE
そうだ。ただしマルチクラウドの文脈では、クラウド間の移行という新しい次元が加わる。AWSからGCPへ、AWSからAzureへ — 同じRでもクラウド間移行ならではの考慮点がある
あなた
クラウドサービスの対応関係を理解しておく必要がありそうですね
あ
田
田中VPoE
その通り。それに加えて、データ移行戦略と移行中のサービス継続（カットオーバー戦略）が特に重要になる
7つのRs移行戦略
概要
| 戦略 | 説明 | コスト | リスク | 適用場面 |
|---|---|---|---|---|
| Retain | 現在のクラウドに残す | なし | なし | ロックインが深い、移行メリットが少ない |
| Retire | 廃止する | 低 | 低 | 使われていない、重複している |
| Rehost | そのまま移す（Lift & Shift） | 低〜中 | 低 | コンテナ化済み、VM間移行 |
| Replatform | 少し変えて移す（Lift & Reshape） | 中 | 中 | DB種別変更、マネージドサービス切替 |
| Refactor | 作り直す（Re-architect） | 高 | 高 | クラウドネイティブに最適化 |
| Repurchase | SaaSに置き換える | 中 | 中 | 自前運用からSaaS移行 |
| Relocate | コンテナごと移す | 低 | 低 | Kubernetes間移行 |
マルチクラウド移行での適用
移行パターンの選択フロー:
ワークロード評価
├── コンテナ化済み？
│ ├── Yes → Relocate（K8s間移行）or Rehost
│ └── No → コンテナ化の余地は？
│ ├── あり → Replatform（コンテナ化して移行）
│ └── なし → Refactor or Retain
├── クラウド固有サービスに依存？
│ ├── 低 → Rehost / Relocate
│ ├── 中 → Replatform
│ └── 高 → Refactor or Retain
└── 代替SaaSがある？
├── Yes → Repurchase検討
└── No → 上記フローで判断クラウド間サービス対応表
コンピュート
| 機能 | AWS | GCP | Azure |
|---|---|---|---|
| VM | EC2 | Compute Engine | Virtual Machines |
| コンテナオーケストレーション | ECS/EKS | GKE | AKS |
| サーバーレス | Lambda | Cloud Functions/Run | Azure Functions |
| コンテナ実行 | Fargate | Cloud Run | Container Instances |
データベース
| 機能 | AWS | GCP | Azure |
|---|---|---|---|
| リレーショナル | RDS/Aurora | Cloud SQL/AlloyDB | Azure SQL/Database |
| NoSQL（ドキュメント） | DynamoDB | Firestore | Cosmos DB |
| キャッシュ | ElastiCache | Memorystore | Azure Cache |
| DWH | Redshift | BigQuery | Synapse Analytics |
ストレージ・メッセージング
| 機能 | AWS | GCP | Azure |
|---|---|---|---|
| オブジェクトストレージ | S3 | Cloud Storage | Blob Storage |
| メッセージキュー | SQS | Cloud Tasks/Pub/Sub | Service Bus |
| イベント通知 | SNS/EventBridge | Pub/Sub | Event Grid |
データ移行戦略
移行パターン
| パターン | 方法 | 適用場面 | ダウンタイム |
|---|---|---|---|
| 一括移行 | 一度にすべてのデータを転送 | 小〜中規模、計画停止が許容 | あり（数時間〜数日） |
| 段階的移行 | データを段階的に移行 | 大規模、長期運用 | 最小限 |
| 同期レプリケーション | リアルタイムでデータを複製 | ゼロダウンタイム要件 | なし |
| CDC（Change Data Capture） | 変更分のみを継続的に転送 | 大規模DB、サービス継続 | なし〜最小限 |
データ量別の移行手段
| データ量 | 推奨手段 | 所要時間の目安 |
|---|---|---|
| 〜100GB | ネットワーク転送（API/CLI） | 数時間 |
| 100GB〜10TB | 高帯域ネットワーク転送 | 数日 |
| 10TB〜100TB | 専用線 + 圧縮転送 | 数日〜数週間 |
| 100TB〜 | 物理デバイス転送（Snowball等） | 数週間 |
カットオーバー戦略
3つの戦略
| 戦略 | 説明 | リスク | 適用場面 |
|---|---|---|---|
| ビッグバン | 一度にすべてを切り替え | 高 | 小規模、テストで十分検証済み |
| 段階切替 | サービス/機能単位で段階的に切替 | 中 | 大規模、リスク分散が必要 |
| 並行稼動 | 新旧環境を同時稼動し段階的に移行 | 低 | ミッションクリティカルなサービス |
段階切替の例:
Week 1-2: バッチ処理を移行（影響小）
Week 3-4: データ分析基盤を移行（非リアルタイム）
Week 5-8: APIサービスの一部を移行（カナリア）
Week 9-12: 残りのAPIサービスを移行
Week 13: 旧環境の縮退・廃止まとめ
| ポイント | 内容 |
|---|---|
| 7つのRs | Retain, Retire, Rehost, Replatform, Refactor, Repurchase, Relocate |
| サービス対応 | クラウド間のサービス対応を理解して移行先を決定 |
| データ移行 | データ量と要件に応じた移行パターンを選択 |
| カットオーバー | ビッグバン、段階切替、並行稼動から選択 |
チェックリスト
- 7つのRs移行戦略を理解し、適切に選択できる
- 主要クラウドのサービス対応関係を把握した
- データ移行のパターンと手段を理解した
- カットオーバー戦略の選択基準を理解した
次のステップへ
次は「抽象化レイヤーの設計」を学びます。マルチクラウド環境で共通のインターフェースを提供する抽象化レイヤーの設計方法を身につけましょう。
推定読了時間: 30分