弱小大学の研究室における計算機環境の理想と現実

はじめに

これはあくあたん工房GWアドベントカレンダー1日目の記事です．

しがないM2が悲惨なラボ計算機環境をどうにかしたいとあがいている様子です．過度な期待はしないでください．
なおこれは，かなり恵まれた環境で，かなり恵まれた学生が，さらに高望みしているだけの記事です．未だにPCの起動ディスクがHDDだとか，メモリが4GBしかないとか，そういう世界の話はしません．タスクとしては主に軽い深層学習がメインで，MPIを使ってマルチノードで大規模演算！みたいなことはしていません．

理想

プログラムを書いたら，

ワンクリックで，

いいかんじに強いマシンと沢山のGPUで超高速に計算をして，

クラウドにデータをバックアップして，

AIに論文を書いて欲しい！！！！！！！！！頼む！！！！！！！！

はい．最後の一つはともかく，研究者にとって

• 計算機上で行う計算自体はあまり意味がない（場合による）
• できればその部分で時間を取られたくない
• 抽象化された計算機が自分のプログラムを勝手にいいかんじにしてほしい

というのは共通の悩み・願望だと思っています．書いたプログラムをシュッとシームレスに動かす，それだけで良いのですが，現実はなかなかに非常だったりします．そもそも物理マシンがある時点で管理しないといけないですしね．

現実

多くの研究室では，予算の都合上一人一台高スペックなワークステーションを割り当てるのは難しいのではないでしょうか？せいぜい研究室に数台，それなりのスペックのものを用意して共通で使用することが多いのでは．弊研究室もその分に漏れず，それなりのワークステーションをサーバとしてみんながsshで接続し，計算を回しています*1．
ユーザこそ後述するLDAPにとって統一された管理を実現していましたが，各マシンの内部の管理は各代の有識者が思い思いに環境を作っており，完全にカオス．CUDAのバージョンもNVIDIA DriverのバージョンもPythonのバージョンも違う，誰もノウハウを残していないので思い思いに計算を回している，逆に謎の遺産によってなぜか動いている，誰がどのマシンを使っているか分からない…etc トラブルが起こったときに場当たり的に解決している状況が続いていては，再発して当たり前です．いちいちその復旧に追われ，研究がままならなくなっては本末転倒…

他にもハードの問題としてそもそもマシンが古くてよく壊れる，起動しなくなる，動いても遅い，などなど…問題は山積みです．

これはお金のない研究室の都合なのですが，

• 一度に買える計算機の台数が少ない
• しかし数が足りないために毎年購入

→ スペック，CPU・GPUアーキテクチャが全く異なるPCが何台も存在

• 年によって使える予算に差
• 潤沢な年だけマシンのスペックが上がる

→ 特定のマシンに計算が集中

など，管理の問題だけでなく予算の都合による構造的な問題も存在します*2．

加えて研究室のWebサイトやメールなど研究に直接は関与しないサービスを動かすマシンも存在します．この管理も教員や学生がやっており，時間が無駄に……

これらを踏まえ，まずはこれまでの研究室の計算機環境を見ていきます．

今までの環境

以前のサーバ構成

M1からこの研究室に来たのですが，既に環境としてはそれなりに整っているという印象でした．もちろん多数の不安定要素がありましたが，日常のオペレーションについては問題なく，みんなそれなりにやっているという感じでした．しかし，

• どう考えても古すぎるラボの中心となるMac mini
  • メールシステムの認証が要件を満たしていないのかGmailから認証できない
  • 再起動の度に設定が吹き飛んで初期化されるApache
  • もはや誰もわからないOpenDirectory
  • ずっとPHPのバージョン警告が出ているWordPress
• 使いもしないのにWindowsが入っている計算サーバたち
  • システムSSDの空き容量が20GB程度しかない
• ディスプレイにつなぎもしないのにDesktop OSが入っている計算サーバたち
  • 昔は繋いでいたらしいが，サーバとして使っているのにChromeとかLibre Officeとか入ってて邪魔
• 完全に粗大ゴミと化している古い計算マシンたち
• 初期構築以降の環境構築方法を誰も残していないので思い思いにインストールされているCUDAとNVIDIA Driver
• 怪しすぎるセキュリティ

などなど，課題は山積みでした．前から早くこのMac miniから乗り換えたいよねという話はしていたのですが，やはりなかなか難しく，腰が重かったことは言うまでもないでしょう．しかし僕ももうM2になってしまう，出来る人間が出来るうちにやらないと手遅れになる，という危機感から，春先より気合いを入れて移行を始めました．

新しい環境への移行にあたって

完璧を目指すことは最初から諦めていました．そんなにスキルレベル高くないです．しかし，自分は卒業してしまう身なのでどうにかノウハウだけは残す必要があります．オレオレシェルスクリプトを残すよりはという気持ちで，今回はAnsibleを利用しました．また，

• 完全自動化は諦める
• ぶっ壊れない環境を作るのでは無く，ぶっ壊れた環境を躊躇無く消し飛ばしてできるだけ早く復旧できるようにする
• 全て自力で解決しようとしない

のようなポリシーでPlaybookを組み，無理なところはおとなしく手動オペレーションでいいやという気持ちになることで，自分の中のハードルを下げています．

結果から言うと

• OSのインストール・IPアドレスの固定までは手動（逆に言うとそれ以降は全て自動化）
• 計算用マシンについては途中トラブってもOSのインストール含め概ね30分〜1時間以内に復旧できる
• 金でなんとかなるものはなんとかした（NASを買った）

という感じです．かなり頑張った．

新しい環境

新しいサーバ構成

まず，ストレージ周りを全てNASに押し付けて解決を図りました．自分で頑張ってRAID組んで壊れたら復旧させて…とか面倒臭いので，ここはお金で解決*3．

これまでのMac Miniの代わりに，計算以外のタスクを担うサーバとして富士通のPRIMERGY TX1320M3を購入してもらいました．4コアXeon，16GBメモリ，1TB HDD×2（RAID1）でまぁ困らないくらいのスペックかなと*4．これに

