たごもりすメモ

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

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

RubyConf 2014にいってきた＆しゃべってきた

出していたproposalが通ったので Rubyconf2014 に行ってきていた。旅費および会期中の宿泊費は現勤務先のLINE株式会社に出してもらいました。いつもいつもありがたいことです。

サンディエゴの会場付近はとにかくリゾート地っぽい感じで、あちこちに背の高いヤシがぽんぽん立っており、空も海も青いし、なるほどこれは国民性も変わろうというものだ、という感じ。初のアメリカ行きがこれだったので、USに対してだいぶ変なバイアスがかかった可能性がある。

そこでまたNorikraの話をした。何回目だと言われるかもだけど、英語だとまだ2回目だったし、英語圏でのカンファレンスでは初めてだったので……。

人によっては*1多少ウケたっぽいのでよかったよかった、ということにする。が、これ以上無闇に話しにいってもしょうがない気もするので、この活動は当面ではここまでかなー。

RubyConfに参加しての感想とか印象に残ったセッションとかは、ちょうどSFにいったときにゲストに呼んでもらった rebuild.fm 68 でしゃべったので、そっちを聞いていただくのが書く面倒がなくていいです。
ぶっちゃけて言ってしまうと、技術の話を聞くなら日本国内のカンファレンスのほうが面白いなあ、という印象。だからたぶん、ああいうところには、そもそも異なる文化についての見聞を広めるつもりで行くのが正しいんだろうと思う。

サンディエゴは海軍に縁の深い場所ということで、退役した空母ミッドウェーが丸ごとそのまま博物館として公開されてたりして、これがまた超面白かった。日本では絶対に見られない感じで非常によい。

食事は……まあ、選べばおいしいところはある、かなあ、というくらい。写真のメキシコ料理屋はすごくおいしかったが、この前日に行ったメキシコ料理屋はいまいちだった。あとスパゲティ専門店に行ったら、噂に漏れ聞いた「アルデンテという言葉を理解しているのはイタリアの外には日本人しかない」という言葉の信憑性が大幅に増した。

今回はせっかく太平洋を渡ったので、休暇をくっつけて日程を延ばし、ベイエリアにもちょっと行ってきた。写真はMountain Viewでフラグ立てとばかりに行ってきたコンピュータ歴史博物館。超面白かった。あれは一度行くといいが、閉館まで2時間半という時刻に行ったのがちょっと残念だった。半日丸々確保しておくべきだった。

そのほか、サンフランシスコ市内の知り合いに連れていってもらってステーキ食べた*2り、別の人に案内を頼んで市内観光したり、前述のとおりrebuild.fmに出ることになって録音したり。なんかいろいろだった。皆様ほんとうにお世話になりました。おかげさまで短いながらも濃くて楽しい滞在でした。

ただまあ、あそこに自分が住むことはないだろうなあ、と思う。出掛けると東京は自分に合っているということを再認識できるなあ。

あとはアレだ、アメリカ西海岸といえばクラフトビールですよ。

ビールビールビールビールビールビール。計8泊の滞在で30杯(20数種類)くらいは飲んだと思うが記憶が定かではない。

鞄を亡くすこともコーヒーをかぶることもなく無事帰ってこられました。よかったよかった。

*1:既にストリーム処理をなにがしかやっている人とかだと

*2:これがまためっちゃうまかった