ストーリー
田
田中VPoE
ワークロードの分類、配置基準、マイグレーションパターン、抽象化レイヤー — 理論を一通り学んだ。ここで実際のワークロード配置マップを作ってもらう
あなた
Step 1の演習で使ったTechServe社の続きですね
あ
田
田中VPoE
そうだ。前回の適性診断で「ベストオブブリード + 規制対応」の戦略が決まった。今回はその戦略に基づいて、具体的にどのワークロードをどのクラウドに配置し、どの順序で移行するかを設計してくれ
あなた
配置マップ、移行計画、抽象化レイヤーの設計まで含めるんですね
あ
田
田中VPoE
その通り。アーキテクトとして、チームが実行できるレベルの計画書を作ってくれ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | ワークロード配置マップの作成 |
| 想定時間 | 90分 |
| 成果物 | ワークロード配置マップ + 移行計画 + 抽象化設計 |
| 対象組織 | TechServe株式会社(Step 1から継続) |
前提条件
Step 1の演習で決定した戦略を前提とします。
- 戦略パターン: ベストオブブリード + 規制対応
- AWS: メインクラウド(コア業務基盤)
- GCP: データ分析・AI基盤
- Azure: Enterprise連携・EU展開
TechServe社の主要ワークロード(12件)
| No. | ワークロード名 | 現在の構成 | 月間コスト | ビジネス重要度 |
|---|
| 1 | ユーザーAPI | EKS + Aurora | 800万円 | Tier 1 |
| 2 | 管理画面 | EKS + Aurora | 300万円 | Tier 2 |
| 3 | 決済処理 | Lambda + DynamoDB | 400万円 | Tier 1 |
| 4 | 通知サービス | Lambda + SQS/SNS | 200万円 | Tier 2 |
| 5 | ファイルストレージ | S3 + CloudFront | 500万円 | Tier 2 |
| 6 | DWH・分析基盤 | Redshift + Glue | 900万円 | Tier 2 |
| 7 | ログ・監視 | CloudWatch + OpenSearch | 400万円 | Tier 3 |
| 8 | バッチ処理 | Lambda + Step Functions | 300万円 | Tier 3 |
| 9 | 認証基盤 | Cognito + IAM | 200万円 | Tier 1 |
| 10 | 顧客SSO連携 | Cognito Federation | 100万円 | Tier 1 |
| 11 | ML推論API | SageMaker | 300万円 | Tier 2 |
| 12 | EU展開(予定) | 未構築 | - | Tier 1 |
Mission 1: ワークロード分類と配置先決定
要件
12件のワークロードを4軸で分類し、配置先を決定してください。
- 各ワークロードの4軸分類(ビジネス重要度、技術特性、データ特性、変化の頻度)
- 配置先の決定(AWS/GCP/Azure)とその理由
- 移行戦略(7Rs)の選択
解答例
| No. | ワークロード | 重要度 | 技術タイプ | データ | 変化 | 配置先 | 7Rs | 理由 |
|---|
| 1 | ユーザーAPI | Tier 1 | API | 機密 | 高 | AWS | Retain | コア基盤。AWSに最適化済み |
| 2 | 管理画面 | Tier 2 | Web | 社内 | 中 | AWS | Retain | ユーザーAPIと密結合 |
| 3 | 決済処理 | Tier 1 | API | 規制対象 | 低 | AWS | Retain | DynamoDB依存、高い信頼性要件 |
| 4 | 通知サービス | Tier 2 | バッチ | 社内 | 中 | AWS | Retain | SQS/SNS依存、移行メリット小 |
| 5 | ファイルストレージ | Tier 2 | データストア | 機密 | 低 | AWS | Retain | 500TBの移行コスト大 |
| 6 | DWH・分析基盤 | Tier 2 | 分析 | 機密 | 中 | GCP | Replatform | BigQueryに移行で性能・コスト改善 |
| 7 | ログ・監視 | Tier 3 | ストリーミング | 社内 | 低 | AWS+GCP | Replatform | 統合監視ツールに移行 |
| 8 | バッチ処理 | Tier 3 | バッチ | 社内 | 低 | AWS | Retain | Step Functions依存が深い |
| 9 | 認証基盤 | Tier 1 | API | 機密 | 低 | AWS→Azure | Refactor | Entra IDに段階的移行 |
| 10 | 顧客SSO連携 | Tier 1 | API | 機密 | 低 | Azure | Refactor | Entra IDでEnterprise SSO |
| 11 | ML推論API | Tier 2 | API | 機密 | 中 | GCP | Replatform | Vertex AIに移行 |
| 12 | EU展開 | Tier 1 | Web+API | 規制対象 | 高 | Azure | 新規構築 | EUリージョン+GDPR対応 |
Mission 2: 移行ロードマップの策定
要件
配置先決定に基づき、具体的な移行ロードマップを策定してください。
- 4フェーズの移行計画(各フェーズの対象と期間)
- 各フェーズのリスクと緩和策
- 移行の前提条件と成功基準
解答例
移行ロードマップ
| フェーズ | 期間 | 対象 | 内容 |
|---|
| Phase 0 | 0-3ヶ月 | 基盤準備 | Terraform移行、GCP/Azureアカウント構築、ネットワーク接続 |
| Phase 1 | 3-9ヶ月 | 分析基盤 | Redshift→BigQuery移行、ML基盤のVertex AI移行 |
| Phase 2 | 9-15ヶ月 | 認証・SSO | Cognito→Entra ID移行、顧客SSO連携構築 |
| Phase 3 | 15-21ヶ月 | EU展開 | Azure EUリージョンに新規構築、GDPR対応 |
各フェーズのリスクと緩和策
| フェーズ | 主要リスク | 緩和策 |
|---|
| Phase 0 | Terraform変換の不具合 | 段階的変換、既存CFnとの並行運用 |
| Phase 1 | データ移行中のクエリ不整合 | 並行稼動で検証、段階的切替 |
| Phase 2 | 認証障害による全サービス停止 | 段階的移行、ロールバック手順の整備 |
| Phase 3 | GDPR要件の見落とし | 法務チームとの連携、外部監査の実施 |
成功基準
| 基準 | 目標 |
|---|
| データ整合性 | 移行後のデータ不整合ゼロ |
| サービス可用性 | 移行期間中のSLA 99.95%以上 |
| コスト | 移行完了後、月間コスト10%以上削減 |
| パフォーマンス | 移行後のレイテンシが移行前以下 |
Mission 3: 抽象化レイヤーの設計
要件
マルチクラウド環境を支える抽象化レイヤーを設計してください。
- 抽象化する対象としない対象の判断
- IaCレイヤーの設計(ディレクトリ構成)
- アプリケーションレイヤーの抽象化インターフェース設計(2つ以上)
解答例
抽象化の判断
| 対象 | 抽象化する? | 理由 |
|---|
| IaC(Terraform) | する | 全クラウドを統一管理。最優先 |
| K8s マニフェスト | する | EKS/GKE/AKSで共通利用 |
| オブジェクトストレージ | する | S3/GCS/Blobの共通インターフェース |
| 監視・ログ | する | Datadog/Grafanaで統合 |
| DynamoDBアクセス | しない | AWS残留、固有機能を活用 |
| BigQuery分析 | しない | GCP固有の強みを最大化 |
| Entra ID認証 | しない | Azure固有のEnterprise機能を活用 |
IaCディレクトリ構成
terraform/
├── modules/
│ ├── kubernetes/
│ │ ├── aws/ # EKS
│ │ ├── gcp/ # GKE
│ │ └── azure/ # AKS
│ ├── network/
│ │ ├── aws/ # VPC
│ │ ├── gcp/ # VPC
│ │ └── azure/ # VNet
│ └── monitoring/
│ └── datadog/ # 全クラウド共通
├── environments/
│ ├── production/
│ │ ├── aws-ap-northeast-1/
│ │ ├── gcp-asia-northeast1/
│ │ └── azure-westeurope/
│ └── staging/
├── shared/
│ ├── variables.tf
│ └── providers.tf
└── Makefile
アプリケーション層の抽象化
// 1. オブジェクトストレージ
interface ObjectStorage {
put(bucket: string, key: string, data: Buffer): Promise<void>;
get(bucket: string, key: string): Promise<Buffer>;
delete(bucket: string, key: string): Promise<void>;
generatePresignedUrl(bucket: string, key: string, ttl: number): Promise<string>;
}
// 2. シークレット管理
interface SecretManager {
getSecret(name: string): Promise<string>;
putSecret(name: string, value: string): Promise<void>;
rotateSecret(name: string): Promise<void>;
}
達成度チェック
| 観点 | 達成基準 |
|---|
| ワークロード分類 | 4軸で体系的に分類され、分類根拠が明確 |
| 配置決定 | 戦略パターンに基づいた合理的な配置先選定 |
| 移行計画 | フェーズ分けされ、リスク対策が含まれた実行可能な計画 |
| 抽象化設計 | 抽象化の要否判断が合理的で、具体的な設計が示されている |
| 整合性 | 配置決定、移行計画、抽象化設計の間に矛盾がない |
| 実現可能性 | チームのスキルとリソースを考慮した現実的な計画 |
推定所要時間: 90分