2017年5月25日

3度目の投稿となりますCloud&SDN研究所の加藤です。

BBTower内の謎の組織「Cloud&SDN研究所」ですが、実態は主にクラウド・ネットワーク周りのサービス研究開発部隊で、コーヒー淹れから研究所バックボーン運用まで何でもやります。昨年、研究所にて進めていたサービス dc.connect については無事サービスも始まりまして絶賛サービス提供中です。今回は dc.connect に付随するクラウドインターコネクトを使ってできる事、関連する技術等々をこの場を借りて共有できればと思います。

はじめに: dc.connect とは?(宣伝)

dc.connect は 当社利用のファイバ網を通してAzure, AWS などのパブリッククラウドへ接続をするサービスで、オンプレミス (以下、オンプレ) 環境などへのクラウドインターコネクト (専用線越しのクラウド接続) を提供します。

dc.connnect 大体のサービス図
dc.connnect 大体のサービス図

パブリッククラウドで使用中のネットワークへの経路情報を当社側で用意した通信網およびゲートウェイを通して、ユーザへ提供するサービスです。

もし、 本サービスと同等のクラウド間接続を自前で準備する場合、

  • 自前 (or キャリア契約) のファイバ網の敷設と管理
  • 接続に必要なルータ機器
  • クラウド接続点のラックの契約
  • 継続的なルータ運用

上記を全てを自前でケアする必要があります。本サービスはこれらに冗長化を加えてのサービスとして提供するため、ユーザは安定かつ非常に手離れの良い形でクラウドとオンプレとの接続が可能です。(※ 冗長構成の方法などのカスタマイズについては応相談)。複数のクラウドを同時に使用するマルチクラウド接続も可能です。

なぜクラウドに対して直接接続するか

クラウドインターコネクトによる接続はインターネット網を経由しない直接の通信です。この通信は品質が担保された形で高速にやり取りが出来ます。クラウド内のネットワークとデータやり取りする際、インターネット網経由のVPN越しのアクセスに比べて従量でかかる費用を落とせる事がクラウドインターコネクトの分かりやすいメリットになります。それ以外に、下記のようなシステム的な要求に応える事も可能です。

  • 自分の計算資源をクラウドに組み込む
    • プライベートクラウドとパブリッククラウドと両方使う
      • 繁忙期に一時的に必要なリソースをパブリッククラウドから賄う
    • パブリッククラウドへの移行の為にパブリッククラウドとオンプレ環境を繋ぐ
クラウド-オンプレミス間プライベート接続例
クラウド-オンプレミス間プライベート接続例
  • 自分のネットワーク資源をクラウドに組み込む
      • クラウド側に自分のグローバルIPアドレスを振りインターコネクト経由にする
        • インターネット向けトラフィックを直接クラウドに流す、など
      • パブリッククラウド向けのトラフィックをインターコネクト経由にする
        • パブリック側のPaaS、BLOBストレージなどへのアクセス品質向上

パブリッククラウドと自分の環境を繋ぐ事により、クラウド側から提供される制限されたネットワークに対して設計の幅をもたせることが可能です。昨年の”SORACOMを閉域網で接続する“についても 裏側ではdc.connect にてマルチクラウド (SORACOM(AWS)-Azure間接続) を実現したうえで、目的を実現しています。

クラウドネットワーク (Azureベースの解説)

Azureを例に、パブリッククラウドのネットワークの構造は、

  • プライベートのネットワーク (VNET: 192.168.2.0/24)
    • サブネット1 (Subnet1: 192.168.2.0/27)
    • サブネット2 (Subnet2: 192.168.2.32/27)
    • 外向けのゲートウェイ用ネットワーク (Gateway: 192.168.2.224/27)
AzureとExpressRouteネットワークの大体の図
Azure+ExpressRouteのネットワークの図

で分かれています。各サブネットにはルータが設けられ、それらを纏めるルータとVPNを張る為の外向けのゲートウェイが存在します。いずれのネットワークもルータが存在し、クラウド内で経路を交換します。(例でAzureをベースに書いておりますが、AWSも名前は違いますが”だいたい”同じ設計で動いています) クラウドインターコネクトをする場合、「外向けのゲートウェイ」とオンプレ側の経路情報の交換を行います。