• OpenLDAP
  • ユーザ情報の統一管理．LinuxのPAMから参照してログイン・メール等からも利用
  • ユーザの作成等もAnsibleでPlayBook化．かなり無理矢理
  • https://galaxy.ansible.com/pddg/ldap_server
• Postfix/Dovecot
  • IMAPS/POP3S/SMTPSを吐くメールサーバ
  • https://galaxy.ansible.com/pddg/dovecot
  • https://galaxy.ansible.com/pddg/postfix
• apt-cacher-ng
  • apt install高速化のためのキャッシュサーバ．
  • クライアント側もセットアップ．HTTPSの通信は無視．
  • https://galaxy.ansible.com/pddg/apt_cacher_ng
• Nginx + Certbot + MySQL + PHP（WordPress）
  • ac.jpもLet's Encryptなんだっていう驚きが少しあった
  • 元はApacheでしたが好きじゃないのでNginxに
  • https://galaxy.ansible.com/nginxinc/nginx
  • certbotは自作Role．MySQLも自作RoleでDockerコンテナとしてデプロイ．要望があればオープンにします．
• AutoFS
  • NFSのマウントに使用．自作Role．
• SSHD
  • 簡単な設定だけ
  • https://galaxy.ansible.com/pddg/sshd_config
• Docker
  • https://galaxy.ansible.com/geerlingguy/docker
• Docker registry + Portus
  • DockerHubのミラー用プロキシとして使用してサーバごとのpullを高速化したい
  • 間に合わなかったのでGW中にやりたい
• Avahi-daemon
  • systemd-resolved + systemd-networkdでmDNSがうまく有効にならない…

など，その他いろいろ細かい設定をするRoleを書いて実行しています．当然OpenLDAPもPostfixもDovecotも触ったことないので一から調べました．未だにOpenLDAPはよくわからない．続いて計算機も

• Docker
  • 上に同じく
• NVIDIA Driver + nvidia-docker2
  • 自作Role．
  • Ansibleのrebootモジュールを使ってドライバのインストールは全て自動
• Neovim
  • 趣味と実益を兼ねています
  • https://galaxy.ansible.com/pddg/neovim
• AutoFS
• GPUデバッグコンテナ
  • Dockerでの実行に慣れていない人，Dockerfileを書く前にGPUで動くかの簡易チェックをしたい人等に公開している，SSHログインできるコンテナ．
  • LDAPの設定をホストからマウントしてLDAPユーザでログイン出来るように
  • GitHub - pddg/sel-gpu-debug-container: Interactive CUDA container image for debugging
• Sigularity
  • DockerではPermissionの問題がある（プロセスがrootとして動作する）
  • まだちゃんと試せてないので未導入

という感じで整備．まだSingularityの導入で変わるかも知れませんが，基本的にはユーザの善意を信じて大きくパーミッションを与え，Dockerでの実行をサポートしています*5．nvidia-docker2は容易にCUDAのバージョンを切り替えることが出来るので，他人とバージョンが違っても安心なのがとても良いですね．Dockerの学習コストは少し高いですが，クライアントマシンとサーバマシンで環境を統一してデバッグできるので，メリットは十分大きいと考えています．
ワンクリックでサーバ上で実行！とはいきませんが，

1. ローカルで開発
2. ローカルでDockerfileを書いて実行を試す
3. サーバ上でイメージをビルド
4. コンテナを作ってデータセットをマウントし実行

で，少なくとも環境構築の手間はかなり省かれたかなと．

監視

業務用のサーバでもないのに，監視なんて必要なのか？という話なのですが，あった方がいいと個人的には思っています．ディスクの空き容量，CPU・GPU・メモリの使用状況等，いちいち自分で確認しに行くよりもWebUIから確認，自動でアラートするなどやっておいて損することは無いと思います．余っていた古いXeonマシンがあったのでこいつでいいやと突っ込むことに．監視ソリューションのOSSとしては

• Zabbix
• Nagios
• Prometheus

他に一部無料枠として

• Mackerel

等がありますが，

• 僕自身に運用経験があった*6
• AlertManagerの通知先としてSlackがサポートされていた*7
• GrafanaのUIが使いやすい

等の理由から，Prometheus + Grafana + Alert ManagerをDockerを用いてデプロイしています（全てAnsibleでプロビジョニング）．各サーバに

• Node Exporter：ホストの様々なメトリックを取得
• cAdvisor：Dockerコンテナに関するメトリクスの取得
• DCGM Exporter：GPUがある場合に導入．GPUに関するメトリクスが取れる

等を入れ，監視サーバから叩いています．各ホストに関するメトリクスを簡単にまとめてダッシュボードを作成．以下の様な感じで提供しています．どのサーバがどういったスペックなのかもここで確認できる様になっています．

Grafanaのダッシュボード（自作）

アラートも設定しており，例えば10分以上ダウンしていればSlackに通知が来ます．

Alert ManagerからSlackへのアラート

アラートはもっと拡充していきたいなと考えていますが，優先度が低いのでまだ後回しになっています．誰か手伝って．

情報共有・記録

これはステマですが，弊研究室はWikiシステムとしてesa.ioを導入しました．

esa.io

そもそもサークルでアカデミックプラン*8を知って使い始めたのですが，使いやすい，デザインが見やすい等かなり良いです．これまではMDWiki.jsを使用していたのですが，

• Gitでcommit・pushしないといけない
• PushしたときにWeb上に自動で反映させる独自hookが大抵上手く動かない
• 上記2点も相まって誰も使ってくれない
• これ本体に認証システムがないのでApacheで特定のパス以下にLDAPを用いたベーシック認証を加えていたが，Nginxだと自前ビルドが必要で面倒臭い．

などの問題があったため，思い切って先生に提案しました．目に見えて利用率は上がりました．みんなもっと気軽に自分の知見書いて欲しいですね．

他にやりたいこと

使用中であることの明示

