たごもりすメモ

コードとかその他の話とか。

退職します

先にまとめ

現在の勤務先を退職することにしました。本日が最終出社日です。
次はまだ決まっていません。というか、どことも具体的な話はまだしていない、という段階です。面白そうな職場はどこにあるかなと探している段階ですので、魅力的なところに心当たりがある方はぜひご連絡ください。色々な人と話ができるといいなあと思っています。

現職について

11月半ばくらいまでは転職はまったく考えていませんでした。が、その頃の世間の技術的な流れなどを見ていて、ちょっと技術的に異なることをやろうかなあ、と考えたのが直接的な理由です。今後どうするかを考えたとき、せっかくなら働く環境なども変えてしまった方がこれからの人生が刺激の多いものになりそうだということで、現職を退職することを決めました。
やりたいことを変えるだけなら社内でやればいいだろう、という話を会社側からはされましたし、もっともなことでもあるのですが、同時に前の転職から4年半が経って、気付いたら30台の前半を丸々過ごしたことになってました。このあたりで違う場所を見に行くのもいいなあ、というのは今では大きな動機のひとつです。

4年半、いろんな人と仕事をしました。巨大なインターネットサービスの開発・運用について様々なことを学びましたし、色々なソフトウェアを書きました。OSSであれこれやれたのは本当にこの会社のすばらしいところだと思いますし、同時に本当にすごい多くのソフトウェアエンジニアと働けたことに感謝しています。

次について

オンプレ環境でがっつりあれこれやっていたので、クラウドサービス上で事業を展開するところで働きたいなあ、と思っています。以下のような要素があると魅力だと思っています。

  • サイト・サービスの動的なスケールアウト戦略に興味がある
  • OSSを積極的に利用している
  • OSSへのフィードバックに積極的である
  • プログラマがごりごりプログラミングしている
  • 適当にOSSにコミットしていても怒られない

もちろん勤務体系については自由が効くと嬉しいし、給料は高ければ高いほどよいですね!

とはいえ、先に退職する、ということの最大のメリットは色んな人とおおやけに話ができる、ということだと思っています。面白そうなサービス、面白そうな事業、面白そうなソフトウェア、そういうものに心当たりがある方、ぜひ声をかけていただけると嬉しいです。以下の適当な方法でご連絡ください。なお会社名を添えてご連絡をお願いします。所属先が無い連絡*1には返信しません。自分が知ってそうなケースでも、念のため添えてください。

数日ばたばたしそうな気がするので、すぐには返事ができないかもしれません。ちょっとだけお待ちください。

なお、次まで、あまり長く間を空ける気はありません。ご連絡いただける場合は早目にお願いします :-)

想定FAQ

独立は? 海外は?

どちらも考えていません。自分の好みとしては、独立するなら大きく当てられるネタがないとなーと思っていますが、今のところそのような持ちネタがありません。海外の有名なサービス企業にはあまり興味がないし、住む場所としては東京は最高だなーと思ってます。今のところ。

ISUCONどうなるの?

考えたら永遠に転職できないので、敢えて考えませんでした。どうなりますかねえ。次回開催時の都合次第ということで。

OSSプロダクトどうするの?

淡々とメンテを続けますので、これまで通りフィードバックをお願いします!

御社、続いてるね?

そう見えちゃう可能性があるのは否定できません。これはこの時期の退職にしてしまって、正直心苦しい点でした。
が、普通に出入りは普段からあって、その中でたまたま重なることはあるよね、という感じです。退職を決めるときに誰とも相談してませんし、他の人の事情も知りませんでした。まあ同じくらいの時期の入社なら同じくらいに色々考えてもおかしくないでしょー。

いまだにインターネットサービスを作る上では最高の会社だと思っています。どんどんすごいソフトウェアエンジニアも入社しています。今後を楽しみに見ています。

wishlist

うちの冷蔵庫を溢れさせてやろう! という親切心をお持ちのかたはぜひどうぞ! wishlist

明日

明日より無職(仮)*2となりますが、いっぽうCROSS 2015というイベントが明日にありまして、そこでこのようなセッションに登壇することになっております。

