Azure Automationとは？Runbookによる運用自動化・スケジュール実行・更新管理を実務目線で解説

Azure

Azureの運用を任されるようになると、だんだん「毎日・毎週おなじ作業を手でやっている」ことに気づきます。夜間に使わない仮想マシンを止める、月初にレポート用のスクリプトを回す、OSのパッチを当てる——どれも大事だけど、人間が手作業でやるとやり忘れ・時間外対応・作業ミスがついて回ります。

これを「Azureの中にいる自動化の仕組み」に肩代わりさせるのが Azure Automation です。ただ、いざMicrosoft Learnを開くと、Runbook・ハイブリッドワーカー・DSC・Update Manager……と用語が一気に押し寄せてきて、「結局これは何をしてくれるサービスなの？」で手が止まりがちです。私自身、最初は「Functionsと何が違うの？」あたりでずっと迷子になっていました。

「Automationって、要はスクリプトを自動で回すだけ？パッチ管理とか構成管理とかも入ってるらしいけど、全部同じサービスなの？」

この記事では、Azure Automationを「深夜でも文句を言わずに働いてくれるロボット執事」にたとえながら、Runbookの書き方、定期実行とWebhook、マネージドIDでシークレット無しに操作する方法、構成管理（DSC/Machine Config）、更新管理（Update Manager）、そして資産（変数・資格情報）の安全な参照までを一気通貫で解説します。最後にLogic Apps／Functionsとの使い分けも表で整理します。読み終わるころには、「この運用作業はAutomationに任せられそうだ」と自分で判断できるようになります。

Azure Automationとは——雇わなくていい「夜勤のオペレーター」

Azure Automationは、ひとことで言うとAzureの運用作業を自動化してくれるマネージドサービスです。公式の説明では「プロセスの自動化」「構成管理」「更新管理」を提供する、とされています。難しく聞こえますが、やってくれることは意外と地に足がついています。

イメージとしては、Azureのテナントに24時間働いてくれる夜勤のオペレーターを一人雇う感じです。「毎晩22時になったら開発用のVMを全部止めておいて」「毎週月曜の朝、全サーバーにパッチが当たっているかチェックして」——そんな指示書（＝スクリプトや設定）をあらかじめ渡しておくと、Automationがその通りに、人間が寝ている間も淡々とこなしてくれる。しかもこのオペレーターは、実行基盤のサーバーを自分で用意する必要がありません。実行環境（Azureが用意するサンドボックス）はマネージドで、こちらは中身の指示書に集中できます。

Automationの機能は、大きく次の3つの柱に分かれています。この分類を頭に入れておくと、あとの各章が「どの柱の話か」で迷いません。

  • プロセスの自動化……スクリプト（Runbook）を定期実行・外部起動する。VMの起動停止、レポート生成、リソースのタグ付けなど。この記事の中心。
  • 構成管理……サーバーの「あるべき状態」を定義し、ズレ（構成ドリフト）を検知・修正する。DSC / Machine Config。
  • 更新管理……OSのパッチ適用状況を評価し、スケジュールを組んで一括で当てる。現在はAzure Update Managerに移行。

この3本柱を包んでいる入れ物が Automationアカウント です。まずAutomationアカウントというリソースを1つ作り、その中にRunbookやスケジュール、変数などをぶら下げていく、という構造になります。最初の一歩は「Automationアカウントを作る」だと覚えておけば大丈夫です。

Runbook——執事に渡す「作業手順書」

Automationの主役が Runbook（ランブック） です。名前のとおり「手順書（run book）」で、自動化したい処理を書いたスクリプトそのものだと思ってください。ロボット執事に「これをこの順番でやってね」と渡す作業指示書、という位置づけです。

Runbookにはいくつか種類がありますが、実務で使うのはほぼ次の2つです。

  • PowerShell Runbook……Azureの操作と相性が良い定番。Az モジュールでVM・ストレージなどをそのまま操作できる。Windows寄りの運用や、とりあえず自動化を始めるならこれ。
  • Python Runbook……PythonでAzureのSDKや外部ライブラリを使いたいとき。データ処理・機械学習まわりや、既存のPython資産を活かしたいチーム向け。

ほかにPowerShell WorkflowやグラフィカルRunbookもありますが、初心者はまずPowerShell Runbook一択で始めて問題ありません。迷うぐらいなら普通のPowerShellで書く、が正解です。

