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
   

   View Slide

2. リポジトリ
   https://github.com/threecourse/marathon-cloud-run-public
   （課金リスクがあるので、利用時は注意下さい）
   

   View Slide

3. 1. モチベーション
   ● ヒューリスティックコンテストでは、
   2秒間などで最適な解を返すプログラムを提出する
   ● 焼きなましの温度といったハイパーパラメータをチューニングしたい
   → Optunaを使用する
   ● スコアはぶれるので、少なくとも10ケース程度の平均はとりたい
   例えば、10ケース x 2秒 x 100試行のパラメータチューニングを素直に行う
   と30分かかってしまう
   → クラウドに並列化して投げたい
   

   View Slide

4. 2-1. 環境の選択肢
   1. Google Cloud - Cloud Run
   レスポンスが早く、スケールするため、今回の目的には適している
   2. Google Cloud - AI Platform Training
   起動までの時間が重いため、機械学習などの重いタスク向け
   3. Google Kubernetes Engine
   何もわからない・・
   4. ローカル実行
   時間がかかる。計測がぶれるので、その間他のプログラムを下手に動かせな
   い
   

   View Slide

5. 2-2. Cloud Runとは
   https://cloud.google.com/run/?hl=ja
   ● Google CloudのDocker Imageをさくっとデプロイできるサービス
   ● 自動でスケールする
   ● 起動している時間だけ課金される
   ● インスタンスの性能は弱め
   （vCPUは最大4、メモリは最大8GB、実行時間は60分まで）
   

   View Slide

6. 3. 構成
   ソースコードはこちら
   https://github.com/threecourse/marathon-cloud-run-public
   3-1. システムの構成とパラメータチューニングの流れ
   3-2. Docker Image
   3-3. Optunaによるパラメータチューニング
   3-4. 解答プログラム
   

   View Slide

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で繰り返し実行
   

   View Slide

8. 3-2. Docker Image
   ● Docker ImageでREST APIを提供するWebサーバを立てる
   ● サーバでは、以下の処理を行う
   1. 入力ケースやハイパーパラメータをリクエストとして受け取る
   2. GCS（Google Cloud Storage）から解答プログラムをダウンロードする
   3. 解答プログラムを実行し、計算結果をレスポンスとして返す
   

   View Slide

9. 3-3. Optunaによるパラメータチューニング
   https://optuna.org/
   ● Optunaは、ハイパーパラメータ最適化フレームワーク
   ● パラメータの探索空間、試行回数、スコアを返す関数を定義すると、
   いい感じのパラメータを返してくれる
   ● 今回の方法では、スコアを返す関数は、
   「Cloud Runにリクエストを投げ、そのレスポンスからスコアを取得して返す」
   関数となる
   ● テストケースは、
   並列でCloud Runにリクエストを投げることで、時間を節約できる。
   ● 試行は、並列に行うことは可能だが、それまでの結果を用いて良さそうなパラメ
   ータを探索するため、並列数を増やし過ぎると良くない。10並列程度にしている。
   

   View Slide

10. 3-4. 解答プログラム
    ● 与えられた課題にできるだけ最適な解を作成し、
    そのスコアを返すプログラム
    ● 引数で開発環境かコンテストの提出環境かを判別するようにする
    ● 開発環境では、
    入力として、入力ケース、ハイパーパラメータを受け取る
    出力として、スコアなどをJSONで出力するようにする
    ● 提出環境では、AtCoderなどの入力・出力に合うようにする
    

    View Slide

11. 4-1. 使用感
    ● AtCoder Heuristics Contest 003で使用。結構快適だった。
    ● 本当は短時間コンテストの方が優位だが、短時間コンテストでパラメータチ
    ューニングするところまでいかず、使えていない・・
    ● 20ケース x 2秒 x 100試行で計算が4000秒かかるところ、
    1-2分で返ってくる
    （各ケースは並列、試行は10並列なので全体で200並列くらい）
    ● 10日のコンテストで2000円の課金になった
    

    View Slide

12. 4-2. 問題点
    ● 計算時間の安定性
    以前使ったときはたまに計算時間が確保できずスコアが下がる？
    → 今回検証すると、稀に15％くらい高速に動くインスタンスがあった
    → あまり気にしなくて良いかも？
    

    View Slide

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では感覚的にこの数倍かかった気もするが）
    

    View Slide

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

    View Slide