【Azure Database for PostgreSQL - Flexible Server】死活監視を行う方法

はじめに

Azure Database for PostgreSQL フレキシブル サーバー(以下、フレキシブルサーバー)は、Microsoft クラウドによるフルマネージドなPostgreSQLデータベース サービスです。

このサービスをコストを抑えながら利用するためにはサーバーを必要な時だけ起動することが1つの方法となります。

例えば、Azure AutomationのRunbookを活用し、フレキシブルサーバーの自動起動及び停止を行うことで上記のコスト削減を実現することが可能です。しかし、Azure AutomationのRunbookによる自動起動停止は、Azure基盤の問題などによって上手く動作しないケースも存在します。

そこで、フレキシブルサーバーが無事起動できているかどうかを監視し、起動に失敗した場合は自動でフレキシブル サーバーの起動をリトライする機能をAzureのサービスを活用して実現しましたのでご紹介いたします。

この記事で得られること

• Azureモニターのアラートに関する概要及び全体感に関する知識
• アクション グループ、アラート処理ルール、アラートの設定に関する知識
• Azure Database for PostgreSQL - Flexible Serverで上記を実践し、死活監視を行う方法

要件

下記のような環境及び条件でフレキシブルサーバーを死活監視するケースを考えてみます。

環境

• 平日9:00~17:00にフレキシブルサーバーを稼働

条件

• 平日の9:10~10:00の間のみ、死活監視を行う
• フレキシブルサーバーのダウンを検知した場合は下記の2つを自動で行う
  • 指定したメールアドレスにダウンした旨をメールで通知する
  • ダウンしたサーバーに対して起動処理を実行する

全体感

上記を達成するためには、下記4つの課題をクリアする必要があります。

1. 何をもって「フレキシブルサーバーが起動できていない」と判断するか
2. 起動できていないことを検知した時、どのようにして指定された機能をトリガーするか
3. 2.を特定の時刻だけ機能させるためにはどうすれば良いか
4. 指定された機能をどのように実装するか(この記事内では割愛します)

そして、1~3を解決できるのが、Azureモニターのアラートと呼ばれる機能で
下記のような仕組みになっております。※1

上記を踏まえたうえで、さっそくフレキシブルサーバーの死活監視を構成してみましょう！

Azure Portalで実際に設定してみる

1. 何をもって「フレキシブルサーバーが起動できていない」と判断するか

①対象のフレキシブルサーバーを表示し、[監視]-[警告]の順にクリックします。その後、[+作成]-[アラートルール]をクリックします

②フレキシブルサーバーのどのログorメトリックを監視対象とするかを決定します。

• フレキシブルサーバーにおいてはDatabase Is Aliveメトリックが、死活ステータス(1:稼働中,0:利用不可)となります。下記のキャプチャでは、「5分ごとに過去5分間のメトリックを確認し、最大値が1より小さい=0:利用不可となった場合にアラートを発火する」といった設定を行っています

2. 起動できていないことを検知した時、どのようにして指定された機能をトリガーするか

機能の定義、及びグループ化はアクショングループで行います。詳細は割愛しますが
ここではメール通知＋サーバーの起動(Azure Function+Powershell)を1つのアクショングループとして定義しています。これをアラートと紐づけることで、アラートが発火した際にこのアクショングループがトリガーされます。

④最後に、アラートルール名やタグなどを決めて[確認および作成]します。

3. 2.を特定の時刻だけ機能させるためにはどうすれば良いか

アラート処理ルールを活用し、特定時間だけアクションを実行させるようにします。

①対象のフレキシブルサーバーを表示し、[監視]-[警告]の順にクリックします。その後、[+作成]-[アラート処理ルール]をクリックします

②どのアラートルールに対して、アラート処理ルールを適用するか設定します

③アクションの追加、抑制の設定をします。今回は抑制するため[通知を表示しない]を選択します。

④このアラート処理ルールの適用タイミングをスケジューリングします。今回は、監視したい時刻以外を設定すればOKです。

⑤最後に、アラート処理ルール名を決めて[確認および作成]します。

以上で、フレキシブルサーバーの死活監視設定が完了です。

おまけ

• 発火した後のアクションを抑制する ≒ 特定時間だけ監視、にしています。厳密にはアラート自体の発火は続くのでAzurePortal上での履歴が汚れてしまうのが課題です
• 上記を改善するため、Log AnalyticsのテーブルにKQLを直接発行して取得する形を試しましたが、Log Analyticsのテーブルにレコードが追加される時間と実際のメトリクスにラグがあり、誤検知が多かったため不採用としました

参考

※1: アクション内には4つのアクションをアイコンとして載せていますが、他のアクションも可能です。

引用