集中から3層アーキテクチャとAPIまで

購入ボタンを押した一瞬の裏側

スマホのネットショッピングで、購入ボタンをタップした瞬間を思い出してください。1秒もたたないうちに「注文が完了しました」の画面に切り替わります。動画は、この一瞬の裏側では「誰がどの処理を担当するのか」という緻密な役割分担が、ものすごいスピードで働いている、という話から始まります。

システムの処理方法は、大きく2つのアプローチに分けられます。

• 集中処理：1つのコンピューターに処理を集中させる。
• 分散処理：複数のコンピューターに処理を分散させる。

この回は、この2つの違いから出発して、クライアントサーバシステム（2層・3層）を経て、最後にWeb APIという窓口にたどり着く流れです。IPA（情報処理推進機構）の試験シラバスでも、集中処理と分散処理、クライアントサーバシステムは基本の項目として並んでいます。

集中処理：巨大な頭脳にまかせる

集中処理は、ホストコンピューター（またはメインフレーム）と呼ばれる大型のコンピューターが、すべての処理を行う構成です。そこに複数の端末が接続され、端末は基本的に処理をしません。動画の言い方では、巨大な頭脳が1つドーンとあって、手足の端末がたくさんくっついているイメージです。

全部を1つに任せるのは危うい気もしますが、動画はまず、はっきりしたメリットを挙げます。

動画が挙げるデメリットは3つです。開発が大規模になるため初期費用が高いこと、ホストが故障すると接続しているすべてのコンピューターが使えなくなる致命的な弱点があること、そして後から大きくしにくい拡張性の低さです。容量が足りないからといって、何億円もする巨大なコンピューターをポンポン買い足すわけにはいかない、と聞き手も納得していました。

（補足：ホストコンピューターは、メインフレーム・汎用機とも呼ばれる大型コンピューターを指す言い方です。Wikipediaによると、もともとは端末の対比語、現在は分散システムの対比語として使われる語で、確認できたのは二次資料です。）

分散処理：手分けして働く

「1台が壊れると全部止まる」という弱点を克服するために生まれたのが、分散処理だと動画は説明します。複数のコンピューターで分散して処理を行う方法です。

最大のメリットは、1台が故障しても影響が限定的なことです。これがリスクの分散です。必要に応じてコンピューターを増やせるので、拡張性が高い点もメリットです。

いいことずくめに見えますが、集中処理のメリットだった部分はどうなるのでしょうか。聞き手が鋭く突っ込みます。

観点	集中処理	分散処理
データの一貫性	保ちやすい	保つのが難しい
システム管理	一元化できる	分散される
故障したとき	全体が停止	影響は限定的
拡張性	低い	高い
初期費用	高い	動画では触れず

分散処理の2つの配置：水平分散と垂直機能分散

動画によると、分散処理には、コンピューターの配置の仕方で2つのアプローチがあります。

• 水平分散システム：複数のコンピューターが対等な立場にある。
• 垂直機能分散システム：サービスを提供する側と、サービスを受ける側が分かれている。

私たちが普段使っているアプリは、まさに垂直機能分散にあてはまりそうだ、と聞き手は言います。その代表例がクライアントサーバシステムで、コンピューターをサーバとクライアントに分けて役割分担する仕組みです。サービスを提供する側がサーバ、私たちが使う端末側がクライアントです。

（補足：水平分散・垂直機能分散という呼び方と分け方は、動画の整理です。公的資料での定義は確認できていません。ちなみにIPAのITパスポート試験シラバスでは、クライアントサーバシステムは「分散処理方式の一つ」と位置づけられています。）

2層アーキテクチャ：端末が頑張る「ファットクライアント」

クライアントサーバシステムの構成には、さらに2層アーキテクチャと3層アーキテクチャがあります。層は「レイヤー」のことです。

2層アーキテクチャは、処理をクライアントとサーバの2層に分けて行う構成です。シンプルに2つに分けるのですが、主にクライアント側で処理を行うため、端末に負担がかかるという特徴があります。ユーザーの端末が頑張って計算するので、負担が大きいわけです。

クライアント側の処理が重くなることから、これをファットクライアントと呼ぶ場合もあります。ファットは「太った」という意味で、いろいろ詰め込んで重くなったクライアントのイメージです。聞き手は「自分のスマホが太って負担がかかっていると考えると、ちょっと嫌ですね」と笑っていました。

