AgileWorksを運用していた際、通常のログイン、申請、承認は問題なく利用できるにもかかわらず、フォームのアップロードだけが完了しない障害が発生しました。画面には明確なエラーが表示されず、処理中の状態が続いた後に通信が終了するため、最初はファイルの問題なのか、AgileWorksの問題なのか判断できませんでした。
私は、ファイル、ブラウザ、サーバー負荷、AgileWorksのログ、Tomcatのログ、Webサーバーのログを順番に確認しました。その結果、フォームの処理時間が既存のタイムアウト値である60秒を超えており、処理完了前に通信が終了している可能性が高いと判断しました。対象の設定を100秒へ変更したところ、問題のフォームをアップロードできるようになりました。
ログインや申請は正常なのにフォームだけ完了しなかった
発生していた症状は、フォームファイルを選択してアップロードを開始すると、完了画面へ進まず、処理中の表示が続くというものでした。AgileWorksへのログイン、申請画面の表示、申請データの登録、承認操作には問題がありませんでした。
また、同じフォームで操作すると、毎回ほぼ同じ状態になりました。完全にサーバーへ接続できないわけではなく、アップロード開始直後は通信が発生していました。その後、一定時間が経過するとブラウザ側の処理が終了します。
通常操作が正常であるため、AgileWorks全体の停止ではないと考えました。一方で、フォームアップロードは、ファイルの受信だけでなく、内容の展開や検証、設定の反映などが行われる可能性があります。通常の画面表示より長い処理だけで問題が出ることから、私は処理時間とタイムアウトを重点的に確認しました。
最初にファイルと再現条件を確認した
サーバー設定を変更する前に、アップロードするファイル自体に問題がないか確認しました。ファイル名、拡張子、容量を記録し、同じファイルで毎回再現するかを調べました。また、ファイル名を短くしたものや、別のフォームでも操作しました。
次に、別の利用者、別のブラウザ、別の端末で再現するか確認しました。特定の利用者だけで発生する場合は権限、特定の端末だけで発生する場合はブラウザやセキュリティソフトなどが原因の可能性があります。しかし、複数の条件で同じ症状が発生したため、サーバー側の調査を進めました。
さらに、小さいフォームと問題のフォームで処理時間を比較しました。小さいファイルでは完了する場合、大きさやフォームの複雑さによって処理時間が変わっている可能性があります。反対に、すべてのファイルが即座に失敗する場合は、権限、容量制限、設定ミスなど別の原因も考えられます。
ブラウザからTomcatまでの通信経路を整理した
フォームのアップロード処理は、ブラウザからAgileWorksへ直接届くとは限りません。私の調査では、ブラウザ、Webサーバーまたはリバースプロキシ、Tomcat、AgileWorksという通信経路を意識しました。
| 確認対象 | 私が確認した内容 |
|---|---|
| ブラウザ | 通信開始時刻、終了時刻、HTTPステータス |
| Webサーバー | アクセスログ、エラーログ、応答待ち設定 |
| Tomcat | 処理ログ、タイムアウト設定、起動状態 |
| AgileWorks | アップロード処理の開始と終了、エラー記録 |
| サーバー資源 | CPU、メモリ、ディスク空き容量 |
途中に複数のサーバーがある場合、それぞれにタイムアウト設定が存在する可能性があります。Tomcatを変更しても、手前のWebサーバーが短い時間で接続を切れば改善しません。そのため、どこで通信が終わっているのかをログの時刻で照合しました。
処理が約60秒で終了することを確認した
原因の切り分けで役立ったのが、操作開始から終了までの時間を測定することでした。エラー内容だけを見るのではなく、何秒後に処理が終了するかを記録しました。その結果、問題のフォームでは約60秒で通信が終了する傾向がありました。
次の例は、記事へ掲載するために時刻などを置き換えたマスキング済みの例です。実際のログを公開する場合は、サーバー名、利用者名、URL、IPアドレスなどを削除する必要があります。
09:15:02 フォームアップロード開始
09:16:02 ブラウザ側の通信終了
経過時間：約60秒
AgileWorksの通常画面：正常
通常の申請・承認：正常
フォームアップロード：未完了毎回ほぼ同じ時間で終了する場合、偶発的なファイル破損や一時的な負荷だけでなく、固定値として設定されたタイムアウトの可能性が高くなります。私は関連する設定値を確認し、60秒の値と実際の終了時刻が一致することを確認しました。
フォームアップロードだけ処理時間が長くなる理由を考えた
通常の画面表示や申請処理は短時間で完了していても、フォームアップロードでは複数の処理が行われます。ファイルを受信した後、内容の展開、形式の確認、設定情報の読み込み、登録処理などが行われるため、通常操作より時間がかかる可能性があります。
一方で、単純にタイムアウトを延ばせばよいとは限りません。以前より処理が遅くなっている場合は、CPU使用率、メモリ不足、ディスク容量、ストレージ性能、データベースの応答、ウイルス対策ソフトの走査なども確認する必要があります。
私の調査では、通常機能は正常で、サーバー資源にも直ちに異常と判断できる状態は見つかりませんでした。また、処理が毎回約60秒で終了していたことから、タイムアウト設定の見直しを行う判断をしました。
タイムアウトを60秒から100秒へ変更した
対象環境では、関連するタイムアウト値が60秒に設定されていました。一方、問題のフォームは60秒以内に完了しないことがありました。そこで、処理完了まで一定の余裕を確保するため、対象の設定を100秒へ変更しました。
変更前：60秒
変更後：100秒100秒は、すべてのAgileWorks環境に適した共通の推奨値という意味ではありません。今回の環境で確認した処理時間と既存設定を比較し、余裕を持たせる目的で設定した値です。実際の設定箇所や名称は、製品のバージョンやWebサーバー構成によって異なる可能性があります。
設定変更前には、対象ファイルのバックアップを取得しました。また、変更前の値、変更後の値、作業日時、作業者、変更理由を記録しました。障害対応後に元の値へ戻す必要が生じた場合に備えるためです。
設定変更後にサービスを再起動した
設定ファイルを変更した後、記述内容を確認し、関連サービスを再起動しました。本番環境で作業する場合は、申請や承認への影響があるため、事前に利用部門へ作業時間を周知する必要があります。
再起動後は、サービスが起動状態になったことだけでなく、起動ログにエラーがないかを確認しました。設定ファイルの記述ミスがある場合、サービスが起動しなかったり、一部機能が利用できなくなったりする可能性があります。
その後、AgileWorksへログインし、画面表示と検索を確認しました。基本機能が正常であることを確認してから、問題のフォームを再アップロードしました。障害対応では、対象機能だけを確認するのではなく、変更によって通常機能へ影響が出ていないかも確認することが重要です。
変更後に実施したテスト
設定反映後、問題が発生していたフォームを同じ条件で再度アップロードしました。その結果、60秒を超えても通信が終了せず、処理が完了することを確認しました。また、開始から完了までの時間を記録し、100秒に近い時間が常に必要になっていないかも確認しました。
次に、別のフォームや小さいファイルでもアップロードを行いました。特定のフォームだけが偶然成功したのではなく、フォーム管理全体に問題がないことを確かめるためです。
- 問題が発生していたフォームの再アップロード
- アップロード完了までの時間測定
- 別フォームと小さいファイルのアップロード
- ログイン、検索、画面表示
- 通常の申請、承認、差し戻し
- CPU、メモリ、ディスク使用状況
- TomcatとAgileWorksのエラーログ
さらに、アップロードしたフォームを使って申請画面を開き、入力、保存、承認経路まで確認しました。管理画面でアップロード完了と表示されても、実際のフォームが正常に利用できなければ復旧完了とは判断できません。
タイムアウトを長くするときの注意点
タイムアウト値を長くすれば、処理が完了するまで通信を維持しやすくなります。しかし、異常な処理や応答しない処理も長時間残る可能性があるため、極端に大きな値へ変更することは避けるべきです。
また、Tomcat以外にWebサーバーやリバースプロキシがある場合、最も短いタイムアウトが先に動作します。Tomcatを100秒へ変更しても、手前のサーバーが60秒で接続を終了すれば改善しません。通信経路上の値を一覧化し、矛盾がないか確認する必要があります。
処理時間が以前より長くなっている場合は、タイムアウト変更だけで終わらせず、フォームの複雑化、サーバー負荷、ストレージ、データベースなどを調べます。タイムアウトは原因そのものではなく、処理遅延の結果として表面化している可能性もあります。
同じ症状が発生したときの調査順序
同様の障害が発生した場合、私は次の順序で確認すると原因を整理しやすいと考えています。作業ごとに開始時刻、終了時刻、結果を記録すると、ログとの照合や保守担当への説明に役立ちます。
- ファイル名、容量、拡張子、操作手順を記録する
- 別の利用者、ブラウザ、端末で再現性を確認する
- 別フォームや小さいファイルと比較する
- CPU、メモリ、ディスク容量を確認する
- ブラウザ、Webサーバー、Tomcat、AgileWorksのログを確認する
- 操作開始から失敗までの時間を測定する
- タイムアウト設定と終了時刻を比較する
- 設定変更後に通常機能を含めてテストする
まとめ
AgileWorksでフォームアップロードだけが完了しない場合は、ファイルだけでなく、操作開始から通信終了までの時間を確認することが重要です。毎回ほぼ同じ秒数で終了する場合は、Webサーバー、プロキシ、Tomcatなどのタイムアウトが関係している可能性があります。
私の環境では、通常の申請や承認は正常でしたが、フォームアップロードが約60秒で終了していました。ログと設定を照合し、対象のタイムアウトを60秒から100秒へ変更したところ、アップロードが完了しました。
ただし、タイムアウト値を延ばすだけでなく、サーバー負荷や処理遅延の原因も確認する必要があります。変更後は問題のフォームだけでなく、ログイン、申請、承認、別フォームのアップロードまでテストすることが大切です。
コメント