『１日ひとつだけ、強くなる。』を読んだ

１日ひとつだけ、強くなる。

プロゲーマーという立場で書かれてはいるが、内容は格ゲーに特化したものではなく、割とどんな分野でも応用の効く内容だと感じた。

特に、ソフトウェアエンジニア(以下SWE)として働いていた身としては、SWEとしての仕事と「eスポーツとしてのゲーム」との共通点を感じる部分が多かった。SWEもウェブ上のメディアで成長に関するトピックが頻繁に話題に上がる。実際自分も自分の成長について悩む事がこれまでに少なくなかった。SWEをやっていると、知らなければならないこと、身につけなければならないことが延々と増え続けるので、その中でどのような道を決定して自分を成長させていくのか、ということは実際難しいことだと思う。

そういった『成長』とどう向き合っていくか、ということがこの本の主題のように思った。
強くなるには成長が必要だが、どのように成長するか。成長するために新しいことを試すにはリスクがある。しかし、一方で変化を恐れたり、怠慢して何もしないといずれ時代遅れになって通用しなくなり、結果的に自分の価値を失う。SWEとして働く世界においても全く同じだと思う。

本書ではウメハラさんが彼の後輩から「どうして成長しないといけないんですか」と聞かれたことがあるというエピソードが紹介されている。*1それに対してどう答えたかは書いてないが、代わりに成長に関してどう考えているかが述べられている。

成長しながら力をつけることができれば、自分が楽しいし、いい結果も生まれやすい。 だから、成長は義務などではなく、楽しく生きて、この時代にコースアウトしないためのツールとて考えればいいのではないか。

(中略)

コースアウトする可能性があったとしても、より良い走りをしようと前に出て戦う。そのときは駄目だとしても、成長（変化）を続けて、次のレース、次の次のレースで良い成績を出すようにする。　このような姿勢でいることが、最終的に自分の身を守る。僕は、そう考えている。

自分としては同意出来る考え方である。新しい言語、アルゴリズム、設計手法なんかを使えるようになったりして手数が増えたり、前よりも早く書けるようになったりすると単純に楽しいし、それが結果的に自分の強みにつながる。最終的に報われないこともあるが、それでもまずは楽しむためにやる、という考え方で取り組む姿勢はSWEにとってもマッチするのではないだろうかと思った。

もちろん「それでも成長するだけの価値は感じられないのでやはり疑問が拭えない」という人もいると思うが、どこかで無茶振りをされたりして急に勉強したりしなければならないケースは仕事していると大体どっかである。そういう時に役に立ちそうな考え方が本書には多く記載されている。今後も自分は自分の成長について悩んだら読み返したい一冊である。

*1:「リスクを負わない姿勢が一番のリスクになる」の章より

Treasure Data Summer Internship 2018 に参加した #td_intern

8月13日から9月28日までの約Ⅰヶ月半に渡ってTreasure Dataのインターンに参加してきた。
毎年インターンに参加した学生が報告ブログを書くのが恒例行事になっているので、自分も書いてみることにする。 なお、Treasure Dataの方には、ブログを書くことおよび成果発表スライドを公開することの許可は得ている。

インターンで何をやったのか

今回のインターンではDigdagの機能開発を主に行った。DigdagとはTreasure Dataが公開しているオープンソースのワークフローエンジンであり、似たようなproductとしてはAirFlow、Luigiなどがある。

メンターとして @muga_nishizawa さんと @komamitsu_tw さんの２人にお世話になった。

インターンの成果

こちらのスライドにまとまっている。*1

資料自体は英語だがプレゼンと質疑応答もすべて英語(グダグダになったけど)で行った。

外部のデータストアにアクセスできるOperatorを作った

github.com

Digdagには、task間でデータを共有する手段としてstore parameterという、hash形式でオブジェクトを共有する仕組みがある。しかし、一度workflowの実行が終わってしまうとそのデータを次の実行時に引き継ぐことができなかった。スケジュール実行などで、前回の実行時に作成した値を次の実行時にも参照したいというニーズを満たすには、ユーザが自分でscriptを書いてshell operatorなどで実行し、どこかにその値を保存しておく必要があった。
それを気軽にoperatorだけで実現するために、外部のデータストアにDigdagからデータを保存、およびロードできるようにする仕組みを実現するOperatorを実装した。利用できるデータストアとしてPostgreSQLとRedisをサポートしている。詳細はdocument を参照していただきたい。*2

digdag-uiのログを見やすくした

github.com

digdag-uiのsessionページなどでworkflowのログを閲覧できるのだが、１つのworkflowが出力するログ全てが一箇所に出力されてしまうため、どのログがどのtask(attempt)に対応しているか分かりづらくなるという問題があった。
なので、試しに単純にattemptごとにログを分割して表示するようにフロント側を修正してみたら、ええやん、ということになりマージされた。

DigdagのREST APIでレスポンスできるattemptやsessionの数を増やせるようにした

github.com

Digdagは内部で組み込みwebサーバを起動しており、REST形式のAPIを提供している。そのAPIの中に、指定されたprojectのattemptやsessionの一覧を返すEndpointが存在するが、一度のリクエストで返せる件数が 100 とハードコーディングされていたので、それ以上の件数を一回のリクエストで取得できなかった。大量にattemptやsessionが存在するprojectの場合にこれだと不便という声があったため、 100 以上に上限を増やせるようにした。何も設定しなければ、これまで通りの 100 が上限として適用される。

