普段Azure Machine Learning(Azure ML)を用いて機械学習関連の開発業務を行っています。
いつものようにブラウザからStudioにアクセスして、Computing Instanceを起動させようとしたところ起動に失敗してしまいました。
起動しなくなった原因
Computing Instanceを作成してから大分日が経っていたことが原因だと考えられます。
といっても1年以上放置していたわけではなく、今回は作成してから9か月経った時点でダメになりました。
このような仮想マシンは作成した時点では最新ですが、以後は自動的に不具合修正やセキュリティ更新プログラムの適用がされることはないようです。
これが積み重なり、不具合が発生して起動しなくなる事態に発展するわけですね。
対処方法
起動しなくなったVMはもうどうしようもなく、削除して再作成するほかありません。
当然、再作成後のVMには以前インストールしたPythonのパッケージが残っているわけもないため、
環境の再構築が必要になります。面倒ですね。
(Experimentをきちんと立てて実行するだけならVM自体の環境が汚れていくことは無いのですが、
適当にNotebookからPythonを実行する際に足りないパッケージをインストールしていくことでこうなってしまうのです)
環境構築の簡略化
環境の再構築の面倒さが増す原因になるのが、何を「pip install」「conda install」したか分からないということ。
というのも私は複数のプロジェクトで同じconda環境を使いまわしており、何か新しいパッケージが必要になるたびに
継ぎ足し継ぎ足しでインストールしていました。
そのため、適切にパッケージ管理が出来ておらず、VMが起動出来なくなった段階でこれまで積み上げてきた
秘伝のパッケージ達がパァになったわけですね。(猛烈に後悔しております)
これを防ぐためには、何をインストールしたのかきちんと管理してやる必要があります。
方法1 conda環境の管理
まず思いついたのが新規プロジェクト立ち上げ時には新たなconda環境を作成するということです。
「conda create」する際にはymlファイルにinstallするcondaパッケージやpipパッケージを記載することが出来ます。
このymlファイルを軸にパッケージの管理をしてやれば、きちんとファイルが残っているので焦る必要は無くなります。
ただし、後々新規パッケージが必要になってもymlファイルに追記してconda環境を作り直すしか無さそうなのが面倒です。
(ここをもっと簡単にする方法をご存知の方 教えてください！)
方法2 Notebookからの実行をやめる
先ほども書きましたが、そもそもNotebookから実行しなければ適当にパッケージをインストールして訳が分からなくなることは無くなるでしょう。
つまり、training実行時にきちんとExperimentを呼び出して実行すれば、そのソースコード等にインストールするpipやcondaパッケージ、あるいはDocker Containerの内容が残されるはずです。
とりあえず試してみるハードルが高くなってしまう、Experimentの立ち上げから実行まで時間が掛かる等のデメリットはありますが、文書としてきちんと管理出来ることのメリットは大きいはずです。
最後に
今回、きちんとパッケージ管理をしておくことの重要性を思い知られました。
クラウド開発に対する知識不足が招いてしまった事態ですが、これを教訓として運用方法を考えていかないといけないですね。
皆さんもご注意ください…。