Azureのこまったちゃん

普段AWSしかまともに触らない（というか一人でマルチクラウドとか現実として厳しい）ので、Azureの案件とか持ってこられても…というInfrabbitです。

 

とはいえ、お世話になっているところからAzureで困ってる、と言われるとまあやるしかないのですが…。

触ってみて思ったのは、まず、「とにもかくにもやたらとブラックボックス化している」というところです。

とにかくGUIからの動きとAPIの動きが全然一致しない。GUIからの操作で平気な顔して複数リソースを形成してしまう。これはAWSでもSaaS系サービスではしょうがないところもあって、ECSとかはそういう側面も多いのだけど、そんな比じゃない。

とにかくほとんどのサービスがそういうことをやらかす。なので、うっかりIaCだとかで何かやろうとすると、どのAPIとどう対比しているのか、が極めて理解しにくい。心底AWSやGCPのAPIデザインが優秀だとわかる。

一方で、GUIでちまちまやるだけ、ならば「必要なもんを勝手に作って勝手になんやかんやしてくれる」というブラックボックスは、「壊れたとき、うまく動かないときどうするのか」ということを一切考えなければとても優秀。

インフラ屋にしてみれば絶対近寄りたくないけれど、一般企業や社内SEなんかにとっては福音なんだろうね。AWSやGCPをがっつり考えなくていい。あとWindowsのことだけやってたいとことか。

 

次に、基礎設計の違い。一番大きいのはやっぱり課金のメカニズム。アカウント＝課金＝クレカという、ECサイトおなじみのスタイルであるAWSなんかとは異なり、Azureにおいては根底に居るのはEntra ID、つまりActiveDirectoryである。

ActiveDirectoryの原則は、１組織１AD。すなわち、課金とはAD＝組織に対する請求であって、ユーザーアカウントに対するものじゃない。そして、その組織の中でOUにあたる区分的に分割しているのがサブスクリプションの概念。

これによって、対１組織に対して複数の課金体型を形成している。

結果、AzureというサービスはAWSのようにアカウントごとに何かサービスが独立区分されて発行されたものではなく、ADに対して１つだけ、Azureというサービスが存在していて、その中をサブスクリプションやテナントで区切って使う、という概念になる。

このため、どんなリソースを作る場合も「どのサブスクリプションで作りますか」という厄介な設定が必ずついて回り、すべてのリソースのきわめてルートに近い場所にサブスクリプションの区分が埋め込まれる。

小さいことだけど、これはこれでとてもめんどくさい。ついでに、リソース名にハイフンやアンダーバーが使用できない場所が多すぎる。命名規則は特殊文字禁止にしないとまともな命名規則すら困難になる。全部キャメルで書けってか。

そして、この基礎設計概念がその上の各サービスの設計に大きな影響を及ぼしていて、厄介極まりない。これとブラックボックス化の合わせ技一本により、こんな制約が生じる。

「サブネットは専用のサブネットを自動的に作成して、その中でこのサービスは稼働する。ネットワークはAzure側で整備するのでお前らは触ることはできない。ついでに他のサブネットと通信したければ専用のプライベートエンドポイントを作成してそれを介して通信せよ」

こんな感じでネットワーク設計すら自由度が極めて抑制される。当たり前のように、PublicサブネットとPrivateサブネットーとか思って作ると、それとは別にApp ServiceサブネットだとかDatabaseサブネットだとか、なんちゃらサブネットとかが気付けば大量に作られて、それぞれで異なるセキュリティルールが組まれて、みたいなことになる。

別に動けば何でもよくて中身なんかどうでもいいならこれでいいんだが、じゃあこの状態で「～～から～～への疎通がうまくいかない」とかいわれてもマジで知ったことではないのである。

だってネットワーク設計から思いっきり逸脱しているからだ。

じゃあ既存ネットワークに組み込めば、ということになるんだが、組み込むにはあれやっちゃダメとかこれやっちゃダメとかいらん制約がぼっこぼこ現れる。それをいちいち解釈して組みなおすだけで日が暮れる。

