yohei-y:weblog

» Permanent link | はてなブックマーク | livedoor clip

ブログを書くまでがトークセッションです、と自分で言ってしまった手前書かないわけにはいかなくなってしまったわけです。

第4回卓人の部屋でしゃべってきました。 池袋のジュンク堂に行くのは2回目です。前回はRWSのPOPを置きに行ってきました。 ジュンク堂の6Fでは高橋会長の本を全力で応援するフェアというのをやっていた。

とりあえずKPTで振り返ってみました。

Keep

トークセッションを満員御礼にできた

taiさんが来てくれてた

高橋会長にたくさん話をふった

いろいろな人と名刺交換した

shuyoさんと久々に会った

なんばさんに超久々に会った(×ばつな話を聞いた)

yojikさんやshot6さんと初めて会えた

私服の長田さんに会えた

発売日に増刷がかかった

Problem

和田さんに負担をかけすぎた

開始が15分くらい遅れてしまった

会場を見回しながら話ができなかった

ちょっと内輪な話をしすぎたか?

もうちょっと穏便な発言をすべきだったような

話を伝えるのは難しい

咳しすぎ

レオの質問にちゃんと答えられなかった

オライリーの高さんの前でRWSをDISってしまった

懇親会で全員とお話できなかった

JSONPは脆弱性だろjk、というコメントにogijunと簡単だからいいじゃんと軽く答えたんだけどもう少しまともに答えられれば良かった

高橋会長とお話できなかった

POPを書いたのがそこそこ酔っ払ってから

Try

事前に参加者リストをジュンク堂さんからもらう

体調管理は万全に

火曜日に本書の打ち上げがあるのでそこで高橋会長と和田さんとじっくり話す

サインの練習

こうしてみるとProblemばかりですが、twitterやブログでの反応をみると満足してくださった方が多いようなので安心しました。

後から思ったこと。アドレスバーの話。アドレスバーに出現するURIをコピペできるのがWebの疎結合の源泉。 だからアドレスバーでURIが表示されてそれを別のアプリにコピペできることはとても重要。 これはレオさんの質問(URIでいいの?)に対する答のヒントになるかな。 URIのこのシンプルさと重要性はとても深くて、高橋さんのつっこみのWebのフラットさとかアーレントの件とかにつながるんだろうな。

トークセッション中に言及した書籍やリンクなどをご紹介しておきます。

村田さんの本。もう絶版なんだよなー、もったいない。 この本はXMLの本なんですが、Webの本でもあります。 このころ検討されていたハイパーリンクの話は今読むと実は参考になるかも。

分散システムの教科書。ちなみにタネンバウムと共著のスティーン先生のWebページではこの本を使った授業のスライドが入手できます。

リソースモデリングの話は羽生さんのこの本を目指して書いたのですが、とてもここまでは至りませんでした。 羽生さんは本当にすごいっす。ERDレッスンはWeb技術者必携の本です。

僕はこの本で情報アーキテクチャを知りました。 著者のJesse James GarrettはAjaxという言葉を作った人です。 Amazonのレビューにもあるけど訳がちょっとやばいんですが、薄くてよい本です。

情報アーキテクチャ、ちゃんと学ぶならこちらの本の方がお勧めです。なんですがやっぱり訳が...。なんとかならないのかな、この状況。

最後に業務連絡なのですが、おかげさまで増刷がかかったため、2刷に向けて改訂作業中です。明日(2010年04月11日)までにtwitterで#webtechbookをつけてつぶやいてもらえると、収集して反映します。こちらのWikiにまとめ中です。よろしくお願いします

ラベル: webtechbook

» Permanent link | はてなブックマーク | livedoor clip

このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。

この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。

ただ、「RESTレシピ」の連載を続けるうちに、少し疑問に思うことが出てきたのです。「RESTレシピ」は基本的にHTTPやURIの知識を前提に、それらをどうRESTfulに使うか、を解説しようと試みた連載です。HTTPとURIはいわば前提知識でした。しかし、その前提知識を得ようとすると、結構大変なことがわかります。

