Azure 環境のテンプレート

Microsoft Azure のリソースを作成して展開する方法としては、以下のようなものがあります。 

1. GUI ツールである 「Azure Portal (Web ブラウザでアクセス)」 を利用する
2. コマンドラインツールである 「Azure PowerShell」/「Azure CLI」 を利用する
3. 「Azure REST API」 を利用する
    

上記ツールの概要と使い方を学びたい方は、以下の Microsoft Learn をご参照ください。

• 「Azure portal を使用してサービスを管理する」 
• 「PowerShell でスクリプトを使用して Azure タスクを自動化する」 
• 「CLI を使用した Azure サービスの制御」
   

Azure REST API の利用方法に関する参考情報については以下をご参照ください。 

• 「Azure 監視 REST API のチュートリアル」 
   

Azure Portal や Azure PowerShell / Azure CLI を用いれば、Azure リソースの作成は可能であり一般的に利用される手法となります。 
クラウドを利用するシステムが増えて管理システム数が増えた場合や、今後クラウド上に新たなシステムを多数展開する場合においては、この手法によるリソース作成が最適でなく課題となる場合もあります。 
クラウドの利用をシステム単位に捉え、都度個別に作成を自由に行う場合に発生する可能性のある具体的な課題例としては以下のようなものがあります。 

1. 反復作業にも関わらず工数が削減できない、必要以上に時間がかかっている
   • 同じようなアーキテクチャのシステム (例: Web/AP/DB) を展開するのに、各システム単位で毎回同じような作成作業を行っている 
   • システム単位には 1 度の作業でも全体からすると何十回と同じ作業が行われており、標準化・自動化すべきところを最適化できていない 
   • 開発、テスト、本番などのインフラストラクチャ作成が自動化されておらず追加のテスト等が簡単にはできない
2. システムのアーキテクチャや品質が安定しない
   • 達成したい目的がほぼ同じシステム (例: Web/AP/DB) なのに、システム単位にアーキテクチャが大きく異なり、成功するシステムもあれば問題を抱えてしまうシステムもある
   • 本来アーキテクチャはベストプラクティスにそったものであるべきところが、システム単位に統制のとれていない自由なアーキテクチャが採用されてしまい、運用管理面において不必要な問題や負荷を生じさせている

上記の課題例をイメージ図にしたものが下記です。

このような課題を解決する手法として、Azure リソースのコードによる定義と、定義したコードによるデプロイの自動化が推奨されています。 このような考え方は、Infrastructure as Code (IaC) とも呼ばれます。Infra structure as a Code (IaC) についてより詳しくお知りになりたい方は、「コードとしてのインフラストラクチャとは」をご参照ください。

IaC によりインフラストラクチャをコード定義する事ができるため、ベストプラクティスに準拠したアーキテクチャそのものを組織内外で共有する事が可能となります。
IaC を用いた場合の具体的なメリットとしては以下のようなものがあります。

1. ベストプラクティスに準拠した成功するシステムを組織内外で共有・再利用できる
2. 冪等性が確保され、必ず毎回同じインフラストラクチャが展開される事が保証できる
3. インフラストラクチャの展開や管理工数が削減でき、ベストプラクティスに準拠する事でシステムが安定する
4. インフラストラクチャをコードで定義する事で、自動展開やバージョン管理を行う事が可能となるため、アジャイル開発や DevOps 等の考え方にインフラストラクチャを組み込む事が可能となる

上記のメリットをイメージ図にしたものが下記です。

命令型である Azure PowerShell / Azure CLI を利用して上記イメージ図のような仮想マシンと DB で構成されるインフラストラクチャを完成させる場合、単純化すると以下の処理を順番に実行する事が必要になります。

1. Virtual Network を作成する
2. 仮想マシンを作成する
3. DB を作成する
    

つまり、上記のような 1 つ 1 つの処理を行うためのコマンドをスクリプトとして記述していく必要があり、1 つ 1 つのコマンドは完全に独立したものとして実行されます。実行順序もスクリプト中で制御する必要があります。例えば、必ず Virtual Network を先に作成してから、仮想マシンを作成しないとエラーとなります。
Microsoft Azure 側も 1 つ 1 つの処理の相関を感知する事はできず、単純に別々の 1 つ 1 つの処理命令が来ているとしか認識できません。
各処理のスクリプト量も多くなり、作成者の技量によりスクリプト自体の品質もバラつきが発生します。手軽さゆえにコーディング規約が無い場合も想定され、俗人的なスクリプトを適切に管理し組織内外で共有するのは容易ではありません。
また、Azure PowerShell や Azure CLI のバージョンによりコマンド体系やパラメータが変更になる場合があり、その場合はスクリプト自体の更新が必要となります。
自分だけが理解できればいい自己学習用環境、組織内外での共有などを考える必要が無い状況においては、Bash や PowerShell に慣れている場合はすぐに使い始められるといったメリットやスクリプトならではの自由度もあり非常に有用です。実際に多くのユーザに Azure PowerShell や Azure CLI は数多く利用されています。

ARM テンプレートの場合は宣言型となり、インフラストラクチャ定義をコードで行います。

1. 仮想マシンと DB と Virtual Network で構成されるインフラストラクチャのコードによる定義

処理が 1 つになっただけのように思えますが、全く異なります。ARM テンプレートはインフラストラクチャそのものを定義しているのであり、1 つ 1 つの処理を記述しているのではありません。
この違いをイメージ図にしたものが下記です。

「エンタープライズ向け Azure Virtual Desktop」 

「PCI-DSS 3.2.1 の AKS 規制クラスターのアーキテクチャ」