現在どのマシンをどのくらい使うか，他の作業との共存の可否，使い終わったか等をSlackで自己申告する様にしています．あんまりいけてないので，Alert Managerでｲｲｶﾝｼﾞにならないか考えているのですが，

• Dockerを使うと基本的にプロセスはrootで動く
  • 使用ユーザの特定が難しい
• Dockerコンテナ名は指定しない限りランダムになる
  • コンテナ名で通知しても分からない
• 「使用している」の基準の設け方が難しい

等があり，自動化出来ていません．誰か上手いやり方を知っている人は教えて頂きたい．

自動ジョブ実行システム

現状，何か計算を実行するのはユーザの手動に頼っています．そのため，

Aさん「今日一日使います」
Bさん「あ，じゃあそのあと使わせてください（あ，じゃあ明日やるかぁ…）」

みたいな場合があり得ます．空くのは分かっていても，わざわざ終わるかどうかを監視して終わったらすぐ実行するなんて面倒なこと，締め切り間際でもしない限りやりませんよね？これを

Aさん「今ジョブ投入しました．今日中に終わると思います」
Bさん「その次投入してありまーす（明日の朝には終わってるかな？）」

みたいにできると，日中にひたすら結果待ちをする時間を省けて幸せになれるんじゃ無いかと思っています．ただ，こういうのやったことないのでどうやれば良いのか全く分かっていません．どうやるんだ…？

今後の課題

Ansibleをちゃんと使える後継者を育成することが一番大変そうです．とは言ってもそんなに難しいことはしていないので，ドキュメントをある程度残していくだけで十分（向こう数年くらいは）運用できると思っています．

理想に近づくために

共用計算マシンの整備

まずお金が足りません．重い計算を行うのに，スペックは圧倒的に足りていません．もっとスペックで殴れれば色んなことを試せるんですが，GPUメモリが全然足りていません．これについてはそもそも研究室単位で頑張ることが間違いだと思っていて，学部・大学単位で設備を揃える必要があると思っています．生物系だとたとえば質量分析器や電子顕微鏡等，高価な機材はその学部単位で所有し，各研究室が共同で使用していました．情報工学でもそろそろまともな共有マシン群が欲しい……せめてTesla K80とかが数枚載ったマシンが数台あると大分変わると思うんですが……（ﾁﾗｯﾁﾗｯ

大学側での提供サービスの拡充

研究室Web・メール等は大学側で吸収してくれないかな……と思っています．どちらも別に研究室単位で管理する必要ないですよね？よくガバガバセキュリティでスパムの踏み台にされてる話を聞きますよ？
SMTPはリレーサーバが（おそらくスパム対策で）提供されているのですが，そもそも自分でPostfixの運用をしたくない……
更にLDAPも，大学側がActive Directoryとかで提供してくれると楽になるのにとつらい気持ちになっています．うちではWindowsマシンが一台もない，Mac等は個人が使うのでID統一の必要が無いという条件があるのでOpenLDAPで事足りていますが，Windowsを使う研究室では無理でしょう．あくまで自分の研究室が恵まれているために可能な構成だと思います．

クラウド利用は？

Google Colaboratoryは神．ただし軽いタスクに限る．
大学の予算の使い方の仕様上，従量課金制というのがとてつもなく相性が悪いです．産総研のABCIみたいな一定ポイント買い切り制ならまだ良いかも知れませんが，そもそもラボ内のマシンで四苦八苦している人がクラウドのインスタンスでどうのこうのなんて，理解出来ると思いますか？
無料でトライアンドエラーできるのがオンプレの良いところなのですが，これにお金がかかるとなって，結局「みんな怖がって使わない→クラウドインスタンスがエリクサー化」するのも嫌です．やっぱり学内共用計算マシンと，その使用方法講座みたいなのを実施するのがベストなんじゃないかなぁと．

まとめ

• 大学の計算機環境は様々な事情でレガシーの塊のところも多く，管理者がどんどん変わっていくのでカオス
• 弊研究室では古い環境を一新してAnsibleで全て整備した
• 今後求められるスペックに一研究室で対応するのは大変，大学・学部での共用計算資源で大規模な計算もできるようにしてほしい

お金が欲しいですね．
他の研究室でのプラクティスとか全然聞かないんですけど，みんな一体どうしてるんでしょう？実はみんなOpenLDAPもADも完全に理解してて，分かってないのは僕だけとか？もうみんなKubernetesで機械学習基盤組んでて，ラボメンみんなマニフェスト書けるとか？こういうの入れると良いよとか，こういうフローオススメだよとか，無限に募集しています．よろしくお願いします．

では，明日は弊サー期待の新入生が書いてくれるっぽいので楽しみにしています．ﾖﾛｼｸﾈｰ！

*1:なお，弊研究室は一人一台MacBookが支給され，これをクライアントとして用いています

*2:買えているだけマシという話もある

*3:なお，ここでQNAPを選択したのは完全に失敗でした．NAS上のホームディレクトリとNFSで配信する他のサーバで利用するためのホームディレクトリを一致させると，AFP等でNASにログインしたとき，ホームディレクトリのパーミッションが777に書き換えられ，公開鍵でのsshがPermissionのエラーで弾かれるようになります． https://forum.qnap.com/viewtopic.php?t=123842

*4:SSD 1TB×2はオプションが無かった

*5:sudoできるユーザは限られています．dockerグループにデフォルトで所属させ，sudo無しでの実行をサポートしているだけ

*6:poyo.hatenablog.jp

*7:弊研究室は全てSlack経由で連絡を取り合っています

*8:docs.esa.io

ChainerのEarlyStoppingとOptunaによる最適化

はじめに

前回こんな記事を書きました．

poyo.hatenablog.jp

本当は今回の記事もまとめて1つで公開する予定だったのですが長くなりすぎたので分割しました．

環境

環境は全て前回の記事と同様です．

• Chainer v5.3.0
• CuPy v5.3.0
• Optuna v0.9.0

枝刈りと過学習

