$30 off During Our Annual Pro Sale. View details »

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

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

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

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

threecourse

March 06, 2022
Tweet

More Decks by threecourse

Other Decks in Programming

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) → エラー時に何もわからなくなるので、あまりお薦めしない