じぶん Release Notes (ver 0.33.2)

一応大学の敷地内

個人開発

• 実力不足（若しくは高望み）により，SWEに戻れなくなるかもしれないという危機感があって色々と気が散りがちなせいか，9ccほっぽり出してよくわからないものをやっている

github.com

github.com

読書

読み終わった

• 信長のシェフ　10巻

読んでる

• コンピュータアーキテクチャ技術入門
• Cracking the Coding Interview
• FPGAの原理と構成
• FPGAボードで学ぶ 組込みシステム開発入門［Intel FPGA編］

研究

• 実装は先月でほとんど終わったのでヤマは超えたかと思ったが先月以上の修羅場であった
  • どれぐらい修羅場かというと，完全なオフを取れたのは6月21日になってからだった
  • SWoPP投稿者は自分だけではなかったので，研究室はいつもより人がいる時間が長くて多少は気を紛らわせたのが幸い
• もう研究室に住んでるんじゃないかという気持ちになったが，研究室では寝られないので必ず家に帰って寝た
• どうしてこうなったのかを自分なりに分析すると
  • 評価環境にトラブルが起きることを一切想定していなかった
  • PythonのGILによる影響を過小評価していた．ThreadにCPUを使わせるとすぐに全然関係なさそうな箇所のパフォーマンスが落ちて原因特定に苦労した．
    • 今回は5〜10%程度の性能差を追うための評価実験だったのでかなりシビアだったのことも影響した
  • 実行したことがないアプリケーションを用いた評価実験で，自分が取りたい数値以外にボトルネックになっている箇所を事前に調査しなかった
  • そもそも予稿提出までの時間的余裕がなかった
    • 安全に進めることを考えるなら，本来は確実にコントロールできる評価実験の範囲で研究を完結させるべきだったのかもしれない
    • しかし，それだと研究としては中途半端になってしまうので，本当はどうすべきだったのか自分でもわからない
    • これはあとで教授と議論してみるか

勉強

• できるわけがない

その他

• 今月こそは状況を改善しようと思っていたが本当に何も改善できなかった．反省
• 先月書いた「某社インターン」は落ちた
  • 就職に関する不安だけが募る
  • これまた社会復帰したときのポジションが「webアプリケーションエンジニア」になってしまったら，自分は一体何のために金と時間を投資しているのだろうか

Keep

• 自分は他人と比べて体力も精神力も劣っていることを忘れずに，どんなに忙しくても睡眠時間は確保する
  • 20代の若者とばかりつるんでいると手前まで若くなった気になるが，現実は残酷である

Problem

• 以下が全くできていない
  • ジョギング再開
  • 9ccの作業時間を毎週少しでも割くようにする
  • 就職に向けたSWEリハビリ

Try

• 以下の優先度で再開する
  • 就職に向けたSWEリハビリ
  • 9cc作業再開
  • ジョギング

まとめ

• 大学院入学依頼，最も厳しい一ヶ月だった
• しかし，そのまま修論につながるレベルのoutputは出せた（多分）．無駄足を踏んでばかりいた訳ではない（と信じたい）．

じぶん Release Notes (ver 0.33.1)

個人開発

DE10-Lite

• FPGAを勉強したくてDE10-Lite買った

  • ソリトンウェーブで購入したが，学生なのでアカデミア価格で買えた*1
  • 最終的にはFPGA上で簡単なマルチパーセプトロン，ゆくゆくはcNNもFPGA上で実装して，ホントに量子化したNNの推論が高速に動作するのか確かめたい
  • まずFPGAボードで学ぶ 組込みシステム開発入門［Intel FPGA編］の第1章を読んで，FPGAの概要，歴史，FPGAの構造について学んだあとにQuartus PrimeのLite EditionをVirtualBox上のUbuntuにセットアップした
  • 現在の進捗として，この本の第2章の課題である60秒計を実装して動作させるところまではできた
  • しかし，後述するように5月中はあまり時間が取れなくてほとんど触れなかった
  • 簡単な時計を作るにしても，動作クロックを考慮して内部カウンタを用いて「1秒を測る」というアプローチを通じて，動作時のタイミングを考慮して実装しなければならない，という電子回路独自の概念を学んだ
  • あと，verilog HDLのif文はifブロック内部に2行以上処理を書けないということを学んだ*2

