コラム

はじめに

こんにちは。BTCクラウドCoEの池浦です。

ハイブリッドクラウド、マルチクラウドをテーマに何回かにわたり書いてみたいと思います。

まず今回はハイブリッドクラウドについてです。

同じようなテーマの記事やブログなどでは取り扱っていない内容も盛り込んだつもりですので、是非最後まで読んでいただけると幸いです。

ハイブリッドクラウドにする意味

ハイブリッドクラウドはオンプレとパブリッククラウドを常時接続して両者を併用する形態ですが、何故ハイブリッドにする必要があるのでしょうか？ 大抵は以下のような理由かと思います。

• オンプレの延長としての利用

オンプレにあったファイルサーバ、メールサーバなどのOA(Office Automation)系のシステムをクラウドに置き、社内から利用するというものです。ファイルサーバやメールサーバなどは容量がどんどん増えていく傾向にあり、拡張が容易なクラウドへの移行は大きなメリットがありました。しかし、OA系のシステムはSaaSへの移行が主流となっており、このような目的でのハイブリッドクラウドは減少傾向にあると思われます。

• 機密性の高いデータとのシステム連携

クラウドが安全かどうかという点についてはここでは触れませんが、セキュリティ面の考慮から機密性の高いデータはオンプレに配置しておきたいという考えが無くなることはないと思います。典型的な例としては、3階層のアーキテクチャのWebシステムにおいて、Web/AP層はクラウドに配置してデータ層はオンプレに持つという使い方です。

• 移行計画の都合

クラウドへの移行はワンショットで一度に完了することはまれで、大抵の場合は段階的に移行していくことが多いのではないでしょうか。そうなるとどうしても移行が完全に終わるまではシステム連携の都合上ハイブリッドクラウドが必要になることがあります。また、主要なパブリッククラウドベンダーは各社移行ツールを提供していますが、ツールによってはハイブリッド構成が前提となっているものがあります。

他にも、オンプレとクラウドにまたがる統合的な運用スキームを構築するなどの理由はあるかもしれませんが、これらのような目的や事情がなければ、ハイブリッドクラウドを構築する必要性はないとも言えます。例えば社内からの利用が前提とはいえ、それほど機密性の高くないデータしか持たないWeb系のシステムのためにわざわざハイブリッド環境を構築するのは大袈裟な気がします。

接続方式について

さて、続いてハイブリッドクラウドを実現するためのキモとなるオンプレとクラウドの接続方式についてです。まずは、以下のクイズについて答えを考えてみてください。

ハイブリッドクラウドの接続に用いられる次の方式のうち、通信の暗号化が担保されているものを全て選択してください。

A：インターネットVPN

B：IP-VPN

C：広域イーサネット

D：専用線

ハイブリッドクラウドの接続方式としてよく使われるのが、インターネットVPN、IP-VPN、広域イーサネット、専用線になります。それぞれ簡単に説明します。

• インターネットVPN

一般的なインターネット回線、インターネット網をつかって、IPsecと呼ばれるプロトコルをつかって通信を暗号化することで仮想的にプライベートな通信を確保します。IPsec-VPNに対応したルータとインターネット回線があれば、他になにも用意する必要がないお手軽さが魅力です。一方で、インターネット網を利用するため、どうしても通信が不安定になります。なお、インターネットVPNの中にはSSL-VPNやリモートアクセスVPNと呼ばれる専用のクライアントソフトを使って実現するものもあります。クライアントソフトを使うのでクライアントVPNとも呼ばれます。これらはクライアント端末と拠点を一時的に接続するために使われますが、ハイブリッドクラウドの様に拠点と拠点を常時接続する場合には適していません。

• IP-VPN

OSI参照モデルのレイヤ3で実現するVPNであり、レイヤ3VPNとも呼ばれます。時々IPsec-VPNと混同している人がいますが、両者は全く異なります。IP-VPNは通信事業者が提供する閉域網を利用したVPNで、MPLS(Multi-Protocol Label Switching)と呼ばれる技術を使用します。MPLSはレイヤ3のIPパケットにラベルを付与することで閉域網の利用者（契約者）の識別を可能にし、仮想的にプライベートな通信を実現しますが、通信の暗号化は行いません。IP-VPNという名前からわかる通り、L3のプロトコルはIPに限られ、ルーティングプロトコルもBGP(Border Gateway Protocol)のみとなります。

• 広域イーサネット

