読者です 読者をやめる 読者になる 読者になる

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

1年分の自分のはてなブックマークを見直した。 およそ 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 にインスパイアされて書いてみた。

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

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