質問
⚠️ この事例は公開されてから1年以上経過しています。 情報が古い可能性がありますので、ご注意ください。
🕓 事例公開日 : 2025-04-23
【背景】
今年1月から契約している環境で、Developmentプラン×2とSmallプラン×1を利用している。Developmentプランの環境をSmallプランに移管して動作検証を実施したところ、Smallプランの方で明らかにレスポンス遅延が起きている。データの差異もなく、データサイズが原因でもない。Smallプランの方がスペック的に優れているはずなので、何らかの原因があると考えている。Q1.
Smallプランでレスポンス遅延が発生する原因と対処方法を教えてください。回答
A1.
大変恐れ入りますが、レスポンスが遅いなど処理の遅延に関しましては、まずお客様にて問題の切り分けを実施していただく必要がございます。以下の流れと同様に進めていただくのがよろしいかと存じますので、参考までにご一読いただけますと幸いです。・Accel-Mart Plus お問い合わせガイド - 障害調査
https://aws.accel-mart.com/support_inquiry_guide/texts/inquiry_process/support_category_decision/failure_analysis.html
また、Accel-Mart Plus サービスサポート窓口の回答範囲は以下となっておりますので、合わせてご確認ください。
・Accel-Mart Plus お問い合わせガイド - ①Accel-Mart Plus サービスサポート窓口の回答範囲を確認
https://aws.accel-mart.com/support_inquiry_guide/texts/inquiry_process/support_range.html
このような前提ではございますが、可能な範囲でお答えさせていただきます。
調査の進め方
レスポンスが遅くなる理由は様々であり一概に判断することはできませんが、まずはどこで遅くなるか、ボトルネックとなる部分を特定する必要があります。その上で、その原因を調査・究明していくのがよろしいかと存じます。
例えば、通常のリクエストは以下の流れで処理が実行されます。
a. ブラウザ → b. Webサーバ → c. APサーバ → d. DBサーバ比較する環境で同じリクエストを送信し、上記のどの箇所で遅延が発生しているかを特定するのがよろしいかと存じます。以下、あくまでも参考程度ではございますが、調査方法の例を記載いたします。
ログについて
以降の説明に先立ち、Accel-Mart Plus でのログ取得方法をご確認ください。
・ログファイルの取得方法を教えてください。https://cloud.intra-mart.support/hc/ja/articles/16597104254873
区間別の調査方法
a. ブラウザ → b. Webサーバ
1. ブラウザの開発者ツール（Networkタブ）で各リクエストのタイミングを確認・Waiting (TTFB) が長い場合、サーバ側に入ってからの処理がボトルネック
・Connecting, SSL が長い場合はネットワークやTLS周りの可能性
2. curl -w オプションを使用して、各段階の時間（名前解決、接続、転送など）を測定
curl -s -o /dev/null -w '%{time_starttransfer}\n%{time_total}\n' https://www.example.com
curl -s -o /dev/null -w '%{json}' https://www.example.com
3. ブラウザから Accel-Mart Plus に到達するまでのネットワークの経路が同じなのかを確認
・今回の場合だと、Development プランと Smallプランの環境にてネットワーク経路に違いがないかを確認
・ping/traceroute/mtr によるネットワーク経路・遅延確認
b. Webサーバ → c. APサーバ
1. 同一リクエストに関する Apacheアクセスログ と Resinアクセスログやリクエストログ を確認し、Apache で処理が滞留していないかを確認・この区間での遅延は、APサーバへの負荷が高まっている可能性あり
2. リソース表示を確認し、処理に見合ったサーバリソースが確保できているかを確認
・リソースが足りない場合は、キャパシティプランニングを行った上で、プラン変更を検討
関連ドキュメント
・Accel-Mart Plus 運用者操作ガイド - リソース表示
https://aws.accel-mart.com/am_document/texts/system_operation/resource_display/index.html
・Accel-Mart Plus サービス仕様書 - リソースプラン
https://aws.accel-mart.com/service_manual/texts/03_specifications/02_resource_plans.html
・intra-mart Accel Platform ログ仕様書 - リクエストログ
https://document.intra-mart.jp/library/iap/public/im_core/im_log_specification/texts/specific_log/request.html
・intra-mart Accel Platform 設定ファイルリファレンス - Resin -
https://document.intra-mart.jp/library/iap/public/configuration/im_configuration_reference/texts/resin/log/index.html#%3Caccess-log%3E
・Apache - ログファイル - アクセスログ
https://httpd.apache.org/docs/current/logs.html#accesslog
c. APサーバ 単体
1. APサーバ上の処理に時間がかかっているリクエストや機能を特定する・以下で紹介されている「im-log-stats」を利用すると、時間がかかっているリクエストを特定することが容易になる
・Accel-Mart Plus お問い合わせガイド - ⑪問題の切り分け、原因特定作業などの実施
https://aws.accel-mart.com/support_inquiry_guide/texts/inquiry_process/support_category_decision/failure_analysis.html#root-cause-analysis
2. 時間がかかっている処理を特定したら、その処理内でどのようなことが行われているのかを確認
・必要に応じて、デバッグ文の挿入や、DEBUG, TRACEレベルのログを出力するようにして、処理時間を計測し、ボトルネック箇所を特定する
・以下にイメージを記載します（スクリプト開発モデルで例示します。その他の実装方式でも遅くなっていると思われる処理の前後でログを出力することをご検討ください）
修正前
function heavyLogic() {
executeLogic1();
executeSql2();
executeLogic3();
}
修正後
let LOGGER = Logger.getLogger();
function heavyLogic() {
LOGGER.trace("a");
executeLogic1();
LOGGER.trace("b");
executeSql2();
LOGGER.trace("c");
executeLogic3();
LOGGER.trace("d");
}
・この例の場合、ログ出力時刻より各ロジックの処理時間がわかる
・通常だとシステムログに出力される
・Traceレベルのログ出力設定が必要
関連ドキュメント
・intra-mart Accel Platform ログ仕様書 - システムログ
https://document.intra-mart.jp/library/iap/public/im_core/im_log_specification/texts/system_log/index.html
d. DBサーバ 単体
1. 実行しているSQLを特定後、そのSQLにどれだけの時間がかかっているのかを測定する・psql などの DBクライアントツールより、SQL単体で実行する
・前述の例の場合は、executeSql2() 前後のログ出力時刻より、処理時間が計測可能
・必要に応じてSQLログの出力を検討
・intra-mart Accel Platform ログ仕様書 - 付録 - SQLログを出力する
https://document.intra-mart.jp/library/iap/public/im_core/im_log_specification/texts/appendix/index.html#sqlログを出力する
2. SQLの実行計画を確認し、妥当な計画になっているかを確認する
・psql などの DBクライアントツールから EXPLAIN もしくは EXPLAIN ANALYZE を実行することで確認可能
・必要に応じて、SQLの修正、および、インデックスの検討を行う
c. APサーバ → d. DBサーバ
1. データベースコネクション数が枯渇していないかを確認する2. ネットワーク送受信量が帯域上限に達していないかを確認する
・いずれも、リソース表示機能にて確認可能
・処理に見合ったサーバリソースが確保できていない場合は、キャパシティプランニングを行った上で、プラン変更を検討
以上、レスポンス遅延の調査方法例を記載させていただきました。
上記を参考に、原因究明を行なっていただければと存じます。