具体的には本書のレビュアをお願いした高橋さん(高橋さんは同時並行していた文字コード本もレビューしていたそうです。さらに最近監訳本も出てるし...凄いですね!)のこのエントリが詳しいですが、HTTP解説本は現在壊滅的な状況です。僕も学んだ『Webプロトコル詳解』も『HTTP詳説』も絶版なのです。僕が2007年に監訳した『RESTful Webサービス』があるのですが、こちらはHTTPやURIを主題に解説しているわけではありません。オライリーにも英語であれば『HTTP Definitive Guide』がありますが、残念ながら日本語訳は出ていません。

幸いなことに日本にはStudying HTTPという素晴らしいサイトがあります。HTTPやURIの詳しい仕様を知ろうと思えば、このサイトで事足りることも多いです。ただし、Studying HTTPさんはあくまでも仕様の解説であり、その仕様をWebサービスの開発においてどのように実践的に使っていくか、という情報はあまりありません。

ということで、このような状況を打破すべく本を書こうと思い立ったのでした。『Webを支える技術』というタイトルから想像する技術は人によって異なると思いますが、本書で対象としている技術は副題にある「HTTP、URI、HTML、そしてREST」です。ちなみにHTMLは代表例で本書では他のハイパーメディアフォーマット(Atom、JSON)も扱っています。これらの仕様を解説しながら、この仕様はなぜこうなっているのか、どのように使えばいいのか、を本書では解説しています。

目次は以下のような感じです。大きくわけて5部構成で、第1部はWebの歴史とRESTについて、第2部はURIの仕様、第3部はHTTPの仕様、第4部はHTML、Atom、JSONの仕様、第5部はWeb サービスの設計になっています。

