アーキテクチャとWebサービス

下から上へ、データが加工されながら流れていくという構造です。

④ 2層アーキテクチャ

2層アーキテクチャとは、アプリケーションソフトウェアがもつ機能をデータベース層／ファンクション層／プレゼンテーション層の3つに分割し、サーバ側にデータベース層を、クライアント側にファンクション層およびプレゼンテーション層の役割をもたせ、2層構造で連携処理するシステムを指します。

機能は3つに分かれているが、物理的な配置は2か所——だから「2層」です。

⑤ 2層アーキテクチャの問題点

2層アーキテクチャでは、クライアント側にファンクション層の役割をもたせるため、以下の問題点があります。

⑥ 2つの問題点の根っこは同じ

どちらも、クライアント側に処理の中身を置いていることから生じています。

クライアントが100台あれば、100台すべてに高性能なPCを用意し、100台すべてのプログラムを更新することになります。台数が増えるほど負担が膨らみます。

⑦ ファットクライアント

このように、稼働するアプリケーションソフトウェアが増え、保守が困難になったクライアントをファットクライアントとよびます。

fat は「太った」という意味です。機能を抱え込んで重くなったクライアント、というイメージです。

⑧ なぜ2層が使われたのか

一見すると欠点ばかりですが、登場した当時には理由がありました。

ネットワークが速くなり、台数が増えたことで、前提が崩れた——これが次のテーマで学ぶ3層アーキテクチャが主流になった背景です。

第5章で学んだAjaxや、第2章で学んだWebアプリケーションの広まりも、同じ流れの上にあります。

更新作業の現実

この負担が、3層アーキテクチャを生んだ

「サーバ側だけを更新すれば済む」——この一点だけでも、3層にする価値があります。

第2章の内容とつなげる

第2章の応用ソフトウェアの節で、「Webアプリケーションにすれば更新が1か所で済む」という利点を見ました。これはまさに、プレゼンテーション層だけをクライアントに残し、ファンクション層をサーバに移した結果です。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　プレゼンテーション層は、ユーザインタフェースを提供する層である。

> b　2層アーキテクチャでは、サーバ側にデータベース層とファンクション層を、クライアント側にプレゼンテーション層をもたせる。

> c　ファットクライアントとは、稼働するアプリケーションソフトウェアが増え、保守が困難になったクライアントである。

解答　a：○　b：×　c：○

• b：×……2層アーキテクチャでは、サーバ側にデータベース層を、クライアント側にファンクション層およびプレゼンテーション層をもたせます。ファンクション層がどちら側にあるかが、2層と3層を分ける決定的な違いです。

② 2層との違いは1点だけ

ファンクション層がどちら側にあるか——これだけが違います。

③ 論理的な概念であること

> なお、3層アーキテクチャは「どの層にどの機能をもたせるか」という論理的な概念であり、3層の物理的な構成を規定したものではありません。

>

> たとえば、データベース層とファンクション層は、同一のコンピュータ上で動作させてもよいし、そうでなくてもよいのです。

これは重要な注意点です。「3層＝サーバが3台」ではありません。

機能の分け方の話であって、機械の台数の話ではない——この区別を押さえてください。

④ 3層アーキテクチャのメリット

3層アーキテクチャでは、クライアント側にファンクション層の役割をもたないため、以下のメリットがあります。

⑤ 3つのメリットを整理する

2層の2つの問題点がそのまま解消され、さらに開発面の利点が加わっている——という構造です。

⑥ なぜ開発を並行できるのか

各層の独立性が高く、層間の依存度が低いためです。

層と層の間の受け渡し方だけを先に決めておけば、中身は互いに独立して作れます。

第2章の3層スキーマ、第5章のOSI参照モデルでも見た「層に分けると変更の影響が閉じ込められる」という原則が、ここでも働いています。

⑦ シンクライアント

このように、稼働するアプリケーションソフトウェアが限定的であり、保守性が高いクライアントをシンクライアントとよびます。

thin は「薄い、やせた」という意味です。ファット（太った）の対義語として名づけられました。

「シン」を「新（新しい）」と誤解しないこと——カタカナだけを見ていると起こりやすい誤りです。

⑧ 取り違えが出題された

