GKE (+ Ingress) もしくは App Engine Flexible Environment に加え Cloud IAP を利用すると、限定公開の MLflow Tracking Server を楽に構成できる。 この記事では、構成が容易な後者の AppEngine FE を利用した方法を紹介する。
目的と前提
- Cloud IAP を利用して MLflow Tracking を楽にそこそこ安全に(not 安価に)動かす。
- MLflow Tracking のバックエンド DB は CloudSQL、Artifact store は GCS とする。
- MLflow 1.9.1 で確認。AppEngine FE のためのコンテナイメージの Python は 3.6.x。
今のところ自分の所属するプロダクトでは、Dataflow の GKE クラスタしか動いていないので、今回は GKE ではなく App Engine FE で済ませた。
※ここでの「セキュア」という表現について
パブリックなインターネットに晒すにあたり、HTTPS 対応と IAM による認証ができることが最低限の条件だとする。
ここでは扱わない内容と他の方法
- GCP を使わない方法
- GKE (Ingress) + Cloud IAP でやる方法
- MLflow 自体に手を入れる方法
- Cloud Run + Cloud Endpoints を使う方法
- Cloud IAP は今のところ CloudRun には対応していないので、Endpoints を利用することになりそう。
- Endpoints (Extensive Service Proxy beta 2 が CloudRun では使える。Envoy ベースの Proxy)
- OpenAPI の定義があれば、よしなにしてくれるらしい
- が、MLflow の REST API に swagger.yaml はない様子で、ProcolBuffers で定義されているだけだった ( mlflow/protos)
本編
サービスアカウントを作成する。以下のようなロールがあれば十分かも。
環境変数の設定
クライアントを利用するときに、Cloud IAP の OAuth2 Client ID とそれに対応した Token を、Service Account の権限で取得する。
自分の場合、Optuna や LightGBM などの Callback 内で MLflowClient
を利用することが多いので、以下のような関数を MLflow Tracking API をコールする前に実行して、MLFLOW_TRACKING_TOKEN
を更新するようにしている。
仕組み
MLflow 1.9 時点では、認証方式として BASIC 認証と Bearer Token による認証が利用できる。
公式ドキュメント にあるとおり、これらは MLFLOW_
Prefix の環境変数に与えることで利用できる。
上記の例で、MLflow Tracking Server の API をコールするたびに自前で Token を取得しているのは、MLflow 側に Token の更新処理が実装されていないため。
付録
app.yaml
の例
liveness_check
,readiness_check
には、MLflow の/health
エンドポイントが使える。- バックエンド DB として CloudSQL のインスタンスを指定できる。
Dockerfile
- AppEngine FE では、
app.yaml
と同じディレクトリにあるDockerfile
から、ランタイムイメージを Cloud Build でビルドして利用するので、これも必要。 - 下記の段階では、
python3
コマンドは Python 3.6 だった。
entrypoint.sh
- AppEngine で動かすので、8080 番ポートを使用する。