意外に性格が違っていた二つのクラウドサービス

　クラウドサービスといえば、「Office 365」や「Gmail」のような、いわゆるSaaS（Software as a Service）型のサービスの認知度が高いだろう。一方で、システム構築に利用されるIaaS（Infrastructure as a Service）やPaaS（Platform as a Service）型のサービスも浸透している。後者で広く使われているといえば米Amazon Web Servicesの「Amazon Web Services（AWS）」と、米Microsoftの「Microsoft Azure」だろう。日経NETWORKでは2016年5月号で両者を利用してWebアプリケーションを想定したネットワークシステムの構築方法を紹介した。

　基本的に両者ともできることに大きな差はない。先行して普及したAWSを、追いかけるAzureが機能的にも似せてきて、結局似たような操作が延々繰り返されるのではないか。実は執筆にとりかかるまではそんな懸念を抱えていた。

　実際にサービスを使い始めてみると、段々その違いが際立ってきたような印象があった。どことなく“パソコン的”な緩さが感じられるAzureと、すべての選択肢をユーザーに提示し、コントロールできるようにする“Control Freak”なAWSだ。

トップ画面に性格が出る

図1●Amazon Web Services（AWS）のトップ画面

[画像のクリックで拡大表示]

　象徴的なのがコンソールにログインした直後の画面。AWSはずらっとアイコンが並ぶ（図1）。グループに分けられてはいるものの、階層化はしていない。一覧性が高く、どんなサービスが存在するか一目でわかる利点はあるが、逆にどれが重要視すべきサービスなのかはわかりにくい。ただ、「あなたはこれだけのコントロールができるんですよ」という積極的な働きかけをしているように感じる。

図2●Microsoft Azureのトップ画面

[画像のクリックで拡大表示]

　一方AzureはWindows 8以降で採用したタイル型のユーザーインタフェースを踏襲し、表示するのは稼働状況や作成した仮想マシンなど（図2）。タイルに並べる項目はユーザーが指定できる。すっきりしていて、「現在の稼働状況」を見るには便利だ。しかし、どんなサービスがあるのかは、ここからは見えない。余計な物は見せず、「これが大事なんですよ」とサービス側で決めて提示するという印象だ。

pingコマンドの扱いも違う

　似たようなことは、疎通確認を行うネットワークコマンド「ping」を使ったときにも感じた。AWSの場合、仮想ネットワークのセキュリティ設定でpingコマンドが使うプロトコルであるICMPを通すように設定し、サーバーがICMPに応答するようになっていれば、通常のネットワーク通り疎通を確認できる。ユーザーが正しくコントロールすれば、正しく動作するのだ。

図3●Azureではpingの結果が返ってこない

上側はpingコマンドを10.0.0.4に対して発行した結果。タイムアウトしている。下のarpコマンドで対応するMACアドレスが取得できているので、10.0.0.4は同じサブネットに存在していることがわかる。

[画像のクリックで拡大表示]

　しかしAzureはこれができない。Azureの場合は、仮想マシンのネットワークインタフェースの前に、暗黙的なロードバランサーが介在し、このロードバランサーがICMPプロトコルの通過を認めてないという（詳細はこちら）。このため、pingに対する応答は返ってこないのが標準状態だ（図3）。この暗黙的なロードバランサーが標準で配備されるあたりが、サービス側が「うまくやりますから大丈夫ですよ」というメッセージを出しているように思う。

　pingコマンドが使えないのは、結構痛い。ネットワーク技術者にとって、ごく基本的なツールだからだ。もっとも同じプロトコル（ICMP）を使い、ルーターの経路を表示させるtracerouteコマンドを使うと、なぜか届かないという点ではAWSも似たようなものではある。

グローバルIPアドレスの扱いにも差が

　さらに仮想マシンに割り当てた、グローバルIPアドレスに対する考え方も違っていた。仮想マシンには、起動のたびに変わるグローバルIPアドレスが割り当てられる。これがないと、社内などリモート環境から、クラウドサービスで稼働する仮想マシンを操作できないからだ。

　しかしVPNで社内ネットワークとクラウドに設置した仮想ネットワークをつないだりすれば、必ずしもこうしたアクセスはできなくてもよくなる。起動するたびに変わるとはいえ、公開サーバーでもないのにグローバルIPアドレスを通じて直接インターネットとつながっているというのは心許ない。

　そこでグローバルIPアドレスの割り当てを外そうとすると、Azureは個別の仮想マシン単位でこれが可能だが、AWSはそうではなかった。Azureの方が便利なのだが、冷静に考えるとそれが正しい姿なのかというと多少疑問が残る。

　AWSは仮想マシンが所属するサブネットの単位で、グローバルIPアドレスとひもづけられたゲートウエイ機能「Internet Gateway（IGW）」との接続を外す。確かに普通にネットワーク機器で構成する場合を考えると、ファイアウオールを経由したDMZに公開サーバーを設置する。そしてそのサブネットに所属するコンピュータは公開して、ほかは公開しないようにする。その意味ではAWSの方が、現実のネットワークに向き合っているように思える。

　さらにAzureの場合、グローバルIPアドレスを外した仮想マシンから、インターネットへのアクセスは可能だ。Azureが用意したルーティング機能が、NAPT（Network Address and Port Translation）を実施してアクセスしてくれる。AWSだと、別途NATゲートウエイを設置するなどの操作が必要だ。

　Azureはどうも、「きっとこうしたいだろう」という考えに基づいて、先回りして設定してくれているような印象だ。こういった便利さが、冒頭で述べた“パソコン的”な印象につながっている。「Windowsが便利」というと意外に思われるかもしれないが、以前は「便利そうな機能はどんどん取り入れる」という形で機能を増やしていた。その結果、便利機能が悪用されたため、「Trustworthy Computing」が生まれた。また悪評高いWindows 8のタイルインタフェースや、Microsoft Officeのリボンインタフェースなども、あながち間違ったインタフェースではない。ユーザーの“慣れ”を無視して一新した結果が反発を生んだのであって、最初からあのインタフェースでMicrosoftが想定した「便利さ」に合えば、結構便利なものなのだ。

　思い返してみると、もともとAWSはIaaSとしてスタートした。これに対しAzureは、PaaSを中心にしたサービス構成でスタートした。そうした経緯も、どことなくこうした性格の差に現れているような気がしてならない。IaaSであれば、細かくきっちり設定するのは当然だし、PaaSならばある程度そういった部分を隠蔽してサービスを提供するものだからだ。いずれにしても、三つ子の魂百までとはよく言ったものだな、と思った次第である。