国内IaaS市場、AWS一強に、挑戦を挑む2つの「巨人」。

　結論から言って、AWSは素晴らしい。AWSが登場する前（Before AWS）とAWSが登場した後(After AWS)では、情報技術の世界は様変わりした。資本力の乏しい個人や小規模事業者も、AWSを使うことで、比較的少ない料金で本格的なインターネット・サービスを立ち上げることが出来るようになった。今ではスタート・アップの企業に限らず、歴史のある有名企業もAWSの導入が進んでいる。

　しかし、この数年、AWSが独断場だったIaaS（Internet as a Service）の世界に、2つの巨人が存在感を示すようになってきている。ひとつはパソコンの巨人「マイクロソフト」(Azure)である。AWSが日本に参入してきた時から、すでに「Azure」は存在していたが、現在のものとはまったく別物だった。2018年からはユーザー・インターフェイスが旧タイプから完全移行し、使いやすさに磨きがかかった印象だ。

　そしてもう一つは、検索エンジンの巨人「Google(GCP)」だ。以前は「Googleエンジン」というPaas(Platform as a Service)中心のサービスだったが、昨年のGoogleのイベント(Google Cloud Next 17 Tokyo)では、多用なサービス群を持つGoogleが、他サービスを脇に置いて、本国米国から沢山のGCPエンジニアを東京に集める本気ぶりだ。

　現在のIaaSは、AWSの一強に2つの巨人が真っ向から挑む格好となっている。

AWSは、ホームページ制作者にとってまるで「迷路」のようだ。

AWSは、IaaSにおける実質的な「デフェクト・スタンダード」のようになっている。そのため、AWSと比較対照するサービスがなかった時、「そんなものんか」と思いながら、特段疑問を持つこともなく、AWS流のやり方を覚えようと、多くの開発者は必死だったように思う。

　開発段階では教則本を見ながら、ひとつひとつ確かめながら作っていったら良いのだが、運用段階に入ると、自分が何を、どこに、どのようにしたのかを忘れてしまい、AWSのサービスの中を右往左往してしまう。

　例えばこんな感じだ。ワードプレスを使ったホームページをつくろうとすると、まずはEC2でインスタンスを立ち上げ、RDSでデータベースを作り、EC2とRDSのネットワークをカスタムで構築(VPC)する。そして最後に、Route53で、ドメインのレコードを変えて、独自ドメインを導入する。

EC2に代表されるAWSだが、Saasやエンタープライズ向けソリューションも提供している

しかし開発から時間がたった後、運用段階に入り、AWSにログインすると、まるで「迷路」の入り口に立ったような気分になる。自分がどのインスタンスを使い、どのネットワークで、どのデータベース使ったのかを、改めて整理する必要がある。もちろん開発がこれで止まれば、問題はないのだが、次から次へと同じようなものが誕生すると、この混乱ぶりにある種の怖さを覚える。

　そんな時、2つの「巨人」を触ってみると、AWSとは異なり、もう一つ上に階層があることに気が付いた。Azureでは、「リソース」と呼び、GCPでは、「プロジェクト」と呼ぶ。これらは基本的に同じで、それぞれのサービスを一つにまとめる「フォルダ」のような感じだと思えばよい。これのフォルダが上位に存在するだけで、横断的に広がるサービスを顧客単位・プロジェクト単位・サービス単位でまとめることができ、サービスとプロジェクトを一目で関連付けることができるようになる。

　IaaSの世界では、どこも開発段階に焦点が当てられ、よくインスタンスが数秒で立ち上がり、コード管理がよくできているみたいなことが売り文句となっているが、こういったことは将来的に特別なことではなくなっている。今後は、いかに運用段階を効率的に行うかの「マネージメント機能」が重要になってくるように思う。

AWSのカスタム・ネットワーク構築がさらに混乱を深めている。

AWSはEC2を立ち上げると、自動的にデフォルトのネットワークが構築されるが、安全なネットワークを作ろうとすると、EC2内で「Webサーバー」と、「データベース・サーバー（DBサーバー）」を別けて、DBサーバーは「NAT」を通したプライベート・ネットワーク（公開されていない）で管理し、Webサーバーはパブリック・ネットワーク（公開されている）で管理をするみたいケースをよく見る。　　そこでAWS内でネットワークを構築しようとすると、まずは以下の2つを理解する必要がある。それは「リージョン」と「アベイラビリティーゾーン(AZ)」である。

「リージョン」と「アベイラビリティーゾーン」の関係図

そして、VPC内にサブネットを構築し、それぞれのサーバー（Webサーバー・DBサーバー）を配置する。その時、VPCはリージョンをまたぐことはできず、またサブネットも複数のAZをまたいで構築することはできない。

あ、っという間に増えるサブネット

整理をすると、リージョンとAZとVPCとサブネットの関係は以下のようなる。

これらの構成を理解して、どこに配置したかを覚え、それを管理するというのは正直、なかなか骨が折れる作業だが、AWSしかなかった時は「まぁ、こんなものか」と深く考えずにただ覚えるしかなかった。

しかし、GCPだと、そもそもこのような構成がない。

詳細は割愛をするが、GCPは、AWSのようにVPCとリージョンを紐付けたネットワークではなく、デフォルトからリージョンをまたいでネットワークが構成されている。そのため全リージョンをまたいで、インスタンスにアクセスをすることができる。

要するに、GCPは、世界中どのリージョンからでもインスタンスをアクセスすることができるため、リージョン内を小分けにしたAZに配置し、そこをVPCで構成し、AZと紐付けた「サブネット」的な考え方がそもそもない。そこでGCP内の「サブネット」の役割は、単純にわかりやすく名前をつけただけという感じだ。

AWSしか知らなかった時は、「ネットワーク」はこういうものだと思っていたが、いざ他を知れば、AWSのネットワークの複雑さが際立っているように見えた。

それでも、AWSが国内で一番良い理由。

散々、AWSの悪口を書いてきたが、やはりそれでもAWSがIaaSの世界では最も良いと思う。AWSは単純にネットワーク(VPC)やコンピューティング(EC2)だけでなく、ストレージ(S3)や、エンタープライズ・アプリケーションや、開発ツールなど多種多様に及ぶ奥深いものである。そのためひとつのサービスを抜き出して、論評するのも良いが、やはりサービス全体を俯瞰して見れば、これほどのサービスは他に見当たらない。

　また、ユーザー数が最も多く、AWSの多種多様に渡るサービスを試し、失敗し、それを事細かくブログに掲載をしているため、インターネットを覗けば最新のリファレンスに事欠かない。そのため、使い勝手の悪さでも、リファレンスのお陰で、十分ゴールまでたどり着くことができる。逆に、使い勝手がよいサービスでも、最新のリファレンスがなければ正直、ゴールまでたどり着くことが難しいように思う。

　最後に、現在「世界シェア34%」でコンシューマー向けではなく、当初からエンタープライズを意識して始まっていることに安心感を覚える。恐らくSaaSも含めたクラウドサービスの多くは、コンシューマー向けとして始まっており、突然サービス停止やサービスの統合などということは珍しくない。

　しかし、恐らくシェア34%の多くが、企業が占めており、既存サービスの舵を切るスピードは遅いかもしれないが、突然のサービス停止やサービス統合は考えにくい。インフラ・サービスは、使いやすさも重要だが、「安定感」こそが、なによりも大切のように思う。そこを裏切るサービスが最も、「使いにくいサービス」だと思う。
　