これからはじめる Azure の基礎知識

まいど AWS の犬が、少々 Azure に触れてみましたので、絵は描かずに基礎知識の整理と共有だけしていきたいと思います。

全然ド素人な状態なので、なにかしら間違ってたり不足していると思われますが、同じようにイチから調べる人の足がかりにでもなれば、くらいの質感で進めていきます。



はじめに

今のところ少々用事があっただけなので、これから Azure を掘り下げるぞとか、Azure の犬になるぞ、とかは考えていなく一発ネタで終わる可能性が高いです。雑なメモをブログに起こして、いったんの区切りとする個人的な清書のため、詳しくはちゃんとリンク先のドキュメントなどを読んでくださいませ。

さて、AWS に似たパブリッククラウドはいくつもあり、Azure もその１つです。公式ドキュメントに何箇所も AWS との比較が出てくるくらいには、Azure も AWS を意識しています。

シェア率は AWS 31% に対して Azure 26% と非常に近くなっており、クラウドを扱うエンジニアなら知っておいても損はないのかなと思いつつ、しかしながら情報量はシェア率に比べて少ない体感なので、その辺をどう捉えるかってのも重要な要素となりそうです。

とはいえさすが大手クラウドというくらいには情報があるので、今回はインフラ基盤的な部分はこのくらい知っておけばアトは進められるでしょう、ってとこまで整理します。書籍や講習に一切頼らずネットサーフィンでビッグウェーブしただけなのでアレですが、初手として表面知識を得る場所になれたらなって感じです。


一般教養

更新情報

Azure も AWS re:Invent 規模とまではいかなくともイベントを開いたり、公式ブログがあったりするので、深追いしていく場合は↓この辺りをチェックしたり、好きなブログをRSSリーダーに登録していくことになります。


個人的には Azure なら NAT G/W 不要にできるんか！って知った瞬間に『規定の送信アクセスの廃止』によって糠喜びになったのが、最高にハイってやつでした;-)

価格

いきなり価格を知ってもアレなんですが、価格ページが非常に見やすくまとまっているので、どのようなカテゴリやシステムが存在するのかをザッと眺めてみたり、他社との比較をしてみるってのは良い初手になりそうです。


個別の価格ページは、以下で必要そうだったら貼っていきます。


Account

アカウント周りは AWS より複雑と思われ、良し悪しあるところですが、アカウント数・組織やユーザーの管理・請求管理など大事なところですので、使うならキッチリ理解した方がよいです。

リンク


単語

AWS だとアカウント直下に VPC を作るところから始まり、アカウント単位で請求されますが、Azure の場合はそれにあたるのは Subscription となります。ちなみに GCP もアカウント内で Project 単位に分けるタイプです。

Account大元のアカウントという単位
Tenantアカウント内における権限の管理範囲のこと
Microsoft Entra IDMicrosoft が提供する ID ・アクセス管理サービスで、Tenant 内に必ず１つ存在する。旧名 Azure AD (Active Directory)
Subscription請求の切り分け単位

組織の方針によっては、1 account : 1 service や、1 account : 1 environment で運用したり、ユーザーの管理データが異なるでしょうから、この辺はクラウド毎に合わせて頑張るしかないですね。


Role

Role 周りは AWS に似ているようで異なり、慣れないだけかもだけど少し理解しづらい感じはあります。まぁ AWS も最初はわかりづらいのは一緒か。

リンク


単語

ザックリとならこのくらい知っておけば大丈夫そうです、多分。

Entra Roleユーザーやグループへ割り当てる Role
Azure RoleAzure 内のリソースへ割り当てる Role
Security Principal以下４つのアクセス権限を要求するオブジェクト
  • Uesr
  • Group
  • Service Principal
  • Managed Identity
Scopeアクセス権限のグループ化で、下記の上から順に親子関係となる
上位で割り当てた Role は下位に引き継がれる
  • Management Group
  • Subscription
  • Resource Group
  • Resource