tdプラットフォームの実行済みjobの結果をexportするOperatorを作った

github.com

tdプラットフォームに対してQueryを実行した結果などを、後から別のデータストアなどに出力したい場合に使えるOperatorである。

今まではDgidagのオペレータ経由でQueryを実行することはでき、その際にオプションを指定することでQueryの結果を別のデータストアなどに出力することはできた。しかし、同じQueryの結果を、複数のデータストアに書き出すことができなかった。(例えばtdプラットフォームの別テーブルとシステム連携用に自前で運用しているFTPサーバの両方に結果を書き出したい、というような場合)

tdオペレーターで実行したjobの件数をstore parameterに保存するようにした

github.com

詳細はPRを見て欲しい（Digdagを普段から使ってれば見ればわかるハズ）。

Kubernetsに関する調査

詳細は↑のスライドを見て欲しいのだが、コンテナが使えるディスクサイズの限定とコンテナからEC2 APIへのアクセスを遮断する方法について調査した。

この辺の調査結果をどう活用するかについては、 10/17に渋谷で開催される PLAZMA TD Tech Talk 2018 at Shibuya : Part 2 のMugaさんのセッションを聞いていただければと思う。

techplay.jp

こんな感じで働いた

インターン前半は東京オフィスにて勤務し、後半は主にUS Mountain Viewオフィスにて勤務した 。

２人のメンターのうち @komamitsu_tw さんは東京オフィス勤務で、 @muga_nishizawa さんはUS MountainViewオフィス勤務であった。そのため、東京オフィスで働いていた間は主に @komamitsu_tw にサポートしていただきながら仕事を進め、同様にMountainViewオフィスでは @muga_nishizawa さんにお世話になった。

8月13日〜8月31日 / 9月25日〜9月28日

東京オフィスにて勤務した。

初日にいくつかDigdagのタスクを振ってもらい、それについて自分が簡単なDesign docを書いて、それを２人にメンターに見てもらって問題なければそのまま実装に入る、という流れだった。普段、チームでwebサービスなどの開発をしている人なら、恐らく日常的に実践しているような開発フローだと思う。

また、東京オフィスでは毎日ケータリングでランチを無償で提供していただき、実に最高であった。普段はコンビニ弁当と松屋で生きているので、久々の栄養バランスの取れた食事は大変ありがたかった。

9月4日〜9月21日

US MountainViewオフィスにて勤務した。

USで勤務することになった経緯としては、メンターの @muga_nishizawa さんがUS在住であり、現在Digdagについては @muga_nishizawa さんがメインでメンテナンスをしているということもあったので、時差がある状態でリモートでコミュニケーションを取るよりは同じタイムゾーンで直接会話できる環境で働いた方がやりやすかろう、という会社側のお気遣いによるものである。

英語で1on1していただいた話

USにいる間も普通に開発をしていたが、せっかくUSに来たのだからということで、MountainViewオフィスのエンジニア以外の方と何人か1on1をさせていただく機会をいただいた。もちろん英語である。

繰り返す、英語である。

30を過ぎて初めて海外に単身渡航したおっさんが初めて英語ネイティブの人と30分間1on1した結果なんですが、中学1年で習うような英文よりも難しい英文は聞こえていても全く脳の処理速度が追いつかずに言語として処理できず、ロクに話せもしませんでした。現場からは以上です。

— Kazuhiro Serizawa (@seri_k) 2018年9月6日

自分の英語は大学院ブログにも書いているがTOEIC700点のスキルしかなく、Speakingに関しては中学校時代で完全に止まっていた。
MountainViewオフィスの方々としても、はるばる日本からUSまで１人でやってきた大学院生(おっさん)がここまで英語が話せないということについてはきっと驚いただろうが、自分自身もこんな英語力でいきなり外資企業のオフィスに来てしまって正直驚いた。人生、それなりに歳をとってみても、まだまだびっくりするような事態が突然身の上に起こることがあるのだな、ということを久しぶりに思い出した。

結果的に、英語1on1は何度か回数を重ねる度に多少マシになって、何度も聞き返しながらも、かろうじて高校１年生ぐらいの英語を使って自分の専攻について説明したり、相手の業務内容について質問できるようにはなったので、せっかくだから日本に戻ってからもちゃんと英語勉強を継続しようと思った。近々TOEICの勉強を再開する*3のとオンライン英会話サービスとかを始めようと思っている。

帰国する頃になると、疲れていたのか以下のような謎ポエムをインターネッツに残しているが、きちんとした人間らしい高度なコミュニケーション手段を使えるにこしたことはないので、さっさと英語は勉強した方がよいというのが今の結論である。

人間間のコミュニケーションは言語によってなされるものだと思っていたが、言語という手段が通用しない環境で物事をあらゆる手段を用いて伝え合うことで大体何とかなってしまうところを見るに、言語とは普段行っているコミュニケーションの手段のほんの一部に過ぎ無いのかもしれないという気持ちになる

— Kazuhiro Serizawa (@seri_k) 2018年9月16日

所感

実際に働いていたのは33日間ということで、かつてフルタイムで働いていた身からすると短期間であるため、その短い期間の中で、どのように早く立ち上がって確実なアウトプットを出していくかが今回のチャレンジだったように思う。結果として、ビビり過ぎて全体像が把握できそうな単純なタスクからやりすぎたか、という反省はあるが、Treasure Dataのメンターのおふた方は自分のアウトプットについて概ね良い感想を抱いていただいたようなので安心した。