下は「リソースグループ内のVMを全部止める」だけのごく単純なRunbookのイメージです。中身より「これぐらいの短いスクリプトが1本のRunbookになる」という粒度感をつかんでください。

# マネージドIDでAzureにサインインしてからVMを停止する
Connect-AzAccount -Identity

$rg = "rg-dev"
Get-AzVM -ResourceGroupName $rg | ForEach-Object {
    Write-Output "Stopping $($_.Name)..."
    Stop-AzVM -ResourceGroupName $rg -Name $_.Name -Force
}
Write-Output "Done."

ポイントは冒頭の Connect-AzAccount -Identity です。ここが「シークレットを一切持たずにAzureへログインする」魔法の一行で、あとのマネージドIDの章で詳しく触れます。まずは「Runbook＝Azure用の短いスクリプトを1本ずつ管理するもの」というイメージを持てればOKです。

「発行」しないと動かないという落とし穴

最初につまずくのがこれです。Runbookはエディタで書いた後、「発行（Publish）」という操作をして初めて本番として実行できるようになります。書いただけの状態は「下書き」で、テスト実行（テストペイン）はできても、スケジュールやWebhookからは呼ばれません。「スケジュールを組んだのに動かない」の犯人はたいてい発行忘れなので、書いたら発行、を癖にしておきましょう。

トリガー——「定期実行」と「外から起動」の2系統

Runbookという手順書ができたら、次はいつ・何をきっかけに実行するかを決めます。これがトリガーです。大きく2系統あり、この違いが分かると設計がぐっとラクになります。

スケジュール——時計で自動起動

スケジュールは「毎日22時」「毎週月曜9時」のように、時刻ベースで自動的にRunbookを回す仕組みです。夜間バッチや定期メンテナンスはほぼこれで組みます。Automationアカウント内でスケジュールを作り、それをRunbookに「リンク」するだけ。cronのような書式を覚えなくても、画面で「毎週・月曜・9:00」と選べるのが親切なところです。

1つ注意したいのがタイムゾーンです。作成時にタイムゾーンを選べるので、必ず「(UTC+09:00) 大阪、札幌、東京」を選んでおきましょう。ここをUTCのままにして「なぜか9時間ずれて動く」というのは、多くの人が一度は踏む定番の罠です。

Webhook——外部システムから叩いて起動

もう一方のWebhookは、Runbook専用のURLを1本発行しておき、そのURLにHTTP POSTが来たら実行する仕組みです。監視ツールがアラートを検知したとき、社内システムのボタンが押されたとき、他のサービスから連携したいとき——つまり「時刻」ではなく「外部のできごと」で起動したいケースで使います。

WebhookのURLは発行時に一度しか表示されず、あとから確認できません。しかもURLを知っている人は誰でもRunbookを起動できてしまうので、パスワード同然に扱います。表示された瞬間にKey Vaultなど安全な場所へ控える、というのが鉄則です。

「時計で回すならスケジュール、外のできごとで起こすならWebhook」。この二択で覚えておけば、トリガー選びで迷いません。

マネージドID実行——シークレットを持たずにAzureを操作する

ここがAutomationを実務で使ううえで、いちばん美味しいポイントです。Runbookから「VMを止める」「ストレージを触る」といったAzure操作をするには、当然ながら「あなたは誰？操作していい人？」という認証が要ります。昔はここでサービスプリンシパルの証明書やパスワードをRunbookに埋め込んでいましたが、それだと秘密情報の管理と定期更新（ローテーション）という重い宿題を背負うことになります。

これを一掃してくれるのがマネージドIDです。Automationアカウントにシステム割り当てマネージドIDを有効にすると、そのアカウント自身がAzure上で「身分を持った存在」になります。Runbookの中では、先ほど出てきた一行を書くだけです。

# パスワードも証明書も書かない。IDだけでサインインできる
Connect-AzAccount -Identity

スクリプトのどこにもパスワードが出てきません。認証情報はAzureが裏側で面倒を見てくれるので、キーレスで、しかもローテーション不要。これがマネージドID最大の利点です。私はセキュリティ設計で「まずキーを消せないか」を最初に考えるタイプなので、この方式は本当に相性が良く、新規のRunbookは原則これで組んでいます。