• my9cc

  • 研究が忙しく，今月は作業できていない
  • 大変よくない状態だが，SWoPP2019の予稿を書き終えるまでは再開できそうもない

読書

読み終わった

• 研究者としてうまくやっていくには　組織の力を研究に活かす (ブルーバックス) 長谷川修司
• コンパイラの構成と最適化 最適化周りの8, 9章だけ読んだ
• はじめての論理回路
• 信長のシェフ 7巻
• 信長のシェフ 8巻
• 信長のシェフ 9巻
  • 武田信玄がかっこよすぎてつい9巻まで買ってしまった．
  • アホみたいに買うと漫画購入費で破綻しそうなので信長のシェフは1ヶ月に1冊のペースを守っていきたい
• アルキメデスの大戦（１４）

読んでる

• コンピュータアーキテクチャ技術入門
• Cracking the Coding Interview
• FPGAの原理と構成
• FPGAボードで学ぶ 組込みシステム開発入門［Intel FPGA編］

研究

• 連休中は作業がかなり捗るという発見をした
  • 普段の研究室も静かで良い環境なのだが，MTG等のイベントが一切ないことが保証されているというだけで心理的なストレスはかなり減る
  • おそらくは，そのイベントのための準備とか，イベントに遅刻しないようにするために時間を気にすることに無意識のうちに相当なパワーを使っているためだと考えられる
• 一方で，連休中にガーっと実装したやつを評価したら思ったようなパフォーマンスが出ずに窮地に追いやられた
• しかし，5月いっぱいかけて地味にホットスポットを探してパフォーマンスチューニングし，なんとかベースラインの実装よりは良い性能が出せそうな見込みが出てきた
  • Pythonでの並列プログラミングは色々罠があって大変である

• 5月31日現在，何とか諸々の問題は解決できて，6月からは評価と論文執筆に集中できそうである

  • いろいろ詰みそうになったが，その度に原因を調査して問題解決する胆力は大学院に入ってから少しは伸びたのではないかと思う

• 研究の副産物として，動作検証用のPythonコードをいくつか書いてgistに放流した

chainer iterator_statemachine examination · GitHub

python mulitprocessing.Queue test for each Context · GitHub

python mulitprocessing.Queue test for each Context. See also https://gist.github.com/serihiro/bb9614b816b9c35e95ec4b53d3382f72 · GitHub

勉強

• 研究が忙しくてほとんど何もできていない
• ただでさえ就活が近づいてるというのにソフトウェアエンジニアとしてのリハビリが何もできてなくてやばい
• AtCoderも今月は1回ABCに出ただけかな．よろしくない．
• 単純な幅優先探索が実装できなくて痛い目を見たので，グラフアルゴリズムは少し復習した

Keep

• 適度な息抜き

Problem

• いつも走ったり歩いたりしているコースに羽がある系の虫が増えてつらい
• 忙しいのでついサボってしまい，結局ジョギング再開できておらず，体重が減らない

Try

• ジョギング再開
• 9ccの作業時間を毎週少しでも割くようにする

まとめ

• かなり厳しい一ヶ月だったが，その分進捗もあった
• 来月は，6月末にSWoPP2019の予稿の締切があるのでそれに向けてがんばる

*1:買ったあとに気づいたが，OpenCLのBSPに対応してないFPGAなのでDE10-Nanoの方が良かったかなと思ったが，値段が5,000円ぐらい違うのでまずは安いFPGAでverilog HDLで実装する修行をするのだ

*2:論理ブロックで条件分岐を実装してるためと考えられるが，普通にプログラミングしてると意識しないところなのでコンパイルエラーになって結構悩んだ

じぶん Release Notes (ver 0.33.0)

じぶん Release Notes という月報のような取り組みを知ったので自分もやってみる．