当初，Optunaのプレスリリースにあった「学習曲線から、最終的な結果がどのぐらいうまくいきそうかを大まかに予測する」という一文から，「過学習を起こしそうだったら早めに切る」という意味だと誤解していました．実際にはその試行内ではなく，過去の試行との比較を行うため，これは全く意味が異なってしまいます．これに関連したIssueは以下です．

github.com

必要な部分だけ抽出すると，

• Optunaの枝刈りは過学習を検知するものではない
• 過学習を気にするなら，例えばChainerならchainer.training.triggers.EarlyStoppingTriggerを使うように

ということです．

EarlyStopping

これは，モデルの学習の収束を判定するための方法です．何らかの指標，例えばvalidation lossを監視し，train lossは減少し続けるのに対して，validation lossが改善されなくなった場合，学習を打ち切ります．ChainerではTriggerとして実装されています．

    # 1 epochごとにvalidationのaccuracyを監視し，3回以上改善しなければstopする
    early_trigger = training.triggers.EarlyStoppingTrigger(
        check_trigger=(1, "epoch"),
        monitor="validation/main/accuracy",
        patients=3,
        mode="max",
        max_trigger=(epoch, "epoch")
    )
    # `(epoch, "epoch")`の代わりに上記のTriggerを渡す
    trainer = training.Trainer(updater, early_trigger, out='output')

これはあくまで終了するだけなので，学習終了後にそのパラメータを読み出したりはしてくれません．そういうことがしたければ以下の記事が参考になります．

qiita.com

qiita.com

タイミング

適当な値を出しますが，こんな感じのlossの推移があり，

epoch	1	2	3	4	5	6	7	8
loss	100	80	60	40	20	30	25	28

EarlyStoppingTriggerのパラメータとして以下の物を渡したとします．

• patients=3
• mode="min"
• max_trigger=(10, "epoch")

patientsは「最小値からいくつ連続して値が改善しなかった場合に学習を止めるか」というパラメータです．例の場合，最小値は5 epoch目の20です．以降，30 → 25 → 28と値が上下していますが，一貫して最小値20を上回っているため，8 epochで中断されます．
modeには，最小，最大どちらの方向で値を監視するかを設定します．lossならば最小の方向になり，accuracyなら最大の方向に監視することになると思います．デフォルトは"auto"ですが，明示した方がトラブルはないんじゃないかなと思います．
max_triggerは値が改善され続けたときにいくつまで学習するかを設定します．

OptunaとEarlyStopping

Optunaは，あくまでも目的関数が返す最後の値を最適なパラメータの選出に使用します．枝刈りを行っても行わなくても，学習過程で記録した最小値が利用されるわけではないため注意が必要です．これを簡単なサンプルで示してみます．

import optuna

def objective(trial):
    sample_losses = [
        [200, 90, 52, 31, 15, 7, 17, 28, 45, 56],  # A
        [143, 82, 56, 40, 26, 18, 24, 23, 26, 28]  # B
    ]
    losses = sample_losses[trial.number]
    # 途中経過を報告する
    for i, loss in enumerate(losses):
        trial.report(loss, step=i)
    # 最後の値を返す
    return losses[-1]

if __name__ == "__main__":
    study = optuna.study.create_study("sqlite:///test.db")
    study.optimize(objective, 2)
    # 全ての試行のvalueをprint
    print("[Trials]")
    for t in study.trials:
        # Trialの番号，その時の値，値の推移
        print(t.number, t.value, t.intermediate_values)
    # Optunaが選んだbestなtrial
    best = study.best_trial
    print("[Best]")
    print("Number:", best.number)
    print("Value:", best.value)

実行されるTrialの順に応じて異なる数列をOptunaへ報告する目的関数を設定し，これを最適化させてみます．この sample_losses をプロットすると以下の様になります．

sample_lossesの推移

見て分かるように，実際には試行Aの方が6 epochで（epochではないですが便宜上の単位として使います）最も低い値を記録しますが，Optunaは試行Bをbest trialとして選出します．

[I 2019-03-24 23:45:29,729] A new study created with name: no-name-22ecd572-e23d-4ce4-8370-26a12267b372
[I 2019-03-24 23:45:29,830] Finished trial#0 resulted in value: 56.0. Current best value is 56.0 with parameters: {}.
[I 2019-03-24 23:45:29,918] Finished trial#1 resulted in value: 28.0. Current best value is 28.0 with parameters: {}.
[Trials]
0 56.0 {0: 200.0, 1: 90.0, 2: 52.0, 3: 31.0, 4: 15.0, 5: 7.0, 6: 17.0, 7: 28.0, 8: 45.0, 9: 56.0}
1 28.0 {0: 143.0, 1: 82.0, 2: 56.0, 3: 40.0, 4: 26.0, 5: 18.0, 6: 24.0, 7: 23.0, 8: 26.0, 9: 28.0}
[Best]
Number: 1
Value: 28.0

これは嬉しくありません．正しく最も良い値で判断して欲しいところです．そこで，最終的に返す値を変えます．途中経過の値は枝刈りに使われるのみ*1なので，無視できます．

import optuna

def objective(trial):
    sample_losses = [
        [200, 90, 52, 31, 15, 7, 17, 28, 45, 56],  # A
        [143, 82, 56, 40, 26, 18, 24, 23, 26, 28]  # B
    ]
    losses = sample_losses[trial.number]
    # 途中経過を報告する
    for i, loss in enumerate(losses):
        trial.report(loss, step=i)
    # 最小値を返す
    losses.sort()
    return losses[0]

if __name__ == "__main__":
    # 省略

実行してみます．

[I 2019-03-25 00:02:33,012] A new study created with name: no-name-36544734-db8e-4478-83d5-314d3d999c7b
[I 2019-03-25 00:02:33,122] Finished trial#0 resulted in value: 7.0. Current best value is 7.0 with parameters: {}.
[I 2019-03-25 00:02:33,223] Finished trial#1 resulted in value: 18.0. Current best value is 7.0 with parameters: {}.
[Trials]
0 7.0 {0: 200.0, 1: 90.0, 2: 52.0, 3: 31.0, 4: 15.0, 5: 7.0, 6: 17.0, 7: 28.0, 8: 45.0, 9: 56.0}
1 18.0 {0: 143.0, 1: 82.0, 2: 56.0, 3: 40.0, 4: 26.0, 5: 18.0, 6: 24.0, 7: 23.0, 8: 26.0, 9: 28.0}
[Best]
Number: 0
Value: 7.0