Auth

Role と若干話が近いところですが、こっちは User 寄りということで分けておきます。

リンク


単語

Terraform を手元や外部システムで実行したければ Service Principal が必要になるので、あとでその辺りも触れます。

Userポータルへのログインを必要とする認証
Managed IDAzure リソース自体に割り当てる認証
Service PrincipalAzure 外のリソースが扱うための認証
手元の開発環境での Terraform などがこれに当たる


Network

本記事で書くべき箇所はほぼココなので、いっぱい項目があります。かなり AWS と似ているので、そこまで苦労はしないけど面倒くさいことに変わりはないです。

全般

細かい項目の前に、全般的な情報を置いておきます。


Region

Region の概念は AWS と同じで、ある地域の中の複数の AZ の集まりという感じです。

日本だと東日本 (japaneast) と西日本 (japanwest) の２つがあります。

Availability Zone (AZ)

これも AWS と同じで、Region の中で可用性をもたせるための物理的なデータセンターの単位です。

Virtual Network (VNet)

AWS の VCP と同じで CIDR を割り当てる入れ物です。

Subnet

Subnet という概念は同じですが、この辺から AWS と若干雰囲気が変わってきます。


まず AWS との大きな違いは、AZ 別に CIDR を割り当てるのではなく、AZ にまたがった１つの CIDR になるというところで、これはこの方が利便性が良いと思われます。

もう１つ変わった違いがあり、以下のようないくつかの仕組みには『専用 Subnet』が必要であると記述されているところです。
  • VPN Gateway
  • Bastion
実際に試したわけではないですが、もし通常使いの Subnet で VNet の CIDR を全て埋めてしまうと取り返しがつかなくなる可能性があるため、余白を残す設計にしておくのが無難かもしれません。

そして気になる Public / Private の分別ですが、やはり基本的には分けて設計するのが良さそうです。最初は『規定の送信アクセス』という機能の存在で迷いましたが、将来的に廃止されることで、結局は Private なリソースにも特定のインターネット接続の手段を用意する必要があることになり、AWS と同じ構成になるでしょう。

Network Security Group (NSG)

AWS での SecurityGroup なので、かなり重要な要素です。


AWS は Subnet には『Network ACL』をステートレスで、リソースの NIC に『Security Group』をステートフルで設定していたところ、Azure は Subnet にもリソースの NIC にも Network Security Group をステートフルで割り当てます。

どう設計するかは好みの問題かもですが、基本的には NSG をリソース単位で割り当てるだけ、がわかりやすいのではないかと思います。

Subnet と NIC でのトラフィック制御はそれぞれ独立していて、例えば NIC で 80番ポートを通していたとしても、Subnet の NSG も有効なら 80番ポートが空いていないと NIC にたどり着くことはできません。

選択肢としては Subnet だけで一括して管理するか、NIC だけで各リソースを管理するか、両方有効にするか、ですが、両方有効にするのはおそらく Subnet 側に NIC 側の全てのポートを登録することになるので、効果は変わらず管理が面倒になるだけだと思われます。

Service Endpoint / Private Link

Storage や SQL Database といった Azure PaaS は、そのまま利用するとインターネット経由で接続されるため、通常は Service Endpoint を利用することになりそうです。Private Link は Azure 外のオンプレからも～など 要件によって使い分けるという感じ。


なにもしない通常は PublicIP でインターネット経由、Service Endpoint は PublicIP だけど Azure 内部経路、Private Link は PrivateIP ということで、わりと重要な設計要素になってくるので理解しておく必要があります。

構築時に Service Endpoint は Subnet 側でも設定が必要、などあるので必要に応じて IaC に組み込んでいけばよいです。