ただし、有効化しただけでは何もできません。そのマネージドIDに対して、操作したい範囲のRBACロールを付ける必要があります。たとえば「rg-devの中のVMを止めたい」なら、そのマネージドIDに対してrg-devスコープで「仮想マシン共同作成者」などのロールを割り当てます。ここで必要最小限の権限だけを、必要なスコープにだけ付けるのが定石です。サブスクリプション全体に「共同作成者」をベタ付けするのは、事故のもとなので避けましょう。

「Connect-AzAccountで認証エラーになる」ときは、たいていマネージドIDの有効化を忘れているか、ロールを付け忘れているかのどちらかです。この2点をセットで確認する、と覚えておくと詰まりにくいです。マネージドIDそのものをもう少し体系的に知りたい方は、条件付きアクセス・マネージドID・PIMを噛み砕いて解説の記事も参考になります。

資産（Assets）——変数・資格情報・証明書を安全に取り出す

Runbookを本格運用しはじめると、「接続先のURL」「通知先のメールアドレス」「外部APIのキー」といった設定値をスクリプトに直書きしたくない場面が必ず出てきます。それを引き受けるのが Automationの資産（Assets）です。Automationアカウント側に値を保管しておき、Runbookからは名前で呼び出す、という分離ができます。

  • 変数（Variables）……環境名やしきい値など、コードから切り出したい設定値。「暗号化」を有効にすると値が保護され、取り出し以外では中身が見えなくなる。
  • 資格情報（Credentials）……ユーザー名＋パスワードのセット。オンプレ機器への接続など、どうしてもID/パスワードが要る相手向け。
  • 証明書（Certificates）……クライアント証明書などをアップロードして保管。
  • 接続（Connections）……接続に必要な情報をひとまとめにした構成。

Runbookからの取り出しは、たとえば変数ならこう書きます。

# 「NotifyEmail」という名前で保存した変数を読み込む
$mail = Get-AutomationVariable -Name "NotifyEmail"

# 資格情報を取り出してオンプレ機器などへ接続
$cred = Get-AutomationPSCredential -Name "OnPremAdmin"

ここで指針を1つ。AzureのシークレットならKey Vault、Automation内で完結する運用値なら資産と切り分けると整理しやすいです。とはいえ本命は前章のマネージドIDで、「そもそもパスワードを持たない」設計にできるならそれが一番安全です。資格情報はマネージドIDが使えない相手（オンプレ機器など）への最後の手段、ぐらいの温度感で使うのがおすすめです。

ハイブリッドRunbookワーカー——オンプレや別環境で実行する

ここまでのRunbookは、Azureが用意するクラウド上のサンドボックスで動きます。これで多くの用途は足りますが、「Azureの外にあるサーバーやオンプレの機器を操作したい」となると話が変わります。クラウドのサンドボックスからは、社内ネットワークの奥にいる機器に手が届かないからです。

そこで登場するのがハイブリッドRunbookワーカーです。オンプレや別クラウドのサーバーに専用のエージェントを入れておくと、そのサーバー自身がRunbookの実行役になる仕組みです。ロボット執事の分身を、Azureの外の現場にも常駐させるイメージですね。

Runbookの中身は同じで、実行時に「クラウドで動かすか、ハイブリッドワーカー（＝現地のサーバー）で動かすか」を選ぶだけです。これで「オンプレのファイルサーバーを毎晩バックアップ」「社内システムのメンテナンススクリプトを定時実行」といった、Azureの外の作業もAutomationのスケジュールに乗せられるようになります。オンプレとクラウドが混在している現場では、この仕組みが効いてきます。

構成管理——「あるべき状態」を保ち、ズレを直す

3本柱の2つ目、構成管理に入ります。これは発想が少し違っていて、「スクリプトを1回走らせる」ではなく「このサーバーは常にこの状態であってほしい」という設計図を持たせ、ズレたら直すという考え方です。

たとえば「Webサーバー役のVMには必ずIISが入っていて、指定のサービスが起動していて、この設定ファイルがこの内容になっている」というあるべき状態を定義しておきます。すると、誰かが手作業で設定を変えてしまったり、サービスが落ちたりして状態がズレた（＝構成ドリフトが起きた）ときに、それを検知して自動的に元へ戻せます。手作業のサーバー管理でいちばん怖い「気づかないうちに設定が変わっていた」問題への処方箋です。

