multi-cloud-architecture

バンドルされた上流サポート

サポートファイルはスキル相対パスに含まれています。固定されたソース、ライセンス、ハッシュ、インポート時の変更については、UPSTREAM-NOTICE.md を参照してください。

マルチクラウドアーキテクチャ

AWS、Azure、GCP にまたがるアプリケーションを設計するための意思決定フレームワークとパターンです。

このスキルを使用しない場合

• タスクがマルチクラウドアーキテクチャに関係しない場合
• この範囲外の別のドメインやツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 該当するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。

目的

クラウドに依存しないアーキテクチャを設計し、クラウドプロバイダー間でサービスを選択する際に、情報に基づいた判断を行います。

このスキルを使用する場合

• マルチクラウド戦略を設計する
• クラウドプロバイダー間で移行する
• 特定のワークロード向けにクラウドサービスを選択する
• クラウドに依存しないアーキテクチャを実装する
• プロバイダー間のコストを最適化する

サービスの行は幅広いユースケースをまとめたものであり、差し替えてそのまま使える同等品を示すものではありません。Azure SQL Database は PostgreSQL/MySQL ではなく、Event Hubs の Kafka 互換性は Kafka の全機能を備えているわけではなく、S3 互換 API の動作もさまざまです。サービスの現在の提供状況、リージョンやコンプライアンス上の制約、実際のアプリケーション契約を確認してください。マルチクラウドでのレプリケーションでは、一貫性と競合、RPO/RTO、ID、フェイルバックを明示的に設計する必要があります。地理的に配置しただけでは、データ主権への準拠は保証されません。導入を決定する前に、並行稼働、ネットワークとデータ転送料、バックアップ、チームにかかるコストを測定してください。以下の 30～70％の削減幅は過去の事例に基づく参考値であり、見積もりでも、コミットメントの購入を推奨するものでもありません。

クラウドサービスの比較

コンピューティングサービス

AWS	Azure	GCP	ユースケース
EC2	Virtual Machines	Compute Engine	IaaS VM
ECS	Container Instances	Cloud Run	コンテナ
EKS	AKS	GKE	Kubernetes
Lambda	Functions	Cloud Functions	サーバーレス
Fargate	Container Apps	Cloud Run	マネージドコンテナ

ストレージサービス

AWS	Azure	GCP	ユースケース
S3	Blob Storage	Cloud Storage	オブジェクトストレージ
EBS	Managed Disks	Persistent Disk	ブロックストレージ
EFS	Azure Files	Filestore	ファイルストレージ
Glacier	Archive Storage	Archive Storage	コールドストレージ

データベースサービス

AWS	Azure	GCP	ユースケース
RDS	SQL Database	Cloud SQL	マネージド SQL
DynamoDB	Cosmos DB	Firestore	NoSQL
Aurora	PostgreSQL/MySQL	Cloud Spanner	分散 SQL
ElastiCache	Cache for Redis	Memorystore	キャッシュ

参考： 完全な比較については references/service-comparison.md を参照してください。

マルチクラウドパターン

パターン 1：単一プロバイダーと DR

• 主要なワークロードを 1 つのクラウドで実行する
• 別のクラウドに災害復旧環境を用意する
• クラウド間でデータベースをレプリケーションする
• フェイルオーバーを自動化する

パターン 2：ベストオブブリード

• 各プロバイダーから最適なサービスを使用する
• AI/ML は GCP で実行する
• エンタープライズアプリは Azure で実行する
• 汎用コンピューティングは AWS で実行する

パターン 3：地理的分散

• 最寄りのクラウドリージョンからユーザーにサービスを提供する
• データ主権への準拠
• グローバル負荷分散
• リージョン間のフェイルオーバー

パターン 4：クラウドに依存しない抽象化

• コンピューティングに Kubernetes を使用する
• データベースに PostgreSQL を使用する
• S3 互換ストレージ（MinIO）
• オープンソースツール

クラウドに依存しないアーキテクチャ

クラウドネイティブな代替サービスを使用する

• コンピューティング： Kubernetes（EKS/AKS/GKE）
• データベース： PostgreSQL/MySQL（RDS/SQL Database/Cloud SQL）
• メッセージキュー： Apache Kafka（MSK/Event Hubs/Confluent）
• キャッシュ： Redis（ElastiCache/Azure Cache/Memorystore）
• オブジェクトストレージ： S3 互換 API
• モニタリング： Prometheus/Grafana
• サービスメッシュ： Istio/Linkerd

抽象化レイヤー

Application Layer
    ↓
Infrastructure Abstraction (Terraform)
    ↓
Cloud Provider APIs
    ↓
AWS / Azure / GCP

コスト比較

コンピューティング料金の要因

• AWS： オンデマンド、リザーブド、スポット、Savings Plans
• Azure： 従量課金制、リザーブド、スポット
• GCP： オンデマンド、確約利用、プリエンプティブル

コスト最適化戦略

1. 予約済み／コミット済みのキャパシティを使用する（30～70％のコスト削減）
2. スポット／プリエンプティブルインスタンスを活用する
3. リソースのサイズを適正化する
4. 変動するワークロードにはサーバーレスを使用する
5. データ転送コストを最適化する
6. ライフサイクルポリシーを導入する
7. コスト配分タグを使用する
8. クラウドコストツールで監視する

参考： references/multi-cloud-patterns.md を参照してください。

移行戦略

フェーズ 1：評価

• 現在のインフラストラクチャを棚卸しする
• 依存関係を特定する
• クラウドとの互換性を評価する
• コストを見積もる

フェーズ 2：パイロット

• パイロット対象のワークロードを選定する
• 移行先のクラウドに実装する
• 十分にテストする
• 得られた知見を文書化する

フェーズ 3：移行

• ワークロードを段階的に移行する
• 2つの環境で並行稼働する期間を設ける
• パフォーマンスを監視する
• 機能を検証する

フェーズ 4：最適化

• リソースのサイズを適正化する
• クラウドネイティブサービスを導入する
• コストを最適化する
• セキュリティを強化する

ベストプラクティス

1. インフラストラクチャをコードとして管理する（Terraform/OpenTofu）
2. デプロイ用の CI/CD パイプラインを導入する
3. クラウド間での障害を想定して設計する
4. 可能な場合はマネージドサービスを使用する
5. 包括的な監視を導入する
6. コスト最適化を自動化する
7. セキュリティのベストプラクティスに従う
8. クラウド固有の設定を文書化する
9. 災害復旧手順をテストする
10. 複数のクラウドについてチームをトレーニングする

参考ファイル

• references/service-comparison.md - サービスの完全な比較
• references/multi-cloud-patterns.md - アーキテクチャパターン

関連スキル

• terraform-module-library - IaC の実装用
• cost-optimization - コスト管理用
• hybrid-cloud-networking - 接続性用

制限事項

• このスキルは、タスクが上記の説明された範囲に明確に該当する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。