クラウド／データセンターをさらに活用するための最新ネットワークサービス（Part 3）

IaaSからSaaSへ

　クラウド普及の初期には、俗に「インターネット系ビジネス」と呼ばれる企業がIaaSを中心に利用する例が大半だったが、現在では業種を問わずさまざまな企業が利用しており、かつその用途もさまざまな業務アプリケーションをクラウド上で利用する、いわゆる“SaaS”の活用事例が急速に伸びてきている。

　インターネットを介してアプリケーションを利用する、という考え方自体はインターネットの普及初期段階からあり、かつてはASP（Application Service Provider）などと呼ばれていたが、日本ではユーザー企業の“自前主義”の意識がそう簡単には変わらないため、普及しない、などと言われていたことを思い返すと隔世の感がある。当時のASPでは比較的大規模な業務アプリケーションが中心だったが、現在のSaaS普及を牽引しているのはMicrosoftが提供するOffice 365であり、GoogleのG Suiteだったりと、PC上で実行可能な比較的軽量なオフィスアプリケーションであるという点も興味深い。クラウドの普及に伴って従来のITシステムの運用に関わる負荷の見直しが進んだ結果、多数のPC／クライアント端末の管理を行なう負担を削減することのメリットが大きいと判断された結果だろう。

　とはいえ、実際にオフィスアプリケーションをSaaSで運用してみると、従来のネットワーク構成では対応できない部分があることも知られるようになってきた。なかでも多くのユーザーが直面しているのが、セッション数が膨大になるという問題だ。

インターネットブレイクアウト

図1：クラウドサービスへのアクセスは別経路へ迂回する「インターネットブレイクアウト」（出典：IIJ）

　一般的な企業のネットワーク構成では、社内からインターネットに出て行くトラフィックは必ずProxyサーバーを経由させてセキュリティを確保するというポリシーで運用されている例が多い。一般的なウェブアクセスなどに対してはセキュリティ対策として一定の効果が見込める上、構築／運用のノウハウも蓄積されていることから適切なサイジングができており、実運用上Proxyサーバーの存在をあえて意識しなくてはならないような状況はあまりなかったようだ。しかし、特にMicrosoft Office 365で顕著なようだが、アプリケーションを利用する際に多数のセッションが張られる傾向があり、ユーザー当たりのセッション数がOffice 365の運用を開始した途端にそれまでとは比較にならない規模に跳ね上がり、Proxyサーバーの処理能力を超えてしまう問題が顕在化する例が少なくないという。

　Office 365の利用数は順調に伸びているようで、採用企業数が右肩上がりで成長を続ける中で、この問題もよく知られるようになってきており、対策を提供する企業もさまざま出てきている。もっともシンプルな解決策はProxyサーバーのキャパシティ増強だが、これを採用する企業は多くはないようだ。というのも、Proxyサーバーの大規模化には相当なコストが必要であり、その点で二の足を踏む企業が少なくないという。

　次に、よりコストパフォーマンスに優れた対策として打ち出されたのは、ロードバランサーの活用だ。ロードバランサーは、一般的にはウェブサーバーの前段に配置して、外部からウェブサーバーに向けて入ってくるトラフィックを最適化するために利用される機器ではあるが、大量のセッションを効率よく捌くという観点で見ると、一般的なProxyサーバーよりも対応可能なセッション数に余裕があり、コスト面で割安になるといわれる。実際に、ロードバランサーのベンダーには、Office 365のユーザー数拡大を好機とみてセキュリティゲートウェイとしてロードバランサーを活用する、という提案を積極的に展開しているところも見受けられる。

　こうした、機器更新という手段とは異なるアプローチも実用化されている。中でも注目を集め、多くの企業で採り入れられたのが「インターネットブレイクアウト」という手法だ（図1）。これは、Office 365のトラフィックがProxyサーバーを圧迫するという事象にストレートに対応するもので、端的に言えば「Proxyサーバーを迂回する経路を準備し、Office 365のトラフィックだけを選別して迂回経路に流す（ブレイクアウト）ことで、Proxyサーバーの負荷増大を回避する」というやり方だ。この場合、ブレイクアウトされたOffice 365宛のトラフィックはProxyサーバーを経由せずに直接出て行ってしまうことになるのだが、これは通信相手が信頼できるサイトであることが分かっているということで納得する形だ。

