bookmarks=本の栞

西田 圭介 / 『Googleを支える技術 -巨大システムの内側の世界』 / 2008-03-28 / 技術評論社 / A

ビジネスモデルとか、GmailやGoogle Docsなど、表に見えるところばかりが注目されるGoogle。 それを支えているのはどんな技術なんだろうか。 バラバラに発表されている要素技術の論文や発表を丹念に追いかけて、想像し再構成し解説した本。

取り上げられている内容も素晴らしいし、翻訳と解説（こなれ具合）も素晴らしいし、紹介の仕方/順番も素晴らしい。
データセンター、電力、といったファシリティに触れるといった着目点も素晴らしい。

惜しいと思ったのは、Googleを支える技術をあまりにも分かりやすく説明してしまっているために、それがどれほどすごいことなのかを感じられないところ。
数万から数十万ユーザが同時に利用するクリティカルなシステムを設計/構築したことがないエンジニアにも、そのすごさを分からせるような"おせっかいさ"があってもいいのではないかと思った。

量はあるポイントから質を変えてしまう。
『三日でわかるLinux』とかいったCD-ROM/DVD付きの本を買ってきて古くなったパソコンにLinuxをインストールしてみて、「わーい、Apacheのサンプルページが見えた」というレベルはもちろん、クラスタ化されたAP/DBサーバ＋ロードバランサでWebサーバを数台並列稼働させるようなシステムを作っているのでは、とうてい分からない世界がある。

個人的な感触でいうと、サーバの合計台数が10台を超えると一つ山がくる。
周辺のネットワーク関連機器なども合わせて40-50台を超えるともう一つ山がくる。
台数が増えると、システムの複雑さは二次曲線的に高まる。
サーバの台数が2倍(4x2=8)に増えると、複雑さは2乗(4^2=16)になるイメージ、といったらわかるだろうか。
作るのも大変だけど、運用するのはもっと大変だ。
（もうひとつ残念だったのは、この「運用」について触れられていない点。元となる論文が公開されない以上、無い物ねだりではあるのだけれど）

例えば、さらっと「監視していて障害が発生したら」と書いてあるけど、数千というオーダーではなくて数万、数十万というオーダーなのだ。
繰り返すが、量はあるポイントから質を変えてしまう。
ms（ミリ秒）単位の遅延があっというまに秒単位の遅延になってしまう。
「ここは例外」があっというまにゴルディオスの結び目になってしまう。

本書から伺えるGoogleはとてもシンプルで分かりやすい。
どこまでが本当のGoogleの姿で、どこまでが論文にするため抽象化/簡略化された姿で、どこからが著者の力量なのか、それは本書からは分からない。

名人の技はものすごく簡単そうに見える。
Apple社の製品がシンプルで使いやすいのは、シンプルにするためにものすごいエネルギーを注いでいるから。
『アジャイルプラクティス』(p.114)で紹介されているパスカルの言葉：「長いお手紙をお許しください、短くする時間をとれなかったのです」。

いや、ホントにスゴい本だった。
続編が読みたい！ 本書で取り上げられなかった運用と「いかにシンプルに保つのか」の工夫を知りたい！

Amazon.co.jp: 『Googleを支える技術 -巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)』

Windows版Safari

Windows用のSafari 3.1が正式リリースされました。
Apple社のアナウンス

普段からSafariの美しい画面に親しんでいる私としては待ってました!のニュース。 さっそく使ってみました。

謳い文句どおり、、、とまではいきませんが、それなりの早さは体感できます。

美しい描写

画面の美しさは、Macで見るときほどではありませんが、IEやFirefoxとは比べ物になりません。
違いがよく分かるように、IEとFirefoxとSafariを並べて同じページを表示してみました（クリックすると大きな画像が開きます）。
※ 環境はWindows XPで、OSのアンチエイリアス機能であるClearTypeは機能していません。Safariのアンチエイリアスは「弱」にしてあります。

アンチエイリアスを「強」にすると、かえってみにくくなりますね。サンプルを下に貼付けておきます（これもサムネールをクリックすると拡大画像をポップアップで表示します）。

続きを読む

高機能コマンドラインHTTPクライアント、cURLでHTTP Status Codeを調べる方法です。

Googleで検索してみると、PHPから利用する方法は結構見つかりますが、シェルスクリプトから利用するなど、cURL本体の機能については解説しているページがほとんどありません。
そこで簡単なサンプルで使い方を解説してみます。

結論を先にお伝えすると、-wというオプションを利用します。
cURLのマニュアルページではこのように記載されています。

-w/--write-out <format>

Defines what to display on stdout after a completed and successful operation. (snip)

http_code The numerical code that was found in the last retrieved HTTP(S) page.

では、サンプルスクリプトを。

#!/bin/bash
CURL="/usr/local/bin/curl"
URL="http://www.example.jp/index.html"
OUTPUT="output.html"
STATUS="status.txt"
${CURL} -s ${URL} -o ${OUTPUT} -w '%{http_code}\n' > ${STATUS}

-wで指定した項目は標準出力に表示されますが、cURLでは他にもいろいろなモノが標準出力に表示されます。
上の例では、ゲットしたコンテンツをファイルに保存したり（-o ファイル名）、プログレスバーを消したり（-s）しておいて、HTTP Status Codeだけをファイルに保存しています。

実際に利用する場合はもう少し工夫が必要です。

• -S: cURLのエラーは原因調査のためにも表示する
• -w 'http_code=%{http_code}\n': 他の出力結果と区別が付くようにヘッダも記録する
• -I: 更新チェックだけでいいときは、ヘッダのみ取得する

取得したHTTP Status Codeが何を意味するのかを調べるならこちら。

• 本家 Status Code Definitions(RFC 2616 HTTP/1.1)
• 日本語の参考資料 HTTP Status Code (Studying HTTP)

※Studying HTTPは、Status Codeに限らずHTTPに関する技術資料が非常に充実している良質のサイトです。