APサーバのリソースで最もよく使われるのは、データソースとスレッドプール
アプリケーションサーバ（APサーバ）は、データベースのコネクション、アプリケーションの実行スレッド、メッセージングのキューなどさまざまなリソースをアプリケーションへ供給します。今回は、それらのリソースの中で最もよく使われる、次の2つを例に紹介します。
- データベースのコネクションを管理しているデータソース
- アプリケーションの実行スレッドを束ねているスレッドプール
この2つはたいていのケースで使われて、問題となることも多いため、リソースを必ず監視しましょう。
リソース数を確認した結果、残りリソースが0ではない（すなわち、不足していない）のに何か問題が起きているならば、ほかのレイヤーを分析しましょう。
残りリソース数が0の場合は、リソースが不足している可能性があります。
さらに、リソース割り当て待ちが増加傾向にある場合は、リソースが不足しています。
リソースを追加する際、別のリソースを消費することに注意
リソースが不足している場合には、リソースの追加を検討します。その際、リソースを追加すると別のリソースを消費することに注意しましょう。
たとえば、データソース内のコネクション数を追加する場合には、APサーバからDBサーバへ接続するコネクション数が増えます。DBサーバは、コネクションごとにCPUとメモリを消費します。
また、DBサーバには同時に確立できるコネクションに上限があるのが一般的です。コネクションを追加する際には、その上限に達しないようにしつつ、DBサーバのCPUやメモリなどのリソースが枯渇しないように注意しましょう。
スレッドプールにスレッドを追加する場合には、APサーバ内で同時に処理するリクエスト量が増えます。アプリケーションが使うリソースには、APサーバが提供するもののほかに、HTTPコネクションなどアプリケーションが独自に使用するものがあります。それらも接続先のリソースを消費するので、注意しましょう。
さらに、APサーバが動いているOSのCPUやメモリなどのハードウェアリソースにも上限があります。同時に処理するリクエスト量が増えると、より多くのハードウェアリソースが必要となるので注意しましょう。
リソースを監視するときに着目する3つの要素
リソースを監視する際は、以下の3つの要素に着目します。
リソースの状態
リソースによって異なりますが、多くの場合、次の3つの状態があります。
- アプリケーションへ貸し出し中
- プール内で待機中
- アプリケーションが待機中
これらの状態ごとに、どの状態のリソースがどの程度あるのかを記録し、その推移を見ることで、システムの状態を把握できます。
状態の変化
1つ1つのリソースがどのように状態が変化していったかを記録します。この情報によって、「各リソースがいつ貸し出されて、いつ返却されたのか」を確認でき、リソースのリース期間の推移などを算出できるようになります。
状態ごとのリソース量
これはAPサーバが公開しているMBeanへアクセスすることで取得します。
リソースの情報を提供するAPサーバを使うのがおすすめ
状態の変化に関する情報は、APサーバのデバッグ機能などによって、アプリケーションの修正やサーバの再起動などをせずに取得できます。
このような情報を取得する機能がないAPサーバを使用している場合には、同様の機能を自ら実装しなければなりません。リソースが貸し出されるたびに状態を「貸し出し中」へ変更し、返却時に「プール中」へ変更するようなログやMBeanをフレームワークで実装しましょう。
ただし、この方法では、「貸し出し中」と「プール内で待機中」の2つの状態しかわかりません。アプリケーションがどの程度貸し出しを待っているかわからず、リソースが不足している明確な証拠にはならないため、注意が必要です。
リソースの情報を取得する仕組みの構築は大変であり、障害時など問題が発覚した時にしか使用されないことが多いです。システム本来の用途である業務の改善とは違い、運用の高度化に対する工数の見積もりやスケジューリングがされにくいのが現実で、実装されていないことがよくあります。そのため、リソースの情報をMBeanやデバッグ機能で提供しているAPサーバを使うことをおすすめします。
本連載のまとめ
これまで、システム内のさまざまなレイヤーをどのように監視していけばいいかを紹介してきました。障害を起こさないシステムの構築は困難ですが、障害の切り分けをしやすいシステムの構築はそれほど大変ではありません。まずは「どこで、何が起きたか」を監視できるシステムを構築することで、障害の切り分けをしやすいシステムを目指していただけると幸いです。
