質問
⚠️ この事例は公開されてから1年以上経過しています。 情報が古い可能性がありますので、ご注意ください。
🕓 事例公開日 : 2024-08-27
【背景】
検証環境において、特に接続操作を行っていない状況でシステムが停止した。リソース監視画面を確認したところ、APサーバのCPU使用率が高くなっていることを確認した。1. 事象
症状の説明：
2024年8月5日 18:55頃、検証環境でシステムが停止する事象が発生した。ユーザー側では特に操作を実施していなかったが、システムが自動的に再起動された。リソース表示画面でAPサーバのCPU使用率が上昇していることを確認した。2. 発生条件
・発生日時：2024年8月5日 18:55頃・対象環境：検証環境
・ユーザー操作：特になし（接続していない状態）
・システム状態：APサーバのCPU使用率が上昇
回答
1. 原因
技術的な原因：
Resinがシステムの高負荷を検知し、自動的に再起動処理を実行しました。CPU使用率とメモリ使用率が上昇したことが再起動のトリガーとなっています。なお、AWS基盤側での障害は発生していませんでした。技術的要因の分析：
・要因1：18:30以降、複数のリクエストで処理時間が5秒以上に延長 → システムリソースの継続的な圧迫・要因2：18:55-19:00の時間帯で特にリクエスト処理時間が増大 → CPU・メモリ使用率のピーク到達
・要因3：最長で332秒（約5.5分）を要するリクエストが発生 → スレッドプールの枯渇とリソース競合
・要因4：複数の重い処理が同時並行で実行 → システム全体の応答性能の劣化
・要因5：ログアウト処理やチャット関連APIで異常な処理時間を記録 → アプリケーションレベルでの処理遅延
根本的な要因：
18:30以降に実行された複数のリクエストが通常よりも著しく長い処理時間を要したことで、APサーバのCPUとメモリリソースが継続的に圧迫され、Resinの自動再起動閾値に到達したことが根本原因です。2. 対応方法
根本解決方法：
1. 18:30から19:00の時間帯に実行された業務処理やバッチ処理の内容を確認してください2. 以下の処理で特に長時間を要したものについて、処理内容やデータ量を見直してください：
・ユーザーメニュー取得API（最大166秒）
・ログアウト処理（最大199秒）
・チャット連絡先取得API（最大332秒）
・ユーザー定義画面表示（最大128秒）
3. 該当時間帯の業務処理を特定し、処理の最適化やデータ量の削減を検討してください
暫定対処方法：
1. 重い処理が集中する時間帯を避けて業務を実施してください2. 大量データを扱う処理は分割実行を検討してください
3. リソース監視画面でCPU使用率を定期的に確認し、高負荷時は処理を一時停止してください
3. 原因究明に至るまでの調査方法
1. システム再起動の発生時刻（2024-08-05 18:55頃）を特定2. AWS基盤側の障害履歴を確認し、外部要因を除外
3. Resinの再起動ログを確認し、自動再起動であることを確認
4. リソース監視データからCPU使用率とメモリ使用率の推移を分析
5. im-log-statsツールを使用してリクエストログを解析し、処理時間の傾向を可視化
6. 18:30以降のリクエストログから処理時間5秒以上のリクエストを抽出（availability_check/index.jspを除外）
7. 抽出されたリクエストの処理時間、URL、HTTPメソッドを一覧化
8. 特に18:55-19:00の時間帯で処理時間が集中していることを確認
9. 最も処理時間が長かったリクエスト（チャット連絡先取得API：332秒）を特定
参考情報：
ログ解析の詳細な手順については、以下のドキュメントをご参照ください。
Accel-Mart Plus お問い合わせガイド - ⑪問題の切り分け、原因特定作業などの実施