STEP 28：プロジェクト③ ハイブリッドクラウド設計

ホーム > クラウドデータ基盤 > STEP 28

🌐 STEP 28: プロジェクト③ ハイブリッドクラウド設計

AWSとGCPを組み合わせたマルチクラウド環境を構築しよう

📋 このプロジェクトで設計するもの

  • AWSとGCPを組み合わせたハイブリッドアーキテクチャ
  • クラウド間のデータ転送パイプライン
  • コスト最適化のためのクラウド使い分け
  • 障害時のフェイルオーバー戦略
  • セキュリティとコンプライアンス対策

学習時間の目安： 2.5時間

🎯 このプロジェクトのゴール

STEP 26（AWS）とSTEP 27（GCP）で構築した基盤を連携させます。「どちらか一方」ではなく「両方の強みを活かす」設計を学びましょう！

🎯 1. ハイブリッドクラウドとは

💡 例え話：ハイブリッドクラウド = 複数の銀行口座

【単一クラウド = 1つの銀行だけ使う】 ・〇〇銀行にすべてのお金を預ける ・その銀行がシステム障害 → 全部使えない！ ・その銀行の手数料が高くても選択肢がない 【マルチクラウド = 複数の銀行を使い分ける】 ・給与振込 → A銀行（振込手数料が安い） ・貯金 → B銀行（金利が高い） ・決済 → C銀行（ネットバンキングが便利） ・A銀行が障害 → B銀行から引き出せばOK 💡 クラウドも同じ！ ・データ蓄積 → AWS S3（安い、実績あり） ・大規模分析 → GCP BigQuery（速い、安い） ・AWS障害 → GCPにフェイルオーバー

なぜマルチクラウドが必要？

📊 単一クラウド vs マルチクラウド

【単一クラウドのリスク】 ❌ ベンダーロックイン → AWSが値上げしても移行できない ❌ 単一障害点 → AWSが落ちたらシステム全停止 ❌ 最適サービスが使えない → BigQueryの方が良くてもRedshiftを使うしかない 【マルチクラウドのメリット】 ✅ ベンダーロックイン回避 → いつでも移行可能、価格交渉力UP ✅ 高可用性 → AWS障害時はGCPで継続 ✅ 最適サービス選択 → 用途に応じてベストなサービスを使用 ✅ コスト最適化 → 安い方のクラウドを使い分け 【マルチクラウドのデメリット】 ⚠️ 運用の複雑化 → 2つのクラウドの知識が必要 ⚠️ データ転送コスト → クラウド間の転送は有料 ⚠️ セキュリティ管理の複雑化 → 2つのIAMを管理

想定シナリオ

🏢 グローバル展開する企業のデータ基盤

【企業の状況】 ・多国籍企業で世界中にオフィスがある ・北米・欧州：既存システムがAWS上で稼働 ・アジア太平洋：新規事業でGCPを採用予定 ・要求：グローバルで統一されたデータ分析基盤 【課題】 ・北米のデータはS3、アジアのデータはGCS ・両方のデータを統合して分析したい ・どちらかのクラウドが落ちてもサービス継続したい ・コストを最適化したい 【解決策：ハイブリッドクラウド】 ・データ収集は各リージョンの最寄りクラウド ・分析はBigQuery（コスパ最強） ・バックアップは相互に保持 ・障害時は自動フェイルオーバー

🏗️ 2. ハイブリッドアーキテクチャ設計

全体アーキテクチャ

【マルチクラウドアーキテクチャ図】 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 北米・欧州（AWS中心） アジア太平洋（GCP中心） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ┌─────────────────────┐ ┌─────────────────────┐ │ 🇺🇸 北米データソース │ │ 🇯🇵 アジアデータソース │ │ ・ECサイト(米国) │ │ ・モバイルアプリ │ │ ・社内システム │ │ ・IoTセンサー │ └──────────┬──────────┘ └──────────┬──────────┘ │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ AWS S3 (データレイク) │ │ GCS (データレイク) │ │ Raw/Processed/Curated│ │ Raw/Processed/Curated│ └──────────┬──────────┘ └──────────┬──────────┘ │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ AWS Glue (ETL) │ │ Dataflow (ETL) │ └──────────┬──────────┘ └──────────┬──────────┘ │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ Amazon Redshift (DWH)│ │ BigQuery (DWH) │ │ ・ローカル分析用 │ │ ・グローバル分析用 │ └──────────┬──────────┘ └──────────┬──────────┘ │ │ │ ┌──────────────┐ │ └─────→│ データ連携 │←─────────┘ │ (日次同期) │ └──────┬───────┘ │ ▼ ┌─────────────────────┐ │ 統合BIレイヤー │ │ ・Looker Studio │ │ ・Tableau │ │ ・Power BI │ └─────────────────────┘

