MLflow：Tracking・Tracing・Registry・成果物 accessを別の運用境界として管理する

MLflowは、実験・runの追跡、modelやartifactの管理、Model Registry、GenAI向けTracingなどを一つの基盤で扱えるOSSのAI/ML運用基盤である。運用では「MLflow serverを置いた」こと自体を統制成立とみなさず、Tracking Server、backend store、artifact store、Model Registry、trace/telemetry、認証・認可、外部LLM/APIへの接続を別の境界として設計する。

2026-10-22時点の公式documentationでは、Tracking ServerはUIとREST APIを提供し、metadataはbackend storeへ、model weightや画像・データ等の大きなartifactはartifact storeへ保存する。既定backendはSQLiteで、file-based backendは後方互換用のmaintenance modeとされている。高並行度のproduction用途ではPostgreSQL/MySQL等のDB backendを検討し、schema migration前にはbackupを取る。

Tracking Serverはrun/experiment/model/traceのmetadataをbackend storeへ記録し、artifactは別のartifact storeへ置く。この分離を理解せずにbackup、retention、権限、災害復旧を設計すると、metadataだけ復旧してartifactが欠ける、またはartifactだけ残ってlineageを失う。

運用台帳では少なくとも次を別々に固定する。

• MLflow versionとserver configuration
• backend store URI、DB engine/version、migration state、backup/restore手順
• artifact storeのbucket/container/path、credential principal、encryption/retention
• Registry/experiment/workspaceの論理境界
• network exposure、TLS終端、allowed hosts/CORS、authentication/authorization
• trace payloadの保存先、export先、retention、機密情報の扱い

MLflow Tracking Serverはartifact accessをproxyできる。--artifacts-destination を使う構成ではclientはTracking Server経由でartifactへアクセスでき、server側credentialが使われる。一方、--default-artifact-root と --no-serve-artifacts を使う構成ではclientがstorageへ直接アクセスし、client側にstorage credentialが必要になる。

この差は単なるperformance設定ではなく、credential boundaryである。proxy構成ではTracking Serverがアクセス可能なartifactへの権限が集約されるため、server compromiseや過剰権限のblast radiusを評価する。direct構成では各client principalへ必要最小権限を付与し、credential配布・rotation・失効を管理する。

既存experimentは作成時のartifact locationをmetadataとして保持するため、後からproxy modeへ切り替えても既存experimentが自動的に新経路へ移行するとは限らない。migration時は新旧experimentのartifact URIと実アクセス経路をreadbackする。

MLflowはbasic HTTP authentication用のauth appを提供し、experiment、registered model、scorer等へのaccess controlを構成できる。公式Tracking Server文書は、productionでTLS/HTTPSやproxy authenticationを付加するためreverse proxyやVPNを推奨している。

したがって、MLflow内のuser/permissionだけをinternet-facing serverの完全な防御境界とみなさない。少なくとも次を分離して確認する。

• internet/VPC/LANからの到達範囲
• TLS terminationとcertificate更新
• reverse proxy / IdP / VPN等の外周認証
• MLflow内resource permission
• backend DBとartifact storeのservice credential
• admin password/secret key/token等のsecret管理

--host 0.0.0.0 で外部公開する場合は、--allowed-hosts と --cors-allowed-origins 等のsecurity settingを明示し、実際のreverse proxy経路からnegative testする。

MLflow TracingはOpenTelemetryと互換で、MLflow ServerはOTLP /v1/traces endpointを提供する。またMLflow SDKからOTLP backendへtraceをexportでき、dual exportも構成できる。

traceにはprompt、model input/output、tool引数、retrieved context、user identifier、error、metadata等が入り得る。そのため「observabilityだから安全な付帯情報」と扱わない。instrumentation開始前に、何をspan attribute/eventとして記録するか、redaction、sampling、retention、export先、tenant/experiment分離を決める。

OTLP exporterのheaderへAPI key等を渡す構成では、そのsecretの環境変数・deployment manifest・process dump・debug logへの露出も監査対象にする。dual exportを使う場合はMLflow側と外部observability backend側の両方に同じtraceが残り得るため、削除・retention・DSR等の運用を二重に確認する。