また少し外れた話題として、AWS では AWS 内での PublicIP 接続はインターネット経由をするのか、といった疑問に明確な回答がありました。
オンプレやプライベートクラウドを構築したことがあると、物理ネットワーク的にいちいち Global なインターネットに出ないでしょってイメージできるところではありますが、じゃあ AZ 間は？となると中の人にしかわからないわけで、明確な回答はかなり重要な部分となります。

では Azure はとなると情報は見つけられませんでしたが、重要なデータ保存系システムにおいてデフォルトはオープンな PublicIP 接続ですよと言われれば、そりゃそのままではアカンですわとなるわけで、ブラックボックス内に関係なくキッチリ設計しましょうというだけです。

※追記：ありました。教えてもらいました

Public IP

PublicIP には Basic と Standard があり、簡単に言うと Standard の方が高機能な感じなのですが、一応軽く違いを知っておきつつも Basic SKU は廃止予定ということで無駄に悩む必要もなくなる箇所かと思われます。


AWS でも今年２月から PublicIPv4 が有料化され、Azure も有料で同価格となっています。

AWS だと動的な PublicIP 静的な ElasticIP という感じで、Azure はより複雑かなと思いきや Basic 廃止によってこちらもシンプルになると言ってよいのかな、という印象です。

VNet Peering

VNet 間を繋げる仕組みは AWS の VPC Peering と似て難しくはないです。複数サービスでの全体構成を考える時に重要なので抑えておきましょう。


VPN Gateway

VPN も Azure 外との接続が必要な時に重要なところです。費用や可用性を考慮して、VPN Gateway を使うのか VM で構築するのか、を考えていきます。


NAT Gateway

NAT G/W ができたのが 2020年 ということで新しめです。AWS 同様、ここで事故らないようにしっかり設計していきましょう。


Network Watcher

ネットワーク系の監視機能が、自動的に有効化されているということで存在は知っておいたほうがよさげです。



Load Balancer

ここで Load Balancer と表記すると紛らわしいかもですが、トラフィックの負荷分散の仕組みというカテゴリで、だいたいこの辺を抑えておけばよさげという感じです。

Azure Load Balancer

これが紛らわしい理由で、L4 動作のロードバランサーです。AWS での NLB に相当すると考えてよさげ。


Azure Application Gateway v2

L4/L7,TLS で動作する多機能なロードバランサーです。AWS の ALB 相当プラス色々って感じか。v1 は既に非推奨になっているので、v2 しか知る必要はなさそうです。


Traffic Manager

DNSベースの分散ということで、一応抑えておく程度。


Front Door

リージョンではなくグローバルなL7分散、かつ WAF やら CDN やら色々で、これも抑えておく程度か。



SSL/TLS

SSL証明書は今や公開サービスに必須なのでチェックです。AWS だと ALB + ACM なところ、Azure だとややわかりづらい感じがありそうです。



CDN

CDN はクラウド外にも色々あって、必ずしもそのクラウドのを使う必要はないため、一応チェック程度。大規模な利用量だと、コミコミで安くなることもあるかもなので、CDN としての機能と両面での相談ですかね。



DB / KVS

深く踏み込まず比較程度まで。一通りマネージドなミドルウェアは揃ってますよ、ということで。



VM

ここでは簡単にインスタンスまで。コンテナはめんどくさいので省略です。

全般

慣れるまで VM スペックを表す表記ルールが気持ち悪いかもしれません。また、どれが最新でお得なのかも理解しづらいのですが、AWS でそれを把握しているのは単に CPU 性能についてキチンとブログで追った結果なだけかもですね。


SSH

ネットワーク基盤とかを構築した際に、疎通確認などのために SSH で操作するのが簡単なので。


Command

VM でもコンテナでも API 経由でコマンドを実行できます。


節約利用

AWS 同様、スポットインスタンスがあり、オンデマンドの 75～90% OFF とかなり安いので、使い込むならインスタンスタイプの選定と、安全な活用方法を考えるとよさげです。

他にも AWS での Reserved Instance や Savings Plans 相当の仕組みもあるようです。

