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でインフラを構築する場合は参考にしてもらえればと思う。
…個人的には、構築前に一度サポートに問い合わせをしたほうが良いと思う。