Cloud_RunとOptunaでヒューリスティックコンテスト

Cloud run x Optunaでヒューリスティックコンテストのパラメータチューニング

リポジトリはこちら
https://github.com/threecourse/marathon-cloud-run-public

Transcript

1. Cloud Run x Optunaでヒューリスティックコンの パラメータチューニングをする Daisuke Kadowaki 2021/8/24
2. リポジトリ https://github.com/threecourse/marathon-cloud-run-public （課金リスクがあるので、利用時は注意下さい）
3. 1. モチベーション • ヒューリスティックコンテストでは、 2秒間などで最適な解を返すプログラムを提出する • 焼きなましの温度といったハイパーパラメータをチューニングしたい → Optunaを使用する • スコアはぶれるので、少なくとも10ケース程度の平均はとりたい 例えば、10ケース x 2秒 x 100試行のパラメータチューニングを素直に行う と30分かかってしまう → クラウドに並列化して投げたい
4. 2-1. 環境の選択肢 1. Google Cloud - Cloud Run レスポンスが早く、スケールするため、今回の目的には適している 2. Google Cloud - AI Platform Training 起動までの時間が重いため、機械学習などの重いタスク向け 3. Google Kubernetes Engine 何もわからない・・ 4. ローカル実行 時間がかかる。計測がぶれるので、その間他のプログラムを下手に動かせな い
5. 2-2. Cloud Runとは https://cloud.google.com/run/?hl=ja • Google CloudのDocker Imageをさくっとデプロイできるサービス • 自動でスケールする • 起動している時間だけ課金される • インスタンスの性能は弱め （vCPUは最大4、メモリは最大8GB、実行時間は60分まで）
6. 3. 構成 ソースコードはこちら https://github.com/threecourse/marathon-cloud-run-public 3-1. システムの構成とパラメータチューニングの流れ 3-2. Docker Image 3-3. Optunaによるパラメータチューニング 3-4. 解答プログラム
7. 3-1. システムの構成とパラメータチューニングの流れ 1 Cloud Storage Cloud Run 1. Cloud Storageに 解答プログラムのソースコードをアップロードする 以下をOptunaを用いて繰り返し実行する： 2. Cloud Runに入力ケース・ハイパーパラメータの 情報を含むリクエストを送信する 3. Cloud Runは、Cloud Storageからソースコードを ダウンロードする 4. Cloud Runは、計算を行い結果をレスポンスとし て返す 2 3 4 Optunaで繰り返し実行
8. 3-2. Docker Image • Docker ImageでREST APIを提供するWebサーバを立てる • サーバでは、以下の処理を行う 1. 入力ケースやハイパーパラメータをリクエストとして受け取る 2. GCS（Google Cloud Storage）から解答プログラムをダウンロードする 3. 解答プログラムを実行し、計算結果をレスポンスとして返す
9. 3-3. Optunaによるパラメータチューニング https://optuna.org/ • Optunaは、ハイパーパラメータ最適化フレームワーク • パラメータの探索空間、試行回数、スコアを返す関数を定義すると、 いい感じのパラメータを返してくれる • 今回の方法では、スコアを返す関数は、 「Cloud Runにリクエストを投げ、そのレスポンスからスコアを取得して返す」 関数となる • テストケースは、 並列でCloud Runにリクエストを投げることで、時間を節約できる。 • 試行は、並列に行うことは可能だが、それまでの結果を用いて良さそうなパラメ ータを探索するため、並列数を増やし過ぎると良くない。10並列程度にしている。
10. 3-4. 解答プログラム • 与えられた課題にできるだけ最適な解を作成し、 そのスコアを返すプログラム • 引数で開発環境かコンテストの提出環境かを判別するようにする • 開発環境では、 入力として、入力ケース、ハイパーパラメータを受け取る 出力として、スコアなどをJSONで出力するようにする • 提出環境では、AtCoderなどの入力・出力に合うようにする
11. 4-1. 使用感 • AtCoder Heuristics Contest 003で使用。結構快適だった。 • 本当は短時間コンテストの方が優位だが、短時間コンテストでパラメータチ ューニングするところまでいかず、使えていない・・ • 20ケース x 2秒 x 100試行で計算が4000秒かかるところ、 1-2分で返ってくる （各ケースは並列、試行は10並列なので全体で200並列くらい） • 10日のコンテストで2000円の課金になった
12. 4-2. 問題点 • 計算時間の安定性 以前使ったときはたまに計算時間が確保できずスコアが下がる？ → 今回検証すると、稀に15％くらい高速に動くインスタンスがあった → あまり気にしなくて良いかも？
13. 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では感覚的にこの数倍かかった気もするが）
14. 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） → エラー時に何もわからなくなるので、あまりお薦めしない