OSI参照モデルのレイヤ2で実現するVPNであり、レイヤ2VPNとも呼ばれます。IP-VPNと同様に通信事業者が提供する閉域網を利用し、QinQ(IEEE8.2.1qトンネリング)と呼ばれる技術を使用します。QinQは利用者（契約者）のトラフィックに対して通信事業者側でVLANタグを追加付与することで仮想的なプライベート通信を実現します。IP-VPNと同様に通信の暗号化は行われません。IP-VPNとの大きな違いは、IP以外のプロトコルを扱うことができ、IPを使う場合も様々なルーティングプロトコル(RIP,OSPF,IGRP等)が利用可能です。IP以外のプロトコルって何だ？と思われる方もいるかもしれませんが、Apple社のAppleTalk(L3はDDP)、旧Novell社のIPX/SPX(L3はIPX)など、現在インターネットで利用されているTCP/IPとは別のプロトコル体系も昔は使われていたようですが、今となっては出会う機会はほとんどないかと思います。ルーティングプロトコルについてもパブリッククラウドとの接続はBGPがデファクトスタンダードとなっており、他のプロトコルが使われることはほぼありません。

• 専用線

二つの拠点間で専用の通信回線を敷設する方法です。前述のVPNとは異なり仮想的ではなく、物理的にプライベートな通信が提供されます。契約者以外は利用できないため、最も安定的でかつ高度なセキュリティが確保されます。通信の暗号化は行われません。OSI参照モデルではレイヤ1にあたるため、上位のプロトコルは広域イーサネット同様に様々なものが利用可能ですが、前述の通りパブリッククラウドの接続に限って言えば使えるプロトコルが多いというのはあまりメリットにはなりません。

専用線はよく高価だといわれますが、実際にどのくらいの金額かイメージができないかたも多いのではないでしょうか。インターネットで公開されていたある価格表によると1Gbpsの専用線の場合、15Km以内で月額約120万円、500Kmになると月額約1,000万円を超えています。たとえば、東京と大阪間で専用線を敷いた場合は400Km以上あるので、月額1,000万円級になるということですね。

リストプライスなので実際の見積もり金額は異なると思いますが、金額感や距離による価格の変化のイメージはできたのではないでしょうか。

以上、簡単にそれぞれの接続方式について説明したところで、先ほどのクイズの答えですが、、、正解は「A」となります。VPN(Virtual Private Network)という言葉が、専用線との比較で語られることが多く、専用線=暗号化無し、VPN=暗号化というイメージを持っていた方もいるのではないでしょうか。VPNは仮想的にプライベートなネットワークを実現するためのものなのでVPN=暗号化ではない、というところがポイントでした。

サービスプロバイダと接続サービスのレイヤ

インターネットVPN以外の接続方式を選択した場合、一般的にはパブリッククラウドに認定を受けたプロバイダのサービスを利用することになります。プロバイダを利用することで、回線やコロケーションの契約を利用者側が個別に行う手間が省けます。コロケーションというのはパブリッククラウドが閉域接続をするために予め回線を引き込んでいるデータセンタのことで、ここにプロバイダ側も回線を引き込んであり、ここで物理的な接続が行われます。相互接続ポイントなどとも呼ばれます。プロバイダを使うか、自前で行うかの違いは以下のようなイメージになります。

さて、プロバイダの提供する接続サービスにはレイヤ2接続とレイヤ3接続の2種類があります。両者の具体的な違いが説明されている資料があまりないので、イメージがし辛いところかと思います。先ほど接続方式のところでレイヤ2VPNとレイヤ3VPNについて触れましたが、このレイヤの違いとは関係がありません。

レイヤ2接続とレイヤ3接続の大きな違いはBGPセッションをどこで結ぶかという点です。以下はレイヤ2接続とレイヤ3接続の構成のイメージ図です。パブリッククラウドやプロバイダによって異なる場合もありますので、参考程度に考えていただければと思いますが、レイヤ2接続ではパブリッククラウドとBGPセッションを結ぶのはオンプレ側の機器となります。一方、レイヤ3接続ではプロバイダ側の機器となります。

おわりに

最近、クラウド移行プロジェクトの提案依頼書などを見ていると、過度なプラットフォーム依存を避けるような要求をちらほら見かけます。例えば、ゴリゴリのサーバレスアーキテクチャではなく、移植性の高いコンテナアーキテクチャが暗に示されていたリ、特定のクラウドベンダーでしか提供されていない機能の利用をできるだけ避ける、といった感じです。この背景には、ここ数年で発生したパブリッククラウドの大規模な障害によるサービス停止が少なからずあるように思えます。一つのクラウドベンダーに依存し、そこから容易に抜け出せなくなることを将来的なリスクと考え、他のクラウドへの移行、あるいはオンプレへの回帰の道を確保するという流れが一部にできつつあるように感じる今日この頃です。つい最近では某クラウドサービスにおいてハイブリッドクラウド用の中核サービスでも障害が発生しました。ハイブリッドクラウドに対する考え方や構築の仕方も、例えばキャリアの選択、冗長化の方式、あるいはマルチクラウド化等々、今後変わってくるかもしれません。

以上、今回はハイブリッドクラウドについて書いてみました。次回はマルチクラウドについて書いてみます。

最後まで読んでいただきありがとうございました。

それではまた！