インスタンスサイズ

最小サイズは B1ls の 1vCPU 0.5 GiB で、1vCPU 未満は存在しないようです。

最大は 128 – 208 vCPU , 2048 – 3800 GiB くらいまでありますが、申請しないとクォータで引っかかって使えないです。


Tool

とりあえず手元で CLI を使えると色々捗るので、使えるようにします。


Install

例えばこんな感じです。


Login

コマンドを打つと URL とコードが出るので、ログイン済みのブラウザでアクセスしてコードを貼り付けると、コマンド側が勝手に進行してログイン状態となります。


ログイン後はローカルのこの辺にキャッシュされます。



Terraform

最後に軽く Terraform で土台を作るまでのところまで整理します。

User

正確には Service Principal ですが、まずは Terraform を実行するユーザーを作成します。もちろん、これを閲覧・作成する権限のある作業者である必要があります。

Microsoft Entra ID → アプリの登録 から新規作成し、新しいクライアント・シークレットを作成して『値』をコピーしておきます。この値は provider の client_secret で指定します。

ついでにサイドバーの概要に遷移し、アプリケーションID = client_id , ディレクトリID = tenant_id をコピーしておきます。

Role

該当 Subscription のアクセス制御 (IAM) でロールの割り当てを追加します。

とりあえず共同作成者など強めの権限を、さきほどの Service Principal に割り当て、必要があればあとで権限を制限してください。

ついでに、概要からサブスクリプションID = subscription_id をコピーしておきます。

Code

まずは provider から。


最初に VNet と行きたいところですが、Azure ではリソースグループになります。


次に組織内での CIDR を設計してから、VNet を作ります。

そして設計したとおりに、おそらく public / private で Subnet を作ります。

あとは VM などのリソースに割り当てる NSG を作り、

VM 作成後は簡単なテストならパスワード認証でもいいし、公開鍵を使うなら登録しておいたりします。ちなみに、デフォルトユーザー名は azureuser で、sudo -i で root になれます。

これ以上は設計次第で、VNet Peering や VPN を繋いだり、社員のユーザー管理を整理したり、などなど忙しくなっていきます。

管理画面の何も無い状態で VM 作成をすると、自動的に VNet, Subnet, NSG あたりが作成されるので、最初はそういうのを画面で見ながら Terraform コードを書いていってもよいかもしれません。


おわりに

これまで色々なクラウドに触れつつも、ようやく Azure の表面に触れてみた感想としては、

改めて整理してみると、この程度の理解と構築までなら、特に情報に苦労することなく進めることができるので、業界第二位は伊達じゃないといったところでしょうか。体感としては、Microsoft らしい触感(?)がありつつも、思ったより触り心地は悪くない、といった印象です。

検討するなら Azure ならではの機能を目的としてそれに合わせて最適化したり、各システムの性能・安定性・コストパフォーマンスなどの総合力を比較したり、規模が大きめなら営業担当者やサポートの腕前、ボリュームディスカウントといった方面も重要になるといったところ。


これから初めてクラウドを選定するぞ、という組織はもう少ないかもですが、検討する選択肢の１つに Azure をサクッと入れるってのは少なくとも悪くはないかなってのと、

１つしかクラウドを知らないぞ、という組織やエンジニアはぼちぼちいるかもなので、２つ目以降に Azure ってどうなんって知ろうとするってのにもほどよい対象になると思われます。


まぁ正直なところ、サービスを動かすだけならどのクラウドでも可能なので、どこを使うかは技術力よりも政治的なところで決まることもありますが──

それでもエンジニアとしては、コスパや品質の判断をできるようにしておくってのと、複数のクラウドを扱える設計、ユーザーの統一管理、といった根本的な部分を綺麗に仕上げておくのが大事かなと思う今日このごろです:-)

Posted on 2024/06/11   カテゴリー: Azure, Cloud, これからはじめる パーマリンク