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

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

Transcript

1. 2026/04/28 ⼤栗 宗 ついに来た！ 本格的なマルチクラウド時代の Google Cloud
2. ⾃⼰紹介 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
3. Agentic Enterprise 3
4. ⼈間と AI エージェントが共に働く企業 4 AI エージェントが企業データに基づいて⾃律的に動くためには、 データがどこにあっても活⽤できることが必要 Google Cloud 3 層 でマルチクラウド対応を発表 • Network • Analytics • Transaction ロックインせず技術的な優位性で勝負する！という意気込みだと思っています
5. 3 層全部で揃ったマルチクラウド対応 5 ネットワーク層の相互接続 分析層の統合 トランザクション層の マルチクラウド Network Analytics Transaction Spanner Omni Cross-cloud Lakehouse (formerly BigLake) • Partner Cross-Cloud Interconnect • AWS Interconnect - multicloud
6. Network 6
7. Cross-Cloud Interconnect 双⽅向 GA 7 2025年11⽉に Google Cloud と AWS を簡単に直結する Interconnect を発表 Next 2026 直前に⼀般提供開始 2 拠点 4 ルーターの 4 重冗⻑を Google Cloud と AWS で事前設置 • 作成と承認だけですぐに繋がる • セットアップが数⽇から数分に • 1〜100 Gbps をオンデマンド拡張 • パフォーマンスとレイテンシが安定
8. 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 へ進化！
9. ブログ書いてます 9 https://dev.classmethod.jp/articles/aws-and-google-cloud-aws-interconnect-multicloud-ga/
10. プレビューは Google Cloud メインでブログ書いてますよ！ 10 https://dev.classmethod.jp/articles/partner-cross-cloud-interconnect-for-aws-google-cloud-aws-preview/
11. Analytics 11
12. 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 にまたがるエンタープライズデータ を分析可能になります。
13. Cross-Cloud Interconnect 13 オプションの Cross-Cloud Interconnect を活⽤して安定的な分析が可能に
14. ブログ書いてます 14 https://dev.classmethod.jp/articles/cross-cloud-lakehouse-preview-bigquery-aws-iceberg/
15. Transaction 15
16. Cloud Spanner ＝ NewSQL ＋ マルチモデル 16 分散 SQL を切り開いた NewSQL の代表的なサービス • NoSQL の⽔平スケーリング ＋ RDBMS の ACID ＋ 外部整合性 • Relational / Key-Value / Vector/ Graph の各種データモデル • 全⽂検索にカラム型エンジン • 可⽤性 99.999％ AI エージェントのコンテキスト基盤としても注⽬
17. なぜ「どこでも動く Spanner」が必要だったか 17 • 事業継続性 ◦ クラウドを超えた⾼可⽤性の確保 ◦ 緊急時のクラウド撤退 • データレジデンシー ◦ データ主権を確保するためのオンプレミス戦略 ◦ Google Cloud がサポートしていない地域での運⽤ • マルチ / ハイブリッド クラウド戦略 ◦ ポータビリティの確保 ◦ 多数の環境に渡る⼀貫したソフトウェア • Spanner に関⼼がある⾮ GCP 顧客 ◦ ⾃⼰管理を好むユーザー ◦ 他のインフラストラクチャーのみを利⽤している
18. Spanner を⽀える技術 18 Spanner のコア技術 • 環境に依存しない技術 ◦ Paxos コンセンサス（2PC の単⼀障害点を補完） ◦ ⾃動シャーディング ◦ 同期レプリケーション • Google に依存する技術 ◦ Colossus → 抽象化レイヤー ◦ TrueTime → 再構築
19. Colossus 19 Colossus は Google のほぼすべてのプロダクトを⽀えるファイルシステム 依存を解消するため Colossus 相当の機能を提供する抽象化レイヤーを導⼊ • ローカルファイルシステムの書き込み • ネットワーク経由アクセス • シャードの分割 • シャードの再配置 Spanner Omni のストレージは SSD + ext4 が推奨
20. TrueTime 20 TrueTime は • 原⼦時計 ＋ GPS で⾼精度な時刻同期基盤を構築 • 時刻を不確実性を含む区間として表現 [earliest, latest] • Commit Wait : ε の幅だけ書き込みを待ってからコミット • 外部整合性を保証 TrueTime は原⼦時計ではなく 区間表現 と Commit Wait が重要 不確実範囲が他のDB操作とオーバーラップするので パフォーマンスを損なわない
21. デプロイパターン 21 • 単⼀サーバー ◦ 1 台のマシンで実⾏される単⼀のサーバーがあります。 • 単⼀ゾーン ◦ 単⼀ゾーンに分散された複数のサーバーで実⾏されます。 • 単⼀ロケーション、複数ゾーン （レプリケートされたデプロイメント） ◦ 1 つのロケーション内の複数のゾーンに分散された複数のサーバーで実⾏されます。 • 複数ロケーション、複数ゾーン ◦ 複数のロケーションと複数のゾーンに分散された複数の サーバーで実⾏されます。 単⼀サーバーなら簡単に試せます！ macOS 上でも
22. やっぱり、ブログ書いてます 22 https://dev.classmethod.jp/articles/spanner-omni-google-cloud-next26/
23. DEMO 23
24. Google Cloud がマルチクラウドに本気になった年 24 Google Cloud は「外に出る」選択をした • ロックインから技術的優位性へ • Network‧Analytics‧Transaction の 3 層全部 で 揃った本気度 • Agentic Era がそれを必然にした