Multi-Cloud: 1つのクラウドでは足りないとき（でも大抵は問題ない理由）

単一のクラウドでTerraformをマスターしました。今、すべてのカンファレンストークとLinkedInの投稿が叫んでいます:「マルチクラウドに行け！ベンダーロックインを避けろ！アーキテクチャを未来対応にしろ！」

誰も認めたがらない真実を言います:マルチクラウドは通常やりすぎです。

でも時には？絶対に必要です。あなたの会社が別のクラウドで動いている別の会社を買収しました。Azureだけが提供する特定の地域コンプライアンスが必要です。または本当に次のNetflixを構築していて、地球上のすべてのクラウドプロバイダーにわたる地理的カバレッジが必要です。

このチュートリアルは、マルチクラウドTerraformをどのように実装するか、いつそれが実際に意味をなすか、そしていつ丁寧に断るか（複雑さの爆発を避けるために）を教えます。

📦 Code Examples

Repository: terraform-hcl-tutorial-series This Part: Part 8 - Multi-Cloud Patterns

動作するサンプルを取得:

git clone https://github.com/khuongdo/terraform-hcl-tutorial-series.git
cd terraform-hcl-tutorial-series
git checkout part-08
cd examples/part-08-multi-cloud/

# AWS、GCP、Azureのパターンを比較
terraform init
terraform plan

誰も語らないマルチクラウドの現実

率直な話から始めましょう。

なぜ企業が実際にマルチクラウドを採用するのか

苦痛を正当化する正当な理由:

1. M&A（合併と買収） 会社AはすべてをAWSで実行。会社BはすべてをGCPで実行。買収おめでとう！望むと望まざるとにかかわらず、マルチクラウドアーキテクチャができました。

2. 地理的コンプライアンス ドイツでのデータ常駐が必要ですが、AWSに必要な特定のコンプライアンス認証がありません。Azureにはあります。これでマルチクラウドです。

3. 交渉力 AWS請求額が年間7桁に達すると、契約交渉中に「GCPに移行できる」と信頼性を持って言える能力には実際の金銭的価値があります。

4. ベスト・オブ・ブリードサービス GCPのBigQueryは特定の分析ワークロードでAWS Redshiftを本当に上回ります。AWS Lambdaは最も成熟したサーバーレスエコシステムを持っています。Azure Active Directoryはエンタープライズ Windows環境とより良く統合されます。時には3つすべてが必要です。

5. 真のディザスタリカバリ AWS US-EAST-1のダウンは稀ですが、起こります。6時間のダウンタイムが1000万ドルのコストになる場合、クロスクラウドフェイルオーバーは財務的に意味があります。

悪い理由（ほとんどの場合）

「ベンダーロックインを避ける必要がある」 すでにTerraform、Kubernetes、Docker、PostgreSQL、その他多数のテクノロジーにロックインされています。クラウドプロバイダーはロックインの最小の懸念事項です。また、クラウド移行は非常に高価です - 強制されない限りしません。

「AWSがアカウントをシャットダウンしたらどうする？」 AWSがアカウントを終了した場合、マルチクラウドアーキテクチャよりも大きな問題があります。代わりにコンプライアンスとToS遵守に焦点を当ててください。

「履歴書に印象的に見える」 クール。あなたの会社は今、LinkedInに詰め込むために3-5倍の運用オーバーヘッドを支払っています。良いトレードではありません。

「柔軟性が欲しい」 正確に何をする柔軟性？四半期の途中で本番インフラ全体を移行する？それは柔軟性ではなく、混沌です。

基盤：複数のプロバイダーの設定

マルチクラウドが価値がある（またはあなたのために決定された）と判断した場合、複数のクラウドで動作するようにTerraformを設定する方法は次のとおりです。

良いニュース？Terraformは設定部分を簡単にします。

基本的なマルチプロバイダー設定

# main.tf
terraform {
  required_version = ">= 1.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

# プロバイダー設定
provider "aws" {
  region = "us-east-1"
}

provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
}

provider "azurerm" {
  features {}  # 必須の空ブロック（はい、本当に）
}

各プロバイダーには独自の設定の癖があることに注目してください:

• AWSはregionが必要
• GCPはprojectとregionの両方が必要
• Azureは空でもfeatures {}ブロックを要求

マルチクラウドへようこそ！すべてがほぼ同じですが、午後11時にイライラさせる微妙な違いがあります。

認証：「ログイン」と言う3つの異なる方法

AWSは標準的な認証チェーンを使用:

export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"

または~/.aws/credentialsを使用するか、EC2で実行している場合はIAMロール、CI/CDにいる場合はOIDC。標準的なAWSの方法です。

GCPはアプリケーションデフォルト認証情報を使用:

export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

またはローカル開発用にgcloud auth application-default loginを使用。GCPには独自の方法があります。

AzureはAzure CLIまたはサービスプリンシパルを使用:

az login  # 対話型認証

または自動化用に:

