Cross-Cloud Interconnect が GA になったのでまとめてみた

はじめに

2024/02 Update!!
一部情報を最新の情報へアップデートしました。
追記した情報は、各章に記載しておりますのでご確認ください。

こんにちは、クラウドエースでSREディビジョンに所属している Shanks と申します。

クラウドエースではオンプレミスと Google Cloud を連携したシステム構築を幅広く行っております。
その中でも、システム要件として「大容量通信が発生するため帯域幅を確保したい」「Google Cloud に安定した回線で接続したい」「オンプレミスと低レイテンシで通信をしたい」といったご要望を受けることがあります。
そのような場合、通常「Cloud Interconnect」というプロダクトを利用します。
すでに多くの企業様が導入いただいているためご存知の方も多いかと思いますが、Cloud Interconnect とは「オンプレミスと Google Cloud 間を物理的な専用線で相互接続する機能」を提供するプロダクトです。

本記事では、2023/06/01 に Cross-Cloud Interconnect（以降、CCIと呼ぶ。）という Cloud Interconnect の派生機能が新たに追加されましたので、さっそくまとめていこうと思います。

ターゲットとなる読者層

• 他のパブリッククラウドを利用していて、Google Cloud との接続を計画している方
  • Google Cloud - Amazon Web Services(AWS)
  • Google Cloud - Microsoft Azure(Azure)
  • Google Cloud - Oracle Cloud Infrastructure(OCI)
  • Google Cloud - Alibaba Cloud(Alibaba)

この連載でやること・やらないこと

やること・やらないこと

観点	対象	備考
CCI 概要	✅
注意事項	✅
制約事項	✅
料金体系	✅
サンプルアーキテクチャ解説	✅
構築方法解説	✅
実際の接続	🚫	別記事にて紹介していますのであわせてご確認ください。
他クラウドサービスの個別解説	🚫	各クラウドサービスのドキュメントをご確認ください。

注意事項

Cloud Interconnect は、Partner Interconnect と Dedicated Interconnect の2種類の接続方法が提供されていますが、どちらも VPN 等の他接続サービスと比べ高額なプロダクトです。
接続を計画する際は、スケジュールに十分余裕をもって設計を行い、手戻りがないよう慎重に進めましょう。

CCI 概要

Cloud Interconnect とは

https://youtu.be/cKaryf7qp9w
Cloud Interconnect とは、冒頭でも述べたとおり、「オンプレミスと Google Cloud 間を物理的な専用線で接続する機能」を提供するプロダクトです。
Cloud Interconnect は、低レイテンシで高可用性の接続を実現することにより、オンプレミス ネットワークと Google Cloud Virtual Private Cloud（VPC）ネットワーク間での安定したデータ転送を可能にします。

また、物理的な専用回線ということもあり、他のユーザの通信に左右されることなく安定的な帯域幅の確保が可能です。
いわゆる、ノイジーネイバーの影響をうけない、ということです。

Cloud Interconnect には Google Cloud との直接接続である「Dedicated Interconnect」と、サポートされているサービスプロバイダを中継する「Partner Interconnect」がありますが、本記事の本筋からそれてしまうためここでは割愛します。

Dedicated Interconnect	Partner Interconnect
Cloud Console より引用	Cloud Console より引用

ネットワーク接続プロダクトの選択に関する詳細は、公式ドキュメントをご確認ください。
https://cloud.google.com/network-connectivity/docs/how-to/choose-product?hl=ja

新機能「Cross-Cloud Interconnect」とは

上述のとおり、今まではあくまで「オンプレミスとの接続」をサポートするものであり、他のパブリッククラウドへの接続はサポートしていませんでした。
そのため、Google Cloud と他のパブリッククラウドを接続する場合は、個別に相互接続を設けたうえで専用線を提供するサービスプロバイダ側の網内でルーティングを行う必要があるなど、一筋縄ではいかない構成が必要でした。
また、この構成では独自ルータなど設備側の費用が高額になり、設計〜構築に時間がかかるという難点がありました。

新たに登場した CCI は、「他クラウドサービスとの接続」を着眼点としており、上述した問題を解決する追加機能です。
これにより、他クラウドサービスとの接続において 直接 相互接続が可能になりました。

• Benefit > Integrated multicloud strategy
• Benefit > Reduced complexity

Cross-Cloud Interconnect
Cloud Console より引用

CCI の利点

CCI の利点は以下のとおりです。

• Google Cloud と他クラウドサービスを直接繋げることができる
  • クラウドサービス間 での高可用性が保証された専用線接続を提供
  • サービスプロバイダ側での複雑なルーティング設計（迂回経路）を行う必要がない
