概要
某クラウドML Platform上で実行しているGaradioへsshプロキシサーバを介して安定的にアクセスを試みた記録。
経緯
趣味でNVIDIA GPUが利用可能な開発環境インスタンス上でGradioを使用している。
ローカルアクセスが不可のためアクセスにはGradio share optionを使用していた。以下オプションの説明の翻訳。
gradioアプリの公開共有リンクを作成するかどうか。SSHトンネルを作成し、どこからでもUIにアクセスできるようにします。提供されない場合、Google Colabで実行する場合を除き、毎回デフォルトでFalseに設定されます。localhostがアクセスできない場合(Google Colabなど)、share=Falseの設定はサポートされません。
仕組みとしては上記の説明の通り実行環境からどこかのサーバーにssh tunnelを掘ってそのtunnel先にアクセスするための公開共有リンクをいい感じに勝手に用意してくれるものと理解していた。(あやふや)
問題:Gradioのshare linkが切れる
shareオプションは便利ではあったのだがいつの間にかhttpセッションが切れて?止まってしまうという現象が度々発生していた。
切れたタイミングの大半はGradio Statusで障害が発生しているタイミングだった。おそらくtunnnel先のサーバーが安定していないのかと想像。
https://status.gradio.app/
対策:自前のssh tunnel先を構築
現象が発生するとGradioが使用できず結構なストレス&時間を無駄にしていたので対策を決意。
構想としては自前でssh tunnel先としてssh serverを用意してそこにアクセスすればGradio側の障害に巻き込まれずに済むだろうと考えていた。今回は自宅のraspberrypiをssh serverとしたがインターネットからアクセスできるssh serverならこの方法が適応できるはず。
前提条件
- 外部からcloudのVM環境上へのssh接続は不可。
- cloudのVM環境上から外部ssh接続は可能。
- cloudのVM環境上から外部ssh serverに安全にsshできる(公開鍵認証推奨)
- PCからssh serverに安全にsshできる(公開鍵認証推奨)
最終的な接続図
クライアント(PC)側
$ssh -L 8888:127.0.0.1:8888 user@raspberrypi -N -f -v
クラウド側
クラウドの7860ポートをraspberrypiの8888ポートに
ssh -R 8888:127.0.0.1:7860 user@raspberrypi -N -f -v
図の通りのssh tunnelを確立してPCから http://127.0.0.1:8888 にアクセスすることでGradioが安定的に使用できた。
Gradioに起動時に gradio-debug と no-gradio-queueオプションをつける事。
私が利用しているML Platformサービスではngrokなどのssh tunnelingサービスは禁止されている(banされる)とネット上の情報があったが利用規約には明文化されておらずまた今のところこの方法を使用してbanされていない。(念のためsshポートはデフォルト22から変更してる)