クラウドとの経路交換について

パブリッククラウドにインターコネクト回線だけを用意しても、それだけではクラウドへのインターコネクトを経由した通信にはなりません(インターネットを通ってアクセスをします)。インターコネクトの回線を経由してラウドへアクセスをするためには、その回線越しにアクセスをするための情報を交換(経路交換)する必要があります。

クラウドのネットワークとの経路交換をするためには、 BGP (Border Gateway Protocol) を使えるルータが必要になります。BGPは一般に、中規模以上のネットワークのバックボーンで使われるルーティングプロトコルで、

  • 複雑なプロトコルではないためユニキャストで疎通があれば経路交換が成り立つ
  • OSPFなどのルーティングプロトコルと比較して必要な設定や複雑な計算が少ない

上記の特徴から、VPNや拠点間の1:1のルーティングにも向いており、現在のパブリッククラウドとの殆どでBGPが使われています(BGPがオプションのクラウドも存在します)。また、バックボーンの経路制御で使われているBGPの為、冗長用に正/副2 回線を用意していても柔軟にコントロールが可能です。クラウド向け経路情報を受け取ったオンプレ側ルータでは Local Preference、クラウドからオンプレへ戻る経路は AS-PATH Prepend  にて正/副をコントロールをします。

クラウドとの経路交換することで、パブリッククラウドからプライベートなVNET/VPCのネットワークや、PaaS/BLOBなどのクラウドサービスへのインターコネクトを通る経路情報を受け取ります。逆に、オンプレから送る経路情報は、インターコネクトを通る自分の経路情報を送りますが、現在のところクラウド側で受け取る情報にフィルタは無いため、オンプレ1/オンプレ2、といった複数のネットワークや、デフォルトルートなどの特殊な経路情報※ をクラウド側に渡すことができます。

※ 現在(2017年5月) 、Subnet上流のVNET/VPCのゲートウェイより、外向けゲートウェイの経路情報が優先されています。その為、オンプレ側ルータでデフォルト経路を流すと、クラウド内の仮想マシンはインターネットのアクセスをインターコネクト経由で試みます。

インターコネクト+マルチクラウド

当研究所ではクラウドインターコネクト経由で複数のクラウド(Azure、AWS、試験的にSoftLayer (Bluemix))と接続しています。

オンプレミス環境からパブリッククラウド各社BGP Status
オンプレミス環境からパブリッククラウド各社BGP Status
オンプレミスから複数クラウドへの接続例
オンプレミスから複数クラウドへの接続の図

dc.connect を用いて複数のクラウドを接続した際に、Azure側のBGPルータではオンプレミス側の経路以外に、同時に接続しているAWSの経路も確認できます。元々、私は各クラウドからオンプレミス側のネットワークを共通で見れれば良いかな?と考えて環境を作りましたが、Azure-AWSのインスタンスがdc.connect経由でアクセスできる環境が出来ました。(双方のアクセスを行わない場合は、中心にいるオンプレ側のルータでの経路等のフィルタが必要になります) 接続しているクラウドの数に増減ありますが、現在も便利なのでこのまま使っています。

インターコネクト+マルチクラウドの所感 (まとめ)

クラウドインターコネクトをするために網から設計をすると運用コストを含め物理から考える必要があります。しかし、何かしらのサービスでインターコネクトが出来ると、クラウド間で計算資源やネットワーク資源、データ資源、トラフィックなどを自由に行き来させることが可能になります。

当研究所の検証基盤も一部を複数のクラウド側に乗せていますが、dc.connect を内部で利用することで、都度VPN張ることもなく、引っ越しや環境の再作成が容易にでき、利便性が向上しました。

dc.connect 担当初めの頃はクラウドインターコネクトの利点は「プライベート網を使ってのセキュリティの確保と回線品質の担保」程度にしか考えていませんでしたが、最近では「構成次第で何でも渡せて便利に使えるなぁ」と考えております。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。