今回は，パフォーマンスチューニングについて考えてみます。

ハードウェアは進化しているのに，なぜパフォーマンスチューニングを続けるのか

インフラエンジニアは10年前に比べて，格段にパフォーマンスチューニングのスキルを要求されるようになっています。CPUが高速になりストレージも高速になり，メモリの単価も安くなっているにもかかわらず，です。これはひとえに，ネットの，というかWebのサービスの傾向によるものに他なりません。

いまやWebはネットのかなりの部分のトラフィックを締めており，そのWebがどんどん双方向化しています。ここでいう双方向化というのは，大多数のユーザも情報を発信するようになっている，ということとほぼ同義です。

インターネットは双方向（通信）というのはかなり以前から言われていますが，そうは言ってもたとえば2000年のころWebは双方向だったか？ というとそんなことはないと思います。Webはごくごく一部の企業や人が情報を発信し，それ以外の大多数が情報を受信するという特性の媒体でした。

それが，2chの登場で匿名ながらも情報発信が盛んになり，blogの登場でわずかながらも自分のコンテンツを持つ人が増えてきて，SNSの登場でネットにいわゆる「自分の場所」を持つことが普通のことになってきて，ECやニュースサイトがソーシャル機能を持つようになり，TwitterやFacebookのようなソーシャルメディアが活発に使われるようになって，急速に発信される情報が増えてきました。

特に，「⁠こまかい情報」がたくさん発信されるようになってきています。当然ながら，同じだけの量のデータの場合，細かくたくさん発信されるほうがシステムへの負荷は上がります。そして，こういったロングテールコンテンツは，WebのPVあたりの収益性を見ると相対的に低いケースが多い気がします。そうなると，限られたサーバリソースによっていかに負荷に耐えるか，ということが重要になってきます。

いずれにしても，これからのインフラエンジニアは（特にWebの）パフォーマンスチューニングのスキルによって，その評価がかなり変わってきます。良い面としては，以前は縁の下の力持ち的な位置付けだったインフラエンジニアが一躍脚光を浴びるポジションになってきたことです。やはり脚光を浴びるポジションであるほうが目指す人は多くなりますし，やりがいも増えるので，これは良いことだと思います。

パフォーマンスチューニングの基本

では筆者が思うところのパフォーマンスチューニングについて考えてみたいと思います。もちろん時代はどんどん進化しているので，古い部分もあるかもしれません。とはいえ時代を越えて共通な点もあると思います。

まずパフォーマンスチューニングの最大のポイントのひとつは，関係する要素を全て把握することです。例としてCPU，ディスク，メモリ，ネットワーク，外部サービスあたりがあげられます。他にもたとえばプロセスという切り口もありますが，これは実質CPUとメモリです。Webのパフォーマンスチューニングに限らず，パフォーマンスを要求されるケースに共通することは，ボトルネックを解消することです。

ボトルネックは，ある時点においてパフォーマンスの限界になっているポイントです。もちろんこれは刻々と変化します。ただ，いずれにしてもある時点でどこがボトルネックになっているかを知るには，関係する要素の全てを知っている必要があります。全てです。

1ヵ所でも知らないところがあってそこがボトルネックの場合，それ以外をどんなに手を入れてもあまり効果はありません（ゼロではないのですが⁠）⁠。理想をいえば，全ての要素がほぼ同じくらいボトルネックになっているのが一番性能を限界まで引き出している状態なのですが，まあそれは現実には不可能なため，だいたいはその時点での突出したボトルネックを解消して，それによって発生する別のボトルネックを解消，ということを繰返していきます。

ところで，たとえば上記であげた要素は，おおむね2つのグループに大別できます。それは「演算」と「I/O」です。インフラエンジニアがチューニングの対象にするボトルネックはたいがいがI/Oです。演算というのはすなわちCPUで，それはプログラムによるものです（⁠「⁠プログラムはCPU」ではないので注意が必要です⁠）⁠。

たとえば無駄にループが深いといった，いわゆるホットスポットといわれる部分に手を入れることで，パフォーマンスが格段に向上することも良くあることですが，ここでは「プログラムの修正は除いた」パフォーマンスチューニングについて考えてみます。

もちろん，「⁠いまのボトルネックはCPUのようだからこれはプログラムの修正を検討したほうが良いかもしれない」と思うことは立派なインフラエンジニアの仕事ですし，プログラムが読み書きできて実際の原因まで突きとめられればそれは最高です。また，最近のプログラムは加速度的に複雑になってきていて，プログラム的には手を入れきってあってもCPUが足りないことも多々あります。ただ，CPUに関していえばインフラエンジニアができることはあまりありません。できることは，CPU自体を増やす，CPUを速いものに交換する，1台あたりのCPUの数をバランスさせる，といったところです。

UNIXもしくはLinuxでの話になりますが（WindowsやMacOSもそうですが⁠）⁠，プログラムというのはユーザランド部分とシステムコール部分に分かれます。システムコールというのはプログラムだけでどうにもできないので処理をカーネルに委託する部分で，これはその大部分がI/Oの操作になります。つまり，上記の「演算（CPU⁠）⁠」と「I/O」という大別は，言い換えれば「ユーザランド」と「システムコール」という大別に置き換えることができます。

さて，たとえばシステム負荷を知る方法としてuptimeというコマンドがあります。uptimeによって1, 5, 15分の負荷の平均が表示されますが，ここで表示される値は何を意味しているのでしょうか? これはとりもなおさず，プロセスのrunnable queueの値です。つまり「プログラム的には実行できる状態になっているのに待機している」プロセスの数です。もちろん，ユーザランドプログラムすなわち演算能力待ちで待機しているプロセスもありますが，多くのケースではこれはI/Oによって引き起こされています。

I/Oにはディスクやネットワーク，メモリなどがありますが，メモリがボトルネックになることはまずありません（メモリが小さくてスラッシングが，というのはメモリI/O自体に話ではないですね⁠）⁠。つまりインフラエンジニアが取り組むパフォーマンスチューニングはディスクとネットワークが対象のことが多い，ということになります。さらにさらにいえば，ネットワークよりはディスクのほうがネックになるケースのほうが格段に多いです。ここにCPUも入れて考えてみると，ディスク，CPU，ネットワーク，メモリという順にボトルネックになりやすい気がします（もちろんケースバイケースです⁠）⁠。つまり，まず最初に習得するべきはディスクI/Oについてです。