質問
🕓 事例公開日 : 2026-07-14
【背景】
2026年5月のサーバリソース状況をチェックしたところ、以下の2つの異常な上昇を発見しました。 仮想サーバのネットワーク送受信量について5月4日の10:00～11:00頃と16:00～17:00頃に、ネットワーク送受信量が急増していました。AP1の送信量が多いタイミングでAP2の受信量が増加し、逆にAP1の受信量が多いときはAP2の送信量が増加するという傾向が見られました。該当時間帯に30秒以上かかったリクエストは、すべて特定のAPI（https://example.com/foo/bar/baz/count）でした。 データベースサーバのI/O・スループット・ストレージ容量について
5月22日21:00頃に、読み取りIOPS、書き込みIOPS、読み取りスループット、書き込みスループットが急上昇しました。同時に空きストレージ容量が急激に減少し、その後徐々に回復しました。リクエストログを調べましたが、処理時間が長いリクエストは見つからず、原因が特定できませんでした。
Q1. ネットワーク送受信量上昇の原因について
仮想サーバのネットワーク送受信量が上昇した原因は、特定のリクエストURL（https://example.com/foo/bar/baz/count）によるものと考えてよいでしょうか。Q2. データベースサーバのリソース上昇原因について
データベースサーバで読み取りIOPS、書き込みIOPS、読み取りスループット、書き込みスループット、空きストレージ容量に異常が発生した原因を教えてください。ログを確認しましたが、原因となる情報が見つかりませんでした。回答
A1. ネットワーク送受信量上昇の原因について
ご提示いただいたリクエストURLは、今回のネットワーク送受信量上昇の直接的な要因ではないと判断しております。今回のネットワーク送受信量上昇は、APサーバ間（AP01・AP02）で実行されるセッションレプリケーションが原因である可能性が高いと考えられます。
弊社で個社利用環境のネットワーク通信状況を調査したところ、該当時間帯にAPサーバ間でHazelcastを介した大量の通信が発生していたことを確認いたしました。
Hazelcastは、intra-mart Accel Platformのセッション管理を行うコンポーネントであり、セッションレプリケーション（APサーバ間でセッション情報を同期・複製する仕組み）もこのコンポーネントによって実行されます。A2. データベースサーバのリソース上昇原因について
内部ログを調査した結果、5月22日21:00頃の該当時間帯に、データベースの特定テーブルに対して、PostgreSQLの自動メンテナンス処理（AutoVacuum）が実行されていたことを確認いたしました。AutoVacuum処理は、データベースの正常動作を維持するためにPostgreSQLが自動的に実行するものであり、今回のディスクI/O・スループット上昇、および空きストレージ容量の一時的な減少の原因と推定されます。
AutoVacuum処理に伴う一時的な書き込み増加により、空きストレージ容量も一時的に減少いたしましたが、処理完了後は元の水準に回復いたしました。
AutoVacuumの詳細については、以下のPostgreSQLのドキュメントをご参照ください。
- PostgreSQL 15 ドキュメント - 定常的なデータベース保守作業
https://www.postgresql.jp/docs/15/routine-vacuuming.html#AUTOVACUUM