挙句ドキュメントはWindowsのことばっかりでLinuxなんてオマケ程度しか書かれていない。PowershellPowerShellってうるさい。エラーメッセージはM＄っぽい感じでわかりにくく、ついでに日本語エラーだったり英文だったりと統一性がない。参照リンク先に至ってはとりあえずトラブルシュート集に飛ばしとけ的URLが示される。せめてエラー番号と対になるラベルに飛ばせやｗｗｗｗｗ

APIもサービスごとでびっみょうに違いがあって、とてもやりにくい。TerraformではAzurermというモジュールプロバイダがその辺を頑張ってくれているのだが、ぶっちゃけAzurermはほとんどAzureのサービスをカバーできていない。

じゃあどうするか、というとAzAPIという「AzureAPIを直に叩く」というプロバイダで直接JSON書いてぶったたく。Azureのすべてを操作できる。素晴らしい。

…とでもいうと思ったか死んでしまえ。めんどくさいことを省きたくてやってるIaCでAPI直書きなんてめんどくささを増幅させているだけだ。そして、このAPIでうっかりプロパティの指定サボってデフォルト値が入ったりすると、前述の通り「勝手に何かが作られる」。

いやもうほんと勘弁してほしい。こちとらビルディングブロック設計に慣れてて、要素はすべて制御下にある、というのが基本前提なんだよ。IaCはそもそもそうじゃなきゃダメだろ。ただの手順簡略化ツールじゃないんだよ。ブラックボックスなんて許容したくもない。

 

もともとあんまりゲイツは好きじゃないんだが、Azureのおかげで大っ嫌いになれましたありがとうございます。それでもOffice365使うしかないので使うんだけどさ。Visioないと困るけどさ。SharepointとかExchangeはマジで要らないのでもうちょっと自由にOfficeスイートの製品の取捨選択させてほしいわ。

 

まあ悪口ばかり書いてもしょうがない。いいところも。

Entra IDが基軸、ということは、要するに認証認可がきっちりとサービスから分離している、ということだ。Azureを導入できる＝企業としての1IDのルールとリテラシが浸透している、IDプロバイダが明確化されている、ということに他ならない。

という建前。

実際はどうかというとこの理念をまったく理解してない会社が適当に導入して、なんか統合ID管理サーバとか別にいるのにEntraも導入して、「使うユーザーだけEntraに登録すればいいんだよね？」とかいう概念でID管理サーバがぼこぼこ派生し、営業部のEntraID、管理部のEntraID、開発部のEntraIDみたいなことになった挙句、社内のID管理は別ベンダーの製品です。とか普通にある。

バカじゃないかと思うけど、じゃあAzure使いたい、ってだけの理由で社内の全IDをEntraに統合できますか、って言ったらそれは無理だろうね。そのためにOIDCとかSAMLとかあるんだけど、当然そんなもん考慮すらされない。

で、最終的にID管理できないって言ってくる。知らんわ。設計が悪いわ。かといって再設計でリファクタしようにも大ナタ振るうハメになるので、「そんなことされちゃ困る」って言いだされる。基幹のID管理をOIDCやSAMLで連携するなら当然、ADやEntra使ってる側のアプリはドメインごと変わっちまう話なんだから、そりゃあアプリ改修なしでとかありえないですよ。子ドメインに切るったってそれじゃ乱立してるのと大差ないよね。多少マシ、でしかなくて。どうせそのうちそびえたつ何かになる。その場しのぎで稼ぐ、というだけならそれでもいいとは思うけど、うちとしてはそれが「正しい行為」だとは思わないのでInfrabbitとしてはやらないかな。

マイクロソフトはSIerを殺したいのか。まあ、これはMSが悪いというよりも思想を理解してない使い手側が悪い。ドキュメント通りに作るためにアプリのために独立ADが要ります、なんていうベンダーなんて腐るほど見てきた。

なんで既存ADがいるのに独立ADを立てるのか。そこになんの疑問もなぜ抱かないのか。まあ、その会社の手順書がそうなってるから、とかそういう話になってくるのでこの辺でお口チャック。

 

とはいえ、きちんと設計さえされていれば、そもそもEntra IDはADなのだから優秀なのだ。ADが出来が悪い、なんて思ったことはない。ADは「ちゃんと使えるなら」とんでもなくきちんとしたID管理サーバなのだ。何の気なしにクラスタ組んで、ユーザーに意識させずに双方向レプリケーションをやってのける。

