トップ > 日記

2017年のエンジニアリング振り返り

日記

はてなに入社して4年経った。

2017年のエンジニアリング活動を一言でまとめてみよう。

時系列データベースの開発にはじまり、なぜかIPSJ-ONEで登壇し、その後IPSJ-ONEでの構想をベースにはてなシステム構想を考え始め、ウェブサイエンス研究会でストーリーとしてまとめ上げつつ新たな可能性に気づき、それを実践していく場としてウェブシステムアーキテクチャ(WSA)研究会を立ち上げた。

一方で、仕事では、昨年の振り返りに書いているように、エンジニアとしての専門性を発揮する機会が薄れてきたという問題意識が、いよいよ深刻な課題へと変貌したように感じている。それも残念ながら自分一人だけの問題ではなくなってきた。 この課題をエンジニアリングそのものではなく、人間のスケールアウトでは解決できない、組織アーキテクチャの課題であると捉えている。 組織アーキテクチャの課題を解くための鍵は、今のところ「未来を定義する」「未来に向かって集中して取り組める環境をつくる」ことだろうと仮定している。 前者の未来については前述のシステム構想があり、後者の方法論として今年実践する機会のあったプロジェクトマネジメントがある。

したがって、来年は、今年構想したビジョンを技術と組織の両輪を回し、実現し始める、ということが目標になる。 そしてその裏には、エンジニア個人としては技術を作る技術をやっていきたいと思いつつ、生活時間の大半である業務の課題はマネジメントであるというギャップをどう埋めて一つのストーリーとしていくかが重要になるだろう。

ここまで、いきなりまとめに入ったのだけれど、2017年に力を注いだ各トピックについて細かく振り返ってみる。

  • 時系列データベースの設計・開発・運用
  • 学術研究のアプローチとの出会いとビジョンの構想
  • プロジェクトマネジメント
  • アウトプット

時系列データベースの設計・開発・運用

このTSDBのオレオレ実装を、半年毎日コード書いて頑張っていたのだけど、リリース前に疲弊しまくって睡眠もうまくとれなくなってしまったので、途中までになってしまった。https://github.com/yuuki/diamondb/ 個人でやるプロジェクトとしては、ひと通り動くまでに時間がかかりすぎ、細かくロードマップを引きづらかったので、サーベイを続けて、新たな課題を発見し、その課題を小さく解決する手法を編み出したい。

TSDBの開発は、大きな成果だと思っており、この知見を横展開するために、より汎用的なアーキテクチャにできないかと考えたのが、TimeFuzeアーキテクチャ構想だ。

時系列データベースに限らず、大規模な計算機システムのモニタリングを支えるデータ処理アーキテクチャが好きなので、今後のライフワークとしていきたい。

学術研究のアプローチとの出会いとビジョンの構想

突然だけど、id:matsumoto_r (まつもとりー)さんの昨年の振り返りをみてみよう。

さらに、id:y_uuki さんとは今年1年非常に仲良くさせていただいて、12月はなぜか毎週会って何かイベントごとをこなすようなぐらい、企業・アカデミア方面で関わることが多かったように思います。いつか、企業とアカデミアの両方の要素を含む新しい研究会みたいなものを一緒に作っていけるといいな、ぐらいに一方的に信頼しており、色々と今年は無茶をお願いしましたが、できるだけその無茶をちゃんと責任をもってサポートできるようにしたいと思います。

エンジニア・研究者とはどうあるべきか - 2016年振り返りと新生ペパボ福岡基盤チームの紹介 - 人間とウェブの未来

今年は、まつもとりーさんのおかげもあって、学術研究コミュニティとの関わりが深くなった年だった。 前述の 高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ に始まり、まつもとりーさんの5年間の挑戦の最後を見届け matsumotoryさんの博士学位論文公聴会に参加し、見て聞いて考えたこと - ゆううきブログ、ペパボ・はてな技術大会では考えたビジョンをみてもらって、自分なりにウェブシステム全体をみてストーリー化し、それに対して議論していただいて、最後は「企業とアカデミアの両方の要素を含む新しい研究会」としてウェブシステムアーキテクチャ研究会を一緒に立ち上げることができた。

その中で気づいたのは、学術研究のアプローチにより、ウェブシステムの分野におけるある種の限界を突破できるかもしれないということ。 ここでの限界というのは、同じことの繰り返しで積み上げによる進化をしていないじゃないか感と、シリコンバレーの巨人の西洋技術を取り入れるだけで自分たちの存在価値とはなんなのだろう感を指している。 それらに対するアプローチは既にあり、前者は体系化、後者は徹底したサーベイと自分なりの思考からの新規性ということになる。 このあたりのよもやまについてはTwitterにあれこれ書いていた。

ちなみに、学術研究のアプローチを企業でのエンジニアリングに導入することで何が起きるかについては、まつもとりーさんの下記の2つの記事にすべて書かれている。*1

なにより重要なのは、そもそもなにがやりたいのかという自分の欲求と、それが実現したらどんな世界になるのかをイメージすることだとまつもとりーさんは何度もおっしゃっていた。*2 前者はともかく後者はまあいいんじゃないと思いがちだし、実際何度もそう思った。 特に現場の泥臭い運用をやっていれば、なおさらそう思う。 しかし、前者だけであれば個人の趣味でしかないので、食べていくために仕事をしないといけないとなると費やせる時間は限られる。 そこで、欲求が世界にどう作用するかを考えることで、やりたいことを仕事にできる...はず*3。

こういうことをずっと考えていた1年だった。 こうしてちょっとずつ自分なりの道をつくりつつあるのも、まつもとりーさんのおかげだなあとしみじみ思います。いつもありがとうございます。

プロジェクトマネジメント

時系列データベース開発とクラウド移行のプロジェクトを丸ごと任された結果、物事を前に進めるための条件というものがあることを体感で理解したように思う。 これをウェブオペレーションチームの一部で実践しはじめ、小さな範囲でうまくできそうだということがわかってきたので、来年はチームというか部署全体で適用していきたい。 これらについては、まだアウトプットしていないのでどこかでアウトプットしたい。daiksyさんの薦めで、RGST2018に応募していたのだけど、残念ながら選考で落ちてしまった。

SREの分野のマネジメントって、SRE本以外に世の中に知見があまりなく、逆にチャンスだと思うが、自分が追求することではないと思っているので、誰かこれをはてなで追求したい人がいないかを探している。

