質問
🕓 事例公開日 : 2026-09-01
【背景】
5月にネットワーク送受信量が急増した件について、以前の問い合わせでセッションレプリケーションが原因である可能性が高いとの回答をいただいた。この件について、発生要因の詳細を把握したいと考えている。Q1. セッションレプリケーションが発生したトリガーは何か
該当時間帯にセッションレプリケーションが増加した要因を知りたい。Q2. システムイベントとの関連性はあるか
ノード切替、再起動、フェイルオーバー、システムメンテナンス等との関連有無を確認したい。Q3. アプリケーション処理に起因する可能性はあるか
利用状況やアプリケーション処理に起因する可能性がある場合、その観点で確認可能な情報を教えてほしい。回答
A1. セッションレプリケーション増加の要因について
セッション管理モジュールのセッションレプリケーションは、リクエスト終了時にレプリケーション処理が実施される仕様です。該当時間帯に大量の通信が発生していた点については、リクエストの急増に伴うセッションデータの蓄積が影響している可能性があります。
また、一般的な要因として、以下のようなタイミングでも通信量が増加する場合があります。
- クラスタへのノード追加や削除に伴うリバランス
- ノードの再参加や障害復旧時のデータ再同期
特定の時間帯のAPサーバのリクエストログを確認したところ、通常時と比較しリクエスト数の増加が確認されました。この時間帯には、フォーム関連処理、ワークフロー確認処理、承認処理など、複数の異なる処理のリクエストが同時間帯に重なって発生しておりました。
また、この時間帯には通常時より長い応答時間も記録されており、処理が集中していたことを示す一つの可能性として考えております。特定のURLについても他の処理と同時間帯に重なって応答時間の増加が見られましたが、当該URL単体が今回の直接の原因ではないと考えております。
なお、他の複数の時間帯についても、通常時と比較してリクエスト数の増加が確認されており、同様の傾向であったと考えられます。
A2. システムイベントとの関連性について
該当時間帯のログを確認いたしましたが、ノードの参加・離脱に関する記録は見られず、フェイルオーバー、システムメンテナンス等との関連性についても見られませんでした。今回のセッションレプリケーション増加は、ノード切替・再起動・フェイルオーバー・メンテナンス等によるものではなく、複数の処理が同時間帯に集中したことによるリクエストおよびセッションデータ更新の急増が要因であったと考えております。
A3. アプリケーション処理に起因する可能性の確認方法について
リクエストの急増に伴うセッションデータの蓄積が影響している可能性がございます。この点の確認方法として、以下のログをご確認いただくことをお勧めいたします。リクエストログの確認
リクエストログをご確認いただくことで、どのようなリクエストが発生していたか、また当該リクエストを契機として実行された処理の状況をご確認いただける可能性がございます。
- intra-mart Accel Platform ログ仕様書 - リクエストログ
https://document.intra-mart.jp/library/iap/public/im_core/im_log_specification/texts/specific_log/request.html
Resin JVM ログの確認
処理が滞留していた場合にはスレッドダンプが出力されていることがございます。こちらをあわせてご確認いただくことで、事象の発生状況や原因の切り分けにお役立ていただける可能性がございます。
出力されたスレッドダンプの取得方法については、以下 FAQ をご確認ください。
- Accel-Mart Plus 環境でヒープダンプやスレッドダンプを取得する方法はありますか？
https://cloud.intra-mart.support/hc/ja/articles/50801164299545
Hazelcastログの確認
通信量増加要因となり得る「ノード追加」「ノード削除」「ノード再参加」については、Hazelcastログにその発生履歴が出力されます。該当時間帯のHazelcastログをご確認いただくことで、セッションレプリケーションとの関連有無の調査にお役立ていただける可能性がございます。
- intra-mart Accel Platform ログ仕様書 - Hazelcastログ
https://document.intra-mart.jp/library/iap/public/im_core/im_log_specification/texts/specific_log/hazelcast.html
今後の対応について
ネットワーク送受信量の推移を確認したところ、突出した増加はその後は見られていない状況です。そのため、様子を見ていただき、事象が再発した場合に、改めて対応をご検討いただく、という進め方も一つかと存じます。
その際は、対象時間帯に複数の処理が重ならないよう実行タイミングを分散いただくことで、リクエストの集中による負荷の増加を抑えられる可能性がございます。
また、セッションレプリケーションの発生自体を抑制するための機能や設定はございませんが、セッションの保存（セッションレプリケーション）は基本的にリクエストごとに実行されるため、セッションレプリケーションの発生回数を減らすには、恒常的な対応としてアプリケーション全体のリクエスト数を見直していただくことが有効と考えられます。