問題はそれが出来る/理解するカスタマーがほとんどいねぇってだけで。あとドキュメントがひどいので誰も読めないし理解に苦しむってだけで。Ciscoとそういう意味では同類。

 

というわけで、Azureの基礎設計自体はEntra IDルーツと考えればそこまで違和感自体はない。そこから設計すりゃこうなるよなって順当進化といえばそうなのだ。そもそもその手前にOffice365がいて、それとの結合もあったわけだし。

というかできればOffice365でSSOと連携させてるんでOfficeのメニューの中にAzure出してくれていいんだけど。なんでAzure行くときだけPortal行かなきゃいけねえんだよ。カスタムアプリにつけろってか。

なので、ADきちんと使えてて、認証認可のID設計がきちんと整備されていてルールが定まっているADを統合ID管理に使ってる、あるいはADと認証連携できるID管理ツールを使いこなせている、そこそこでっかい企業にとっては、AWSのアカウント＝メールアドレスみたいな暴論に対して思うところがあろうというのは想像に難くない。

実際、AWSもIdentity Center入れて管理するなら似たような話にはなってくるが、その場合でもアカウントでパーティショニングされているのはある意味わかりやすい。パーティショニングを超えて管理する際にちょっとめんどいところはあるけれど、OUに対して許可出す、という概念で行ける。

※Azureはそもそもハコが一つなんで、あんま考えないんだと思う。

 

さて、そんなこんなでAzureさんと格闘しているのですが、例えばこれ。

「イメージビルドしている間にタイムアウトしたぜ。タイムアウト伸ばせ」

こんなエラーに見舞われて、タイムアウト伸ばしたりいろいろしていたんですが、原因何だったでしょう、という話。

 

実は、このイメージをビルドしてデプロイする先がVMSSなので、まあプライベートのイメージギャラリーに展開しようと思って、イメージギャラリーをDistributedとしていたんですね。

で、このギャラリーもTerraformで作って、ドキュメント見てたらイメージギャラリーに書き込むロールとかが要るよ、ってんでそういうロール組んでアタッチしていたんです。

 

タイムアウトの原因は、ロールの権限不足。もっとたくさんの権限が要る、Contributorをつけろ、とCoPilotさんに何回も聞いた結果言われる。Contributorってほぼ特権レベルなんですが、いいんですか。最小権限の原則とかどうとらえればいいのかわからないけど、まあリソースに充てるロールだし、いっか。どうせスコープは自分のギャラリー内だけだし。

で、Contributorってどれだよｗｗｗｗｗｗ中途半端に日本語化されたGUIのせいで、どこにあるのかわからない。GUIで確認してTerraformに落とし込みたかったんだが。

で、眺めてたら特権ロールのとこに「共同編集者」…。お前か。お前なのか。わかるかこんなもん。だったら全部英語で書いてあった方がよほどわかるわボケが。

 

というか権限不足ならそんなんAzureのAPIがそういうエラー出せばいいだけだろ、AWSさんなんかもろにどの権限が足りんまでいってくるぞ。なんだタイムアウトって。ただの結果だろそれは。

 

こんなくだらないレベルの問題すら、解決に１日以上かかってしまう、それが私にとってのAzure。AWSだったら30分でおわってる。長くて1時間だ。

 

たぶんこれ、Azure特化のエンジニアなら同様に1時間もかからない。世の営業どもはAWSできるならAzureもGCPも大して違わないと思っているが、現実の効率の問題として、数十倍以上の時間効率とコスト差が生まれる。だってこれ開発環境のAzureに展開して、同じ内容をProduction環境にも作ってってやるんだから「同等ですよ、ミスないですよ」を保証しなきゃならんのでIaCなんて必須も必須。

手でぽちぽちやったものを保証できるのかって言ったらできないんだよ。

やりたいことはただイメージ形成してゴールデンイメージ作ってAutoScalingに適用する、たったそれだけ。基本も基本。だれでもできるしGUI上でやりゃあ終わってるだろうけど、ちゃんとコードにしてエビデンス作って、冪等性確保して、ってきちんとやっていくとそれだけの差が生まれる。

