Linuxコマンドを用いたボトルネック調査 – 「クラウド時代だから必要なITインフラ基礎知識」(3)

こんにちは、さくらインターネットの大喜多です。

前2回の記事にて、クラウドインフラにおいて物理インフラを意識することなく利用できる仕組みについて説明してきました。コントロールパネルによる操作・APIによる自動化など、構築に関しては意識することは少なくなりました。

しかし、実際にシステムを運用していくと、OSから必要な値を取得してのボトルネック調査など、あくまで「物理インフラの上に仮想インフラがある」ことを意識せざるを得ない場面が多々出てきます。

本記事では、Linuxのコマンドを用いて仮想サーバのボトルネック調査を行う手順について解説致します。

第1回	クラウドインフラのしくみ
第2回	クラウドを支える仮想化
第3回	Linuxコマンドを用いたボトルネック調査
第4回	インターネットを支える技術
第5回	ITインフラ監視入門～Zabbixインストール編～
第6回	ITインフラ監視入門～Zabbix活用編～
第7回	いまどきのインフラ設計のキモ
第8回	Design for FailureなWebシステムの構築

CPUの負荷を把握する
ストレージの負荷を把握する
ネットワークの流量を把握する
さくらのクラウドで取り得る対策
「さくらのクラウド」ならではのデザインパターン

CPUの負荷を把握する

「アプリケーションのレスポンスが期待通りでない」「サーバの動作が重い」等の現象を感じたら、まずはじめにtopコマンドでCPU負荷の高いプロセスを調べてみましょう。

[root@test ~]# top
top - 18:04:25 up 19 days, 22:51,  1 user,  load average: 0.05, 0.02, 0.00
Tasks: 121 total,   1 running, 120 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.0%us,  1.0%sy,  0.0%ni, 93.6%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1020212k total,   830908k used,   189304k free,    32768k buffers
Swap:  4194300k total,   270960k used,  3923340k free,   360256k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1391 mysql     20   0 1321m 304m 4884 S  0.3 30.6  75:05.25 mysqld
 1587 zabbix    20   0  177m  14m  12m S  0.3  1.5  28:43.99 zabbix_server
    1 root      20   0 19232 1020  820 S  0.0  0.1   0:08.64 init

左から8番目（SHRの右）の「S」のフィールド(プロセス状態)を確認します。
上記の例は全てS（スリープ）状態となっています。
S以外にも下記の通りR、Dという状態があります。

プロセス状態	意味
R	実行(可能)状態：CPUリソースを消費している 9番目のフィールド(CPU使用率)を確認し、継続的に使用率が高い場合、CPUがボトルネックになっている可能性がある
D	ストレージのIO完了待ちが多発しているストレージがボトルネックになっている可能性がある
S	スリープ状態またはネットワークを介したデータ送受信等のイベント待ち CPUには余裕があるが通信が遅くなっている場合、ネットワークがボトルネックになっている可能性がある

CPU、もしくはストレージがボトルネックになっている場合、vmstatコマンドを用いて切り分けを行います。

[root@test ~]# vmstat 1 
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 271328 110320  59792 392132    0    0     1   165    0    5  1  0 88 11  0
 0  0 271328 110304  59792 392132    0    0     0    16  101  175  1  0 99  0  0
 0  0 271328 110304  59792 392132    0    0     0   436  154  276  0  0 98  2  0

右から3番目のフィールド(id)がCPUの空き具合(%)を、右から2番目のフィールド(wa)がストレージのIO完了待ちの割合(%)を示しています。このケースではCPUの使用率は高くありませんが、若干IO完了待ちが発生しているタイミングがあるようです。

vmstatコマンドでは、マルチコアCPUのサーバの場合、全コアの利用率を平均した値が表示されます。mpstatコマンドを使用することで、コアごとの使用率（%usr）が確認できます。マルチコアCPUのサーバでありながら特定のコアに負荷が集中している場合、アプリケーションやミドルウェアの見直しが必要になります。またコア全般的に使用率が高い場合、CPUコア数を増やすことで改善できる可能性があります。

下記例はCPU4コアの場合。
一番右の%idleがCPUの空き率となります。
%usrがCPUの使用率となりますが、%iowait（io処理待ち）によって使用率が上がっています。
下記例では各CPUの使用率は「0」となっていますが、実際にCPUで計算が行われるタイミングでは、この部分の数値が上がります。

[root@test ~]# mpstat -P ALL 1
12:23:45     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:23:46     all    0.00    0.00    0.00    7.02    0.00    0.00    0.00    0.00   92.98
12:23:46       0    0.00    0.00    0.00   28.00    0.00    0.00    0.00    0.00   72.00
12:23:46       1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
12:23:46       2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
12:23:46       3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