今こそ語るエンジニアの幸せな未来

話す内容については大変楽しみなのですが、それはそれとして登壇者がヤバく、社長、社長、無職(仮)、というとりあわせです。どうなるんだこれと思っていますが、みなさま良ければお越しください。当日券あるらしいよ! また無料の招待チケットをふたつ持っています。欲しい人は tagomoris@gmail.com にその旨をご連絡ください(先着順、当選は返信をもって以下略)。

最後に

よし、お前ら! 飲みに行くぞ!!!1!!

*1:要するによくあるヘッドハンターの連絡

*2:有給休暇の消化期間があるため

Webエンジニアが目を通しておきたいインフラの基本の本

「Webエンジニアが知っておきたいインフラの基本」を著者の馬場さんから献本いただきました*1。ありがとうございます。

ITインフラの設計やら構築やら運用やらに関わりながら仕事をするようになってそれなりの年数になった。日頃おろそかにしている部分もあれば専門だと思って自信をもってやれることもある。その中でたまに思うのは、何が当たり前で何は当たり前ではないのか、ということがよくわからなくなってきたなあ、ということだ。
障害対応時の心構えは? そもそもシステムメンテナンスにおける心構えとは? Webアプリケーション基盤の設計方法は? 非機能要件にはどのようなものがあるか? パフォーマンスとは何を指すのか? どんなサーバにも入っているツールで調べものをするときの鉄板は? サーバのパフォーマンスを示すグラフの見方は? どのような兆候が出ていたら注意しなければならないのか? どの数字にどういった意味があるのか? あれやこれや。

この本は、専門家を育てるための本ではない、と思う。扱われている内容が、まさに基本だからだ。しかし、おそらくだが、この基本といえる内容は多くの人にとっては当たり前ではないのだろうと思う。

だからこそ、多くの人に目を通してみてほしい。普段運用やITインフラの設計・構築にはあまり関わっていない人にとって、一度目を通してもその内容すべてを学ぶことは困難だと思う。が、ITインフラ全体のどのような領域にどのような種類のノウハウがあるのかについて、なんとなく概観できる、という点で本当に価値がある本だと思う。一度目を通したら、あとは気になったことがある度に、いつでもこの本の内容に戻っていけるだろう。

自分にとっても、多くの人にとっての基本とは何なのかを再確認できるいい機会をいただいたと思っている。ありがとうございます。

*1:だいぶ前に!!!

社内ITシステムを構築・運用するのに最重要な3つのポイント

自社で使用するシステムを開発する、とする。

このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。
こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。

ということで、自分が心掛けていることをざっと書く。

全く手を入れずに動き続ける状態を最初に作る

もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1

ということで、システムにはある程度の確率で、不可避なメンテナンスコストというものが発生することは覚悟する。それを理解した上で、普段の何の仕様変更もない日常においては、何らかのメンテナンス作業を要求することは絶対にしてはならない、と思おう。

何か作業をしなければ正常に動かないシステムは、その時点で既に正常ではない。毎日何かしないといけないならジョブスケジューラにやらせる。ある程度の確率で起きるイレギュラーな事態についても、比較的高い確率で起きるなら自動的に対処できるようにするべきだ。

定期的な手作業は複数システムのローンチを経て、最終的に手のつけられないレベルに増大する。蟻の一穴という言葉がある。例外を許してはならない。

メンテナンス時にダウンタイムを作らない

メンテナンス作業が必要なことはある。どうしてもある。データ量の増大にともなう稼動サーバの変更、データ連携先の変更、言語ランタイムやミドルウェアのバージョンアップ、あれやこれや。

それぞれの作業の難易度はもちろんいろいろだろう。しかし可能な限り、ダウンタイムをとってはいけない。あらゆる作業はダウンタイムをゼロで行う、そのくらいの覚悟でやるのが望ましい*2

