清く正しいキャパシティプランニング
製品の導入を勧めている中で必ず聞かれるのが、「リソースはどのくらい必要ですか」。キャパシティプランニングなんて言ったりしますが、これ、エンタープライズアプリケーションの中ではかなり重要で、炎上も頻発しやすいテーマです。今日はそんなお話。
タイミングはいつなの？
いわゆるパッケージソフトウェアだと、必要なCPUのスペック、メモリのスペック、ディスクのスペックは大体書かれています。それは機能が固定されていて、変動するところはデータ部分のみになるので、xxGB以上のメモリ、YYGB以上の空き容量 等と、最低限の条件が書けます。ハードウェアを調達するには、使うパッケージに合わせるのが普通かと思います。
ところがです。エンタープライズアプリケーションという分野では、スクラッチで開発するので、どのような機能が付き、どのような画面があり、どのようなデータが来て、どれくらいの処理能力が必要なのか は、見積もりことが困難です。
「いやいや、あなたのところは他社でも経験してきているんでしょ？だいたい分かるでしょ？」
本当に良く聞かれます。でも、他社のデータとこの会社のデータは違うのです。処理させる内容も違うのです。参考値として出しても、コミットなんてできるわけがありません。
予算取りで必要、というのは理解しますが、99%、その値がコミット値として取り扱われてしまいます。その結果、設計もされていないアプリケーションの動作環境だけが先に決まり、CPU/Memory/Disk容量の制約が生まれてしまいます。アプリケーションの作る側としては、それが聖域になってしまい、処理能力を稼ぐためのチューニング、メモリ容量を節約するためのチューニングなどを徹夜で行い続けることになります。
パッケージソフトを動かす感覚でハードウェアを調達しているとしか思えません。キャパシティプランニングは、設計前に机上で行うものではないのです。
本来どうあるべき？
エンタープライズアプリケーションのキャパシティプランニングは、設計して、ある程度の規模のプロトタイプ（例外条件の無いような状態で、想定している簡単なデータが来れば業務として成り立つようなもの）を作成し、本番相当のデータを流した上で測定して決定すべきと考えています。
まず注目すべきは、1件あたりの処理時間 (Turn Around Time, TAT）。これが想定より大幅に掛かっているのであれば、プログラムの中のそれぞれの処理がどれだけ掛かっているか、ブレークダウンして確認します。処理時間が一番掛かっている部分から処理方式の見直しを行っていきます。
次に使用メモリ容量を確認します。10,000件くらい流してみて、どのくらいのメモリ使用量の増減があるかを確認します。Cの環境とかであれば、メモリリークしているかどうか、Javaの環境であれば、HeapとGCのタイミングを見てGCが頻発しないよう、Heapのメモリ容量の調整や、場合によっては一部は別のVMに処理を移す等の検討を行います。
さらにスループットを検討します。単体でのスループットを計測し、目標のスループットに達する為に多重度をいくつにすべきか を検討します。データの入り口が一つ（QueueとかWebServerとか）の場合、後続の処理を行うモジュールを2倍に増やしても、シングルスレッドで動作するところがボトルネックとなるため、1.7倍程度のパフォーマンスしか得られませんので注意が必要です。
いつ評価するの？
これらの「性能検証」は、設計段階でやっておくべきです。
「え？だってさっき、ハードウェアの見積は最初にする必要がないみたいなこと言ってたじゃない！」
違うんです。こういう時こそ、時間貸しのクラウド環境を上手く使って検証すればよいのです！そして、このような性能問題は本開発前に確認しておくことで、開発が進むに連れて、もし性能が未達となった場合でも、どこを多重化・チューニングすれば回避できるかの判断が容易になります。
これを、実装後のテスト段階でやってみてください。炎上と悲劇しか生まれません。設計から見直す必要があるものの、「今更何イッテンだ！とにかく直せ！納期は守れ！」みたいな奴隷への号令よろしく、「テストフェーズからが本開発！」なんていう自虐的な武勇伝が生まれ、炎上・徹夜を繰り返し、体も心もズタボロになってしまうのです。倒れて救急車に運ばれるならまだまし、倒れても救急車に乗れないなんていう最悪中の最悪な結果なんて誰も望んでいません。楽しく仕事が出来ないなら、今すぐ辞めるべきです！
設計段階において、ある程度の性能をクリアするための基礎情報が取れれば、そこで初めて環境のリソーススペックが決められます。そしてよほどのことがない限り、自前でハードウェアを調達する時代ではなくなっています。何のためのVirtual Machine、何のためのContainer でしょうか？区画を一度作ったら二度と変えない方針のVM設計なんて、仮想化の意味がないです。必要な時に必要な分だけリソースを利用できるメリットをもっと享受すべきです！
リソースの決定
パッケージソフトもスクラッチで開発するアプリケーションも、リソースの決定方法は同じです。アプリケーションがどれだけ使用するのかをプロトタイプなどを利用して目処をつけて、稼働環境や開発環境としてどれだけのリソースが必要なのかを計算し、それをクラウド上に作るべきです。
そのためには、取るべきアーキテクチャを策定し、使う製品の特性をその道のプロ（ベンダーのコンサルタント等）から学び、基礎固めを行わないといけません。ちなみに、ITに従事している皆さんはめちゃめちゃ頭の良い方が多いので、「こんなことにも使えるんじゃないか」と、色々やっていただくケースが多いのですが、「その目的に使われるような製品の機能なのか」どうか、今一度確認することをお勧めします。製品として想定していた以外の使い方をして上手く動かなかった場合、我々製品提供側もどうすることも出来ないケースが多々ありますので... 疑問点があれば、製品サポートにお尋ねいただくのが良いです。
話はちょっと逸れましたが、プロジェクトの予算承認という課題の時
にも触れましたが、全体を一気にプロジェクト化・予算化するのではなく、マイルストーン毎に区切って一つ一つ進めるのがよいのです。キャパシティプランニングを行うための、「そう大きくない予算」を是非置いておくことをお勧めします。
相談先
レッドハットではプロジェクト全般の進め方について、皆様のプロジェクトマネージャと同じ視点で支援する「テクニカルアドバイザー」的なコンサルティングも行っています。レッドハットのコンサルタントは、広く深く技術的な観点で。ITシステムとしてあるべき形を常に追求してお客様にご提供していますので、一度ご相談いただければと思います。
