EXERCISE 90分

ストーリー

田中VPoE
ワークロードの分類、配置基準、マイグレーションパターン、抽象化レイヤー — 理論を一通り学んだ。ここで実際のワークロード配置マップを作ってもらう
あなた
Step 1の演習で使ったTechServe社の続きですね
田中VPoE
そうだ。前回の適性診断で「ベストオブブリード + 規制対応」の戦略が決まった。今回はその戦略に基づいて、具体的にどのワークロードをどのクラウドに配置し、どの順序で移行するかを設計してくれ
あなた
配置マップ、移行計画、抽象化レイヤーの設計まで含めるんですね
田中VPoE
その通り。アーキテクトとして、チームが実行できるレベルの計画書を作ってくれ

ミッション概要

項目内容
演習タイトルワークロード配置マップの作成
想定時間90分
成果物ワークロード配置マップ + 移行計画 + 抽象化設計
対象組織TechServe株式会社(Step 1から継続)

前提条件

Step 1の演習で決定した戦略を前提とします。

  • 戦略パターン: ベストオブブリード + 規制対応
  • AWS: メインクラウド(コア業務基盤)
  • GCP: データ分析・AI基盤
  • Azure: Enterprise連携・EU展開

TechServe社の主要ワークロード(12件)

No.ワークロード名現在の構成月間コストビジネス重要度
1ユーザーAPIEKS + Aurora800万円Tier 1
2管理画面EKS + Aurora300万円Tier 2
3決済処理Lambda + DynamoDB400万円Tier 1
4通知サービスLambda + SQS/SNS200万円Tier 2
5ファイルストレージS3 + CloudFront500万円Tier 2
6DWH・分析基盤Redshift + Glue900万円Tier 2
7ログ・監視CloudWatch + OpenSearch400万円Tier 3
8バッチ処理Lambda + Step Functions300万円Tier 3
9認証基盤Cognito + IAM200万円Tier 1
10顧客SSO連携Cognito Federation100万円Tier 1
11ML推論APISageMaker300万円Tier 2
12EU展開(予定)未構築-Tier 1

Mission 1: ワークロード分類と配置先決定

要件

12件のワークロードを4軸で分類し、配置先を決定してください。

  1. 各ワークロードの4軸分類(ビジネス重要度、技術特性、データ特性、変化の頻度)
  2. 配置先の決定(AWS/GCP/Azure)とその理由
  3. 移行戦略(7Rs)の選択
解答例
No.ワークロード重要度技術タイプデータ変化配置先7Rs理由
1ユーザーAPITier 1API機密AWSRetainコア基盤。AWSに最適化済み
2管理画面Tier 2Web社内AWSRetainユーザーAPIと密結合
3決済処理Tier 1API規制対象AWSRetainDynamoDB依存、高い信頼性要件
4通知サービスTier 2バッチ社内AWSRetainSQS/SNS依存、移行メリット小
5ファイルストレージTier 2データストア機密AWSRetain500TBの移行コスト大
6DWH・分析基盤Tier 2分析機密GCPReplatformBigQueryに移行で性能・コスト改善
7ログ・監視Tier 3ストリーミング社内AWS+GCPReplatform統合監視ツールに移行
8バッチ処理Tier 3バッチ社内AWSRetainStep Functions依存が深い
9認証基盤Tier 1API機密AWS→AzureRefactorEntra IDに段階的移行
10顧客SSO連携Tier 1API機密AzureRefactorEntra IDでEnterprise SSO
11ML推論APITier 2API機密GCPReplatformVertex AIに移行
12EU展開Tier 1Web+API規制対象Azure新規構築EUリージョン+GDPR対応

Mission 2: 移行ロードマップの策定

要件

配置先決定に基づき、具体的な移行ロードマップを策定してください。

  1. 4フェーズの移行計画(各フェーズの対象と期間)
  2. 各フェーズのリスクと緩和策
  3. 移行の前提条件と成功基準
解答例

移行ロードマップ

フェーズ期間対象内容
Phase 00-3ヶ月基盤準備Terraform移行、GCP/Azureアカウント構築、ネットワーク接続
Phase 13-9ヶ月分析基盤Redshift→BigQuery移行、ML基盤のVertex AI移行
Phase 29-15ヶ月認証・SSOCognito→Entra ID移行、顧客SSO連携構築
Phase 315-21ヶ月EU展開Azure EUリージョンに新規構築、GDPR対応

各フェーズのリスクと緩和策

フェーズ主要リスク緩和策
Phase 0Terraform変換の不具合段階的変換、既存CFnとの並行運用
Phase 1データ移行中のクエリ不整合並行稼動で検証、段階的切替
Phase 2認証障害による全サービス停止段階的移行、ロールバック手順の整備
Phase 3GDPR要件の見落とし法務チームとの連携、外部監査の実施

成功基準

基準目標
データ整合性移行後のデータ不整合ゼロ
サービス可用性移行期間中のSLA 99.95%以上
コスト移行完了後、月間コスト10%以上削減
パフォーマンス移行後のレイテンシが移行前以下

Mission 3: 抽象化レイヤーの設計

要件

マルチクラウド環境を支える抽象化レイヤーを設計してください。

  1. 抽象化する対象しない対象の判断
  2. IaCレイヤーの設計(ディレクトリ構成)
  3. アプリケーションレイヤーの抽象化インターフェース設計(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分