Model Registryはmodel versionを識別・管理するための機構であり、登録されていること自体は組織の品質承認や本番投入承認を意味しない。production promotionでは、exact model/version、artifact digest、evaluation結果、approval記録、serving deploymentとの対応を別のcontrolとして残す。

model URIやalias等の参照を使う場合、mutableな参照先の変化を考慮し、release時には最終的に解決されたimmutable artifact/versionを記録する。rollback時も同じartifactへ戻れることを確認する。

database-backed storeではMLflow serverが古いschemaに対して起動できない場合があり、公式documentationはmlflow db upgradeと事前backupを案内している。upgradeをapplication image更新と同一視せず、次の順序をrunbook化する。

• current MLflow version、DB schema、plugin/driver compatibilityを固定する。
• backend DBとartifact storeの復旧可能なbackup/readbackを取る。
• stagingまたはcopyでmigrationを検証する。
• schema migrationを実行する。
• server起動後、run/experiment/model/trace/artifactの代表fixtureをreadbackする。
• rollback不能なmigrationが含まれる場合は、復旧点をDB backup側へ置く。

• metadata DBは復旧したがartifact storeが欠損し、run/model lineageが壊れる。
• proxy artifact modeのserver credentialが過剰権限で、server compromise時に広範囲のartifactへ到達できる。
• direct artifact modeでclient credentialが端末やCIへ拡散する。
• reverse proxyだけ更新してMLflow側permissionを確認せず、resource isolationが崩れる。
• traceへprompt、PII、secret、retrieved confidential dataが保存され、別のobservability backendへも複製される。
• MLflow upgradeでDB migrationが必要なのにbackup/readbackをせず、復旧不能になる。
• mutableなmodel参照だけをdeployment recordへ残し、後からexact artifactを再現できない。
• artifact serving mode変更後も旧experimentが旧URIを保持し、想定外のcredential pathを使い続ける。

• server image/package version、config、plugin、DB driverをpinし変更履歴を残す。
• backend DBとartifact storeを別々にbackupし、復旧演習で相互整合をreadbackする。
• productionではnetwork exposure、TLS、reverse proxy/IdP、MLflow permissionを多層で管理する。
• artifact proxy/direct方式を明示し、service/client principalをleast privilege化する。
• admin password、CSRF secret、DB credential、object-store credential、OTLP header secretをsecret managerへ置きrotationする。
• trace instrumentationにallowlist/redactionを設け、prompt/output/tool/retrieval dataのretentionを明示する。
• model promotion時にexact version/artifact hash/evaluation/approval/deploymentを紐づける。
• upgrade前後にrepresentative run、artifact、registry、traceをreadbackする。
• server、DB、artifact store、OTLP exporterの監査logを相関できるidentifierで残す。

MLflowの標準機能だけで組織のIAM、network perimeter、secret management、data classification、backup、legal retentionが自動的に完成するわけではない。逆に、reverse proxyや外部IdPを導入しただけでもMLflow resource permissionやartifact credentialが自動的にleast privilegeになるわけではない。

artifact proxyはclient credentialを減らせる一方、server credentialへ権限が集約される。direct accessはserverのartifact data pathを外せる一方、client credential配布面が広がる。どちらが安全かはdeployment topologyと組織のIAM設計による。

OpenTelemetry互換性は観測先の選択肢を増やすが、trace dataの機密性やretentionを保証するものではない。

• hosted MLflow serviceや各cloud/managed integrationでは、標準OSS serverとは異なるIAM、network、retention、backup、SLAが追加され得る。
• plugin、custom auth、custom artifact repository、reverse proxy構成では標準documentation以外のfailure modeが生じ得る。
• current deploymentで既存experimentがどのartifact URIを保持しているかは、構成ファイルだけでなく実metadataのreadbackが必要である。
• trace payloadに含まれる機密情報の範囲はinstrumentation対象libraryとapplication codeに依存するため、実trace sampleの監査が必要である。

MLflowはTracking、Registry、Tracing等を統合できるが、運用上はTracking Server、backend store、artifact store、authentication/authorization、trace export、model promotionを別の境界として管理する。artifact access方式やtrace export先によってcredential/data boundaryが変わるため、configurationだけでなく実際のURI、principal、保存先、permission、代表fixtureをreadbackして確認する。