Web Application & Software Architecture 101 ~②Web Architectureとは？~

ServerSide アーキテクチャ Web

educativeのWeb Application & Software Architecture 101という講座を受けたのでその内容についてまとめです．これは現在のWebアプリケーションがどのような設計で成り立っているかを概念レベル（コードレベルではない）で説明されてい講座です．なのでWebアプリケーションの設計について学びはじめの方やWebアプリケーションの設計の全体像を知りたいという方にぴったりの講座です． 第2回目の今回は層によるWeb Architectureの概要とそこで使われるClient Server Architecture，Http ProtocolやWeb Architectureが採用するRESTと呼ばれるアーキテクチャスタイルについてまとめます．

前回にも述べましたが，Webアーキテクチャはユーザーインターフェース，バックエンドサーバー，データベース，キャッシュサーバーなど様々なコンポーネントから成り立っています．さらにそのアーキテクチャの構成を詳しく見ていくとClient -Server Architectureと呼ばれるアーキテクチャになっています．

Client-Server Architecture

Client-Server ArchitectureはWebアプリケーションのアーキテクチャの基本的な構造です．世の中のほとんどのWebアプリケーションはClient-Server型のアーキテクチャとなっています．

Client

Clientとはユーザーインターフェースを表示する部分を担う部分です．Client側はサーバー側にRequestを送ることでResponseを受け取ります．そのResponseの情報を元にJavascriptやHtml，CSSと呼ばれる言語を使ってClientはユーザーインターフェースを描画します．

f:id:harada-777:20200802195753p:plain:w300

ビジネスロジックがない薄いClientをThin Client，ビジネスロジックが含まれるClientをThick Clientと呼ぶそうです．

f:id:harada-777:20200802195749p:plain:w300

f:id:harada-777:20200802195744p:plain:w300

Server

ServerとはClientからRequestを受けとって必要な情報を返す部分です．全てのサービスはアプリケーションサーバーが起動している必要があります．アプリケーションサーバーとは，プログラムを実行させる場所のようなものです．JavaでWebサービスを作る場合はTomcatやJettyと呼ばれるアプリケーションサーバーの上に自分で書いたプログラムを動かすいイメージです． このServerがHtmlなどを使って画面の生成までする場合をServer-Side Renderingと呼び，Client側が画面を生成する場合Client-Side Renderingと呼びます．本講座の後半にそれぞれのメリットデメリットが詳しく述べられるのですが，ざっくり言うとServer-Side Renderingでは重たいHtmlの生成などをServer側に持ってこれるメリットがあり，Client-Side Renderingをすると，その分Server側がシンプルになり，Server側のバックエンドアプリケーションを複数のClientで使い回すことができます． 次節以降はClientとServerがどうのように通信するかについて見ていきます．

ClientとServerの通信方法

Http Protocol

ClientとServerはHttp Protocolと言うプロトコルに従って通信が行われます．Http ProtocolはRequest-Response型の通信プロトコルである，ステートレスであることが特徴です．ClientはいくつかのHttpメソッド（Get，Post，Put，Deleteなど）を使ってがServerにRequestを行うことでデータを取得したり作成したりします．

REST API

さらに最近のWeb アプリケーションはRESTと呼ばれるアーキテクチャスタイルを実装しています．アーキテクチャスタイルとは設計原則のようなものです．この設計原則をHTTP Protocolなどを使って実装したAPIがREST APIです．REST APIは以下のような特徴を持ちます． + Client-Server型である

  • ステートレスである

    • 1回1回の通信は独立している

  • リソースを操作する命令が予め定義され，共有されている

    • HTTPのGET，POST，PUT，DELETEメソッドなど

  • URIでリソースの場所を一意に識別できる

  • レスポンスとしてXMLもしくはJSONで操作結果を返す

このような原則を全てのWebアプリケーションが実装することで再利用性が高まります．例えば向いはクライアント毎（スマホ，PC）にサーバーのコードが別れていたそうですが，今ではビジネスロジック部分のバックエンドサーバーを使い回し，JSONでデータを受け取ってそれぞれのクライアントに合わせた画面が描写するといったことが可能になっています． 外部サービスにおいてもRESTを実装されていることが多いので，HTTPプロトコルで通信使，JSONを受け取るようにこちら側のAPIを作れば簡単に他のサービスの機能を扱うことができます．

f:id:harada-777:20200802195740p:plain:w300

HTTP Pull & Push

HTTP Protocolには実は2種類の通信方法があります．それがPull型とPush型です．それぞれ用途が違うので解説をしていきます．

