はじめに
本記事では、数年前に弊社のIBM i システムにて発生したレスポンス遅延について、原因調査や実施した改善策などをまとめたいと思います。
IBM i RiSINGへの参加、Qiitaへの投稿は今回が初めての経験となりますが、よろしくお願いいたします。
システム構成概略
弊社では、社内で利用する販売系業務システムの更新に伴い、新たにIBM i にて構築したシステムを利用する運びとなりました。
業務システムでのIBM i の利用方法としては、主にIBM i のHTTPサーバ機能を使用しており、ユーザ（例：営業所の社員）は業務用にカスタマイズされたブラウザのGUIにて操作を行います。
これによって、ユーザが5250エミュレータの画面を直接操作することなく、業務システムを利用できる仕組みとなっております。
業務システムの構成図（概略）は以下の通りです。
発生した現象
さて、紆余曲折の開発フェーズを終え、いざ業務システムを運用開始したところ・・・
「メニュー画面より機能を選択しても画面遷移しない！」
「登録ボタンを押したら画面が固まってタイムアウトになり、入力中の内容が消えた！！」
「そもそもアプリがロード画面のまま立ち上がらない！！！」
といった怒りの声が全国各地の営業所等々から多数寄せられ、問い合わせ窓口はパンク状態となってしまったのでした・・・
この現象は発生後15分程度で自然に復旧する場合もあれば、数時間以上復旧せず、やむを得ず手動でIPLを実行してようやく収まった...と思いきや直後に再発するなど、ユーザ側への影響が大きくなる場合もあり、改善が求められていました。
また、発生中の動作としては、画面が固まったとしても完全なフリーズ状態ではなく、
数十分待つことで正常な画面遷移が行われる場合もある、
つまり大規模なレスポンス遅延が発生している
ということが判明しました。
しかし、しばらく待ってもらうことで必ずしも回避できるというものではなく、
ある一定時間以上の遅延が発生すると待っている間に
タイムアウトとなり、アプリが強制終了するため、大規模な遅延発生時は実質システム利用不可のような状態となっていました。
レスポンス遅延の原因調査
運用チームとして、上記現象の原因調査を行いました。
すでに判明していたのは、この現象はシステムの稼働中常に発生し続けるものではなく、
特定の時間のみに集中的に発生しているということです。
具体的には・・・
- ・08:30前後
- 弊社の始業が08:30のため、業務システム起動時のログイン処理が集中している？
- ・11:45前後
- 午前中が期限の発注処理が集中している？
- ・17:00前後
- 弊社の終業が17:30のため、駆け込みで処理が集中している？
以上のように、現象が発生する時間帯には、処理が集中しているであろうことが予想されました。
そのような場合、まず思い浮かべる要因としては、CPUのリソース不足、
すなわち、システムにおいて負荷がピークとなる時間帯にCPUがフルパワーで処理しても
処理が追い付かず、未完了の処理が溜まってしまい、システムが遅延するという現象が考えられます。
事前の調査で、現象が発生していない時のCPU使用率は60％～80％であることが判明しました。
早速、現象発生時にCPU使用率を調査したところ...
低い時で30％台！
現象発生時のCPU使用率はおおむね通常時よりも低かったのです！
逆に言うと、現象発生時には何らかの理由により
CPUがフルパワーを出すことができない状態となっている、ということです。
その後も関係各所と協力の上、調査を進めた結果、
「アクティブスレッド」値が上限に達していることが原因ではないか
という可能性が判明しました。
実はこの「アクティブスレッド」ですが、IBM i のHTTPサーバ機能、IBM HTTP Server for iにおいて、重要な役割を担っている値なのです！
アクティブスレッドの表示方法
この「アクティブスレッド」の現在の値ですが、IBM HTTP Server for iを利用されている方にはお馴染み（？）の「IBM Web Administration for i」より確認することができます。
ログイン後、メニュー左下の「リアルタイム・サーバー統計」をクリックすると
（画像は一部加工しております）
「アクティブ・スレッド数」が表示されます。
アクティブスレッドとは
では、そもそも「アクティブスレッド」とは何の値なのでしょうか。
おそらく、IBM i 技術者の方でも聞いたことがないという方も多いのではないでしょうか。
（・・・聞いたことがないというIBM i 技術者の皆様はおそらくHTTPサーバ機能を利用されていない方かと思われます。
そもそもIBM i でHTTPサーバ機能を利用するシステムはかなり少数派かと思いますので、業務のお役には立てないかもしれませんが、よろしければ最後までご覧ください。）
まずはIBM HTTP Server for iのドキュメントより、「スレッド」の記載をご確認ください。
引用元：https://www.ibm.com/docs/ja/i/7.5.0?topic=tasks-managing-http-server-performance#rzaiemngperf__threads
スレッド
サーバーは、クライアント要求を受け取るたびに、まず使用可能なスレッドがあるかどうかを確認し、次に使用可能なスレッドを使用して要求を処理します。 使用可能なスレッドがない場合は、スレッドが使用可能になるまで要求を保持します。 要求が終了すると、サーバー・スレッドはアイドル状態になります (その時点で、サーバーが再び使用できるようになります)。
この「クライアント要求を処理するために使用中のスレッド」こそが
「アクティブスレッド」なのです！
一方、「使用が終了しアイドル状態に戻ったスレッド」は
「アイドルスレッド」といいます。
そして、このアクティブスレッドの最大数は管理者が設定することができます。
（例えば、アクティブスレッドの最大数を100に設定した場合、アクティブスレッドの現在の値が60であれば、アイドルスレッドの値は40ということになります。）
以上を踏まえ、もう一度ドキュメントをご覧ください。
引用元：https://www.ibm.com/docs/ja/i/7.5.0?topic=tasks-managing-http-server-performance#rzaiemngperf__threads
スレッド
サーバーは、クライアント要求を受け取るたびに、まず使用可能なスレッドがあるかどうかを確認し、次に使用可能なスレッドを使用して要求を処理します。 使用可能なスレッドがない場合は、スレッドが使用可能になるまで要求を保持します。 要求が終了すると、サーバー・スレッドはアイドル状態になります (その時点で、サーバーが再び使用できるようになります)。
...
使用可能なスレッドがない場合は、スレッドが使用可能になるまで要求を保持します。
・ ・ ・
使 用 可 能 に な る ま で 要 求 を 保 持します。
すなわち、処理が集中する時間帯に、処理中のクライアント要求が増え、
アクティブスレッド値が最大数に達している場合、
新たなクライアント要求は、アクティブスレッドがアイドルスレッドに戻り
再び使用可能となるまで延々と待ちつづけることになります。
待っている間、当然処理は行われないため、画面遷移もしなければ登録も行われません。
画面は固まります。
そして、ユーザがブチ切れることになります。
数十分待って画面遷移が行われたケースについても、待っている間に実行中のいずれかの処理が終わり、アクティブスレッドがアイドルスレッドに戻った結果、無事に処理が開始されたということで説明がつきます。待ち時間が長ければ当然タイムアウトにもなります。
改めて、現象発生時（レスポンス遅延現象発生中かつCPU使用率が低い時）のアクティブスレッド値を取得してみました。
ちなみに、この時のアクティブスレッドの最大数設定値は...言うまでもなく150です。
見事に張り付いています。
アクティブスレッドが高くなる原因
では、なぜ処理集中によってアクティブスレッド値が高くなるのでしょうか？
重要なのは、アクティブスレッド値が高い時間帯にCPUが利用できていない、ということです。
これはCPUが仕事をサボっているため...ではなく、CPUが処理を行う以前の段階で何らかのボトルネックが発生しているためと考えました。
ボトルネック箇所にて処理に時間がかかった結果、アクティブスレッドが増え、やがて最大数に達してしまい、CPUに余力があってもそれ以降のクライアント要求が処理されず待ち続けているという読みです。
一方で、アクティブスレッド値とCPU使用率の両方が高くなるケースも稀にありますが、弊社の場合1分程度でアクティブスレッド値が下がります。両方が高い状態のまま長時間が経過してレスポンス遅延が発生したことは現在のところありません。
両方が高い状態が続き、レスポンス遅延が発生する場合、IBM i のスペック面（CPU等）がボトルネック箇所になっていることが考えられます。
アクティブスレッドとCPU使用率の関係
改めて、アクティブスレッドとCPU使用率の関係を下表にまとめました。
| アクティブスレッド | |||
|---|---|---|---|
| 低い | 高い（レスポンス遅延発生） | ||
| CPU 使用率 |
低い | 良好 | CPU処理以前の段階で 何らかのボトルネックが発生？ |
| 高い | 問題なし （CPUの高負荷が続いても 処理しきれている場合） |
IBM i のスペック面が ボトルネック箇所になっている？ |
|
ボトルネック箇所の調査
関係各所と協力の上、今回の現象でのボトルネック箇所の調査を進めた結果、以下の点がボトルネックになっている可能性が高いということがわかりました。
（実際のところ、他にも多種多様な改善策を試していますが、今回は代表的な項目に絞って説明させてください。）
- ・ディスクの動作時間
- IBM i にはDB2データベースが標準で統合されていますが、プログラム内でSELECT文のSQLを実行する際、指定したデータは当然IBM i に搭載されたディスクから取得しています。
- そして、ディスクがHDDの場合、目当てのデータが記録されている場所までプラッタを回転させ、データを読み取る磁気ヘッドを動かして、やっとデータを取り出せる仕組みです。このHDDの動作時間についてはディスクの構造上どうしてもかかってしまうものですが、通常は微々たるものです。
- しかし、多数のユーザが利用した際、例えば別のユーザから同時に同じプラッタの両端の位置に記録されたデータをSELECTされるようなことがあれば、当然ディスクの回転時間は増加し、動作時間も無視できないものとなることが想定されます。
- 弊社のIBM i のディスクはHDDを使用しており、レスポンス遅延発生時の動作時間を測定したところ推奨値の数倍の動作時間がかかっていることが判明しました。
- ・ネットワークの混雑
- 上記にて記載したレスポンス遅延の発生時間帯ですが、他の企業においても概ね同様の時間帯に始業時間や昼休み時間が設定されていることが想定されます。
- そして、ベストエフォート型のネットワーク回線を使用している場合、同じ回線を複数の企業で共同利用するような形となるため、同一時間帯に利用が集中すると1ユーザの利用できる帯域は小さくなり、結果的に回線速度も低下します。
- アクティブスレッドはクライアント要求が終了するまで、つまり通信が完了するまでアイドルスレッドに戻らないため、IBM i サーバ内でのSELECT処理にかかる時間が同じでも、SELECTした結果をクライアント側へ送信する際に通信時間がかかると、その分通信が完了するまでの時間が増え、レスポンス遅延につながります。
レスポンス改善のためのチェックリスト
最後に、一連の調査結果を踏まえて、IBM i HTTPサーバ機能利用時のレスポンス遅延時にチェックするべき項目を、チェックリストとしてまとめます。
①アクティブスレッド値（対策例：適切なアクティブスレッド上限値の設定）
アクティブスレッド値が最大数に達している場合、それ以降の要求を処理できず、レスポンス遅延につながります。
最大数を変更することも可能ですが、あまり大きな値に設定するとシステム・パフォーマンスが低下する可能性があるとのことですので、少し最大値を上げてみて、それでもレスポンス遅延が発生し長時間（数十分以上～）続くような場合には、最大数を上げなくても済むように根本的な対策が必要となります。
②CPU使用率（対策例：IBM i のスペックアップ）
レスポンス遅延発生時のCPU使用率を確認します。アクティブスレッド値とCPU使用率の両方が高い場合、IBM i のスペック面（CPU等）がボトルネック箇所になっていることが考えられ、IBM i のスペックアップ等が必要となります。
アクティブスレッド値が高く、CPU使用率が通常よりも低い場合、CPU処理以前の段階でのボトルネックを調査する必要があります。
③ディスクの動作時間（対策例：インデックスの作成）
CPU処理以前の段階でのボトルネックとして、ディスクの動作時間がかかっているケースがあります。
対策例としては、DB2のテーブルにおいて適切なインデックスの作成を行うことでレスポンス遅延の軽減が可能となるケースがあります。
④ネットワークの状況（対策例：ベストエフォート型回線から帯域保証型回線への変更）
同様に、CPU処理以前の段階でのボトルネックとして、ネットワークの混雑によってもレスポンス遅延が発生するケースがあります。
対策例としては、ベストエフォート型のネットワーク回線を利用している場合、帯域保証型のネットワーク回線に変更することで、利用集中による混雑時の回線速度低下が軽減され、レスポンス遅延の軽減が可能となるケースがあります。
まとめ・感想
今回、IBM i RiSINGの成果物として、以前行ったIBM i でのレスポンス遅延への対応を振り返り、Qiita記事としてまとめることによって、自分自身としても当時の対応などを改めて整理することができ、良い経験となりました。
弊社のIBM i システムにおいては、上記チェックリスト③・④の対応を行ったことにより（詳しい内容は記載できず、申し訳ありません）現在では長時間のレスポンス遅延はほぼ発生しない状態となりましたが、アクティブスレッド値・CPU使用率については常に確認できるよう、常時リアルタイムの値を表示するモニターを作成して、監視を行っています。
ご覧いただきありがとうございました！
当記事の著作権はIBMに帰属します。
詳細はこちらを参照ください。