自分はフルタイムで働いたことはあるがインターンは初めてという珍しいパターンだったと思うが、TreasureDataの場合は両者の間にほとんど差異はなかったように思う。逆に、そのように働ける学生でないとインターンとして採用されるのは厳しいかも知れないが、興味があって腕に自信のある学生はぜひ来年応募してもらえればと思う。*4

*1:speaker deckのスライドを直接埋め込むと幅が足りずに両端が切れてしまったので直接リンク先に飛んで閲覧してほしい

*2:このOperatorについては別途解説記事を書く予定

*3:院試以来サボっていた

*4:多分来年もあるはず

システム運用の現場でしか学べないことは他メンバーに積極的に経験してもらうべきだった

基本的に自分はタスクを拾いすぎてしまう傾向にある。それに加えて比較的朝型なこともあり、前職ではエンジニアの中で一番朝早く出社していることも多かった。*1

その結果どうなるかというと、朝出社して見つけた運用上のトラブルは大体自分がとりあえず手を付ける状態になっていた。前日の夜間バッチやその日の早朝に動くバッチがコケて問い合わせが来ているのでそのリカバリをする、前日にデプロイした後レスポンスが高くなってアラートが出ているのでその調査をする、web appがやたらと500系エラーを吐いているのでBugsnagを見る、等々。

出社している以上無視するわけにもいかないというのもあるが、見つけてしまうと放っておけない性格ということもあり最優先でこれらの対応をしてしまっていた。お陰で前職で触っていたproductについてはかなり広範囲の知見があり、その行動がそれなりに社内での評価につながっていたのではないかと思われるのだが、一方で今はその行動については後悔している。

そういう球拾いを自分だけがやりまくっていた結果、何が起きたかというと、自分しか対処できないトラブルのようなものが増えてしまった。そしてその状態でそのチームから離れてしまった。もちろん引き継ぎ資料は大量に書いたし、自分が何か早朝とか深夜とかに対応した日は、その日何があってどういう対応をしたかはesaなどに障害内容と作業内容を決められたフォーマットで記載して貯める運用をしていたし、それなりに大事であればその日のうちにmtgをセッティングして口頭でサーバーサイドチーム内で説明した。知見を共有するという点では出来る限りのことをやったという自負はある。しかし、SREなどをしていてシステムの運用を経験したことがある人なら分かると思うが、障害対応において「知っている」ということと「やったことがある」というのでは経験値にかなりの差がある。自分は他のメンバーが「やってみる」という経験を大分奪ってしまっていたと思う。 早朝や深夜では自分に限らず気づいた人間が真っ先にやるしかないのだが、それでも、もし自分の作業中に出社してきたら一緒に調査するとか、実際にやった対応をステージング環境とかで一緒にやってみるとか、もう少し実践的な経験を積ませるようなことを意識すべきだったと思う。人が少ないベンチャーで常に余裕がない状態ではあったが、人が少ないからこそ、現場で学ぶことが一番の近道であるようなことを経験してもらってレベルアップしてもらうべきだった。新しい言語やライブラリの使い方はいくらでも好きな時間に学べるが、いざシステムで障害が起きた時の対応方法やその後のリカバリはいくらマニュアルを作ってそれを学んでもらってもカバーしきれないところがある。

だからこそ、普段から知識だけでなく機会をシェアできるような運用の仕組みを作らないといけないと感じる。例えば、以前、受託開発をしていた時代に常駐していた客先では、社内からの問い合わせを受け付ける窓口のエンジニアを当番制で決めており、何かあったらまずはその当番のエンジニアが調査を行うという仕組みを作っていた。この仕組は非常によくワークしていて、プロパーだろうがSESだろうが新人だろうがベテランだろうが強制的にアサインされるため強制的に知見を吸収する機会を作ることができる。こういう機会を設けて、組織として運用経験をシェアするような仕組みが必要だと感じる。インフラエンジニアがいるから安心ということは全くなく、むしろサーバーサイドに関わるエンジニアがSQLを書いたりhotfixを出さないと治らない障害の方が圧倒的に多い訳なので、専門のSREチームを構築できないような規模の組織では（多分そのケースがほとんどだと思うが）サーバーサイドエンジニアが運用知見をどれだけ持っているかが運用において重要だと今にして思う。

*1:多分9時前には大体出社していたし、忙しい時は7時台ということもあった。

春学期に読んだ論文まとめ

といってもあまり読めてない気がする。6月以降は完全にレポートに忙殺された。

とりあえず読んだ順に紹介。

深層学習関連

TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems

TensorFlowのwhite paper。TensorFlowの歴史、google社内での利用用途、計算グラフの構築と実装、parameter serverを使った並列訓練の話などかなり多紀にわたってtensorflowについて紹介されている。

今でこそdefine by runのアプローチが柔軟で良いとされる風潮にある気がするが、この論文を読んだ限りではモデルの表現の柔軟さと実装時の最適化を両立できるdefine and runのアプローチも悪くないのではないかという気がする。論文によればTensorflowは同一の計算グラフでモバイルデバイスからサーバ上でまで同じコードで実行できるとあり、実際Androidでも学習済みモデルを使った推論が可能だし、MobileNets というモバイル用に省メモリで動作できるcNNも提案されている。広いプラットフォームを持つgoogleとしては実行とネットワークの定義を切り離すことは会社としても重要な戦略であったと考えられる。