◇第1部 Web概論
□しろいしかく第1章 Webとは何か
■しかく1.1 すべての基盤であるWeb
■しかく1.2 さまざまなWebの用途
■しかく1.3 Webを支える技術
■しかく1.4 本書の構成
□しろいしかく第2章 Webの歴史
■しかく2.1 Web以前のインターネット
■しかく2.2 Web以前のハイパーメディア
■しかく2.3 Web以前の分散システム
■しかく2.4 Webの誕生
■しかく2.5 Webの標準化
■しかく2.6 Web APIをめぐる議論
■しかく2.7 すべてがWebへ
□しろいしかく第3章 REST ── Webのアーキテクチャスタイル
■しかく3.1 アーキテクチャスタイルの重要性
■しかく3.2 アーキテクチャスタイルとしてのREST
■しかく3.3 リソース
■しかく3.4 スタイルを組み合わせてRESTを構成する
■しかく3.5 RESTの2つの側面
■しかく3.6 RESTの意義
◇第2部 URI
□しろいしかく第4章 URIの仕様
■しかく4.1 URIの重要性
■しかく4.2 URIの構文
■しかく4.3 絶対URIと相対URI
■しかく4.4 URIと文字
■しかく4.5 URIの長さ制限
■しかく4.6 さまざまなスキーム
■しかく4.7 URIの実装で気をつけること
□しろいしかく第5章 URIの設計
■しかく5.1 クールなURIは変わらない
■しかく5.2 URIを変わりにくくするためには
■しかく5.3 URIのユーザビリティ
■しかく5.4 URIを変更したいとき
■しかく5.5 URI設計のテクニック
■しかく5.6 URIの不透明性
■しかく5.7 URIを強く意識する
◇第3部 HTTP
□しろいしかく第6章 HTTPの基本
■しかく6.1 HTTPの重要性
■しかく6.2 TCP/IPとは何か
■しかく6.3 HTTPのバージョン
■しかく6.4 クライアントとサーバ
■しかく6.5 リクエストとレスポンス
■しかく6.6 HTTPメッセージ
■しかく6.7 HTTPのステートレス性
■しかく6.8 シンプルなプロトコルであることの強み
□しろいしかく第7章 HTTPメソッド
■しかく7.1 8つしかないメソッド
■しかく7.2 HTTPメソッドとCRUD
■しかく7.3 GET ── リソースの取得
■しかく7.4 POST ── リソースの作成、追加
■しかく7.5 PUT ── リソースの更新、作成
■しかく7.6 DELETE ── リソースの削除
■しかく7.7 HEAD ── リソースのヘッダの取得
■しかく7.8 OPTIONS ── リソースがサポートしているメソッドの取得
■しかく7.9 POSTでPUT/DELETEを代用する方法
■しかく7.10 条件付きリクエスト
■しかく7.11 べき等性と安全性
■しかく7.12 メソッドの誤用
■しかく7.13 Webの成功理由はHTTPメソッドにあり
□しろいしかく第8章 ステータスコード
■しかく8.1 ステータスコードの重要性
■しかく8.2 ステータスラインのおさらい
■しかく8.3 ステータスコードの分類と意味
■しかく8.4 よく使われるステータスコード
■しかく8.5 ステータスコードとエラー処理
■しかく8.6 ステータスコードの誤用
■しかく8.7 ステータスコードを意識して設計する
□しろいしかく第9章 HTTPヘッダ
■しかく9.1 HTTPヘッダの重要性
■しかく9.2 HTTPヘッダの生い立ち
■しかく9.3 日時
■しかく9.4 MIMEメディアタイプ
■しかく9.5 言語コード
■しかく9.6 コンテントネゴシエーション
■しかく9.7 Content-Lengthとチャンク転送
■しかく9.8 認証
■しかく9.9 キャッシュ
■しかく9.10 持続的接続
■しかく9.11 そのほかのHTTPヘッダ
■しかく9.12 HTTPヘッダを活用するために
◇第4部 ハイパーメディアフォーマット
□しろいしかく第10章 HTML
■しかく10.1 HTMLとは何か
■しかく10.2 メディアタイプ
■しかく10.3 拡張子
■しかく10.4 XMLの基礎知識
■しかく10.5 HTMLの構成要素
■しかく10.6 リンク
■しかく10.7 リンク関係 ── リンクの意味を指定する
■しかく10.8 ハイパーメディアフォーマットとしてのHTML
□しろいしかく第11章 microformats
■しかく11.1 シンプルなセマンティックWeb
■しかく11.2 セマンティクス(意味論)とは
■しかく11.3 RDFとmicroformats
■しかく11.4 microformatsの標準化
■しかく11.5 microformatsの分類
■しかく11.6 microformatsとRDFa
■しかく11.7 microformatsの可能性
■しかく11.8 リソースの表現としてのmicroformats
□しろいしかく第12章 Atom
■しかく12.1 Atomとは何か
■しかく12.2 Atomのリソースモデル
■しかく12.3 エントリ ── Atomの最小単位
■しかく12.4 フィード ── エントリの集合
■しかく12.5 Atomの拡張
■しかく12.6 Atomを活用する
□しろいしかく第13章 Atom Publishing Protocol
■しかく13.1 Atom Publishing Protocolとは何か
■しかく13.2 AtomPubのリソースモデル
■しかく13.3 ブログシステムを例に
■しかく13.4 メンバリソースの操作
■しかく13.5 サービス文書
■しかく13.6 AtomPubに向いているサービス
□しろいしかく第14章 JSON
■しかく14.1 JSONとは何か
■しかく14.2 メディアタイプ
■しかく14.3 拡張子
■しかく14.4 データ型
■しかく14.5 JSONPによるクロスドメイン通信
■しかく14.6 ハイパーメディアフォーマットとしてのJSON
◇第5部 Webサービスの設計
□しろいしかく第15章 読み取り専用のWebサービスの設計
■しかく15.1 リソース設計とは何か
■しかく15.2 リソース指向アーキテクチャのアプローチ
■しかく15.3 郵便番号検索サービスの設計
■しかく15.4 Webサービスで提供するデータを特定する
■しかく15.5 データをリソースに分ける
■しかく15.6 リソースにURIで名前を付ける
■しかく15.7 クライアントに提供するリソースの表現を設計する
■しかく15.8 リンクとフォームを利用してリソース同士を結び付ける
■しかく15.9 イベントの標準的なコースを検討する
■しかく15.10 エラーについて検討する
■しかく15.11 リソース設計のスキル
□しろいしかく第16章 書き込み可能なWebサービスの設計
■しかく16.1 書き込み可能なWebサービスの難しさ
■しかく16.2 書き込み機能な郵便番号サービスの設計
■しかく16.3 リソースの作成
■しかく16.4 リソースの更新
■しかく16.5 リソースの削除
■しかく16.6 バッチ処理
■しかく16.7 トランザクション
■しかく16.8 排他制御
■しかく16.9 設計のバランス
□しろいしかく第17章 リソースの設計
■しかく17.1 リソース指向アーキテクチャのアプローチの落とし穴
■しかく17.2 関係モデルからの導出
■しかく17.3 オブジェクト指向モデルからの導出
■しかく17.4 情報アーキテクチャからの導出
■しかく17.5 リソース設計で最も重要なこと
◇付録
□しろいしかく付録A ステータスコード一覧
□しろいしかく付録B HTTPヘッダ一覧
□しろいしかく付録C 解説付き参考文献

