Cloud run x Optunaでヒューリスティックコンテストのパラメータチューニング
リポジトリはこちら https://github.com/threecourse/marathon-cloud-run-public
Cloud Run x OptunaでヒューリスティックコンのパラメータチューニングをするDaisuke Kadowaki 2021/8/24
View Slide
リポジトリhttps://github.com/threecourse/marathon-cloud-run-public(課金リスクがあるので、利用時は注意下さい)
1. モチベーション● ヒューリスティックコンテストでは、2秒間などで最適な解を返すプログラムを提出する● 焼きなましの温度といったハイパーパラメータをチューニングしたい→ Optunaを使用する● スコアはぶれるので、少なくとも10ケース程度の平均はとりたい例えば、10ケース x 2秒 x 100試行のパラメータチューニングを素直に行うと30分かかってしまう→ クラウドに並列化して投げたい
2-1. 環境の選択肢1. Google Cloud - Cloud Runレスポンスが早く、スケールするため、今回の目的には適している2. Google Cloud - AI Platform Training起動までの時間が重いため、機械学習などの重いタスク向け3. Google Kubernetes Engine何もわからない・・4. ローカル実行時間がかかる。計測がぶれるので、その間他のプログラムを下手に動かせない
2-2. Cloud Runとはhttps://cloud.google.com/run/?hl=ja● Google CloudのDocker Imageをさくっとデプロイできるサービス● 自動でスケールする● 起動している時間だけ課金される● インスタンスの性能は弱め(vCPUは最大4、メモリは最大8GB、実行時間は60分まで)
3. 構成ソースコードはこちらhttps://github.com/threecourse/marathon-cloud-run-public3-1. システムの構成とパラメータチューニングの流れ3-2. Docker Image3-3. Optunaによるパラメータチューニング3-4. 解答プログラム
3-1. システムの構成とパラメータチューニングの流れ1CloudStorageCloud Run1. Cloud Storageに解答プログラムのソースコードをアップロードする以下をOptunaを用いて繰り返し実行する:2. Cloud Runに入力ケース・ハイパーパラメータの情報を含むリクエストを送信する3. Cloud Runは、Cloud Storageからソースコードをダウンロードする4. Cloud Runは、計算を行い結果をレスポンスとして返す234Optunaで繰り返し実行
3-2. Docker Image● Docker ImageでREST APIを提供するWebサーバを立てる● サーバでは、以下の処理を行う1. 入力ケースやハイパーパラメータをリクエストとして受け取る2. GCS(Google Cloud Storage)から解答プログラムをダウンロードする3. 解答プログラムを実行し、計算結果をレスポンスとして返す
3-3. Optunaによるパラメータチューニングhttps://optuna.org/● Optunaは、ハイパーパラメータ最適化フレームワーク● パラメータの探索空間、試行回数、スコアを返す関数を定義すると、いい感じのパラメータを返してくれる● 今回の方法では、スコアを返す関数は、「Cloud Runにリクエストを投げ、そのレスポンスからスコアを取得して返す」関数となる● テストケースは、並列でCloud Runにリクエストを投げることで、時間を節約できる。● 試行は、並列に行うことは可能だが、それまでの結果を用いて良さそうなパラメータを探索するため、並列数を増やし過ぎると良くない。10並列程度にしている。
3-4. 解答プログラム● 与えられた課題にできるだけ最適な解を作成し、そのスコアを返すプログラム● 引数で開発環境かコンテストの提出環境かを判別するようにする● 開発環境では、入力として、入力ケース、ハイパーパラメータを受け取る出力として、スコアなどをJSONで出力するようにする● 提出環境では、AtCoderなどの入力・出力に合うようにする
4-1. 使用感● AtCoder Heuristics Contest 003で使用。結構快適だった。● 本当は短時間コンテストの方が優位だが、短時間コンテストでパラメータチューニングするところまでいかず、使えていない・・● 20ケース x 2秒 x 100試行で計算が4000秒かかるところ、1-2分で返ってくる(各ケースは並列、試行は10並列なので全体で200並列くらい)● 10日のコンテストで2000円の課金になった
4-2. 問題点● 計算時間の安定性以前使ったときはたまに計算時間が確保できずスコアが下がる?→ 今回検証すると、稀に15%くらい高速に動くインスタンスがあった→ あまり気にしなくて良いかも?
4-3. 料金Cloud Runの料金● https://cloud.google.com/run/pricing?hl=ja● vcpu1個・メモリ0.5GBのインスタンス、4000秒(2秒 x 20ケース x 100試行)のとき、CPU: 4000vcpu/秒=0.096$メモリ: (0.5 x 4000)GB = 0.005$ 程度。リクエストやネットワーキング:データ保存先のリージョンに気をつければ無視して良さそう。(AHC003では感覚的にこの数倍かかった気もするが)
4-4. 課金死のリスクhttps://threecourse.hatenablog.com/entry/2020/07/12/112536● 予想外のCloud Loggingの課金で1万円● 1回の計算は4秒で、その中で5万行くらい標準エラーに出すようにしていた(焼きなましの温度変化を毎回標準エラーに出すようにしていた)● 計算をトータルで2万回くらい投げた● Cloud Runは、デフォルトでは標準出力・エラーをCloud Loggingに投げに行く(https://cloud.google.com/run/docs/logging?hl=ja#container-logs)● そのため、Cloud Loggingの使用量が250GBくらいになった(1行が20byteとするとちょっと多いが、追加情報を付与して飛ばされていると思われる)● 1GBあたり0.5$、250GB使用していたので(250GB - 無料枠50GB)x 0.5$ = 100ドル =1万円対策● 外部プロセスを呼ぶときに、標準出力・エラー出力を出さないようにする(subprocess.DEVNULLを使うなど)● ログの除外の設定をする(https://cloud.google.com/logging/docs/exclusions?hl=ja)→ エラー時に何もわからなくなるので、あまりお薦めしない