Azure 環境における本番環境の複製作業をする機会がありましたので、今回その過程で経験した「こんなはずじゃなかった！」というポイントや、押さえておきたいノウハウをご紹介します。
複製した本番環境の構成
今回の複製対象の構成は、以下のLinuxベースのシンプルなものです。
- 仮想マシン (VM): アプリケーションサーバーとして利用
- OSディスク: VMに紐付くOS用ディスク
- 仮想ネットワーク (VNet): VMが接続されているプライベートネットワーク
- セキュリティグループ (NSG): VNet内のVMへのアクセス制御
- パブリックIPアドレス: 外部からのVMへのアクセス用
- ネットワークインターフェイス (NIC): VMとVNetを接続 (NICにセキュリティグループを設定済み)
これらのリソースを複製し、ステージング環境を構築します。
ところで、なぜ「本番環境の複製」が必要なのか？
「本番環境の複製なんて必要？」そう思われるかもしれませんが、意外とそうしたケースは存在します。開発・運用においてステージング環境は必須ですが、時間の経過とともに本番との乖離が生じたり、大規模テストや緊急な検証のために、より本番に近い最新環境が必要になったりすることがあります。
このような場面で、本番のサービス稼働に影響を与えることなくその内容を迅速に複製できることは、ときに有効です。これにより最新の環境で綿密なテストができ、リリース後の予期せぬトラブルを減らすことにも繋がります。
主要アプローチと気づきポイント
当初、「リソースグループごとコピーできたら楽なのに」と淡い期待を抱きましたが、Azureでは残念ながらそのような直接的な複製機能はありませんでした。そのため、個々のリソースを組み合わせて構築することになります。
大まかな複製のアプローチ
(Azureポータルで操作＋ARMテンプレートを使用)
※ARMテンプレートはAzure Resource Managerを使ってAzureリソースをデプロイする際に使用するJSON形式のファイル
１．ステージング環境用リソースグループの作成
２．ネットワーク関連リソースの作成
本番環境からARMテンプレートをエクスポートし、仮想ネットワーク、セキュリティグループ、パブリックIPアドレス、ネットワークインターフェイスの順でデプロイします。
ネットワークインターフェイス作成の段階で、直前に作成した3つのリソース(VNet、NSG、パブリックIPアドレス)をNICに紐づけます。
３．VMとOSディスクの複製
Azure Backupを利用し、バックアップ済みVMから「新規作成」オプションでVMとOSディスクを復元します。
複製作業で気づいた主な落とし穴とノウハウ
今回は細かな手順というより、作業過程で気づいたポイントをいくつかご紹介します。
ARMテンプレートの活用:
本番環境からエクスポートしたARMテンプレートは、意外とそのまま読み込んで進められる部分が多いです。事前に細かく内容を把握してから編集が必要かと思っていましたが、読み込んだ後のAzureポータル画面で、ステージング環境用のサブスクリプション、リソースグループ、リージョン、リソース名を設定できます。
パブリックIPアドレスも、本番用のARMテンプレートをそのまま読み込んでも、本番とは異なるIPアドレスが自動で新規に割り当てられます。
ネットワークインターフェイスは上記項目に加えて、紐づけるパブリックIPアドレス/仮想NW/セキュリティグループが設定できるので、ここは本番環境のものではなく必ず事前に新規作成したステージング環境用のリソースIDに置き換える必要があります。
ARMテンプレートによる差分確認:
そのほかARMテンプレートを使う利点として、複製元の本番環境のARMテンプレートとステージング環境用に作成したリソースのARMテンプレートを、差分をとって比較することで、意図通りかどうかのチェックができます。
また、本番環境構築当時からある程度の期間が経過していると、その後にAzureで機能追加されている部分が設定項目有無の差分としてあらわれるので、その辺りも把握できる良い機会になります。
<ARMテンプレート例> ※一部非表示加工あり
VM複製時のNICとパブリックIPアドレスの自動生成
Azure Backupからの復元でVMを「新規作成」する際に、仮想ネットワークとサブネットは選択できますが、NICやパブリックIPアドレスは選択できず、自動的に新しいものが生成されてVMに割り当てられてしまいます。(予想外)
⇒セキュリティグループ適用の注意点:
複製元の本番環境で、NICにのみセキュリティグループが設定されていた場合(仮想NWには設定されていない場合)、ステージング環境用に新規作成されたVMには、まだ事前に作成したNICが割り当てられていないことにより、セキュリティグループが適用されていない状態になります。そのため、事前に仮想ネットワークのサブネットにも適切にセキュリティグループを設定しておくことを強く推奨します。(VM起動時には、中身が本番環境と同等のVMが動作することになるため)
⇒NIC付け替え時の注意点:
VM作成時に自動で割り当てられたNICではなく事前に作成したNICに付け替えるには、VMには常にNICが1つ以上必要であるため、いったん両方を割り当てたうえで、不要な方を外す必要があります。その際に双方のNICに割り当てられているパブリックIPアドレスのSKU(契約プラン：Standard/Basic等）が異なると、同時にNICをVMに対して割り当てられないエラーが発生するため、SKUを合わせる必要があります。（ややハマりポイント）
ストレージアカウントの利用:
VM復元時には、仮想ディスクのイメージファイルを一時的に格納するためのストレージアカウントを選択する場面があります。ここで、一時的とはいえ本番環境にあるストレージアカウントを使用することは避けるために、ステージング環境用にストレージアカウントのリソースを新規作成しておく必要があります。（予想外）
VM作成後の考慮:
本番環境を複製しているため、VM起動直後からcronジョブなどでプロセスが稼働する可能性があります。事前に、セキュリティグループで通信を制限したり、早い段階で不要なプロセスの停止や自動起動の無効化をしておきましょう。
データディスクの利用確認:
複製元にOSディスク以外にもデータディスクが存在し、かつVMにアタッチされている場合でも、実は使われていないケースがあります。Azureポータルの設定だけで見ると使用しているように見えますが、VMにSSH接続してLinuxコマンドのdf -hなどでマウントや利用状況を確認すると、実はマウントされておらず使用していなかった、ということがあります。念のため確認しましょう。
まとめ
今回は、Azureの本番環境の複製作業で起きた予想外な点や気づき、注意ポイントなどをご紹介しました。
・リソースグループの直接複製はできないため、個々のリソースを組み合わせる
・ARMテンプレートはNW関連リソース作成の効率化と、構成比較チェックに活用できる
・VM複製による新規作成時のNICは自動生成される
・セキュリティグループ適用有無を確認する
・NIC付け替え時のSKU合わせに注意
・バックアップの復元に一時的な利用としてストレージアカウントが必要になる
・複製VM起動後のプロセスの動作に注意、データディスクの実使用状況も確認を
「既にある環境を複製」という言葉だけでとらえると簡単そうですが、予想外のことやいくつか考慮すべきこともありましたので、もし今後同じように本番環境の複製が必要な場面に遭遇した際は、そういえばいつだかそんな記事を見かけたなと思い出していただければと思います。
エコモットでは、ともに未来の常識を創る仲間を募集しています。
あなたがお持ちのAWSやAzureの資格を活かせる場面がたくさんあります。
弊社に少しでも興味がある方はぜひ下記の採用ページをご覧ください！