令和元年度の本試験では、次の記述が出されました。

> 「クライアントサーバシステムのクライアントで、データの処理や保管などの多くの機能を担うように構成したシステムをシンクライアントシステムという。」

解答：×（ファットクライアントの説明）

「多くの機能を担う」＝太っている＝ファット——意味から考えれば取り違えません。

⑨ Webアプリケーションは3層の典型

現在のWebアプリケーションは、3層アーキテクチャそのものです。

第2章で学んだLAMP（Linux＋Apache＋MySQL＋PHP等）を当てはめると、

ブラウザさえあれば使える——これが、クライアントが「薄い」ということの具体的な姿です。

② SOA（Service Oriented Architecture：サービス指向アーキテクチャ）

SOAとは、ソフトの機能ひとつひとつを「サービス」という部品として切り出し、その部品を組み上げてシステムを作る考え方です。

ここでの「サービス」とはアプリケーションの処理単位を論理的に記述したものです。

③ サービスの4つの特徴

サービスは、以下の特徴を有します。

④ 4つの特徴を読み解く

「中身を知らなくても使える」——これがサービスという考え方の核心です。

電気製品にたとえると、コンセントの形と電圧さえ合っていれば、発電所の仕組みを知らなくても電気が使えるのと同じです。インタフェース（コンセント）が決まっていれば、中身（発電方式）は問われません。

⑤ サービスの粒度

サービスは、ビジネス・プロセスを実行できる粒度で作られます。

「データベースに1行追加する」のような細かすぎる単位でもなく、「販売管理システム全体」のような大きすぎる単位でもない——業務上の意味のあるひとまとまり、というのが適切な粒度です。

⑥ SOAのイメージ

既存のシステムを部品に分解し、組み替えて新しいものを作る——これがSOAの発想です。

⑦ SOAの2つのメリット

SOAを導入することにより、以下のメリットを享受できます。

1　柔軟性の向上

各サービスは自由に他のサービスと組み合わせることが可能なため、外部環境の変化や事業戦略の変更など、ビジネス環境の変化により迅速に対応できます。

2　再利用性の向上

サービスは他のさまざまなシステムから呼び出して再利用することが可能なため、システムごとに類似したアプリケーションを開発および運用する無駄を削減できます。

新たなシステムを開発する場合、既存のIT資産の再利用が可能になり、ROI（Return On Investment：投資対効果）の向上が見込めます。

⑧ ビジネス部門とIT部門から見たメリット

また、

• レガシーシステムの機能もラッピングによって、サービスとして再利用可能
• 再利用可能なサービスの組み合わせで、アプリケーションを構築
• サービスの組み換えや追加によって、市場の変化に即時対応
• サービス同士は疎結合で接続されるため、組み換えが容易

⑨ 疎結合という言葉

疎結合とは、部品どうしのつながりが緩いことを指します。対義語は密結合です。

部品を入れ替えやすくするには、つながりを緩くしておく——この考え方は、第9章で学ぶモジュール設計にも通じます。

⑩ レガシーシステムのラッピング

レガシーシステムとは、古くから使われ続けている基幹システムのことです。

SOAでは、レガシーシステムの機能をサービスとして包み直す（ラッピングする）ことで、新しいシステムから呼び出せるようにできます。

「動いているものは壊さず、外側を整える」——限られた資源でシステムを刷新する現実的な手法です。中小企業への助言としても実用的な視点になります。

利用者は1つのサイトを見ているだけですが、裏では複数のサービスが連携しています。これが「アプリケーションをリンクする機能」ということの意味です。

⑤ SOAP（Simple Object Access Protocol）

SOAPは、Webアプリケーションの連携に必要なメッセージ交換を行うためのプロトコルです。

SOAPでは、メッセージをXML形式で記述し、データをHTTPで伝送します。

⑥ WSDL（Web Services Description Language）

WSDLは、主にSOAPベースのWebサービスに使われます。プログラムからWebサービスを呼び出すインタフェースを記述するための仕様です。

それぞれのWebサービスがどのような機能をもつのか、それを利用するためにはどのような要求をすればいいのかなどを記述する方法が定義されています。

