3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について)

はじめに

前回記事で3大クラウドに関して、各々のクラウドのシェアと将来性に関して感想を記述したところ、トレンド1位になったりと大変大きな反響をいただきました。
長い記事であったにも関わらず、目を通してくださった読者の皆様ありがとうございます！

しかしながら、予想外のバズり方をしてしまってだいぶハードルが上がってしまったのと、ちょうど弊社でインパクトの大きい経営施策(シリーズBの資金調達/事業譲渡)が立て続けに執行されたことが相まって、記事第二弾の投下が遅くなってしまいました。

楽しみにしてくださっていた方々、申し訳ございません。

今回から本丸である各々のクラウドインフラの固有の優位性、得意/不得意領域、利用するメリット/デメリットに関して述べていきたいと思います。

当初はAWS, Azure, GCPの順で述べていく予定でしたが、前回記事でAzure固有の優位性に関して引っ張っていた部分があったので、Azure固有の優位性から述べていきます。

Azureの固有の優位性

私がAzureを使っていて感じた、他のクラウドインフラにはない優位性は以下の４つでした。
※ 今後確実に発生するChatGPT関連の優位性も含めると５つになります。

1. VSCode,GitHubへの連携性の高さ
2. プロダクションレベルで運用するために必要な基本設定量の少なさ
3. ゼロトラストアーキテクチャの組みやすさ
4. 過去のMicrosoft資産との互換性の高さ

web業界だと上述1,2の優位性からもたらされる恩恵が大きく、VSCode,GitHubの連携性の高さと基本設定量の少なさを組み合わせると、サービスのPoCからMVP、PMFまで持っていくために必要なインフラエンジニアの負荷を最小化して迅速なリリースにつなげることができます。

以下、個別に詳細を述べていきます。

1. VSCode,GitHubへの連携性の高さ

VSCode(Visual Studio Code)、GitHubは多くのエンジニアに支持されており、エンジニア採用時にGitHubへのコミット内容をチェックしている企業も多く存在しています。
Findy社など、コントリビューション内容を数値化してリクルーティングにつなげるサービスを展開している企業もあります。

VSCodeはMicrosoft社が開発していますし、2018年にGitHubはMicrosoft社に買収されたので、両方Microsoft社の持ちものです。

そして、AzureもMicrosoft社が提供しているクラウドサービスであることもあって、 VSCode,GitHubともにAzureとの高い連携性を誇ります。
Microsoft社がこれらの連携性を高めることが競争優位性になることを意識して買収やリソースの投下をしている印象です。

これにより、VSCodeで開発したものをすぐにAzureにデプロイして確認できる状態を作りやすくなっています。
具体例を上げると、連携性の高さを利用して以下のようなことを簡単に実現できます。

• VSCodeのAzure Toolsを使ってVSCodeでの開発内容を直接Azure FunctionsやAzure App Serviceにデプロイする
• Azure側からGitHubに接続してGitHub ActionsのCI/CD pipelineの設定を行う
• VSCodeのWeb版とGitHub CodeSpacesを使って、AWSのCloud9のようなCloud IDE環境を構成する

AWSやGCPもAzureと同様にVSCodeやGitHubと連携することはできますが、さすがにAzureほど簡単ではない印象でした。

2. プロダクションレベルで運用するための必要設定量の少なさ

AzureはAzure App Serviceや Azure Static Web AppsといったPaaS系のサービスが多く実装されています。

このPaaS系のサービスを利用してプロダクトなどをリリースする場合、リリースまでに必要な設定量が少なく抑えられ、一定のセキュリティレベルを保ったまま迅速なリリースを行うことができます。

設定量を抑えられる反面、細かい調整は難しくなるというトレードオフはありますが、少人数のインフラエンジニア/SREしかいない環境だとこれらのサービスは強い味方になります。

具体例として、GitHub上でStorybookを使ってUIコンポーネントを作成している場合の確認フローをAzureで構成する場合を例示します。