設計のポイント

1️⃣ データの配置

【原則：データは発生源の近くに】 北米のユーザー → AWS（バージニア） 欧州のユーザー → AWS（フランクフルト） 日本のユーザー → GCP（東京） 💡 理由: ・レイテンシを最小化 ・データ主権（GDPR等）を考慮 ・転送コストを削減

2️⃣ 分析基盤の選択

【用途に応じて使い分け】 ローカル分析（北米向けレポート） → Redshift（データが近い） グローバル分析（全世界の統合分析） → BigQuery（スケーラブル、安い） アドホック分析（調査・探索） → Athena / BigQuery（従量課金） 💡 全部をBigQueryに集約するのが 最もシンプルでコスパが良い！

🔄 3. クラウド間データ転送

💡 例え話：データ転送 = 引っ越し

【データ転送 = 引っ越し業者の選び方】 ■ 少量の荷物（数GB） → 自分で運ぶ（Pythonスクリプト） → 安いけど手間がかかる ■ 大量の荷物（数TB） → 引っ越し業者に頼む（Transfer Service） → お金はかかるが効率的 ■ 毎日の配送（定期転送） → 定期便を契約（スケジュール転送） → 自動化で楽々 💡 転送コストの相場: ・AWS→外部: $0.09/GB ・GCP→外部: $0.12/GB ・1TB転送すると約$100!

方法1: Storage Transfer Service（GCP公式）

# GCPのStorage Transfer Serviceを使ってS3からGCSへ転送 from google.cloud import storage_transfer transfer_client = storage_transfer.StorageTransferServiceClient() # 転送ジョブの設定 transfer_job = { “description”: “Daily transfer from AWS S3 to GCS”, “project_id”: “your-gcp-project”, “transfer_spec”: { # 転送元: AWS S3 “aws_s3_data_source”: { “bucket_name”: “your-s3-bucket”, “path”: “processed/”, “aws_access_key”: { “access_key_id”: “YOUR_AWS_ACCESS_KEY”, “secret_access_key”: “YOUR_AWS_SECRET_KEY” } }, # 転送先: GCS “gcs_data_sink”: { “bucket_name”: “your-gcs-bucket”, “path”: “from-aws/” }, # オプション: 転送済みファイルを削除しない “transfer_options”: { “delete_objects_from_source_after_transfer”: False, “overwrite_objects_already_existing_in_sink”: False } }, # スケジュール: 毎日午前3時（UTC）に実行 “schedule”: { “schedule_start_date”: {“year”: 2025, “month”: 1, “day”: 15}, “start_time_of_day”: {“hours”: 3, “minutes”: 0} } } # ジョブ作成 response = transfer_client.create_transfer_job(request={“transfer_job”: transfer_job}) print(f”✅ Transfer job created: {response.name}”)

📝 コードの解説

【各設定の意味】 aws_s3_data_source: ├── bucket_name: 転送元のS3バケット名 ├── path: 転送するフォルダ（processed/以下） └── aws_access_key: AWSの認証情報 gcs_data_sink: ├── bucket_name: 転送先のGCSバケット名 └── path: 保存先フォルダ transfer_options: ├── delete_objects_from_source_after_transfer: False │ → 転送後もS3のファイルを残す（バックアップ） └── overwrite_objects_already_existing_in_sink: False → 既存ファイルを上書きしない（差分転送） schedule: ├── schedule_start_date: 開始日 └── start_time_of_day: 毎日の実行時刻（UTC） 💡 日本時間で午前3時に実行したい場合は UTC 18:00 (hours: 18) を指定

方法2: シンプルなPythonスクリプト