Large Scale Distributed Deep Networks

TensorFlowの前身であるDistBeliefという機械学習フレームワークの紹介。こちらはwhite paperというよりは、parameter serverを用いた分散深層学習のアルゴリズムとそれを実現するシステムアーキテクチャの話題が中心である。

ここで扱っているアルゴリズムは非同期に勾配を更新するDownpour SGDと、バッチ処理で非同期に勾配を更新するSandblaster L-BFGSである。正直、両者の根本的な違いがよく分からんかったのだが、前者はパラメータープロセスは1台で、後者はパラメータサーバを複数台に分散し、それらに指示を出すコーディネータープロセスが全体の処理を管理する点が異なるらしい。

ChainerMN: Scalable Distributed Deep Learning Framework

日頃お世話になっているChainerの分散プロセス実行ができるように拡張してくれるライブラリのChainerMNについてのwhite paperである。 書かれている内容はChainerMNの紹介がメインだが、2章のPreliminariesで深層学習、分散深層学習についての解説がとても細かく載っているので、ここを読むだけで深層学習と分散深層学習についての基本的な知識を得られると思う。データ並列とモデル並列の図解も*1とてもわかりやすい。

A Data and Model-Parallel, Distributed and Scalable Framework for Training of Deep Networks in Apache Spark

Apache Spark上で動作するモデル並列訓練を行うための分散深層学習フレームワークの紹介。 実装はspark上で行列計算にJBlas、自然言語処理用にMalletを使用して全結合NN、cNN、LSTMを実装した、とあるが、コードが全く出てこないのでどのように実装されたのかよくわからない。

パラメータの更新には独自の分散バックプロパゲーションを考案したとあり、これがこの論文の貢献のようなのだが、数式を見る限りはどの辺が新しいバックプロパゲーションなのかよく分からなかった。。モデル分散してるから行列を列単位に分散してるのでバックプロパゲーションの数式がそういう風に変わるよねというのは分かるが、何か自分が見落としてるのかもしれない。。

AMPNet: Asynchronous Model-Parallel Training for Dynamic Neural Networks

これもモデル並列を行うための分散深層学習フレームワークを作ったぜという話。ただ、これはモデル分散といっても処理対象のパラメータの行列を分割するようなものではなく、レイヤーごとに別のノードに配置してパイプラインで処理を行うというアプローチ。

途中で読むのを辞めてしまったので若干正確性に乏しいが、深層学習の訓練においてはメモリからデータをロードする部分がボトルネックになったりGPUのプロセッサがボトルネックになったりとハードウェア的に処理の負荷がかかる箇所が計算フェーズによって異なるという事情があるのに対し、既存のフレームワークは一切それを考慮しておらず、ハードウェアを使い切れていないということを批判している。*2

そこで、レイヤーごとに実行するノードを分割し、1 iterationをパイプラインに分割してそれぞれの処理を別々のマシンで行うことで、各レイヤーの計算に特化したハードウェアを詰むことでハードウェアを使いきれるようになるね、という主張らしい。

Convolutional LSTM Network: A Machine Learning Approach for Precipitation Nowcastin

レーダーエコーで計測した降水データを時空間予測問題として解くための畳み込みLSTMを提案する論文。要するに動画のフレーム予測と同じようなアプローチで降水予測を行おうというアプローチである。

降水データは6分ごとの観測点の降水強度を行列にマッピングし、それを時系列的に連続する20枚のフレームを1 windowとして、最初の5frameをinput、残り15frameを予測する問題設定としている。

ネットワーク構成がユニークで、2層のLSTMレイヤーでencodingした後にそのレイヤーをコピーした別のレイヤーで予測を行い、inputと同じ行列サイズのアウトプットになるように畳み込んで予測フレームを出力している。なぜこのような構成にしたかは不明。あとなぜかloss関数がSoftmaxである。

専攻研究であるReal-time Optical flow by Variational methods for Echoes of Radar(ROVER)という数理モデルを用いた手法よりも高い予測精度を示した。

なお、この論文を参考に気象庁が提供するレーダーエコーデータを用いて同じようにConvLSTMで訓練を行ってみたが論文ほどの精度は出なかった。やはり10分毎計測、1km間隔の観測データしかないので、動画のように扱って予測するにはちょっと解像度的に厳しいかもしれない。

その他

Software model checking

とある講義のレポート課題で読んだやつ。 ソフトウェアモデル検査に関する研究についてまとめたサーベイ論文である。述語論理の用語が全然分からなくて訳すのすら大変だった記憶。

Halide: A Language and Compiler for Optimizing Parallelism, Locality, and Recomputation in Image Processing Pipelines

これも↑と同じ講義でレポート課題になっていたので読んだやつ。

最近一部で静かなブームとなりつつある、ハイパフォーマンスなコードを生成するコンパイラと記述するためのDSLを提供するHalide。Adobeの画像処理エンジンなどで使用されているらしく、この論文ではどのようにして画像処理一般で行うstencil計算をDSLでシンプルに記述してコンパイラで高速化したコードを吐くか、という手法について書かれている。Halideで生成されたコードと人間が手でチューニングしたコードのパフォーマンス比較もしているが、この結果がかなり凄くて、Halide DSLで34行で書いたコードが人間が手で書いた122行のCのコードよりも4.4倍高速だったりする。またcudaを使用したコードも出力でき、そちらでも人間が書いたどのコードよりも早いという結果になっている。人間が書いたアセンブラよりもccが吐くアセンブラの方が速い！みたいな感じだろうか。