2年の連載(全12回)のベースがあるから比較的楽に書けるよなーと最初は楽観的に思っていたのですが、これが大間違いでしたw。はっきりいって原型をとどめているところはほんの少しだけになっています。連載時の原稿は本書の100ページ分くらいだったので、最初はページ数が足りるかどうか心配だったのですが、書いてみたらなんと400ページの本になってしまいました。前付けと後付けを除くと350ページ強なので、2/3を書きおろしたことになります。また、連載時の原稿もかなり修正したり切り貼りしたり、校正したりしてあるのでバグも直っているし文章も読みやすくなっているはずです。

業務連絡:すでにAmazonなどには本書の情報が載っていて、ブックマークもされているのですが2つ変更点をお知らせします。

1つめは発売日についてです。Amazon上は3/18発売になっているかと思いますが、これが諸般の大人の事情で4/8になりました。すでにAmazon等で予約してくださったかたには3週間ほどの延期になってしまいます。申し訳ありません。

2つめの変更点は価格です。発売日延期のお詫びというわけではないですが、10円値下げして2570円+税になりました。なので税込2700円以内で買えるようになりました。それでもやっぱり技術書は高いのですが、技評さんに頑張ってもらいました。

追記(2010年03月07日) Amazon上の発売日と価格、そしてタイトルの誤記が直りました。

最後にイベントのお知らせです。発売日の4/8(木)に合わせて、ジュンク堂書店池袋店にてトークセッションをやります。さすがに僕一人で話すのは無理なので、レビュアをお願いしたt-wadaさんにお願いしました。なのでこのトークセッションは自動的に第4回卓人の部屋になる予定ですw。

• 『Webを支える技術』刊行記念トークセッション
• 日時: 2010年4月8日 19:00〜
• ジュンク堂書店池袋本店4階カフェにて

なお、ジュンク堂さんでは本書の発売に合わせてフェアもやってくださるそうなので、トークセッションにいらしていただくといろいろ面白い本が一緒に買えると思います。まだ何を話すのかとか全然決まっていないのですが、少しでも面白い話をできるように和田さんと打ち合わせるようにします。よろしくお願いします。

あ、あともう一つ忘れていました。本書の公式ハッシュタグは「webtechbook」になりました。高橋さんの命名です。すでにtwitterでは少しだけ使い始めています。このエントリのタグもwebtechbookにしました。ご愛用ください。それからtogetterにまとめページがあります。このハッシュタグを使ってもらえるとまとめやすくなると思います。

最後に、gihyo.jpでそのうち公開されるはずですが、本書のはじめにから少しだけ引用しておきます。

システムとしてのWebの構造や設計思想、いわゆるアーキテクチャは初期からほとんど変わっていません。最初のWebブラウザと現在のWebブラウザでは実現している機能に雲泥の差がありますが、使っているプロトコルは依然としてHTTPですし、表示しているのは昔も今もHTMLです。Webが誕生してから20年、常に新しい技術が生まれてきました。しかしその基本となるアーキテクチャは同じです。これはアーキテクチャの完成度がとても高いことを示しています。

(中略)

しかし一方で、簡単に接続できなかったり、データを活用するのに特殊なノウハウが必要だったりするWebサービスも存在します。簡単に接続できるWebサービスと、接続するのが難しいWebサービスとの違いはどこにあるのでしょうか。

