Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ついに来た!本格的なマルチクラウド時代の Google Cloud

ついに来た!本格的なマルチクラウド時代の Google Cloud

クラスメソッド社主催の Google Cloud Next’26 Recap の発表資料です。
https://classmethod.connpass.com/event/390028/

Avatar for maroon1st

maroon1st

April 28, 2026

More Decks by maroon1st

Other Decks in Programming

Transcript

  1. ⾃⼰紹介 2 ⼤栗 宗(@maroon1st) クラウド事業本部所属 ⽇系SIer → クラスメソッド → 某外資 →

    クラスメソッド (2回⽬) 最近クラウド⼆⼑流?エンジニアをやってます • Google Cloud, AWS, Cloudflare, etc • Google Cloud Partner Top Engineer 2023, 2024, 2025, 2026 • Google Cloud Partner All Certification Holders 2025
  2. ⼈間と AI エージェントが共に働く企業 4 AI エージェントが企業データに基づいて⾃律的に動くためには、 データがどこにあっても活⽤できることが必要 Google Cloud 3

    層 でマルチクラウド対応を発表 • Network • Analytics • Transaction ロックインせず技術的な優位性で勝負する!という意気込みだと思っています
  3. Cross-Cloud Interconnect 双⽅向 GA 7 2025年11⽉に Google Cloud と AWS

    を簡単に直結する Interconnect を発表 Next 2026 直前に⼀般提供開始 2 拠点 4 ルーターの 4 重冗⻑を Google Cloud と AWS で事前設置 • 作成と承認だけですぐに繋がる • セットアップが数⽇から数分に • 1〜100 Gbps をオンデマンド拡張 • パフォーマンスとレイテンシが安定
  4. Partner Cross-Cloud Interconnect for AWS 8 対応リージョンは 5 ペア(⽶東 1

    / ⽶⻄ 2 / 欧州 2)まもなくシンガポール? ⽇本はまだなので早く来てほしい!!! なお、オレゴンリージョンの AWS ↔ GCP RTT は約 10 ms でした。 Network Connectivity Center(NCC)も Preview 対応して Google Cloud で複 雑な VPC 構成でも簡単に AWS と接続可能になります。 クラウド間接続が Peer to Peer からマルチクラウド WAN へ進化!
  5. BigLake から Google Cloud Lakehouse へ 12 2026 年 4

    ⽉ 20 ⽇ 付で BigLake → Google Cloud Lakehouse に改称 2026 年 4 ⽉ 22 ⽇ に Cross-cloud Lakehouse が Preview Iceberg REST Catalog のメタデータを検出して、AWS の S3 データを⾼速かつ 低遅延でアクセスします。 今後 Snowflake、Databricks、AWS Glue にまたがるエンタープライズデータ を分析可能になります。
  6. Cloud Spanner = NewSQL + マルチモデル 16 分散 SQL を切り開いた

    NewSQL の代表的なサービス • NoSQL の⽔平スケーリング + RDBMS の ACID + 外部整合性 • Relational / Key-Value / Vector/ Graph の各種データモデル • 全⽂検索にカラム型エンジン • 可⽤性 99.999% AI エージェントのコンテキスト基盤としても注⽬
  7. なぜ「どこでも動く Spanner」が必要だったか 17 • 事業継続性 ◦ クラウドを超えた⾼可⽤性の確保 ◦ 緊急時のクラウド撤退 •

    データレジデンシー ◦ データ主権を確保するためのオンプレミス戦略 ◦ Google Cloud がサポートしていない地域での運⽤ • マルチ / ハイブリッド クラウド戦略 ◦ ポータビリティの確保 ◦ 多数の環境に渡る⼀貫したソフトウェア • Spanner に関⼼がある⾮ GCP 顧客 ◦ ⾃⼰管理を好むユーザー ◦ 他のインフラストラクチャーのみを利⽤している
  8. Spanner を⽀える技術 18 Spanner のコア技術 • 環境に依存しない技術 ◦ Paxos コンセンサス(2PC

    の単⼀障害点を補完) ◦ ⾃動シャーディング ◦ 同期レプリケーション • Google に依存する技術 ◦ Colossus → 抽象化レイヤー ◦ TrueTime → 再構築
  9. Colossus 19 Colossus は Google のほぼすべてのプロダクトを⽀えるファイルシステム 依存を解消するため Colossus 相当の機能を提供する抽象化レイヤーを導⼊ •

    ローカルファイルシステムの書き込み • ネットワーク経由アクセス • シャードの分割 • シャードの再配置 Spanner Omni のストレージは SSD + ext4 が推奨
  10. TrueTime 20 TrueTime は • 原⼦時計 + GPS で⾼精度な時刻同期基盤を構築 •

    時刻を不確実性を含む区間として表現 [earliest, latest] • Commit Wait : ε の幅だけ書き込みを待ってからコミット • 外部整合性を保証 TrueTime は原⼦時計ではなく 区間表現 と Commit Wait が重要 不確実範囲が他のDB操作とオーバーラップするので パフォーマンスを損なわない
  11. デプロイパターン 21 • 単⼀サーバー ◦ 1 台のマシンで実⾏される単⼀のサーバーがあります。 • 単⼀ゾーン ◦

    単⼀ゾーンに分散された複数のサーバーで実⾏されます。 • 単⼀ロケーション、複数ゾーン (レプリケートされたデプロイメント) ◦ 1 つのロケーション内の複数のゾーンに分散された複数のサーバーで実⾏されます。 • 複数ロケーション、複数ゾーン ◦ 複数のロケーションと複数のゾーンに分散された複数の サーバーで実⾏されます。 単⼀サーバーなら簡単に試せます! macOS 上でも
  12. Google Cloud がマルチクラウドに本気になった年 24 Google Cloud は「外に出る」選択をした • ロックインから技術的優位性へ •

    Network‧Analytics‧Transaction の 3 層全部 で 揃った本気度 • Agentic Era がそれを必然にした