社内システムに限らないが、各種ITシステムの利用者は開発者が考えるよりもダウンタイムに敏感で、鈍感だ。と思う。この程度落ちてもいいだろうという意識で数分のサービス停止を何度も繰り返していると、システムのユーザは意外にもそのダウンタイムに気付いているし、そして簡単にサービス停止が常態化した状況に慣れてしまう。
こうなると、予想外の状況下においてシステムが停止している場合にも、それがなかなかユーザから報告されない、という状況を招く。早期に発見していればすぐ対処して数分で復旧できたのに、何日も気付かなかったばかりに復旧に数日以上も必要とする、ということは大いにありうる。

何か動かなかったとき、すぐにユーザに教えてもらえる、それが復旧への最短ルートだ。維持しよう。*3

動作不良には最優先で対処する

何かが正常に動いていない、と言われたとき、その問題には最優先で対処するべきだ。後回しにしてはいけない。そのシステムはもう捨てるという決断が行われているのでなければ。

各所の業務における、ある社内システムへの依存度というものを正確に測るのは極めて難しい。もちろんログを確認することで誰がいつアクセスをしたのかは分かる。しかしその動作がその人の業務にとってどのようなインパクトを持つのかについては、ログから推し量ることはできない。
もちろん個別にインタビューすれば分かることかもしれないが、全てのアクセスについてそのようなことは当然不可能だ。

システムが動作していないとき、それが誰のどのような業務にどの程度の影響を与えるか、あらためて確認している時間はない。開発者が大して重要でもないと考えたシステムが、社内のどこかの誰かにとってクリティカルになっていたりする。……というより、そんな状況にもなっていないようなシステムなら最初から作らなければよいのだ。

なので、動作不良が起きているとき、それは社内の誰かの業務にとってクリティカルな問題になっている、ということを前提に行動する必要がある。止むに止まれぬ事情があって即座に復旧できない場合、最低限どこかに時間的な見通しについて示しておかなければならない*4

まとめ

書いてみたら当たり前のことすぎた。しかし何度でも繰り返す重要性があると思ったので、そのままポストする。

*1:余談だが、データ連携時のフォーマットがどう変わってもいいように予め作り込んでおこう! という手法は愚の骨頂で全体の開発コストを異常に押し上げる上に使われていないコードを大量に残すことでメンテナンスコストまで激増させる。絶対に避けるべき。

*2:もちろんリスクの大きい作業を行うとき、その内容とリスク、何かあった時の影響範囲について事前に関係者に知らせておくのは最低限必要な作業のうちのひとつだ。ダウンタイムをゼロにする覚悟でいるからといって、その種の行動を怠ってよいということではない。あたりまえにやるべきことだ。

*3:もちろんシステムが正常に動作しているかの監視をきちんとやる、ということが重要なのは言うまでもない。しかしビジネスへの影響が直接的な形では見えない社内システムにそこまで厳密かつ正確な監視設定を必ず行えるところは少ないのではないかと思う。またデータが化けている、みたいな問題までシステム的に必ず拾うということは事実上不可能だと思う。

*4:もちろんだが、止むに止まれぬ事情とは、自分のエディタの中にある未コミットのコードのことは含まない。

2014年を振り返ってみる

今年もいろいろあった。Blogエントリベースで簡単にまとめとこう。

f:id:tagomoris:20141231180607p:plain

コード書いた系

今年はあんまり新規に書いたコードというのがなかった気がするなあ。どうしてもメンテナンスが多くてそれに追われていた感があった。みなさんこんなのどうしてらっしゃるんや……。

いっぽうv1をリリースするブームが自分にやってきて、メンテナンスリリースを前向きにやる、みたいな気持ちになれたのはまだマシなほうだったと思う。

うーむ、少なめ。

Focuslightはロゴなんかも作ってもらって、メンテナンスも人に引き継げて、よい先行きをたどった。Wootheeも使ってもらえているケースが増えてきたし、実装言語も更に増えた。

2013年末に初期実装を終えた fluent-plugin-bigquery についてはこの1年で驚くほど普及した。年始からのしばらくでソフトウェアとしてもっと整え、多くのパッチをもらってマージし、年の途中ではメンテを naoya_ito 氏に引き継いでもらい、年の後半にはあちこちでBigQueryへの言及を目にするようになった。

