たごもりすメモ

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

Datastore Masakari Talksやった #dsmasakari

Datastore Masakari Talksっていう名前でやったら面白いんじゃね？ という話で @shot6 さんと盛り上がって、そのまま会場を手配してもらったので二人して面白駆動な感じでやった。


Datastore Masakari Talks - connpass

これがまた大変面白い感じになったのでよかった。

勉強会に Masakari とついていて話すのを敬遠した人もいたみたいだけど、普通の神経の人はしゃべってる人のことを面罵したりはしないし、普通でない人というのは業界にほとんどいないので、要するに普通の勉強会だった。「DISることしか言ってはいけません」的なレギュレーションは使ってれば問題のあるところって普通見付かるよね、という前提のもとに決めたもので、要するに普通に使っていて感じたことを話してほしいじゃんね、みたいな感じ。

自分も2年前に使うのをやめたデータストア、Kyoto Tycoonについてしゃべった。

なにしろ2年前に使うのをやめていたのでどうしようかとも思ったが、最終リリースが4年前なのでまあいいかという感じだった。めでたしめでたし。
(修正 19:54) ブクマコメントを見て気付きましたが、資料を作った時点で 0.9.25 のものを見ており、もっと新しいリリース 0.9.56 があったので、このChangeLogの最終コミット 2012-05-01 を参照するべきでした。資料も間違っています。お詫びします。……にしても使うのやめたのより前だったから、まあいいや。(修正ここまで)

また何か面白いネタがあったらやりたいかもしれないが、今だと適切なネタがWebサーバくらいしかないなあ、というような話を飲みにいったときにしていた。

#morisnite vol.2 やりました

このたびひと区切りついたところ自宅を埋め尽くさんばかりの勢いで届いたビールが一人で飲んでいる限り賞味期限という制約を突破できないことが明らかであり、みんなで飲もう、ということでまたも主旨不明としか言いようのないイベントが行われました。

#morisnite vol.2 - connpass

このようなイベントにこころよく会場をご提供いただいたフリークアウトさん、ならびに調整してくださった @myfinder さん、本当にありがとうございました。 #morisnite はこの会場あってこそです。

というか、よくわからないけどITエンジニアがぞろぞろと酒と食べ物持ってきて好き放題話しながら飲み食いする、というだけのイベントがこれだけ楽しいの、なんなんですかね。すばらしいです。

なお事後報告ですが、自宅には以下のビール的物品が届きました。

  • ビール 小瓶および缶*1 267本
  • ビール 一升瓶*2 12本
  • ビール ギフトカタログ*3 6冊

この中から一升瓶すべてと、小瓶および缶をかなりの量、あわせて60Lくらいを会場に運搬*4しましたが、見事に参加者により飲みきられました。じつにすばらしい。

また @941 さんによる寿司的物品の差し入れ、および自分の某友人によるシャンパンのダブルマグナム瓶の提供もありました。

なんかよくわからない楽しさでした。ありがとうございました。

*1:メーカーおよび種別極めてさまざま

*2:サンクトガーレン 感謝および感謝の黒

*3:サンクトガーレン

*4:個人で赤帽とか初めて頼んだよ

「Serverspec」の話

著者の宮下さんから送っていただきました*1。ありがとうございます。

o'reillyに電子版もありますね。

送っていただいてからちょっと私事でばたばたしていたら大量にレビューが書かれているので、どう紹介したものかと思っているうちに更に日が経ってしまった。
他の多くの人が書いている「まさにServerspec作者にしか書けない内容だから必見」というのは同意する部分しかないんだが、自分が同じこと書いてもなあ。

ということで、ちょっと視点を変えて「なぜServerspecが必要なのか」について書こうと思う。……と思ってここまで書いたんだが、このServerspec本にも書いてあったしもう一度確認しよう、と思って読み直してみたところ、自分の考えていたことが全部書いてあった。

1.4 Serverspecの必要性 (p8)
Serverspecって本当に必要なの？ という意見もよくTwitter等で見かけますので、必要性について開発者としての意見を述べます。
もしサーバ構築を手動で行っているのであれば、(……中略)
サーバ構築にシェルスクリプト、Chef、Puppetなどを利用している場合は、(……中略)
ChefやPuppet等は、特に慣れてしまえば、(……中略)
インフラコードをリファクタリングするのであれば、(……後略)

うーむ、困った。言いたいことはここに書いてあるのだが、1節まるごと全文引用するわけにもいかないし、本に書いてあることと同じことを自分も考えているでございとここに書くのも気がひける。何か方法はないものか。

追記

ふとひらめいたが、サーバ構築をExcelの詳細設計書ベースで手動でやっているSIerのみなさまこそServerspecを使うべきだ！！！！！ というのはいかがでしょうか。間違いなく便利だ！

追記ここまで

と思ったまま延々公開できないままだったので、とりあえずこのエントリを公開してしまおうと思う。もし Serverspec が自分に必要なものかどうかがわからないという人がいたら、どこかの本屋でこの本を探して該当部分をチラ見してみてほしい。あるいは、そこまでやる人にはどうせServerspecは必要だということになるはずなので、何も考えずに買ってみてもいいと思う。損は無い。

(To 宮下さん: ところで、この節だけでも英訳して serverspec.org に置かれているとものすごく良いのではないかと思いました)

*1:だいぶ前に！

退職します

先にまとめ

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

現職について

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:これは毎年そうしている