Definition：Web architecture
Webアーキテクチャとは、World Wide Web上でクライアントとサーバーが情報をやり取りするための構造・設計原則の総称である。HTTP/HTTPSプロトコルを介したリクエスト・レスポンス型の通信を基盤とし、クライアント（ブラウザ等）、サーバー、データベース、ネットワークインフラといった構成要素間の役割分担と相互作用の方式を定義する。代表的な構成モデルには以下がある。
Webアーキテクチャとは、World Wide Web（Web）を構成する情報資源、識別方式、通信プロトコル、クライアント、サーバー、データ形式、アプリケーションなどの関係を定める技術的な構造である。Webは当初、ネットワーク上に分散した文書を相互に参照するための仕組みとして設計されたが、その後、動的なWebアプリケーション、Web API、クラウドサービス、リアルタイム通信、エッジコンピューティングなどを支える分散システム基盤へと発展した。
Webアーキテクチャの中心には、情報資源を識別するURI、情報資源を取得・操作するためのHTTP、情報の構造を記述するHTML、表示を制御するCSS、ブラウザ上で処理を実行するJavaScriptなどがある。さらにDNSによる名前解決、IPによるネットワーク通信、TLSによる通信の保護、Webサーバー、アプリケーションサーバー、データベース、キャッシュ、CDN、ロードバランサー、APIゲートウェイ、コンテナ、クラウド基盤などが組み合わされる。したがって、Webアーキテクチャは単なるWebページの構造ではなく、ネットワークを介して分散した計算資源と情報資源を相互接続するためのアーキテクチャである。
Webの起源は、1989年に英国の物理学者ティム・バーナーズ＝リー（Tim Berners-Lee）がCERNで提案した情報共有システムにある。当時のCERNでは、多数の研究者が異なるコンピュータやシステムを利用しており、文書や情報がそれぞれ異なる場所に分散していた。そこで、ネットワーク上に分散した情報を相互に参照できる汎用的な仕組みが必要とされた。
バーナーズ＝リーが構想したWebは、特定のコンピュータにすべての情報を集約する方式ではなかった。ネットワーク上に存在する個々の情報資源を識別し、それらをハイパーリンクによって相互に結び付け、必要な情報をネットワーク経由で取得する方式である。この構造によって、異なるコンピュータや異なる組織が管理する情報を、同じ基本的な仕組みによって参照できるようになった。
Webの初期構成では、情報資源を識別するためのURL、文書を記述するHTML、情報を転送するHTTPが重要な役割を担った。1990年には最初のWebサーバーとWebブラウザがCERNで実装され、1991年にはWebが外部に公開された。その後、Web技術が広く公開されたことで、WebはCERN内部の情報共有システムから、インターネット上で利用できる汎用的な情報基盤へと発展した。
Webがインターネット上へ広がるうえで重要な転換点となったのが、1993年に登場したMosaicなどのグラフィカルなWebブラウザである。テキスト中心であった初期のWebブラウザに対し、画像を含む文書を視覚的に表示できるブラウザが普及したことで、Webは研究者や技術者だけでなく、一般利用者にも利用される情報媒体となった。
1994年にはWorld Wide Web Consortium（W3C）が設立され、HTML、CSS、DOMなどを含むWeb技術の標準化が進められた。Webは特定企業の独自仕様だけに依存するのではなく、複数のブラウザやサーバーが相互運用できる標準技術を基盤として発展していった。この標準化は、Webが世界規模のオープンなプラットフォームになるうえで重要であった。
1990年代後半にはWebブラウザの普及とともにWebサイトが急増し、Webは情報公開のための主要な媒体となった。この時期のWebページは比較的静的なHTML文書が中心であり、Webサーバーは要求されたファイルを返すという単純な構成が一般的であった。
Webアーキテクチャの根本にあるのが、ネットワーク上の情報資源を識別する仕組みである。URI（Uniform Resource Identifier）は情報資源を識別するための統一的な識別子であり、URL（Uniform Resource Locator）はURIの一種として、資源の取得方法や場所を表す。
例えば、`https://example.com/articles/web.html`というURLでは、`https`が使用するスキームを示し、`example.com`がホスト名を示し、`/articles/web.html`が対象となる資源を示している。Webブラウザはホスト名をDNSによってIPアドレスに解決し、そのIPアドレスを使用してネットワーク上のサーバーと通信する。
HTMLではリンク先のURIを指定することで、ある文書から別の文書や情報資源を参照できる。これがハイパーリンクである。Webでは、情報資源そのものを一つの巨大なデータベースに集約するのではなく、分散した情報資源を識別子とリンクによって結び付ける。この分散型の構造がWebの基本的な特徴である。
Webの通信はWeb固有の技術だけで完結するものではなく、インターネットのネットワーク基盤の上に構築されている。利用者が`example.com`のようなホスト名を指定すると、DNS（Domain Name System）がその名前を対応するIPアドレスへ変換する。これによって、人間が扱いやすいドメイン名と、ネットワーク通信で使用されるIPアドレスを分離できる。
WebブラウザはDNSによって得られたIPアドレスを利用してサーバーとの通信を確立する。HTTPによるWeb通信は、この下位層にあるIPネットワークやトランスポート層のプロトコルの上で動作する。初期のHTTPではTCPが通信の基盤として利用され、現在もHTTP/1.1やHTTP/2ではTCPが使用されている。一方、HTTP/3ではQUICが採用されており、Webの通信方式はネットワーク技術の発展とともに変化している。
HTTP（Hypertext Transfer Protocol）は、Webにおける情報資源の取得や操作を実現する主要なアプリケーション層プロトコルである。クライアントがリクエストを送信し、サーバーがレスポンスを返すという要求・応答型の通信モデルを基本とする。
典型的なWebアクセスでは、ブラウザが`GET`メソッドによってURIで指定された資源を要求し、サーバーがHTMLや画像、CSS、JavaScriptなどをレスポンスとして返す。`POST`はデータの送信などに利用され、`PUT`、`PATCH`、`DELETE`などはWeb APIにおけるリソースの更新や削除などに利用される。
HTTPレスポンスにはステータスコードが含まれる。`200`番台は成功、`300`番台はリダイレクト、`400`番台はクライアント側の要求に関するエラー、`500`番台はサーバー側のエラーを表す。例えば`200 OK`は正常な処理、`301 Moved Permanently`や`302 Found`はリダイレクト、`404 Not Found`は指定された資源が見つからないこと、`500 Internal Server Error`はサーバー内部で処理に失敗したことを示す。
Webの普及に伴って、HTTPそのものも大きく発展した。初期のHTTPは単純な文書転送を主な用途としていたが、Webページを構成するHTML、画像、CSS、JavaScriptなどの資源が増加すると、通信効率の改善が必要になった。
HTTP/1.1では持続的接続が導入され、一つのTCP接続を複数のリクエストに利用できるようになった。その後、HTTP/2ではストリームを利用した多重化などが導入され、一つのTCP接続上で複数のリクエストとレスポンスを並行して処理できるようになった。
HTTP/3では、TCPに代わってQUICを利用する。QUICはUDPを基盤としながら、暗号化、信頼性のあるデータ転送、多重化などを実現する。これによって接続確立やパケット損失時の処理などを改善し、現代のWebに適した通信方式を実現している。
Webのクライアント側を構成する主要技術にはHTML、CSS、JavaScriptがある。HTML（HyperText Markup Language）はWeb文書の構造と意味を記述する。見出し、段落、リンク、画像、表、フォームなどをHTMLの要素によって表現する。
CSS（Cascading Style Sheets）はHTMLなどで記述された文書の表示方法を指定する。文字の大きさや書体、色、余白、配置、画面のレイアウトなどを制御できる。HTMLが文書の構造を担当し、CSSがその視覚的な表現を担当するという分離によって、同じ文書構造を異なる表示環境に対応させることが可能になった。
JavaScriptはWebブラウザ上で実行されるプログラミング言語として発展した。ユーザーの操作を受け取って処理したり、HTMLの内容を動的に変更したり、HTTPを利用してサーバーと非同期に通信したりできる。JavaScriptの発展によって、Webブラウザは単なる文書表示ソフトウェアから、アプリケーションを実行する環境へと変化した。
Webの初期には、Webサーバーが保存されているHTMLファイルをそのまま返す静的Webが中心であった。しかしWebの利用目的が広がるにつれて、利用者の入力やデータベースの内容に応じて異なるページを生成する必要が生じた。
そこでCGI（Common Gateway Interface）などを利用して、Webサーバーから外部プログラムを呼び出し、処理結果をHTMLとして返す仕組みが利用されるようになった。さらにPHP、Perl、Java、ASPなどのサーバーサイド技術が発展し、データベースと連携した動的Webアプリケーションが一般化した。
例えばオンラインショップでは、商品情報をデータベースに保存し、利用者が指定した条件をサーバー側で処理して検索結果を生成する。この場合、Webブラウザ、Webサーバー、アプリケーション、データベースが連携して一つのサービスを構成することになる。
Webアプリケーションの基本構造はクライアント・サーバーアーキテクチャとして捉えることができる。クライアントはサービスを利用する側であり、Webブラウザが代表的なクライアントである。サーバーは情報資源を提供したり、要求された処理を実行したりする。
単純なWebサイトではWebサーバーがHTML、CSS、画像などを直接配信する。一方、動的なWebアプリケーションでは、Webサーバーの背後にアプリケーションサーバーやデータベースが配置される。
WebサーバーはHTTP通信や静的資源の配信を担当し、アプリケーションサーバーは業務ロジックを実行し、データベースは永続的なデータを管理するという役割分担が可能である。この分離によって、それぞれの構成要素を独立して変更、拡張しやすくなる。
Webアプリケーションが大規模化すると、すべての処理を一つのプログラムに集約するのではなく、役割ごとに分離する多層アーキテクチャが利用されるようになった。
典型的な構成では、ユーザーとのインターフェースを担当するプレゼンテーション層、業務処理を担当するアプリケーション層、データの保存と検索を担当するデータ層に分ける。
この構造では、例えばWebページのデザインを変更しても業務ロジックやデータベースそのものを変更せずに済む場合がある。また、同じ業務ロジックをWebブラウザだけでなくスマートフォンアプリや別のシステムから利用することも可能になる。
2000年代に入ると、Webは企業や組織が情報を一方向に公開する媒体から、利用者自身が情報を生成、編集、共有するプラットフォームへと発展した。ブログ、SNS、動画共有サービス、オンライン地図、Wikiなどがその代表例である。
この変化を表す言葉としてWeb 2.0が広く使われた。Web 2.0は特定の単一技術を意味するものではなく、ユーザー参加、ネットワーク効果、Webサービス、リッチなユーザーインターフェースなどを特徴とするWebの発展段階を表す概念として用いられた。
技術的には、JavaScriptによるクライアント側処理と、HTTPによる非同期通信が重要な役割を果たした。これによって、ページ全体を再読み込みすることなく、必要なデータだけをサーバーから取得して画面を更新できるようになった。
Ajax（Asynchronous JavaScript and XML）は、JavaScriptからHTTP通信を行い、取得したデータを利用してWebページの一部を動的に更新する方式を指す。名称にはXMLが含まれているが、実際にはXMLだけが使用されるわけではなく、後にはJSONが広く利用されるようになった。
Ajaxによって、検索結果、コメント、地図、メール一覧などをページ全体の再読み込みなしに更新できるようになった。これによってWebアプリケーションの操作性が大きく向上し、Webブラウザ上で高度なアプリケーションを構築するための基盤が形成された。
Webアプリケーションが高度化すると、HTMLページそのものではなく、データを他のプログラムへ提供する必要が生じた。そこでWeb APIが発展した。Web APIはHTTPなどのWeb技術を利用して、データや機能を外部のプログラムから利用できるようにするインターフェースである。
JSON（JavaScript Object Notation）は、Web APIで広く利用されるデータ形式となった。オブジェクトや配列などの構造を比較的簡潔に表現でき、JavaScriptとの親和性も高い。そのため、ブラウザとサーバーの間だけでなく、サーバー同士のデータ交換にも利用されるようになった。
Web APIの普及によって、Webブラウザ、スマートフォンアプリ、他のWebサービス、企業内システムなどがHTTPを共通の通信基盤として利用できるようになった。Webはこの段階で、人間が読む文書を配信する仕組みから、機械同士がデータや機能を利用するための分散システム基盤へと拡張された。
Web APIの代表的な設計思想の一つがREST（Representational State Transfer）である。RESTはHTTPそのものを定義するプロトコルではなく、ネットワーク上の分散システムを設計するためのアーキテクチャスタイルである。
RESTでは、システム内の対象をリソースとして捉え、それぞれをURIによって識別する。HTTPのメソッドを利用してリソースを取得、作成、更新、削除することで、Webが持つ既存の仕組みを利用したAPIを構築できる。
例えばユーザーを`/users/123`というリソースとして表現し、`GET`で取得し、`PUT`や`PATCH`で更新し、`DELETE`で削除するという設計が可能である。
RESTの普及によって、Webの基本的な原則であるURIによる識別、HTTPによる通信、ステートレスな要求処理などを、Webアプリケーション間の通信にまで適用できるようになった。
Webアプリケーションがさらに高度化すると、従来のようにユーザーの操作ごとにサーバーから新しいHTMLページ全体を取得する方式から、ブラウザ側でアプリケーションを継続的に実行する方式へと発展した。SPA（Single Page Application）はその代表例である。
SPAでは、最初にHTML、CSS、JavaScriptなどのアプリケーション本体をブラウザへ配信し、その後のデータ取得や画面更新をJavaScriptとWeb APIによって行う。これによって、ページ全体を再読み込みせずに画面を切り替えたり、サーバーから取得したデータだけを表示したりできる。
React、Vue、AngularなどのJavaScriptフレームワークやライブラリは、このようなクライアント側アプリケーションの開発を支える技術として普及した。一方で、JavaScriptのコード量やブラウザ側で実行する処理が増加すると、初期ロード時間やメモリ使用量などの問題も生じる。そのため、クライアントとサーバーのどちらに処理を配置するかがWebアーキテクチャ上の重要な設計事項となった。
SPAの普及によってクライアント側処理が増加する一方、HTMLをサーバー側で生成するSSR（Server-Side Rendering）も重要な方式として発展した。SSRでは、サーバーが要求されたページのHTMLを生成してブラウザへ返すため、ブラウザが大量のJavaScriptを実行する前に主要なコンテンツを表示できる。
さらに、静的サイト生成、SSR、クライアントサイドレンダリングを組み合わせるハイブリッド構成も発展した。ページの性質に応じて、あらかじめHTMLを生成する部分、リクエスト時にサーバーで生成する部分、ブラウザ上で動的に生成する部分を使い分けることができる。
この発展によって、現代のWebでは「ブラウザ対Webサーバー」という単純な二層構造ではなく、クライアント、エッジ、Webサーバー、アプリケーションサーバー、データベースなどの各層に処理を分散させることが一般的になっている。
Webが社会基盤として普及すると、通信内容の盗聴や改ざん、通信相手のなりすましなどへの対策が不可欠になった。HTTPSはHTTPをTLS（Transport Layer Security）によって保護した通信方式である。
TLSでは、証明書などを利用して通信相手を認証し、暗号技術によって通信内容を保護する。これによって、ネットワーク上の第三者が通信内容を容易に読み取ったり改ざんしたりすることを防ぐ。
Webアプリケーションそのものにもセキュリティ対策が必要である。SQLインジェクション、クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）などに対して、入力値の検証、出力の適切なエスケープ、認証、認可、セッション管理、アクセス制御などを適切に実装する必要がある。
したがってWebセキュリティはHTTPSだけによって実現されるものではなく、通信、ブラウザ、Webサーバー、アプリケーション、データベースなどシステム全体を対象とする設計上の問題である。
Webサービスの利用者が増加すると、同じ情報を何度もサーバーから取得することによる通信量とサーバー負荷が問題になる。そこで重要になるのがキャッシュである。
キャッシュでは、一度取得した情報を一定期間保存し、同じ情報に対する要求が発生した場合に保存済みのデータを利用する。これによってネットワーク通信を削減し、応答時間を短縮し、オリジンサーバーの負荷を低減できる。
HTTPには`Cache-Control`、`ETag`、`Last-Modified`などのキャッシュ制御機構が用意されている。キャッシュはWebブラウザだけでなく、プロキシ、CDN、アプリケーションサーバー、データベースなどさまざまな場所で利用される。
Webサービスの利用者が世界各地に分散すると、一つのデータセンターからすべてのコンテンツを配信する構成では、利用者との物理的な距離による遅延やネットワーク負荷が問題になる。そこでCDN（Content Delivery Network）が利用される。
CDNは、世界各地に配置された多数のエッジサーバーを利用してコンテンツを配信する。利用者に近いエッジサーバーからキャッシュされたコンテンツを返すことで、通信遅延を低減し、オリジンサーバーへのアクセスを減らすことができる。
大規模なWebサービスでは、DNS、CDN、ロードバランサー、Webサーバー、アプリケーションサーバーなどを組み合わせることで、世界規模のアクセスを処理する。
Webサービスへのアクセスが増加した場合、一台のサーバーだけで処理することには限界がある。サーバーそのものの性能を高める垂直スケーリングだけでなく、複数のサーバーを並列に配置する水平スケーリングが利用される。
ロードバランサーは、クライアントからのリクエストを複数のサーバーへ振り分ける。ラウンドロビン、最小接続数、負荷状況など、さまざまな方式によって振り分けることができる。
水平スケーリングでは、どのサーバーが要求を処理しても同じサービスを提供できるようにする必要がある。特定のサーバーだけがセッション状態を保持する構成では、リクエストの振り分けが制約されるため、セッション情報を共有ストレージや分散キャッシュに保存する方式などが利用される。
このように、スケーラビリティの問題は単純にサーバーの台数を増やす問題ではなく、状態、データ、通信、障害などをどのように分散させるかというアーキテクチャの問題である。
Webサービスが大規模化すると、一つの巨大なアプリケーションとして構築するモノリシックアーキテクチャでは、開発やデプロイ、運用が複雑になる場合がある。そこで、システムを複数の独立したサービスに分割するマイクロサービスアーキテクチャが発展した。
例えば、ユーザー管理、商品管理、注文処理、決済、検索などをそれぞれ独立したサービスとして構築し、APIやメッセージングによって連携させることができる。それぞれのサービスを独立して開発、デプロイ、スケールできることが大きな特徴である。
一方、サービスを分割すると、サービス間通信、ネットワーク障害、データ整合性、分散トランザクション、監視、ログ管理、障害の連鎖など、新たな問題が発生する。そのためマイクロサービスは単純にモノリシックアーキテクチャより優れた方式ではなく、システムの規模や要件に応じて採用する分散システムの設計方式である。
クラウドコンピューティングの普及はWebアーキテクチャを大きく変化させた。従来のWebサービスでは、企業が物理サーバーを購入し、データセンターに設置して、ネットワーク、ストレージ、データベースなどを自ら管理する必要があった。
クラウドでは、計算資源、ストレージ、データベース、ネットワークなどをサービスとして利用できる。Webアプリケーションは仮想マシン、コンテナ、マネージドデータベース、オブジェクトストレージ、CDN、ロードバランサーなどを組み合わせて構築できる。
クラウドの重要な特徴の一つが、必要な計算資源を動的に増減できることである。アクセス数の増加に応じてサーバーを増やし、アクセス数が減少すれば減らすという構成が可能になる。この性質は、Webサービスの水平スケーリングと非常に相性がよい。
Webアプリケーションを多数のサーバー上で効率的に実行するため、コンテナ技術が広く利用されるようになった。コンテナはアプリケーションとその実行環境をまとめて扱う仕組みであり、異なる環境でも同じアプリケーションを実行しやすくする。
さらに、多数のコンテナを管理するためのオーケストレーション基盤が発展した。Kubernetesはその代表例であり、コンテナの配置、サービスディスカバリ、負荷分散、障害時の再配置、スケーリングなどを自動化できる。
これによってWebアプリケーションは、単一のサーバー上で動作するプログラムから、多数の計算ノードに分散配置され、必要に応じて自動的に増減するサービスへと発展した。
クラウドコンピューティングの発展に伴い、利用者が仮想マシンやコンテナを直接管理せずにアプリケーション処理を実行するサーバーレスコンピューティングも普及した。
サーバーレスでは、HTTPリクエストやデータベースへの変更、メッセージの到着などをイベントとして処理を実行する。処理が必要なときに計算資源を割り当てることができるため、アクセス量が変動するWebサービスに適した構成を実現できる。
ただし、実行時間、状態管理、コールドスタート、実行環境への依存などの制約も存在するため、すべてのWebアプリケーションに適しているわけではない。サーバーレスもWebアーキテクチャを構成する一つの選択肢として位置付けられる。
HTTPの基本モデルはクライアントが要求を送り、サーバーが応答する要求・応答型の通信である。しかしチャット、オンラインゲーム、リアルタイム監視などでは、サーバー側で発生したイベントをクライアントへ即座に通知する必要がある。
WebSocketは、このような双方向通信を実現するためのWeb技術である。HTTPを利用して接続を確立した後、クライアントとサーバーの間に持続的な通信路を確立し、双方がデータを送信できる。
これによってWebブラウザを利用したチャット、オンラインゲーム、リアルタイム監視、金融情報表示など、継続的に状態が変化するアプリケーションを構築できるようになった。
クラウドでは処理を中央のデータセンターへ集約することが多いが、利用者と処理拠点との距離が大きくなると通信遅延が発生する。そこで、利用者に近い場所に処理を配置するエッジコンピューティングが発展した。
CDNのエッジサーバーでは、静的コンテンツのキャッシュだけでなく、リクエストの変換、アクセス制御、認証、簡単なアプリケーション処理などを実行できる場合がある。
エッジコンピューティングでは、処理を必ず中央のサーバーへ送るのではなく、処理内容やデータの性質に応じて、クライアントに近い場所、ネットワークのエッジ、中央のクラウドなどへ配置する。これはWebアーキテクチャの分散化をさらに進めるものである。
JavaScriptはWebブラウザにおける主要なプログラミング言語として発展したが、計算量の大きい処理や既存のネイティブプログラムをWebへ移植する用途では、別の実行形式も必要になった。そこでWebAssembly（Wasm）が登場した。
WebAssemblyはWebブラウザなどで実行できる低レベルのバイナリ形式であり、C、C++、Rustなどの言語からコンパイルできる。JavaScriptと組み合わせることで、画像処理、音声処理、ゲーム、科学技術計算などの処理をWeb環境で実行できる。
これによってWebブラウザはHTMLを表示し、JavaScriptを実行するだけの環境ではなく、複数のプログラミング言語から生成されたコードを実行できる汎用的なアプリケーション実行環境へと拡張された。
現代のWebアーキテクチャは、初期Webの「ブラウザがサーバーからHTMLを取得する」という単純な構造から大きく発展している。大規模なWebサービスでは、利用者の端末からDNS、CDN、ロードバランサー、Webサーバー、APIゲートウェイ、アプリケーションサービス、キャッシュ、データベース、メッセージング基盤、オブジェクトストレージなど、多数の構成要素を経由して処理が行われる。
さらに、処理が一か所に集中しているとは限らない。ブラウザではJavaScriptやWebAssemblyが実行され、CDNではキャッシュやリクエスト処理が行われ、エッジでは利用者に近い場所で処理が行われ、クラウド上ではアプリケーションロジックが実行される。データベースやオブジェクトストレージは永続的なデータを保持し、メッセージング基盤はサービス間の非同期通信を担う。
このように、現代のWebは多数のコンポーネントがネットワークを介して連携する分散システムとなっている。
Webアーキテクチャの発展は、Webそのものの発展であると同時に、分散システムの発展でもある。初期のWebでは、異なる場所にある文書をURIとハイパーリンクによって相互に接続することが中心であった。その後、サーバーとデータベースが分離され、複数のサーバーがロードバランサーによって並列化され、さらにサービスそのものが複数のマイクロサービスへ分割されるようになった。
分散化が進むにつれて、可用性、スケーラビリティ、障害耐性、データ整合性、通信遅延などが重要な設計問題となった。ネットワークを介した通信では、サーバー障害、通信遅延、タイムアウト、パケット損失、サービス間通信の失敗などが発生する可能性があるため、タイムアウト、リトライ、冗長化、キャッシュ、負荷分散などを組み合わせる必要がある。
したがってWebアーキテクチャを理解することは、単にWebページの作り方を理解することではない。ネットワーク上に分散した計算資源とデータをどのように組み合わせ、一つのサービスとして利用者に提供するかを理解することである。
Webアーキテクチャの設計では、第一に情報資源をどのように識別するか、第二にそれらをどのようなプロトコルで取得・操作するか、第三に処理をクライアントとサーバーのどこに配置するか、第四にデータをどこに保持するか、第五に負荷や障害にどのように対応するかを考える必要がある。
小規模なWebサイトであれば、一台のWebサーバーがHTMLや画像を配信する構成でも十分な場合がある。しかし利用者が増加すると、キャッシュ、CDN、ロードバランサー、複数のアプリケーションサーバー、データベースなどを導入する必要が生じる。さらに大規模化すると、サービス分割、コンテナ、オーケストレーション、メッセージング、分散データベースなどが必要になる場合がある。
このようにWebアーキテクチャには単一の完成形が存在するわけではない。要求される性能、可用性、セキュリティ、データ量、利用者数、開発体制などに応じて、適切な構成を選択することが重要である。
Webは、1989年に提案された分散ハイパーテキストシステムから始まり、1990年代のWebブラウザの普及、HTMLとHTTPの標準化、動的Webとデータベースの結合、JavaScriptとAjaxによるインタラクティブ化、Web APIとRESTによるシステム間連携、SPAによるクライアント側アプリケーション化、CDNとクラウドによる大規模配信、コンテナやマイクロサービスによる分散化、エッジコンピューティングやWebAssemblyによる実行環境の拡張へと発展してきた。
この歴史において一貫しているのは、ネットワーク上に分散した情報資源や計算資源を、標準化された識別方式と通信方式によって相互接続するという考え方である。初期のWebではその対象が主として文書であったが、現在ではデータ、API、アプリケーション、サービス、計算処理そのものへと拡大している。
したがってWebアーキテクチャは、HTMLやHTTPだけを扱う技術領域ではない。URIによる情報資源の識別、DNSによる名前解決、HTTPによる通信、HTML・CSS・JavaScriptによるクライアント側処理、Webサーバーとアプリケーションサーバーによる処理、データベースによる永続化、キャッシュとCDNによる高速な配信、ロードバランサーによる負荷分散、APIによるシステム間連携、クラウドとコンテナによる大規模な実行基盤、エッジによる処理の分散などを、一つの体系として捉える概念である。
Webは当初、分散した文書を相互に参照するための仕組みであった。しかし、オープンな標準技術と分散型の構造を基盤として発展した結果、現在では検索、電子商取引、SNS、動画配信、金融、企業システム、クラウドサービス、オンラインアプリケーションなど、極めて広範なサービスを支える世界規模の分散システム基盤となっている。
Mathematics is the language with which God has written the universe.