このように，結局は目的関数の返す値によって決定されることが分かりました．よってOptunaで最適化する際には，その試行の中の最良の値を返す必要があるように思われます*2．

枝刈りを行う際の更なる注意点として，Optunaは枝刈りした試行についてPRUNEDというステータスで記録しますが，best trialの選出には PRUNED のものは含まれません*3．これは，過去の同じステップと比べて値が悪化しているのだから当然と考えられます．しかし，前述のように，学習の過程でベストな値を取っても，その後改善せずむしろ過学習により劣化した場合に枝刈りされる可能性は依然としてあり，その場合は本来最適であったパラメータが見逃されることになります．

これはEarlyStoppingを用いても抑制はできるでしょうが完全に防ぐことは出来ないと考えています．その仕組み上，最良の値からいくつかぶん学習を進める必要があるため，その長さ（patients）の分だけ枝刈りの可能性が残されてしまうためです．あまり長い patients を設定することは避けるべきかと思います．

実際にやってみた

前回の記事で使用した実験コードに更に手を加える形で実装しました．

全体は以下にあります．

optuna-sample/main.py at 1b7cfccea08b4a2255ff685d931f746ce0de2007 · pddg/optuna-sample · GitHub

    # 省略
    early_trigger = training.triggers.EarlyStoppingTrigger(
        check_trigger=(1, "epoch"),
        monitor="validation/main/accuracy",
        patients=3,
        mode="max",
        max_trigger=(epoch, "epoch")
    )
    trainer = training.Trainer(updater, early_trigger, out='output')

    # 実行中のログを取る
    log_reporter = extensions.LogReport()
    trainer.extend(log_reporter)
    
    # 省略

    # 学習を実行
    trainer.run()

    # Accuracyが最大のものを探す
    observed_log = log_reporter.log
    observed_log.sort(key=lambda x: x['validation/main/accuracy'])
    best_epoch = observed_log[-1]

    # 何epoch目がベストだったかを記録しておく
    trial.set_user_attr('epoch', best_epoch['epoch'])

    # accuracyを評価指標として用いる
    return 1 - best_epoch['validation/main/accuracy']

上記のコードの途中でTrialオブジェクトに対してuser_attrとして最良であった場合のEpoch数を記録していますが，これは後から以下の様にして取り出すことが出来ます．

    print("[Best Params]")
    best = study.best_trial
    print("Epoch:", best.user_attrs.get('epoch'))

これを用いて，枝刈り無し，MedianPrunerによる枝刈り有り，SuccessiveHalvingPrunerによる枝刈り有りの3種類でそれぞれ100回の最適化を行いました．EarlyStopping無しの結果については前回の記事をご覧ください．また，前回から繰り返し書いていますがこれは厳密な時間測定ではなく，なんとなく感覚を掴んでいるだけですので，悪しからず．

枝刈り無し

[I 2019-03-24 15:57:00,465] A new study created with name: prune_test
[I 2019-03-24 15:57:42,481] Finished trial#0 resulted in value: 0.03238105773925781. Current best value is 0.03238105773925781 with parameters: {'n_unit': 36, 'batch_size': 105}.
# 省略
[I 2019-03-24 20:16:07,683] Finished trial#99 resulted in value: 0.022976338863372803. Current best value is 0.018449485301971436 with parameters: {'n_unit': 95, 'batch_size': 37}.
[Trial summary]
Copmleted: 100
Pruned: 0
Failed: 0
[Best Params]
Epoch: 9
Accuracy: 0.9815505146980286
Batch size: 37
N unit: 95

4時間強程度の時間がかかりました．思ったより全然時間を短縮できませんでしたね．今回は最大で20 epoch学習をおこなっているのですが，これが思ったより多すぎなかったということなのでしょうか． とはいえ，Best Paramsを見て頂ければ分かるように，9 epoch目でベストの値をたたき出していることが分かります．

MedianPrunerによる枝刈り

[I 2019-03-24 15:56:47,192] A new study created with name: prune_test
[I 2019-03-24 15:57:31,076] Finished trial#0 resulted in value: 0.02388054132461548. Current best value is 0.02388054132461548 with parameters: {'batch_size': 67, 'n_unit': 116}.
# 省略
[I 2019-03-24 16:29:43,264] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 14
Pruned: 86
Failed: 0
[Best Params]
Epoch: 8
Accuracy: 0.9790022373199463
Batch size: 69
N unit: 125

約30分程度で済んでいます．EarlyStopping無しで行った時よりも多少時間が短縮できているようですが，たまたまかも知れません．こちらもBest Paramsは8 Epoch目と比較的早い段階で収束していることがわかります．

SuccessiveHalvingPrunerによる枝刈り

[I 2019-03-24 15:56:58,310] A new study created with name: prune_test
[I 2019-03-24 15:58:00,723] Finished trial#0 resulted in value: 0.023097515106201172. Current best value is 0.023097515106201172 with parameters: {'batch_size': 61, 'n_unit': 70}.
# 省略
[I 2019-03-24 16:26:50,098] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 8
Pruned: 92
Failed: 0
[Best Params]
Epoch: 9
Accuracy: 0.9769024848937988
Batch size: 61
N unit: 70

30分弱程度で完了しました．やはり枝刈りは強力ですね．こちらも9 Epoch目で学習が収束していることから，今回のサンプルネットワークを用いたMNISTの学習では8，9 epochあたりで十分収束するということでしょうか（もちろん触るパラメータ次第だとは思いますが）．

まとめ

ChainerのEarlyStoppingTriggerは簡単に使えて強力ですので，無意味に長い学習を行って計算リソースや時間を無駄に消費したくない方は是非導入してみてはいかがでしょうか．

