Microsoft Azureに構築した環境で負荷試験を行った際、インフラ回りでひっかかったことについて念のため記述しておく。
一応、サポートから正式に回答いただいた(電話で聞いたとき聞き間違いかな？と思ったのでメールで詳細についてももらって確認している)ことなので、事実…ではあるようだ。
なお、この情報は2016年06月時点のものなので、仕様が変更される可能性もある。
設計前に一度MSに問い合わせたほうが良いだろう。
OS側で要求するIOPSがディスクの制限値を上回ると、ディスクの応答を数秒間停止させる
…らしい。
規定のIOPS(プレミアムストレージ以外だと500が上限)を上回るIOPSが発生した場合、他の利用者に影響が出ないようAzure側でディスクが応答しないようにして調整するらしい(動作的には、ディスクが満杯になった際の挙動と同じらしい)。
で、止まってる間も規定値を超えるIOPSが発生し続けていた場合、その間ずっとディスクが応答しないでいると…
ディスクが応答しない状況が続いた結果、OSが再起動され、最悪の場合だとOSのクラッシュも発生する(した)らしい。
ディスクの物理破損の心配ないと思ってRAID0とかでストライピングするのは危険そうだ。
VMのプランに応じてネットワーク帯域制限がある
表にはこのあたりの情報は出してないらしいけど、少なくともStandardプランで650MBpsくらいとのこと。
もち、それ以上はパケットロスとなる。
VMのプランに応じた帯域で、各ネットワークインターフェイスごとに制限をかけているようだ。
対策
とりあえず、サポートいわくこんな感じらしいので、負荷がかかるようなサービスを提供する場合は、この辺を考慮したインフラ設計をしていただければと。
今のところ、それぞれの対処法としては以下のような感じなのだろうか？
ディスクのIOPS問題への対策
- Linuxだったらcgroup使ってIOを制御する
- プレミアムストレージを用いる(既存の環境がある場合はストレージアカウントが変わるので作り直しになる)
- 大きな容量を使用する場合は、Blob Storageとかを使って可能な限り仮想HDDは使わない。
ネットワーク帯域制限への対策
- 帯域制限がかかるのがネットワークインターフェイスらしいので、クラスタを組んでたり用途の違うネットワークがあるなら、それ用の仮想ネットワークをちゃんと作成してやる(VMに紐づくネットワークインターフェイスや仮想ネットワークを、通信用途ごとに複数用意してやる)
- VMのプランに応じて帯域制限の容量も変わるらしいので、プランを引き上げる
こんな感じかなぁ。
あとは、VMでいろいろと機能を持たせるのではなく、極力Azureに用意されている機能(DBが必要ならClearDBとかオブジェクトストレージならBlobとか)を利用するようにすればいいだろう。
とにかく、AWSと同じようにインフラを設計するのは少し危険なようなので、もしAzureでインフラを構築する場合は参考にしてもらえればと思う。
…個人的には、構築前に一度サポートに問い合わせをしたほうが良いと思う。
