3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について)
はじめに
前回記事で3大クラウドに関して、各々のクラウドのシェアと将来性に関して感想を記述したところ、トレンド1位になったりと大変大きな反響をいただきました。
長い記事であったにも関わらず、目を通してくださった読者の皆様ありがとうございます！
しかしながら、予想外のバズり方をしてしまってだいぶハードルが上がってしまったのと、ちょうど弊社でインパクトの大きい経営施策(シリーズBの資金調達/事業譲渡)が立て続けに執行されたことが相まって、記事第二弾の投下が遅くなってしまいました。
楽しみにしてくださっていた方々、申し訳ございません。
今回から本丸である各々のクラウドインフラの固有の優位性、得意/不得意領域、利用するメリット/デメリットに関して述べていきたいと思います。
当初はAWS, Azure, GCPの順で述べていく予定でしたが、前回記事でAzure固有の優位性に関して引っ張っていた部分があったので、Azure固有の優位性から述べていきます。
Azureの固有の優位性
私がAzureを使っていて感じた、他のクラウドインフラにはない優位性は以下の5つでした。
- VSCode,GitHubへの連携性の高さ
- プロダクションレベルで運用するために必要な基本設定量の少なさ
- ゼロトラストアーキテクチャの組みやすさ
- 過去のMicrosoft資産との互換性の高さ
- Azure OpenAI Service経由でのOpenAIの利用
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付きで構築し、プルリクエストでのコンポーネントの作成フローを整備すると以下のようになります。 私が対応したときには作業開始から完了まで数時間もかかりませんでした。
- Microsoft Learnを見ながら Azure Static Web Appsの設定をAzure側の画面から行ってGitHubと接続する
- GitHubとの接続時にGitHub Actionsを設定できるので、CI/CD pipelineを構成する
- GitHub ActionsでのCI/CD pipelineの構築を正常に行えばそのあとはプルリクエストを上げたタイミングで自動でそのプルリクエストでの差分確認環境が作成され、該当プルリクエスト上にリンクが貼られる(同時作成数には上限あり)
- プルリクエストをレビュアーがマージすると、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点があります。
- サーバールームにWindows Serverがインストールされたオンプレミスのサーバーがあり、VMWare vSphereやHyper-Vを利用して業務システムなどの個々のサーバーのインスタンスを運用している
- 保守期限切れのOSで動いているサーバーがある(Windows 2008 Serverなど)
- Windows Server標準のActive DirectoryでイントラネットのIAM管理をしている
- 非常に高確率で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 ライセンス付き製品に移行する必要があります。
5. Azure OpenAI Service経由でのOpenAIの利用
2022年11月30日にOpenAI社がリリースしたChatGPTによって、生成AIブームが始まりました。
Microsoft社はOpenAI社の大株主であり、2023年にはMicrosoft社の製品にもChatGPT/GPT-4が搭載されています。
2024年にはApple社の製品にもChatGPTの搭載が決定されるなど、OpenAI社の勢いはとどまるところを知らない状態となっています。
Azureでは、ChatGPTやGPT-4などのOpenAIのAPIをAzure OpenAI Service経由で利用できます。
別の記事でも述べているとおり、セキュリティやプライバシーに重点を置いてOpenAIのAPIを利用するのであれば、Azure OpenAI Serviceの利用は一番の選択肢になります。
実際に、多くの企業で生成AI系サービスを実装する際にAzure OpenAI Serviceは利用されています。
もっとも、API経由で自社情報にアクセスするわけではなく、単にブラウザ上でのチャットウィンドウとしての利用が主なユースケースなのであれば、OpenAI社のChatGPT EnterpriseやChatGPT Teamでもセキュリティを担保した利用が可能です。
さいごに
今回はAzure固有の優位性に関して述べていきました。
この記事で私が感じたAzureがシェアを伸ばしている理由が少しでも皆様に伝われば幸いです。
次回はこれを踏まえたAzureの得意/不得意領域とAzureを利用するメリット/デメリットに関して述べていきます。