認証付きサーバーレス機械学習の実験管理ダッシュボードの作った！

まとめ

• 機械学習のダッシュボードでVMをずっと立ち上げっぱなしにしたくないので、アクセス時のみインスタンスが立ち上がるGCPのCloud Runというサービスにtensorboardを立ち上げました。
• 立ち上げただけだと、誰でもアクセスできるので認証用のコンテナを別に立ち上げました。
• github actionsを使ってインフラの変更を適用してくれるようにワークフローを組みました。

発端

ウェルモ社内では、機械学習の前処理や実験管理をGCPで行いたいという要望がありました。
AWSにはSageMaker Experimentsなどのサービスがあるので、GCPで類似したサービスがないか調べるとAI Platform pipelinesを見つけました。
ただ、このサービスはGKEを立ち上げる必要があり、今の規模ではコストに見合わないと判断し、できれば使いたくありませんでした。
そんな折に、サーバーレスサービスを組み合わせて、機械学習ワークフローを作ったという記事が公開されました。

https://twitter.com/enakai00/status/1338407033180016645

https://twitter.com/kazunori_279/status/1339510875867103233

githubレポジトリと記事には、我々が目標にしているGKEを使わないワークフローの内容が書かれていましたが、学習結果を可視化する部分がなかったので、今回作ることにしました。

やりたいこと

• 機械学習の実験結果をチームで共有するため、Mlflowやtensorboardをクラウド上に立ち上げたい。
  • 利用状況を考えると、結果を確認時以外には利用しないので普段はインスタンスを落としておきたい。
• 社内（やkaggleなどのコンペ）で結果を共有する場合に、チームメイト以外からのアクセスを避けたいので、認証機能を付けたい。

作成物

コードはこちらです。

作成物は上記のような構成で作成しました。Pomeriumでユーザー認証をOauth認証を用いて行い、GCSに保存しておいた機械学習の実験結果をtensorboardで可視化を行っています。また、インフラの変更時のCI/CDをgithub actionsを使っています。

ここではGCEのようなVMを利用せず、Cloud Runというサービスを利用しています。
Cloud Runはインスタンス数をゼロにスケーリングする機能があるため、普段はインスタンスを立ち下げて、コストの削減ができると思っています。^[1]

Cloud　Run利用時に、GCPの認証サービスであるIAPが使えなかったので、Pomeriumを使ってCloud Run上にOauth認証サービスをデプロイしました。
googleアカウントやgithubアカウントを使って認証可能です。

最後に、インフラ構成やダッシュボードのアプリを変更するたびに手動でデプロイするのが嫌だったので、terraformでインフラをコード化し、ワークフローが動くようにgithub actionsで整えました。

Cloud Run?

GCPのサービスで、コンテナをサーバーレスで実行してくれるサービスです。
アクセス時にコンテナのアプリケーションが数秒で立ち上がるため、普段はインスタンスを落としておいてコストを削減してくれるすごく便利なものです。^[2]

Pomerium?

Cloud RunではGCPのIAPが使えなかったため、認証周りはPomeriumというOSSを使いました。
Goで書かれているOSSで、機械学習用のダッシュボードと認証用のコンテナを切り分けるためにこちらを使いました。^[3]

使い方

githubのREADMEを参考にしてください。こちらに書くと長くなりすぎそうだったので止めました。
ざっくりとは書いていますが、

1. 自分のgithubレポジトリにまるっとコピーする。
2. 認証付きダッシュボードの設定を更新する。
3. github actionsのワークフローを起動するために、github secretsのアップデート
4. terraformの変数をアップデートしてpull requestしてmergeする。
5. GCP上で立ち上がる。

のような感じです。何か質問があればこの記事のコメントかgithubのissueに記載いただけると嬉しいです。
一箇所自動化しきれていない部分があるので、どうすればいいのか一緒に考えてくれる人がいると嬉しいです。

利用時の画面

よく見る認証画面ですね。

よく見るtensorboardの画面ですね。

認証付きtensorboardが動いていることがわかりますね！（わからない）

終わりに

• 本職のインフラエンジニアではない私が２週間ぐらいで根を詰めて作ったものです。色々問題点があると思うので何かあれば指摘していただければと思います。
• だいぶワークフローを整えたとはいえ、データ分析の本職の人が片手間にやるには認証周りが難しいと思います。認証周りがなくていいならすぐできると思います。
• kaggleの実験管理はMLflowを使われる方が多いので、次はMLflowでやってみようと思います。MLflowのkaggleOpsの記事をみるとGCSに保存したデータを読み込んで（コピーして）出力しているのでできそうですね。

認証周りで他に試したOSSなど

• oauth2_proxy
  • 認証でまず出てくるもの。
  • 静的ページの認証に使うには楽そうだが、IPを持ったhttps://localhost:8888などに使うにはCloudRunでは上手くいかなかった。
    • 多分CloudRun自体がk8s上で動いているのに関係ありそう。
  • GAE(Google App Engine)では実験管理のOSS（tensorboard, Mlflowなど）と組み合わせて動くが、この場合にはカスタムコンテナになってしまうため、ゼロにスケーリングせず、コストがかかるため不採用とした。
• vouchをつかったCloudRun認証。https://github.com/karthikv2k/oauth_reverse_proxy
  • 二年前の更新で止まっているためそのままでは使えない。
  • Dockerfileが--from=vouch-proxy:latest /vouch-proxy . → --from=voucher/vouch-proxy:latest /vouch-proxy .に書き換える必要があるが、それでも動かなかった。
• CloudRunの前にロードバランサーを立てて、ロードバランサーにIAP（Identity Aware Proxy: GCPのマネージドOauth認証）をかける。
  • 以下の２点の理由から実現可能性が高いと考えた。
    • httpsロードバランサーにはIAPを設定できる
    • CloudRunにはロードバランサー経由でアクセス可能である
  • 特定IPのアクセスをCloudRunからロードバランサーに常に許可する必要があり、そこまで細かな設定ができなかったため、断念した。

参考文献

• Authorizing end users in Cloud Run with Pomerium
• TensorBoardをGoogle App Engineで使えるようにしてみた

脚注

1. GAEを使ってダッシュボードを作成する手も考えましたが、必要なライブラリを考えるとカスタムコンテナになると判断したため止めています。この記事を書いている時点では、カスタムコンテナはインスタンス数をゼロにスケーリングすることができない認識です。

2. 私はインフラ専任ではないので、詳しい方詳細な資料をいただけると嬉しいです。

3. 私はGoや認証系に全く詳しくないので、記載に誤りがあれば訂正いただけると嬉しいです。