この仕組みは従来 PowerShell DSC（Desired State Configuration） として提供され、Automation State Configurationで管理されてきました。現在Azureは、これをより新しい Machine Configuration（Azure Policyのゲスト構成） に寄せる方向で進化させています。名前と入り口は移り変わっていますが、「望ましい状態を宣言的に定義し、ドリフトを検知・適用する」という考え方の芯は同じです。まずはこの考え方だけ押さえておけば、どちらの入り口から入っても迷いません。

更新管理——OSパッチを評価してまとめて当てる

3本柱の最後、更新管理です。運用でいちばん地味に大変なのがOSのパッチ当てで、「どのサーバーに未適用の更新が残っているか」を人力で追いかけるのは現実的ではありません。ここを引き受けるのが更新管理で、現在は独立した Azure Update Manager として提供されています（かつてのAutomation Update Managementの後継です）。

やってくれることは大きく2つです。

  • 評価（Assess）……対象のVM群をスキャンし、「どのサーバーに、どんな更新が、いくつ未適用か」を一覧で見せてくれる。まず現状把握。
  • 適用（Schedule）……「毎月第2水曜の深夜2時に、この更新をこのグループに当てる」といったメンテナンスウィンドウを組み、まとめてパッチを適用する。

ありがたいのは、Azure上のVMだけでなくAzure Arc経由でオンプレや他クラウドのサーバーも同じ画面で管理できる点です。「業務時間中に再起動してしまった」という事故を避けるため、必ずメンテナンスウィンドウ（許可された時間帯）を切って運用するのが実務のセオリーです。深夜帯にまとめて当てて、朝には全台パッチ済み——という状態をスケジュールで作れます。

Logic Apps／Functionsとの使い分け（ざっくり早見表）

Automationを学ぶと必ず出てくるのが「Logic AppsやFunctionsと何が違うの？」という疑問です。役割が近いようで、得意分野がはっきり分かれています。ここでは深追いせず、選ぶときの当たりを付けられるようざっくり早見表にまとめます。

サービス得意なこと向いている場面
Azure AutomationIT運用スクリプトの実行（PowerShell/Python）・構成管理・パッチ夜間バッチ、定期メンテ、VM起動停止、パッチ当てなどの運用作業
Logic AppsSaaSやサービス同士をGUIでつなぐワークフロー（豊富なコネクタ）「メールが来たら承認して記録」のようなサービス連携
Functionsイベントに反応して動く、短時間のコード実行APIのバックエンド、ファイル到着時の処理などのイベント駆動

覚え方はシンプルです。「サーバー運用のスクリプトを回したい」ならAutomation、「サービス同士をつなぎたい」ならLogic Apps、「イベントでコードを走らせたい」ならFunctions。この記事のテーマである「夜間バッチ・定期メンテ・パッチ当て」は、まさにAutomationのど真ん中の用途です。Logic AppsとFunctionsはそれぞれ奥が深いので、詳しくは別記事で扱います。

まとめ——「手でやっている定期作業」から任せていく

Azure Automationを、ロボット執事のたとえで一気に見てきました。要点を振り返ります。

  • Automation＝運用作業を自動化するサービス。柱は「プロセス自動化」「構成管理」「更新管理」の3つ。
  • Runbook＝自動化したい処理を書いたスクリプト（まずはPowerShell）。書いたら発行を忘れずに。
  • トリガー＝時刻で回すスケジュールと、外部から起こすWebhookの2系統。
  • マネージドID＝シークレットを持たずにキーレスでAzureを操作できる本命の認証。有効化＋RBACロール付与がセット。
  • 資産＝変数・資格情報・証明書を安全に保管し、Runbookから名前で参照。
  • ハイブリッドワーカー＝オンプレや別環境でRunbookを実行する分身。
  • 構成管理（DSC/Machine Config）＝あるべき状態を定義しドリフトを検知・修正。
  • 更新管理（Update Manager）＝パッチの評価とスケジュール適用。

最初から全部を使いこなそうとしなくて大丈夫です。まずは「毎日手でやっている定期作業を1つ」Runbookにして、マネージドIDで動かし、スケジュールで回す——ここまでできれば、Automationの一番おいしい部分は体験できています。そこから構成管理・更新管理へ広げていけば、運用がどんどんラクになっていきます。

あわせて読みたい

タイトルとURLをコピーしました