Storybook自体は静的なサイトとなりますし、大規模なバーストトラフィックも無いので、リクエストがあるまでサーバーインスタンスを起動しないタイプのサーバーレスに寄せたほうがインフラコストの削減に繋がります。
それを前提にGitHubで開発を行ってるStorybookをAzureにホスティングするのであればAzure Static Web Appsが適しています。

そして、Azure Static Web AppsでStorybookの環境をCI/CD pipeline付きで構築し、プルリクエストでのコンポーネントの作成フローを整備すると以下のようになります。 私が対応したときには作業開始から完了まで数時間もかかりませんでした。

1. Microsoft Learnを見ながら Azure Static Web Appsの設定をAzure側の画面から行ってGitHubと接続する
2. GitHubとの接続時にGitHub Actionsを設定できるので、CI/CD pipelineを構成する
3. GitHub ActionsでのCI/CD pipelineの構築を正常に行えばそのあとはプルリクエストを上げたタイミングで自動でそのプルリクエストでの差分確認環境が作成され、該当プルリクエスト上にリンクが貼られる(同時作成数には上限あり)
   
4. プルリクエストをレビュアーがマージすると、Storybookのプロダクション環境がゼロダウンタイムで更新され、差分確認環境が破棄される

Azure Static Web Appsを利用した場合、これだけできる環境が基本的には無料 〜 $17.52/月で運用できるので、だいぶコストも抑制できます。 (2023年2月時点)
Azure Static Web Appsは基本httpsになりますし、DDos対策や認証も簡単に対応することができます。

このPaaSサービスはフロントエンジニア/プルリクのレビュアー/インフラエンジニアとどの観点から見てもよくできているなと感じました。

AWSでもAWS Amplifyを使えば同様のフローは実現できますが、さすがにプルリクエストに差分確認環境のリンクを貼るのはAWSにログインしてURLを取得する手作業が必要になりますし、自動化するなら自作のGitHub AppなりAPIを呼び出すスクリプトが必要になるので、ここまで楽にするのは追加工数がかかります。

3. ゼロトラストアーキテクチャの組みやすさ

ゼロトラストアーキテクチャ(ZTA)は情報システム系のセキュリティ領域にはなるのですが、従来型のネットワーク境界型の防御では防ぎきれない不正アクセスを防止するため、アクセスに対して何も信頼せず(ゼロトラスト)常に検証を行うべきというセキュリティアーキテクチャです。

ゼロトラストアーキテクチャ自体は2015年頃から提唱されていたセキュリティアーキテクチャですが、コロナ禍においてリモートワークやパブリッククラウドにあるSaaSサービスでの業務が主流になってきた関係上、ここ数年でかなり注目度が高まりました。

従来型のイントラネットでの境界防御 + PCの社外持ち出し禁止 + PCへのセキュリティソフトの導入というセキュリティ体制だとカバーが難しいサイバー攻撃が増えていることもこの流れに大きく寄与しています。

Microsoft社は世界でもトップクラスにサイバー攻撃を受けている組織であることもあって、セキュリティ系サービスにも力を入れています。
そしてMicrosoft社が提供しているDefender for EndpointやDefender for Cloudなどのセキュリティ系サービスでゼロトラストを実現する際には流石にAzureが一番簡単でした。
これはMicrosoft社が提供しているOffice365やAzure等のクラウドサービスは基本IAMがAzure AD(クラウド版のActive Directory)で統一されていることが大きいです。

ゼロトラストを実現する上でアイデンティティ（IAM）がかなり重要な役割を担うのですが、異なるIAM間だとIAMをSSO(Single Sign On)などで接続する作業が必要となります。
Microsoft社のクラウドサービスのIAMはAzure ADで統一されているので、この接続作業が不要になります。
他にも色々とありますが、ゼロトラストはそのテーマだけで記事をいくつか書けるレベルなので、詳細はここでは割愛します。

4. 過去のMicrosoft資産との互換性の高さ

