🔥

【第24回】Azureで社内システム再現（クラウド編）｜Hybrid Worker にバックアップとアラート通知を構成する

2025/04/30に公開

 概要これまでの「オンプレ編」では、Azure の仮想マシン（IaaS）を使って、社員番号から名前を検索できるシンプルな社内システムを構築してきました。Active Directory、SQL Server、ADFS などを組み合わせ、オンプレミスの構成を仮想的に再現しています。
※全体構成の詳細は、【第0回】Azureで社内システム再現（オンプレ編）｜構成図と動作の流れ をご参照ください。
クラウド編では、これまでの構成をベースにしつつ、Azure のマネージドサービス（PaaS）を中心とした構成へ段階的に移行していきます。
※クラウド移行全体の設計方針については、【第10.5回】Azureで社内システム再現（クラウド編）｜オンプレ構成をどうクラウドに移行するか？ にまとめています。

 システム構成（今回の対象範囲）今回のテーマは、Azure 環境に構築した社内システムの中核となる Hybrid Worker VM に対して、バックアップと監視体制を整備し、運用フェーズへの移行を図ることです。
まず、下図は「クラウド編」における全体構成図です。
このうち、赤枠で示している Recovery Services コンテナー（バックアップ）と Log Analytics Workspace（監視）周辺の構成が、今回の対象範囲となります。
今回は以下の作業を行いました。
Hybrid Worker VM を対象とした Azure Backup の構成
Log Analytics Workspace（LAW）を用いたイベントログの収集
「Error」ログを検出するクエリの作成と、それに基づくアラートルールの設定
アラート発火時にメール通知が届くようアクショングループを構成
テスト用にエラーログを手動発生させ、検知と通知が正しく機能することを確認
これにより、Hybrid Worker に対する障害対応と異常検知の体制が整い、システムの安定運用に向けた基盤が完成しました。

 Azure Backup の構成（Hybrid Worker のバックアップ）社内システムの中核である Hybrid Worker（hw-vm）を対象に、Azure Backup を使ったバックアップ構成を行います。

IaaS ベースの VM はユーザー側での復旧責任があるため、障害発生時の備えとしてバックアップは必須の構成要素です。
Azure Backup では、まずバックアップデータを保存するための「Recovery Services コンテナー（RSC）」を作成します。
また、バックアップの「ポリシー」は、バックアップの取得タイミングや保持期間などを定義するルールであり、

これに従って Azure が自動的にスナップショットを取得・管理します。
今回は、毎日午前5時にバックアップを取得するようなポリシーを構成して進めます。

 Recovery Services コンテナーの作成Azure ポータルで「Recovery Services コンテナー」を選択し、作成を進めます。
リソースグループ、名前、リージョン等を設定します。

 バックアップの構成を開始Recovery Services コンテナーが作成されたら、上部の「＋バックアップ」をクリックします。
バックアップ対象を選択する画面へ遷移します。

 バックアップ対象を選択（Azure VM）バックアップする対象として「仮想マシン」を選択します。

今回は、Automation や ADF の実行基盤となっている hybridworker を対象とします。

 バックアップポリシーの作成次に、バックアップの頻度や保持期間を定義する「バックアップポリシー」を作成します。

今回は以下のように設定しました。
バックアップの実行：毎日 午前 5 時

 バックアップ構成の最終確認と有効化設定内容を確認し、「バックアップを有効にする」をクリックします。

これにより、初回のバックアップ準備が開始されます。

 動作確認Recovery Services コンテナーの「バックアップ項目」から、対象の VM に対してバックアップが正常に取得されていることを確認できます。
このように、Hybrid Worker VM に対するバックアップが正常に完了していることを確認できました。

 Hybrid Worker の監視構成（Log Analytics + アラート通知）次に監視の構成を行います。

Hybrid Worker に対して Azure Monitor のログベース監視構成を行い、

イベントログに「Error」が出力された際に、指定のメールアドレスへ通知が届くように設定します。
具体的には、Azure Monitor Agent により収集されたイベントログを Log Analytics Workspace（LAW）に送信し、

そのログに対してクエリ（KQL）を実行してアラートルールを定義しています。

これにより、エラーが発生した際に即座に検知・通知する仕組みを実現します。

 Log Analytics Workspace の作成まず、Log Analytics Workspace（以下 LAW）を作成し、ログの集約先を用意します。

 データ収集ルール（DCR）の自動作成Hybrid Worker を構成すると、Azure Monitor Agent が対象 VM にインストールされ、

対応するデータ収集ルール（DCR）も自動的に作成されます。

 LAW との接続確認Hybrid Worker の VM が LAW に接続され、ログが送信されていることを確認します。

 エラーログ取得用のクエリ作成収集されたログに対して以下のクエリを実行し、直近のエラーログを時系列順に確認します。
Event
| where EventLevelName == "Error"
| sort by TimeGenerated desc
このクエリは「Detect-ErrorEvents」という名前で保存し、アラートルール作成に使用します。

 アラートルールとアクショングループの概要Azure Monitor の監視構成では、ログの異常を検知した際に「誰に・どのように知らせるか」を定義する必要があります。

そのために使うのが、以下の2つの仕組みです。
アラートルール：

クエリ結果やメトリックのしきい値に基づいて、異常を検知するルール。

今回は「エラーが1件以上検出されたら通知する」という条件を設定します。
アクショングループ：

アラートが発火したときに「どのようなアクションを取るか（例：メール通知）」を定義する設定です。

 アラートルールの作成保存したクエリ（Detect-ErrorEvents）をもとに、アラートルールを作成します。
アラートの対象として「カスタム ログ検索（Log Analytics クエリ）」を選択します。

ここでは先ほど保存した Detect-ErrorEvents クエリを選び、クエリ実行結果に基づいて異常検知を行います。

 アラートロジックの設定次に、アラートの評価条件を設定します。

評価頻度を「1分ごと」、しきい値を「0より大きい」に設定することで、

1分間で1件でもエラーがあれば即アラートが発火する仕組みです。
このルールでは、「現在の評価ウィンドウ内に1件でもエラーが検出された場合のみ」通知が発生します。

※ 過去のログ（例：前日に出たエラー）は評価対象外です。

 アクショングループと通知設定アラートが発火した際に「どんな通知・操作を行うか」を定義するのがアクショングループです。

ここでは、指定のメールアドレスに通知を送るように新しいグループを作成します。
最後に、これまでの設定内容を確認し、問題がなければアラートルールを作成して完了です。

 動作テストと通知確認Hybrid Worker VM 上で手動でエラーを発生させ、アラートが正常に検知・通知されるかを確認しました。

テストには、PowerShell 上で以下のコマンドを実行して、明示的に Application ログにエラーイベントを作成しています。
EventCreate /L Application /T ERROR /SO "TestSource" /ID 100 /D "これはテストエラーです"

ログ種別：Application ログ

タイプ：ERROR

ソース：TestSource

イベント ID：100

メッセージ：「これはテストエラーです」
この操作により、VM 内のイベントログにエラーが記録されます。
また、Log Analytics Workspace 上でも、先ほど保存したクエリにより該当のエラーイベントが検出されました。
このエラーにより、アラートルールが発火したことも確認済みです。
最終的に、設定したアクショングループのとおり、指定したメールアドレス宛に通知が届きました。
以上により、Hybrid Worker のイベントログ監視とアラート通知が正しく機能していることが確認できました。