プロに教わるAzure設計運用のベストプラクティス 第2回

オンプレミスからIaaSへの単純な「リフト」でもよく発生するトラブルと解決策

「失敗あるある」から考える、Azure移行のベストプラクティス

Azureメンテナンス時の「失敗あるある」と対処法

　最後に、Azureのメンテナンスについてよくある失敗とベストプラクティスを考えていく。

●Azureメンテナンスの発生タイミング

　オンプレミス環境とAzureの違いとして、Azure側の判断によってメンテナンスが自動で実施される点が挙げられる。Azureがサービスを安定的に提供するために実施するものであり、顧客側ではそのタイミングをコントロールできないという点が重要だ。ここで言う「メンテナンス」にはさまざまなものが含まれるが、次の4つに大別することができる。

　① 障害時の復旧メンテナンス
　② 仮想マシンの再起動を必要とするメンテナンス
　③ ライブマイグレーション
　④ メモリ保護更新

　①は、何らかの障害発生時にシステムを復旧させるためのメンテナンスだ。たとえばホスト障害によって仮想マシンが停止したあと、異なるホストで仮想マシンを自動復旧（起動）させるようなケースである。これはオンプレミス環境でも発生しうる事象であり、違和感はないだろう。

　②は非常にまれだが、過去には実施されたケースがある。大規模なものとしては2018年、「Spectre」「Meltdown」というCPU脆弱性への対応として、ホスト側ハイパーバイザの更新を適用するために強制的な仮想マシンの自動再起動が行われた。通常、こうした仮想マシンの再起動を要するメンテナンスでは、利用者側で再起動のタイミングをある程度コントロールできるようにしている。だがこのケースでは脆弱性の影響範囲が大きく、緊急度も高かったためにこうした措置がとられた。筆者の記憶するかぎりでは、この件以降、すべての仮想マシンに影響する規模で再起動が必要なメンテナンスは発生していない。

　③のライブマイグレーションは、仮想マシンを稼働させたまま異なるホストに移動する技術で、移動処理中の仮想マシンには数秒間の一時停止状態が生じる。更新プログラム未適用のホストから適用済みホストへの移動、リソース利用量が多いホストから少ないホストへの移動、障害予兆が検知されたホストからの退避といったケースで実行されることがある。

　④のメモリ保護更新は、仮想マシンを稼働させたまま、ホストに更新プログラムを適用する技術だ。通常は数秒程度、最大で30秒間の一時停止状態が生じる。毎月適用されるホスト向け更新プログラムの多くは、③のライブマイグレーション（適用済みホストへの移動）を伴わない、この④で実施される傾向にある。

●失敗あるある：メンテナンスを考慮に入れない監視設定

　通常のWindows Serverと同様に、ホストの更新プログラムは毎月リリースされている。①以外のメンテナンスは日中の時間帯を避けて実施されるが、それでも毎月③もしくは④のメンテナンスで仮想マシンの一時停止が発生するというのは、オンプレミス環境にはないAzureならではの事象だ。また②以外のメンテナンスについては、原則としてメールなどによる事前通知なしで実施されるという点にも注意が必要だ。

　実際のところ、メンテナンスによる仮想マシンの一時停止で問題が生じるケースは少ない。ただし、以下のような特定のケースでは問題が顕在化することもある。

　（A）Windows Server Failover Cluster等のクラスター サービスにおけるハートビート通信が無応答になり、フェールオーバーが発生する
　（B）夜間のバッチ処理等でデータのフェッチ先仮想マシンが無応答になり、バッチ処理そのものがエラーとなり失敗する
　（C）死活監視のパケットに無応答になり、アラートが発報されてしまう

　Azure側で定期的にメンテナンスが発生することを理解しておらず、移行後にそれを知って対策を検討するというのは、非常によくある「失敗あるある」だと言える。

●対処法：監視間隔の変更やリトライ処理の実装