20年ほど前はMicrosoft社がIT業界で一世を風靡していたこともあって、歴史がある組織ほどMicrosoft社が過去に出してきた製品を多く利用している傾向があります。
過去のMicrosoft資産の互換性がなくなると業務が回らなくなる状態になっている組織も多いのではないでしょうか。
e.g. SilverlightやInternet Explorer(IE)がないとレンダリングできない業務システム、Win32APIに強く依存したマクロ付き神Excel

これらの組織の多くで共通している事実として以下の4点があります。

1. サーバールームにWindows Serverがインストールされたオンプレミスのサーバーがあり、VMWare vSphereやHyper-Vを利用して業務システムなどの個々のサーバーのインスタンスを運用している
2. 保守期限切れのOSで動いているサーバーがある(Windows 2008 Serverなど)
3. Windows Server標準のActive DirectoryでイントラネットのIAM管理をしている
4. 非常に高確率でMicrosoft Office 365を利用している

大企業、公的機関、SIerで蓄積されているオンプレミスのMicrosoft資産(保守期限切れのOSに重要な業務システムが入ったWindows Server VMやActive Directory)を現場業務に影響がない状態でクラウドに移動するクラウドリフトを段階的に進めていくという用途でこれらの組織ではAzureがシェアを伸ばしているんじゃないかと思います。
※ ここに関して明確な調査データを知らないので、あくまで私が知る事実からの推測になります。調査データを保持している方は共有していただけると助かります。

Azureが提供しているサービスを利用すると以下のオペレーションが実現できるので、極力今までのオンプレミスの環境と互換性を保ちつつ、ゼロダウンタイムでオンプレミス環境からハイブリットクラウド、最終的にはフルクラウドという段階的な移行が可能になります。

• Azure VMware Solution（AVS）でIPを変えずに保守期限切れのOSが入ったVMも含めてVMWare vSphereにあるVMをゼロダウンタイムでAzure上にマイグレーションする
• Azure MigrateでHyper-V上で動いているVMをゼロダウンタイムでAzure上にマイグレーションする
• Active DirectoryとMicrosoft Office 365に付随するAzure ADをAzure AD Connectで同期してIAMの情報を一元管理する

少なくとも日本においては、この優位性がここ数年の大企業、公的機関、SIerでのAzureの大幅な伸びに一番貢献していると思われます。

今まで述べてきたAzureの優位性のうち、「ゼロトラストアーキテクチャの組みやすさ」もこれらの組織でのニーズはありますが、私の知る限りこれらの組織でゼロトラストアーキテクチャが導入されているところはまだそんなに多くないです。

リフト&シフト周りはAWSも相当強い領域なので、現時点ではAzureも絶対的な優位性と言えるレベルまでは行ってない印象です。
AWSでもVMware Cloud on AWSやVM Importなどのサービスを利用して同等のクラウドリフトを実現できます。
しかしながら、2022年10月のMicrosoft社製品のライセンス形態の変更により、2025年9月30日以降、Azure以外のクラウドインフラ上でのMicrosoft社製品の利用が制限されます。
これにAWSや現在AWS上でWindows Serverを動かしている顧客、クラウドシフトを考えている将来の顧客がどう対応するかでだいぶ優位性に変化がありそうです。
個人的にはこの後出しジャンケンはさすがにアンフェアじゃないかとは思います…。

AWS では多くのお客様およびパートナーが、ライセンスに関して独自の SPLA を利用しています。AWS のお客様は、ソフトウェアサービスをサードパーティーに提供するシナリオにおいて独自の SPLA を使用できます。Microsoft との SPLA があるお客様には、Services Provider Use Rights (SPUR) が適用されます。SPUR では、インフラストラクチャを AWS にアウトソースする具体的な方法が説明されています。ユーザーがライセンスを取得した製品は、マルチテナント AWS にデプロイしたり、お客様の SPLA の下でライセンス供与したりできます。EC2 専用インフラストラクチャにデプロイするのでない限り、コアまたはプロセッサでライセンスされた製品 (Windows Server, SQL Server) は、AWS ライセンスに含まれるインスタンスにライセンス付与されます。Microsoft の 2022 年 10 月のライセンス変更により、サービスプロバイダーは 2025 年 9 月 30 日までしか AWS 上で独自の SPLA を使用することができません。それ以降は、これらのお客様は、最新化するか、AWS ライセンス付き製品に移行する必要があります。