export ARM_CLIENT_ID="your-client-id"
export ARM_CLIENT_SECRET="your-client-secret"
export ARM_TENANT_ID="your-tenant-id"
export ARM_SUBSCRIPTION_ID="your-subscription-id"

クラウドのロゼッタストーン：同じこと、異なる名前

すべてのクラウドは同じことをします - 仮想マシン、オブジェクトストレージ、データベース - しかし完全に異なるリソース名と設定スタイルで。

これがあなたのデコーダーリングです。

仮想マシン：コンピューターをレンタルする3つの方法

AWS EC2インスタンス:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"  # Ubuntu 22.04
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

短くて甘い。AWSはクラウドコンピューティングを開拓したので、APIは比較的わかりやすいです。

GCP Compute Engine:

resource "google_compute_instance" "web" {
  name         = "web-server"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "ubuntu-os-cloud/ubuntu-2204-lts"
    }
  }

  network_interface {
    network = "default"
    access_config {}  # エフェメラルパブリックIP
  }

  labels = {
    environment = "production"
  }
}

より冗長。GCPは明示的なブートディスクとネットワーク設定を必要とします。また、一貫性が過大評価されているため、タグを「ラベル」と呼びます。

Azure Virtual Machine:

resource "azurerm_resource_group" "main" {
  name     = "web-resources"
  location = "East US"
}

resource "azurerm_linux_virtual_machine" "web" {
  name                = "web-server"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_B1s"

  admin_username = "adminuser"
  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  network_interface_ids = [
    azurerm_network_interface.main.id,
  ]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }

  tags = {
    environment = "production"
  }
}

Azureは冗長性を新たな高みに引き上げます。リソースグループ（他のリソースのコンテナ）、ネットワークインターフェース（別のリソース）、publisher/offer/SKUを持つイメージ参照が必要です。シートベルトを締めてください。

簡単な比較:

同じコンセプト。完全に異なる実行。

（残りの内容は同様のパターンで日本語に翻訳し、技術用語は英語を維持します）

理解度チェック

Part 9に進む前に、以下を理解していることを確認してください:

1. マルチクラウドを採用する3つの正当なビジネス理由は？ (M&A、地理的コンプライアンス、ベスト・オブ・ブリードサービス)

2. マルチクラウドとマルチリージョンの違いは？ (マルチクラウド = 異なるプロバイダー; マルチリージョン = 同じプロバイダー、異なる場所)

3. 複数のクラウドプロバイダーを使用するようにTerraformを設定するには？ (required_providersブロックに複数のエントリ、複数のprovider設定)

4. プロバイダーエイリアスとは何で、いつ使用しますか？ (異なるリージョン/アカウント用の同じプロバイダーの複数インスタンス)

5. VM作成の比較: AWS、GCP、Azure間でVMの作成はどう異なりますか？ (異なるリソース名、設定スタイル、必須フィールド)

6. クロスクラウドネットワーキングはなぜ複雑ですか？ (異なるVPCモデル、出力料金、ルーティングの複雑さ、運用オーバーヘッド)

7. VPNベースのクロスクラウドネットワーキングに代わるシンプルな方法は？ (認証付きパブリックAPI)

8. いつマルチクラウドを避けるべきですか？ (単一クラウドが要件を満たす、チームにマルチクラウド専門知識がない、明確なビジネスケースがない、初期段階の会社)

次は何？: Part 9 - Terraformバックエンドとリモートステート

ラップトップでterraform applyを実行してきました。学習には問題ありません。

でもSarahがあなたと同時に彼女のラップトップでterraform applyを実行したらどうなりますか？

ステートの競合。インフラの破損。本番障害。パニック。

Part 9では、リモートバックエンドでチームコラボレーションを解決します:

• なぜローカルステートファイルがチームを壊すか（そして修正方法）
• リモートバックエンドの設定（S3、GCS、Azure Storage）
• DynamoDB/Cloud Storageによるステートロック（同時applyの防止）
• 既存のステートをリモートバックエンドに移行（すべてを破壊せずに）
• マルチ環境管理のためのワークスペース戦略

問題:

開発者A: terraform apply（開始）
開発者B（10秒後）: terraform apply（開始）
結果: ステートファイルの破損！誰が何を作成したか？誰も知らない！

解決策: ロック付きリモートステート。Part 9でお会いしましょう。

連載ナビゲーション:

• Part 1: Why Infrastructure as Code?
• Part 2: Setting Up Terraform
• Part 3: Your First Cloud Resource
• Part 4: HCL Fundamentals
• Part 5: Variables, Outputs & State
• Part 6: Core Terraform Workflow
• Part 7: Modules for Organization
• Part 8: Multi-Cloud Patterns (現在地)
• Part 9: State Management & Team Workflows
• Part 10: Testing & Validation
• Part 11: Security & Secrets Management
• Part 12: Production Patterns & DevSecOps

この記事は「Terraform from Fundamentals to Production」シリーズの一部です。TerraformでInfrastructure as Codeをマスターするためにフォローしてください。