しかし何より、個人的には Norikra v1 というのが巨大トピックで、2013年に作ったNorikraをより使ってもらうための2014年、という感じだった。

発表など

15回……。LTをあまり含んでいなくて、よく頑張ったな、という感じの回数だ。 1ヶ月のあいだに2〜3回発表があって英語のを含む、みたいな無茶なスケジュールになりがちで、そういうのは業務にかなり甚大な影響を与えるので、ちょっとやりすぎ感はあった。でも調整できないんだよねそういうの。

2014年の目標のひとつが海外で英語で発表する、というもので、それについては RedDotRubyConf, HadoopConf Taiwan, RubyConf で実現できたので文句なしという感じ。台湾では基調講演までやらせてもらって、あれはすごく貴重な経験だった。

国内の大きいところだとデブサミHadoop Conference Japan、YAPC::Asia あたり。YAPCでベストスピーカー賞2位とかももらって、それぞれできる話をした、という割にはよく聞いてもらえてありがたかった。

ほかにも筑波、福岡、札幌、という感じでお呼ばれしたのが印象強く、国内外問わずあちこち旅行したイメージがある。もっとお呼ばれしたい。YAPCベストスピーカー賞で国内の .pm に行く権利があと2回分あるので、みなさんぜひ呼んでください!

Norikra meetupはそろそろもう一回やりたいなあ。

記事寄稿

今年はSDでいちど原稿書いた。これは後日自分で読み直すくらいよい出来だったと自負しているので満足。

書籍に関しては進みかけた話があったんだけど、いろいろあって頓挫しましたね。やっぱり共著は強烈にリーダーシップとる人がいないと厳しい。来年、時間があったら一人で書こうかな。時間あるかな。

ノウハウなど

Ansible使いはじめて、なるほどこれが、みたいな経験をしたけど、まああんまり想像と違うというものではなかった。大規模サーバオペレーションみたいなのにあった方がいいのは確か。

いっぽう環境をいつでも何度でも作って壊せるというのは想像を少し超えて便利だ、特に検証・実験目的には、と思った覚えがある。

あとはHadoopやFluentd関連を継続してあれやこれや。でもあんまり新しいことをやれてない気がするなあ。もうちょっとどうにかしたい。

そのほか

日本OSS奨励賞というものをいただいた。そういうものがあること自体は知っていたけど、自分に関係するものだと思ったことはまったく無くて、これはもうびっくりするやら何やら。そんでテンションが上がって書いた記事。

受賞自体について、周りの知人に多くのお祝いの言葉をいただいたのも嬉しかったけど、実はこれが実家の両親に知られて、どうやらうちの息子はそれなりに頑張っているらしい、みたいな思われかたをしたらしかった。書籍(単著)執筆みたいなのと同じで業界を超える効果がある。

いろいろあって連覇できました。ISUCON Makers Casual Talksとかもやって超楽しかったけど、そういえばblogエントリ書いてなかったな。

これはなんか、こんなタイトルでエントリ書けば300ブクマは固い!みたいなことをtweetしてたノリでそのまま書いたやつ。こういうことを繰り返していると人間はダメになるな、という良い実例。2015年はやめよう。

あとひょんなことからRebuild.fmにゲストで呼ばれるという奇貨にあって、非常に楽しかった。と同時に、いろんな人がこれを聴いてたようで、影響力はんぱないなーという感じ。

まとめ

今年も総じてあれこれやったほうだとは思う。楽しかった。特に国内外あちこちに行けたのは良い経験だったと思う……東京住むの最高だな、と思ったことも含めて。

技術的に新しい方向のことがあまりなくて、それが個人的にはちょっと残念だという印象はある。リリース済みソフトウェアのメンテナンスを省コストでどうやっていくか、という点についてうまい落としどころを見付けて、新しいコードをがんがん書きたい。

とはいえFluentd v1のリリースが見えているので、そっちかなあ、とか、あれこれある。ちゃんとしたことは年が改まって2月に考えよう*1

*1:これは毎年そうしている

fluentd v1 configのチェッカを作った

