はじめに
Microsoft Azure (旧称：Windows Azure)に関わってもう約15年。感慨深いものがあります。
以前は、サーバー構築というと都心から離れたデータセンターの良く冷えたサーバールームで寒さに震えながら作業していたことを考えると、職場や自宅から簡単お手軽にシステム構築できてしまうクラウドサービスが簡単に使える良い時代になったもんです。
便利になった一方で、クラウドサービスのポリシーや仕様を事前に把握せず、これまでのオンプレミスの知識や経験だけでシステムを構築したために、運用開始後にトラブルの頻発するケースが後を断ちません。
そんなわけで、システム運用フェーズで無用なトラブルを発生させないために、Microsoft Azure を利用する前に必ず理解しておくべきことと思うポイントをまとめてみました。
必ず理解しておくべきこと
- 計画メンテナンスのコントロールは限定的
- 通信タイムアウトは適切に設定すべし
- リトライロジックは必須
- 計画的なリプレースが必要
計画メンテナンスのコントロールは限定的
システムを安全に維持するためには、脆弱性対策含むこまめなソフトウェアアップデートが必須です。そしてソフトウェアアップデートには、一時的な停止がつきものです。メモリ保持メンテナンスの導入など昔と比較すると運用影響はかなり削減されましたが、Azure の場合もアップデートのための計画メンテナンスが毎月のように行われます。多くのサービスはマルチテナント（共用環境）のため計画メンテナンスの大部分は利用者でコントロールできず、あらかじめメンテナンスへの対策が必要です。
Azure 仮想マシン
Azure 仮想マシン (Azure Virtual Machines) サービスは、Hyper-V ベースの仮想化技術によって提供されていますが、Azure Host OS やハードウェア（下図の青色で塗り潰した箇所）のセキュリティ更新や機能拡張などのために、計画的なメンテナンスが月に１回程度の頻度で行われます（その他、緊急メンテもありうる）。
ホストのメンテナンスによって、わずかながら仮想マシンの運用に影響し、多くの場合、数秒から30秒程度のフリーズ状態が発生します。フリーズ状態の間、他のマシンからの通信への応答などができません。他の利用者と物理サーバーを共有している以上、このフリーズが発生する日時をコントロールすることはできません。もし、コントロールしたいのであれば、Azure Dedicated Host を使って物理サーバーを専有利用することが唯一の解決策となります。
その他のサービス
メンテナンスウィンドウが設定できる Azure の PaaS サービスや Azure Firewall などのネットワークサービスにおいても、設定できるメンテナンスウィンドウはゲストOS上のソフトウェアの更新が対象です。物理サーバーのメンテナンスをコントロールするものではないと理解ください。
例えば、Azure Cache for Redis では、次のように説明されています。
更新チャネルとメンテナンス期間は、キャッシュをホストしている VM のオペレーティング システムに対する Redis サーバーの更新と更新に適用されます。 更新チャネルとメンテナンス期間は、キャッシュ VM やその他の Azure ネットワーク コンポーネントをホストするホスト OS の更新には適用されません。
すなわち、利用者でコントロールできるのは、下図の茶色の部分になります。
それ以外の部分は、Azure仮想マシンの説明で述べた通りコントロールすることはできません。
結局のところ、メンテナンス期間の設定有無に関わらずフリーズメンテナンスの影響は避けられません。そのため、Azure を利用する以上、後述の通信タイムアウト設定やリトライロジックが必須となります。
通信タイムアウトは適切に設定すべし
Azure のホストのメンテナンスの大部分は、数秒〜30秒程度以下のフリーズという形で影響します。
以下は、私が東日本リージョンに配置した仮想マシン(Standard B2s)のメンテナンス実績(2024年1月から2025年6月末)です。
| 日時(GMT) | 影響時間(秒)※ |
|---|---|
| 2024-02-01 22:33:13 | 30 |
| 2024-02-08 04:35:29 | 9 |
| 2024-08-31 13:13:23 | 7 |
| 2024-09-18 22:58:11 | 0 |
| 2024-10-03 21:34:37 | 7 |
| 2024-11-06 06:21:36 | 1 |
| 2025-02-04 14:35:51 | 1 |
| 2025-03-02 08:54:59 | 25 |
| 2025-05-20 14:27:03 | 1 |
| 2025-05-25 13:17:58 | 15 |
※ Azure Instance Metadata Service で取得した影響予想時間
したがって、フリーズ（通信無応答や遅延）が発生することを想定して、通信タイムアウトやリトライを設計・実装しなければならないということになります。
日本マイクロソフトのAzure テクニカル サポートチームの Azure IaaS VM で実施されるメンテナンスについての案内がございますが、30秒以内に収まるとは限らないので、その点は理解しておく必要があります。
アプリケーションにおいて、通信のリトライが実装されておらず、タイムアウトも固定で変更できない場合、メンテナンス影響は避けられません。
リトライロジックは必須
通信タイムアウトを適切に設定すれば、計画メンテナンスの影響を避けられるのかというとそうではありません。通信異常時のリトライロジックは必須です。
例えば、Azure Firewall の計画メンテナンスは、次のように説明されています。
計画されたメンテナンスの場合、接続のドレイン ロジックにより、バックエンド ノードが適切に更新されます。 既存の接続が閉じられるまで、Azure Firewall は 90 秒間待機します。 最初の 45 秒間、バックエンド ノードは新しい接続を受け入れず、残りの時間はすべての着信パケットに RST で応答します。 必要に応じて、クライアントは別のバックエンド ノードへの接続を自動的に再確立できます。
リトライが実装されておらず通信断が容認されないアプリケーションの場合、通信経路に Azure Firewall を配置しないよう設計しましょう。
計画的なリプレースが必要
Microsoft Azure に限ったことではありませんが、クラウドでもリプレースは付きものです。
より良い機能が提供される一方で、今使っている機能が終息になるため変更しなければならないということは多々あります。
Azure Service Health や Azure Advisor のサービスの廃止ブック などを用いて利用しているサービスのライフサイクル（終息情報）を把握して、中長期的なリプレース計画を立てることが肝要です。
なお、FUJITSU Hybrid IT Service for Micrsoft Azure では、契約顧客向けに機能終息情報の一覧の提供や定期的な注意喚起を行なっております。
最後に
初めて Microsoft Azure 上にシステムを構築される方に向けて、重要と思うポイントをまとめてみました。構築時に気が付かず、運用開始してから夜間の緊急コールに悩まされることのないよう対策していきましょう。