blog.a-know.me

個人開発

github.com 低レイヤを知りたい人のためのCコンパイラ作成入門を見ながら少しずつ作っているCコンパイラ．平日は日中は研究で疲れてほとんど進んでいないが，余裕があるときや土日に少しずつ進めている．

現在サポートできている機能は以下の通り

• intの四則演算
• カッコ対応
• 変数定義，変数代入，変数を使った四則演算
• 関数呼び出し

まだソースファイルの読み込みに対応してないので，コードを直接標準入力で受け取ってx86_64アセンブリを標準出力に出力する．

❯ ./9cc '(1+2) *3;'
.intel_syntax noprefix
.global main
main:
  push rbp
  mov rbp, rsp
  sub rsp, 208
  push 1
  push 2
  pop rdi
  pop rax
  add rax, rdi
  push rax
  push 3
  pop rdi
  pop rax
  mul rdi
  push rax
  pop rax
  mov rsp, rbp
  pop rbp
  ret

最終的にはセルフホストまで達成したい．今後も研究と平行して地道に進めていきたい所存．

github.com LSTMの訓練用データセットとして，Moving-MNISTのような20フレームで１セットのシンプルな動画のフレームを生成するCLI．

壁にあたって跳ね返るところの移動方向の更新がちと面倒だったが良い経験になった． 画像の描画にはPillowを使用しnpy形式で出力される．

読書

読み終わった

• 企業の研究者をめざす皆さんへ
  • 現在はPFNでフェローも務める丸山 宏氏のIBM研究所時代の経験を元に，企業研究者としての心構えや在職中に学んだこと，マネジメントに関することなどを紹介している
  • 自分自身は研究職に興味がある訳ではないが，研究のテーマの探し方やプレゼンの仕方などが参考になった
• 放課後ていぼう日誌4巻
• ゆるキャン△8巻
• 信長のシェフ6巻

読んでる

• コンピュータアーキテクチャ技術入門
• コンパイラの構成と最適化
• はじめての論理回路
• Cracking the Coding Interview

研究

• Entropy-Aware I/O Pipelining for Large-Scale Deep Learning on HPC Systems
  • 分散訓練を行うときに訓練データセットを各計算ノード上で実行するキャッシュサーバにフェッチしておき，オンメモリで訓練データをワーカに読み込む Deep IOの提案と評価
  • 全訓練データセットのリストを生成し，計算ノードごとに領域を分割してメモリに載せてノード上のメモリにある訓練データのみを使って訓練する
  • 1 epochが終わったら訓練データセットのリストをシャッフルし直すが，その時にディスクから読み直すのではなくノード間のメモリ上のデータをRDMAで交換することで高速にシャッフルできる点がポイント
• Characterizing Deep-Learning I/O Workloads in TensorFlow
  • TensorFlowのFileSystem APIの解説とI/Oの評価用にベンチマークとミニアプリケーションを実装して評価した話
  • 訓練データの読み込みとcheckpointingの時の書き込みの２種類をストレージ別に評価している
• ChainerのMultiProcessIteratorのn_processを変えた時の100 iterationの訓練に要する時間への変化を評価したりしてた（データセットの格納先はノードローカルのNVMe SSD）

解像度別のImageNetの画像セット作るのが地味に面倒だった

• 論文にできそうなネタが見つかったのでその評価実験をずっとやっていた

• 研究室のcompactionとかいろいろあって雑用が大変だった

勉強

• 今月は次の研究テーマを決めるために集中してサーベイしたり予備実験をしていて自分の勉強はほとんどできていなかった
• 来月はコンパイラの実装とFPGAでロジックを実装するための勉強を進める

その他

• 箱根本箱というホテルを知った
  • めっちゃ良さそう
  • １日引きこもってコード書いたり論文読んだりするリフレッシュに良さそう
• SEKIRO買って一周目クリアした
  • 一周目は竜の帰郷ルート．お米は大事．
  • 完成度が非常に高い
  • 操作性が非常に良くてチャンバラが楽しい
  • 久々にシングルモードしかないゲームで楽しいと思えた