また枝刈り有り・無しの場合で，かかる時間と得られる最適化の妥当さのバランスがどうなっていくのか，上記の結果を見る限り同じ100回の最適化でもそれぞれ異なるパラメータに行き着いており，最終的にどこに収束していくのか，気になります．

あとこれはどなたかご存じの方がいらっしゃれば教えて頂きたいのですが，こういった最適化のようなタスク，および実際の学習において numpy.random.seed(0)のようにseed値を固定すべきなのでしょうか．再現性を中途半端に考慮するより最初からランダムにし，複数回行って平均等を見るべきなのでしょうか．

深層学習は難しいですね．

*1:と解釈しているのですが，パラメータのサンプリングに使われたりするのでしょうか

*2:むしろOptunaはなぜ途中で値を報告させる機能を有しているにも関わらず，それらを考慮しないのでしょう．

*3:少なくともv0.9.0ではそうなっています． optuna/base.py at v0.9.0 · pfnet/optuna · GitHub

Optunaによる枝刈りとAsynchronous Successive Halving Algorithm

はじめに

PFNから発表されたハイパーパラメータ最適化ツールOptunaの記事が多数見受けられるようになってきました．Optunaは特に探索中に試行の枝刈りを行うことで，効率の良い探索を行うことができることが目玉の一つです．ここでは特に，Chainerと組み合わせる際の枝刈りの方法と，Optunaの採用する枝刈りのアルゴリズムについてまとめておきます．また，僕自身そこまで詳しいわけでは無いため，厳密な枝刈りによる効率化の度合い，その是非等についてはここでは議論しません*1． Optunaがパラメータの選択に採用しているアルゴリズムに関する情報は以下の記事が大変詳しく書かれています．

qiita.com

環境

• Chainer v5.3.0
• CuPy v5.3.0
• Optuna v0.9.0

実行環境はUbuntu 18.04 LTSで，Docker，Docker-compose，nvidia-docker2を使用しました．また，NVIDIA Driverのバージョンは415.27です．

$ docker --version
Docker version 18.09.2, build 6247962
$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

ハードウェアは以下の通りです．

• Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 10コア20スレッド × 2
• RAM 64GB
• GPU GTX 1080 ti

使用するコード

特にどんなコードでも大差ないため，MNISTを使って例を示します．まず単純に最適化する場合のコードを以下に示します．

import argparse
import functools
import chainer
import numpy as np
import optuna
from chainer import links as L
from chainer import functions as F
from chainer import training
from chainer.training import extensions

# From: https://github.com/chainer/chainer/blob/v5/examples/mnist/train_mnist.py
# Copyright (c) 2015 Preferred Infrastructure, Inc.
# Copyright (c) 2015 Preferred Networks, Inc.
# Network definition
class MLP(chainer.Chain):

    def __init__(self, n_units, n_out):
        super(MLP, self).__init__()
        with self.init_scope():
            # the size of the inputs to each layer will be inferred
            self.l1 = L.Linear(None, n_units)  # n_in -> n_units
            self.l2 = L.Linear(None, n_units)  # n_units -> n_units
            self.l3 = L.Linear(None, n_out)  # n_units -> n_out

    def forward(self, x):
        h1 = F.relu(self.l1(x))
        h2 = F.relu(self.l2(h1))
        return self.l3(h2)

# 目的関数を設定する
def objective(trial, device, train_data, test_data):
    # trialからパラメータを取得
    n_unit = trial.suggest_int("n_unit", 8, 128)
    batch_size = trial.suggest_int("batch_size", 2, 128)
    n_out = 10
    epoch = 20

    # モデルを定義
    model = L.Classifier(MLP(n_unit, n_out))

    if device >= 0:
        chainer.backends.cuda.get_device_from_id(device).use()
        model.to_gpu()

    optimizer = chainer.optimizers.Adam()
    optimizer.setup(model)

    train_iter = chainer.iterators.SerialIterator(train_data, batch_size)
    test_iter = chainer.iterators.SerialIterator(test_data, batch_size,
                                                 repeat=False, shuffle=False)
    updater = training.updaters.StandardUpdater(
                    train_iter, optimizer, device=device)
    trainer = training.Trainer(updater, (epoch, 'epoch'), out='output')

    # validationをするextensionを追加
    trainer.extend(extensions.Evaluator(test_iter, model, device=device))

    # 学習を実行
    trainer.run()

    # accuracyを評価指標として用いる
    return 1 - trainer.observation['validation/main/accuracy']

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument('trials', type=int, help='Number of trials')
    parser.add_argument('-g', '--gpu', type=int, default=-1, help='GPU ID')
    args = parser.parse_args()

    np.random.seed(0)

    # MNISTデータを読み込む
    train, test = chainer.datasets.get_mnist()
    # 目的関数にパラメータを渡す
    obj = functools.partial(objective, device=args.gpu, train_data=train, test_data=test)
    # Studyを作成
    study = optuna.study.create_study(
        storage='sqlite:///optimize.db', study_name='prune_test', load_if_exists=True
    )
    # 最適化を実行
    study.optimize(obj, n_trials=args.trials)

    # Summaryを出力
    print("[Trial summary]")
    df = study.trials_dataframe()
    state = optuna.structs.TrialState
    print("Copmleted:", len(df[df['state'] == state.COMPLETE]))
    print("Pruned:", len(df[df['state'] == state.PRUNED]))
    print("Failed:", len(df[df['state'] == state.FAIL]))

    # 最良のケース
    print("[Best Params]")
    best = study.best_trial
    print("Accuracy:", 1 - best.value)
    print("Batch size:", best.params['batch_size'])
    print("N unit:", best.params['n_unit'])

試しに100回ほど最適化してみた結果，約4時間程度かかりました*2．

