データベース サーバーの監視と構成
企業がオンプレミスのデータベースを Azure Database for MySQL/PostgreSQL に移行した後も、そのパフォーマンスを監視する方法が必要になります。
あなたはデータベース開発者として、データベース固有のツールとオンプレミスの VM 監視を使用してきました。 データベースが Azure で実行されるようになったため、ポータルを利用し、1 つのツールを使用して様々なデータベースをすべて監視できます。
このユニットでは、担当するデータベースの正常性の監視が Azure Monitor によってサポートされる方法について説明します。 問題が明らかになったら、データベースの構成を変更して問題を解決する方法を確認します。
Azure Monitor を使用してデータベースの正常性を表示する方法
Azure Database for MySQL/PostgreSQL でのリソースの使用を追跡するには、Azure Monitor を使用します。 Azure portal のサーバーの [メトリック] ページを使用すると、パフォーマンスの傾向を検出し、異常を発見するために役立つグラフを作成できます。
Azure Database for MySQL/PostgreSQL のメトリック
サーバーの監視に使用できるメトリックは、次の 4 つの大まかなカテゴリに分類されます。
- Storage のメトリック
- 接続のメトリック
- データ処理でのリソース使用率のメトリック
- レプリケーションのメトリック
Storage のメトリック
ストレージのメトリックでは、サーバー全体のデータベースの合計サイズ ("使用されている記憶域") と、サーバー上の現在の記憶域の容量 ("容量の上限") を追跡します。 アクティブなシステムでは、"使用されている記憶域" メトリックが時間の経過と共に増大することがわかるでしょう。 サーバーで自動拡張オプションが選択されている場合は、空き領域が減少すると "容量の上限" メトリックが増加することがあります。 空き領域の量が現在の使用量の 5% を下回るたびに、ストレージが追加されます。 サーバー上の使用されている領域と空き領域の割合を表示するには、"ストレージ使用率" メトリックを使用します。
ストレージを増やすためにサーバーで定期的に時間が費やされている場合は、より多くの領域を手動で割り当てることを検討してください。 これを行うには、Azure portal でサーバーの [価格レベル] ページを選択し、[ストレージ] スライダーを使用します。 ストレージに対して課金されるので、使用可能なストレージを多く設定し過ぎないようにしてください。
"バックアップ ストレージの使用量" メトリックは、バックアップのために使用されている容量を示します。 このメトリックは、コストの観点から重要です。 サーバーに割り当てられている記憶域スペース (価格レベルで指定されています) のサイズを下回っていれば、バックアップ ストレージに対して課金されることはありません。 この制限を超えると、バックアップ ストレージの料金が発生します。
接続のメトリック
"アクティブな接続" メトリックは、サーバーで現在サポートされているコンカレント接続の数を示します。 これは、接続プールの種類を構成しているかどうかによって異なりますが、同時ユーザー数と同じであるとは限りません。 現在、Azure Database for MySQL/PostgreSQL では接続プール機能を提供していませんが、PgBouncer* (PostgreSQL の場合) などのプロキシ サービスを使用してこの機能を実装することができます。 詳細については、「Azure Database for PostgreSQL を使用するためのパフォーマンスのベストプラクティス – 接続プール」を参照してください
"失敗した接続" メトリックは、ユーザーが無効な資格情報を提示した回数を示します。 これらのイベントの数が短時間で多い場合は、ブルートフォース攻撃を示している可能性があります。
データ処理でのリソース使用率のメトリック
これらのメトリックは、サーバーでのワークロードの処理状況を監視するために役立ちます。
"CPU 使用率" メトリックは、CPU のビジー状態を示します。 時間の経過と共に増加している場合を除き、CPU 使用率が高いことは問題ではありません。 CPU 使用率が 90% を超えてさらに上昇している場合は、システムが処理能力の上限に近づいていることを示しています。 より多くのリソースを持つ価格レベルにスケールアップすることを検討してください。
"メモリの割合" メトリックは、メモリの占有率を示します。 Azure Database for MySQL/PostgreSQL では、データのキャッシュにメモリを使用し、各クライアントの要求によって開始される処理を実行します。 メモリの使用量が過剰になるまでは (使用可能な実際のメモリ量に応じて、通常は 95% を超える使用量)、使用量が多いことは問題ではありません。 使用可能なメモリが非常に少ないと接続エラーが発生し、メモリの断片化が原因でパフォーマンスが低下する可能性があります。 このメトリックを監視して、メモリの占有量が時間の経過と共に増加しているかどうかを判断し、それに応じてサーバーをスケールアップします。
"IO 率" メトリックでは、サーバーで実行されているディスク アクティビティの量を追跡します。 理想的には、この値はできるだけ低い必要があります。 ディスク IO は低速な操作です。 このメトリックの値が高く、"メモリの割合" が多い場合は、サーバーのリソースが不足してデータを効率的にキャッシュできなくなり、代わりにディスク ストレージに対するデータの読み取りと書き込みが必要となっていることを示している可能性があります。 データはある時点でディスクに保存する必要があり、トランザクション ログを保持する必要があるため、ある程度の IO アクティビティは避けられません。 ほとんどのデータベース サーバーでは、この書き込みは、非同期で実行される別のプロセスまたはスレッドによって実行されます。
"ネットワーク入力" と "ネットワーク出力" メトリックは、アクティブな接続を介してサーバーで入力および出力されるトラフィックの量を示します。 これらの数値の制限は、クライアント アプリケーションとサーバーの間のパスの帯域幅によって決まります。
レプリケーションのメトリック
Azure Database for PostgreSQL では、"レプリカ間の最大遅延" と "レプリカの遅延" メトリックが提供され、レプリカがどれだけ最新であるかを判断するために役立ちます。 これらのメトリックは、読み取り専用レプリカを構成した場合にのみ意味があります。
"レプリカ間の最大遅延" メトリックは、最も遅いレプリカでマスターよりも遅れているバイト数を示します。 このメトリックは、マスターからのみ監視できます。
"レプリカの遅延" メトリックでは、最新のトランザクションがマスターから受信されてからレプリカに適用されるまでに経過した時間が秒単位で示されます。 このメトリックは、レプリカで表示する場合にのみ意味があります。
Azure Database for MySQL には、"レプリケーションのラグ (秒)" メトリックがあります。 このメトリックは、レプリカからのみ監視でき、レプリカがマスターよりも遅れている秒数が示されます。
パフォーマンスを監視するためのグラフとアラートを作成する
Azure portal のサーバーの [メトリック] ページを使用すると、メトリック値を追跡するグラフを作成できます。 メトリックは 1 分間隔で収集されます。 各メトリックについて、そのメトリックの報告方法を決める集計を指定します。
- Average では、メトリックの平均値が 1 分ごとに生成されます
- Max では、1 分間の最大値が示されます
- Min では、最小値が示されます
- Sum では、メトリックの合計が示されます
- Count では、メトリックが生成されたイベントが何回発生したかが示されます
すべての集計がすべてのメトリックで意味があるとは限りません。
下のグラフの例では、[CPU 使用率]、[メモリの割合]、[IO 率]、[アクティブな接続] の各メトリックについて、分単位の平均値がキャプチャされています。 101 個のアクティブな接続がすべて同時に実行にされていることがわかります。 CPU とメモリの使用率は両方とも安定しており、IO 率は 0 です。 この例では、クライアント アプリケーションで読み取りが集中的に行われるワークロードが実行されていて、必要なデータがメモリにキャッシュされています。
メトリックがキャプチャされてから結果がグラフに表示されるまでに、最大 5 分の遅延が発生することに注意してください。
リソースがクリティカルな状態に達していることがメトリックに示されている場合に管理者に通知するように、アラートを設定できます。 下の例では、メモリ使用率が 90% を超えた場合に、管理者に電子メールが送信されます。
サーバー パラメーターの構成
ネイティブな MySQL および PostgreSQL サーバーでは、パラメーター ファイルに格納されている構成設定が使用されるため、高度な構成が可能です。 PostgreSQL の場合、この情報は postgresql.conf ファイルに保持されます。 MySQL の場合、構成データはさまざまな my.cnf ファイルに格納されます。 Azure Database for MySQL/PostgreSQL では、これらのファイルに直接アクセスすることはできません。 代わりに、Azure portal または Azure CLI を使用して、サーバー パラメーターを表示および変更します。
Azure portal を使用したパラメーターの表示と設定
サーバーの構成パラメーターは、Azure portal のサーバーの [サーバー パラメーター] ページで使用できます。 パラメーターの値は、サーバーに適した値に変更できます。 下の画像は、Azure Database for PostgreSQL の [サーバー パラメーター] ページを示しています。 Azure Database for MySQL の対応するページも同様です。
サーバー構成の大部分が Azure によって制御されているため、すべてのサーバー構成パラメーターを使用できるわけではありません。 たとえば、メモリの割り当てに関連付けられているパラメーターはありません。 また、Azure Database for MySQL では ISAM ストレージがサポートされていないため、myisam パラメーターはありません。
"動的" とマークされているパラメーターへの変更は、すぐに有効になります。 "静的" とマークされているパラメーターでは、サーバーを再起動する必要があります。 これは、サーバーの [概要] ページで行います。
Azure CLI を使用したパラメーターの表示と設定
パラメーターをプログラムによって表示および変更するには、az mysql/postgres server configuration コマンドを使用します。 すべての構成パラメーターの設定を表示するには az mysql/postgres server configuration list を使用し、1 つのパラメーターを表示するには az mysql/postgres server configuration show [parameter-name] を使用します。 下のコード スニペットは、Azure Database for PostgreSQL の例を示しています。
az postgres server configuration show \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age
結果は次のようになります。
{
"allowedValues": "0-1000000",
"dataType": "Integer",
"defaultValue": "0",
"description": "Number of transactions by which VACUUM and HOT cleanup should be deferred, if any.",
"id": "**********************",
"name": "vacuum_defer_cleanup_age",
"resourceGroup": "northwindrg",
"source": "system-default",
"type": "Microsoft.DBforPostgreSQL/servers/configurations",
"value": "0"
}
この出力の重要な項目は、value フィールドです。このフィールドには、パラメーターの現在の設定が表示されます。
構成パラメーターの値を変更するには、次のように az mysql/postgres server configuration set コマンドを使用します。
az postgres server configuration set \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age \
--value 5
静的パラメーターを変更した後にサーバーを再起動する必要がある場合は、az mysql/postgres server restart コマンドを実行します。
az postgres server restart \
--resource-group northwindrg \
--name northwind101