JENNIFER

アシスト技術者が見た　Webシステムの運用／開発現場の実態

多くの企業が基幹システムなど業務遂行に必要不可欠なシステムをC/SからWebへと移行しています。Webシステムは、Webサーバ／アプリケーションサーバ／データベースサーバの3層構成が多く、問題が起きたときの切り分けが非常に煩雑です。そのため、なかなか問題を解決できず業務遂行に重大な影響を及ぼすことがあります。特にECサイトなどはアプリケーション遅延によって多大な機会損失を招く可能性もあります。本稿では、JENNIFERの技術担当者がお客様先で伺ったアプリケーション運用／開発における課題と解決策を5回に渡ってご紹介します。

アシスト技術者：塩澤正寛
2005年、株式会社アシスト入社。
運用監視ツール担当歴4年、現在ではアプリケーション性能監視ツールJENNIFERのご紹介、サポート、技術支援を担当。週のほとんどはお客様先へ訪問し、課題解決から製品設計まで、幅広くこなしている。

週末は子どもを連れてキャンプに行くなど、子煩悩な一面を見せる。

ケーススタディ　Vol.3

頻発するシステムのレスポンス遅延。全社展開にあたり、原因特定／品質向上が急務に

■基本情報
業態：通信
システム：社内システム(全社統合スケジューラシステム)
利用ユーザ数：約80,000人
同時接続数：約8,000人

■ご担当者の悩み
支社毎で構築/運用していたスケジューラシステムを全社で統一するプロジェクトが始動。採用されたスケジューラシステムはグループ会社内でも実績のあるパッケージでしたが、過去には度々レスポンス遅延が発生しており、その都度、再起動で復旧させていたそうです。今回、全社基盤として展開するにあたり、今まで同様再起動で復旧するわけにもいかず、システムの性能劣化時の影響も大きくなるため、大規模利用でも性能品質に問題がない状態でリリースするために何をすべきかと悩まれていました。

問題点は、システム改善に有効な情報を開発ベンダと共有できないこと

度々起こるレスポンス遅延について、過去にもシステムの開発ベンダに改善要望は出していたそうですが、社内にはアプリケーションの内部動作にまで精通した技術者がおらず、エスカレーションに必要な情報をベンダに提供できていませんでした。その結果、具体的な改善はされないまま運用が続いていたそうです。今回、システムの全社展開にあたり、負荷テストサービスを利用した第3者による品質検証の実施が決定していましたが、併せて性能劣化の原因を特定するための手段を弊社にご相談いただき、アプリケーション性能管理（APM）ツールJENNIFERをご紹介しました。

＜解決方法＞直感的に分かりやすいようシステムの性能を可視化し、開発ベンダと情報共有

性能劣化の原因を容易に特定するには、アプリケーション性能管理(APM)ツールでアプリケーション内部の情報を可視化し、モニタリングすることが有効です。そこで、結合テストからJENNIFERを導入、低負荷(単体ユーザで実行した)時のアプリケーションやSQLの応答時間をモニタリングし、性能品質基準を定めました。可視化されたアプリケーションの性能情報から、定めた基準に満たないアプリケーションを特定できたので、改修はスムーズに行われ、システムの品質が向上しました。さらに、負荷テストツールHP LoadRunnerで高負荷をかけ、システム利用ピーク時の性能もモニタリングしました。すると、高負荷時にもレスポンスが遅延することが判明したため再度改修を依頼し、同時にハードウェア／ミドルウェアのパラメータのチューニングを行いました。十分な負荷テストの実施と、性能情報の可視化／共有、システム改修により、全社展開しても性能品質に問題がない状態でシステムをリリースすることができました。

アシスト技術者が実際に行った、原因特定までの4ステップ

STEP1：客観的なデータを基にシステムの性能品質基準を定める

JENNIFERで全てのトランザクションの性能を可視化し、レスポンスの遅速を把握します。客観的なデータを基に、担保されるべきレスポンスとして平均値3秒という性能品質基準が定められました。

STEP2：基準に満たないアプリケーションを把握し改修を依頼

STEP1で定めた性能品質基準に満たないアプリケーションとSQLの一覧をJENNIFERで取得します。それらを日時でレポート化して、性能劣化時の情報などを開発ベンダと共有し、改修を依頼しました。また、デバッグ過程で見過ごされ、ユーザ操作で表面化しない例外処理（Exception）も統計情報から検知し、併せて改修を依頼しました。提供した情報を基に、SQLチューニングやデータベーステーブルへのインデックス追加が行われ、レスポンスは大幅に改善しました。

STEP3:システム利用のピーク時に備え負荷テストを実施、性能をモニタリング

システムを利用するユーザが集中しても性能品質基準を満たせるよう、既存システムのアクセス推移や利用状況を分析し、実運用に近いシナリオで新システムの負荷テストを実施します。すると、高負荷時にJavaのスレッドが滞留することが判明。そこで、JENNIFERで自動的に取得されるダンプ情報(スタックトレース、リソース情報)を基に、再び開発ベンダへ調査を依頼し、改修が進められました。

STEP4：ハードウェア／ミドルウェアのパラメータを調整し、予定通り本番リリース

さらに、Apacheをはじめとしたミドルウェアのパラメータ値を調整しながら、複数回のテストシナリオを重ねることで、高負荷時でも性能品質基準を満たすことができました。

＜変更したパラメータ一覧＞

ミドルウェア	パラメータ	パラメータ詳細	変更値
Apache	Maxclient	WWWサーバへの同時接続数（プロセス数）	300→800
Apache	Xmx	最大ヒープサイズ	1024→4096
Tomcat	maxProcessors	Javaの同時処理スレッド数の設定	300→900
その他	データベース	特定のテーブルへのインデックス追加	－
その他	ウイルス対策ソフト	リアルタイムスキャン	無効化

性能を可視化することで、原因特定と改修のための情報提供がスムーズに

JENNIFERを導入したことで、アプリケーションの内部動作に精通していない技術者でも、レスポンスの遅いアプリケーション／SQLの特定が容易になりました。これまでは、問題箇所の切り分けができず、その場しのぎで対応していたシステムの性能劣化も、性能を可視化することで、具体的に開発ベンダに改善要望を出すことができました。最終的に、当初のスケジュール通り本番リリースとなり、運用開始後も大きな問題は起きていません。

＜効果＞開発時の効率的な負荷テストと性能可視化で、安定稼働と品質向上を両立

APMツールJENNIFERを開発フェーズで活用することで、システムの性能品質基準が設けられ、機能毎の品質が統一されました。また、HP LoadRunnerを使った負荷テストサービスを利用し、通常時／ピーク時どちらも想定したユーザオペレーションをテストしたことで、スレッドの滞留など低負荷では発生しない問題を事前に把握／改善した上でリリースすることができました。今回のプロジェクトは、システム品質向上の成功事例となり、お客様社内では性能テストやツール活用のための勉強会が定期的に開催されているそうです。2011年の導入から今に至るまで継続的にHP LoadRunnerとJENNIFERを利用していただき、システムの安定稼働と品質向上を実現されています。