Windows365についての記事を書くために、まずクライアント・サーバーについての説明をしようと思う。
この記事は主にIT素人さん向けに書く。
いつものように「常体」で簡潔な文章を心がける。
ITシステムやスマホのアプリなどは、ほとんど全てがクライアント・サーバーというシステム構成で実装されている。
今では当たり前になっていてクライアント・サーバーという名前が使われる事がほとんど無くなってしまった。
最近では多数派になったWebアプリケーションも一種のクライアント・サーバーである。
今後はITエンジニアではない「一般ユーザー」もITシステムの開発や活用に関わる機会が多くなるだろうから、ある程度のITシステムの知識は必要になる。
今回は一般ユーザーのIT素人さん向けにクライアント・サーバーについて解説したいと思う。
最低限のシステム要素
クライアント・サーバーのクライアントとはユーザーが直接操作するパソコン、又はアプリの事である。
サーバーとはそのクライアントのパソコンが通信する相手のデータセンターやクラウドコンピュータなどに設置されている大きなパソコンの事である。
サーバーという言葉は一般ユーザーも仕事で聞いたことのある人も多いのではないか。
クライアント・サーバーとは、複数のクライアント端末が単一のサーバー機にアクセスして情報処理を行うシステムの構成の事である。
クライアント・サーバーは、C/Sとも表記する。
現代のクライアント・サーバーにはいくつか種類がある。
それらを分かりやすいように、図を使って解説する。
それに当たって、システムの構成を理解する為に、最低限必要なハードウェアとソフトウェアの「要素」について以下の図と言葉で表す。
まず、以下の「凡例」図を見て欲しい。
凡例
クライアント端末
ユーザーが直接操作するパソコンやスマホやタブレット端末の事である。
この図はハードウェアを表す。
サーバー機(Webサーバー・APサーバー)
白いサーバー機はクライアント端末が通信する相手のサーバー機を表す。
Webサーバーとは一般のWebで提供されるWebアプリやWebサービスを稼働させる為のミドルウェアである。
昔はHTMLファイルやCSSファイルなどをクライアント端末のブラウザに送るだけのソフトウェアだったが、年々進歩して今ではWebサーバー側でアプリケーションを実行できるようになった。
現在インターネット上で提供されているWebサービスはこのWebサーバーによって開発され稼働している。
APサーバーとは「アプリケーション・サーバー」の略であり、クライアント端末のアプリと通信する専用のサーバー側のソフトウェアである。
サーバー側のアプリはこのアプリケーション・サーバーの組み込みモジュールとして、個々のアプリ固有の機能を実装する。
近年はサーバー側開発用フレームワークにAPサーバーの機能を内蔵している物も多い。
その為APサーバーという言葉もだんだん使われなくなってきている。
サーバー機(データーベース・サーバー)
黒いサーバー機は主にWebサーバー・APサーバーが通信する相手のデーターベース・サーバー機を表す。
これにはDBMS(データーベース管理システム)がインストールされて稼働している。
データーベース管理システム
先に説明したDBMSというソフトウェアの事である。
主なDBMSにはOracle, SQL Server, PostgreSQL, MySQLなどがある。
このソフトウェアがデータを保管し操作編集する。
システムの扱う全てのデータの置き場所がここになる。
標準的ソフトウェア製品
俗に言うサーバー側のミドルウェアや、クライアント側のブラウザなど、システムやアプリを開発する為の土台や部品になるソフトウェアの事である。
汎用ソフトウェアとして広く使われており、多くは標準的ソフトウェア製品となっている。
一般ユーザーになじみやすいものはChromeやEdgeやSafari,Firefoxなどのブラウザだろう。
APサーバーのTomcatやWebサーバーのnginx, Apache, IISなどもこれで表す。
専用ソフトウェアやプログラム
固有のシステムやアプリの情報処理を記述したプログラムを表す。
クライアント側ならデスクトップOS用のアプリを表し、サーバー側ならAPサーバーなどに組み込む「アプリ専用モジュール」を表す。
DBMSならストアドプロシージャを表す。
通信処理
クライアントとサーバーは通信するので、どことどこが通信するのかを表す。
個別のデータ・テーブル
DBMSに作成した、個々のシステムやアプリ専用のデータやテーブル(データの容器)を表す。
クライアント・サーバーの機器構成
クライアント・サーバー型システムの最も単純な構成は、複数のクライアント端末が一台のサーバー機と通信する構成である。
また、現代のシステムは大半がサーバー機にDBMS:データーベース管理システムを稼働しているので、「まず、クライアントとサーバーが通信し、次にサーバーとDBMSが通信する」という構成で構築されている。
クライアント/サーバー型システムの基本構成
上図の「公的通信」とはインターネットや社内LANなどの末端通信回線の事である。
「内部通信」というのは、様々なケースがあり「データセンター内部の通信」や「APサーバーとデーターベース・サーバーとの通信」や「APサーバーとDBMSの通信」などを表す。
「内部通信」はクライアント・サーバーの構成方法によって、「誰と誰がどのように通信するのか」が変わってくる。
クライアント・サーバーにはいくつも種類があり、多様なシステムの構成方法がある。
それらを大雑把に分類すると、二種類の分類方法が考えられる。
「単独サーバーと分散サーバー」という分類と、「2階層クライアント・サーバーと、3階層クライアント・サーバー」という分類の、二種類の分類である。
単独サーバーと分散サーバー
単独サーバー構成
「単独サーバー構成」図は、最も単純なクライアント・サーバーの構成を表したものだ。
サーバー機は一台だけで、その中にDBMS(データーベース管理システム)を設置する。
クライアントPCは複数台存在し、その全てが一台のサーバー機にアクセスする。
「公的通信」とは、社内LANやインターネットやVPNなど「セキュリティ対策が施された、安全に通信できる通信回線を使用した通信」と考えて欲しい。
この「単独サーバー構成」はクライアント・サーバーの構成を考える時の「基本的概念」と考えて欲しい。
企業の業務システムなどのクライアント・サーバー型システムの場合、現実にこの構成のシステムは多く使われている。
ユーザー数の少ない業務クライアント・サーバー型システムならだいたいこの構成である。
この構成でも千人ぐらいのユーザー数は扱える。
もっと多くの「万」単位のユーザー数になると、「単独サーバー構成」ではサーバー機のリソース不足で、満足なレスポンスタイム(応答時間)を得られない。
ユーザーがストレスを感じない快足なレスポンスタイムを得るには、サーバー機のリソースを増やしてやる必要がある。
複数サーバー構成
「複数サーバー構成」図は、一般的なデータセンターやクラウドコンピュータなどで使用されるクライアント・サーバーの構成である。
大規模クライアント・サーバー構成の基本概念図である。
クライアント・サーバーのサーバー機がアプリケーション・サーバー機とデーターベース・サーバー機に分離している。
アプリケーション・サーバー機とはクライアント端末から直接接続し通信するサーバー機で、これを複数台揃えておく。
データーベース・サーバー機は一台である。
データ容量を拡大する為に複数のデバイスを用意する事もある。
ハードディスクを複数台組み合わせてディスクアレイにしたり、分散コンピューティングで複数のサーバー機が一台の仮想データーベース・サーバー機として使用できるようにしたりする技術や製品があるが、概念的にはデーターベース・サーバー機は一台と考える。
複数のアプリケーション・サーバー機には個々に異なるIPアドレスが付番される。
「負荷分散装置」とはDNSの一種であり、アプリケーション・サーバーに仮想的に割り当てられたドメイン名で、クライアント端末がサーバー機のIPアドレスを問い合わせると、負荷分散装置に登録している複数のアプリケーション・サーバー機のIPアドレスを、順番にクライアント端末へ回答していく。
つまり一つのアプリケーション・サーバー機にクライアント端末との通信負荷が集中しないようにする装置だ。
クライアント端末は負荷分散装置にドメイン名を渡し、返されたIPアドレスのアプリケーション・サーバー機へ「公的通信」で接続する。
アプリケーション・サーバーへリクエストする度に、これを繰り返す。
クライアント端末へ返されるIPアドレスは、毎回異なる。同じになっても偶然である。
全てのアプリケーション・サーバー機は、一つの同じデーターベース・サーバー機へ接続する。
通常はアプリケーション・サーバー機とデーターベース・サーバー機は、同じデータセンターの中に存在すると考えて欲しい。
「内部通信」は同じ施設内のLANで行われる。
インターネットのような外部通信回線は使用されない。
データーベース・サーバー機は、外部のクライアント端末からは直接アクセスできない。
これにより、データーベース・サーバー機の保有するデータを外部の不正アクセスから守る事ができる。
負荷分散とセキュリティを満たすクライアント・サーバー構成である。
クライアント・サーバーの構成の座標軸として、アプリケーション・サーバーが単独か複数か、という種類がある。
最も単純だとデーターベース・サーバー機とアプリケーション・サーバー機が一台のサーバー機に収まる。
次に複雑になると、データーベース・サーバー機とアプリケーション・サーバー機が、それぞれ一台の、二台構成がよく使われる。
その次に複雑になると、アプリケーション・サーバー機をプライマリ機とセカンダリ機の二台用意して、プライマリ機に繋がらない時はセカンダリ機に繋がる構成というのもある。
更に複雑になると「負荷分散装置」を使用する事になる。
これが「単独サーバー構成と複数サーバー構成」の分類である。
2階層と3階層クライアント・サーバー
もう一つの分類は「2階層クライアント・サーバー」と「3階層クライアント・サーバー」である。
2階層クライアント/サーバー
「2階層クライアント・サーバー」とは、「単独サーバー構成」のように単純なクライアント・サーバー構成で、クライアント端末が直接データーベース・サーバーのDBMS(データーベース管理システム)と通信する構成である。
原始的で単純なクライアント・サーバーと言える。
昔のクライアント・サーバーは皆この構成だった。
構成が単純なのでシステム開発コストを低く抑える事ができる。
データーベース・サーバー機をクライアント端末に公開する事になるので、不正アクセスもし易くなる。
今でも開発コスト削減で、この構成を取るクライアント・サーバー型システムは多い。
システムを社内LANの中でしか使用しないのなら、セキュリティ的に問題なく、社内システムの場合、ユーザー数も少ない事が多いから一台のサーバー機で足りるからである。
この構成ではクライアント端末のアプリは直接SQLを発行してデータを得たりする。
3階層クライアント/サーバー
インターネットのようにサーバー機を外部公開し、データーベース・サーバー機をクライアント端末に直接晒すのは危険が多い場合は、クライアント端末とデーターベース・サーバー機の間に、アプリケーション・サーバー機を配置して、それを経由しなければデーターベース管理システムにアクセスできないようにする。
アプリケーション・サーバー機をデーターベース・サーバー機から分離する事で、個々のサーバー機のリソースに余裕も生まれる。
スマホのアプリなどは全てこの構成である。
PCのアプリもサーバーがインターネット公開されるものはこの構成だ。
データーベース・サーバー機はデータセンター内に隠されている。
「複数サーバー構成」は3階層クライアント・サーバーでなければ、構成できない。
この構成では、データはデーターベース・サーバー機に格納され、業務ロジック(サーバー側処理)はアプリケーション・サーバー側に配置される。
データとロジックを分ける構成にする事が、元々の3階層化の目的だった。
ただ、現実にはDBMSにストアドプロシージャを配置したりして、データーベース・サーバー機に業務ロジックの一部を置いたりするので、それは厳密とは言えない。
クライアント端末とアプリケーション・サーバーとの通信は、昔はSOAP(WCF)、今ならREST-APIやgRPCが使われる。
UWPのようにソケットを使用する場合もある。
クライアント端末とサーバー機のOSや実行基盤が異なっていても通信できるように、標準化された通信規格とデータ規格を使用し、シリアライズ(バイナリとテキストの変換)によって個々の実行基盤の規格に変換して通信する。
これが「2階層と3階層クライアント・サーバー構成」の分類である。
二者択一なので、これは分かりやすいと思う。
データーセンターやクラウドの構成
データーセンターやクラウドコンピュータなどのサーバー機器構成は、割と自由に構成できるが、一般的な公開アプリの場合は以下のように「3階層」で「複数サーバー構成」の機器構成となる。
データーセンターなどの構成
青い枠組みの中がデーターセンター内を表している。
ユーザーのPCやスマホなどのクライアント端末から、インターネットを介して、データーセンター内の「負荷分散装置」に最初にアクセスする。
負荷分散装置がアプリケーション・サーバー機のIPアドレスを、クライアント端末へ返す。
そのIPアドレスのアプリケーション・サーバー機に、再びクライアント端末がアクセスして、3階層クライアント・サーバー型アプリが起動する。
あとはアプリケーション・サーバーがデーターベース・サーバー機と通信して情報処理を行う。
クライアント端末はデーターベース・サーバー機には直接アクセスできない。
一つのクライアント端末がアクセスするアプリケーション・サーバーは一つではない。
一回目の接続ではNo.1のアプリケーション・サーバーに接続しても、二回目の接続ではNo.3のアプリケーション・サーバーに接続し、三回目はNo.2のアプリケーション・サーバーに接続するという事が起きる。
負荷分散装置はユーザーのクライアントとアプリケーション・サーバーをランダムに繋いでいるので、接続先のアプリケーション・サーバーは決まっていない。
クラウドコンピュータではアプリケーション・サーバーの個数を、自由に増やしたり減らしたりできる。
これによりアクセスの集中する昼間や繁忙期にはサーバー機を増やして、夜や閑散期などはサーバー機を減らしたり出来る。
データーベース・サーバー機の構成は、それぞれの独自の工夫が施されているので、ご利用のデーターセンターやクラウドの仕様書やマニュアルを確認して欲しい。
クライアント・サーバーのソフトウェア構成
次にクライアント・サーバーのソフトウェアの構成について説明する。
3階層クライアント・サーバーのソフトウェア構成を先に解説したい。
クライアント・サーバーのソフトウェア構成
データーベース・サーバーのソフトウェア
3階層クライアント・サーバーでは、図の右側のデーターベース・サーバー機に、データーベース管理システムを設置している。
代表的なデーターベース管理システムは、Oracle, SQL Server, PostgreSQL, MySQL, DB2, MariaDBと言ったところだ。
OSはUNIX, Linux, Windows Serverなどが使用される。
ちなみにUNIXとは特定のOSではなくUNIXという仕様に従ったOSの総称である。
ベンダーによって実装が異なる。
IBM AIX, HP-UX となどがある。
LinuxもUNIXを参考に開発されている。
アプリケーション・サーバーのソフトウェア
図の左下のアプリケーション・サーバー機に、Webサーバーやアプリケーション・サーバーなどを設置する。
代表的なWebサーバーは、Apache, nginx, 古いものでIIS などがある。
アプリケーション・サーバーだと WebLogic , Tomcat , GlassFish, WebSphereなどがある。
最近は、Webサーバーでも業務ロジックを稼働させる事ができるので、Webサーバーでもアプリケーション・サーバーとして機能する。
(正確にはWebサーバーからサーバー側アプリケーションを呼び出している)
Webサーバーやアプリケーション・サーバーにはサーバー側の業務ロジックが設置される。
最近はNode.js やASP.NET MVCなどサーバー側アプリケーション自身がアプリケーション・サーバーの機能を内蔵するものも多い。
この場合、上記のnginxやTomcatなどのアプリケーション・サーバーを必要としない。
アプリケーション・サーバーにはデーターベース管理システムのクライアントソフトウェアがインストールされており、そのクライアントソフトウェアでデーターベース管理システムへ接続する。
図の「内部通信」と書かれたものがそれを意味する。
OSはUNIX, Linux, Windows Serverなどが使用される。
クライアントのソフトウェア
図の左上のクライアント端末にはそのOSで稼働する「アプリ」がインストールされており、アプリの内蔵する通信機能により、OSのネットワーク機能を経由して、アプリケーション・サーバーへ接続する。
図の「公的通信」と書かれたものがそれを意味する。
負荷分散装置へのIPアドレスの問い合わせはOSのネットワーク機能に任せられるので、アプリは負荷分散装置との通信処理を自分では行わない。
画面レイアウトや値の入出力や帳票出力、画像や動画の表示など、画面側の業務ロジックはこのアプリに内蔵される。
OSはWindows10, macOS, iOS, Androidなどが使用される。
2階層クライアント・サーバーのソフトウェア構成
2階層クライアント・サーバーのソフトウェア構成は、3階層クライアント・サーバーの、アプリケーション・サーバー機のソフトウェアと、データーベース・サーバー機のソフトウェアを、一台のサーバー機にインストールした構成になる。
つまりnginx, Tomcat などと、PostgreSQL, MySQL, Oracleなどを、同じサーバー機に配置する。
この配置方法だと、3階層クライアント・サーバーのアプリをそのまま、2階層クライアント・サーバーで稼働させることができる。
しかし、通常はアプリやシステムの開発コスト削減のため、クライアント端末のアプリから、直接データーベース管理システムへ接続する設計にする事が多い。
クライアント端末に、データーベース管理システムのクライアントソフトウェアを直接インストールして、クライアント・アプリから直接データーベース管理システムへ接続する。
このやり方ならアプリケーション・サーバー側のシステムやアプリを開発しなくても良いから工数の削減になる。
アクセス数の少ないシステムなどはこの構成にする。
社内ネットワークの中など、安全の保証されたネットワークでしか使用しない構成である。
Webアプリケーションのソフトウェア構成
Webアプリケーションも一種のクライアント・サーバー型アプリである。
通常のクライアント・サーバー型アプリとの違いは、Chrome, Edge, Safari などブラウザがクライアント端末に存在すれば、ブラウザの機能によって稼働する事ができる点にある。
クライアント側の業務ロジックは、HTMLやJavascripによって記述され、ブラウザ上で動作する。
WebアプリはOSには依存しないため、クライアント端末がWindows10であろうが、iOSであろうがAndroidであろうが、同じように動作する。
Webアプリケーションのソフトウェア構成
この図のように、アプリケーション・サーバーとデーターベース・サーバーのソフトウェア構成は、ほとんど通常のクライアント・サーバー型アプリと変わらない。
違いは、必ずWebサーバーを必要とする点と、クライアントの業務ロジックをアプリケーション・サーバー機に配置しておく点にある。
Webアプリはサイトを開く度に、クライアントの業務ロジックをブラウザでクライアント端末にダウンロードする。
だから通常アプリと違い、クライアント端末にアプリをインストールしておく必要が無い。
クライアント端末側アプリの管理やメンテナンスが非常に楽になる長所がある。
短所は機能がアプリに比べて少ないことだ。
クライアント端末には簡単な機能しか実装できない。
終わりに
クライアント・サーバー構成は、比較的古くからある構成で、将来新しい技術の登場で縮小するかと思っていたが、スマホの普及で逆に広く普及している。
「アプリ」と呼ばれるものは、ほとんど全てクライアント・サーバーであるにも関わらず、あまりに広く普及しているので、クライアント・サーバーという言葉は当たり前すぎて使われなくなってしまった。
しかし、広く普及しているソフトウェア構成の仕組みを、一般ユーザーが認識していないのは問題だ。
例えば「Excelだけでグループウェアを作って欲しい」などの要望が聞かれる事がある。
これはグループウェアなどのソフトウェアが、サーバーを介してユーザー間で通信しており、Excelだけでは作れない事が認識できていないから、出てくる発想だ。
ITエンジニアではない、一般ユーザーさんにはこういうことが常識として分かっていない人も多い。
だから時々、こういうシステムの基礎知識を、ITエンジニアではない、一般ユーザー向けに書いている。
ITシステムはこれからも広い範囲で使用されるようになるので、一般ユーザーにも最低限の知識は必要である。
しかし、世間では一般ユーザー向けの説明は充分とは言えないと思う。
その部分をこのブログで埋めてみようと思っている。
時々、技術的記事も書く。
冒頭で、ITエンジニア向けの記事か、一般ユーザー向けの記事か明記する。
最後まで読んでいただきありがとう。