そこを軽視するならそれはもうSIerでも何でもない。ただ、画面でぽちぽちしたらできましたーって言ってるだけの話だし、本人それでいいならいいけど、普通に運用考慮したらそんなもんクソ以下のそびえる何かにあっという間に成り下がる。

そんなもんは社内SEならそれでいいけど、売り物にしてる我々にはダメだ。で、ベンダー違うとそれだけ変わる。時間が。つまりコストが変わる、原価が変わる、価格が変わる。

今回のはワンショットの案件受諾じゃなくて定期契約の中での話だからそこは隠蔽されているけど、実際問題としてはバカみたいに違う。

それをそのままコストとして露呈したら基本「なんだこいつ使えねぇ」って思われちゃうから、だからこそ相手にわからないように時間外も使って勉強したりもするんだけど、そんなん含めたら数十倍じゃきかんのよ。だってかっこつけたいし。こいつ…できる…！って思われたいしｗｗｗｗ

 

そういうわけで、そんなことは最初からわかってるので、クソ時間かかりますよ、というのは言ってあるが、はてさて、彼らが認識しているクソ時間かかる、のクソとは係数何倍で想定したんでしょうね？

 

なお、そんな最中はずっとCopilotさんと愚痴ぼろっぼろこぼしてました。

例えばこんな会話。

 

koga-infrabbit
AWSCLIがわかりやすすぎるのかAzureがごちゃつきすぎているのか。

GitHub Copilot
多くのエンジニアが同じ印象を持っています。
AWS CLIやCloudFormationは「リソース名や構成が直感的でシンプル」なのに対し、Azureはリソース階層やID、プロパティが複雑で冗長になりがちです。

Azureがごちゃついて見える主な理由
リソース階層が深い（サブスクリプション→リソースグループ→ギャラリー→イメージ→バージョン…）
IDやパラメータが長く、明示的な指定が多い
サービスごとにAPIやCLIの設計思想が微妙に異なる
ドキュメントやエラーメッセージが冗長で分かりづらいことがある
IaC（Terraform/Bicep）での記述も冗長になりやすい
AWS CLIが分かりやすい理由
リソース名やコマンドがシンプル
一貫したAPI設計
CLIやIaCの記述量が少なくて済む
補足
Azureも「柔軟性」や「エンタープライズ向けの細かい制御」が強みですが、
学習コストや初期のとっつきやすさはAWSの方が上と感じる人が多いです。

koga-infrabbit
AzureのドキュメントはWindows主体、RDP主体なのでLinuxで何かやろうとすると情報量が少なすぎるんですよ。

GitHub Copilot
おっしゃる通りです。
Azure公式ドキュメントはWindowsやRDP、PowerShell主体の内容が多く、LinuxやSSH、cloud-init、シェルスクリプトでの運用例は圧倒的に情報が少ないのが現状です。

よくある困りごと
Linux VMのカスタマイズや自動化（cloud-init, shell, systemd）に関する公式サンプルが少ない
Azure Image BuilderやVMSSのLinux向けベストプラクティスが見つけにくい
トラブルシュート例もWindows前提が多く、Linuxだと自己解決が必要な場面が多い
Azure CLIやBash例は増えてきたが、深い運用やIaC連携はまだまだ情報不足
対策・おすすめ
英語版ドキュメントやGitHubの公式サンプルを積極的に探す
コミュニティ（Stack Overflow, GitHub Issues, Qiita, Zennなど）でLinux事例を検索
TerraformやAnsible、cloud-initの汎用的な知識を活かして応用する

koga-infrabbit
AWSサポートしてくれればそれでいいよもうｗ

GitHub Copilot
お気持ち、よく分かります！
**「Azureの複雑さに疲れた、AWSの方が分かりやすいしサポートも充実している」**という声は本当に多いです。

もしAWSで同じようなイメージビルドやオートスケール構成を作りたい場合は、

EC2 Image Builder
Auto Scaling Group（ASG）
CloudFormationやTerraform
ECR（Elastic Container Registry）やECS/Fargate
など、より直感的なサービスやIaCでシンプルに構成できます。

 

もう何のためにCopilotに金払ってるのかわからなくなってくるｗｗｗｗｗｗ
ここまでくるとただの世間話してる同僚でしかないです。

 

しかし意地でもAzure触らせようとしてくるCopilotがこちら。