その答えは「Webらしい設計」にある、と筆者は考えています。サービスをWebらしく作ると、ほかのシステムと簡単に連携でき、将来の拡張も楽になるのです。良い設計のWebサービスは、Web全体のアーキテクチャと調和しています。Webらしい良い設計をするためには、Webのアーキテクチャを理解して意識することが大切です。

本書は、WebサービスをいかにWebらしく設計するかをテーマとしています。クライアントとサーバはどのように役割分担するのか、望ましいURIとはどのようなものか、HTTPメソッドはどのように使い分けるのか。Webサービスにおけるこれらの設計課題について、現時点でのベストプラクティスを紹介します。このテーマを実現するために、本書は次の2つの目的を持って執筆しました。

(中略)

本書の対象読者は、規模の大小にかかわらずWeb技術を使ったシステムを開発した経験のある人です。本書にはプログラミング言語のコードはほとんど登場しません。なぜなら、アーキテクチャは実装よりも1段階抽象度が高い概念だからです。その代わりに登場するのが、具体的なHTTPのやりとりです。HTTPのライブラリは、ほとんどすべてのプログラミング言語で用意されています。読者のみなさんが得意な言語でどのように実装するかを想像しながら読んでいただけると、よりわかりやすくなると思います。

ラベル: webtechbook

» Permanent link | はてなブックマーク | livedoor clip

先週の金曜日に開催された yokohama.pm で、最近のこのブログのメインネタである CAPとBASEとEventually Consistentについてお話してきました。 このネタ、あまり公の場で話すチャンスがないのでこういう機会をいただけてよかったです。 ありがとうございました。

最近なにかと忙しくてあんまり更新できませんが、 まだ続く予定です。

そんじゃーね

ラベル: base, cap, eventuallyconsistent

» Permanent link | はてなブックマーク | livedoor clip

CAP 定理と BASE の概念を考えたのは UCB の Brewer 先生で、彼は inktomi の偉い人だったというのは前回述べた。

当時のinktomiはYahoo!や Microsoft、それにgooにも検索エンジンを提供していて、1億以上のWebページ(テラバイト級のデータ)を扱っていたようだ。

手元のWEB+DB PRESS Vol.49 のはてなブックマークリニューアル記事によると、現在のはてなブックマークは1160万URLと100GBのHTMLデータ(圧縮済み)を扱っているらしいので、ざっくりいって98年の時点でinktomi は現在のはてブの10倍のデータを扱っていたといってもいい。inktomiで使っていたコンピュータの性能は現在のPCサ ーバに比べれば1/10程度の性能なので、システム全体でみると現在のはてブの100倍の規模になるだろうか。

結果的には、inktomiのビジネスは失敗し、検索大手の座はGoogleに奪われることになるのだが、Googleに数年先ん じてWebのための分散システムを構築することでBrewerはWebスケールの分散システム構築における理論的基盤を獲得す るための経験値を得たのだと思う。

彼がこの時点で得た理論的基盤というのがCAP定理と伝統的なACIDトランザクションを緩和するBASEという考え方で ある。これが2000年の話。

CAPは2002年にMITのSeth Gilbert と Nancy Lynchによって形式化され、 晴れて定理となる。CAP定理によれば

• Consistency (データの整合性)
• Availability (システムの可用性)
• tolerance to network Partitions (ネットワーク分断への耐性)

の三つのうち同時に達成できるのは常に二つしかない、ことが明かになっている。

CAP のうち、AとPの意味するところは簡単にいうと以下のようになる。

Availability は分散システムにおけるデータの受給者(簡単にいうとブラウザなどのクライアントのこと)が、 常にサービスにアクセス(読込みも、書込みも)できるということを保証する。 サーバ側の都合でデータにアクセスできないことがあるとき、そのシステムは Availability を満たしていない。

Partition tolerance は、分散システムを構成するノード(簡単に言うと物理・仮想サーバ)がひとつ壊れたとして もシステム全体が問題なく動作しつづけることを保証する。 システム中のデータを保持しているサーバのうち1台がが物理的にクラッシュしたときに、 データの読込みや書込みができなくなったら、そのシステムは Partition tolerance を満たしていない。

