オンプレミスインフラエンジニアのためのMicrosoft Azure入門 – Azure Resource Manager

オンプレミスインフラエンジニアのためのMicrosoft Azure入門 – Azure Resource Manager

オンプレミスインフラエンジニアのためのMicrosoft Azure入門 – Azure Resource Manager

はじめに

本シリーズは、Microsoft Azureを中心にパブリッククラウドについて手短に学ぶ事を目的にした記事です。

既にウェブ上にはテーマに関する優れたコンテンツも多くありますので、どちらかといえば私自身の言葉で説明をすることも意識はしつつ、いくつかおすすめのURLを掲示する“まとめサイト“的な位置付けを目指したいと思います。

今回は、Azure上で仮想マシンをはじめとするリソースを展開する際に使用されている仕組みの1つである、”Azure リソースマネージャ(ARM)”について紹介します。

リソースとは

直訳すれば、“資源“という英単語の意味です。

Microsoft Azureでは、管理できる対象1つ1つのことをリソースと呼びます。

具体的には、次のようなものはリソースと呼びます。

仮想マシン
ストレージアカウント
Webアプリ
データベース
仮想ネットワーク
リソースグループ
サブスクリプション
管理グループ
タグ

こうしてみると、かなり幅広い属性にわたり、リソースという用語が使用されています。

私個人の解釈としては、Windows OS上で取り扱う”ファイル”という用語に似ているなと感じています。
実際、ファイルには次のような種類がありますしね。

txt
csv
doc/docx
xls/xlsx
ppt/pptx
pst/pstx

などなど。

なお、リソース関連の用語定義はAzure Resource Manager とは- Microsoft Azureをご覧ください。

リソースグループとは？

リソースグループは、複数のリソースを集約した単位の呼称です。

上記で、”リソースはファイルに似ている”という例えを使いましたが、この例えに近いものとしては”リソースグループはフォルダに似ている”というのはありかもしれません。

イメージ図：1つのフォルダに色々な種類のファイルを保存している様子

1つのフォルダには、様々なタイプのファイルを保存することが出来ます。実際に、1つのリソースグループには色々なタイプのリソースを含めることが出来ます。

イメージ図：1つのリソースグループに色々な種類のリソースが保存されている様子

図を見てみると明らかですが、1台の仮想マシンであっても、仮想マシン、ディスク、仮想ネットワークアダプタなど複数のリソースが関連付いていることが確認できます。(上図内では、vm-windows-001とvm-windows-002という仮想マシン2台のリソースが、rg-az104-test-001という名前の1つのリソースグループに含まれている状態を示しています。)

後述していますが、ARM環境では仮想マシン作成の際にこれらをまとめて適切な順序で作成をしてくれます。

リソースグループを使用する理由、メリット

まず初めに、Azure Resrouce Managerという機能は2014年にリリースされました。

本機能の前身となるのが、Azure Service Manager(ASM)です。私がAzure環境を触れるようになったのは2021年から徐々にでしたので、既にASMではなくARMが主流となってからのため、ユーザー体験としてASMに触れたことはないのですが、ASM環境では次のようなチャレンジがあったようです。

1つの仮想マシンを作る場合でも、関連するリソースを1つ1つ手作業で作る必要がある。
上記に関して、作成順番も考慮しなくてはならない。
リソース削除の際も、1つ1つ手作業で行う必要がある。
タグ付け機能も使用できない。(正しい請求ができない)

クラウド環境では、迅速性やコストの可視性、オーケストレートされた構成要素の管理などが重要視される中、ASMではそれらが実現できなかったのでしょう。

ARMが登場したきっかけは、まさに上記のクラウド環境がもつ基本要素の提供にあったと言えます。

なお、上述の歴史的背景については以下のリンク内に原文があります。

Azure Resource Manager とクラシックデプロイ: デプロイモデルとリソースの状態について – Microsoft Azure

リソースグループは仮想マシンのパフォーマンスやセキュリティに対して機能するものではなく、デプロイタスクやコスト管理、操作権限制御など、管理系タスクを支援してくれるという性質があると覚えておくとよいでしょう。

またリソースの考え方については、Microsoft様提供のYoutubeチャンネル内でも紹介があります。

リソースグループに関するベストプラクティス

Windows OS上でのフォルダが、リソースグループのようなものであるという例えは使いましたが、”では実際に、OS上で効果的にファイルやフォルダを管理する方法ってどうだろう？”と考えると、これは結構人によって様々分かれそうな気がします。

リソースグループについても自由度がある一方で、逆に言えばある程度”一般的なお作法”がある方が利用者からするとありがたいと思います。

そこでMicrosoft Azureのページを確認していた所、次の情報にたどり着きました。

上記URLを参照することで、組織で運用するAzure環境に対して、何個リソースグループを作成すべきかや、その名付けルールのお手本を学ぶことができます。

リソースとリージョンの関係

これは、Microsoft Azureの支援を受けた際に私もとても混乱した点でした。

例えば、”仮想マシンは東日本リージョンに配置しよう”と思って作成をします。
仮想マシンはリソースの集合体そのものですが、”リソースグループ”にもリージョンの指定が可能です。

やろうと思えば”西日本リージョンにあるリソースグループの中に、東日本リージョンで動作する仮想マシンを作成する”という事も可能だという事です。

普通に考えれば、”仮想マシン自体のリージョンを意識することはわかるが、どうしてリソースグループ自体のリージョンを考慮する必要があるのか。”と思うはずです。

このことについては、Microsoft Azureのページ内に次のように記載があります。

Azure Resource Managerとは – Microsoft Azureより引用

細かい話ですが、OS上のファイルやフォルダであっても、メタ情報を用いることでファイルシステムがもつパーミッション機能などが使えるのと似ていると言えます。

リソースグループと、それに内包されるリソースを極端に異なるリージョンに配置する必要はないと言えますが、”リソースグループのリージョン＝メタデータの格納場所”は試験対策でも実運用でも覚えておくべき大切な内容です。

リソースグループ間で、リソースは移動が可能か？

可能です。

移動については即座に終わらないケースがあったり、移動可能なリソースの種類には要件があったりします。

なお、移動に関する制限や仕様については以下のリンクの内容を参照ください。

リソースを新しいリソースグループまたはサブスクリプションに移動する – Microsoft Azure

ASM環境で作成されたリソースは今後も継続しようできるのか？

この点についてはMicrosoft社の公式ページ以外にも、IT情報系のページでも言及されています。

一言でいえば、”2023年3月1日に、ASMを使用して作成された仮想マシンは使用不可となります。”

正確に言えば、次の通りのようです。

ユーザーの中には、ASM環境で展開された本番環境の仮想マシンもあるかもしれません。対象者の方は、お早めに移行のための手続きを開始しましょう。移行に際しての不明点やよくある質問も、上記URL内でカバーされていますのでぜひアクセスしてみましょう。

オンプレミスインフラエンジニアのためのMicrosoft Azure入門 – Azure Resource Manager