はじめに

　以前、「Azureにおけるアプリケーション監視の手引き」という記事を投稿しました。この記事の中で、Azureでアプリケーションをどのように監視していくかを挙げていきました。今回はその延長として、「データベース監視」について考えていきます。あくまで、私個人の視点で記載している記事となっております。読んでみてご意見や質問、議論したい内容などもあればコメントいただけると嬉しいです。

目次

本記事の前提とデータベース(Azure)の構成パターン
監視の必要な項目
仮想マシン上のデータベースの監視
AzureSQLDatabaseの監視

本記事の前提とデータベース(Azure)の構成パターン

　Azure上でデータベースを使用する際、以下のような構成パターンがあるかと思います。

オンプレミスサーバー上にミドルウェアをインストールして使用する
仮想マシンやKubernetesにミドルウェアをインストールして使用する
AzureSQLDatabaseやCosmosDBなどのマネージドサービスを使用する

　「1」のオンプレミスサーバーへの構成については、AzureArcを導入する前提で記事の説明を行います。オンプレミスサーバーの監視をするのであれば、Azureで監視する以上、AzureArcの導入を先に進めて下さい。

　「2」のKubernetesを使用した構成においては、コンテナという性質上Pullでメトリクス情報等を取得できるPrometheusの導入をお勧めします。Azureにもマネージドサービスとして使用可能なPrometheusがありますが、そちらの導入については以下の記事をご参照下さい。

Zenn | Azure Monitor managed service for Prometheus を試してみた

　「3」のマネージドサービスにおいては、本記事では、主にリレーショナルデーベース(以下、RDB)を対象として記載おります。以下のようなデータベースは考慮しておりませんが、共通して考えられる箇所もあるかと思います。

NoSQLデータベース(CosmosDB、Table Storageなど)
データウェアハウス(Microsoft Azure Synapse Analytics)

監視の必要な項目

　Azure上に構成されたデータベースの監視においては、最低限のラインとしては以下項目が必要になってきます。

コネクション数
スロークエリ
リソース監視
レプリケーション時間

「コネクション数の監視」、「スロークエリ」、「IOPSの監視」はおいて、どの構成パターン（NoSQLかSQLかを含む）においてもデータベースを使用している以上監視することをお勧めします。

コネクション数

　コネクション数はデータベースの監視の中で一番最初に始めるべき項目です。コネクション数を監視することで、データベースのパフォーマンスと可用性を監視することができます。コネクション数が通常時よりも多すぎる場合は、データベースのリソースを圧迫している可能性があり原因と対処を必要とする判断基準の一つとなります。ここで重要なのは、コネクション数は異常値を観測するようにしましょう。コネクション数が通常時「5以下」のデータベースにおいて、急に「10以上」のコネクション数が発生している場合は異常という具合に、監視するのが良いです。

スロークエリ

　スロークエリとは、実行時間が一定時間よりも遅いクエリのことです。スロークエリが発生した際は、ユーザー側も処理が遅いと感じている可能性が高く、ユーザー視点でとても重要な指標となります。また、データベースサーバーのリソースの枯渇が発生した場合、スロークエリが原因になっていることもしばしばあります。

リソース監視

I/O

　データベースのパフォーマンスはディスクのI/O(Input/Outoput)の速さに依存してきます。データベースに限らず、処理が遅い時の原因としてI/Oがボトルネックとなっていることは多くあります。その際は仮想マシン(Azure)を使用しているのであれば、仮想マシンのプランを考え直すことになるでしょう。そのためリソース監視においては、IOPSを常時監視をして定期的にマシンの構成を見直しするようにしましょう。
　Azure SQL Databaseにおいて、マネージドサービスのため原則としてMicrosoftがIOPSの保証をしてくれてはいますが、適切なサービスレベルを適用するために監視をするようにしましょう。

CPU

　CPUの監視が極めて分かりやすく重要であることは読者の皆さんはご存じのことかと思います。データベースを管理していくにあたって、CPUのリソースが足りずクエリ失敗ということがあります。リソースの枯渇が発生した場合は直ちに負荷をかけたクエリ(おそらくスロークエリ)を確認して対処していくことになります。

DTU(DTUコアベースの場合のみ)

　Azure SQL Databaseにおいて、DTUコアベースというサービスレベルがあります。DTUコアベースを使用するのであれば、「DTU (Database Throughput Unit)」も監視するようにして、DTUの値に合わせてAzure SQL Databaseの構成を見直していきましょう。