• 花粉症がようやく落ち着いてきたのでそろそろジョギング再開したい
• 講義がなくなって自由な時間が増えたので，昼食後に2kmほど学内を散歩するようにしたら体調が良くなってきた
• 某社インターンへの応募

Keep

• 昼食後の散歩
• Cコンパイラ実装

Problem

• 疲労で勉強が全く手についていないので毎日少しずつでも進めるようにする
• 疲労が溜まりやすくなってきたので夜は23時までに寝て睡眠時間を7.5時間以上確保する

Try

• ジョギングの再開

まとめ

4月は研究室の雑用やら次の研究テーマ決めのためのサーベイや実験で慌ただしく過ごしていたらあっという間に終わってしまった感がある．かけた時間の割には思った以上に進捗は少なく，勉強については全然できていないことに気づいた．土日もどちらかは研究室にいて作業をしており，少し研究に時間をかけすぎていたように思うが，おかげで次の研究テーマになりそうなものが決まったので，５月はその研究を進めつつ，自分の勉強にも毎日少しずつ時間を割くようにしたい．

散歩コースの途中にある桜

2018年をふりかえって

今年は仕事を辞めて大学院生になったりして変化の大きい年だったと思う。 例年のように振り返ってみる。

1月-3月

今年で一番忙しかった時期だと思う。引っ越しと入学手続きと退職の３つが重なり、まさに「公私共に忙しい」というやつだった。今考えると、大学卒業以来初めて仕事を辞めるという大きな変化のタイミングではあったのだが、感慨に浸る余裕もなく、ただ大量のタスクをこなすだけの毎日だった。

仕事の方は3月頭ぐらいまで結構デカい機能の開発をしたりしていたが、並行して引き継ぎ資料を大量に作っていた。在籍中は普段から知識がブラックボックスにならないようにドキュメントはこまめに書く方だったが、それでも引き継ぎ資料を書いていたら、結構自分しか知らなそうなことが残っていたのを発見したりして、完全なオープン化は難しいとつくづく感じた。もっとも、前職ではほぼ一人でクレカ決済用のマイクロサービスの設計と実装をしたり、社外システム連携の調整と設計と実装を複数案件やっていたりしたので、多少ブラックボックス化してしまうのも無理もない仕事内容だった気がするが。

東京を離れる数日前に家の近くで撮った桜

4月-6月

筑波大学院での生活がスタートした。最初は朝から夕方まで講義出てたらめっさ疲れるかなと思ったが、会社員時代よりは楽だったようでそこまで肉体的にはキツくはない、というのが最初の数週間の印象だった。
講義はとりあえず難易度を気にせず、シラバスを読んで面白そうなやつを片っ端から取ったら、どうも取りすぎてしまったようで6月末ぐらいにレポートラッシュがやってきて軽くヤバかった。秋学期も講義取りすぎてヒーヒー言ってるのでこの頃と比べても何も進歩していない。それでも受講した講義は全部単位が取れたのでまぁよかった。

serihiro-graduate-school.hatenadiary.jp

研究の方は「HPCで深層学習を何となくやる」以外の何もテーマが決まっていなかったので、事前調査のためにTensorflowやChainerMNのホワイトペーパーを読んだり深層学習関係の本を読んだりしてデータ並列とモデル並列とは何かみたいなことを調べていた。結果的に、この辺の並列深層学習ネタは現在研究のスコープから外れているのだが、計算ノード並べて同期データ並列でスケールさせるのが現在の世界的なトレンドではあるようなので、そのベースとなるアイデアと実装方法をじっくり調査できたのは良かったと思う。