# 小規模データ向け: Pythonで直接転送 import boto3 from google.cloud import storage import os def transfer_s3_to_gcs(s3_bucket, s3_key, gcs_bucket, gcs_blob_name): “””S3からGCSへファイルを転送””” # 1. S3からダウンロード s3_client = boto3.client(‘s3′) local_path = f’/tmp/{os.path.basename(s3_key)}’ print(f”📥 S3からダウンロード中: s3://{s3_bucket}/{s3_key}”) s3_client.download_file(s3_bucket, s3_key, local_path) # 2. GCSにアップロード gcs_client = storage.Client() bucket = gcs_client.bucket(gcs_bucket) blob = bucket.blob(gcs_blob_name) print(f”📤 GCSにアップロード中: gs://{gcs_bucket}/{gcs_blob_name}”) blob.upload_from_filename(local_path) # 3. ローカルファイルを削除 os.remove(local_path) print(“✅ 転送完了!”) # 実行例 transfer_s3_to_gcs( s3_bucket=’my-aws-bucket’, s3_key=’processed/sales_2025-01-15.parquet’, gcs_bucket=’my-gcp-bucket’, gcs_blob_name=’from-aws/sales_2025-01-15.parquet’ )

転送コスト最適化

⚠️ 転送コストに注意！

【データ転送コスト（Egress料金）】 AWS S3 → 外部: ├── 最初の10TB: $0.09/GB ├── 次の40TB: $0.085/GB └── それ以上: $0.07/GB GCS → 外部: ├── 0-1TB: $0.12/GB ├── 1-10TB: $0.11/GB └── 10TB+: $0.08/GB 【計算例】 毎日100GBを転送する場合: 100GB × $0.09 × 30日 = $270/月 毎日10GBを転送する場合: 10GB × $0.09 × 30日 = $27/月 💡 コスト削減テクニック: 1. 圧縮: Parquet形式で80%削減 2. 差分転送: 変更分のみ転送 3. 集計後転送: 生データではなく集計データを転送 4. 同一リージョン: 同じリージョン間は無料の場合あり

💰 4. コスト比較と最適化

サービス別コスト比較

サービス AWS GCP 推奨
ストレージ S3: $0.023/GB GCS: $0.020/GB GCPが13%安い
DWH（定額） Redshift: $0.25/時間〜 BigQuery: スロット予約 用途次第
DWH（従量） Athena: $5/TB BigQuery: $5/TB 同じ
データ転送 $0.09/GB $0.12/GB AWSが25%安い
BIツール QuickSight: $9/月〜 Looker Studio: 無料 GCPが圧勝

💡 最適な使い分け戦略

【コスト最適化のベストプラクティス】 1️⃣ データ収集・蓄積 → AWS S3 ・既存システムとの連携が楽 ・転送コストが安い（外に出す時） 2️⃣ 大規模分析 → GCP BigQuery ・クエリ課金で使った分だけ ・パーティショニングでコスト削減 ・Looker Studio連携で可視化も無料 3️⃣ リアルタイム処理 → GCP Dataflow ・ストリーミング処理が得意 ・BigQueryとの相性が良い 4️⃣ 機械学習 → GCP Vertex AI or AWS SageMaker ・データの場所に合わせて選択 【転送戦略】 ・Raw データ → 転送しない（元のクラウドに保管） ・Processed データ → 必要な場合のみ転送 ・Curated/集計データ → BigQueryに集約
【ハイブリッド構成のコスト例】 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ 単一クラウド（AWS全振り）: $1,200/月 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ├── S3 (500GB) $12 ├── Redshift (24時間稼働) $600 ├── Glue ETL $100 ├── QuickSight (10ユーザー) $90 ├── Athena $50 └── その他 $348 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ ハイブリッド構成: $750/月（37%削減！） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【AWS側】 ├── S3 (500GB) $12 ├── Glue ETL $50 └── 転送コスト (50GB/日) $135 【GCP側】 ├── GCS (200GB) $4 ├── BigQuery $100 ├── Dataflow $100 ├── Looker Studio $0 ← 無料！ └── その他 $349 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 削減額: $450/月（年間$5,400！） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🛡️ 5. フェイルオーバー戦略

💡 例え話：フェイルオーバー = 予備の発電機

