はじめに
皆さんはじめまして、宮川と申します。ネットワークを本分にパブリッククラウドの閉域接続を専門にしています（Amazon著者ページ）。今回、アドベントカレンダーの機会を頂きましたので、最近事例が増えているマルチクラウド構成におけるネットワーク基盤、特にクラウド間の接続について簡単にご紹介したいと思います。
本稿は以下の方々をターゲットにしています。
- マルチクラウド化されそうなシステムのネットワーク基盤に関わる方
- マルチクラウドのシステムに関わっているが、ネットワークについてよくわからないよという方
- マルチクラウド全般に興味がある方
マルチクラウドの背景
システム基盤としてパブリッククラウドを使うことはまったく珍しくなくなりました。読者の皆様の関係されるITシステムにおいてもなんらかのパブリッククラウドを利用されていることでしょう。そして、さらにこのパブリッククラウドの利用を増やしていこうと考えたときに、現在利用しているクラウドだけでなく異なるクラウドの追加も検討対象になるのではないでしょうか。これが「マルチパブリッククラウド」＝「マルチクラウド」です。
システム基盤をマルチクラウド化するときの課題は数多くありますが、ネットワーク基盤整備も大きな課題のひとつです。ひとつずつ整理してみましょう。まずは通信要件です。
通信要件
マルチクラウド環境における通信要件は、大別すると以下の2つです。
- オンプレミス環境と各クラウド間の接続
- クラウド間の接続
1点目はマルチクラウドならではの話では無いので除くとして、2点目が大きな問題になります。パブリッククラウドの基本要素である「VPC」（Azureの場合はVNET、以下単にVPCとします）がクラウドごとに作られるはずですが、もしそれら同士を接続しないのだとすれば単に「オンプレミスでクラウドで構成された基盤が別々に複数ある」というだけです。
「VPC」同士の接続
クラウド間の接続で、まずターゲットになるのは「VPC」同士の接続です。本稿はそこにフォーカスして方式・設計のパターンについてご紹介します。
インターネットで接続する
異なるクラウド間の接続がインターネット経由で接続する方式です。
ゼロトラストネットワークも近年はずいぶん普及しておりひとつのアプローチとして正しいのですが、やはりいわゆる「クライアント-サーバ間」の通信に向いた概念です。いわゆる「システム間通信」すべてを認証・検証して通信することは難しく、防御を固めるとは言え各システム主体をインターネットにさらしておくというのは非常の大きな危険が伴うと考えるべきでしょう。
図：インターネットを介してサーバ間接続する（手書きの拙い絵ですみません．．．）
サイト間VPNで接続する
そこでサイト間VPN接続を考慮します。
図：サイト間VPNで異なるクラウドのVPC同士を接続する
実は各クラウドは別のクラウドの「VPC」とサイト間VPNで接続するための設定手順やパラメータを自社公式ドキュメントで公開しています。
例えばAWS/Azure/Google Cloudの3つのマルチクラウド間の接続を考える場合、以下の3つのドキュメントを参考に三角形の関係を構築すれば各クラウドの「VPC」間は接続できます。
AzureとAWS間のVPN接続
Google CloudとAWS間のVPN接続
Google CloudとAzure間のVPN接続
閉域接続サービス
インターネットを経由するVPN接続はセキュリティの懸念から敬遠される傾向があり、また性能の一貫性という観点からもシステム要件に合致しないかもしれません。そのような場合は「AWS Direct Connect」のような各クラウドの閉域接続サービスを利用することができます。
この閉域接続を利用したクラウド間の接続は様々な構成が考えられます。要点をご紹介していきます。
クラウドの公式サービスを利用する
Azure-OCI間だけ（かつリージョンも限定される）が対象ですが、AzureとOCIはお互いの閉域接続サービスである「ExpressRoute」と「FastConnect」を相互接続しています。これを利用すれば各々のクラウドでパラメータ設定するだけで広帯域・安定なクラウド間接続が実現できます。詳しくは以下のURLを参照してください。
もうひとつがGoogle Cloudが提供する「クロスクラウドインターコネクト」です。Google
Cloudとほかのクラウド（AWS、Azure、OCI、Alibaba）との間の相互接続をサポートするもので、これも各々のクラウドでパラメータ設定をするだけで広帯域・安定なクラウド間接続が実現できます。詳しくは以下のURLを参照してください。
余談：VPNにしても閉域接続サービスにしても、AWSには自身が主導してクラウド間の相互接続を提供するような動きが見られませんね。
自社準備・外部サービスを利用する
公式のサービスでサポートされないクラウド間の接続は利用者自身が準備する必要があります。ひとつのクラウドへの接続を複数束ねるルータ（レイヤ3機器）があれば良いだけであって、端的に言ってしまえば、ひとつのルータから複数のクラウドに接続すればそのルータを介してそれぞれのクラウドは相互に通信が可能です。
このような異なるクラウド同士を仲介するルータ（レイヤ3機器）の構築手法にいくつかの選択肢があり、「オンプレミスネットワークの機器で仲介する」「通信キャリアの機器で仲介する」「クラウドの閉域接続ロケーションの機器で仲介する」「仮想ルータ提供サービスで仲介する」といった方式が考えられます。以下の表に簡単にまとめておきます。
| 方式 | 特徴 |
|---|---|
| オンプレミスネットワークの機器で仲介する | ・自社管理の機器であり構成が容易 ・WAN回線帯域を消費し遅延も大きい |
| 通信キャリアの機器で仲介する | 通信キャリアの仕様で提供可否が左右される |
| クラウドの閉域接続ロケーションの機器で仲介する | ・WAN回線を消費せず遅延も小さい ・コロケーションスペースの確保にコストが必要 |
| 仮想ルータ提供サービスで仲介する | ・WAN回線を消費せず遅延も小さい ・設定・構築のノウハウが少ない |
図：オンプレミスデータセンターまで戻してクラウド間接続するパターン
図：クラウドの閉域接続ロケーションでクラウド間接続するパターン
クラウド間接続における複数のVPC（VNET）を束ねることの重要性
繰り返しになりますがパブリッククラウド基盤を構成する基本要素は「VPC」です。仮想サーバのようなVPC内で動作するリソースを用いていれば当然として、パブリッククラウドの様々なサービスとオンプレミス基盤とを仲介するゲートウェイ的な役割をVPCは果たしています。
先だってのAWS re:Inventのセッションでも触れられていましたが、当初AWSはVPCはひとつだけでそれほど増えないと想定していたそうです。ところが現実は全く異なっており、2個、3個どころか10、100の桁で「VPC」を使うケースが続出しています。そうなった理由は様々でしょうが、ひとつ言えるのは現時点でごく少数の「VPC」だけで済んでいても将来的に100の桁まで増えるかもしれないということです。
これらすべての「VPC」ひとつひとつをVPNや閉域接続で接続していくことは数量的に不可能です。すべての「VPC」が単一（できるだけ少数）のハブに接続することでクラウド単位でまとめて接続していく必要があります。ハブ機能はAWSならば「Transit Gateway」、Azureならば「Virtual WAN」、Google Cloudなら「共有VPC」や「Network Connectivity Center」で提供されています。比較的新しく情報の少ないサービスもありますが、積極的に取り入れていく必要があるでしょう。
図：ハブアンドスポーク型でVPCをまとめてクラウド間接続するアイデア
この点以外にも、クラウド間の通信可否をコントロールするアクセス制御（いわゆるACL＝アクル）、アドレス重複を回避するためのNAT（ネットワークアドレス変換）、限られた帯域を重要な通信に優先使用させるQoS、また場合によっては暗号化も考慮しなければなりません。
おわりに
いかがでしょうか。本稿ではマルチクラウド活用を考えたときに求められる「クラウド間のネットワーク接続」にフォーカスしてその必要性と実装例、検討課題についてご紹介しました。
最後になりますが、本稿のようなマルチクラウドネットワークをテーマとし、マルチクラウド化の必要性と意義、それに必要となる技術や要件を解説した『マルチクラウドネットワークの教科書』という書籍を12月11日に発売します。もしさらに詳しく知っておきたいという方がいらっしゃれば、書店や電子書籍で手にとって見て頂ければ嬉しいです。電子書籍は固定レイアウト型ではなくハイライトも入れられるリフロー型ですので、その点が気になる方も安心してお求め頂けます。