$ python main.py 100 -g 0
[I 2019-03-24 09:44:51,751] A new study created with name: prune_test
[I 2019-03-24 09:48:36,239] Finished trial#0 resulted in value: 0.02411597967147827. Current best value is 0.02411597967147827 with parameters: {'n_unit': 57, 'batch_size': 23}.
# 省略
[I 2019-03-24 15:01:56,820] Finished trial#99 resulted in value: 0.023074626922607422. Current best value is 0.019391894340515137 with parameters: {'n_unit': 93, 'batch_size': 41}.
[Trial summary]
Copmleted: 100
Pruned: 0
Failed: 0
[Best Params]
Accuracy: 0.9806081056594849
Batch size: 41
N unit: 93

また，実際に使用したDockerfileと以下の実験を行ったスクリプトファイルはそれぞれこちらとこちらにあります．

枝刈りとは

Optunaによる試行の枝刈りとは，

深層学習や勾配ブースティングなど、反復アルゴリズムが学習に用いられる場合、学習曲線から、最終的な結果がどのぐらいうまくいきそうかを大まかに予測することができます。この予測を用いて、良い結果を残すことが見込まれない試行は、最後まで行うことなく早期に終了させてしまうことができます。これが、Optuna のもつ枝刈りの機能になります。

となっています*3．Optunaではv0.9.0現在，2種類の枝刈り方法が存在します．以降，試行をtrial，その試行の中での学習のステップの単位をepochとします．

MedianPruner

アルゴリズム

最小化したい値（validationのlossやaccuracyなど）を定期的（1 epochごとなど）に報告し，その値を過去のtrialにおける同じepochにおける値と比較して，それらの中央値より悪ければ試行を止めるPrunerです．

例えば，以下のような試行が行われているとします（これらの報告されている値はvalidation lossだと考えてください）．

.	1 epoch	2 epoch	3 epoch	4 epoch
1 trial	100	80	60	40
2 trial	120	100	90	80
3 trial	110	75	65	10

4 trialでは，1 epoch目で95，2 epoch目で90を取ったとすると，このとき，過去の3回の試行における各タイムステップの中央値は以下のようになり，

.	1 epoch	2 epoch	3 epoch	4 epoch
median	110	80	60	40

4 trialの2 epoch目の値90は過去の試行における2 epoch目の中央値80よりも大きいため，4 trialは破棄されます．

使い方

MedianPrunerをインスタンス化し，studyに渡します．

    # 途中省略
    # Prunerを作成
    pruner = optuna.pruners.MedianPruner(n_startup_trials=5, n_warmup_steps=0)
    # Studyを作成してPrunerを指定
    study = optuna.study.create_study(
        storage='sqlite:///optimize.db', study_name='prune_test', pruner=pruner, load_if_exists=True
    )

Chainer用のインテグレーションを追加します．これはTrainerのExtensionで提供されています．これは僕がハマったことなのですが，実はpruner=NoneとしてStudyに渡すと，デフォルトでMedianPrunerが使われるため，以下のExtensionを追加するだけでPruneされてしまいます．Pruneされたくない人は注意してください((単に中間の値を全て保存しておきたいだけならtrial.report(値, step=epoch数)で出来ます．))．

    # 省略
    trainer = training.Trainer(updater, (epoch, 'epoch'), out='output')

    # validationをするextensionを追加
    trainer.extend(extensions.Evaluator(test_iter, model, device=device))

    # Optunaとのインテグレーションのためのextensionを追加
    # trialオブジェクト，監視するメトリクス，監視する頻度を指定
    integrator = optuna.integration.ChainerPruningExtension(
        trial, 'validation/main/accuracy', (1, 'epoch')
    )
    trainer.extend(integrator)

実行すると時折枝刈りされる試行が出てきます．

$ python main.py 100 -g 0
[I 2019-03-24 12:30:48,730] A new study created with name: prune_test
[I 2019-03-24 12:32:23,866] Finished trial#0 resulted in value: 0.033683180809020996. Current best value is 0.033683180809020996 with parameters: {'n_unit': 26, 'batch_size': 60}.
# 省略
 [I 2019-03-24 13:16:01,994] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 10
Pruned: 90
Failed: 0
[Best Params]
Accuracy: 0.978394627571106
Batch size: 108
N unit: 72

45分程度かかったようです．Accuracyは枝刈り無しよりも悪いですが，100回しか行っていないためもっと試行回数を増やせば良くなりそうです．

n_startup_trials

枝刈りを開始するまでの必要trial数を指定します．n_startup_trials=0なら試行の数にかかわらず，過去の試行の中央値よりも悪ければ破棄されます．例えば，最初に上げた例の2 trialは本来1 epoch目で中断されてしまいます．n_startup_trials=5とすると，5 trialまでは必ず実行され，6 trialから枝刈りが行われるようになります． デフォルトはn_startup_trials=5です．

n_warmup_steps

学習開始直後の学習曲線の傾きの角度が大きいものと，そうでないものがあるとき，小さいものの方が最終的な性能は良くなる場合もあるにもかかわらず，枝刈りが行われてしまうという可能性があります．これを回避するため，ある試行の中で，必ず実行するステップ数を決めることができます．例えばn_warmup_steps=5とすると，5 epoch目までは必ず全ての試行において実行され，6 epoch目から枝刈りが行われるようになります． この値を大きく取ればそれだけ様々なパラメータの可能性を見ることができますが，逆に枝刈りの効率は下がってしまいます．

SucccessiveHalvingPruner

v0.6.0から追加された，異なるアルゴリズムを採用したPrunerです．

Optuna v0.6.0 をリリースしました！ https://t.co/Ug8tYoJxZt 枝刈り機能の Keras サポート、枝刈りの新アルゴリズム ASHA (Asynchronous Successive Halving Algorithm) 等が新しく入ってます。ASHA は図のように一部のユースケースで最適化の性能を大きく向上します……！ pic.twitter.com/KZJIyXOYmV

— Takuya Akiba (@iwiwi) 2019年1月10日

アルゴリズム

単純なSuccessive Halvingアルゴリズム（SHA）ではなく，Asynchronous Successive Halvingアルゴリズム（ASHA）という改善された（？）アルゴリズムを採用していることがドキュメントに述べられています*4．ASHAについては以下の論文で提案されています．

arxiv.org

SHAそのものの解説はこちらの記事が詳しかったです．