　上述した（A）～（C）のケースについては、それぞれ次に示すような対処を行うのが望ましい。

　（a）ハートビートの間隔を、メンテナンス時間を意識したものにする
　（b）バッチ処理の中で、アクセス先へのリトライを実装する
　（c）監視の間隔を、メンテナンス時間を意識したものにする

　（a）では、最大30秒間の断（仮想マシンの一時停止）に耐えられるハートビート間隔、障害検知の閾値を設定することが望ましい。もっとも、最大30秒間の断を許容することで、本当の障害発生時にも検知が遅れ、ユーザーサービス品質に影響が出てしまう可能性がある。それが許容できないシステムの場合は、メンテナンスによる一時停止であってもフェールオーバーするシステム設計を行う必要がある。

　（b）は、バッチ処理にかぎらずデータベースにアクセスするアプリケーションなどでも有用なアプローチであり、間隔を空けたリトライ処理を実装することでエラーを回避できるはずだ。オンプレミス環境では、データベースやファイルへのアクセスの失敗はほとんど発生しないため、リトライが実装されていないケースが多い。Azureへの移行に際しては、バッチやアプリケーションの改修が必要な場合もあるということは頭に置いておいてほしい。

　（c）も、（a）と同様に最大30秒間の断が発生することを前提とした変更となる。たとえばPingで死活監視を行っている場合、オンプレミス環境では5秒間隔／3回連続の失敗時にアラートを発報する設定にしているものを、Azureでは10秒間隔／4回連続失敗という条件に見直す、といったことだ。

　ここまで説明してきたとおり、Azureにおいては、顧客側ではタイミングをコントロールできないメンテナンスが発生する。特に、ライブマイグレーションやメモリ保護更新によるメンテナンスのハンドリングを間違えると、毎月何らかのアラートに悩まされるはめになる。移行前に十分考慮しておくことが大切だ。

★メンテナンスのベストプラクティス

・メンテナンス時に発生する一時停止をどのようにハンドリングするか、主に「クラスター」「バッチ処理」「監視」の観点で移行前に検討しておく
・特に、バッチ処理やアプリケーションのリトライ実装は非常に重要。移行前によく検討しておく

＊　＊　＊

　今回は、オンプレミスからAzureへの移行において、ストレージ／ネットワーク／メンテナンスの観点でそれぞれよくある失敗と、そこから考えられるベストプラクティスをご紹介した。Azureへの単純な「リフト」と言っても、あらかじめ検討しておくべきさまざまな要素がある。それぞれの注意点について事前に検討／検証を行い、動作を理解しておくことで、トラブルの少ないAzure移行を実現できるはずだ。

●参考文献、リファレンス

・Managed Diskの価格とサイズ一覧：料金 - Managed Disks | Microsoft Azure

・記憶域スペースの構築：スタンドアロン サーバーに記憶域スペースを展開する | Microsoft Docs

・ExpressRouteについて：Azure ExpressRoute の概要プライベート接続を介して接続する | Microsoft Docs

・ExpressRoute経由でAzure Migrateを利用する：Azure Migrate Server Migration を使用して ExpressRoute 経由でデータをレプリケートする - Azure Migrate | Microsoft Docs

・Azure 仮想マシンにおけるメンテナンス：メンテナンスと更新 - Azure Virtual Machines | Microsoft Docs

・リトライ処理のガイダンス：再試行の一般的なガイダンス - Best practices for cloud applications | Microsoft Docs

●筆者プロフィール

髭分 将／日本マイクロソフト Premier Field Engineer

　国内NIerでネットワーク製品の営業やサポートエンジニアを経験した後、Microsoftに入社。Microsoft ではAzure及びAzure Stack HUB/HCIといったハイブリッド ソリューションのエリアを担当。これまでにエンタープライズのAzure移行支援や、パートナー向けのAzureトレーニング等に従事。

　プライベートでは二人の娘の面倒をみたり、ビールを飲んだりすることに専念して暮らしています。