Premium Storage を使ってみよう ~アプリが使っている IO を測定してみる~

Facebooktwittermail

Web サーバーを構築したいんですけど、IOPS っていくつに設定すればいいですか?

Premium Storage の話、第三弾です。一回目は概要の話、二回目は IOPS とスループットの話、今回はアプリと IO に関する話です。

見出しに書いた質問、Web サーバーに関わらず、「SQL Server を使いたいんだけど IOPS はいくつ?」とか、「スマホゲームのバックエンドに Azure を使うと IOPS は?」など、いろいろなケースで聞かれるのですが、いつも正確な回答ができずにいます。理由は、二回目の記事に書いたバケツリレーにあります。詳細は二回目の記事を読んでいただきたいのですが、OS の中では、IO は 下の図のようにバケツリレーで渡されます。

irp20150617

このバケツリレーで使われるバケツの数が分からないと、ディスクに必要な IOPS の見積もりができません。バケツを最初に渡すのはアプリケーションです。なので、IOPS をいくつに設定するのかは、アプリケーションがどれだけのバケツをファイル システムに渡すのか、つまりどれほどの IO をアプリが発生させるのかに依存します。そう考えると、「Web サーバーの場合は、ざっくり 2,000 IOPS くらい用意しとけば良いですよ」のような回答は、Web アプリの構成やアクセス数などを無視した適当な回答ということになってしまいます。

アプリが発生させる IO の数を測るには?

「じゃあアプリがどれほどの IO を発生させてるの?」という話になりますが、Windows に標準搭載されている Performance Monitor を使うと、アプリが発生させる IO の数を調べることができます。Performance Monitor とはその名の通り、OS のパフォーマンスを測定するためのツールで、CPU/メモリ/ディスク/ネットワークなどの基本的な要素はもちろん、Active Directory のようなサービスのパフォーマンスや Performance Monitor に対応しているマイクロソフト製以外の製品のパフォーマンス データの収集も可能です。Windows 環境のパフォーマンス測定をする際、Performance Monitor は必須アイテムです。

アプリが発生させる IO の数を測定する際、Performance Monitor で監視するカウンターは以下の 3 つです。

  • Process\IO Data Operations/sec
  • Process\IO Read Operations/sec
  • Process\IO Write Operations/sec

 

この 3 つですが、IO Read Operations/sec は読み込み処理に使っている IO の数、IO Write Operations/sec は書き込み処理に使っている IO の数、IO Data Operations/sec は Read と Write の合計値になります。

Iometer で実験してみよう

というわけで、早速前回までと同じように Iometer を使って、4 KB 75% Read (25% Write) / 0% Random の負荷を Premium Storage のディスクにかけます。この状態で Iometer が発生させている IO の数を測定してみます。Performance Monitor で上に書いた 3 つのカウンターを監視すると、以下のようなグラフが表示されます。

perfl20150617

Iometer で Read 75%/Write 25% と設定して、Premium Storage の最大 IOPS である 5,000 IOPS が出るように負荷をかけてみました。Iometer で設定した Read 75%/Write 25% という負荷の割り振りが、Performance Monitor から見ても正しく割り振りされていることが確認できます。

サーバーでどれくらいの IO が発生しているのか見てみよう

Performance Monitor を使って、ご自身の環境でどの程度の IO が使われているのかを見てみましょう。

サーバー全体で使用されている IO の傾向を見るには、Performance Monitor の Process のカウンターから上記した 3 つのカウンターを選択しますが、監視対象には「_Total」を選択します。_Total を選択すると、特定のアプリではなく、サーバーで動いている全てのアプリの IO を合計した値を示してくれます。以下は、監視対象に _Total が選択されている例です。

perfc20150617

_Total を監視してサーバー全体の IO の傾向を確認した後ですが、次はどのアプリが IO を消費しているのかを確認します。今度は、先ほど選んだ _Total の下に表示されている「<All instances>」を選択して IO を測定します。<All instances> を選択すると、全てのアプリに対して IO を測定するためのカウンターが設定されます。全てのアプリが使っている IO の測定を行うと、以下のような画面が表示されます。これは Iometer で負荷をかけながら Performance Monitor で測定した時の画面です。

perfd20150617

「Dynamo」というアプリ(プロセス)が IO を大量に使って、他のプロセスが使っている IO はほぼ 0 であることが分かります。「Dynamo ってなんだ?」と思われた方、Iometer を実行した時に負荷を発生させるプロセスが Dynamo です。「Iometer っていうアプリ名なんだから、Performance Monitor でも Iometer って名前で表示されるんじゃないの?」と思われがちですが、Performance Monitor にはアプリ名ではなく、プロセス名で表示されますのでご注意ください。

Performance Monitor で計測を行う際、「どの程度の時間をかけてデータを集めれば良いの?」についてですが、できれば一週間くらいデータを取得するのが良いと思います。これは、サーバーが忙しい時間帯・曜日と、ひまな時間帯・曜日の傾向を確認するためです。こういう測定をした結果、忙しい時間帯がごく短時間であれば、Premium Storage を使わずに、Azure VM の D シリーズを使って SSD ディスクで処理をしてしまおうという選択肢がとれるかもしれません。Premium Storage の代わりに D シリーズの SSD ディスクを使うことでコストダウンできます。また、オンプレミスの環境を Azure に移行したい場合などは、今回紹介した IO の測定をオンプレミスの環境で行うことで、移行時に必要な IOPS の傾向を事前に把握することができます。

Performance Monitor の使い方もなかなか奥が深く、今回はディスクのパフォーマンスにフォーカスした内容で書きましたが、メモリリークの傾向やネットワークの負荷状況を確認したい場合などにも使えます。いろいろと試してみてください。

まとめ

  • ディスクに設定する IOPS を算出するためには、アプリケーション(プロセス)が発生させる IO の数を知る必要がある
  • アプリが発生させている IO の数を測定するためには、Performance Monitor を使う
  • IO の使用状況を見て、Premium Storage を使うのか、その他の手段を採用するのかを検討する

 

次回はディスクがボトルネックになっているのかどうかを調べる方法について書こうと思います。

Facebooktwittermail