　なお、ブレイクアウトのための回線にもいろいろな選択肢があり得る。WAN接続のための専用線が複数経路用意されている場合は、用途ごとに使い分けを行うという形にすることもできるし、専用線の他に公衆網経由のブロードバンド接続を別途使うという手法もあるかも知れない。あるいは、LAN内部のルーティングの工夫によって、LAN内部にProxyを迂回する経路を作り、WAN接続の回線自体は共有する、という手法も考えられなくはないだろう（セキュリティ上別の懸念が生じる可能性もあるが）。

　現在ではインターネットブレイクアウトはクラウドを活用している国内企業の間ではよく知られた手法となりつつあり、対応するサービスもいろいろ出てきている。

SD-WANによる解決策

図2：Silver Peak Systemsの製品は、独自のパケット識別技術「First-packet iQ」によりアプリケーションごとのルーティングを可能にする（出典：マクニカネットワークス）

　インターネットブレイクアウトと一口に言っても実際には構成の仕方は複数存在する。いずれにしても必要なのは、「Office 365のトラフィックを識別して特別な経路にルーティングする」機能で、一般的にはSD-WANソリューションでカバーする例が多いようだ。

　グローバルでSD-WANソリューションを展開するSilver Peak Systemsでは、同社のSD-WANソリューションのユースケースが日本とそれ以外の国々では明確に異なっていると明かしている。

　海外では専用線接続（同社ではMPLSと表現している）のコストは相対的に高い上に信頼性が低いことから、ユーザー企業は専用線接続の問題を回避するためにSDWAN技術を採用し、ブロードバンド回線と専用線を併用することで通信品質を確保しているという。

　一方、日本国内では諸外国と比較すると専用線接続のコストは安価な上、信頼性は極めて高いことから、一般的な企業ユーザーには「専用線接続をバックアップするための別の回線を運用するためにSD-WANを導入する」というニーズはほとんどないという。

　とはいえ国内でもSD-WANの採用数は順調に成長しているそうで、その用途はまさに「インターネットブレイクアウトを実現するため」なのだという。同社では独自技術によるパケット識別技術“First-packet iQ”によってアプリケーションのトラフィックを迅速に識別し、アプリケーションごとにルーティングを行なうことができる。まさに、インターネットブレイクアウトのためにあるような技術だと言える（図2）。

　一方、日本国内のインターネット活用をリードしてきた企業と言える株式会社インターネットイニシアティブ（IIJ）は、同社が提供するSD-WANサービス「IIJ Omnibus（オムニバス）」に「クラウドルーティング」サービスを実装しており、インターネットブレイクアウトに相当するトラフィックの振り分けをクラウド側で実行することを提案している（図3）。

図3：「IIJ Omnibus」で提供する「クラウドルーティング」サービス（出典：IIJ）

　この方式では、社内とクラウドを接続するWAN回線の逼迫には対応できないし、社内LAN側にProxyサーバーを設置／運用していては意味がないことになるが、逆に処理を全てクラウド側で実行できるというメリットにも繋がる。社内にはトラフィックを識別して振り分けるための仕組みは不要で、全てのトラフィックを一律にクラウド側に送ってしまえばよい。クラウド側で動作するクラウドルーティングがトラフィックを適切な経路に振り分けてくれるし、さらに経路ごとに適切なセキュリティ機能を適用することもできる。

　昨今のSaaS活用の流れを、IT部門のマンパワーを業績向上に直結する重要な部分に振り向けるため、煩雑な管理作業を可能な限りオフロードする、という目的だと考えた場合、「Office 365に移行したら従来は存在しなかった“インターネットブレイクアウト”という新たな仕組みの運用管理が必要になった」ということでは、ユーザー企業としては少々釈然としない結果となりそうだ。しかし、こうした仕組みも全てクラウド側に任せてしまうことができれば、少なくとも社内のIT部門が対応すべき運用管理負担を効果的に軽減できることは間違いないだろう。デジタルトランスフォーメーション（DX）が企業が最優先で取り組むべき課題として強調されるようになっている現在、デジタル対応に取り組むマンパワーの確保や、確保した人材をいかに雑事から解放し、企業競争力に直結する部分で力を発揮してもらうかが企業に取って重要な課題となる。こうした観点からは、IIJ Omnibusが提供する各種サービスは多くの企業に取って魅力的なものだと言えるだろう。

SaaS活用の際の留意点