【フェイルオーバー = 予備電源】 ■ 通常時 ・メインの電力会社から電気を供給 ・予備の発電機は待機状態 ■ 停電時 ・メインの電力が停止 ・自動的に予備発電機が起動 ・サービスは継続 ■ 復旧時 ・メインの電力が復旧 ・予備発電機から切り戻し ・通常運転に戻る 💡 クラウドも同じ！ ・AWS = メイン電源 ・GCP = 予備発電機 ・AWS障害 → GCPに自動切り替え

フェイルオーバーの設計

【フェイルオーバーシナリオ】 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ 通常時（AWS = メイン、GCP = バックアップ） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ユーザー/アプリ] │ ▼ [AWS S3] ──(日次同期)──→ [GCS] │ │ ▼ ▼ [Redshift] [BigQuery] │ (待機) ▼ [QuickSight] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ AWS障害発生！ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ユーザー/アプリ] │ ✖ AWS障害検知 │ └──────→ [GCS] │ ▼ [BigQuery] │ ▼ [Looker Studio] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ 復旧時 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ・AWSの復旧を確認 ・GCP→AWSへ差分データを同期 ・徐々にAWSに切り戻し

フェイルオーバー監視スクリプト

# フェイルオーバー監視・自動切り替えスクリプト import boto3 from google.cloud import bigquery import time import requests def check_aws_health(): “””AWSの死活監視””” try: # S3にアクセスできるか確認 s3 = boto3.client(‘s3′, region_name=’ap-northeast-1′) s3.head_bucket(Bucket=’your-bucket’) # Redshiftにクエリできるか確認 # （実際にはRedshift接続も確認） return True except Exception as e: print(f”❌ AWS障害検知: {e}”) return False def notify_slack(message): “””Slackに通知””” webhook_url = “https://hooks.slack.com/services/YOUR/WEBHOOK/URL” requests.post(webhook_url, json={“text”: message}) def failover_to_gcp(): “””GCPにフェイルオーバー””” print(“🚨 AWS障害検出! GCPに切り替え中…”) notify_slack(“🚨 AWS障害検出! GCPへのフェイルオーバーを開始します”) # 1. DNS切り替え（Route 53 → Cloud DNS） # 実際にはDNSレコードを更新 # 2. アプリケーション設定を更新 # 環境変数やConfig Serverの設定を変更 # 3. BigQueryで動作確認 bq_client = bigquery.Client() query = “SELECT COUNT(*) as cnt FROM `dataset.table` WHERE DATE(timestamp) = CURRENT_DATE()” result = list(bq_client.query(query).result()) print(f”✅ GCPへの切り替え完了: {result[0].cnt}件のデータを確認”) notify_slack(f”✅ GCPへのフェイルオーバー完了: {result[0].cnt}件のデータを確認”) # 監視ループ consecutive_failures = 0 FAILURE_THRESHOLD = 3 # 3回連続失敗でフェイルオーバー while True: if check_aws_health(): consecutive_failures = 0 print(“✅ AWS正常稼働中”) else: consecutive_failures += 1 print(f”⚠️ AWS障害: {consecutive_failures}回目”) if consecutive_failures >= FAILURE_THRESHOLD: failover_to_gcp() break time.sleep(60) # 1分ごとにチェック

💡 RTO/RPOの設計

【重要な指標】 RTO（Recovery Time Objective）= 目標復旧時間 ├── 定義: 障害発生から復旧までの許容時間 ├── 今回の設計: 5分以内 └── 対策: 自動フェイルオーバー、事前にGCP環境を準備 RPO（Recovery Point Objective）= 目標復旧時点 ├── 定義: どこまでのデータを失っても許容できるか ├── 今回の設計: 15分以内（日次同期の場合は最大24時間） └── 対策: リアルタイム同期で短縮可能 【フェイルオーバー訓練】 ・月1回、実際に切り替え訓練を実施 ・手順書を更新 ・問題点を洗い出して改善

🔒 6. セキュリティ設計

クラウド間の安全な通信

