サーバーとクライアントがどういうものか基礎を押さえましょう。

サーバーエンジニアになるにあたり「そもそもサーバーとクライアントって何なんだ」って話なんですが、順を追って書いていきますので、読んでいくうちにわかってもらえると思います。

言葉の定義が大事なトコなので、定義しながら書いていきます。

なお、ハードウェアとしてのサーバーマシンやクライアントPCという考え方はここでは捨てて下さい。

コンピューターという機械にサーバーやクライアントの機能が紐づく訳ではありませんので、以降はコンピューターの事をPCと書きます。


１．プログラムとプロセス

プログラム開発言語で作ったものをプログラムと読んでいますが、ここではもう少し細かくしないといけません。

Windowsの皆さんご存知『メモ帳』を例にします。

メニューから辿っていくとデフォルトでは [c:¥Windows¥System32¥notepad.exe]ファイルになるはずです。
(C言語あたりでコンパイルされてできたファイルです)

以降はプログラムをプログラムファイルと呼んでしまうことにします。

PCがメモ帳を実行する時にはこんな動きをしています。


それでもってメモリに載ったコイツのことをプロセスって言います。

(プロセスを終了するとメモリから消えます)

メモ帳をもう1つ実行すると、同じプログラムファイルから別なプロセスができます。


ここでは蛇足ですが、OSはプロセスを一意の番号(プロセスID)で管理しています。



２．プロセスは他のプロセスのメモリにアクセスできない

プロセスのメモリは OSに管理されていて、あるプロセスが他のプロセスのメモリを参照したり書き換えたりすることはできません。


これは同じプログラムファイルから作られたプロセス同士であってもダメです。

蛇足ですが、プロセスのメモリ管理がヘボいOSでメモリの使い方がヘボいプログラムファイルを実行すると、他のプロセスのメモリを書き換えてしまい暴走したりします。


３．プロセス間通信

しかしプログラムファイルの用途によっては、プロセスの間でデータのやりとりができると便利なものってありますよね。

そういう時はプロセス間通信というのをやります。

例えば、メモ帳でCSVファイルを作り、Excelで読み込むとしましょう。


ナンのことは無い普段よくやる手ですけど、本来はお互いのデータに干渉し合えないはずのプロセス達がデータをやり取りしているではありませんか！

この例ではリアルタム性がないのでピンとこないかもしれませんが、これは広義のプロセス間通信です。

プロセス間通信はプロセスの外でデータを保持できるものを介して行われます。
上の例ではファイルが介在しています。

リアルタイム性が求められるプロセス間通信では、基本的に OSが用意したメモリ(プロセス用に用意されたメモリの外にある)を介在させます。
(プログラムでそういう方法が用意されています。)


４．サーバープロセス

私達がサーバーと呼ぶ PCで動いているのは、プロセス間通信をするプロセス、かつ待受タイプのプロセスなのです。

待受タイプとは何かですが、こういう感じになります。


プログラムファイルのロジックとして永久ループをしながら、OSが用意してくれたプロセス間通信用のメモリをず〜っと監視している、そんなやつ。

厳密には永久ループしなくても良いのですが、永久ループなんだって覚えてしまって良いと思います。

これをサーバープロセスって言います。


５．クライアントプロセス

サーバープロセスとプロセス間通信をするプロセスをクライアントプロセスと言います。

サーバープロセスの図に足すとこうなります。


OSが用意してくれたプロセス間通信用のメモリを読み書きすることで、サーバープロセスとデータのやり取りをします。


６．一般的なサーバー・クライアントシステムの動きの順序

サーバー・クライアントシステムというと大体このようにクライアントプロセスのデータをプロセス間通信でサーバープロセスに渡して、サーバープロセスで処理されたデータを戻してもらう形になっています。


データベースやWEBサーバーなんかはこの形ですので、そういった製品を思い出してみればイメージが湧きやすいと思います。

そしてこのページで一番大事なのは、

サーバーエンジニアが扱うのは全てコレ！
(上の絵はクライアントプロセスからの往復になっていますが、サーバープロセスに投げっぱなしの形もあります。)

ということなのです。

製品やOSSによってサーバープロセスのことを「エージェント」など機能面の名称で呼ぶものも結構ありますけど、仕組みは全てコレだと捉えてしまって問題ないと思います。

色々なプロセス間通信をするプロセスが登場すると思いますが、この基本は変わりませんので名称に惑わされないようにしましょう。


７．ネットワークを介するプロセス間通信

ここまで書いてきたサーバープロセス・クライアントプロセスですが、これらがどこのPCで動いているかは全く言及していませんでした。

これまでの図は 1つの PC内でのイメージに近いのですが、これらが別な PCで動いていてネットワークで繋がってるって形の方が「サーバー」ってイメージに近いですよね。

サーバープロセスが動いている PC・クライアントプロセスが動いているPC、ネットワークの通信プロトコルを TCP/IPと仮定すると上で描いた図はこんな風になります。


それぞれの PCの OSがやってくれる通信部分を隠してしまうとこんな絵になります。

上の基本と何も変わらないですね。


８．初心者を悩ませるプロセスのケース

これがサーバープロセス・クライアントプロセスか。
ｸｸｸ…こんなシンプルな観念の理解は余裕よ！

とイキる初心者を悩ます(と思っています)ケースにこんなプロセスがあるんですよ。


へっ?!、なにコレ…

とイキリが折れる瞬間ですけど、このパターンは決して少なくありません。
これもサーバープロセスって呼ばれるので、ますます混乱するかも知れませんね。

Javaのサーブレットエンジンである Tomcatの例で「あぁ、何だ」って安心できると思います。


プロセス 1つにサーバーかクライアントの機能がどちらか 1つだけという制限はありません。

また、プロセス 1つにサーバー機能やクライアント機能が 1つだけという制限もありません。

これらの機能が一杯載ったプロセスを作ることもできます。
(ソフトウェア設計の合理性として良いかは別ですが)

有名な監視ソフトの Zabbixに至ってはこうですわ。
(Zabbix Agentをサーバーと呼ぶのを聞いたことはありませんが完全にサーバープロセスです。)

(Zabbixサーバーは子プロセスをいくつか持っているのでもしかするとアクティブ・パッシブで別プロセスになってるかも知れませんけど裏を取るのは面倒くさい。)


９．サーバーエンジニアに求められる用語の使い方

一般に言われている「サーバー」は、データセンターのラックに入っているサーバー機(HPや Dellなんかが売ってるやつ)を指す事が多いように思いますし、ITの現場でもそういう意味で「サーバー」って言うこともあります。

ですけど仕事をしている上では TPOに合わせて「サーバー」や「クライアント」の用語の使用を適切にしないといけません。

今回のネタはサーバーの機能設計の資料などを作る際に意識しておくポイントになるかと思います。

ファイアウォールやNATなど、ややネットワーク寄りの話になる場合は、通信の向き(クライアントプロセス→サーバープロセス)が重要になってきますので、プロセス間通信でどちらがサーバーでクライアントなんだかをハッキリしておく必要があります。

個人的な見解では「サーバープロセスが動いているPC」の事をサーバーとするのが正しいと思うのですが、それも時と場合によりますかね。