2008-08-13
_ 近況
日記を http://steps.dodgson.org/ に移動しました. feed の URI はhttp://steps.dodgson.org/index.rdf (コメントあり) かhttp://steps.dodgson.org/no_comments.rdf (コメントなし) です. 古いフィードからはリダイレクトしているので, feed の処理系が勝手に移動してくれる場合もあるらしいです. 古い日記自体はそのまま残っています.
2008-08-06
_ 最近もらった本: サーバ/インフラを支える技術
いただきました. ありがとうございます.
ネットワークの構成から冗長化, サーバのチューニング, デプロイの自動化まで, インフラや運用の話題を集めた本. 私は運用やインフラに素人なので, 内容の技術的正当性について特に意見はない. ただ動いてる実システムの解説という点で信憑性は担保してる気がする. ひたすらすげーなあ大変そうなだなあと読んだ.
特に TCP/IP より下, LAN カード (という表記が我ながら素人っぽい. 玄人ぶるには NIC と呼ぼうか...) より向こうはつい所与のものと考えてしまう. たまに仕事で必要になっても同僚に押しつけてるし. 実は色々やってるんだろうなと, なんとなく思っていた中身を垣間みた気分になる. NIC より手前の話もあるけれど, 個人的には ハブ(...というと素人っぽい. スイッチ.) やルータやロードバランサの出てくる話が, 未知の世界で面白かった.
KLab 社や hatena 社みたいな比較的大規模なインフラが題材だけれど, ふつうに仕事で使えそうな話もぼちぼちあった. 会社にもってくから買って読んでね > 押しつけ先の同僚.
今夜の皿を洗うのは
子供の頃, 皿洗いが嫌いだった. 私の家の皿洗いはボランティア制で、気がついた人間が洗うことになっていた.
台所に立つ回数の多い母親が, おそらく一番多く皿を洗っていた. 私もそれなりによく洗った. 仕事で帰りが遅い日の母は, 流し台にたまった皿の山をみつけると不機嫌になった. 食事は出ないし嫌味は増えるし, 親の機嫌を損ねると良いことはない. だから部活動から帰って母親の姿が見えず, 台所の皿が片付いていないとき, あるいは食後, 誰も席を立たないとき, 後の面倒を避けるために私は仕方なく皿を洗うのだった. 台所に入るたびの不快感を減らしたい気持ちもあった. 汚れた食器類を溢れさせておくのは気分の良いものではない.
弟は滅多に皿を洗わなかった. 空気読みに長け, 不機嫌な悪い親をやりすごすのを苦ともしなかったし, 山積みの食器を見過すだけの汚れ物耐性を備えていた. (そう推し量るのは難しいことじゃない: 奴の部屋はえらく汚かったのだ.)
食事が済んで流し台に皿が積まれるとゲームが始まる. それはチキンレースだった. 相手の目を伺い, しらをきり, そそくさと食卓から離れる...大袈裟なものでもないけれど, 食後にうっすらと漂う白々しさや緊張がイヤだった. だから皿洗いが嫌いだった.
ソフトウェア皿洗い
ソフトウェア開発でも同じ光景を目にする.
古典的には, バグが皿だ. 自由奔放な弟(谷川史子ビューでは姉: 幼少に体が弱かったため親にかわいがられ, わがままと自由を当然のように謳歌している.) であるプログラマがコードを書きちらし, 神経質な兄(谷川史子ビューでは妹: 姉の割を食い, 現実主義でたくましい性格に育ったが姉へのコンプレクスは捨てられない.) であるQA担当がそのバグをあぶりだす. 荒れ狂う開発の滝に飲みこまれ, 妹は最後にいつも辛い思いをする. 時にはグレてしまうこともある.
ネットワークシステムでは, インフラや運用が溢れる皿の山に加わる. 姉(プログラマ)の書き散らしたシステムをデプロイして動かすのは妹(インテグレータ)の仕事だ. 明るく楽観的な姉は実環境を甘く見て, ビルドスクリプトで手抜きをしていた. コンパイルエラーに苦しむ妹. ようやくビルドを通し配備してみると, ヘルチェックも, 再起動のコマンドも, 計測用のモニタ API も,障害解析用のデバッグ出力もないことがわかる. そのくせファイルハンドルは握ったまま. ろくに log の rotate もできやしない. 性能低下, ディスク溢れ, クラッシュ... 安眠を奪われた妹は姉を恨み, 時にはグレてしまうこともある.
皿洗いソフトウェア
皿洗いのチキンレースはある日, 唐突に終わった. 皿洗い機が登場したからだ. 皿を並べてスイッチを入れるだけの便利な機械を, 姉...じゃないや弟さえも使うようになった.
QA担当も彼らの皿洗い機を持っている. それは Selenium かもしれないし WinRunner かも知れない. "サーバ/インフラを支える技術" はインフラにおける皿洗い機のカタログだ. 面倒な作業を自動化するテクノロジーの恩恵に, 私達は浴することができる.
しかしあらゆるテクノロジーがそうであるように, 皿洗い機にも制限があり, そのワークアラウンドがある. たとえばこびりついた米粒を落とす水量はないから, 飯碗は軽くこすってから並べる. 籠の隙間から抜け落ちることがあるから, 箸は専用の棚に挿す. 機械に収まらない大皿は使わず小皿にわける...ワークアラウンドは妹だけでなく, 姉を含む家族みなでとりくむ必要がある.
ソフトウェアにも同じことがいえる. QA担当がいるのに, なぜプログラマは単体テストをするのか? なぜレビューをするのか? 比喩に従うなら, 早く洗った方が汚れはずっとよく落ちるし, テーブルクロスもシミにならないからだ. あるいは皿洗い機に収まらない皿もあるからだ. 洗い場に立たなければ機械のサイズもわからない.
姉の役割
で, ようやく本題なんだけれど(長かった...), インフラや運用についても, 姉(プログラマ)の側に皿洗い機のカウンターパートがあると思う. 妹が鼻歌混じりで皿洗い機をつかえるよう, 姉にできることは何だろう. 姉ロールのプログラマである私は, 皿洗い機よりもこっちに興味がある. 妹ロールの同僚(※髭面)がグレないよう手を打たなければ.
皿洗い機のハイテク化が進むウェブアプリケーションや LAMP の世界では, こうした問題が少いのかもしれない. けれど自分が妹である限り, うかつでわがままな姉のコードで酷い目に会うことも少しはあるだろう. それはどのような問題で, どう解決したのか. あとは何より, 今や皿洗い機にエンコードされた皿洗いの知恵は何だったのか. そういう技術を整理された形で読んでみたい. "プログラマのためのインフラ入門" が読みたい. 皿洗い後進国では切実な願いだと思う.
"まぶしくて まぶしくて 少しだけ嫌いで あこがれてた"
だいたい言いたいことは言ったかな...
もとねたの短編で, 姉は妹にこう告げる.
あたし 朝ちゃんがずっとうらやましかった ... あたしは周りの人に嫌われるのがこわくて いつもにこにこしながら 自分では何も決めないずるい子でいたから まぶしくて まぶしくて 少しだけ嫌いで あこがれてた
姉であるプログラマが妹ロールのエンジニアに抱く気持を一片は表しているかもしれない. 皿洗いは機械をめぐるテクノロジーの物語であると同時に, 姉妹の邂逅をめぐる家族の物語でもあるのだ.
あ, 本を出すなら表紙は谷川史子でどうかよろしく.
2008-08-02
_ 近況
また WEwLC 読書会に参加した. 参加者ほぼ全員が ノート PC を持っており, Lingr で番外編をしている. ノートなし派(派閥じゃなくて経済的事情ですが)としてはやや悲しい. 噂の新型 MacBook が出たら欲しいなあ. 宴会ではまたしても名刺を切らせていた. すみません... > 名刺を頂いた皆様
この読書会はいつも, 本の内容より読書会そのものが勉強になる. 今回は n_shuyo さんの発表がわかりやすかった. 立ち振舞いもなんとなく先生っぽい. このわかりやすさは真似できないと思いつつ, 何が良いのかを考えていた.
きちんと読む: まずきちんと本を読んで理解しないと始まらない. 私は字面だけ追って読み進めてしまう癖がある. (割と根本的にまずい...) 批判的に読まないといかん. 特に内容が主観的だったり, 未整理なアイデアである時は, 話の整合性が怪しくなりがち. ちゃんと読まないと不整合なままのアイデアが自分の中に残ってしまう. 今回は, コード内の影響範囲を図示する "effect sketch" というアイデアが示されるのだが, 著者の考えが整理されておらず記法が一貫性を欠いていた. 私は "影響を図で書けばいいのね" くらいの認識でぼんやりと読んでいたので気がつかなかったけれど, 本当はもっとディティールがあった. そしてそのディティールが少し間違っていた. ぼんやり読むだけだと実際に "effect sketch" を試そうとした時に困るか, それ以前に存在を忘れてしまう気がする.
別の言葉で短く説明しなおす: これは理解を促す上でよく言われることだけれど, 上手くできた例はけっこう珍しい気がする. 参考書のような文章の構造化に自覚的な本が相手だと, 目次や強調部分をピックアップしただけでなんとなくまとまった気がしてしまう. 同じ流儀を普通の本に持ち込むと構造や要点を掴みそこねる. n_shuyo さんのメモはそうした再構成がうまかった. 良い読書ノートってのはこういうんだろうと感心. どうやれば上手くいくのかはよくわからない. 語彙の多少は関係がありそう.
クロスカットな文脈を意識する: "ちゃんと読む" の一環として. 文章には "起承転結" のように大きな流れがある. 普通, この流れは目次に現れる. 一方で, その流れとは直交した文脈もある. たとえばここは著者の "経験談" だな, 次は "愚痴" でここは "思いつき", ようやく "主義主張" が出てきた...というかんじ. こういう文脈を検知できると, それに応じて読み方を変えることができる. 具体的には読み飛ばせる. 今回の例だと, ここは "設定の説明" です, というパターンがよく出てきた. これからテストをするレガシーコード(=設定)の中身を説明する部分. 基本的に酷いコードであるレガシーコードの設計は, 善し悪しを吟味しても仕方がない. だからささっと読めば良いとわかる. (受験英語のエキスパートによれば, こういう文脈を識別する技術があるという.)
周辺情報を補足する: 本の中身ではなく, そこから参照されている技術や用語の説明を調べて追記することができる. 今回はコード変更の影響範囲を絞りこむプログラミング言語の要素として C++ の const 機能(と, それを台無しにする mutable 修飾子) の話が補足されていた. C++ に不案内な参加者には役に立つものだったと思う.
私は以前から本の読み方が下手だと思っていた. そのまま長いこと放置してきたけれど, だんだん非効率の負担が大きくなり困っている. 技術書の著者は本業の文筆家とは限らないから, 文章や構成が期待するほどわかりやすくないことがある. 扱う話題が本質的に複雑なこともある. けれど文章がわかりにくいからと言って, 主張や説明の中身が間違っているとは限らない. 逆に明快な文章で間違った主張をする本も多い. 少しくらい文章がわかりにくくても中身を読みとることができないと, 有意性ではなく読みやすさにバイアスされて自分の知識が形作られてしまう. そんな恐怖がある. (程度を越えてわかりづらい文章は無視していいと思うけれど. 書き手が問題を理解してないせいだろうから...)
読書会の準備であるという分を差し引いても,n_shuyo さんのノートは読む人がちゃんと読めば効率は高い実例. 精進したい. まずは 本を読む本 を読み直そうかしら.
2008-07-24
_ ウェブ華鑑賞: Procol Buffer 編
Protocol Buffer の話題は一部で熱く語られた...というより炎上していた. ようやく炎がおさまってきたから, 野次馬として現場にかけつけてみたい. 火事と喧嘩はウェブの華.
火元から見ていこう. 熱心な Google ウォッチャーである MS の Dare Obasanjo が, protobuf 公開に合わせすかさず "The Revenge of RPC: Google Protocol Buffers and Facebook Thrift" という記事を書いた. 記事の主張自体は穏当なもの. 「最近一部で バイナリエンコードな RPC が流行ってるみたいだけど, 時代は XML と REST で疎結合じゃなかったの？」と修辞的な疑問を示しつつ, "いや基本的に Web は XML で REST な時代なんだけど, Web に出ない会社の内部ならバージョンやらツールを揃えられるでしょ. それならバイナリと RPC で密結合しちゃって効率を稼いでもいいんだよ."とフォローする内容だった.
Steve Vinoski 登場
ところが obasanjo が記事の中でそれとなく引用した, Steve Vinoski (stevevin) の "Convenience Over Correctness" から火が出た. Steve Vinoski は CORBA ベンダである IONA の元社員で, RPC や分散オブジェクトでは相当痛い目に当ったらしい. 彼の書いた blog や雑誌記事では RPC をボロクソに叩いている. この "Convenience Over Correctness" もその流れを汲む内容. "プログラマは目先の便利さに釣られて関数呼びだしっぽく使える RPC を好むけど, 関数呼びだしじゃないことに気がついた時には手遅れだぜアホどもめ" と戒めている. (誇張あり.)
その stevevin が obasanjo のリンクへ呼応するようにエントリを書いた. これが炎上の現場となる. "Protocol Buffers: Leaky RPC" と題された記事は, まず Protocol Buffer の公開にはしゃぐ Google 社員 Mark Pilgrim を指してこういう. "彼のいうとおり protobuf はバイナリで小さくて良いかもしれない. でも良くみるとこれ RPC が付いてるよ. ダメじゃん!"
先に見たとおり, OSS protobuf に RPC の実装は含まれていない. stevevin もそれは承知している. しかし元 CORBA 関係者にとって, protobuf に含まれるインターフェイスは十分批判の材料になる. (もともと stevevin は "RPC のメタファは完全にウンコ" と主張してるからね. )こんあインターフェイスじゃ, ろくなエラー処理も書けない. 関数の idempotency (冪等性. HTTP の GET みたいなもの) も示せない. キャンセルの API があるけど下回りがキャンセル不能なインフラだったらどうする ... と散々にこき下ろし, protobuf RPC は "leaky abstraction" だと結論する. そして "Google は RPC 部分を消しちゃった方がよくね？" と記事を締め括っている.
挑発的な内容にさっそくコメント欄が引火する. "偉大なる Google 様は社内で protobuf を常用してらっしゃる. 貴様のような輩が検索語をタイプする裏では protobuf のメッセージが飛び交っているというに何たる狼藉であるか馬鹿者! 主は COM も知らんのか?" と煽ったり (CORBA に私怨があるとしか思えない相手へ COM を引き合いに出す辺りに煽りの素質を感じる.) "完全にウンコってなんですか? よくわかりません＞＜" とからかったり, "RPC だって非同期くらいあるからね. Thrift とか Rabbit AMQP とかを読むと良いと思うよ？" と無邪気に提案してみたり. (stevevin は CORBA を始めとする通信ミドルウェアの専門家で, AMQP の標準化と実装にも噛んでいる.)
stevevin も大人気なくいちいち返事をしていく. "Google のどこで RPC が使われてるんですかー?おしてくださーい" "何年も前から証拠は上がっているのに, お前こそ RPC がウンコ <でない> と思うなんて正気?" "素人はこのサイトを全部読んでから出直してこい. AMQP くらい知ってるわアホ" という具合. (誇張あり.) 典型的な炎上のシナリオだ.
社員参戦
stevevin のベタな対応に薄笑いを浮べながら読み進める読者は, しかしここで彼の真の実力 -- 釣り能力 -- の高さを思い知ることになる.
なんと Google の OSS protobuf 担当 Kenton Varda が現れたのだ.
"protobuf の RPC は社内でめっちゃ使ってますよ. RPC の実装はリリースに入れられなかったけど, あるにはあるんすよ. 依存しちゃってるんで消すのは無理っすwww エラーも戻り値で返せは大丈夫です. たとえば..." とわざわざサンプルコードを示してくれる. さすが社員. そして idempotency は特に役に立つ場面が見当らない. シンプルさのためにマイナー機能は入れないようにしている, 例外もそう. キャンセルの実装はクライアントローカルに閉じたもので, 下回りは関係ない... などと実情を明かし, "RPC が万能じゃないのは認めるけど, 使い所はけっこうありますよ. そんじゃ" とまっとうな感じで締める.
これに対し, stevevin は "idempotent は CORBA より昔からある重要な概念でしょうよ" とか, 呼び出し先の例外じゃなくてシステムの例外もあるでしょうと反論. 外野も再び騒ぎだし, 混迷は深まっていく. "RFC707 読んだけど RPC がよくわかりません＞＜" "たしかに他所のミドルウェアには idempotent あるねえ." "CORBA 標準化委員から飛んで来ました. idempotent はトランザクションの実装が必須になるので, 標準からは drop したはずです." "いやトランザクション要らないでしょ" "書いたもの全部読めって横柄じゃね? Google 社員は親切だったのに..." "15 年の経験を一言で言えって方が横柄だよ" "RFC 難しいってのは確かだけど, みんな使ってるんだから有用性は明らかじゃん" "いや深い考えなしにテクノロジーを採用するなんてよくあることじゃん" (元ミドルウェア屋が言うと身も蓋もないなー...)
そして stevevin が, "そもそも Google の RPC 実装は見られないんだから, 出ている範囲で判断するしかないじゃん. そりゃ非公開の API があって上で言ったような問題を解決できるかもしれないけど..." と愚痴たところで, ふたたび 社員 kenton が登場. 役目をわきまえている.
"protobuf の API にあるのは最低限の必須インターフェイスだけで, 各実装は独自の API があるんすよ. たとえば timeout を指定するなら SetTimeout() があればいいけど, 実際あります.そんなかんじで色々実装すれば OK."
stevevin はすかさず idempotent の問題に噛み付く. それがプログラマへのヒントならドキュメントに書いとけばいいじゃんと kenton. 盛り上る外野, 脱線する野次馬. インピーダンスミスマッチだ, REST だって RPC みたいなもんじゃね？ いやちがう, DCOM じゃなくて COM ならそこそこ使われてるよ.それ言ったら CORBA だって使われまくってるけど別に出来が良いからじゃないよ(言っちゃった...), RFC707 によると..., Fielding の thesis 読め, ORB子と SOA太 と REST男 の三角関係が...
再開そして決闘
話が収束しないまま疲労がたまり, 議論が行き詰まってきたところで火花は飛び火する.
ZeroC の CTO, Michi Henning が参戦してきたのだ. おお, 俄然盛り上がってきた! (野次馬的には.)
stevevin と同じく, michi も元 CORBA ベンダのエンジニアだ. CORBA 屋をやめてミドルウェアと無関係のスタートアップに移った stevevin に対し, michi は (これも小さな企業である) ZeroC で, 打倒 CORBA を目指す高速な分散オブジェクトシステム ICE を開発している. michi は "The Rise and Fall of CORBA" という記事を書くようなアンチ CORBA 派. しかし ICE を見ればわかるように, 分散オブジェクト自体を諦めてはいない. 対する stevevin は "RPC はウンコ" と罵り, 分散オブジェクト自体を捨てている. (ちなみに今は REST がお気に入りらしい.)
ところでこの二人, まったくの他人ではない. まだ CORBA の世界にいたところ, 彼らは Advanced CORBA Programming with C++ という CORBA の専門書を共著している. いわば僚友だ. しかし時は流れた. 理想論を捨てられない michi の青さに苛立つ stevevin と, ダークサイトに堕ちた stevevin に憤る michi.
michi: "なぜだ? なぜ裏切ったスティーブ!? 分散透過の原則をあれほど愛した君が...
確かに CORBA は失敗した! でもたった...たったそれだけで諦めたのか?
RFC707 を踏み躙るとは! 僕は君を許さない!!"
stevevin: "わかってないのはお前の方だよミッチー... CORBA だけじゃない,
EJB, SOAP, あらゆる分散オブジェクトが現れては消えていった.
参照透過こそが幻想なんだよ. さあ, 剣を抜け! 決着を付けてやる!!"
というかんじで, 袂をわけた二人がいま対峙している! (誇張あり.) 野次馬としては勝手に盛り上がらざるを得ない.
ただ話の内容は地味だ. michi は RFC707 を引用し, そこには RPC の定義がないと指摘する. その上で他の資料から RPC の定義を推測し, Ice を始めとするモダンな実装はかつての制限を打破してるから, 30 年前の RFC (RFC707 は 1976 年 1 月更新) を元にダメと言われても困ると主張する.
すかさず反論する stevevin. RFC707 の 4b 節を引き, "The procedure call model" がRFC の定義なのだと反論する. そしてこの定義こそがまさにダメだとした上で, たしかに 30 年たったおかげで RPC <ではない> 技術も色々登場したからよかったよと吐き捨てる. 性格わるい.
michi のターン. いま HTTP の GET を RPC だと思う人はいないけれど, RFC707 の定義で GET と他の RPC invocation を区別することはできないと主張し, やはり RFC707 は古過ぎて, 今時の分散システムを議論する論拠には不適切だと反撃する.
stevevin のターン. WS-* みたいのを置いておけば HTTP と関数呼びだしは全然違う. RPC の元々のアイデアは, 言語機能(関数)を拡張して通信を扱うことだけれど, これが本当に一番良い抽象なのかという疑問が RPC ダメ論なのだと語る. REST はもっとシンプルなのだと. (このへんの主張は 冒頭にあらわれた RPC 批判 "Convenience Over Correctness" や REST 礼賛 "Serendipitous Reuse" に詳しい.)
michi のターン. python で httplib を使ったコードを示し, いやほら, 関数呼び出しっぽいべ？ と主張. なんか急にしょぼい話に...
stevevin のターン. REST の thesis を引用し, Fielding 自身が REST と RPC は違うと言ってんだろ, と主張. まあこれは michi の REST 理解が甘く, stevevin は正しい気がする.
そのあと外野が乱入し, いや RPC も便利な場面あるよ仕事で使ってるけど, と横槍. そういう場面があるのは知ってる. ちなみに組み込みで REST も悪くないよと stevevin. せっかく盛り上っていたのに尻すぼみしてしまった. あーあ. 野次馬は家に帰ろう...
なお, Michi はこの話題について続きを書くと宣言している. 興味のある人は blog を参照のこと.
あとがき
話が野次馬ビューに偏りすぎてしまった. もう少し技術的な補足をする予定だったけれど, 疲れた今日はこのへんまで. 気がむいたら続きます.
出演:
