株式会社はてなにジョインしました！
1 月末付けで前職を退職し、 2 月から株式会社はてなで Web オペレーションエンジニアとして働いています。
転職の理由
前職も今と同じようにインフラレイヤの設計、構築、運用を担当していて、業務でやりたいことや技術的に取り組みたいことは自由にやらせてもらっていたり、上司や周りにいる方々も高い技術力を持っていて、かつ運用に対する改善等の考え方も技術的に前向きで働きやすく、特に大きな不満があったわけではありません。
一方で昨年の秋には新卒で入社して 3 年弱が経過しようとしていて、自身のキャリアについて振り返ると転職を考え始める時期かと考え始めていました。 前職は 1 社目ということもあり構築するサービスの内容やそれに応じて要求されているシステム構成の考え方、開発のスピード感、新しい技術に対するモチベーションが鈍ってしまうことが怖いという思いや、自社以外のそれらの様子をまだエンジニアとして若い間に見ておきたいという思いがありました。それと同時に、昨年から少しずつ自身のアウトプットを発信していく過程で、ブログや勉強会や OSS に成果物をアウトプットしている同年代の技術に明るいエンジニアと一緒に働きたいという希望もありました。
はてなを考えたきっかけ
はてなを転職先として考えるに至ったのは今までお会いして話を聞いた方々の影響があります。
学生時代の出来事で、今ではもうはてなにはおられませんが、大学に来られた際に 
id:ninjinkun さんや 
id:htomine さんとはてなの技術に対する考え方、プロダクトに対するモチベーションといったカルチャーについて話したり、勉強会では 
id:r_kurain さんとフロントエンドの技術についての苦労や新しい取り組みについて楽しく話したのを今でも覚えています。
話を聞く中でカルチャーや技術に対するモチベーションに憧れ、はてなで働きたいと思っていたのですが、当時はアプリケーションエンジニアを目指していて、言語は Perl より Python が好きでした。 そういったところもあって、前職の会社で働くに至ったということもあるのですが、社会に出てインフラレイヤのエンジニアとして働き始めると言語や既存の技術に縛られることなく働くことが求められ、言語に対する苦手意識は薄まっていきました。
転機があったのは昨年で、勉強会や技術系のイベントに参加する中で 
id:y_uuki さんや 
id:Songmu さんと今のはてなのカルチャーや技術に対する思いを聞いて、以前に思い描いていたはてなと変わらないなと確信できたこと、そのタイミングで自身のキャリアと成長について考え始めたことが今回の転職につながっています。
これから
はてなで働き始めて 1 ヶ月が経ち、システムのポリシーや構成、そしてカルチャーにもなじんできたところで自分の転職当時の気持ちを整理してみました。 今までお会いしたいろいろな方の影響を受けて今はてなで働いているんだなと考えるとなかなか感慨深いです。
今ではミドルウェアの構成やネットワークの運用ポリシーについて技術に尖ったメンバと真剣に議論ができ、一人のエンジニアとしてはてなで働くことができて嬉しく思っています。
つらつらと書きましたがこれからもよろしくお願いします!
ISUCON6 本戦の Server-Sent Events を Rust で!
この記事は Rust Advent Calendar 2016 - Qiita の 20 日目の記事です。(3 日ぐらい遅れてしまいました。スミマセン><)
ISUCON6 本戦 Rust 実装
さて、以前に ISUCON6 で優勝したことを記事に書いたのですが、自分はメンバの中で実装が遅い & プログラミングよりインフラの方が得意ということで実際の競技では肝心のコードは触ってないです。
そこで、今回は復習と早くも来年の ISUCON7 (未定) に備え、練習も兼ねてアプリのチューニングに挑戦することにしました。 Go でチューニングに挑戦してもよかったのですが、今回は Rust Advent Calendar 2016 のネタと Rust でチューニングしていくためのスタートラインとして、 Rust 実装を用意することにしました。
リポジトリは以下になります。
webapp/rust に Rust の実装があります。動作を確認している環境は以下の通りです。
$ rustc --version rustc 1.15.0-nightly (ac635aa95 2016-11-18) $ cargo --version cargo 0.13.0-nightly (806e3c3 2016-10-26) # Linux でのみビルドと動作を確認しています。
ISUCON6 本戦の問題といえば、お題はお絵かきアプリでフロントエンドの NodeJS + React のバックエンドにアプリサーバがあり、フロントエンドのリクエストに対してバックエンドが Json を返すというモダンな構成の問題でした。
お絵かきの過程をほぼリアルタイムに共有するために、フロントエンドはバックエンドからの Server-Sent Events を受け取ってブラウザに応答を返します。
つまり、 Rust で Server-Sent Events を扱う必要があるのですが、実装について設計を考慮すべき箇所やハマりどころがあったため、今回取り上げて解説します。 (その他もハマりどころがあったのですが、コードから読み取れると思いますので、特段取り上げません)
Server-Sent Events の実装
Rust 実装を始める際、 WAF の選定から行いましたが、今回は軽量であるということと Hyper に強く依存していることから Hyper の API を扱いやすいという観点で、 nickel.rs を採用しました。
Server-Sent Events を実装しているエンドポイントは get_api_stream_rooms_id() 関数になります。
624 fn get_api_stream_rooms_id<'mw>(req: &mut Request, mut res: Response<'mw>) -> MiddlewareResult<'mw> {
Server-Sent Events ではストリームに対して書き込みを行います。
nickel.rs では Write トレイトを実装する Response<'a, D, Streaming> から write(&mut self, buf: &[u8]) メソッドを呼び出すことで、 Hyper を経由してストリームに書き込みを行うことができます。
Response<'a, D, Streaming> を得るには Response<'a, D, Fresh> から start(self) メソッドを呼び出して、型を変更します。
694 let mut streaming = match res.start() { 695 Ok(streaming) => streaming, 696 Err(_e) => { 697 let _result = writeln!(&mut std::io::stderr(), "nickel streaming start error"); 698 exit(1); 699 } 700 };
しかし、この時点で res の move が発生するため、以降 res を参照することができなくなります。 つまり、ストリームには書き込めるのですが res を使って HTTP レスポンスを返すことができません。 そのため、他の実装ではエラー処理の際に HTTP レスポンスを返す箇所で Rust 実装では HTTP レスポンスを返すことができていません。 この問題は今後の課題です。
ストリームに書き込めるようになったところで、実際の Server-Sent Events 実装 について触れていきます。
Server-Sent Events の実装に利用するメソッドは write(&mut self, buf: &[u8]) メソッドと flush(&mut self) メソッドになります。
これらのメソッドをまとめ、エラー処理を含んだ処理が print_and_flush<'mw, T: AsRef<str>>(mut streaming: Response<'mw, (), Streaming>, msg: T) 関数になります。
なお、write, flush はいずれの処理も move するため、 streaming を return することで所有権の返却を行い継続してストリームに対して書き込みできるようにしています。
704 streaming = print_and_flush(streaming, msg).ok().unwrap();
最後にこのエンドポイントでは以下のようにして bail() を呼び出して、ストリームを中断しています。
777 streaming.bail("") 778 // Ok(Action::Halt(streaming))
Ok(Action::Halt(streaming)) を return することで、ストリームを終了することもできるのですが、これではストリームを再開する時に Last-Event-ID がリクエストのヘッダに付与されないため、 bail() を呼び出して中断しています。
ここまでが Server-Sent Events の実装の一連の流れです。
まとめ
この記事では Rust で Server-Sent Events を扱う方法について触れました。
内容としては前節でまとまっているので、Rust 実装について少し触れておきたいと思います。 今回やったこととしては他言語の実装を Rust 実装に置き換えるだけなのですが、所有権や Trait という概念がある以上、やはり他の一般的な言語間での移植以上には時間がかかりました。 しかし、これらの概念を理解するためには、もとのコードも洗練されておりとても良い課題だったかと思います。 Web アプリケーションを Rust に移植するなどや ISUCON6 の他言語の実装を参考に Rust を学習される方がおられましたら、自分のコードが役に立てば幸いです。
また、この記事ではパフォーマンスについて触れることはできませんでしたが、トップページのロードは Go 実装より Rust 実装の方が高速のようです。 簡単な計測としてキャッシュを無効にしてブラウザのプロファイリング結果だけ見たところ、 Go 実装で 7.5s 前後だったロード時間が Rust 実装だと 6.7s 前後に短縮される結果が得られました。
この結果を踏まえ次回以降の記事では、さらにチューニングやプロファイル過程を紹介できればと思っています。
この記事は Rust Advent Calendar 2016 - Qiita の 20 日目の記事として書かれました。 21 日目は 11Takanori さんで RustでCSVを操作する - Qiita です。
Gentoo な Thinkpad X1 がぶっ壊れたので MacBook Pro に乗り換えた
先週まで会社の業務で出張に出ていたのだけど、出張先で PC が壊れてしまった。 使っていた PC は Thinkpad X1 carbon (1st Gen) 、 2012 年のモデルなので相当古い。 どういう状態かというと、バッテリ駆動しない(出張中に突然なった) + スピーカーの認識が悪くてときたま X11 を巻き込んでクラッシュする。
バッテリ駆動しない状態になるとデスクトップと変わらず、ラップトップとして役割を果たさないので単純につらい。 普段からただただ重い荷物を持って通勤しないといけないし、インフラエンジニアとして緊急時には対応しないといけないので仕事にも支障が出る。
というわけで、会社で支給されている MacBookPro 2015 に移行した*1。
しかし、 Thinkpad X1 には Gentoo Linux を入れて利用していたのでそう単純な話ではなく、というところで..。
そう、ここ 3 日くらい MacBook Proを捨ててThinkpad T460sを買ってgentooを入れた - joker1007の日記 のエントリーと逆のことをやってたのです!?
(僕が箱根をノロノロとヒルクライムしている間にこんな面白いことをされてたなんて!)
d.hatena.ne.jp
スペック
使っていた Thinkpad X1 は 2012 年のもので 4 年もの。 スペックを比較するとリッチになったぞ!!
- CPU: Intel Core i5 2.4 Ghz (Ivybridge) -> Intel Core i5 2.7Ghz (Broadwell)
- RAM: 8 GB -> 16 GB
- SSD: 256 GB (SATA) -> 256 GB (PCIe)
- ディスプレイ: 1600x900(14インチ) -> 2560x1440(13インチ)
- キーボード: 英字キーボード -> 日本語キーボード
- バッテリ駆動: 3 時間 -> 10 時間
- 重量: 1.36kg -> 1.58kg
CPU も世代が上がってさくさくで使いやすいし、何よりも解像度が上がってよくなった。 家では AC 電源に繋いだままの X1 が放置されているけれど、 移行のために X1 で作業するとドットが目立ってちょっと悲しくなる。
バッテリ駆動時間についてもともと X1 は 6 時間なのだけど、ヘタりにヘタって 3 時間になってしまっていた。 自分の使い方では問題なかったのでよかったけど、ダメになってしまっては意味がない。 MacBookPro は 10 時間も持つので AC アダプタを会社に置きっぱなしにできるのはちょっと嬉しい*2。 けれども重量が 220g も増えてしまったのはいただけない。 ずっしりとした重さを感じていて、リュックでの通勤には少しつらいけど支給の PC がモデル 2016 になるまでの我慢だと思ってこの際割り切った。
キーボードは支給 PC だと日本語キーボードしか選べないので、仕方なく日本語キーボードを使ってる。 キーマップを英字配列に変更していて、フラストレーションはたまるが時々を除いてそれほど困らない。 Insert キーや PageUp, PageDown がなくなったほうが辛いくらい。
総合的にはなかなかいいものだなあという所感。
ソフトウェア
OS が Gentoo Linux から OSX になったのが変化としてかなり大きい。
とはいうものの自分も昔は Snow Leopard まで使っていたので大丈夫だろうと思っていた。 (なぜ Mac をやめたかというと当時、 Lion へのアップデートが有料になり嫌なったのと Spaces がなくなったと聞いて Linux に逃げた。)
今に至るまでいくつか問題があったけれども、まずはいいところだけ書いてく。
- Xcode のインストールに Apple ID が必要ない!
- Homebrew サイコー!!
- Karabiner のおかげでほとんどのキーバインドを矯正しなくていい!!!
- mission control も悪くない!!!!
初めは Firefox (vimperator) も emacs も一部の X11 アプリも使えるし「いいぞ!」という感じだった。 パスワード管理も keepassx を使っていてそのまま移行できたのでかなりよかった! 会社資産の PC に個人のアカウントは入れると面倒なのでそれは移行していないけれど、必要なアカウントだけ選択して移行するのはちょうどいい。
けれども当然、悪いところやハマったところもあって..。
- Finder のキーバインドがカスタマイズできない。
- X11 で Retina が有効じゃない。
- タイル型ウィンドウマネージャ(xmonad)使いたい。
- ファイルシステムで大文字小文字が区別されない。
- 句読点入力がカスタマイズできない(mozc は設定書けたけど OSX でもできるのか不明)。
- mission control の設定が見れない。
- ebuild の資産が使えない。
- UID が 501。
- docker のバインドマウントの挙動が違う。
- 色々なところで sudo を要求されてなんか嫌だ。
Linux だとファイラは thunar を使い、 gtk-can-change-accels=1 を有効にして自由にショートカットキーをカスタマイズしていた。
見た目を気にして nemo を使っていた時期もあってこっちはソースにパッチを ebuild の中で当てて、ショートカットキーをカスタマイズしてた。
たとえば Shift + Super + H でホームフォルダに移動や Control + L で直接パスを入力して移動を指定していたのでそのあたり自由に設定できない Finder はなかなかにつらい。
ハマったのは dotfiles をコピーしたら X11 用の設定までコピーしてしまい Xquartz が起動と停止を繰り返す上にエラーメッセージが出力されずに捕捉するまですごく追いづらかったり、 /etc/shells に書かないと zsh が使えなかったところ。
調査のときに Xquartz はユーザログイン時に launchd から startx が叩かれていることがわかったとか launchd の設定ファイルの文法とかあまり使う機会がないのに launchd に詳しくなってしまった..。
ハマるのは解決すればいいので仕方ないのだけれど、嬉しくない本当の理由はハマっても実務に活かせないところ。 例えば OSX の launchd や docker for mac でハマっても、実務で扱っているサーバは Linux なので systemd や sysvinit が init だったり、 docker も全然違うので実務には活かすことができない。 Gentoo なら同じ Linux のため手元の PC での作業をサーバにそのまま知識を活かせるし、coreutils のコマンド群を触っていても小さな発見があるので楽しい。 ローリングリリースで新しいパッケージも順次追加されるので、 eix-diff でどのパッケージが更新されたかといった情報を得たり、試すのが楽しみにもなる。
結局
使っていると光沢ディスプレイもテカテカが気になったり、タイプ中にタッチパッドが反応してトラックポイントが欲しくなってきたりハードウェア的にも不満が出てきてしまったので、結局 1 年もしないうちに Thinkpad X1 に戻してしまうんだろうなあと思って今は本当にこれでいいのかどうか試す目的で考えながら使っている。