• マルチクラウド構成が柔軟に構成可能
  • マルチクラウド構成によってダウンタイムの軽減やリスク分散、BCP（事業継続計画）対応
  • ベンダーロックインの回避

従来のアーキテクチャ	Cross-Cloud Interconnect
	Cloud Console より引用

注意事項・制約事項

一方で、CCI を利用するにあたって、以下の制約事項がありますのでご注意ください。

• 記事執筆時点でサポートされているクラウドプロバイダーは以下であること
  • AWS
  • Azure
  • OCI
  • Alibaba
• 特定のリージョンでのみサポートされている
  • 詳しくは後述のサポートされているリージョンを参照
• 従来の割り当てと上限は引き続き適用されること
  • Cloud Interconnect や VLAN アタッチメント等関連リソース
• 他クラウドサービスの稼働保証はしない
  • 他クラウドサービスのサポートチケットを作成することもしない（自身で行う必要がある）
• 接続容量（帯域幅）
  • 10 または 100Gbps の２つをサポート
    • 10Gbps で不足する場合は複数の回線を LACP で束ねることもできる（80Gbpsまで可能）
    • 80Gbps を超過する必要がある場合、高額でも 100Gbps を選択する必要がある
    • クラウドプロバイダーによっては LACP が対応していない場合がある
    • クラウドプロバイダーによっては 100Gbps が対応していない場合がある
• IPv6
  • IPv6 は IPv4 間で確立された BGP セッションを介してルート交換をする場合にのみサポートされる

詳しくは CCI の Overview ドキュメントにある Supported cloud service providers や Limitation を参照してください。
https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cci-overview

国内サポート状況

2024/02 Update!!
各クラウドプロバイダーの日本国内におけるサポート状況をアップデートしました。

この記事を読んでいる読者層は日本国内における構築を目的としている方が多いと予想されるため、日本国内におけるサポート状況を抜粋します。
対応していない場合は他のリージョンを利用して回避する必要があります。（Alibaba等）

クラウドプロバイダー	リージョン	サポート状況	LACPサポート	ドキュメント
AWS	東京	✅	✅	リンク
	大阪	✅	✅
Azure	東京	✅	🚫	リンク
	大阪	✅	🚫
OCI	東京	✅	✅	リンク
	大阪	🚫	✅
Alibaba	東京	🚫	🚫	リンク
	大阪	🚫	🚫

サポートされているリージョンについての詳細は CCI のドキュメントを参照してください。

SLA

SLA は従来の Cloud Interconnect と同様のものが適用されます。
https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cci-overview#service-level-agreement

最小要件として、異なるエッジアベイラビリティドメインが設定された VLAN アタッチメントを2つ用意し、Cloud Router に割り当てることで最低限の冗長構成をとることができます。
このときの SLA は 99.9% です。

高可用性が求められる場合は、上記の構成を異なるリージョンでも対となるように構成します。
このときの SLA は 99.99% です。

CCI 料金体系

Cloud Interconnect の料金体系

まず、Cloud Interconnect の料金体系をおさらいしましょう。
Cloud Interconnect の料金要素は、以下の3つです。

• Interconnect 接続
  • 物理回線のプロビジョニング料金
• VLAN アタッチメント
  • 論理回線のプロビジョニング料金
• 下り（外向き）トラフィック
  • GiB単位でのトラフィック料金

※ Cloud Routerの料金は無料です。