あと筑波大学内の計算科学センターにNVIDIAのV100とP100が刺さってる計算ノードで構成されたPre-PACS-Xという実験用HPCクラスタがあったので、そこでChainerMNのサンプルを動かしたりもしていた。ただ、研究テーマは全く決まらずに徐々に焦りを感じ始めた。同じ研究室のM1の学生は、学部時代から研究成果を出しており、その延長で研究を続けているため大学院でも研究の方向性は入学時点で決まっているようだった。一方で、自分は新参者なのでゼロからすべて考えなくてはならない。特に何も考えずにホイホイ大学院に来たはいいが、どこにでもいるウェッブエンジニアに過ぎなかった自分の場合、研究に関しては圧倒的なビハインドを抱えてのスタートだった。

また、研究室内ではB4,M1を対象とした輪講を週2でやっていて、「High Performance Computing: Modern Systems and Practices」というHPC関連の技術を網羅した本を読んだ。HPCというかコンピュータの歴史から始まって、HPCでよく採用されるNUMAなどのアーキテクチャの説明、B/Fの概念、Linpackなどのベンチマークの紹介、アムダールの法則を中心とした分散処理システムのパフォーマンスの話、OpenMPやMPIの使い方まで多岐に渡る内容だったが、マトモに計算機アーキテクチャを勉強したことがなかった自分にとっては本来学部４年間で勉強してくるはずの計算機アーキテクチャの基礎を一通り学ぶことができて大変為になったと思う。この本自体は結構表現が回りくどかったりして読むのが大変だったのが正直な感想ではあるが、これからHPC上で何か動かしたい人が必要な基礎知識を学ぶには良いと思う。

High Performance Computing: Modern Systems and Practices

学業以外の活動としては、大学院生らしくインターンに応募したりしていた。おっさんだし、まだ全然研究で成果を出してないのでまさか書類選考を突破できるまい、と思っていた企業の書類選考+コーディングテストを何故か通過して面接まで行ったりしまいビビり、面接では前職時代からよく読んでいたブログを書いていた人が出てきてさらにビビったが、紆余曲折あってこの企業のインターンには参加せずに、先にブログに書いたようにTreasure Dataのインターンに参加することになった。今年はインターンどうするかはまだ考え中だが、修論の進捗が良くて時間的に可能であれば、今年行かなかった企業のインターンに再挑戦してみたいものである。

森でしょうか

7月-9月

7月もまだ春学期の講義期間ではあったのだが、ほとんどの講義が6月で終わってしまうため時間ができた。
時間ができたからと7月から始まる神経科学の講義をうっかり取ってみたらかなり前提知識が要求される講義で全然ついていかなかったため、慌てて神経科学の本を一冊買って知識を補強することでなんとか単位をゲットした。

Fundamentals of Computational Neuroscience

結果的にはcNNのConvolutional層,Pooling層の処理と視覚野の処理の類似点や相違点などを学べたので面白かった。ニューラルネットワークの字の如く、本当に脳でやっている計算処理がベースなのだなということを改めて実感した。脳から模倣したのはパーセプトロンだけだと勝手に思っていたので新しい発見だった。

8月からはTreasure Dataのインターンに参加した。詳細は以前書いたエントリに詳しい。

serihiro.hatenablog.com