adtech.cyberagent.io

SHAは学習の総時間を決め，途中まで学習をすすめてその中からよりよい組 個を抽出，学習を続けてまた上位 個を抽出……というのを繰り返すことで，良いパラメータでの学習に時間をかけるということのようです．ASHA自体の論文について詳しく読み込めているわけではないこと，こういったアルゴリズムに対して詳しいわけでもないことなどから，以下で述べることは全く正確性に欠ける可能性があることをご了承ください．

用語の定義

• : ハイパーパラメータの組み合わせの数．
• : 一つの試行におけるmaximum resource．
• : 一つの試行におけるminimum resource．
• : reduction factor．2以上の数値．
• : minimum early stopping rate．
• rung
  • 上位の組み合わせを抽出するための区切り？
  • ある について 個の試行を行うことを一つのrungとしている？
• brackets
  • ある 個のハイパーパラメータの組についての最適化
• 昇格
  • あるrungの上位の組み合わせを次のrungへと移行する（学習を継続する）こと

まず，論文中にSHAのアルゴリズムは以下の様に示されています．

また， ，，， のとき以下の左図のようになり，異なる の組み合わせについて示したものが以下の右表になるようです．

Figure 1: Promotion scheme for SHA

のとき，最初のrungでは9個の試行が行われ，上位1/3だけが次のrungへ，そして最終的に1つが選出されていることが分かります．rungが進むごとに一つの試行に割り当てられるresource が増え，学習が進んでいることがわかります．

まず，SHAを単純に並列化（これを論文中では"synchronous" SHA，同期的SHAと呼んでいる）する上での問題は論文中に，

1. あるrungは次のrungに進むために， 個の試行が全て完了しないといけないため，stragglerやdropped job*5に弱い
2. 試行するジョブが全て無くなったときには新しいbracketを追加するが，上位 個を選ぶのは各bracketについて独立であるため，bracketを並列しても，上位 個を選ぶパフォーマンスは向上しない
   • 自信無いです

というようなことが述べられているように見えます．これを解決するために，筆者らはASHAを提唱しており，アルゴリズムの概略は以下の様になっています．

Asynchronous Successive Halving Algorithm

同期と非同期の違いは以下の図のように表されるようです．

Figure 2: Comparison of promotion schemes for SHA and ASHA.

同期SHAでは，rung 1に進むためにrung 0の試行が全て完了するまで待つのに対して，ASHAでは，全ての完了を待たずに先にrung 1のジョブが実行されます．つまり，これまでに実行された 個の試行について，常に という比率を保つように次のrungの学習を行う，というようなことのようです（これも自信無い）．もし昇格するジョブが無かったとき，単にbaseのrung（rung 0）に新しいjobを追加します．これはつまりパラメータの組の全体数 を決めないということです．ASHAで必要なパラメータは，SHAのパラメータから を除いた全てです．

使い方

単にMedianPrunerをSuccessiveHalvingPrunerに置き換えれば良いです．記述は省略しますがChainerPruningExtensionも必要です．

    # 途中省略
    # Prunerを作成
    pruner = optuna.pruners.SuccessiveHalvingPruner(
        min_resource=1,
        reduction_factor=4,
        min_early_stopping_rate=0
    )
    # Studyを作成してPrunerを指定
    study = optuna.study.create_study(
        storage='sqlite:///optimize.db', study_name='prune_test', pruner=pruner, load_if_exists=True
    )

引数は3種類あり，

• min_resource：論文中の
• reduction_factor：論文中の
• min_early_stopping_rate：論文中の

にそれぞれ相当します．なお，最大リソース数 はパラメータとして渡しません．これは各trialの中で決まる値（Trainerに渡すEpoch数など）に当たるためだそうです．また，これらの値から

• 最低限実行されるepoch数：
• Pruneされるタイミング：

などが以下の式で計算出来ます*6．

例えば，デフォルトの値（ ，， ）のとき，

ここで， は例えばrung 0で他よりも良い成績であった場合，次にPruneされるのはとして と計算することが出来ます．つまり，1，4，16，64…epoch目でそれぞれPruneされるかどうかが決まります．実際に，100回実行してみた結果が以下です．

$ docker-compose up asha
[I 2019-03-24 12:30:48,446] A new study created with name: prune_test
[I 2019-03-24 12:32:16,421] Finished trial#0 resulted in value: 0.02267676591873169. Current best value is 0.02267676591873169 with parameters: {'batch_size': 65, 'n_unit': 119}.
# 省略
[I 2019-03-24 12:58:49,325] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 3
Pruned: 97
Failed: 0
[Best Params]
Accuracy: 0.9773232340812683
Batch size: 65
N unit: 119

かかった時間は30分程度でした．MedianPrunerの時と同じく，枝刈り無しで行ったときより結果が悪いのは気になりますが，こちらも同じく時間が大きく短縮されているのでもっと試行回数を増やして良さそうです．

まとめ

MedianPrunerの挙動はドキュメントを読んでだいたい理解したのですが，SuccessiveHalvingPrunerは「Successive Halving Algorithmの非同期版」という書かれ方がされており，全く分からなかったので論文を流し読みしてまとめてみました．やはり枝刈りを行うと圧倒的に時間が短縮されることも実際に確かめることが出来ました．積極的に活用していきたいですね．
内容に間違っている箇所があれば，コメントで優しく指摘して頂けると助かります．

*1:実際，各セクションで実際に最適化を実行していますが，それぞれ同時に動かしたりしています．1080tiなら大丈夫だろwと気軽にやっているので実行時間の正確さは期待しないでください．

*2:遅くないか…？

*3:research.preferred.jp

*4:https://optuna.readthedocs.io/en/stable/reference/pruners.html#optuna.pruners.SuccessiveHalvingPruner

*5:厳密な意味はわからないのですが，stragglerは他と比べて長い試行，dropped jobは実行中の失敗（メモリ不足とか，ノードが落ちたとか？）でしょうか

*6:これらの記号は僕が勝手に決めたもので特に意味はありません