番外 OpenAI, ChatGPT への対応

この点は未確定情報が多く、私の推測が多分に混ざるため番外とさせてください。
現在の優位性とはなっていませんが、今後非常に高い確率でAzureの固有の優位性になるはずです。

現在、大いに世間を賑わせているChatGPT(GPT 3.5)はOpenAI社が提供しています。
そして、Microsoft社は以前からOpenAI社に積極的に投資をしており、最近はさらに投資を加速しています。

BingやTeamsにChatGPTを組み込んだりとMicrosoft側もかなり本気で自社製品への統合を進めています。

Azureが提供しているAzure OpenAI ServiceではOpenAI社が開発しているAIサービスが利用できます。
そして、ChatGPTもこのサービスに追加されることがMicrosoft社のSatya Nadella CEOによって明言されています。
私もAzure OpenAI ServiceにChatGPTが追加されるのを正座待機してます。
※ なお、Azure OpenAI Service自体もGAにはなりましたが、この記事の公開時点だとプレビュー申請が通らないとリソースが作成できません。

OpenAI社側でもChatGPT(GPT 3.5)のAPIの近日中の提供予定があるので、他のクラウドインフラでもOpenAI社のAPIを利用すればChatGPTを利用すること自体はできる状態になると思われます。

しかしながら、ドメイン固有のデータでの学習はAzure OpenAI Serviceでしかできない状態になる可能性が高いです。
※ これができてしまうとAzure OpenAI Serviceの他のクラウドインフラに対する優位性確保が難しくなるので、さすがに積極的に投資してきたMicrosoft社が許さないはずです。

このドメイン固有のデータでの学習ができるようになった場合、優位性としてはかなりインパクトが大きいものになります。
現在、業務でChatGPTを使うと会社の機密事項がOpenAI社に学習情報として流れてしまいます。
これは情報セキュリティという観点で言えば普通に問題がありますし、自社情報でChatGPTに学習させた結果を他社や不特定多数の人間が利用できてしまう状態になるので、ChatGPTの業務利用を禁止している会社も多いのではないでしょうか。
ドメイン固有の学習ができれば自社のサービス/社内業務向けにChatGPTを強化できますし、情報の流出も防ぎつつ、会社の競争優位性確保に繋げられるため、一気にビジネス上のChatGPTのユースケースを増やすことができます。

Azure OpenAI ServiceでのChatGPTの出方やOpenAI社のChatGPTに関する動き次第で、Google社を含んだ多くの企業の競争優位性自体が失われたり、経営戦略に影響が出る状態なので、世界中の企業のCXOが現在神経を尖らせていることかと思います。
完全にMicrosoft社とOpenAI社の出方待ちなので、現時点でこの点に関して私が言えるのはこれぐらいです。

「この先はキミの目で確かめてくれ！」 (平成のゲーム攻略本風)

さいごに

今回はAzure固有の優位性に関して述べていきました。

この記事で私が感じたAzureがシェアを伸ばしている理由が少しでも皆様に伝われば幸いです。

次回はこれを踏まえたAzureの得意/不得意領域とAzureを利用するメリット/デメリットに関して述べていきます。

おまけ

冒頭でも述べたとおり、弊社では最近シリーズBの資金調達を行いました。

資金面でも余裕ができてようやくアクセルを踏めるようになったので、現在弊社ではエンジニア採用を積極的に行っています。
数年以内のIPOに向けて色々とチャレンジングな問題解決が必要となっている状態ではありますが、技術的なハードシングスに挑むことが好きなエンジニアの方の応募をお待ちしてます！