面白いのでもう少し個人的にいじってみたい所存である。なお、Halideコンパイラを用いたコード高速最適化フレームワークのTiramisuというやつもある。こっちも気になる。

*1:これはPFNの中の人のスライドでよく見るやつだが

*2:実際これはnVidia visual profilerとかでprofileしてみると分かるのだが、モデルサイズが大きいネットワークを回すとボトルネックになっているのはCPUからGPUへのデータ転送だったりしてGPUのプロセッサは50%も使ってなかったりするケースがある。これは実際に自分が実験した確認した実例である。

分散深層ニューラルネットワークの実装アプローチまとめ(2018年6月版)

これは何か

• 自分が研究テーマとして扱っている分散深層ニューラルネットワークには、「分散」処理の部分において複数のアプローチが存在する
• このエントリでは、自分の知識の整理のためにこれまで調べたことをまとめておく
• (2018年6月版) と書いたのは、深層学習業界は変化が激しすぎて半年後には状況が変わっていてこのエントリが役に立たなくなることを想定しているためである（その時はまた新しい版を書こうかなと）

分散深層ニューラルネットワークとは

一般に「深層学習」と呼ばれる機械学習手法においては、隠れ層が多数連なる「深層ニューラルネットワーク」が使用される。
昨今では隠れ層の数を大規模に増加させて学習を行う手法が、主に画像認識の分野で効果を上げており*1、それに伴って訓練に要する時間も増加傾向にある。この問題を解決するために、スループットを向上させるためのアプローチとして分散処理を深層ニューラルネットワークに導入する手法が注目されている。

分散深層ニューラルネットワークでは大きくわけて２つのアプローチ、データ並列分散訓練 とモデル並列分散訓練 が存在する。以下、それぞれについて解説する。

データ並列分散訓練

同一のネットワークの複製を複数用意し、それぞれのネットワーク（以下レプリカと呼称）に対して訓練データを適用して並列に訓練を行うアプローチである。 各レプリカは、通常のニューラルネットワークと同様に訓練を行い、個別に勾配を計算して重み行列やフィルタなどのモデルパラメータを更新する。

ここまでは並列でない通常のニューラルネットワークと変わらないが、データ並列分散訓練においては、各レプリカの訓練で得た勾配を、数iterationごと、あるいは毎iterationごとに集約して、平均化したもので各レプリカの勾配を置き変える。これにより、訓練データを分割して並列に訓練を行いつつも、逐次実行で全訓練データを用いて訓練したかのような結果を得ることができる。

この際、レプリカ間で訓練に用いる勾配の「鮮度」が課題となる。常に最新の（つまり鮮度が高い）勾配を用いて訓練を行うには、毎iterationごとにレプリカ間で処理同期を取った上で、勾配を集計し同期する必要がある。しかし、この集計処理がボトルネックとなり、ネットワークのスループット低下につながる。

一方で、勾配の更新頻度を下げすぎると、勾配が同期されるまでは、各レプリカ上のローカルな勾配を用いて訓練が進み、勾配の「鮮度」が劣化する。これにより、レプリカ間のモデルパラメータの差異が大きくなり、損失の収束を遅らせるなどの悪影響をもたらすという問題が生じる。

実際の深層学習フレームワークにおいては、同期処理によるスループット低下を防ぐために、非同期でレプリカ毎に異なるタイミングで勾配を更新する手法を採用しているものもある。以下、同期、非同期それぞれの手法について解説する。

勾配の同期更新

ニューラルネットワークにおいて、勾配は訓練におけるBackwardフェーズでレイヤー毎に計算される。そして求めた勾配に学習係数をかけた値を使ってモデルパラメータを更新するのが一般的な手法である。

勾配の同期更新においては、モデルパラメータを更新する前に、レプリカ間で同期を取り、各レプリカで求めた勾配の平均値（以下、平均勾配と呼称）を用いて全パラメータを更新する。つまり、各レプリカで計算した勾配をモデルパラメータの更新に用いるのではなく、平均勾配を用いて各レプリカのモデルパラメータを更新する。これにより、常に最新の平均勾配を用いて訓練を行うことができる。

このアプローチは、具体的なプロダクトとしてはChainerMNが採用している。バージョン1.3では、同期更新時に他の処理と一部オーバーラップさせることで同期による処理遅延を低下させる DOUBLE BUFFERING という機能が搭載された。この機能を使うと、一時的に古い勾配のまま訓練を行うワーカーが生じるが、精度には影響のないレベルであるとのことである。 *2

勾配の非同期更新

非同期に更新を行う場合、各レプリカ間で同期を取らずに平均勾配を求めるため、勾配の集約と平均勾配の計算を行うための別のプロセスが必要である。かつてGoogle社内で使われていたDistBeliefという深層学習フレームワークにおいては、パラメーターサーバという専用プロセスがこの役割を果たしている。Googleのプロダクトとしては後発であるTensorFlowを分散実行させる場合においてもこのアプローチは同じようではある。