アウトプット

OSS

以前開発していたdrootが、[capze](https://github.com/yuuki/capze]とともにオンプレミス上の大きめのサービスで稼働しはじめ、明らかになったバグを修正したりしていた。

アーキテクチャ設計に関わった GoとMySQLを用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ では、id:tarao さんにより Fireworq として実装され、公開された。今、1200 starsとかになっていてすごい。

ブログ

登壇内容をベースにそれをできるかぎりしっかり文章にまとめるということをやり続けている。 なぜかというと、アウトプットのスケーラビリティを非常に強く重視していて、登壇資料はあくまで当日その場のためのものであり、文章として後に残すことが自分のためにも重要だと考えているためだ。 最小のインプットで最大のアウトプットが鉄則。

登壇

過去最多の11本。とはいっても、数とかどこで登壇したかは問題ではなく、何を考え何を話したか、それぞれの登壇に何かしらの挑戦があったかが重要だと思う。

あとがき

エンジニアとしてやりたいことと、仕事で実際にやっていることとの乖離が大きくなってきた。 そもそも、仕事ではだいたいその場しのぎの解決しかできず、あとは家に帰ってがんばるということがこれまでほとんどではなかったかとすら思う。 世の中のすごいエンジニアもみんなそんなもので、もっとたくさんのプライベート時間を費やしているか、技術力が圧倒的だから少ない時間できれいに解決できるに違いない、自分はまだまだなのだという気持ちでいたのだけど、どうやら必ずしもそういうわけではなさそうだと感じはじめた。 人が増えれば解決するはずだと、信じていたが脆くもその願望が打ち砕かれつつある。サーバ増やしてもスケールしないのと同じでアーキテクチャの問題。

乖離を埋めるためには、どうしたらいいのか。 技術力を発揮するというより、組織やプロジェクトをマネジメントすることが必要だと自分で導出してしまったため、矛盾しているような気もする。 マネジメント、あれほどやりたくないと言っていたのだけど、それが課題となればやるしかない。

自分の技術力向上については、WSA研を目安に研究志向でアイデアをOSSとして実現しつつ、より高みを目指したアウトプットとして論文を書いていきたい。

最後にid:tomomiiさんの縁側トーク 道をつくるを載せておき、来年また思い出せるようにしておく。tomomiiさんに道の概念を話してもらってから、自分の道とはなにかということを頭のなかでずっと考えている気がする。

*1:前者は僭越ながらはてなブログ大賞に選出させていただきました。

*2:イメージすることについては、以前書いた記事で紹介させていただいた、イメージできることを実践するを連想する。

*3:本当はもうすこし深い意味があると思うのだけど、現状はこういう理解でいる

高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017

日記

名古屋大学で開催されたIPSJ-ONE2017 で登壇しました。 IPSJ-ONEというのは、情報処理学会の各研究会から選ばれた日本の若手トップ研究者17人が集まり、自身の研究を高校生でもわかるように発表するイベントです。 1000人ぐらい入る講堂で、しかもニコニコ生放送で配信されるというとても大掛かりなイベントです。

ちなみに、昨年は、同じ研究会からの推薦で、 id:matsumoto_r (matsumotory) さんが登壇されています。 IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来

発表

「高度に発達したシステムの異常は神の怒りと見分けがつかない」という、一見何の話かわからないやばそうな話なんですが、大真面目に話してきました。

スライドを以下に公開しています。ただ、スライドだと何の話をしているかおそらくわからないので、ニコ生のタイムシフト試聴でたぶん一週間くらいは動画をみれるようです。 http://live.nicovideo.jp/watch/lv289955409#6:40:12 (その後におそらくアーカイブされるはず？)

IPSJ-ONEの趣旨として、登壇者個人の成果や考えを表に出すことを求められており、実際には会社やチームでやっていることの中で、僕個人がやっていることについて話をしたつもりです。

5分の発表なので、10秒レベルで無駄を削って、エッセンスのみを抽出しました。特に、一般の方がわかるような内容であることに最重視しており、専門用語を使わないように徹底しました。

内容と補足

補足を追加した内容を以下に書き留めておきます。

インターネットのシステムは、24時間365日動き続けることが求められている一方で、人手による運用でカバーしている部分がたくさんあります。 これをどうにかしたいと思って、全自動化へ向けて頑張るんですが、全然うまくいきません。 なぜうまくいかないのか。それは、自動化に対する恐れがあると考えています。 実際に現場では、このオペレーションを自動化したいけど、本番にいれるのはかなり検証つまないと怖いよね、というような話を頻繁にしています。 もちろん、開発工数がとれないとか別の次元の話もありますが、怖さを取り除くまでに手間がかかると言い換えることもできます。

なぜそんなに恐れるのか。今のインターネットのシステムは、極めて高度に発達しており、生物/自然を連想するような複雑な系をなしています。 この自然は普段はおとなしいですが、時として天災のような異常となって我々人間に襲いかかってきます。 情報システムの場合は、システム障害ですね。 このような異常が発生するために、人は未知に対する恐れを抱いてしまいます。 これに似た構造があり、古来より人々は、例えば神話のような世界で、未知の異常を神の怒りと表現していました。 実際には、雷や地震といった災害になるかと思いますが、今ではこれらの現象が神様の仕業だと考えることは少ないように思います。 そのギャップを埋めたものは何かと考えたときに、思い浮かんだのが、「観測」でした。

「観測」することで、わからないものがわかるようになった事例はたくさんあります。 情報システムの世界では、「観測」にあたるものを監視と呼びます。 監視というのは、人間でいうところの健康診断に似ていて、人間の場合は、体重とか血圧とかその他もっと細かいメトリックを計測しチェックします。 ウェブサービスのような情報システムの場合は、CPU利用率とかメモリ使用量とかそういったものになります。 これらの情報をなるべく頻繁に大量に集めるためには、専用のデータベースが必要です。いわゆる時系列データベースというものになります。

このデータベースの課題として、お金と性能というトレードオフに取り組んでいます。 観測により、自然科学の観測のような世紀の大発見があるわけではなく、ソフトウェアのバグだとかリソースが足りないとか、相対的に価値の低いものしか得られないので、お金が重要になってきます。 発表では、簡単にアイデアを紹介していますが、より具体的には サーバモニタリング向け時系列データベースの探究 / The study of time-series database for server monitoring // Speaker Deck をみてください。(ところで、ここからさらに発展した内容を5月にそれっぽい舞台で発表することになっています。)

さて、観測の次にやりたいことがあり、それは「実験」です。要は、コンピュータシステムの未知について、科学のアプローチを実施しようというような考えです。 実験というのは、Netflixの Chaos Engineering から連想しています。 ただし、Netflixの一連のツール群を使っているという話はあまり聞きません。本番に導入するにはやはりハードルが高いと感じています。 そこで、観測して得たデータを使って、システムモデルを構築し、シミュレーションのような安全な手段で、システム特性を明らかにし、弱点などをシステム本体にフィードバックするというビジョンを考えました。 ここは本当にジャストアイデアの段階で、例えばモデルって具体的になんですかと言われても答えられません。今のところ、フィードバック制御の理論あたりからヒントを得られないかと考えています。

このようなシステムを作って、人間をコンピュータの未知への恐れから解放したい、そう考えています。

神の怒りというのは、比喩ではありますが、単なる比喩ではなく話の根幹となるような話作りを意識しました。 観測と実験という概念は、最初から考えていたわけではなく、神の怒りからの連想ゲームから、うまく情報システムに落とし込める概念を見つけられたと思っています。

ipsjoneとは関係なく、昨年matsumotoryさんが発表されたなめらかなシステムとは違うものを提案しようとずっと考えていました。 (なめらかなシステムについては レンサバの常識を覆す「なめらかなシステム」に挑む──運用技術を学術研究して実際のサービスへ適用 - はてなニュース)

残念ながら僕は名前を付けられませんでしたが、観測と実験というのをテーマにこれからやっていこうと思います。

いただいた反応

別分野の研究者の方からおもしろかった、スライドがよいとフィードバックいただいたのはうれしいですね。 その他、また聞きですが研究者の方から、一番おもしろかった、我々は神の怒りと戦っていかねばならん、というようなコメントをいただいたと伺っています。 システムビジョンにも共感の声があり、思った以上に伝わっているという手応えを得ることができました。

登壇に至るまで

さて、そもそもなんでお前がそんな場所で発表しているんだという話ですね。 僕はそもそも研究者どころか、修士課程を中退しています。 そこからはてなに入社し、いわゆる現場で運用をやっているエンジニアをやっています。今月にEOLを迎えるCentOS 5の撤退みたいな10年前のシステムを相手にすることもやっていたりしました。 技術者としての実績はそれなりに積んでいるつもりですが、アカデミアにおける実績はほとんどありません。なぜこんな人間が採択されたのかは、今だによくわかっていません。

きっかけは、昨年の登壇者である matsumotory さんに、昨年の6月ごろに、IPSJ-ONEというものがあるので、登壇しないかと声をかけていただいたことです。そのときは、雑にいいですよみたいなことを言っていました。 そのときは、いつもの話で大丈夫と言われた記憶があるのですが、ある意味いつもの話ではあるものの、とんでもない無茶振りであることが後々わかってきます。 その頃はIPSJ-ONEというものがどういうものかあまりわかっておらず、matsumotory さんがちょっと前に登壇したやつぐらいの認識でした。 家に帰って改めて2016年の動画をみていたら、おいおいこれなんか違うやつなんじゃない？、そもそもトップの研究者が集まるとか書いてるじゃんって思いはじめて、その話を忘れていた11月ごろに、matsumotory さんから声がかかってきました。

今、声をかけていただいたDMを見直してみると、めちゃめちゃ大風呂敷を広げた上で、それを回収するみたいな方法で頑張ったのでそれがよさそうと書かれていて、本当にその通りになって笑ってしまいました。加えて、y_uukiが一番得意でかつ、そこに本番までに+アルファできるようなものを提案できると最高とも書かれていました。これも、僕の認識ではその通りになっていて、結果的に、DiamonDBの実装に加えて、観測と実験によるフィードバックループを回すというアプローチの紹介ということになりました。

しかし、最終的に自分のやっていることが世界にとってどういう意味があるかということを加えるとよいという話もあったのですが、ここは本番では組み込めなかった部分です。自動化されて、運用から解放されて、遊んで暮らせるようになるだけなのか？という漠然とした疑念はありました。科学の歴史をみてみると、例えば未知であった電気現象を逆に利用して、今ではコンピュータのような複雑なものを動かすことができるようになっています。そこからさらにメタなレイヤで、同じようなことが起きないかといったことを考えているのですが、これはこれからの宿題ということにします。

そこから、IOT研究会のほうで講演をしないかとという話になったので、招待講演させていただくことになりました。その経緯はブログに書いています。 情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ

ipsjoneの5分は、僕の発表経験でも3本の指に入る大変さだったので是非頑張ってくださいとも書かれていました。はい、がんばりましたよ。最初は、そんなに大変なことがわかっていなかったのですが、準備を進めるたびに、とにかく大変であることがわかってきました。僕の感覚では、6ヶ月連続200users以上のブログ書いたり、1000usersのブログ書くよりはるかに大変でした。

何が大変だったのか。今までのアウトプットは、自分がやったこととやったことを汎用的な視点で捉えるだけで済みました。 しかし、今回は逆に未来を描いて、自分がやっていることに紐付けるという、頭が痛くなるような手法でした。 しかも、それを一般向けかつLTで伝えることは、余分なものを削ぎ落として、専門家だからこそ難しく書きたくなるようなことを削っていく作業になりました

さらに、僕は自身のテーマというものが、そもそも固まっているわけではありませんでした。ざっくりWebオペレーション技術、SREといった職種/分野の専門性を高めているという程度で、会社の仕事とはまた別の軸で何をやりたいのか、ということを発表準備を通してつくろうとしていました。 テーマがなければ実績もないわけで、実績がある研究者はいいな〜と思いながら、matsumotoryさんの去年のスライドをみると、それまで積み上げてこられた実績が1ページにさくっと書いているだけで、あとはこれからやっていくことが書かれていました。

ようやく、matsumotoryさんの無茶振り具合がわかってきて、初見ハードモードで放り込まれたような気分になっていきました。matsumotoryさんには感謝しています。

ところでこれはトークが採択されたときのmatsumotoryさんの様子です。

f:id:y_uuki:20170321233516p:plain

あとがき

スライドだけみると、なんてことのない単なるライトニングトークにみえるかもしれませんが、その裏でいろいろと試行錯誤したことを記しておきたかったという気持ちで、この記事を書きました。

前述したように、最もこだわったことは、一般の方にちゃんとわかるように話をするということです。 見て動くような内容であれば、工夫をこらさなくてもなんとなく伝わります。我々がいつもやっているような、見えないものをどう伝えるのか、ということを深く考えさせられました。

実は、事前に社内の勉強会で発表したときは、驚くほど無反応でした。だいたい予想はしていたものの、考えすぎて全然だめなのかなーと思って、かなり落ち込んでいました。

しかし、そこから5分の制約を相手に、ボツスライドのほうが多くなるぐらいブラッシュアップを繰り返して、何度も練習して、全然専門家じゃないはずの両親がニコ生で発表をみていて、内容がわかった、わかりやすかったと言ってもらえたことで、発表してよかったと思えるようになりました。

フィードバックの数で言えば、普段書くブログのほうが圧倒的に多いです。しかし、普段のブログや発表はコンテキストを共有しているので、フィードバックが多いのは当たり前です。ちょうど id:Soudai さんが書かれているように、アウェーの舞台で伝えることに向き合った結果、伝えることの難しさ/うれしさを再確認できました。

敢えてアウェーで戦う事に意味があるって話 - そーだいなるらくがき帳

最後になりますが、ipsjone運営委員の皆様のご尽力には頭が上がりません。1回目を立ち上げるのももちろん大変なことだったと思いますが、その後「継続」することは、立ち上げ時の苦労とはまた異なる種類の苦労をされたのだろうと、「運用」を生業とする者としてご推察します。本当にありがとうございました。

2016年のエンジニアリング振り返り

日記

はてなに入社して3年経った。

3年というのは節目と言われる。働き方や考え方の軸が多少変わってきたように思う。 技術観点では、仕事が少しつまらなくなっていた時期があった。 技術的におもしろいことより、つまらないことのほうが優先度が高くなってしまうというよくあるやつだと思う。 もしくは、おもしろいところまで到達できずに、仕事としては十分な成果になってしまうということもあった。

去年の振り返りに、来年はコードを書くと書いていて、多少はできたものの実感としてはあまりできていない。これからのオペレーションエンジニア/SREは、ソフトウェアエンジニアリングによる問題解決ができないと時代に取り残されてしまうという危機感がある。

技術的挑戦を続けていくためには、自分だけでなく、周囲の環境も変えていかないといけないと思い、マネジメントし始めたり、リーダーシップをとったり、直接的な採用活動をするような局面が増えてきた。 それはそれで自分でやると言ってやっていることだし、悪くはないのだけど、これ自分でやっていればアウトプットもできるのになと思いながら、任せないといけないことも多かった。 慣れないことをやっていると、大したことやってなくても疲れるもので、アウトプット活動が止まってしまった時期もあった。

一時的にそういった期間があることは仕方ない、いつも最高の環境があるわけじゃないので、意識的に環境に作用できるようになれれば、それは自分の強みになると言い聞かせてきた。 最終的には、社内外の期待をかけてくださる方々にいくつかのきっかけをいただいて、来年は技術的に挑戦できる年になるという気持ちで年を越せそうだ。 サーバモニタリング向け時系列データベースの探究 / The study of time-series database for server monitoring // Speaker Deck に書いた設計を自分の代表的プロダクトにすべく、プライベートリポジトリでちまちまとコードに落とし込んでいたりする。 このあたりは、今年大変仲良くしていただいたid:matsumoto_rさんと、あとはMackerelチームのプロデューサーである id:sugiyama88 さんのおかげだ。

振り返ってみると、今年は次の挑戦のための土台づくりに専念した年かもしれない。

成長

内在的な技術的成長は多少はあったものの、アウトプットにつながっていないものは成長とみなさないことにしているので、今年は技術的成長があまりなかったといえる。

あえていえば、実際の運用で導入したKeepalivedのシンタックスチェッカーや今書いているソフトウェアの要素であるGraphiteの式のパーザーなど、これまで書けなかったタイプのコードを書けるようになった。トークナイザーとYACCを書いてるだけはあるけど。

あとは、はてなのこれまでのスタックにはないようなアーキテクチャを構築する機会がいくつかあり、アーキテクチャで解決するという手持ちの札が増えてきたように感じる。

技術以外の成長では、多少マネジメントをしたり、プロジェクト管理みたいなことを覚え始めた。SRE本の第18章"Software Engineering in SRE"にも書かれているが、インフラの領域でも、ソフトウェアエンジニアリングを本格的にやるなら、サービス開発のプロジェクト知見も必要なので、役に立つと思う。周囲の方々の助けもいただいて、多少の手応えもつかめた。

そして、今年一番の収穫は、ストーリーをつくるという意識かもしれない。 ストーリーというとプレゼンのようなものを連想する。もちろんプレゼンも含むのだけど、もっとこう自分の技術の取り組みのストーリーみたいなものを考えるようになった。 普通のエンジニアである僕がなぜか来年に登壇することになったIPSJ-ONEの演題を考えたり、研究会での登壇があったり、あとまだ公開されていない何かのためにまつもとりーさんの論文や口頭発表、ブログを読み返したことが影響している。 博士課程では、複数回のジャーナルを通して、最後にそれらをまとめるということをやるようなので、その手法にも影響を受けている 博士課程の予備審査にいってきました - 人間とウェブの未来, NAKAHARA-LAB.NET 東京大学 中原淳研究室 - 大人の学びを科学する: 博士論文とは「構造を書くこと」である!?。 自分のストーリーがあれば、次に何を勉強するかも決まってくる。 僕のように瞬発力とか手の速さで勝てない凡人は、ひたすら考えて、自分のやってきたこと、これからやることを繋いでいくしかない。

アウトプットまとめ

いつものようにブログやOSS活動を振り返る。

ブログ

いつものブログに加えて、今年から技術メモとしてGitHubにちまちまとメモを残していたりする。

順位 エントリ
1位 Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
2位 ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
3位 Googleが数千台もある10年前のLinuxディストリをライブアップグレードした話 - ゆううきブログ
4位 自作Linuxコンテナの時代 - ゆううきブログ
5位 インフラエンジニアがGo言語でオペレーションツールを書くことについて - Hatena Developer Blog
6位 2015年の心に残った技術エントリ - ゆううきブログ
7位 ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ
8位 2016年ウェブオペレーションエンジニアの新卒研修 - Hatena Developer Blog
9位 情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ
10位 2016年はてなWebオペレーションエンジニアのアウトプット - Hatena Developer Blog
11位 ウェブオペレーションエンジニアになるまでの思い出 - ゆううきブログ
12位 リモートワークにおけるSlack Call活用と終業15分前の雑談 - Hatena Developer Blog
13位 nginxのステータスコード444 · yuuki/yuuki
14位 nginxのステータスコード499 · yuuki/yuuki
15位 Keepalivedのシンタックスチェッカ「gokc」を作った - ゆううきブログ
16位 リバースプロキシのコンフィグテスト

合計 8000 users+くらい。

発表

合計8件。

OSS

f:id:y_uuki:20161231215324p:plain

Graphiteへのパフォーマンス改善PR。

go-sql-driver/mysqlのMySQL 4.0対応をして、MySQLプロトコルの知見を深めたりした。 https://github.com/yuuki/go-sql-driver-mysql

他には、ISUCON6予選の出題側としてGo実装とインフラまわりの手伝いをやったりした。

まつもとりーさんの振り返り にも書いていただいているように、今年はペパボさんのエンジニアの方々と交流させていただくことが多く、大変刺激になりました。 はてなの技術力が非常に高いと称していただいていますが、僕としてはどちらかというと我々はまだまだだなあと思っていて、ペパボさんの取り組みは、前へ進む勢いを感じさせられるというか、一本筋が通ってみえるというかそんな気がしています。 我々はまだ場当たり的に問題を解決していってて、このままではいけないと思い、はてなシステムについて考えてたりしている。

あとがき

他のエンジニアの方々の振り返りを眺めていて、たぶん自分より若い人の台頭がすごいなあと感心している。

悔しいので、負けないようにがんばろう。

今年もお世話になりました。来年もよろしくお願いします。

ウェブオペレーションエンジニアになるまでの思い出

日記

書籍「ウェブオペレーション」の中で、「ウェブオペレーションは技芸であり科学ではない」*1という言葉がある。 実際、その通りだと思う。 しかし、技芸というのはどうやって学べばよいのか。 教科書のようなトップダウンな知識体系を構築しようと試みようとしても、どうしても特定の組織に依存したり、特定の技術スタックに依存してしまう。

現時点では、体系立てて学ぶというより、やはりボトムアップに学ぶしかないと考えている。 「ウェブオペレーション」の内容も、基本はストーリー仕立てのエッセイ集になっているのは、そういうことだろう。

Hatena Engineer Seminar #7では、もともとウェブオペレーションの学び方の話をしようと思っていたが、前述のような事情で、自分(id:y_uuki)の場合の学んできたことを例として挙げることにした。 ウェブオペレーションエンジニアの前提となるスキルセットの作り方の一例として紹介する。LT資料なので勢い重視なのは許してほしい。

大学1年からLinuxを触り始めたときからはじまり、C言語を学び、ネットワークプログラミングを学び、アルバイトで巨大なCのプロジェクトをgdbを駆使してトレースしたり、はてなインターンにいったり、研究でSIMDとかGPUとかネットワークスタックとか触ってたり、はてなアルバイトでMackerelの前身を作ったり、子どものころを振り返ってみてシステムっぽいものが好きだったり、といった内容の話をした。

ウェブオペレーションエンジニアになった動機の一つに、教科書に書いてあるような古典的な知識が現場で活用されていることがおもしろいと感じていたことがある。 例えば、書籍「大規模サービス技術入門」*2では、MySQL(MyISAM)のテーブルファイルをあらかじめcatで読ませて、OSのページキャッシュにのせることで暖機運転がわりにする手法に感心したのを今でもよく覚えている。 このような考え方は、自分の技術スキルの方向性にも影響しており、2015年Webサーバアーキテクチャ序論 - ゆううきブログ や 自作Linuxコンテナの時代 - ゆううきブログ などに表れている。

わざわざ語るような大層な経験はなく、ごく平凡な来歴だなと思う一方で、アウトプットだけは人並み以上にやってきたという自負がある。ちまちましたことでも続けていれば、それなりの何かにはなるものだ。 もし今回の話に共感するところがあり、ウェブオペレーションやSREという技術領域に興味をもってもらえたなら、うれしく思う。

ちなみに僕の場合は、自然科学実験みたいな物理作業をとにかくやりたくなくて情報科学科に入ったので、「モノ」としてのサーバやネットワーク機器にあまり興味がないけど、なんとかやっていけている。

あわせてよみたい

同僚にはこういう変な人もいる。

*1:John Allspaw、Jesse Robbins編、角 征典訳,ウェブオペレーションーーサイト運用管理の実践テクニック,オライリージャパン

*2:伊藤 直也、田中 慎司,[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ), 技術評論社

情報処理学会でウェブオペレーション技術について招待講演した話

Monitoring TSDB 日記 Architecture

情報処理学会インターネットと運用技術研究会が主催されているIOTS2016という研究会で、「サーバモニタリング向け時系列データベースの探究」というタイトルで招待講演をしてきました。

講演のきっかけ

インターネットと運用技術研究会(以下IOT研究会)というのは僕にとっては id:matsumoto_r さんが所属されている研究会です。 matsumotoryさんが、ちょうど2年前のアドベントカレンダーで書いた僕の記事に日本語だとIPSJのIOTは分野的にもインターネットの運用技術が含まれるので興味深い論文が沢山あると思う とコメントしていただいたのが最初に研究会の存在を知るきっかけだったと思います。 そのときはそんなものもあるのかと思ってちょっとプログラムを眺めた程度でした。 しかし、まさかその2年後にこうして招待していただくことになるとはもちろん思っていませんでした。 id:MIZZYさんがserverspecの論文をだされた研究会でもあります。

きっかけは、今年の6月ごろです。 やはりmatsumotoryさんに講演とは別件のとあるびっくり無茶振りを受けました。 そして、少し前にIOT研究会へいくつかの資料を提出したところ、次のIOTS2016で講演してくれという話をいただきました。 IOTSがどんなものかわかってなかったのですが、査読付きで1年で1番大きな研究会であり、matsumotoryさんがそこで招待講演できるの羨ましいとおっしゃっていたので、じゃあやります、と答えました。

講演内容

講演するにあたって、当たり前のことですが、まず伝えたいことを考えました。 IOTS2016の開催案内をみてみると、「運用でカバーする」、「運用担当者の人柱の上に成立する前時代的で野蛮な構造物」、「不快な卑しい仕事をやる必要がなくなるのは、人間にとってひじょうな福祉かもしれないが、あるいはそうでないかもしれない」といったなかなか興味深いセンテンスが散りばめられていることに気づきました。 研究者と技術者という、コンテキストが異なるものの、同じ運用技術に携わっているという前提があります。 そこで、ウェブサービスの運用の世界で実際に起きていることと生の課題を伝えようと思いました。

これを伝えるための話作りには、いくつかの案がありました。 ひとつは、そのまま「ウェブサービスの運用の世界」といったタイトルで、ウェブオペレーションを概観する話をするというもの、もうひとつは、時系列DBやコンテナ型仮想化など特定の技術の話をするというものです。

最終的には後者にしました。 ちょうど時系列DBのアーキテクチャ刷新に取り組んでいるため、成長するサービスとスケーラビリティといういかにもウェブオペレーション技術っぽい話ができます。 自分がまだ大学にいた頃から取り組んでいたことであり、時系列DBの話をすることは自分がこれまでがんばってきた技術の話をすることにもなります。 さらに、研究会なのだから、論文にできそうなテーマならなおよいはずと思って、最新の取り組みを紹介したかったというのもあります。

だいたい話すことは決まっていたものの、ストーリー化することには苦労していて、2日くらい前にインフラチームの同僚何人かに見せたら反応が芳しくなかったので、同僚の意見を取り入れて、大幅にスライドを書きかえました。 無意識に研究発表的なスライドっぽくつくってしまっていた気がします。 トップダウン視点ではなく、自分視点に置き換えていって、アーキテクチャの説明はすべて図にしました。 会社としてというよりは個人として招待されたと思っているので、結果として自分視点になってよかったと思います。

matsumotoryさんには、見事に上記の意図をすべて汲み取っていただきました。

講演の導入には、まず異なるコンテキストのすり合わせをしようと思って、開催案内を引用させていただきました。 不快な卑しい仕事というのは、書籍Site Reliability Engineeringに書かれている"toil"に相当し、Googleでさえtoilからは逃れられていないが、toilではないエンジニアリングに価値を置いていると伝えました。 toilを消すことは、最近のエンジニアのコンテキストにおいても重要であり、そのような研究活動には価値があるということを暗にお伝えしたつもりです。

発表スライド

発表スライドを以下に貼っておきます。 あとで読む資料としてはまとまりがない点についてはご容赦ください。

若いと言われるが実際若くて平成生まれとか、IOTSの開催案内を会社の全体朝会で紹介したら社員のみんなが大喜びだったとか、アルバイト時代になんか癒やしとか言われてだまされてRRDtoolのCPANモジュールつくってたとか、入社するころにはRRDtoolは若者にはふさわしくないことがわかってきたとか、いつものように調子よくしゃべってたら笑いもとれたので、話をしていて楽しかったです。 以下のスライドがハイライトです。

講演を終えて

僕のことをご存知の方は、3年前に大学院を中退したことを覚えておられるかもしれません。 単に特定の環境とあわなかっただけというだけかもしれません。しかし、自身の体験だけでなく、社会人になってからも、大学の研究室で苦しんでいる学生たちの声を何度か聞くこともありました。 このこともあって、研究活動そのものはともかくとして、大学や研究室といった環境に強いネガティブな感情を今だにもっています。

今回の件は、大学から離れ、現場のエンジニアとしてがんばってきた成果をアカデミックな場で話すよい機会でした。 幸いなことに、思った以上に「話が通じる」という感覚を得られ、うれしく思いました。 もちろん、何を言ってるのかさっぱりだと思われた方も少なくはないでしょうが。 他の発表でもAmazon RedshiftとかKibana、Graphana、Elasticsearchなど見慣れた単語がとびかっていたので、安心感があります。

一方で、大学関係のシステムの運用を対象とした話がやはり多く、それらについてそれほど興味があるわけではありませんでしたが、おもしろく聴けた発表がいくつかありました。 特に柏崎先生の発表はとにかくいきおいのあるスライドというかこれは本当に学会発表か？と思うほどでした。 @hirolovesbeer さんの異常検知の話は質問したところ、イベントネットワーク以外にもサーバのログの異常検知にも使える可能性があるとのこと。

これ使えるなーと思ったものが論文優秀賞をとられていて、エンジニアの視点でよいものがちゃんと評価されるんだなと感じました。

ウェブオペレーションやSREに関する学術研究発表があればもっとおもしろく感じるだろうなと思います。 というのは、最近のウェブエンジニア界隈を眺めていて、それは本当に有用なのか、新しいおもちゃを使わされているだけになっているんじゃないかと疑問に思うことが増えてきて、真に有用な技術ってなんだろうなと考えたりすることがあるからです。

そういった考え方、アカデミックなアプローチで技術をつくるという方向性は自分の課題意識とマッチしているのではと思うことはあります。 博士過程へのお誘いもいただいたりしたのですが、前述のネガティブなイメージを払拭するのはすぐには難しいですね。 そもそも生半可な覚悟では社会人で博士号取得なんてできるわけないので、今後、「おもしろそう」「すごいことをやっていそう」「成長できそう」といった強いポジティブなイメージに転換できるかどうかが鍵になると思っています。

帰り際に、あのゆううきブログの中の人ですよね？と話かけていただいて、大学の中の人にまでリーチしているのかとちょっとびっくりしました。 大学を去ったその後に、大学の中の人に影響を及ぼしているというのは不思議な気分ですね。

この記事は、はてなエンジニアアドベントカレンダー2016の4日目の記事です。昨日は id:wtatsuru によるセキュリティ会の取り組みでした。 明日の担当は、buildersconで発表してきたばかりの id:shiba_yu36 です。

2015年の心に残った技術エントリ

日記

１年分の自分のはてなブックマークを見直した。 およそ 2,000 URLのエントリの中から、特に感銘を受けたり、記憶に残ったエントリを紹介したい。 2015年にブクマしたというだけで、必ずしも2016年に公開されたエントリばかりではないことに注意。

エントリ

Scalable Deployments

一昨年のRubyKaigiの講演スライド。 スクリプト言語のtar ballデプロイをみたのはこれが初めてだった。 大量のアプリケーションサーバに対するsshが遅いもしくは失敗する問題を、Serfを利用したpull型デプロイにより解決しているところがすごいアイデアだと思う。

Advanced Techinic for OS upgradeing in 3 minutes

昨年のYAPC::Asiaで直接拝聴したトーク。 前述のtar ballデプロイにも触れられている。 No sshという思想を軸に、目の前のアーキテクチャを変えずに確実に自動化していくという方法論が蒙を啓くようだった。

最近は、色濃い思想をもつ飛び道具系のツールがそこら中に飛び交っている。 いきなりそれらのツールを導入しようとした結果、自分も含めて、振り回されてしまう人たちにとって、一つの道標になる。

MySQLやSSDとかの話

前編と後編でセットになっている。 2000年代のMySQL運用から10年経った今というような視点で読める。 全く他人事ではないので、わかるわかると頷きながらスライドをめくっていた。

単に10年経ってつらいという話ではない。 ハードウェアの進化にあわせた最適な構成は何かということを考えさせるスライドだった。

モバイルアプリのスレッドプールサイズの最適化

コンピュータサイエンスの知識、ここでは待ち行列理論をモバイルアプリ開発に応用している例。 システムの振る舞いをモデル化して、検証するというサイクルを回せているのはすごい。 モバイルの人ってやっぱり計算機やネットワークのことはあまり考えないだろうという思い込みがあり、いい意味で裏切られた。

性能測定道

性能測定は技芸であり、技あるところに道ありとして、性能測定道というタイトルに行き着くまでの流れに魂みたいなものを感じた。 適当にベンチーマーク回して、最終結果の数値だけみて速いとか遅いとか言ってたりするんだけど、はたして本当にそれでいいのか。 性能測定のためにはシステムのブラックボックスを理解する必要があり、性能測定が本質的に難しいということを知れるだけでも、十分な発見だと思う。

情報科学における18のメタテクニック

キャッシング、パイプライニング、投機的実行、先読みなど、コンピュータサイエンスのあらゆるレイヤで利用される普遍的なテクニックを紹介したスライド。 切り口がよい。以前、Cache Nightとかやったらおもしろいんじゃないかとか言ってたことがある。CPUのキャッシュメモリからCDNまで幅広い話題がでてきそう。こういうレイヤを横断したトピックで、利用例を集めてみるのもおもしろいかもしれない。

Webオペレーションエンジニアのアウトプットと開発力

社外へアウトプットするということの大切さを再確認したエントリ。

自分は社内のインフラチームの中で最もアウトプットしているという自負がある一方で、自分一人ではなく、チーム全体のアウトプットを増やすにはどうしたらいいか悩むことがある。 悩みの中心はたぶんアウトプットに対する過小評価を感じている。 アウトプットの目的が単にプレゼンス向上のためだけだと社内で捉えられてしまうことがあり、揶揄も込めてプレゼンスばかりあっても意味ないという話で終わってしまう。 自分も気分が乗る人だけやればよくて無理することはないというスタンスだったんだけど、これで本当にいいのかと思うようになってきている。

改めてスライドを拝見して、アウトプットすることはより質の高い仕事をするためのステップ、もしくは成長のためのステップと捉えるのがよいのかなと思うようになってきた。

はてなに入った技術者の皆さんへ

10年前のエントリなんだけど、今でも全く色あせない。 matsumotoryさんのエントリとあわせて読むとよい。

僕たちが作るものは、会社の外から評価されることによって初めて価値が生まれるのです。

アウトプットに関しては、この一言に尽きると思う。 やはり社外へのアウトプットを単にプレゼンス向上とみなすのはもったないという気持ちが強くなってきた。

シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！

後輩のブログなんだけど、まさにお手本のようなアウトプット。 他人が利用できる形であり、社外でも評価され、なおかつ、裏では社内のサービスのユーザ体験まで向上させている。

ペパボのインターネット基盤技術研究・開発の活動

2年間の自分の仕事を振り返ってみても、基盤技術がボトルネックでサービス開発を妥協していることは少なからずある。 開発チームからの要求があったときに、それはちょっと厳しいから、この辺で妥協するかとかよく言ってる。

一方で、もし圧倒的な基盤技術が開発できれば、例えば、コストを10倍下げて、その結果ユーザが保持できるデータ量を10倍にできるかもしれない。 基盤技術の開発により、競合サービスに対してリードできないかという視点を持ち始めるきっかけになった。

これからのWebサービスは新規性のある技術を自ら研究・開発し、ググっても解決できない問題を自分たちで解決しなければ一歩リードする事ができない時代へと突入

インフラチーム改め Site Reliability Engineering (SRE) チームになりました

昨年、Site Reliability Engineeringという言葉を初めて知った。 通常、自分たちのことをインフラ部とかサーバ管理者とか運用チームとか呼んだりするんだけど、どうにも保守的というか価値を生み出す感がなかった。 はっとしたのは次の一文だ。

...SREがソースコードを追って原因を特定し、パッチを充ててリリースをすることもあるようです。 GoogleのSREの特徴として、ソフトウェアエンジニアとしての業務の比重が大きい事が挙げれます。業務時間の20-80%は開発の業務に関わっているようです。

別の記事にもSREの役割として近い内容が書かれている。

現に、コア原則の一つは SRE が運営の作業に費やせる時間を 50% のみにすることを義務付けています。彼らは、可能な限り最大限の時間をコード書きとシステム構築に費やして、業績と運営効率を改善しなくてはならないのです。

https://www.atlassian.com/ja/help-desk/site-reliability-engineering-sre

自分の仕事を振り返ってみると、運用に手間を割くことが多く、正直そんなにコードを書いているわけではない。 自分たちのことを運用チームと呼んでいたりすると、運用チームだから運用に時間を割くのは当然だと思ってしまう。 @rrreeeyyyくんがよく「運用を消したい」って言っているのとつながる。

エンジニアとしての落としどころを作る

本当にすごい人には勝てないんじゃないか、勝てないとだめなのかとか誰しも考える悩みに正面から応えたエントリ。 落としどころを作るというのは、つまるところ、自分はこれでいいのだなと思えるところを発見することなんだなと思えた。

イメージできることを実践する

技術エントリではないけれど、ことあるごとに思い出すエントリ。 他の人がやってるわけではないんだけど、なぜかイメージできるものというのは確かにある。 例えば、会社でいま存在しないんだけど、こういうポジションがあったらうまくやれそうだなとかおもしろくやれそうだとか、ポジションをイメージできたりすることがある。 このエントリを読むと、他の人がやっているかやっていないかより、自分がイメージできるものをやってみようと思える。

今明かされる! シンラ・テクノロジーのインフラへの挑戦と舞台裏

資料はおそらく公開されていないが、JTF 2015の招待講演は圧巻だった。 中身は、シンラ・テクノロジー（「オンラインゲームを支える技術」の著者である中嶋謙互さんが所属されている会社）のプロジェクトの紹介だ。 クラウドにレンダリングサーバを配備することにより、クライアントではハイスペックなマシンを不要にするアーキテクチャの話。（リモートレンダリングアーキテクチャ）

あまり話題にならなかったのが不思議だ。 GPGPUとカーネルのネットワークスタックにある程度明るくないとピンとこない内容だったかもしれない。 ネットワークレイテンシをできるだけさげるために、RDMAを使って、CPUをバイパスして、NICからGPUのメモリに直接パケットをコピーするとかそういう話。 実はオンラインゲームの基盤技術には昔から興味があったので、こういうのやってみたいなと思ったりする。

こちらのエントリにメモが書かれている。 July Tech Festa 2015 - したためなければいきのこれない

オンラインゲームを支える技術　　??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

オンラインゲームを支える技術　　??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

あとがき

id:toya さんが書かれた 2015年にブックマークしたURLでよかったものの中からブクマコメントに代えて - Really Saying Something にインスパイアされて書いてみた。

こうして振り返ると、ここに挙げたエントリの内容は、おもしろいように昨年の自分のブログの文章にも反映されているなと感じる。 何を考えて、この一年を過ごしたのかということが意外とはっきりと現れる。

他人の心に残るということは、それだけ月日がたっても色あせない何かがあるということだと思う。 今年も他人の心に残るようなアウトプットを心がけたい。

2015年も技術しかしてない

日記

今年も技術しかしてない。

やけにブログを書くことに傾倒していた。

26歳になった。

YAPCで発表した。

ISUCONに負けた。

入社２年過ぎた。

振り返ってみると、今年は技術でも仕事でもプライベートでも、ものごとやものの考え方は5年後、10年後はどうなるのか、変わらないものは何か、色褪せないものは何かを考え始めた年だった。 具体的には、例えば、単にブログを書いて、1カ月にN回書いたとかNブクマついたとか、対外発表の数をこなしてたくさん発表したねだけで終わるのではなく、その先に何があるのかを考えるといったことだ。 他には、5年後でも使っている技術はなにかとか、それを見極めるためには何を理解している必要があるのかといったこともある。 去年は若者らしくあまりそういったことは考えなかった。 たぶん、DockerとかHashicorpを使ってモダンなインフラを作るのがかっこいいと思っていた。 結局、いきなりそれらのツールを導入して、仮にメリットが１つ増えたとしてもデメリットが２つ以上増えることがわかり、技術というのはそういうものではないと悟った。 最終的にはそれらのツールの良い思想だけをいただいて、Dockerやめてchrootでいいとか言い始めることになった。 Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ

昨年の目標

2014年、技術しかしてない - ゆううきブログ 。

今年の目標はどうやら下記の３つだったらしい。

  • ツールを作る
  • 計算機システムの理解
  • インフラ系の若者と交流

ツールを作るというのはあんまりうまくいってない。目標にないはずのブログのアウトプットに大半を費やしていた。

ふたつ目の計算機システムの理解というのもそんなにうまくいかなかった。あまり書籍とか論文とかまとまったものを読めなかった。

インフラ系の若者とは交流成功した。大成功と言ってもよい。

wakateinfra Slackとかあって、毎日なんか会話してる。平和。

f:id:y_uuki:20151231210951p:plain

ブログの振り返り

昨年は28本のエントリを書いた。合計ブクマ数は 5,055 users、年間PVは 172,878 views だった。 今年は13本のエントリを書いた。合計ブクマ数は 5,409 users、年間PVは 198,381 views だった。 1エントリあたりの平均ブクマ数は 416 users / entry 。 去年は東京はもう古いとか書いてたけど、今年は技術しか書いていない。 昔はもっと量を書かないと、とか思ってたけど、量だけあって一ヶ月で廃れる内容を書いても自分で満足できないので、あとで振り返っても色あせないものを目指した。 自分が満足できるアウトプットかどうかが重要だと思う。 採用活動にも奇跡的にうまくつながったので、会社でそんな賞ないはずないのになぜかブログで求人賞みたいなのをいただいた。

順位 エントリ
1位 2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2位 Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
3位 はてなで大規模サービスのインフラを学んだ - ゆううきブログ
4位 Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
5位 Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
6位 Mackerelを支える時系列データベース技術 - ゆううきブログ
7位 Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ
8位 パフォーマンスの観点からみるDockerの仕組みと性能検証 #dockerjp - ゆううきブログ
9位 YAPC::Asia 2015で技術ブログを書くことについて発表しました - ゆううきブログ
10位 Serverspec + Mackerel APIによるインフラテストの実運用化 - ゆううきブログ
11位 ISUCON 5予選で5位通過した話 - ゆううきブログ

発表の振り返り

対外発表は確か３件だけだったと思う。

東京へ行く度に結構疲れてしまった反省をこめて、来年はピンポイントで興味のあるカンファレンスや勉強会で発表したい。

去年の感想によると、東京に疲れてた。今年はピンポイント感あってよかった。 セッションオーナーの話などをいただいたこともあったけど、申し訳ないと思いながらお断りしたりもした。

執筆の振り返り

去年まで雑誌に寄稿とかしたことなかったけど、気づけば今年はSoftware DesignとWeb+DBで執筆することになった。

雑誌の次はいつかは単著で書籍を書いてみたい気もするけどそれは来年とかではない。

OSSの振り返り

ツール書くとか言ってあまり書けなかった。

技術以外のことは何もしてない割にはアウトプットが少ない気がする。 発表やブログのアウトプットは、去年と今年でそれなりに満足したので、来年はブログも発表もできるかぎり抑えて、もっとコード書きたい。 みんなが飲み会とか結婚とかいってのんびりしている間にコード書くというのが半分冗談の来年のテーマだ。

今年もお世話になりました。来年もよろしくお願いします。