(ストレージのFQAより)課金は1日のピークで行なわれるので、図の例で6月15日にゼロにするためには、6月14日中に削除しておく必要があります。HDDを含むすべての種類が割り当て単位で課金されます。カタログにある容量を超えた場合は課金が切り上げられます。ストレージアカウントと同様、請求は1ヶ月単位のサイクルで行なわれますが、マネージドディスクの使用が1ヶ月に満たない場合は1時間単位の課金となります。以下に示す料金が月額になります。か月未満使用した場合はどのように課金されますか。料金は月額を使用して、時間単位で計算されます。(リージョンによって料金が異なります)。¥6.582/時間で課金されます。(マネージドディスクのFQAより)仮想マシンイメージの課金マネージドディスクから仮想マシンイメージを作った場合、「スナップショット」と同等の料金がかかります。「無料」と書いてある記事もあるようですが、課金されることはサポートに問い合わせたので間違いありません。実際に課金状況を調べてみると、はるかに小さな金額しか請求されていません。「課金サポートではこれ以上のことは分かりかねるので、有償の技術サポートに連絡して欲しい」と言われました。詳細が分かったら報告します。仮想マシンの課金Azureの仮想マシンは、分単位課金です。仮想マシンが実行状態になってから課金がスタートして、最初の1分は無条件に1分が課金されます。その後、1分59秒までは追加の課金がなく、2分になってから次の1分の課金が行なわれます。AzureのWebサイトには「秒単位課金」という言葉や「時間課金」という言葉が混じっていて混乱していますが、ブログ執筆時点で分単位で課金されることは間違いありません。「秒単位課金」は「秒単位計測」の意味のようです。1分59秒までが1分、2分ちょうどから次の1分と、正しく認識するには秒単位の計測が必要です。「時間赤金」は課金明細の記載単位だそうです。1時間」のように、1時間単位で記載されています。後損仁通り、仮想マシンの課金は単なるシャットダウンでは停止せず、「割り当て解除」状態に移行しないと課金が継続します。ハードウェアの割り当てをしている以上は「使っている」とみなすわけですが、これも直感に反します。理屈が分かれば不思議ではないのですが。Azureの仮想マシンにドメインコントローラーを構成する場合、以下の注意が必要です。データベースはCドライブに置かない仮想ネットワークのDNSサーバーアドレスをドメインコントローラーのものに変更するAzureのシステムディスクにはRead/Writeキャッシュが設定されていて、不慮の事態によるデータロスがあり得ます。SLAでは稼働率99.9%とか99.95%となっていても、落ちるときは落ちます。ドメインコントローラー昇格時は、ディレクトリデータベースを配置したディスクドライブのキャッシュを無効にするため、データロスの問題は発生しませんが、パフォーマンス劣化の問題があり、いずれにしてもCドライブににディレクトリデータベースを配置するのは好ましくありません。思っていたんですが、Azureキャッシュは無効にできないようです。「データベースはCドライブに置かない」という結論は同じですが、その理由は「予期せぬ停止により、データロスが発生する可能性があるから」ということになります。このあたりの話は、以下のコースで扱っています。Serverの話をしています。最後の1時間くらいです。Azureの「可用性ゾーン(AZ)」が東日本で利用できるようになっています。西日本はもう少しかかりそうですが、いずれは利用できるようになるそうです。AzureのAZは、リージョンあたり3つと決まっています。AWSは「2つ以上」だったでしょうか。Azureのリージョン間は数百Km以上離れているので非常に安全ですが、少々距離が遠すぎます。AZ間の距離は(同一リージョン内の)数十Kmと、かなり短くなっています(AWSと同程度です)。阪神大震災でも40Kmも離れればほとんど影響はありませんでしたから、実用上はAZで十分でしょう。従来の可用性セット(AS)は、最短でサーバーラックが分離されるだけですから、大規模災害に対しては少々不安が残ります。災害リスクを考えるとAZが必要でしょう。日本に関しては、可用性セットで分離できる障害ドメイン(サーバーラック)は2つですから、障害範囲に関しても現時点ではAZの方が有利なようです。AZは仮想マシンを作るときにゾーンを明示的に指定する必要があります。それに対してASは「とりあえず同じASにする」という設定で、適当に分散してくれます。何も考えなくてもいいので、ASの方が設定は楽です。以上のことから、災害対策を想定する場合はAZ、ハードウェア障害を想定する場合はASと使い分けるのがいいようです。Azureでは災害対策にはASR(Azureサイトリカバリ)も利用できます(ASRはリージョン間の複製です)。ASRを使っているならAZを使う必要はないでしょう。「AzureのAZはAWSのAZと同じ」という説明がされていますが(私もしています)、実際には違いもあります。AWSでは、AZ単位でサブネットを分割する必要があります。これに対して、Azureでは同一サブネット内に異なるAZのサーバーを配置できます。AZが違えばデータ伝送遅延時間が違うので、異なるAZを同じサブネットにするのが適切かどうかは分かりません。AWSと同じように、異なるAZは異なるサブネットにした方が分かりやすいのではないでしょうか。試しに、複数のAZに複数のサブネットを構成してpingを実行してみました。Windowsのpingは応答時間の分解能が低いのでLinux(Ubuntu)を使っています。図のように、AZ内では1ミリ秒程度、AZ間では2ミリ秒程度の遅延がありました。サブネットの有無は速度に影響しません。これもAWSと同様のようです。アプリケーションにとっては1ミリ秒と2ミリ秒の違いが重要な場合もあるので、サブネットを自分で分けた方が分かりやすそうです。Serverを中心に技術者向けトレーニングを担当。コミュニティにおけるトレノケート社員による発言やコメントは、トレノケートの正式な見解またはコメントではありません。