非同期更新においては、各レプリカが求めた勾配をパラメーターサーバに送信し、その勾配を用いてパラメータサーバが平均勾配を更新する。各レプリカは次のiterationの訓練を開始する前に、パラメーターサーバから最新の鮮度の高い勾配を取得し、それを用いて訓練を行う。

各レプリカは同期を取らずに平均勾配が更新されるため、レプリカ間で使用している勾配に差が生じている状態が発生する。このことにより、より良い勾配を古い勾配を使った訓練により生じたより劣悪な勾配によって、悪化させてしまう事も考えられる。 このような最新のパラメーターサーバーにある勾配と比べて古い勾配を「陳腐化した勾配（Stale gradient）」と呼ぶ。陳腐化した勾配の影響を緩和するには、学習率を下げる、陳腐化した勾配を定期的に捨てる、ミニバッチサイズを調整する、等が考えられる。*3

モデル並列

レプリカを作らず、ネットワーク上のパラメータを複数のプロセスに分割し訓練を行う並列化手法。 これにより、例えば前結合ネットワークにおいて、巨大な行列となった重み行列と入力ベクトルとの計算を複数のマシンで分散して実行することで、要求されるマシンスペック要求の低下*4と、並列化による高速化が望める。

一方で、ネットワーク的に分断されたマシンクラスタで実現する場合、各プロセス間のデータ通信が大きなボトルネックになると考えられる。そのため、全結合ネットワークやcNNではスループットが大きく低下する可能性が考えられる。この手法を適用して高速化を行うには各プロセス上での高い密度を高くすることができるネットワークが適していると考えられる。例えば、TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systemsではモデル並列の実装例としてLSTMを挙げている。

自分が論文を調べた限りでは、Apache Spark上に全結合ネットワークやcNNをモデル並列で実際に実装している例*5や、レイヤーごとに複数のマシンに分割し、訓練処理をパイプライン化して並列効率を向上させる実装*6もあるが、まだ実例が少ないアプローチであると考えられる。

2018年6月時点では同期更新・非同期更新どちらが良いのか

様々な条件下で両者のアプローチを比較した2016年の論文Revisiting Distributed Synchronous SGDによると、同期更新の方が非同期更新よりも収束速度も正解精度も高いことを示している。また、訓練を実行するワーカー数を増加させた場合も同期更新の方が収束速度がより効率的にスケールすることを示している。近年の画像コンペにおいても上位入賞者チームにおいて同期型が支持されているという意見もある。*7

よって、非同期型に特化した新しい手法が開発されたら状況は変わる可能性はあるが、2018年6月現在では同期型の方を選択する方が正解である可能性が高い。例えば2017年9月にarXivに投稿されたImageNetの訓練に関する論文、ImageNet Training in Minutesでも、同期型データ並列アプローチを使っていることが明記されている。

まとめ

訓練精度という観点で見ると、データ並列・同期更新が現時点では最も高い精度を得つつ、高いパフォーマンスを発揮できるアプローチだと考えられる。しかし、メモリに乗り切らない大規模なパラメータを扱う場合や、マシンリソースの有効活用という観点では、モデル並列を活用できるシーンもあると考えられる。*8