　パブリッククラウド事業者各社はそれぞれ独自機能／独自サービスの実装競争で差別化に邁進している。かつて、IaaSがクラウド利用の中心だった時代には「価格で選ぶ」というユーザーも珍しくはなかったが、現在では、クラウド上で実装したいワークロードの特性とクラウド側の特徴を比較検討して最適なプラットフォームを選ぶことが重要になってきている。さらに、PaaSやSaaSではその差がより顕著であり、他では代替できないことも少なくない。結果として、現在では多くのユーザー企業が複数のクラウドサービスを使い分ける「マルチクラウド環境」に移行しつつある。

　マルチクラウド環境とはいえ、これまで紹介してきたとおり、現状ではさまざまなサービスを閉域網内で利用できる環境が整ってきており、特にセキュリティにセンシティブな業界／企業でもクラウドサービスの活用が可能になってきている点は朗報だろう。しかしながら、マルチクラウド特有の事情に配慮しておく必要がある点は当然と言える。

　まず、セキュリティに関しては、従来のような「境界での防御」という考え方が通用しないことを忘れてはいけない。マルチクラウド環境では、単に社内から複数のクラウドにアクセスするというだけに留まらず、場合によっては社内を経由しないクラウド間での直接通信が発生することになる。しかも、SaaSの利用が拡大しつつある現在では、業務に関係する重要データは全て社内にのみ存在する、という前提を置くことは不可能だろう。

　業務に関連するデータはクラウド上にもさまざま存在しており、かつ、そのデータへのアクセスは社内からだけとは限らない。他のクラウド上で稼働しているサービスからアクセスされる場合もあれば、モバイルユーザーからのアクセスも想定する必要があるだろう。働き方改革が強く推進されている現在、モバイルワーク／リモートワークの比率が今後高まっていくことは確実であり、かつクラウド／SaaSの利用拡大を考え合わせれば、今後多くの業務が社内システムを一切経由せず、モバイルユーザーとクラウドの間で実行されることになるのは間違いない。この場合、こうしたトラフィックのセキュリティを確保する手段は、従来の社内システムのセキュリティとは異なる形にならざるを得ないだろう。

　クラウド環境でのセキュリティ対策としてはCASB（Cloud Access Security Broker）というコンセプトが登場したが、元々のCASBは実のところ「ユーザーと複数のクラウドプロバイダーの間に単一のコントロールポイントを設け」るという境界防御の延長のような発想に基づいて構想されていた。前述の通り、モバイルアクセス／リモートアクセスの増加やクラウド間でのトラフィックの発生など、現在のアクセス経路が多様化していることを想定すると、「全てのアクセスが必ず通過する単一のコントロールポイント」を置くことは不可能に近い。

　こうした状況を受けて、現在主要なCASB製品ではクラウドサービスとAPI連携を行ない、クラウド側で把握しているアクセスの情報を確認する仕組みを導入するようになってきている。現状では、クラウドのセキュリティはクラウド上で確保する手段を考える必要が出てきている。クラウドをリモートにあるリソースとして位置づけ、アクセス経路の途中にセキュリティ・チェックポイントを割り込ませる、という発想から、クラウドの内部にセキュリティ機能を実装しておく、という方向へのシフトが始まっていると考えてよいだろう。

　実際にこうした発想でセキュリティを強化するためにはクラウドプロバイダー側の対応も不可欠なため、現状では全てのクラウドサービスで同じ水準のセキュリティ機能が実現できるとは言い難いが、これは時間が解決してくれる問題だろう。少なくとも、マルチクラウド環境において、アクセスの主要な起点となる社内システムの側だけで充分なセキュリティを確保できるはず、と考えるのは危険である。さらに言えば、各クラウドサービスへのアクセスを閉域網内で完結するようにしたとしても、モバイルアクセス／リモートアクセスが直接クラウドにいく可能性についても考慮しておかないとセキュリティリスクが残ることになる。

　現状では、VPNなどを活用してリモートアクセス／モバイルアクセスのトラフィックを一旦社内に引き込み、社内システムから改めてクラウドサービスに向かう、という構成を採ることが多いようだが、これはWAN接続の帯域を圧迫することにもなるし、モバイルユーザー側から見ると無駄な迂回経路を通ることでレイテンシーが増大することになる。セキュリティと使用感の両立は永遠の課題ではあるが、マルチクラウド環境が多くの企業に取ってごく当たり前となりつつある現在、それぞれの企業ごとに最適解を見つけていく必要があるだろう。