Webアーキテクチャ

この章の内容の多くは「Webを支える技術」(山本陽平著、技術評論社、ISBN978-4-7741-4204-3)に拠っている。

Webがどういうシステムであるかは、アーキテクチャと扱うデータという2つの観点から考察する必要がある。

リソース

Webで扱うデータは全てURI(URL)を持っている、という認識は多くの人が持っていることと思う。これは間違いではないのだが、のちに詳しく述べるように、URIで扱えるデータには、HTTP(またはHTTPS)以外でアクセスできるものも含まれる。

ここでは、Web上に置かれたデータのことをリソース(resource)と呼ぶことにする。

リソースに関して留意すべき点

  • リソースは全てURIを持つ

    • リソースには、対応するURIで示される方法でアクセスすることができる

  • 1つのリソースが複数の表現を持つことがある

    • 例:リソース「ロサンジェルスの今日の天気情報」は、HTMLページ、PDF、画像など、いろいろな表現で提供される可能性がある

  • リソースは時間の経過に従って状態が変化する

    • 例:リソース「ロサンジェルスの今日の天気情報」は、朝には晴れだったが、昼には曇りになっているかもしれない

アーキテクチャ(architecture)

  • もともとは建築学の用語:建築の様式

  • 転じて、コンピュータシステムの様式(構造・設計)を表す用語として使われるようになった

  • IBMが大型計算機System\/360で「コンピュータ・アーキテクチャ」という用語を使い始めたのが最初

アーキテクチャスタイル(architecture style)

  • アーキテクチャパターン(architecture pattern)ともいう

  • 複数のアーキテクチャに共通する性質、様式、作法、流儀など

    • 多数のアーキテクチャ構築から得られた知見

  • 代表的なソフトウェア・アーキテクチャスタイル

    • MVC (Model-View-Controller)

    • Layers

    • Pipes and Filters

REST (Representational State Transfer)

  • ネットワークシステムのアーキテクチャスタイルのひとつ

  • 2000年にロイ・フィールディング(Roy Fielding)が、Webという極めて大規模なシステムがなぜ成立し、これほど成功したのかについて分析し、博士論文としてまとめた

  • 現代のWebの最重要アーキテクチャスタイル

  • 以下の6つのアーキテクチャスタイルを合わせた複合アーキテクチャスタイル

    • クライアント・サーバ

    • ステートレス:アプリケーション状態をサーバで保存しない

    • キャッシュ:通信を通してクライアントが取得したデータを後で使い回す

    • 統一インタフェース:URIに対する操作を、統一された限定的なインタフェースで行う

      • HTTPの場合は、URIに対する操作は8つ(かなり少ない)

    • 階層化システム:システムを階層化しやすい

      • ロードバランサ、プロキシなど

    • コードオンデマンド:プログラムをサーバからダウンロードし、クライアント上で実行

クライアント・サーバ

サービスを提供するソフトウェア(サーバ)と、サービスを受けるソフトウェア(クライアント)が通信するアーキテクチャスタイル。

  • まずクライアントがサーバにリクエストを送信し、サーバがそれに対してレスポンスを返す

  • 多くの場合、クライアントはサーバに対して計算資源に劣る

  • 多くの場合、クライアントはサーバに対して非常に多い

  • メリット:クライアントとサーバの役割分担によるシステム実装の単純化など

  • デメリット:サーバには十分大きな計算資源を割り当てておく必要がある

ステートレスサーバ

クライアントのアプリケーション状態をサーバで管理しない。結果として、クライアントは、サーバに対して自身のアプリケーション状態の情報を毎回全て送信する。

  • 例:奇妙なハンバーガーショップ(「Webを支える技術」6.7節)

  • メリット:サーバの実装の単純化、クライアントが増えても対応しやすい(スケーラビリティの向上)

  • デメリット:毎回の通信量が増える

ステートレスでないアーキテクチャスタイル、すなわち、サーバがクライアントのアプリケーション状態を保存するアーキテクチャスタイルをステートフルサーバという。FTP(File Transfer Protocol、ファイル転送に広く用いられるプロトコル)やSMTP(Simple Mail Transfer Protocol、メール配送に用いられるプロトコル)など、アプリケーション層のプロトコルはほとんどがステートフルである。一方、HTTPは原則的にステートレスなプロコトルである。

理解を助けるために、山本陽平氏による喩え話を転載しよう。ハンバーガーショップでの客と店員のやりとりの例である。

ステートフルサーバとステートレスサーバはどう違うのか。まずは、ステートフルの例:

客: こんにちは

店員: いらっしゃいませ。○○バーガーへようこそ

客: ハンバーガーセットをお願いします

店員: サイドメニューは何になさいますか?

客: ポテトで

店員: ドリンクは何になさいますか?

客: ジンジャーエールで

店員: +50円でドリンクをLサイズにできますがいかがですか?

客: Mでいいです

店員: 以上でよろしいですか?

客: はい

店員: かしこまりました

これはいたって普通の会話に見える。では、ステートレスな場合はどうなのか。

客: こんにちは

店員: いらっしゃいませ。○○バーガーへようこそ

客: ハンバーガーセットをお願いします

店員: サイドメニューは何になさいますか?

客: ハンバーガーセットをポテトでお願いします

店員: ドリンクは何になさいますか?

客: ハンバーガーセットをポテトとジンジャーエールでお願いします

店員: +50円でドリンクをLサイズにできますがいかがですか?

客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします

店員: 以上でよろしいですか?

客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上

店員: かしこまりました

これを見ると、以下のことが分かる。

  • ステートフルなやりとりでは、店員(サーバ)が客(クライアント)のそれまでの注文を覚えている

  • ステートレスなやりとりでは、客(クライアント)は毎回すべての注文を繰り返している

キャッシュ

クライアントが一度取得したリソースを、後に同じリソースが必要になった時に使い回す。

  • メリット:サーバ・クライアント間の通信を減らす(通信データ量の削減、通信時間の削減など)

  • デメリット:キャッシュ管理を適切に行わないと、古いデータを使ってしまうことがある

統一インタフェース

リソースに対する操作を、統一した限定的なインタフェース(操作)で行う。

  • HTTPの場合、リソースに対する操作は8種類(かなり少ない)

  • メリット:実装が簡単になる

  • デメリット:適切なインタフェースの設計が難しい

階層化システム

システム全体を階層化する。

  • 例:サーバとクライアントの間に、サーバの負荷分散のためにロードバランサを挟む。あるいはアクセス制限のためにプロキシサーバを挟む

  • ポイント:全て同一のプロトコルを使うことで、サーバ・クライアントともシステムの変更がほとんど不要

    • クライアントとロードバランサ、ロードバランサとサーバ、両方ともHTTPを用いる、など

コードオンデマンド

プログラムコードをサーバからダウンロードし、クライアント上でそれを実行する。

  • JavaScript, Flashなど

  • メリット:クライアントの拡張が容易

  • デメリット:システムが複雑化する、セキュリティ