【セキュリティ設計のポイント】 1️⃣ 転送時の暗号化 ┌─────────────────────────────────────────────────┐ │ AWS S3 ──TLS 1.3暗号化──→ GCS │ │ ・データは転送中も暗号化 │ │ ・中間者攻撃を防止 │ └─────────────────────────────────────────────────┘ 2️⃣ 保存時の暗号化 ┌─────────────────────────────────────────────────┐ │ AWS: SSE-S3 / SSE-KMS │ │ GCP: Cloud KMS │ │ ・データは保存時も暗号化 │ │ ・鍵はマネージドサービスで管理 │ └─────────────────────────────────────────────────┘ 3️⃣ アクセス制御（最小権限の原則） ┌─────────────────────────────────────────────────┐ │ AWS IAM │ │ ├── 転送用ロール: S3読み取りのみ │ │ └── ETL用ロール: Glue実行権限のみ │ │ │ │ GCP IAM │ │ ├── 転送用SA: GCS書き込みのみ │ │ └── 分析用SA: BigQuery参照のみ │ └─────────────────────────────────────────────────┘ 4️⃣ 監査ログ ┌─────────────────────────────────────────────────┐ │ AWS: CloudTrail → S3に保存 │ │ GCP: Cloud Audit Logs → BigQueryに保存 │ │ ・誰が、いつ、何をしたかを記録 │ │ ・不正アクセスの検知に活用 │ └─────────────────────────────────────────────────┘

⚠️ よくあるセキュリティミス

  • 認証情報をコードにハードコード → 環境変数やSecret Managerを使う
  • S3/GCSを公開設定 → デフォルトは非公開、必要な場合のみ限定公開
  • 過剰な権限 → 最小権限の原則を徹底
  • ログを取らない → CloudTrail/Cloud Auditを必ず有効化

📝 7. STEP 28 のまとめ

✅ このプロジェクトで設計したもの

  • ハイブリッドアーキテクチャ：AWS（北米）+ GCP（アジア）の組み合わせ
  • データ転送パイプライン：Storage Transfer Service / Pythonスクリプト
  • コスト最適化：用途に応じたクラウド使い分けで37%削減
  • フェイルオーバー戦略：RTO 5分、RPO 15分の設計
  • セキュリティ：暗号化、IAM、監査ログ

💡 次のステップへ

STEP 26〜28で、AWS、GCP、そしてハイブリッド構成の3パターンを学びました！

次のSTEP 29では、コスト最適化実践プロジェクトに挑戦します。
既存基盤のコストを50%削減する具体的な手法を学びましょう！

❓ よくある質問

Q1: マルチクラウドは運用が大変では？
確かに複雑になります。しかし、Terraformで両方のクラウドを統一管理したり、Kubernetesでワークロードを抽象化することで、運用負荷を軽減できます。また、ベンダーロックイン回避や高可用性のメリットが運用コストを上回ることが多いです。
Q2: データ転送コストを抑える方法は？
いくつかの方法があります。(1) Parquet等の圧縮形式を使う (2) 生データではなく集計データを転送 (3) 差分転送で変更分のみ (4) 夜間など低トラフィック時間帯に転送。特に圧縮は効果が大きく、80%以上削減できることもあります。
Q3: どちらのクラウドに統一した方が良いのでは？
ケースバイケースです。単一クラウドの方がシンプルで運用しやすいのは事実です。ただし、既存システムの移行コスト、ベンダーロックインのリスク、各クラウドの強み（BigQueryの分析力など）を考慮して判断しましょう。
Q4: フェイルオーバーの自動化は必須ですか？
RTOの要件次第です。数時間のダウンタイムが許容されるなら手動切り替えでも十分です。5分以内の復旧が必要なら自動化が必須です。ただし、自動化にはテストと訓練が重要で、誤検知による不要な切り替えを防ぐ必要があります。
Q5: Azureも含めた3クラウド構成は現実的ですか？
大企業では実際に使われています。ただし、運用の複雑さが増すため、明確なメリットがある場合のみ検討すべきです。例えば、Microsoft 365との連携でAzure、機械学習でGCP、既存システムでAWSのように、用途が明確に分かれている場合は有効です。
← 前のステップ
STEP 27: プロジェクト② GCPでのデータ基盤構築 次のステップへ →
STEP 29: プロジェクト④ コスト最適化実践
📝

学習メモ

クラウドデータ基盤（AWS・GCP） - Step 28

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
#artnasekai #学習メモ
LINE
ホーム
クラウドデータ基盤（AWS・GCP）