SEになる要件には機能要件と非機能要件の二つがあることを知るでしょう。今日は非機能要件について。
非機能要件というと何のことなのかわかりにくいですが、端的には「性能」＝「早さ」と考えれば大きくは外さないでしょう。もちろん実際はそれ以外の部分も含みますが…。
機能要件は発注する側からしてもわかりやすく、その機能が実現できなければシステムが完成したとは言えないので見落とされることは相対的に少なくなります。一方で、非機能要件は実際に動かしてみないとわからなかったり、ユーザも使ってはじめて気づく部分も多いので想定外の問題として顕在化することもよく見かける部分です。
非機能要件でおそらく一番問題になるのが「システムが遅い」という問題でしょう。サービスインしてみたらユーザからレスポンスが悪いと苦情をうけるという例は世の中に溢れていますし、処理量の増加とともに遅くなるということもよくあります。この性能問題を解決するには、システムアーキテクチャに対する理解が必要です。実際にシステムがどのように動いているのかを知らないと適切な解決策がとれないのです。
実際に存在した例をあげます。javaで作ったシステムが遅くCPUが100％で張り付いており、メモリはまだ余っているという状況でどのような対策を打つでしょうか。CPUの処理能力が足りないからCPU性能を上げればいいとだけ考えるのは安直です。javaでは、ヒープ領域というメモリ領域が存在します。また、不要になったメモリを回収するGCという機構があります。そしてGCにはFull GCという非常にCPUパワーを使うGCがあります。ヒープ領域がいっぱいになるとFull GCが行われ処理は当然重くなります。上記の例のCPU100％の原因は、Full GCによるCPUパワーの消費でした。CPU100％という現象は実は表面的なもので、真の原因はヒープ領域の不足というメモリ不足の問題だったのです。この例では、ヒープ領域を増やすことでFull GCの頻度を抑え性能を改善することが出来ました。
性能が出ていないときにデータ（パフォーマンスチャート）に注目することは非常に重要です。しかし、データから表面的に読み取れることが真の原因とは限らないのです。システムがどういう動きをするとそのようなデータになるのか、それを探れるだけの知識が必要です。上記の例はjavaのエンジニアには当たり前の話かもしれませんが、それでも知らなければ適切には解決できません。これも一つの技術力でしょう。
今回はサービスイン後に起きた性能問題を取り上げましが、そもそも性能問題を発生させないために必要だと思うことを次回に紹介します。