サイジングとチューニングの必要性
Javaアプリケーションのサイジング、チューニングとは
サイジングとは、システムやWebサービスを提供するために想定されるシステムへの利用状況や負荷を見積もることです。一般的には、利用する同時ユーザー数、利用されるデータ量の平均量や最大時の量から見積もり、システムを利用するのに十分な性能を発揮するために必要なサーバーの構成、アプリケーションの構成、使用CPU数、使用メモリ量などを見積もる作業になります。
チューニングとはシステムのパフォーマンス性能が悪い箇所を改善するために、サーバーの設定の見直しや、アプリケーションのパフォーマンス測定を行い改善する作業のことです。一般的にチューニング作業はアプリケーションのプロトタイプ作成中から構築後にかけて行うものですが、サイジング要件やアプリケーション規模に合わせて事前にチューニング作業を見積もっておく必要があります。
本連載ではJavaアプリケーションのサイジングとチューニングの重要性について、具体的な障害例を通して紹介していきます。
Javaアプリケーションと言えば
エンタープライズJavaアプリケーションと言えば、Webアプリケーション用のフレームワークを用いて作成されることが多いと思われます。代表的なところではStruts、Seasor2、Spring framework、Click、Wicketなどがあります。フレームワークを用いる一番の目的として、フレームワークで提供される制御層の設計と実装が行われているため、実装を開始するまでに必要な作業が大幅に短縮される点が挙げられます。制御層の作業が軽減されることにより、アプリケーションの画面と業務ロジックの設計～実装～テストに注力することができます。
受けられるメリットは他にもあります。
- 外部ライブラリを柔軟に追加できるよう設計されている
- 書籍やインターネットにも情報が数多くあるため、実装するまでに必要な教育コストを減らすことができる
- 実装のコード量を減らす仕様が導入されているものも多く、可読性や保守性を向上させている
|
|
| 図1：フレームワーク利用のメリット（クリックで拡大） |
これらを総合すると、アプリケーション構築にかかる期間を短くすることが期待できますし、つまりコストを削減するために採用されるケースもあるでしょう。
このように、受けられるメリットが多く紹介されているフレームワークですが、短期間でアプリケーションを作成できるために本来検討するべき課題点であるサイジングが軽視されてしまうことがあります。
以下に、サイジングでの留意点と、チューニングでの留意点を一部取り上げます。
| 項目 | 概要 |
|---|---|
| レプリケーションの必要性 | 同時利用者が多い。利用者増加の予測が立たない。 |
| データI/O量の推測 | 月次処理などで、特定の処理にて一括で大量のデータが入出力されるため、一時的にI/OやCPU負荷、メモリ使用量が急上昇する。 |
| コンテンツ量 | アプリケーションで扱う動的コンテンツの数＝クラスの数になる。アプリケーション公開時に自動コンパイルするか否かの判断になり、メモリ使用量とのアンマッチを起こしやすい。 |
| モジュール依存のメモリ使用 | フレームワークやライブラリが使う一時的なメモリも事前に測定する。フォーマット変換やエンコード、テンプレート機能を持つモジュールはデフォルト設定の場合、メモリを一時的に大量消費するものが存在する。 |
| ユーザーからのアップロード | アップロードするファイルサイズが大きい場合や数が多い場合、それだけI/Oが多く発生するためシステムへの負荷が高い。 |
| 他システム連携 | 他システムとの連携をする場合、連携先システムの処理時間がそのままアプリケーションに影響する。 |
| セッションオブジェクト利用 | 実装を軽減するために利用されるセッション量とユーザー数、セッションの有効時間の概算を行ってセッションの設計とメモリの設定をする。疑似的なメモリリークとなり問題を見つけにくくなる。 |
| 一時データサイズ | アプリケーション内でのみ生成されるオブジェクトのサイズが大きくなるとメモリを切迫し、メモリ不足を引き起こす。一括で大量データを扱う際に発生させやすい。 |
| 表1：アプリケーションサイジング・チューニングでの留意点 | |
これらはアプリケーション規模が小さい時にでも検討する必要があります。なぜならこの課題点を考慮して事前に設計しなければ、アプリケーションが結合テスト中や本番データ投入後に動きが悪くなるケースがいくつもあるためです。
ではサイジングを行わなかった場合は、どのような障害が発生するのでしょうか。
よくある例としては、単体テスト時には気づかなかったオブジェクトの開放ミスや、セッションへの乱雑なオブジェクトの詰め込みなどにより、テスト時には発生せずに本番環境が稼働してから発生する不定期なメモリリークがあります。最悪な場合、アプリケーションがメモリ不足で止まってしまう事例も珍しくありません。
また、システムはWebアプリケーションだけではありません。当然データベースやバックオフィス処理も組み合わせて使われます。これらもサーバーのリソースを利用しますので、Webアプリケーションの都合だけでメモリやCPUを占有してしまうことは避けなければならないでしょう。無尽蔵にリソースを使うことができるシステム構成はまれですし、不必要なリソースの消費はシステム全体の遅延を招く引き金になり、さらには思わぬ障害や不具合を引き起こす原因になります。
