051.2 レッスン 1

オンラインシステムを使っていると、処理中のサンプル画面のような「処理中」というメッセージを目にすることがあります。

この画面を目にする少し前に時間を巻き戻してみましょう。銀行のWebサイトから銀行口座にアクセスしようとしていました。ノートパソコンで銀行のWebサイトにアクセスするときには、Google ChromeやFirefoxといったWebブラウザと呼ばれるソフトウェア（アプリケーション）を使います。そのノートパソコンのブラウザが、Webサイトをホストしている別のコンピュータにリクエストを送ります。Webサイトをホストしているコンピュータを サーバー と呼びます。サーバーは、24時間365日稼働するよう設計されており、絶えず世界中から送られるリクエストに対応します。

サーバーは、仕事やゲームやプログラミング演習に使うコンピュータと同じようなコンピュータなのですが、一つ大きな違いがあります。サーバーは、通常、そこで稼働させている特定のソフトウェア（アプリケーション）にリソースを集中させます。先ほどの例では、サーバーで稼働しているのはWebアプリケーションと呼ばれるソフトウェア（後述）であり、それにリソースを集中させます。

「処理中のサンプル画面」では、サーバーがブラウザからのリクエストを受け取り、サーバーで稼働しているアプリケーションが処理を行っています。銀行顧客の詳細情報をデータベースに問い合わせたり、次の借入れに適用できる優遇措置を確認するために別のサーバーと通信したりする処理です。

この例では、ノートパソコンで動いているブラウザを クライアント（クライアントアプリケーション） と呼びます。クライアントはリモートサーバーとやり取りします。

クライアントとサーバーとの間の通信は、企業ネットワーク内で完結するかもしれませんし、インターネットを経由するかもしれません。クライアント／サーバー間通信の一般的な特徴として、一つのサーバーが多数のクライアントと同時に通信するということが挙げられます。先の例で言うと、銀行のWebサイトをホストする1台のサーバーが、各地のユーザーが自分の銀行口座にアクセスする数千ものリクエストを同時にさばくということです。

上記の銀行の例では、ほぼすべての処理をサーバーが行っていますが、クライアントが主に処理を行うケースもあります。クライアント自体が大部分の処理を行うアプローチを、ファットクライアント（fat client） あるいは シッククライアント（thick client） と呼びます。先ほどの銀行の例のように、クライアント（ブラウザ）からのリクエストをサーバーが処理し、結果をブラウザが表示するアプローチを、シンクライアント（thin client） と呼びます。

ビデオゲームはファットクライアントの代表例です。ローカルマシンが、自らのCPU、RAM、GPU、ストレージを利用し、大部分のデータ処理を行います。特にオフラインでゲームをプレイするときは、外部のサーバーに頼るということはありません。

どちらのアプローチにも長所と短所があります。シッククライアントは、リモートサーバーに頼るシンクライアントと比べると、ネットワークが不安定でも問題になることが少ないですが、ソフトウェアに更新を適用するのが難しく、より多くのコンピュータリソースを必要とします。シンクライアントには、リソースをあまり必要とせず低コストですむ利点があります。

Webアプリケーション とは、サーバーで動作し、ネットワークを通じてアクセスしたユーザーと対話しながら処理を進めるソフトウェアです。ファットクライアントのこともあればシンクライアントのこともあります。すべてのWebサイトがWebアプリケーションであるとは限りません。ユーザーと対話しながら処理を進めることがない静的なWebページは、Webアプリケーションではありません。サーバーは、要求に応答する処理を行うアプリケーションプログラムを実行していないからです。

Webアプリケーションは大きく2つに分けられます。SPA（Single Page Application / シングルページアプリケーション） と MPA（Multi-Page Application / マルチページアプリケーション） です。SPAは、Webページが一つしかなく、再読込やリダイレクトなしにデータをやり取りして新しい内容を読み込みます。MPAは、Webページが複数あり、データのやり取りには再読込やリダイレクトを伴います。

銀行のサイトにアクセスして自分の口座の取引履歴を確認するという、先ほどの例で考えてみましょう。銀行のサイトが読み込まれたところから話を始めます。この銀行のサイト（Webアプリケーション）がSPAであれば、取引履歴が再読込やリダイレクトなしに表示されます。自分の借入状況を確認するとしても、新しいページにリダイレクトされるのではなく、同じページの一部に新しい情報が表示されます。リダイレクトがないので動線がスムーズです。

MPAであれば、自分の借入状況を確認するときに、別のページにリダイレクトされます。

SPAの代表例はGmail（Google Mail）です。例えば、迷惑メールフォルダを表示しようとしたら、新しいページにリダイレクトされるのではなく、同じページにとどまったまま、表示の一部が更新されて迷惑メールフォルダが表示されます。

