「全自動パラメータチューニングさん」は何であって何でないのか

発表資料: 全自動パラメータチューニングさん // Speaker Deck

ソースコード: https://github.com/mirakui/tuningsan

これは何なのか

ハッカソンイベント「Open Hack Day Japan」にて、24時間の制限の中で開発し、90秒でプレゼンテーションした作品です

2013/2/16〜2/18 にかけてヤフー株式会社で開催された、「Open Hack Day Japan」という大規模ハッカッソンイベントで開発しました。 上記のプレゼンテーションは発表で使用したものです。

Open Hack Day Japan - Yahoo! JAPAN

本作品は、全参加作品の中で唯一のコマンドラインツールであり非常に地味でしたが、ありがたいことに KLab賞をいただくことができました。どうもありがとうございます。

指定した1パラメータの自動調整によって、特定の1メトリクスを最大化することを目的としたものです

発表では、Unicorn の worker_processes をチューニングすることによって request/sec を最大化するという例を紹介しました。

どんな仕組みなのかは、上記の発表資料に加えて、以下の設定ファイルの記述例を見ていただくとにわかると思います。

以下はチューニング対象となる Unicorn の設定ファイルで、eruby 形式のプレースホルダが書かれています。

# https://github.com/mirakui/tuningsan/blob/master/example/config/unicorn.conf.erb
pid "/tmp/unicorn.pid"
listen 8080
worker_processes <%= worker_processes %>

そして、チューニングさん自体の設定ファイル（"プラン"と読んでます）が以下です。

# https://github.com/mirakui/tuningsan/blob/master/plans/demo_unicorn.yml
---
parameters:
  worker_processes:
    min: 1
    max: 100
agent:
  type: unicorn
  drb_uri: 'druby://127.0.0.1:8787'
  target_config:
    src: example/config/unicorn.conf.erb
    dst: example/config/unicorn.conf
    reload_command: 'kill -HUP `cat /tmp/unicorn.pid`'
benchmark_command: ab -c 100 -n 1000 http://127.0.0.1:8080/ 2>/dev/null | grep 'Requests per second' | ruby -ne 'puts $_[/\d+\.\d+/]'

「パラメータを変更してミドルウェア再起動してベンチして…」の面倒なサイクルを自動化したものです

上記のプランファイルを見ていただくとわかると思いますが、プランには、「どうやってベンチマークをするか」「どうやって設定ファイルを再読み込みするか」ということが書かれています。

チューニングさんの仕組みは、この設定に書かれた通りのベンチマークを実行してメトリクス（この場合は request/sec）を標準出力から取得して記録し、パラメータを変更しつつそれを何サイクルも実行して最適値を決めるという非常に単純なものです。 コードも400行強ほどしかありません。

デモ効果を狙い、プレゼンテーションは大げさな表現が含まれています

タイトルの「全自動」は誇張表現ですが、適切な設定を記述し、チューニングを開始したあとは全自動です。 全自動洗濯機だって、洗剤を入れたり、洗濯物をネットに入れたりするオペレーションは必要ですよね… コミットログが汚いのは時間勝負だったためです、すみません。

デモ作品ではありますが、このまま業務に投入できるツールです

個人的にはこのまま自分の業務に使っていけると考えています。 よく使うミドルウェア毎にプランを用意しておけば、性能の異なるサーバにミドルウェアを入れた時のセットアップの手助けになるはずです。

何でないのか

最適なベンチマークを行なってくれるものではありません

上記のとおり、どのようなベンチマークを行うかは自分で決めなくてはなりません。 ベンチマークツールも別途用意する必要があります。

チューニングするべきパラメータやメトリクスを見つけてくれるものではありません

最適化したいメトリクスがスループットなのか同時接続数なのか処理速度なのか、それとも別のものなのか、人間が決める必要があります。 また、どのパラメータがボトルネックなのかもチューニングさんは探してはくれません。

真理ですね。

1パラメータのチューニングしかできません

いまのところ、1パラメータのチューニングにしか対応していません。 パラメータが複数存在すると、当然、組み合わせが爆発するからです。 制御工学や数値解析や機械学習に詳しい方、 pull request をお待ちしております。

なお、経験上、チューニングさんのアルゴリズムにおいて、1パラメータのチューニングでは局所最適解に陥ることはほとんど無いと思います（グラフの山は1つになることが多いため）。

最後のスライドに登場する男性のようにモテることを保証するものではありません

自動化の素晴らしさを強調するためにモテモテの男性の写真を用いましたが、効果には個人差があります。

我々の職を奪うものではありません

本当に職を奪うイノベーションであれば、開発する前に未来からターミネーターが派遣されてきて今頃僕はこの世にいないでしょう。

最後に

発表資料について、インターネット上で多くの反響をいただくことができました。 何人かの方から大きすぎる期待をいただいていたので、このようなネタばらしをすると「なんだこんなもんか」と感じたかもしれませんが、こんなものです。 チューニングはまだまだ職人芸が必要な領域であることに間違いはないのですが、短調作業の部分はこんなふうに自動化する余地があるよねという提案がこの作品のテーマでした。

個人的には業務で使うために作ったので、チューニングの道具の一つとして使いつつ磨いていきたいと思います。

最後に、ヤフーの伝統あるイベントであり、僕が在職している時からお世話になっていた素晴らしい Hack Day をついに社外に開いてくれた運営スタッフの皆様にはお礼を申し上げます。