実際、自分は大規模なパラメータを想定したネットワークにおいてモデル並列訓練を行った場合の性能特性について研究する予定であり、現在c++とBlas系ライブラリとMPIで、モデル並列ネットワークを実装している最中である(作るのはとりあえず全結合ネットワークのみ）。自分の研究成果については追ってまた別のエントリで紹介したい。

参考文献

• Large Scale Distributed Deep Networks
• TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems
• Distributed TensorFlow
• Revisiting Distributed Synchronous SGD
• scikit-learnとTensorFlowによる実践機械学習
• ChainerMN: Scalable Distributed Deep Learning Framework
• A Data and Model-Parallel, Distributed and Scalable Framework for Training of Deep Networks in Apache Spark
• AMPNet: Asynchronous Model-Parallel Training for Dynamic Neural Networks
• ImageNet Training in Minutes
• 20171128分散深層学習とChainerMNについて
• 分散深層学習 @ NIPS'17
• GPUを2倍にしても2倍速くなるとは限らない　分散深層学習の仕組みと、世界の潮流を解説

*1:例えばここ数年の画像コンペでかなり使われているcNNの１つであるResNetは、作者らの報告によるとImageNetで152層のネットワーク、CIPHER-10で1202層のネットワークを構築した報告がある

*2:https://chainer.org/general/2018/05/25/chainermn-v1-3.html

*3:https://www.oreilly.co.jp/books/9784873118345/

*4:例えば大規模な行列計算を行うノードとそうでないノードとでGPUの搭載数を変えたりすることで、スペックを要求されない部分には低スペックなマシンを採用することができる

*5:https://arxiv.org/abs/1708.05840

*6:https://arxiv.org/abs/1705.09786

*7:https://logmi.jp/285424

*8:完全に余談だが、過去に非同期処理を多用するマイクロサービスを開発してきた元ウェブアプリケーションエンジニアの感想として、DistBeleifに代表されるパラメータサーバを用いたアーキテクチャの方が馴染みがあるので作ってみたい気持ちにはなる。

outputは最大のinput

outputがないとinputできない

仕事でも勉強でも、日々何かをinput ∈ {調べる, 勉強する, 調査する, 聞いてみる, まとめる, やってみる} しないといけないケースが多い。今は学生なので日々やってることの9割はinputである。

ただ、他の人はどうかは知らないが、自分にはoutputのイメージがないとinputが続かないという問題がある。outputのイメージがないと途中で迷走してやる気がなくなってやめてしまったりすることが多い。

例えば「とりあえずScala勉強してみよう」みたいなのがすごく苦手で、具体的な成果として何をoutputするかが決まってないと続かない。例えば「とりあえずPlay Frameworkのチュートリアルやる」みたいなのがすごく苦手で、大抵途中で飽きてしまう。「今度Play使ったプロダクトの開発するからPlayチュートリアルやってCRUD一式を持つweb appを自分で作って概要を知る」とか、「こういう設計をしたいけど分からないので類似プロダクトのコードを読んで設計を理解して自分のプロダクトに反映させる」みたいな感じでないと続かないタイプである。

なので何も考えずに勉強するだけ、というのもすごく苦手である。そのため、今取ってる講義は全部何らかの応用目的があるものだけに絞っている。とりあえず直近で使わないものは全部「競プロに使えそう」ぐらいなのだが、それでも「ただ単位のため」という目的しかないよりは遥かにマシである。

ささやかでもoutputしながらinputする

自分が普段採用しているスタイルはこれである。*1 以下は研究室で使っているpukiwikiに自分が調べたことをまとめているページである。 基本的に備忘録としてoutputしている感じだが、それ以外にも研究室の定例ミーティングで進捗を報告するときに「XXXについて調べました」というような報告をするときに、当該ページのURLを貼って報告する、という使い方をしている。

あと今気づいたがMPIとかBLASみたいな、個別の研究に影響しない一般的な内容についてはあとで編集しなおしてQiita辺りに投稿してもいいかもしれない。

同様に論文も要約を書きながら読んでいる。

論文をまとめるフォーマットはいろいろあるのだが、とりあえず自分の場合は以下のようにまとめている。

• 3行でまとめると
• この論文が批判していること
• この論文の貢献
• 以下要旨（ここはフォーマット決めてない）

*1:もちろん具体的なソフトウェアを書くことがoutputの場合もあるが、直近だと具体的なブツが公開できてないので今回は説明を割愛。

大学院修士課程に入学した

tl; dr

• 会社員辞めて2018年4月から筑波大学のCS専攻の大学院修士課程に入学した
• 分散深層学習の学習高速化とか大規模inputデータへの対応などに関する研究をする予定
• がんばるぞい

大学院に入学した

2018年4月から仕事を辞めて筑波大学のシステム工学研究科コンピュータサイエンス専攻の修士課程で大学院生をやっている。
働きながら入学手続きしたり引っ越ししたりと色々やっていたので3月、4月はずっとバタバタしていたのだが、ようやく落ち着いてきたので近況についてまとめておこうと思う。

背景

一応5年ぐらいソフトウェアを書いて仕事をしてきた訳だけど、自分はCSの学位を持ってる訳でもなく、ちゃんとCSの基礎的な勉強したことがなかった。*1

そのせいか、業務要件をコードに落とし込むことはできても、「なぜこのアルゴリズムを使っているこっちのライブラリの方が早いのか」「こういうのを早くするためにはどういう最適化をすべきなのか」というような、技術に特化した課題に直面した時に、何もできないタイミングがちょくちょくあった。

特に、サーバーサイドで動作するバッチのパフォーマンスチューニングの面で、「とりあえずプロセスを増やせばスケールできるように設計したが、本当はもっと実装を最適化して必要なサーバ台数を減らすための工夫ができるのではないか？」ということが疑われるケースにおいて、自分の持っている知識の範囲では何もできないケースが多く、これはレベルの低いエンジニアリングだと思っていた。他にもいくつか似たようなケースに直面したこともあって、ソフトウェアのパフォーマンスをエンジニアリングの観点から改善できないことが自分の壁だと認識するようになった。

この壁を何とかしなければ自分のエンジニアとしての未来はないと思えた。ありとあらゆるものがサービス化される昨今で、今自分が作っているAPIやバッチすらも、GUIでモデルやパイプラインを定義して誰でも作れるようになるという予感もあったので、ウェブアプリケーションからクライアントにjson返すしか能がない自分はいつか職を失うだろうという危機感があった。

この壁を突破し、エンジニアとしての仕事を維持していくために自分に今何が足りないか？と考えると、明らかにインプットが足りていなかった。ソフトウェアというものを現場でのみ学んできた自分にとって、経験したことがない問題に対してほとんど何もできないという弱点があることに気づいた。その弱点が露骨に表れるケースの１つが前述のような大規模データの取り扱いだった。

そのため、５～６年前から、どこかのタイミングで仕事を辞めてインプットに専念する時期を作りたいと考えるようになった。しかし金銭的な余裕がない、卒業後に雇用され得るだけのスキルがない、という２つの理由で躊躇していた。しかし幸いにして、ここ数年でエンジニアとしてはそこそこのレベルになれたので最低限食うには困らないという気持ちになり、かつ貯金がそこそこ貯まったこともあり、やっていきが高まってきたので実行に移すことにした。

大学院という選択肢について

貯金があると言っても仕事を辞めないにこしたことはないので、当初は働きながら夜間に通える大学でCSを勉強しようかなと思っていた。しかし、日本だと夜間コースでCSが勉強できる大学は殆どなく*2、またカリキュラムを見ると基礎的な内容が多く、今の自分にとっては学びが少ないように思えた。通信教育系のカリキュラムもいくつか調べてみたけど、どれも基礎的な内容というかプログラミングのカリキュラムという感じで、どうにもしっくりこなかった。

なので、思い切って仕事を辞めて普通に大学院に行くことにした。
色々調べた結果、今の日本ではちゃんとしたCSを勉強するには昼間に通う大学院に行くしかないと思えた。その事実の是非はともかく、今自分が新しいことを勉強できる環境に身を置くとしたら、大学院で研究することが最も効率的な選択だと思えた。

入学までの経緯

別のブログに院試までの準備とか最近の様子とかをまとまているので、興味があればこちらを参照してほしい。
今後も学生生活ネタや研究ネタはこちらのブログに書いていく予定である。

serihiro-graduate-school.hatenadiary.jp

大学院で何を研究するのか

配属はHPCS研究室というHPC関連の技術要素を扱う研究室で、もともと興味があったMapReduce on HPCでの性能改善に関するネタを探そうと思っていた。しかし、MapReduceはあまりにレッドオーシャンで論文のネタになりにくそうという話になり、深層学習 on MapReduce（もしくはそれに類する分散環境）はどうかという話となった。

深層学習については以前に一度本を読んで写経した *3ぐらいの知識しかなく、TensorFlowやChainerもMNISTチュートリアルをやったぐらいの経験しかない。しかし、せっかく時間を取って研究するならやったことがない事の方が学びが多かろうということもあるので今は深層学習について論文を読んで知見をinputしている。同じ研究室内には深層学習を扱っている人はいないので何とか一人で頑張ってみる次第である。

最近の様子

大体、朝8時から19時か20時ぐらいまでは大学内にいる感じである。*4

M1の間に必要な単位をできるだけ稼いだ方がよさそうなので、5日間の平日のうち4日は何らかの講義を1日に1,2個履修している。CS専攻のカリキュラムページ はMkDocsで書かれていて読みやすくて良い。
今取っている講義は、自分の研究に関連する分散処理に関するものや、自分が単純に興味がある遺伝的アルゴリズムや数理最適化に関する理論などである。他にも、インテルの中の人が来て最近のインテルのCPUアーキテクチャに関する説明をしてくれる講義なんかも取っている。色々あって楽しい。

講義以外の時間は研究室にいて、今月は研究テーマを決めるための関連研究の調査をしている。まずは基礎的な所からということで、MapReduceや分散深層学習に関連するものを中心に読んでおり、や英語の論文を読んで要約する作業も最初はかなり時間がかかったが、2,3本読み切った辺りから段々と早くなってきた気がする。あと深層学習について復習するために ゼロから作るDeepLearningを最初から写経しながら読み直した。*5

それ以外だと、大学の図書館に行ってみたら大量に技術書があって、何時間でもいられそうな環境であるということを発見したので帰宅する前とかに図書館に寄って漁ってたりする。この土日も図書館に行って技術書を読んでいた。詳解LinuxカーネルとかTypes And Programming Languagesとかドラゴンブックとかの、普通に買うと余裕で7000円とかする本がタダで読めるのは大変ありがたい。大学にいる間にできるだけ読んでおきたい。

お金の話

「無職なのにお金はどうするの？」という話をよく聞かれるのだが、率直に答えると、必要な予算を計算したところ、自分の貯金を全部使っても若干足りなかったので、足りない分は親からの借金でカバーしている。
大学の入学金・授業料*6は国立なので大した額ではないのだが、2年間の住民税*7・国民年金・保険*8・生活費が、必要予算の大半を占めている。2年間は旅行はおろか、技術系カンファレンスに日帰りで行くことも厳しくなりそうだが致し方ない。改めて自分が生きていくのに必要な予算を計算することで、ただ生きているだけで物凄くお金がかかるということを実感できる良い機会になった。卒業後は、借りた金を早く返せるように、また貯蓄を増やしなおすべく、前職以上に稼げるようになろうと決意した。

卒業後の話

もちろん就職はするのだが、どの企業を受けるかまでは決めていない。
できれば分散システムを利用したプロダクト開発に関われるソフトウェアエンジニアとしてのポジションに就きたいと思うが、具体的な就職活動的なものは来年以降にやることとし、今年は研究に専念したいと考えている。また、在学中のインターンについても行ってみたい会社がいくつかあるので、その辺りにも挑戦してみようと思う。

*1:独学でやった勉強と言えばパタヘネを読んだぐらいか。

*2:例えば東京電機大学には夜間に学べるコースがあるが

*3:その時の話は別エントリに書いた https://serihiro.hatenablog.com/entry/2016/12/22/000000

*4:前職時代がこんな感じだったのでそれをそのまま引き継いでいる感じ

*5:余談だが、最初の方の版は誤植が多いので、古い版を持っている場合はgithubにあるerrataを見ながら読んだ方がいい

*6:実際の額は http://www.tsukuba.ac.jp/admission/graduate/tuition.html を参照

*7:特にフルタイムで働いていた2017年度の所得で計算される2018年度分がとてもとても痛い

*8:1年目は関東ITSの任意継続の方が安かったのでそちらを使い、2年目からは国民保険の方が安いのでそっちに切り替える