感想としては、久々に仕事をして純粋に楽しかった。大学に入って以来全く余裕がない日々だったので、このタイミングで学業から少し離れて、長年の馴染みのあるソフトウェア開発に没頭できたのはかなり精神的に良かったと思う。自分のキャリアとしてはBtoBのサービス開発(転職サイトの企業向けシステム、飲食店向け予約システム etc）に長く関わってきたという背景もあり、同じくBtoBであるTreasure Dataでの仕事はカルチャー面でやりやすかったと感じる。

10月-12月

1月から3月が一番忙しかった時期なのに対し、この時期は一番つらい時期だった。

何がつらかったかといえば、この時期にM1の学生は修論中間発表のようなものがあり、何人かのグループに分かれてそれぞれの研究進捗を毎週交代で発表せねばならない。*1別段、研究がちゃんと進んでいればビビる必要はない。しかしだ、自分の場合は自分の発表の番が回ってくる2週間ぐらい前まで、人に話せるような内容の研究ネタがなかった。先に書いたように、先行研究のサーベイをしてChainerで遊んでいましたという話ならできるのだが、それは研究ではない。他の学生がどんな発表をしているかというと、一番進んでいるものではすでに学会で発表済み、そうでないものでも、最低限何らかのアイデアはあって、そのアイデアを実現するための何らかの実験を行ってその結果を報告している、というものだった。つまり自分のようにサーベイだけしてました、という進捗は自分のグループ内では報告されていない。それを見て実にヤバいということに気づいてしまった。

自分でアイデアを出して研究ができないのなら仕事辞めてまで大学院に来た意味はあるのか？そもそも入学できてしまったことが間違いなのではないか？みたいなことも考えてしまい、この時期は随分とどんどん悪い方悪い方に考えが向かってしまっていた。

なので今は開発をやりたい欲求をこらえて研究すべきなのだろうなぁと思うのだが、如何せんサラリーマン的思考が抜けなくて、研究でやろうとしてるとに意味があるのかどうかということばかり気になって板挟み感ある。。そのうち慣れるんかな

— Kazuhiro Serizawa (@seri_k) October 4, 2018

しかし、そうは言ってもアイデアがないものは仕方がないので、ホントに春学期に読んだ論文の紹介でもするしかない。。と思っていた矢先、Chainerで遊んでいた時に偶然にもプロファイルしていたGPUのプロセッサ利用率とChainerのログから算出した1 iteration辺りの処理時間の相関性から、とあるアイデアをギリギリで思いつき、そのアイデアをChainer本体で実装することを最終ゴールとした内容でどうにかこうにか自分の発表をまとめることができた。やれやれである。
この発表の前の週はロクに眠れずにかなり肉体的にも精神的にもキツい思いをした。春学期の講義ではまぁ良い成績が取れていたので完全に油断していたが、大学院の修士課程というのは研究を行い、あわよくば対外発表もして、最終的に修士論文としてまとめることが目的の場所である。なのでこういったチェックポイントが必ず存在する（次回は来年7月の中間発表）。それを忘れてはならぬと肝に銘じさせる出来事であった。

しかしまぁ、上記の出来事から1ヶ月ぐらい経った今時点でも、これが研究になるのかどうか全く自信がない。自分の指導教官も深層学習が専門ではないので具体的な助言ができないようなので、全て自分で考えて進めていくしかない。自分に何か強みがあるとしたら、馴染みが薄い言語やプラットフォームでもキャッチアップするのが多少人より早いぐらいのものなので、とにかく今は自分のアイデアを実装して、動くものを使って客観的な評価を行い判断するしかない。

講義の方は相変わらず取りすぎてしまい、春学期同様に期末のレポートラッシュを先週、今週と乗り切ったばかりである。ただ、秋学期は実装の課題が多く、その辺は論文要約や論述ばかりだった春学期よりも楽ではあった。まぁ論文要約の講義もあったのだけど、最近は流石になれてきたのか英語の論文も大分早く読めるようになった気がする。英語に慣れたというよりは論文そのもののフォーマットに慣れて、どこをどう読めば抑えるべきポイントが分かるかが分かった、という感じである。春学期の頃はとりあえず全部精読していたが、今はもう少し効率の良い読み方ができるようになった気がする。多少は進歩したのかもしれない。

総括

• 学業については計算機アーキテクチャ周り、並列処理、分散処理に関して新しい知識が多く得られて良かった
• 研究については先に述べたようにまだまだこれからという感じで、今年は何も成果を出していない
• 私生活については会社員時代と変わりはない

*1:筑波大生向けに説明しとくとCSセミナーの話である

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

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

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

特に、ソフトウェアエンジニア(以下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 さんの２人にお世話になった。

インターンの成果

Treasure DataのMountain Viewオフィスで行った成果発表プレゼンに使った資料にまとめまっているのでこちらを参照。なお日本オフィス側にもZoomで配信しながらプレゼンを実施した。

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

github.com

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

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の勉強を再開する*2のとオンライン英会話サービスとかを始めようと思っている。

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

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

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

所感

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

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

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

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

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

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

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

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

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

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

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

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