freeコマンドを使用することで、現在のメモリの使用率（used）を把握することができます。以下の例では「-m」オプションを付けてMB単位で表示させています。

 
[root@test ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           996        888        107         10         58        383
-/+ buffers/cache:        447        549
Swap:         4095        264       3831

1GBのメモリに対して空きメモリ（free）は107MBですから、メモリの使用率は高い状態にあるといえます。ストレージのキャッシュに使用されている空間(buffersおよびcached)の両方を差し引くと、プロセスに割り当てられている実際の消費メモリがわかります。また、併せてSwap:行の値を確認しましょう。Swapの利用量が高くなる原因として、「休眠プロセスのページが実メモリからSwapに追い出される」場合と「実稼働プロセスの利用領域として使用されている」場合がありますが、後者の場合システムのパフォーマンス劣化につながりますので、注意が必要です。

ストレージの負荷を把握する

ストレージのアクセス状況を把握するにはiostatコマンドを用います。以下のように実行すると、1秒間隔でブロックデバイス毎の負荷状況が表示されます。

[root@test ~]# iostat -dmxt 1 
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
vda               0.02    32.17    0.09    9.71     0.00     0.16    34.03     0.02    2.51   0.88   0.86

r/sは秒間あたりの読み込み、w/sは秒間あたりの書き込みIO数(IOPS)を示しています。

ネットワークの流量を把握する

ネットワークの流量をリアルタイム把握するにはvnstatコマンドを用います。(インストールされていない場合はyumコマンドでインストールします)

rxが受信のネットワーク流量で、txが送信のネットワーク流量です。

[root@test ~]# vnstat -i eth0 -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        8 kbit/s    13 p/s          tx:        8 kbit/s    11 p/s

さくらのクラウドで取り得る対策

システムのボトルネックが生じている場合、さくらのクラウドであれば以下の対策が可能です。

CPU負荷が高い場合

マルチコアを生かせるアプリケーションにおいて各コアの負荷が満遍なく高い場合、コア数を増やすことで改善できる可能性があります。さくらのクラウドではサーバ作成後もコア数の変更ができます。また、アプリケーションの特性上マルチコアを生かせない場合は、ロードバランサを用いて複数のサーバに負荷分散することで改善できる可能性があります。

メモリの使用率が高い場合

メモリを増やすことで改善できる可能性があります。さくらのクラウドではサーバ作成後もメモリ容量の変更ができます。

ストレージアクセスの負荷が高い場合

さくらのクラウドの仮想ディスクには「標準プラン」と「SSDプラン」があります。「SSDプラン」の方がより高速なストレージになっていますので、標準プランを利用されている場合はSSDプランに変更することで改善できる可能性があります。また、容量毎にIOPSが異なりますので、よくある質問(技術的な事項)のディスクへのIOPS(1秒あたりのI/O数)やデータ転送帯域などの制限はありますか?をご確認ください。
また、さくらのクラウドはブリッジ接続を使用することでさくらの専用サーバと接続することができます。データベースのように高IOPSが求められるアプリケーションは専用サーバを利用するということも可能です。

ネットワークの流量が多い場合

インターネット向けのネットワーク流量が多くシステムのパフォーマンスに影響が出ている場合、共用セグメントからルータ＋スイッチへの接続変更、ルータ＋スイッチの帯域変更で改善できる可能性があります。

「さくらのクラウド」ならではのデザインパターン

マルチサーバ構成で可用性向上

クラウドの特性を考慮して可用性の向上を図りたい場合、可用性を高めるために複数台の仮想サーバを並べ、ロードバランサでトラフィック分散を行うことが推奨されます。また、仮想サーバAと仮想サーバBを別のホストサーバ上で稼働させ、仮想ディスクAと仮想ディスクBを別のストレージに収容することで、ホストサーバ・ストレージ障害におけるリスクを低減できます。

通常、ホストサーバに障害が発生した場合は別のホストサーバにて仮想サーバを起動する動作(VMwareでいうところのvMotionに相当)が起こりますが、仮想サーバを明示的に別のホストサーバに収容しておくことで、全ての仮想サーバが障害となる可能性を回避することが利点です。

一方で、ホストサーバおよびストレージの分散は可用性向上のための機能であり、負荷分散のための機能ではありませんので、クラウドはあくまでも共用インフラであることを意識して、スケールアウト型のアーキテクチャ設計を行うとよいでしょう。

専有ホストで安定したパフォーマンスを得よう

さくらのクラウドの「専有ホスト」機能は、クラウドを構成するホストサーバ（物理）を1ユーザにて専有することができる機能です。サーバを専有することで、他のユーザと仮想マシンが同居することがなくなるため、外部要因によるパフォーマンスへの影響を避けることができます。また、自社の仮想サーバの中でも負荷の高いサーバを別々の専有サーバに割り当てることで、お互いのパフォーマンスをスポイルすることなく処理を行うことができます。

このように「さくらのクラウド」には、さくらインターネットがこれまで培ってきた物理インフラのノウハウが反映されています。是非ご活用下さい。