3層アーキテクチャ：役割を3つに分ける

端末の負担を減らすために進化したのが、3層アーキテクチャです。処理をデータベース層・ファンクション層・プレゼンテーション層の3層に分けて行います。

3層に分けると何がうれしいのか。動画はそのメリットを、次のように説明します。

• 各層の開発を並行して行える：画面の見え方を作るチーム、裏の計算をするチーム、データを管理するチームが、お互い邪魔せず同時に進められる。
• 各層が独立しているため保守性が高い：一部を直したいときも、他の層に影響が出にくい。
• クライアント側の処理が軽い：2層のファットクライアントに対して、こちらはシンクライアントと呼ばれる。

シンは「痩せた」というニュアンスで、ファットとの対比が覚えやすい、と動画は紹介しています。

層	動画の説明	例
プレゼンテーション層	画面の見え方を作る	Webブラウザ
ファンクション層	裏側の計算（処理）	アプリケーションサーバ
データベース層	データを管理する	データベースサーバ

（補足：動画は3層の軽いクライアントを「シンクライアント」と呼んでいますが、シンクライアントという言葉は、端末側の処理を必要最小限にして、ほとんどの処理をサーバ側に集める方式全般を指すのが一般的です。Wikipediaでは、端末はこれまでのPCのまま、サーバ側に処理を集約する方式も広い意味に含めています（二次資料）。IPAのシラバスにも「シンクライアントシステム」の語があります。3層構成と同じ意味だと決めつけず、「クライアント側が軽い」という共通点でつかんでおくのが安全です。）

Web API：クライアントとサーバをつなぐ窓口

クライアントとサーバがきれいに役割分担できたとして、物理的に離れたシステム同士は、具体的にどうやってやり取りするのでしょうか。そこで登場するのがWeb APIです。動画は、クライアントとサーバの間をつなぐインターフェース、つまり窓口だと説明します。システム同士が会話するための、お問い合わせ窓口のようなものです。

つまり、アプリのボタンを押した瞬間にWeb APIという窓口へリクエストが飛び、サーバが処理して、JSONなどの形式で結果が返り、画面に次の表示が出る。動画は、これが全部一瞬で行われていると話します。

（補足：動画は「Web APIがサーバに指示を出す」と説明しますが、窓口とサーバを別の登場人物として描いたのは、役割をつかみやすくするための簡略化と考えられます。実際には、Webサービスの入口としてサーバ側が用意している仕組みです。Wikipediaでも、Web APIはWebサービスとほぼ同義語とされています（二次資料）。）

（補足：JSONはIETFの標準RFC 8259（2017年12月）で、軽量でテキストベース、言語に依存しないデータ交換形式と説明されています。XMLはW3C勧告のXML 1.0（Fifth Edition、2008年11月26日）です。どちらもIPAのITパスポート試験シラバスVer.6.5に用語として載っています。）

まとめ：システムの進化の歴史

動画は最後に、ここまでを「システムの進化の歴史」としてまとめます。巨大な1つの頭脳に頼る集中処理から始まり、役割を分担する分散処理へ。さらに、2層のファットクライアントから、3層のシンクライアントへと細分化されていきました。そして、それらをWeb APIという窓口がスマートに結んでいます。

• 集中処理：ホストが全処理を行う。データの一貫性と管理の一元化が長所。初期費用が高く、故障で全停止し、拡張性が低い。
• 分散処理：複数台で処理する。故障の影響が限定的で拡張性が高いが、データの一貫性を保つのが難しい。
• 水平分散と垂直機能分散：対等な関係か、提供側と受ける側に分かれるか。クライアントサーバシステムは後者の代表例。
• 2層と3層：2層はクライアントが重いファットクライアント。3層は3つの層に分け、各層の並行開発と保守性の高さ、軽いクライアントが長所。
• Web API：クライアントとサーバをつなぐ窓口。結果はJSONやXMLなどの形式で返る。

次にアプリのボタンをタップするとき、見えない裏側でWeb APIが走り、JSONやXMLの形式でサーバと絶え間なくやり取りしている風景を、少しだけ想像してみてください。