残りの一つ、Consistency はACIDのCと混同しがちであるが、両者の定義は違う(ここ重要)。 ACIDトランザクションの文脈での C は、 Wikipediaでは以下のように説明されている。

日本語では一貫性とも呼ばれる。トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保 証する性質を指す。つまり、データベースのルール、つまり整合性条件を満たさない状態を起こすようなトランザクシ ョンは実行が中断される。

預金残高を例にすると、その値は一般的に0あるいは正の値を取る条件を満たす必要がある。よって、口座Aから送 金を行うとき、その前後でAの口座残高が負になるような額を送金することはできないが、これを保証するのが Consistencyの役割である。

これに対してCAP 定理の C は異なる。 CAPの Consistency は、あるクライアントがシステムのデータを更新したら、 続いてアクセスするすべてのクライアントが必ず更新されたデータを取得できることを保証するものである。

このconsistency をめぐる混乱は、CAPとBASEの議論をわかりづらくしているように思える。 実際に Seth Gilbert と Nancy Lynchの論文では Consistency という言葉は使わずに、 Atomic data object という言葉を使っている(しかしこの Atomic も ACID の Aとは定義が違うので注意!)。

インターネットスケールのサービスでは、 必然的に並列処理とノンストップのサービスが求められるので、 可用性とネットワーク分断耐性が必須となり、CAP定理に従えば整合性については妥協することになる...

...なる、はずだが現在のWebサービスは、超大規模な分散システムとして運用されているにもかかかわらず、 CAPのC(整合性)も満たした上でA(可用性)とP(ネットワーク分断耐性)を実現しているように見える。

実はいろいろな大規模サイト(Amazon, eBay, Windows Live, ...)が、 CAP/BASE を知ってか知らずか、独自にそれぞれ分散システムを作ってきたら、 可用性とネットワーク分断耐性を確保しながら、 ある程度の整合性を確保するような分散システムの構築方法について同じような結論を得て、 その理論的背景として CAP/BASE がぴったり収まった、というのが面白いところだと思う。

この分散システム構築のノウハウのキーワードとなるのが BASE の E、Eventually Consistent という考え方なのである。

つづく

ラベル: base, cap

» Permanent link | はてなブックマーク | livedoor clip

時系列で

• 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る
  • CAPとBASEの基礎ができる
  • http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/
• 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表
  • CAP は Brewer 予測として知られるようになる
  • この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない
• 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化
  • ここで Brewer の CAP が晴れて定理となった
• この間、よくわからず
• 2007年-: eBay の Dan Pritchett が CAP/BASE ベースでいろいろ考える
  • Colorado Software Summit 2007
  • InfoQ の記事とインタビュー
  • QCon 2008
  • 2008年1月の ACM Queue に Dan Pritchett の記事(BASE an ACID alternative)が載る
• 2007年- Amazon CTO の Werner Vogels が Eventually Consistensy 関係でいろいろ
  • QCon London でのプレゼン (2007/08)
  • Eventually Consistent のエントリ(2007/12)をポスト(日本語訳)
  • CACM に Vogels の論文(Eventually consistent)が載る(2009/01)
• 今ここ

歴史的には Brewer が inktomi の創業者であることが興味深い。

すでに inktomi を知らない人がいるかもしれないけれど、 検索エンジンの淘汰の歴史の流れの中で AltaVista と Google の間にいるのが inktomi だ。 inktomiは創業が1996年。Web初期の検索エンジンの座をAltaVistaから奪い、後にYahoo!に買収された。

Wikipedia の記事が詳しいが AltaVista が DEC の Alpha サーバの性能を売りにした scale-up 的アプローチだったのに対し、inktomi は Scale-out 的アプローチを取ったのが(AltaVistaに対する)技術的な成功要因だったようだ。Brewer のスライドの写真を見ると、時期的にはどうやら Sun の UltraSparc II のクラスタを構築していたようだ。これはまさに僕がNAISTの自席で使っていたワークステーションだけれど、CPUが250MHzで640MBメモリを搭載していたと記憶している。

inktomiが取ったこのscale-out戦略ベースのアーキテクチャは今のWebの大規模分散システムの根源となるアーキテクチャとなっている。

つづく

ラベル: base, cap