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

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

2021年06月30日 08時00分更新

文● 髭分将／日本マイクロソフト　編集● 大塚／TECH.ASCII.jp

　Azureのベストプラクティスを紹介していく本連載の第2回では、Azureへ移行する際の「失敗あるある」から、移行におけるベストプラクティスを解説していく。オンプレミスのシステムをAzureに移行することで、設計や運用においてどんな違いが生じるのか、Azureならではのどんな注意事項があるのかを、一般に踏みがちな失敗から考えていきたい。

　本記事では「オンプレミスからIaaSへのシステム移行」をターゲットとして説明を行う。システム改修を伴わないIaaSへの移行は、「システムをそのまま持ち上げる」ことから「リフト」と呼ばれ、大幅な改修が発生するPaaS移行などと比べるとハードルが低い。顧客企業においても「まずはリフトから着手しよう」と考えるケースが多いのが実情だ。

　ただし、オンプレミスの仮想環境とクラウド上のIaaSの間には、皆さんの想像する以上に違いがある。リフトだからと軽く考えていると、思わぬ痛手を被るはずだ。今回の記事を参考に、「失敗あるある」を未然に防いでいただけたら幸いである。

■目次
●ストレージの「失敗あるある」と対処法
　　－失敗あるある：ディスクIOPSの不足
　　－対処法：ストライピング（RAID 0）の活用
　　－対処法：一時ディスクの活用
　　－移行前にIOPSを把握しておくこと
●ネットワークの「失敗あるある」と対処法
　　－Azure移行ではExpressRouteの利用が基本
　　－ExpressRouteが使えない環境での問題
　　－失敗あるある：hostsファイル
●Azureメンテナンス時の「失敗あるある」と対処法
　　－Azureメンテナンスの発生タイミング
　　－失敗あるある：メンテナンスを考慮に入れない監視設定
　　－対処法：監視間隔の変更やリトライ処理の実装

ストレージの「失敗あるある」と対処法

　以下ではストレージ、ネットワーク、メンテナンスというカテゴリごとに「失敗あるある」とその対処法を見ていくことにしたい。まずはストレージからだ。

●失敗あるある：ディスクIOPSの不足

　Azureへの移行において、ユーザーが必ずと言ってよいほど直面するのが仮想マシンで利用するディスクの問題だ。より具体的に言えば「IOPSの不足」である。

　以下に示すのは、Azure仮想マシンで利用できる「Standard SSD」のディスク容量とIOPSの一覧表だ。オンプレミス運用に慣れた感覚で見ると、そもそも「容量」と「IOPS」がひも付けられていることに違和感を覚えるのではないだろうか。

　Azureではディスク容量によってIOPSと課金額が変動する。そのため、移行設計時には既存オンプレミス環境のディスク容量を基準として、利用するディスクのサイズ（SKU）が選択される傾向にある。

　しかし、「ディスクあたりの最大IOPS」の項目をよく見ていただきたい。たとえばE10のディスクは、容量が128GB、そして最大IOPSが500となっている。OSをインストールするディスクならばそれほど問題ではないかもしれないが、データベースやバッチ処理など、ディスク書き込み負荷が高いワークロードで利用するには力不足であることは否めない。

　また、オンプレミス環境でSSDベースのストレージを利用している場合、そのIOPSは500をはるかに超える。単純に「オンプレミスでSSDを使っているから、AzureでもStandard SSDを選んでおけば問題ないだろう」とだけ考えて選択すると、移行の前後でパフォーマンスに大きな差が生じてしまう。

　実際に、データベースサーバーやバッチ処理サーバーのAzure移行を検証すると、このIOPS不足に悩まされるケースは非常に多い。移行後になってこの問題に気づき、ディスクの構成変更を検討することになるのは「失敗あるある」だ。

●対処法：ストライピング（RAID 0）の活用

　Azureでより高いIOPSを求める場合、Standard SSDではなく「Premium SSD」や「Ultra Disk」といったサービスを利用するという手段がある。ただし、いずれも高額なサービスであるため、軽々しく選択できる手段ではない。

　ここで代替策となるのが、OSのソフトウェアRAID機能を使った「ストライピング（RAID 0）」の活用だ。ストライピングは、複数のディスクに対して書き込み／読み出しの並列処理を実行することで高速化する技術だ。

　Windows Serverでは「記憶域スペース」、Linuxでは「mdadm」や「LVM」といった機能が用意されており、いずれも特別な追加コストをかけることなくストライピングを構成できる。ソフトウェアRAIDなので処理のオーバーヘッドは発生するが、1000IOPSの性能を得るためにPremium SSDを利用するよりも、500IOPSのStandard SSDを2つストライピングしたほうが安価に構成できるはずだ。

　もちろんこれは必要なディスク容量とIOPSの組み合わせ次第であり、Premium SSDには一時的にIOPSを拡張するバースト機能もある。また、ストライピングを構成することでオンプレミス環境から大きく変更も生じてしまう。ベストな方法はケースバイケースで選択すべきだが、選択肢の1つとして知っておけば役に立つ場面があるだろう。

●対処法：一時ディスクの活用

　高いIOPSを得るために「一時ディスク」の活用を検討することも大事だ。

　本連載の第1回で説明されているとおり、Azure仮想マシンのディスクは基本的にリモート接続で構成されている。ただし、例外として一時ディスク（Windows Serveの場合、既定でDドライブ）だけは、仮想マシンと同じホストサーバー上のローカルディスクを使用している。そのため高いIOPSが期待できる。

　実際に、よく利用される仮想マシンのパフォーマンス（Das v4シリーズ、下の表）を確認してみると、一時ディスクのIOPSはStandard SSDよりもはるかに高いことがわかる。一時ディスクとして利用されるローカルディスクは、Premium SSDのキャッシュ領域としても利用されるため、一時ディスクおよびディスクキャッシュは合算したかたちでIOPSが設定されているが、それを加味してもStandard SSDのIOPSとは比べものにならない。

　第1回記事でも注意喚起されていたとおり、一時ディスクに記録された内容は、仮想マシンの障害や停止（割り当て解除）などによって失われてしまう。だが、非常に高いIOPSを得ることができ、なおかつ仮想マシンの使用料に含まれるため追加コストが発生しないというメリットがある。そのため、データベース（SQL Server）のtempdbやページファイル、ダンプファイル、あるいはバッチ処理サーバーの一時データの格納領域として活用することで、処理の高速化が見込める。一時ディスクの活用は、Azure仮想マシンでコストパフォーマンス良くIOPSを稼ぐ方法の1つと言えるだろう。

●移行前にIOPSを把握しておくこと

　そして何よりも大切なのは、Azureへの移行前に必ず対象システムのIOPSを把握しておくことである。通常時のIOPSだけでなく、ピーク時のIOPSも必要だ。

　筆者が顧客システムの移行支援を行っていると、意外にも通常時／ピーク時のIOPSを把握していないケースが多いことに気づく。データベースはまだしも、特にバッチ処理用サーバーではそうした傾向が強い。その結果として、オンプレミスの高速なストレージ環境では問題なくさばけていたバッチ処理が、Azureに移行したことでストレージがボトルネックになり、夜間バッチ処理が朝になっても終わらないということになりがちである。

　あらかじめ通常時／ピーク時のIOPSを把握しておけば、こうしたトラブルを未然に防ぐことができ、さらにはStandard SSD／Premium SSDの適切な使い分けや、ストライピング、一時ディスクといったコストパフォーマンスの高い代替策の活用も可能になる。Azure移行を検討する際の重要なポイントとして覚えておいてほしい。