Cloud Router は無料で提供されています。
一般的なネットワーク費用がコントロール プレーン（BGP）トラフィック(に適用されます。
ほとんどの場合、これらの費用はごくわずかです。

CCI の体料金系

CCI の料金体系は、上述の Cloud Interconnect のうち、Dedicated Interconnect の料金と同様です。
これには他のクラウドサービスのリソース料金は含まれていませんのでご注意ください。

サンプルアーキテクチャ解説

サンプルアーキテクチャから考えるユースケース

CCI サンプルアーキテクチャ

上記のサンプルアーキテクチャを例に、解説をします。
従来の Cloud Interconnect では、他クラウドサービスから Google Cloud に対して直接接続することができなかったと説明しました。
では、具体的にどのようなケースでそのようなアーキテクチャが望まれるのでしょうか。

DWH でのユースケース

代表的なものでいうと、Google Cloud に DWH を構築するケースです。

具体的には、システム自体は AWS/Azure/OCI に構築をした or しているが、それらで蓄積されたビッグデータを解析する基盤として Google Cloud の BigQuery 等を活用したい、といったケースがあげられます。

サンプルアーキテクチャでいうところの DWH 領域をご確認ください。
BigQuery 等に溜め込まれたデータを、他クラウドサービスでホストするシステムが分析のためにアクセスをする、となったとします。
こうした大容量のデータをやりとりする場合、帯域幅がボトルネックとなりパフォーマンスが低下する恐れがあります。

CCI を利用することでこれらのリスクを低減することができます。

ユースケースのポイント

• クラウドサービス間の大容量データ転送に最適な帯域幅を確保できる

API でのユースケース

API 管理基盤を Google Cloud に構築する場合も同様です。

サンプルアーキテクチャでいうところの API 領域をご確認ください。
Google Cloud では API の開発と管理を行うためのスケーラブルなプラットフォームとして、Apigee というプロダクトがあります。
特に、Apigee X は Google Cloud ネイティブなプラットフォームとして多くのお客様がご利用いただいております。
この Apigee に対して、内部通信（専用線アクセス）を行いたいというケースがあります。

このとき、CCI を利用することで DWH の例と同様に他クラウドサービスからでも専用線アクセスで直通のアクセス経路を設けることができます。

ユースケースのポイント

• クラウドサービス間の内部IPアドレスによるデータ転送に最適な内部経路を確保できる

構築方法

他のクラウドサービスがサポートしているリージョンを確認する

他のクラウドサービスがサポートしているリージョンを確認し、設計したアーキテクチャが正しく構成できるか確認します。

AWS

aws directconnect describe-locations \
  --region REGION \
  | jq -r '.locations[] \
  | select(.locationCode \
  | test("REMOTE_LOCATION"; "i")) \
  | .availablePortSpeeds'

Azure

Get-AzExpressRoutePortsLocation -LocationName LOCATION

OCI

oci network cross-connect-port-speed-shape list \
  --compartment-id=ORACLE_CLOUD_ID \
  --region=REGION \
  --all

Alibaba だけは使用可能な 10 または 100 Gbps Express Connect があるかどうかの再確認で対応とします。

他のクラウドサービスと接続するロケーションを確認する

CCI が接続する対向のロケーションを確認します。（以降、REMOTE_LOCATION と呼ぶ。）
この手順で確認したロケーションは、後述の構築手順において利用しますのでメモを取っておいてください。

以下のコマンドを使用して REMOTE_LOCATION の場所を一覧表示します。
これにより、接続するクラウドサービスとリージョンがどの REMOTE_LOCATION と紐づいているのかが確認できます。

gcloud compute interconnects remote-locations list

Cloud Console から構築する

Cloud Console から構築をする場合、以下の手順で進めます。

Cloud Console スクリーンショット
Cloud Console トップ画面から ハンバーガーボタン > ハイブリッド接続 > 相互接続 と進む
画面上部の「物理接続」を選択し、「物理接続を設定」を選択する
画面下部に表示された「クラウド間相互接続」を選択する
新規に構成する場合は「新しいクラウド間相互接続を注文する」を選択する
CCI を注文するために必要な情報を記載する
CCI を注文するために必要な情報を記載する
CCI を注文するために必要な情報を記載する
CCI を注文するために必要な情報を記載する
CCI を注文すると詳細画面が表示されるためプロビジョニングされるまで待機する

以降は、通常の Cloud Interconnect と同様の手順となります。
対向となる他クラウドサービス側でも、Cloud Interconnect と接続できるよう準備を行ってください。
※ 他クラウドサービスでの接続準備は各社公式ドキュメントを確認してください。

gcloud コマンドから構築する

gcloud コマンドから構築をする場合、以下の手順で進めます。

1. 接続を注文する
2. AWS ポートを注文する
3. Google Cloud 側リソースを構成する
4. 他クラウドサービス側リソースを構成する
5. 接続を確認する

以降は、通常の Cloud Interconnect と同様の手順となります。
対向となる他クラウドサービス側でも、Cloud Interconnect と接続できるよう準備を行ってください。
※ 他クラウドサービスでの接続準備は各社公式ドキュメントを確認してください。

1. 接続を注文する

2024/02 Update!!
各クラウドプロバイダーの LACP サポート状況と最大容量に関する情報をアップデートしました。

はじめに、Interconnect の接続を注文します。
注文を完了すると、その注文を確認するメールが Google Cloud から注文者と技術担当者に送付されます。
このメールには LOA-CFA と呼ばれる PDF ファイルが添付されており、接続に使用される物理ポートの詳細などが確認できます。
https://cloud.google.com/network-connectivity/docs/interconnect/how-to/dedicated/retrieving-loas?hl=ja

gcloud compute interconnects create CONNECTION_NAME \
    --interconnect-type=DEDICATED \
    --link-type=CAPACITY \
    --requested-link-count=1 \
    --location=GOOGLE_CLOUD_LOCATION \
    --remote-location=REMOTE_LOCATION \
    --description=DESCRIPTION \
    --noc-contact-email=CONTACT_EMAIL

• CONNECTION_NAME : CCI 接続のリソース名
• CAPACITY : 接続の容量
  • 10Gbpsの場合は LINK_TYPE_ETHERNET_10G_LR
  • 100Gbpsの場合は LINK_TYPE_ETHERNET_100G_LR
• GOOGLE_CLOUD_LOCATION : 利用するリージョン（asia-northeast1 等）
• REMOTE_LOCATION : CCI が接続する対応施設のロケーション
  • AWS/Tokyo の場合は aws-eqty2 等
• DESCRIPTION : 接続に関する任意の説明欄（任意項目）
• CONTACT_EMAIL : Google からの連絡を受け取れるメールアドレス

--interconnect-type の値にご注意ください。
CCI では他のサービスプロバイダと接続する必要がないという点で Dedicated Interconnect に似ています。
このため、Interconnect の種別を指定するこのフラグでは DEDICATED を指定します。

クラウドプロバイダー	サービス名	サポートする容量	LACPサポート
AWS	Direct Connect	10〜40 Gbps or 100〜200 Gbps	✅
Azure	Express Route	10 Gbps or 100 Gps	🚫
OCI	Fast Connect	10〜80 Gbps or 100 Gps	✅
Alibaba	Express Connect	10 Gbps or 100 Gbps	🚫

OCI は 10Gbps ポートの LACP には対応しています。
しかし、100Gbps ポートの LCAP をサポートしていません。
そのため、最大帯域幅は 100Gbps です。

Azure / Alibaba は LACP をサポートしていません。
Azure は 10Gbps or 100Gbps のいずれかを、
Alibaba は 10Gbps or 100Gbps のいずれかを利用してください。
--requested-link-count フラグには 1 を設定してください。

2. ポートの注文

ここでは各クラウドサービスで Cloud Interconnect に相当する専用線サービスの注文を行います。
記事執筆時点で弊社でもLOAを送信している段階ですので、確認が取れ次第随時記事を更新していきます。

3. Google Cloud 側リソースを構成する

この手順は通常の Partner Interconnect や Dedicated Interconnect を注文するのと同様ですので、詳細は割愛します。

1. VPC ネットワークを作成する
2. VLAN アタッチメントを作成する
3. Cloud Router を作成する

4.他クラウドサービス側リソースを構成する

ここでは各クラウドサービスで Cloud Router 等に相当するネットワークプロダクトの構築を行います。
記事執筆時点で弊社でもLOAを送信している段階ですので、確認が取れ次第随時記事を更新していきます。

5. 接続を確認する

接続を確認するにはいくつかの方法があります。
代表的な方法を列挙します。

1. どちらかからエンドポイントに ping を送信する
2. gcloud コマンドで Cloud Router がアドバタイズされたルーティング情報を確認する
3. Cloud Console のリンク回線情報テーブルから「受信光パワー」列を確認する

1 の ping を送る方法は、Google Cloud → AWS の VM に ping を送ったり、またはその逆を行うことで確認ができる一番基本的な方法です。

2 の方法は以下のコマンドを実行することで受信したルーティング情報を確認できます。

gcloud compute routers get-status ROUTER_NAME \
  --project PROJECT_ID \
  --region REGION

3 の方法は以下のとおりです。
Cloud Console > 物理接続タブ > CCI 接続名を選択 > 相互接続の詳細 > リンク回線情報テーブル > 受信光パワー列 を確認し、「OK」となっているか確認する。

以上で注文〜構成〜確認までの流れは完了です。
実際に構築してみて気づいた点などを以下の記事で解説していますのであわせてご一読ください。

まとめ

本記事では、新たに Cloud Interconnect へ追加された Cross-Cloud Interconnect についてまとめました。

• Google Cloud と他クラウドサービスを直接繋げることができる
  • クラウドサービス間 での高可用性が保証された専用線接続を提供
  • サービスプロバイダ側での複雑なルーティング設計（迂回経路）を行う必要がない
• 以下のクラウドサービスとの間で利用することができる
  • AWS / Azure / OCI / Alibaba
• Google Cloud 上にシステムの一部を構成したマルチクラウド構成のシステムに最適
  • 例）DWH 基盤だけ Google Cloud に構成する
  • 例）API 管理基盤だけ Google Cloud に構成する
• BCP を考慮したマルチクラウド構成のシステムに最適

また、付録として、実際にパフォーマンステストを行った結果を公開しています。
検討資料としてぜひお役立てください。

本記事がマルチクラウド構成を検討されている方にとって一助となれば幸いです。