MPAの代表例は、Eコマースの大手であるAmazon.comです。各商品が別々のページに表示されます。

MPAがSPAに勝っている点は、アクセスを集計して分析しやすいという点です。サイト管理者が検索エンジンの結果を最適化するためには、この点が決定的に重要です。

通常、Webアプリケーションは、フロントエンド と バックエンド に分けられます。フロントエンドはブラウザへの表示をつかさどる部分で、見た目とユーザーによる操作（クリック、選択、キー入力など）を担当します。

Webアプリケーションの大部分は、一般的にバックエンドが担当します。ビジネスロジックを実装し、ユーザーの要求に応じた処理を行い、データを加工して保存します。データの保存には、サーバーに接続したデータベース管理システムを用いるのが普通です。

フロントエンドとバックエンドは相互にやり取りします。リクエストはフロントエンドからバックエンドへと送られ、バックエンドが生成して返したレスポンスはフロントエンドで整形されてユーザーに表示されます。

銀行口座の取引履歴を取得するという例を見ていきましょう。ブラウザで実行されるフロントエンドが、ユーザーのアクションを解釈します。次に、インターネットを通じてリクエストがアプリケーションのバックエンドへと送られ、バックエンドではユーザーがそのアクション（この例では取引履歴の取得）を実行可能かどうか検証します。実行可能であれば、取引履歴をブラウザのフロントエンドに返し、ブラウザがその取引履歴を整形してユーザーに表示します。

およそどのようなソフトウェアも、内部的ないし外部的に別のコンポーネントやプログラムと通信を行います。Webアプリケーションで、クライアントはどのように通信するのでしょうか。フロントエンドはどのようにデータをバックエンドに送るのでしょうか。

ソフトウェア（アプリケーション）は、基本的なインターネットプロトコルを利用して動作する API（Application Programming Interface / アプリケーションプログラミングインターフェイス） を通じて相互にやり取りします。プロトコルとは、複数のアプリケーションが命令やデータをやり取りできるように定められた規格や規則のことです。

APIを用いると、アプリケーションを機能ごとに分離して、それらを協働させてデータを処理できるという大きな利点があります。すべての人が行き来する際に通らなければならない門のように、データの流れを事前に定められた経路に集約するという利点もあります。Webアプリケーションが機能するためには、APIが非常に重要です。ユーザーとやり取りして、情報を加工して配信し、データを保存する、といった諸々の動作はAPIを通じて行われます。サーバーがそうしたAPIを用意して、クライアントはAPIを通してサーバーにリクエストを送ります。

先ほどの銀行の例に戻りましょう。Webアプリケーションでログインするために、ユーザー名とパスワードを入力して「ログイン」ボタンを押します。ブラウザはこの情報を取得し、バックエンドのAPIを呼び出します。リモートサーバーで動いているWebアプリケーションがそのデータを受け取り、ユーザーの検証を行い、ユーザーがアクセス可能かどうかを確かめ、最終的にレスポンスをブラウザに返します。ユーザーがサーバーとやり取りするには、クライアントとサーバーがデータを送り合います。これを可能にするのがAPIです。

この銀行のWebアプリケーションでは、必要最小限のデータしかやり取りせず、他の機密情報は含まないことに着目してください。

APIによる通信にはさまざまなプロトコルを使えますが、ほとんどの場合は HTTP（HyperText Transfer Protocol / ハイパーテキスト･トランスファー･プロトコル） を使います。ハイパーテキスト とは、ほかのテキストやページへのリンクを含むテキストのことで、Webページを記述するHTMLの基礎となる概念です。

HTTPは非常にシンプルなプロトコルで、所定の書式でクライアントがサーバーに1つのリクエストを送り、サーバーは1つのレスポンスを同じ通信チャンネル経由でクライアントに返送します。1回のやり取りは、クライアントとサーバーの間を1往復して終わることがポイントです。

構造化されたWebアプリケーションでは、ソフトウェアエンジニアが部品（モジュールやコンポーネント）を組み合わせてアプリケーションを構築します。そうすることによって、部品それぞれのタスク（機能）と責任が明確になり、開発と保守が容易になります。

2つのモジュールから構築されたアプリケーションの例を考えてみましょう。1つのモジュールが自社のビジネスロジックを実装し、もう1つのモジュールが外部のサービスとのやり取りを制御しているとします。ここで利用している外部のサービスは、APIを通じて提供される天気予報だとしましょう。この外部のサーバーがダウンし、天気予報を取得できなくなりました。天気予報のデータが自社のサービスに欠かせないとしたら、自社のユーザーを困惑させてしまいかねません。