MSLearn | DTU ベンチマーク

※DTUの監視を行う際も上記「CPUの監視」をしておくことをお勧めします。DTUコアベースのコンピューティングにおいて多くのボトルネックはCPUになってきます。

レプリケーション時間

　マネージドサービスをデータベースとして使用している場合、多くの構成においてレプリケーションを構成しているかと思います。せっかくお金を払ってレプリケーション構成をとっているのですから、しっかりと監視しましょう。レプリケーションが遅延している場合は、障害が発生した時に想定していた地点まで復旧できなくなってしまいますので、もしもの備えにおいて、とても重要な指標となってきます。

仮想マシン上のデータベースの監視

　仮想マシン(AzureArc対応サーバ含む)上に構成されたデータベースの監視は、少し難しい面もありますが、主に以下3手法をとれると思います。全ての手法を導入して、監視項目を網羅できるようにしましょう。

メトリクスとパフォーマンスカウンタ
SQLを使用した監視
レプリケーションの監視

メトリクスとパフォーマンスカウンタ

　CPU使用率やIOPS等の主要なリソースの監視はメトリクスでも簡単に取得をすることができます。しかし、ここでは強くAzure Monitor Agentのパフォーマンスカウンタを使用することをお勧めします。パフォーマンスカウンタを使用してLog Analytics Workspaceへ保管を取得することで、長期保管や分析にログを使用できます。

SQLを使用した監視

　残念ながら、仮想マシン上のデータベースにおいてコネクション数やスロークエリはAzureサービスで監視することはとても難しいです。しかし、幸いほとんどのデータベースでは、コネクション数やスロークエリはコマンドでの確認が可能です。そこで、どうしても監視が必要であれば以下のような手法を一例として提案します。

Automation(Hybrid Runbook Worker)を使用して、SQLでデータベースへ問合せする
問い合わせ結果をローカルのログに出力
Azure Monitor Agent(カスタムテキストログ)で定期的に収集してLog Analytics Workspaceへ保存

以下にMySQLでのクエリの確認方法を載せておきます。

Automation(Hybrid Runbook Worker)はRunbook起動(WorkerGroup厳密にはポーリングの間隔)に制限があるので、ある程度制約が出てきます。CronやSQL確認用のFunctionsを使ってSQLを発行したりといろいろとアレンジ方法はありますので、運用チームとしっかりと話し合って方式を検討してみて下さい。

レプリケーションの監視の監視

　基幹システム等のビジネスの継続と強く結びつくようなシステムなのであれば、BCPが一つの重要な指標になると思います。BCPを要件のインプットにして、ビジネスチームと一緒にSLAを定めましょう。SLAが決まったら、実際の監視方法や設定方法はレプリケーションツールを提供しているベンダーと相談するようにしてください。

AzureSQLDatabaseの監視

Azure SQL Databaseの監視は、全体的ととても簡単に導入できます。主に以下3手法から導入していきます。全ての手法を導入して、監視項目を網羅できるようにしましょう。

メトリクスと診断設定
Query Performance Insight
レプリケーションの監視

メトリクスと診断設定

　コネクション監視とリソース監視においては診断設定しなくてもメトリクスとしてAzureMonitorが取得してくれています。ただし93日間しか保管できないので、長期保存したい場合は診断設定でLog Analytics Workspaceへ送ることを考えておきましょう。

QueryPerformanceInsight

　「Query Performance Insight」を使用するとデータベースのパフォーマンス監視がとても簡単になり、非常に便利です。使用するにあたって、何か特別な設定も必要ありません。クエリのパフォーマンス監視でスロークエリを発見できますが、それだけでなくパフォーマンスの推奨事項の表示など多くのことができます。
詳細は以下のDocsからご確認ください。簡単に試せるはずです。
MS Learn | Azure SQL Database の Query Performance Insight

レプリケーションの監視

　レプリケーションの監視については幸いMicrosoftがレプリケーションの可用性を保証してくれています。なので、あまり気にする必要はないでしょう。特別何か実装をすることも不要です。

あとがき

　Azure環境にシステム構築をしているのであれば、監視の面においては、極力Azure SQL Databaseを採用した方が賢明です。運用がごちゃごちゃしなくて良いし、収集機能の作成にかかるリソースが少なくて済みます。今回は省略しましたが、他のDWHやNoSQLDBについても同じことが言えます。極力マネージドサービスを使用して、監視を楽にしましょう。