tagomoris/fluentd-v1-checker · GitHub
fluentd-v1-checker | RubyGems.org | your community gem host

Fluentdの設定ファイルについてはv1 config という新書式がある。v0.14からはデフォルトでこちらの書式でパースが行われる予定。
ここに @repeatedly さんが書いてるけど、今のうちから v1 config で書いて --use-v1-config しておくと将来的に困らなくてよいと思う。書式的にも綺麗になっているはず。

ところで v1 config といってもいろいろな経緯から、これまでの書式の設定ファイルをぶちこんでもなんとなくパースできるようになっている。値に # とかを含めたいとかでなければ設定を変更しなくても通る場合も多い。

「場合も多い」これが困る。起動してみて動かないとか、思ったのと違う動きかたをしている、とかだとたいへん困る。確認も面倒。
面倒だったので、両方の書式でパースしてみて結果が一致するかどうかを確認してくれるチェッカを作りましたよ、という話でした。

$ gem install fluentd-v1-checker
$ fluentd-v1-checker /path/to/fluentd/config/file/fluentd.conf

これで従来書式と v1 との両方でパースし、結果に差分がなければそのまま終了する。差分があるとこんな感じでdiffを出してくれる。赤が従来書式としてパースした結果、緑がv1。(これはv1書式で書いたので、従来書式としてパースすると当然差分が出る。)

差分が出るようだと --use-v1-config でFluentdを起動したときにこれまでとは異なる設定で動いてしまう、ということだ。

じゃあ v1 書式で新しく設定を書いたときに、従来の書式の設定ファイルと同じ指定になっているかどうかをチェックしたい場合はというと、そのためのオプションがある。

$ fluentd-v1-checker --with-v1-conf fluentd.v1.conf fluentd.v0.conf

これでOK。ちゃんと書式の移行ができたかがわかる。べんり! これで安心して --use-v1-config つきの起動に移行できますね!

HadoopのXML設定のdiffをとるスクリプトを雑に書いた

Hadoopの設定は name, value, final, description の4要素しか持たない上に /configuration/property/attr の階層しかないくせにXMLになっていて、これがもう、ひっじょーにdiffがとりにくい。普通のテキストdiffでは無理といっていい。
おかげで新しいディストリビューションやバージョンが出たとき、そのオススメ設定がこれまで使っていた設定とどの程度違うのかがまったくわからず、毎回死にそうな目にあう。つらい。

ので、この単純な構造のXMLに特化した、雑にdiffをとるためのスクリプトを書いた。これを使うとdiffの結果がこんな感じになる。

超便利でしょ?

もちろん差分のないプロパティについては表示されていない。あと色付けは colordiff*1 および less -R にまかせた。
このスクリプト hadoop_xml_diff.rb は以下のように雑に使う。

$ ruby hadoop_xml_diff.rb path/to/xml/before.xml path/to/xml/after.xml | colordiff | less -R

https://gist.github.com/tagomoris/8f1bd08a7e9c363b9752#file-hadoop_xml_diff-rb

Enjoy!

*1:OSXなら brew install colordiff

Ansible playbookで1台でも失敗したら即座に実行を止める方法

毎回あれー?ってなってドキュメント読んだりググったりするんだけどうまく見付けられないので書いておく。

Ansibleはデフォルトだとtaskの実行が全ホストで失敗しない限り続く。言いかえると、あるタスクがあるホストで失敗したらそのホストについては以降実行されないが、成功した他のホストについてはplaybookの実行は継続される。
これは特に分散ストレージのセットアップなどにおいて、大変よくない。

よくないので1台でもtaskの実行に失敗した時点で止めたいというタスクには以下のように書いておく。

- hosts: ippai
  max_fail_percentage: 0
  tasks:
    - name: ....

failしているホストのパーセンテージが max_fail_percentage を「超えた」場合にplaybookが停止するので、1台でも fail したら即座に止めたい場合は 0 を指定する。

なおここに書いてある。なんでこれ毎回見付けられないんだろうな自分。
http://docs.ansible.com/playbooks_delegation.html#maximum-failure-percentage