バージョンは事実、エイリアスは役割

一言でいうと

レジストリは、モデルファイルを集めておく倉庫ではなく、バージョンとエイリアスで、「今何がサービス中なのか」を1か所で答えさせる仕組みです。

なぜ必要なのか

実験がうまく整理されたら、次の質問が来ます。「それで、今本番で動いているのはどれですか」。意外にも、この質問がいちばんよく詰まります。モデルファイルは、S3のどこかにmodel_final_v3_really.pklとして置かれていて、サービングの設定には、そのパスが文字列で書かれていて、そのファイルがどの実行から出てきたのかは、作った人の頭の中にあります。その人が休暇に入ると、組織は自分のモデルを説明できません。

ロールバックも、同じ理由で難しくなります。デプロイが「パスの文字列を変えること」なら、ロールバックも「パスの文字列を戻すこと」なので、急いでいるときに、誰がどのファイルに戻したのかが残りません。事故のあとにタイムラインを描こうとすると、チャットの記録をあさることになります。

どう動くのか

MLflowのモデルレジストリのドキュメントは、この問題を4つの概念で整理しています(MLflow Model Registry)。

概念	内容
Registered Model	名前を持つモデル1つ。バージョン・エイリアス・タグを持つ
Model Version	同じ名前で登録されるたびに、番号が1ずつ上がる。最初に登録すると1
Model Alias	特定のバージョンを指す、変更できる名前。`champion`のようなもの
Tag	キーと値のラベル。バージョンにも付く(例: `validation_status: approved`)

核心は、バージョンとエイリアスを分けたことにあります。バージョンは、一度作られたら変わらない事実で、エイリアスは、「今この役割を担っているもの」を指すつまみです。本番がmodels:/MyModel@championを見るようにしておけば、デプロイは、エイリアスが指すバージョンを変えることになります。ドキュメントは、この方式について、本番のトラフィックを受けるバージョンにエイリアスを付けて、そのエイリアスを対象にすれば、別のバージョンにエイリアスを指定し直すだけで、サービングの対象を変えられると説明しています。

ここに、リネージ(lineage)が付きます。登録された各バージョンは、それを作った実行やログされたモデルとつながっているので、どのデータとパラメーターで学習したのかをさかのぼれます。前のモジュールで実行を丁寧に書いておいた理由が、ここで回収されます。レジストリは追跡の上に立っていて、追跡が空なら、レジストリもファイルの一覧以上にはなれません。

registry.json   버전 1, 2, 3 …   (변하지 않는 사실)
aliases.json    champion → 2     (지금 누가 그 역할인가)
audit.jsonl     champion 1→2, 2→1 …  (어떻게 여기까지 왔는가)

エイリアスを動かすことには、1つの規律が付いてきます。動かした事実をどこかに書かなければならないということです。エイリアスのファイルだけを見ると、「今championはバージョン2」という現在の状態しかわからず、昨日まで1だったという事実は残りません。そのため、エイリアスの横には、変更履歴がついて回ります。変わる前の値と変わった値、誰がなぜ動かしたのかを1行ずつ積んでおけば、その記録を最初から再生したときに、今の状態がそのまま出てくるはずです。出てこなければ、誰かが記録なしに手を入れたのです。

タグは、エイリアスより軽い目印です。検証を待っているバージョンにvalidation_status: pending、通ったバージョンにapprovedを付ける形で、状態を表します。エイリアスは、1つの役割に1つだけ付きますが、タグは複数付けられるので、自動化が読む条件として使いやすいです。

現場での姿

エイリアスなしで、バージョン番号をサービングの設定に直接埋め込んだチームは、ロールバックのときに、デプロイパイプラインを回し直す必要があります。急ぐほど、そのパイプラインに時間がかかります。エイリアスを使うチームは、同じ状況で指す先だけを変え、その変更が、履歴に1行で残ります。

逆方向の失敗もあります。エイリアスを作りすぎることです。champion、stable、prod、prod-real、prod-newが同時にあると、そのうちどれが本物なのか、誰にもわからなくなります。エイリアスは、役割の数だけ置きます。たいていは、本番1つとチャレンジャー1つで足ります。

3つ目は、バージョンを消す習慣です。失敗したバージョンをレジストリから削除すると、一覧はきれいになりますが、そのバージョンがなぜ失敗したのかも一緒に消えます。次の四半期に、似たアプローチをもう一度試す人が、同じ壁にぶつかります。

4つ目は、レジストリとアーティファクトストアを同じものと思う誤解です。モデルファイルのバイトがどこに置かれるかは、ストアの仕事で、レジストリが答えるのは、「そのバイトが何番のバージョンで、今どんな役割を担っていて、どこから来たのか」です。2つを混ぜると、ファイルを移すたびにデプロイが壊れ、逆に、ファイルはそのままで役割が変わったという事実は、どこにも残りません。ラボでregistry.jsonとモデルファイルを別に置く理由が、これです。

次のクイズで確認すること

バージョンとエイリアスがそれぞれ何を担当するのか、新しいモデルを同じ名前で登録すると番号がどうなるのか、ロールバックがなぜエイリアスを動かすことでなければならないのかを確認します。