サービスを初めてから高負荷になるまで

さて、今回からは具体的に、個人でサービスを初めてからシステムを増強していくまでの課程を説明していきたいと思います。

まずサービスを始める際は、手っ取り早さやコストの問題などから、複数のユーザと共有のレンタルサーバから始めるケースが多いですが、ある程度の人気が出てくるとアクセスに耐えきれなくなり専用サーバを借りるというパターンになると思います。

ここまではわかりやすくシステムを増強することができるのですが、専用サーバで耐えきれなくなってきた際はそれ以降はどのようにすればよいのでしょうか？

その負荷はホンモノか？

まず、サーバの負荷が高いといっても現象はさまざまです。負荷が高いといった現象は具体的に発見されるのは、「⁠ユーザから見たレスポンス」から発見されることが多いはずです。

ここで単純に「サーバを増強しなければ！」と判断はせずに、何が原因でパフォーマンスが低下しているのかを調査する必要があります。大きく分けて、パフォーマンスの低下には下記３パターンがあります。

1. 同一のIPアドレスから常にアクセスがきているパターン
2. 一定周期で集中アクセスがくるパターン
3. とくにアクセスの偏りはなく、全体的にアクセスが増えているパターン

まずはこのパターンのうちのどれに当てはまるかを正確に判断する必要があります。1もしくは2の場合であれば、攻撃を疑ってみるのも良いでしょう。サービスの用件次第にもなりますが、特定のユーザからの攻撃に対してそのユーザをブロックしてしまうという手段があります。

Apacheのmod_accessやmod_evasiveで対応するか、もしくはiptablesで対象のIPアドレスをブロックしてしまう方法が有効です。

しかしながら、それでもレスポンスが改善しない場合は、最初から3のパターンだった場合は何らかの方法で負荷対策をする必要があります。

まずは何がどのように負荷になっているのかを調査しましょう。

ボトルネックを発見する

それでは、ボトルネックの調査に入りたいと思います。ボトルネックを調べるにはとある時点の静止点の情報はあまり活用できる情報ではなく、継続的に取得した情報が手がかりとなります。

まず、ボトルネックになりやすいCPUとMemoryの推移を取得するためにsar（System Admin Reporter）を取得します。各OSに合わせて、以下の手順でシステム情報取得ツールのsysstatをインストールしてください。

$ sudo yum install sysstat

$ sudo apt-get install sysstat

上記のコマンドでインストールを完了したら、/etc/cron.dに自動的に設定されています。これで、定期的なステータスを取得してくれるcronが仕込まれ後々そのデータを参照することができます。

時間帯や曜日ごとのトレンドを把握する必要があるので、すくなくとも1日、できれば1週間はそのまま取得し続けてください。

それではある程度の期間をおいたら、sarの結果を見てみましょう。

以下のコマンドを使用して現在までのステータスを取得します。なお、sarコマンドのオプションは下表のとおりです．

-u	CPU使用状況
-b	ディスクI/Oの使用状況
-r	メモリとスワップの使用状況

$ sar 
19時45分17秒       CPU     %user     %nice   %system   %iowait    %steal     %idle
19時50分01秒       all     82.02      0.00      0.19      0.08      0.00     17.71
平均値:            　　all     82.02      0.00      0.19      0.08      0.00     17.71

さて、上記のsarの結果の見方と照らし合わせてみると、このサーバはuserがCPUを使い尽くしていることがわかります。つまり、CPUがボトルネックとなっている可能性があります。

それではメモリ領域を見てみましょう。Memoryの状況を確認するためには、-r オプションを使用します。

$ sar -r
19時45分17秒 kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
19時50分01秒    287080    228444     44.31     16652    155540   1048568         0      0.00         0
平均値:         　　286718    228806     44.38     16790    155836   1048568         0      0.00         0

このように、とある時間帯だけでなくある程度の時間帯で取得したデータから導き出せる数値の方が正確なパターンが多いです。

また、sarコマンドでは数値でしかだすことができませんがMRTGなどを利用して、グラフ化してしまっても良いでしょう。

• MRTG日本語公式サイト
  http://www.mrtg.jp/doc/

犯人を捜せ

sarコマンドを使って、ボトルネックを見つけることはできました．ではその分のリソースを食いつぶしてしまっている犯人は誰なのでしょう？

リソースを食いつぶしているProcessのと突き止めてやれば良いのです。Webのサービスなので、ある程度犯人は特定できますね。

次の4つのどれかが原因の可能性が高いと思われます。

1. Web Server（Apache etc...）
2. Application （⁠mod_perl、Tomcat etc...）
3. Database（MySQL , PostgresSQL etc...）
4. cron（batch処理など）

どのプロセスが犯人なのかは以下の方法で見つけることができます。psの結果をcpu/memoryでそれぞれソートして、最高の値5件を取得しています。

$ ps aux | sort -nr -k2 | head -5  # cpuの取得
$ ps aux | sort -nr -k3 | head -5  # memoryの取得

このコマンドをcronに仕掛けておいて、sarの結果と突き合わせれば本当にボトルネックになっているプロセスを調べましょう。

現状分析をした後、最適な増強の方法を検討する

それでは、ボトルネックを見つけた後はそれに対応するシステムの増強の方法を検討しましょう。単純にシステムの増強といっても、スケールアウト型・スケールアップ型の方法がありますのでその状況に最適な増強をする必要があります。どの増強方法が最適化という点に関しては、現状使用しているマシンスペックにもよるので、それにそった対応をしていきましょう。

たとえば、CPUがボトルネックになっている際、現状使用しているCPUはどの程度のものでしょうか？数世代遅れのCPUを使用している場合は、マシン毎変えてしまいスケールアップしてしまう手が手っ取り早いです。また、Memoryがボトルネックになっているとしても、Memoryが1Gバイトしかないのであれば4Gバイトに増やすといった増強方法も良いと思います。

「業界標準」スペックに対して、圧倒的に劣るマシンで高い負荷がきている際はスケールアップをする方がコスト的に有利なケースが多いです。

それでもスケールアウトが必要に

しかしながら、すでに業界標準クラスのマシンを使っていて負荷に耐えられないケースの場合はどうすべきでしょうか。手段としてはさらにハイスペックのマシンを使用するというケースもありますが、ここではじめてスケールアウトを検討する必要があります。

次回以降はそれぞれのサーバーに合わせた、増強方法の詳細やスケールアウトに方法について説明をしていきたいと思います。