この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

本記事は2020年7月時点の情報を元に記載しています。閲覧時と時間差がある場合Microsoft社の最新情報と合わせてご参照ください。

 

パーソルプロセス＆テクノロジーの桂川です。公式な告知から半年ほど経過していますが、ついにAzure草創期から使われていたクラシックモデル（ASMモデル）の仮想マシンサービス終了期限が設定されました。これまで各サービスのクラシックモデルのサポートが終了するごとにビクビクしておりましたが、ついに来てしまいました。告知後ほどなくCOVID-19の影響が出始め、システム担当者の方々のご多忙が想定されるところですが、こちらについても進めていかなければなりません。
この記事ではサービス終了の期限をふまえ、システム移行の技術的な話から一歩引いた、システム担当者の方々がどのように移行計画を進めればよいかわかることを目的としています。是非本記事ご参照の上スムーズな移行計画の策定を進めていただければと思います。

 

終了期限と延長の可能性

・サービス終了期限

これはMSドキュメントを見ればわかりますが、おさらいとして記載です。
終了期限については以下のように定められています。
————————–

2020年2月28日～
・クラシックモデルでのIaaS VMの新規作成ができなくなる
　※2020年2月中にクラシック IaaS VMを利用していない場合

2023年3月1日～
・クラシックモデルでのIaaS VMの起動ができなくなる
　※IaaS VMの削除については同日告知予定

————————–
公式情報は以下をご参照ください。
2023 年 3 月 1 日までに IaaS リソースを Azure Resource Manager に移行する

 

・終了期限延長の可能性

これまでにMicrosoftのサービス終了期限は諸々の事情で延長されたこともあります。そのため今回のクラシックモデルのサービス終了の期限が延長される可能性もゼロではありません。Microsoft社としても現時点でその点について明言はできないと思います。
ただ、あくまで個人的な意見ですが、サービス終了期限が延長される可能性は低いと思います。弊社も長年Azureビジネスに携わっており、その中でクラシックリソースを利用されているお客様は少なくなく、かつ大規模に使われているお客様も多くいらっしゃることは認識しております。ただし、今回設定されている期限は告知から3年間の猶予があり少なくとも「圧倒的に時間が足りない！」と言う類のものではありません。また、移行先であるARMモデルも2014年から提供、クラシックモデルへの移行コマンドが2018年から提供されていることも鑑みると移行できる準備は整っていたと言えます。
Microsoft社がこれまでサービス期限の終了を延長する際に「エンドユーザー影響」を考慮していたケースもあるかと思いますが、少なくとも今回その点においては延長の要因とはなりにくいと考えられます。
結論、少なくとも期限通りにサービス終了となる想定で移行を進めていくしかないと考えられます。

　

移行計画の策定

・いつ立てる？

移行は勿論小規模であれば1ヶ月以下で終わるケースもあると思いますが、リソースの規模によっては想定外のコストが必要になったり、1年以上の計画が必要になる場合もあります。想定のコストを予算取りするための期間や、1年程度かかる計画のリソース調整を鑑みると、クラシック IaaS VMに一定の規模がある場合や、移行計画の策定できない場合は、計画自体は来期予算計画の前までに終わらせておくと良いかと思います。

　

・どう立てる？

クラシックIaaS VMのサービス終了とはいえ、何から始めればいいかわからない方は多いと思います。以下に移行計画の策定フロー及び方法を例として記載します。是非情報参考に計画策定を進めていただければと思います。

　①サービス終了範囲の確認
今回サービス終了となるのはクラシックモデルのIaaS VMで、クラシックサービス全てが終了となるわけではありません。
Cloud Serviceやクラシックのストレージアカウント等が終了するわけではないことを認識しましょう。

 

　②自社環境におけるクラシック IaaS VMの有無/構成の確認
“①”の情報を踏まえ、自社Azure環境のクラシック IaaS VMの有無を確認しましょう。Azureポータルで「仮想マシン（クラシック）」でソートすることで確認できます。
また、該当のリソースがあった場合、併せて以下についても確認しましょう。
————————–
・クラシック IaaS VMが所属している仮想ネットワーク
・クラシック IaaS VMが通信を行っているノード
・クラシック IaaS VMが利用しているストレージアカウント
・クラシック IaaS VMが利用しているサービス（サードパーティー含む）
————————–

 

　③システムの移行有無を確認する
ココが意外に重要です。
“②”の情報を踏まえ、該当のクラシック IaaS VMが、移行する必要があるか？を考えましょう。基本的に現在も稼働しているリソースのため必要かとは思いますが、実は既に使われていなかったり、冗長化する必要がないため削減できたり、他のサーバに同居させられたり、外部のSaaSサービスに置き換えられる、など、ARM移行以外の選択肢はあります。クラウドのメリットを活かすためにもシステムの「必要最低限」を見極めましょう。

 

　④移行パターンを決定する
移行するクラシック IaaS VMが決まったら次は移行パターンを決定します。移行はコマンドで行ったり、新規で作り直したり、ディスク単位で作り直したり、と言ったパターンがあります。とはいえ、工数を鑑みると移行コマンドはかなり簡易にできるため、もちろん検証等は必要ですが、移行コマンドを軸に考え、どうしてもできない場合は、それ以外の方法を検討する、という流れが良いかと思います。
この点については以下の記事が詳しいのでご参照ください。
クラシック（ASM）からリソースマネージャー（ARM）モデルへの移行パターン

 

　⑤ダウンタイム/コスト/リソースを試算する
“④”で決めたパターンを基に、対象のクラシック IaaS VMの移行に伴うダウンタイムやコスト、必要なリソース（工数）を試算します。試算される情報は規模に応じて変動しますが、恐らく単純な台数や性能よりも、どれだけ他のシステムやサービスと連携しているか、と言う方が影響が大きいかと思います。

 

　⑥時期、役割分担、大枠の移行計画を決定する
“⑤”の情報を元に、ダウンタイム→ユーザー影響、コスト→予算、リソース→自社工数と言った情報を鑑み、要件確認・設計・構築・移行と言ったフェーズ単位でいつ、だれが作業を進めるか、いつダウンタイム/コスト/リソースが発生するか、と言う程度の計画で良いかと思います。

 

Tips：何もせずサービス終了を迎えたら復旧できる？

　※以下あくまで執筆時点の情報を基にした想定の内容です※
クラシックモデルのVMとしての復旧は恐らく不可能です。
しかしながら、中身データの復旧であれば恐らくできるのではないか？と思います。
現在アナウンスされている情報ですとクラシックのストレージアカウントは終了の対象となっておらず、クラシックIaaS VMも削除されると言った情報はないため、クラシックのIaaS VMは起動できなくなる「だけ」でデータが消失するわけではないと想定されます。
その場合VHDディスクをARM IaaS VMモデルにマウントすることで追加ディスクとして中身を確認することは可能かと思います。ただし、そのVHDファイルをシステムドライブとしてた仮想マシンとしての復旧については、事前のsysprepやNW設定が移行後環境で対応されている必要があり、その上でMicrosoft社のIaaS VMにおける仕様の影響もあるため復旧困難と認識しておいた方が無難かと思います。