前のテーマで学んだ「明確に定義されたインタフェース」を、実際に書き表すための言語がWSDLです。

⑦ REST（Representational State Transfer）

RESTは、リソース（データ）をクライアントとサーバ間でやり取りする仕組みです。

RESTでは、データを主にJSON形式で記述し、データをHTTPで伝送します。

JSON（JavaScript Object Notation）は、サーバとWebアプリケーション間でデータを伝送するために使用する一般的なデータ形式です。JSONは、シンプルで軽量なデータ表現フォーマットであり、WebアプリやAPI、設定ファイルなどに用いられます。

⑧ SOAPとRESTを比べる

⑨ なぜRESTが主流になったのか

第3章で学んだ半構造化データの話を思い出してください。XMLもJSONも半構造化データですが、JSONのほうが簡潔です。第5章で触れたAjaxでも、実際にはXMLよりJSONが使われることが多くなっている、と述べました。

⑩ RESTはHTTPメソッドを使う

令和7年度の本試験では、「RESTはHTTPメソッドを用いることなく」という誤りの選択肢が出されました。

正しくは、RESTはHTTPメソッドを用いるWebアーキテクチャーです。

HTTPには、GET（取得）、POST（作成）、PUT（更新）、DELETE（削除）といったメソッドがあり、RESTはこれらを使い分けてリソースを操作します。

第3章で学んだCRUDと、きれいに対応していることが分かります。RESTは、データベース操作の考え方をWebの世界に持ち込んだ設計思想だといえます。

⑪ Web APIという言葉

API（Application Programming Interface）は、プログラムから別のプログラムの機能を呼び出すための約束事です。

Web APIは、それをWeb（HTTP）経由で行うものを指します。

前のテーマで触れた「APIがあるか」という確認は、この節で学んだ技術が実際に使えるかどうかを問うものです。

マイクロサービスは、SOAの延長線上にあるという位置づけです。

④ 目的

マイクロサービスアーキテクチャは、「あるサブシステムでの変更が、他のサブシステムにおよびにくくする」ことを目的としたAPI（Application Programming Interface）による疎結合化を強く推し進めた形です。

変更の影響を閉じ込める——第2章の3層スキーマ、第5章のOSI参照モデル、本節の3層アーキテクチャでも繰り返し見てきた原則です。

⑤ 導入の狙い

マイクロサービスアーキテクチャの導入によってITシステム内部構造におけるアプリケーションの疎結合化を図り、個別のサービスの変更に伴う影響範囲を小さくすることにより、デプロイ（開発したソフトウェアを本番環境に配置し、利用可能な状態にすること）の柔軟性、拡張性を高める狙いがあります。

デプロイがやりやすくなると、システム開発のスピードが高まり頻繁な改修が可能になります。

⑥ デプロイという言葉

デプロイとは、開発したソフトウェアを本番環境に配置し、利用可能な状態にすることです。

⑦ 独立して起動や停止が可能

マイクロサービスアーキテクチャは、独立した機能を組み合わせることで1つの処理を実現するアーキテクチャです。個々のマイクロサービスは独立して起動や停止が可能です。

この性質が、頻繁な改修を可能にしています。

⑧ モノリシック（モノリス）

一方、モノリシック（モノリス）は英語で一枚岩を意味し、大きな単一機能という特徴を表現したものです。

モノリシックアーキテクチャでは、アプリケーションの一部の機能を変更しようとする場合、マイクロサービスアーキテクチャであれば変更不要な機能も含めて変更する必要があり、変更不要な機能も含めたテストが必要になるなど、機能変更に伴いより多くのリソースが必要になります。

⑨ 2つを比べる

⑩ 一枚岩という比喩

monolith は「一枚岩」を意味します。継ぎ目のない巨大な塊というイメージです。

⑪ どちらを選ぶか

マイクロサービスが常に優れているわけではありません。

⑫ 第1節とのつながり

この比較は、第1節で学んだ集中処理と分散処理の比較と同じ構造をしています。

まとめるか分けるかというトレードオフは、処理形態でもアーキテクチャでも、同じ形で現れます。

中小企業の多くは、モノリシックで十分です。「新しいから」という理由でマイクロサービスを選ぶと、運用できる人がいないという事態に陥ります。