Pull型

HTTP Pull型は必ず最初にClientからRequestがあるパターンの通信方法です．ほとんどの通信はこの方式でHTTPのデフォルトモードはPull型です． Pull型にも場合によって2種類あります． 1つ目が手動でボタンなどをクリックしてRequestを送信して，Responseを受け取る方法です． 2つ目が自動でデータの更新などによって動的に画面を描写するときに使用される方法です．これは自動でスポーツサイトやニュースサイトの画面が更新されるイメージです． この2つ目についてもう少し詳しく見ていきます．これをPull型で実現するにはAjaxと呼ばれる技術を使います． AjaxとはAsynchronous Java Script & XMLの略で，JavascriptとXMLを用いて非同期通信を実現する技術のことです．この技術が生まれる前まではRequestを送ってからResponseが返って来るまでプログラムは動かすことができませんでした．例を用いて説明すると，同期通信の場合Google Mapで拡大や縮小をするとき（このタイミング裏ではより詳しい情報を取得するためのRequestが送られる），プログラムが止まり．毎回画面が真っ白になって画面が見れないタイミングが発生するイメージです．現在Google Mapがこうなっていないのは非同期通信が行われているからです．非同期通信はRequestを送っている間も，プログラムは止まらず，ブラウザは通常通り操作でき，Responseが返ってきたタイミングで画面が描写されます． 2つ目のPull型での自動更新パターンはこのAjaxを使って一定の間隔でRequestを非同期で送り，Responseを受け取ったタイミングで画面を描写し直すといったことを行います．

f:id:harada-777:20200802195737p:plain:w300

ただこの方法には2つ問題があります．1つ目の問題が一定間隔後しかデータが更新されない，2つ目の問題はデータの更新がないのにRequestを送ってしまい無駄に通信が発生してしまいます．この2点を解消する，またよりリアルタイムでデータを取得する必要性が発生し，Push型の通信がいくつか生まれました．

Push型

ここからはPush型の方法をいくつか紹介します．

Ajax Long Polling

1つ目がAjax Long Pollingです．これは厳密にはPush型では擬似的にPush機構が実現できる為本講座ではPush型に分類されていました（おそらく．．）．この方法はまずClient側からRequestを送った後，データの更新があるまでコネクションを保ちます．（コネクションとは通信経路のようなものでそこが開いていないと通信ができません．この方法は意図的に長くこの経路を開きます，）そしてデータの更新があったタイミングでServer側からResponseを受けとり，画面を更新します．そしれResponseを受け取った時にまたClient側はRequestを送ります．

f:id:harada-777:20200802195733p:plain:w300

この方法を使うことでPull型のときよりデータ更新から画面の描画までのタイムラグをなくすことができ，またClientからのRequestする回数も減るので通信の削減にもなります．

Web Socket

Web Socketは双方向で通信が可能な技術です．TCPという層（HTTPより下位の層）での通信方法であり，低遅延でもあります．ざっくりとして流れは以下の通りです． f:id:harada-777:20200802200409p:plain:w300

まずClient側はハンドシェイクと呼ばれるHTTP通信を行い，その後サーバー側がハンドシェイクを受け取るとWebSocketへと切り替えTCP層の通信が始まります． 双方向かつ低遅延の通信ができるのでチャットアプリケーションやリアルタイムマルチプレイヤーゲームなどに使用されます．

HTML5 Event Source

次に紹介するのがHTML5 Event Sourceです．これはServer側からClient側への単一方向の通信方式です．ServerからEventという形でデータが送られてきます．Ajax Long PollingのようにClientからRequestを送る必要がなく，通信の削減ができます．またHTTPプロトコルを利用するのでWebSocketより気軽に導入できます． これはTwitterなどリアルタイムでタイムラインを更新したいSNSアプリケーションに使用されます．

Streaming Over HTTP

Streaming Over HTTPは容量の大きいファイルを分割してストリーミングすることができる技術です．ストリーミングがインターネット上でダウンロードせず動画や音声を視聴できる技術です．ざっくりとしたイメージは以下の通りです．

f:id:harada-777:20200802195729p:plain:w400

大きいサイズのメディアが分割されて運ばれて，Client側で再生されます．（この過程で様々なデータに変換されますが，まだ細かい部分は理解できておりません．．）

まとめ

僕自身はあまりPush型の通信方法を知らず知らないことが多い回でした．この回を受けたことで実装方法はわからなくても，作りたいものが出た時にどういう技術を調べればいいかという指針ができたのでよかったです．（全体像を知るのは大事ですね．．）