そこで、このダウンした天気予報サービスから、同じ天気予報APIを提供している別のサービスに切り替えます。モジュールが分離していますから、1つのモジュールを更新するだけですみます。もう1つのモジュールの自社のビジネスロジックには手を加える必要はないでしょうし、手を加える必要があるとしても最小限の変更ですみます。

タスク（機能）と責任を明確にするモジュール構造は、使いやすいAPIの設計にも影響を与えます。データのやり取りを行うアプリケーションの設計ガイドラインである REST（REpresentational State Transfer） という概念が、使いやすいAPIのアーキテクチャとして広く受け入れられています。

RESTには6つの原則がありますが、このレッスンではそのうちで重要な3つの原則を取り上げます。

REST原則に従うAPIは RESTful （レストフル）であると言われます。現代のWebアプリケーションの多くはREST原則に従っています。RESTfulなAPIがHTTPを用いることは必須ではありませんが、シンプルかつ堅牢で、Web環境では普遍的に利用できるため、主にHTTPが使用されています。

Webアプリケーションの構造を体系化しようとするアーキテクチャやモデルが乱立しており、それぞれのアーキテクチャやモデルの長所と短所が議論されています。従来の モノシリックアーキテクチャ に対置される、マイクロサービスアーキテクチャ は重要なパラダイムです。

独立した複数の相互に依存する サービス を組み合わせて最終的なアプリケーションを組み立てるソフトウェアモデルを、マイクロサービスアーキテクチャと呼びます。このアーキテクチャでは、プログラムコードを単機能化した小さなソフトウェアコンポーネントに分権化することを目指します。すなわち、ソフトウェアのレイヤーを整理して、それぞれのレイヤーを複数の小さなアプリケーションに分割することで、維持管理を行いやすくします。（マイクロサービスアーキテクチャの概念図）

マイクロサービスアーキテクチャと対照をなすモノリシックアーキテクチャでは、最終的なアプリケーションに必要なサービスやリソースを、すべて一つのアプリケーションに閉じ込めます。（モノリシックアーキテクチャの概念図）

「マイクロサービスアーキテクチャの概念図」が示すように、マイクロサービスモデルではサービス（機能）ごとにソフトウェアコンポーネントが分権化されており、アプリケーションは複数のサービスを組み合わせて利用します。それぞれのサービスが、独自のソフトウェアコンポーネント、データベース、サーバーのリソースなどを管理します。「マイクロ」という名前からわかるように、それぞれのマイクロサービスは、すべてのサービスを一箇所で扱うモノリシックアーキテクチャよりもかなり小さくなります。

モノリシックアプリケーションでは、すべてのリソースを一箇所にまとめます。ビジネスロジック、データ、プログラムコードをすべて集権化して一つの大きな塊を作るので、モノリシック（一枚岩）と呼ばれます。

Webアプリケーションがモノリシックモデルなのかマイクロサービスモデルなのか、ユーザーからはほとんどわかりません。先ほどから例に挙げている銀行のWebアプリケーションを、支払い、取引、借入れなどすべてのビジネスロジックを一つのプログラムで扱うモノリシックモデルで作ることもできれば、マイクロサービスモデルで作ることもできます。マイクロサービスモデルでは、支払いサービスや借入れサービス、さらには債務不履行の可能性を分析するサービスなどがあるかもしれません。銀行のWebアプリケーションでしたら、数千のサービスが存在してもおかしくありません。

モノリシックなアプローチでは、特に複数のチームが同じコードに対して作業を行う場合には、アプリケーションが大きくなるにつれて、維持管理の負荷が大きくなります。集権化されたソフトウェアでは、あるチームの変更が別のチームの担当箇所に影響を及ぼすことがよくあります。大規模なチームでは、これが本当に悩ましい問題です。

マイクロサービスでは一つのサービスを一つのチームが管理しますから、その点ではるかに柔軟です。コードの変更を簡単に行うことができ、競合が問題になることは本質的にありません。一つのチームが複数のサービスを管理しても差し支えありません。マイクロサービスにも短所はあります。各サービスが相互に結びついていますから、どこか一つのサービスで障害が発生すると、それがアプリケーション全体に波及する可能性があります。データベースインスタンス、サーバー、相互に通信する外部APIが複数存在するため、アプリケーション全体の耐障害性（レジリエンス）は、最も弱いサービスが決定づけることになります。

モノリシックなアプローチでは、データベースも集権化されているので、データの重複が発生しにくいという利点があります。また、多数の小さなサーバーを用意するよりも一つの大きなサーバーを用意するほうが必要なリソースが少なくてすむので、リソースの消費を抑えられるという長所もあります。同じくらいの規模のアプリケーションであれば、マイクロサービスのほうがリソースの負担は大きくなります。