お客様環境にて安全に作業実施するためにできること～リタイアメント対応編～

藤田美卯 - Nomura Research Institute, Ltd.

はじめに

こんにちは、NRIの藤田です。
現在は、Azureでらくらくパックのお客様環境の情報を管理するための開発業務と、基盤構築されているお客様のシステムの維持・保守をメインで担当しており、昨年からはAzureのリタイアメント対応の主担当をしています。
今回は、お客様環境にて品質を保ちながら安全にリタイアメント対応を行うために実施していることについて実例を用いてご紹介したいと思います。

そもそもリタイアメント対応とは何なのか、またリタイアメント情報のキャッチアップ方法については下記のブログをご参考ください。

atlaxblogs.nri.co.jp

公式手順がベストとは限らない？リタイアメント対応における品質担保の考え方

リタイアメント情報はMicrosoftから公式に発表されるため、情報が発表される際にMicrosoftから移行手順やツールも提供されていることが一般的です。
しかし、状況によってはツールの内部でどんな処理を行っているかが見えない場合や、提供された手順が適さない環境がある可能性もあるため、提供された手順やツールをそのまま使用するというのは、必ずしも安全や品質が担保されているとは言えません。
従って、実機での検証や問い合わせ、お客様へのヒアリングを通じてご要望や環境に合った手順を確立することが品質の担保に繋がります。

Microsoft Azureに関するソリューション・事例はこちら

Azure Load Balancer移行で直面した「ダウンタイム」と「切り戻し」の壁

では、具体的にどのようにご要望や環境に合った手順を確立するのか、過去行ったAzure Load Balancerのリタイアメント対応を例に挙げてみたいと思います。
Azure Load Balancerは業務通信の可用性を高めるために一つの仮想マシンにのみ負荷がかからないようにするためのAzure上のリソースであり、このリソースに入ってきた通信はバックエンドプールに設定している仮想マシンへ分散されます。

このリソースのリタイアメント対応では、2025年9月30日をもってBasicバージョン（Basic Load Balancer）が利用できなくなるため新しいStandardバージョン（Standard Load Balancer）へアップグレードするという作業を行いました。
本対応でもMicrosoft 公式の自動移行ツールや、公式の手動移行手順が展開されておりましたが、この対応の移行方式をお客様と決める上で、移行失敗時の影響と作業時間が懸念事項として挙がったため、最終的にはオリジナルの手動移行手順を採用しました。
方式を決める上で重視したことはできるだけお客様の環境に影響を与えないことです。主に下記2点の懸念事項において対策案を検討し、結果的にお客様の重要システムに対する影響を最小限に抑えつつ、問題発生時にも安全に元に戻せる移行方式を実現することができました。

移行中・移行後に何か問題が生じたら確実に移行前の状態に戻せるか
→リソースの再作成ではなく、リソース切り替え方式の採用
通信断（ダウンタイム）の時間をできるだけ短くできるか
→Azure Portal上での手動移行ではなくスクリプトでの移行を実施

ここからは提案した2つの案の実現方法についてご紹介します。

リソース切り替え方式による「確実なフォールバック」の実現

Azure Load BalancerのバージョンをBasicからStandardへ変更する際、現状のBasicバージョンと同じIPアドレスを持ったStandardバージョンのAzure Load Balancerは作成できないため、Basicバージョンを消して再作成が必要となります。しかし、単純に今のリソースを消して新しいリソースを作成する方法だと、何か問題が発生して戻さなければならない場合に、完全に元のリソースに戻すことは不可能となります。

そこで、今回は前のリソースを消す前に事前に新しいリソースを作成しておいて切り替える方法を採用しました。具体的には、元のリソースに紐づくプライベートIPアドレスを任意のIPアドレスに置き換え、元のリソースに使用されていたIPアドレスとバックエンド情報を新しく作成したリソースへ付け替えるという方法です。

こちらの方法の場合、もし戻さなければならないことになっても環境に残っている移行前のリソースに再度付け替えれば良いだけとなります。
そのため、Azure上の構成上の戻しだけではなく、元々使用していたリソースごと完全に戻すことが可能となりました。

スクリプト化による「通信断時間の劇的な短縮」とミス防止

前述した移行方式を全てAzure Portal上から手動で行うと、IPアドレスを移行前のリソースから切り離してから新しいリソースへ付け替えるまで環境によっては約30分かかってしまいます。この間はバックエンドプールにある仮想マシンへの通信は不可能となるため、24時間365日稼働しているようなシステムにとっては30分の通信断は許容できないため有効な手段ではありません。
また全て手動で対応すると、細かな画面遷移が多くなり値の入力を誤る可能性も高くなります。
そこで、IPアドレスを移行前のリソースから切り離してから新しいリソースへ付け替えるまでの作業を自動的に実施できるようにスクリプトを作成したことで、結果として30分の通信断時間を4分にまで減らすことができました。また、スクリプトを利用することで、作業に関するパラメータ設定を事前に確認するなど作業資源をきちんと用意しておくことができるため、手作業による誤りや見落としも減らすことが可能となりました。

おわりに

今回は、品質を保ちながら安全にお客様環境でリタイアメント対応を行うために実施していることについて実例を用いてご紹介しました。
リタイアメント対応に限らず、お客様環境の維持・保守・構築を担当する方々にとって、安心してお客様に環境を使用していただくためには品質の担保することは非常に重要です。本ブログがAzureを利用される皆様の一助となれば幸いです。