yohei-y:weblog

XML と REST/Web サービス関連の話題が中心の weblog です

2010-04-10

Webを支える技術ジュンク堂トークセッション(第4回卓人の部屋)総括

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

第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の本でもあります。 このころ検討されていたハイパーリンクの話は今読むと実は参考になるかも。

photo
分散システム 原理とパラダイム 第2版
アンドリュー・S・タネンバウム, マールティン・ファン・スティーン
ピアソンエデュケーション 2009-01-23

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

photo
楽々ERDレッスン (CodeZine BOOKS)
(株)スターロジック 羽生 章洋
翔泳社 2006-04-18

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

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

photo
Web情報アーキテクチャ―最適なサイト構築のための論理的アプローチ
ルイス ローゼンフェルド, ピーター モービル
オライリージャパン 2003-08

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

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

ラベル:

2010-03-03

『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

このブログ、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。

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

あ、あともう一つ忘れていました。本書の公式ハッシュタグは「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のライブラリは、ほとんどすべてのプログラミング言語で用意されています。読者のみなさんが得意な言語でどのように実装するかを想像しながら読んでいただけると、よりわかりやすくなると思います。

ラベル:

2009-04-21

yokohama.pm で Eventually Consistent の話をしてきました

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

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

そんじゃーね

ラベル: , ,

2009-03-17

CAPのCとACIDのC

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 という考え方なのである。

つづく

ラベル: ,

2009-03-03

CAP と BASE について調べたこと

時系列で

歴史的には 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の大規模分散システムの根源となるアーキテクチャとなっている。

つづく

ラベル: ,