システム運用のキャパシティ管理の説明です。
キャパシティ管理は、リソースの使用状況やパフォーマンスデータを定常的に監視し、リソース不足やパフォーマンス悪化の兆候を事前に捉え、問題が顕在化する前に対応をするプロセスです。
１．インフラやOSレイヤーでのキャパシティ管理
最低限、ネットワーク帯域やCPU、メモリー、DISK使用率などの定期的な監視が必要です。
これらが増加傾向にある場合、同じ傾向が続くと仮定したときにどれくらいでリソースが枯渇するかを予測し、増加を抑える対策がない場合には、リソース増強の計画を立てていきます。
またCPU待ち行列やページフォールト等は、定期的な監視まではする必要はないですが、レスポンス悪化等があった場合、原因調査ができるように情報取得はしておいた方が良いです。
２．ミドルウェアやアプリケーションレイヤーでのキャパシティ管理
実際のところ、CPUやメモリー、DISKの監視では手遅れになることが多いです。
これらの数字に影響が出る前に、ミドルウェアレイヤーやアプリケーションレイヤーの監視で問題を早期に潰していくことが重要です。
例えばメモリーです。JAVAのシステムではAPサーバーのプロセスがメモリーを確保して、プロセス内のスレッドで確保したメモリーを使う仕組みとなっています。
プロセスが確保するメモリーを増やす場合、オーバーヘッドが発生してレスポンスに影響が出るため、通常は搭載しているメモリーで使用できる最大値を初めから確保します。
例えば搭載しているメモリーが100GBで、APサーバーで60%まで使用してよい設計とした場合、APサーバーを起動した時点で60GBのメモリーを確保してしまうようにします。
実際のところは、APサーバーは60GB確保していても、OSが30GBしか割り当てていないような状態になったりしますが。
いずれにしても、本当のメモリー使用率を知るためには、APサーバー内のメモリー（ヒープ）使用率を確認する必要があります。60GBをフルで使っているのか、半分しか使っていないのか等は、APサーバーのGCログ等で確認することになります。
またミドルウェアには、リソースを利用する上限値を設定することができます。
例えばApacheのMaxClientsやTomcatのmaxThreadsなどの同時接続数の上限値です。
この上限に達してしまうと、CPUやメモリーに余裕があってもWebの応答は待たされることになり、レスポンス悪化の原因になります。
そのためミドルウェアの上限値を設定しているリソースも監視の対象となります。
アプリケーションの管理も重要です。
Webの応答時間は数値を取ることが難しいことが多いですが、最低限、バッチの処理時間は監視が必要でしょう。
３．大量にある項目で何を監視すれば良いか？
これらの項目を全て監視すると、それだけで物凄いコストが発生します。
毎月毎月、変化のない数値を見るのもモチベーションが下がりますし、大量にある情報の中で、重要な変化を見落とす可能性もあります。
CPUに負荷がかかりやすいシステム、JAVAヒープを大量に使用するシステム、DBの更新が激しいシステムなど、監視対象のシステムのリソース使用の特徴を掴み、リスクの低い項目は後から調査ができるように情報取得だけにして、定期的に監視をする項目を減らしていくことが重要です。
【振り返り】
キャパシティ管理の説明は以上で終了となります。次回は可用性管理の説明をしていきたいと思います。
①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理
