インフラの中核を担う「サーバ」を知ろう

はじめに

みなさん、こんにちは。第2回の今回は、インフラの中でも中核にあたる「サーバ」について、もう少し詳しく解説していきます。サーバ関連の技術は幅広く、考慮しなければならないことも多いため、実際のプロジェクトでもインフラエンジニアの技量によって品質に大きな差が発生しているのが現状です。最近では標準化によりサンプルとなる設計や手順が存在することもありますが、扱う製品のバージョンアップも多いため、やはり最後はエンジニアの技量に依存しているところも多くあります。インフラエンジニアが何をしていて、どのように仕事を進めているかなど、現場における生の話も織り交ぜながら解説します。

サーバとは

1. クライアント・サーバシステムにおけるサーバ

日本人には馴染みが薄いですが、レストランで料理を給仕してくれる人を「Restaurant Server」と言います。このように、お客様にサービスを提供する人やモノが一般的なサーバです。ITのシステムではクライアントにサービスを提供するモノがサーバです。レストランでは料理人や給仕が専門化されていることで、おいしい料理と一流のおもてなしといった一般家庭では追及が難しいサービスを受けることができます。ITのシステムでもサーバが専門化されていることで、高速処理や365日24時間常時稼働といった、各コンピュータで追及が難しいサービスを受けることができます。

また、サーバを用意すると複数のクライアントからの要求を同時に処理できることも大きなメリットになります。各コンピュータをネットワーク接続できるからこそ実現できる構成で、ネットワーク技術の発展がクライアント・サーバシステムを支えているとも言えます。小規模のシステムでは1台のコンピュータで完結するものもありますが、最近のシステムではクライアント・サーバ型が一般的な構成となります。

2. 特定の役割を持つサーバ

「サーバ」とだけ表現すると、パソコンと対になるコンピュータとしてハードウェアの色合いが強くなりますが、本記事ではこれを便宜上「物理サーバ」とします。物理サーバのみでは何もサービスを提供できませんが、OSやミドルウェア、アプリケーションなどを導入することで様々なサービスを提供できるようになります。同じ物理サーバでも導入するソフトウェアによって役割が異なってくるのです。

第1回でWeb3層構造について少し触れましたが、最近のシステムではWebサーバ・APサーバ・DBサーバが主役です。ここでは、Webサーバを例に解説したいと思います。

3. Webサーバの役割

Webページを閲覧する時のことを思い出してほしいのですが、パソコン（クライアント端末）のブラウザで直接URLを打ち込んだりGoogleで検索をしたりすると思います。閲覧要求が発生すると、その要求がネットワークを通じてWebサーバまで運ばれ、Webサーバはその要求に従ってコンテンツ（文字や画像）を返し、クライアントは受け取ったコンテンツを表示します（図1）。

図1：Webサーバの役割

それでは、Webサーバとは何でしょうか。図2はWebサーバの構成要素を分解したものですが、インフラの構成要素のうち「サーバ（物理サーバ）」「OS」「ミドルウェア」から成り立っていることが分かります。

図2：Webサーバの構成要素

サーバ（物理サーバ）は多くのメーカが様々な製品を発表していますし、OSやミドルウェアにも複数の選択肢があります。図3は私が今まで関わったプロジェクトで使用されていたWebサーバの組み合わせですが、それだけでも6種類の組み合わせがあることが分かります。この組み合わせの中からどのように選択していくかは様々な観点がありますが、例えばコスト（初期導入コスト、運用コスト）や実績、セキュリティへの対策状況などを勘案してプロジェクトごとに決めていきます。私の経験上ですが、WebサーバはDBサーバなどに比べるとクリティカル度（必要不可欠な度合い）が低いこともあり、コストを優先して左側の組み合わせを選択するプロジェクトが多数派でした。

図3：プロジェクトのWebサーバで使用されていた製品の組み合わせ

4. 複数の役割を持つサーバ

同じ物理サーバ上にWebサーバとAPサーバが同居する構成もよく見られます。この構成では物理サーバとOSを共有していますが、Webサーバ用のミドルウェアとAPサーバ用のミドルウェアを導入することで2つの役割を持たせています（図4）。

図4：複数の役割を持つサーバの構成要素

物理サーバとOSが1セットで済むためコスト面ではメリットですが、物理サーバやOSに障害が発生した場合に両方の役割を失う可能性がある点がデメリットです。このように、ソフトウェアの配置にはメリットとデメリットがあります。興味がある方はインフラ構成に関する書籍や資料を参考されることをお勧めします。

続いて、物理サーバ、OS、ミドルウェアについてさらに深掘りして行きましょう。

物理サーバ

図5は物理サーバの内部を上から撮影したものです。パソコンと比べて堅牢さを感じるのではないでしょうか。搭載されているCPU・メモリ・ハードディスク（以下、HDD）といったパーツには高性能・大容量のものを使用しています。

図5：物理サーバの内部

CPU、メモリ、HDDはサーバの性能に大きく関係するため、必要な性能や容量を見誤ると処理力低下や処理不能（サーバダウン）につながります。システムの使用中に「動作が遅い」と感じるときは、一部のサーバで処理が要求に追いついていない可能性が考えられます。対処法として、該当サーバのCPUやメモリの追加、物理サーバの増設などを検討することもあります。

OS（オペレーティングシステム）

OSは「オペレーティングシステム」の略で「基本ソフトウェア」とも呼ばれます。ハードウェアとアプリケーション、ミドルウェアの間に位置し（図6）、メモリ管理やネットワーク処理など多くのソフトウェアが共通して利用する機能を提供します。

図6：OS（オペレーティングシステム）の立ち位置

「OSがないとどうなるの？」という質問をよく受けますが、OSがなくてもコンピュータを動かすことは可能です。実際、コンピュータが出始めた頃にはOSは存在していませんでした。例えば、アプリケーションにネットワーク機能が必要ならば、アプリケーションにネットワーク機能を盛り込めばOSは不要です。しかし、そのためには相当の時間とお金が必要となるためOSを使用しています。

OSにも多くの選択肢がありますが、使用するOSを決める際はコストや運用性、ミドルウェアとの組み合わせも考慮して決めていきます。以下に、サーバでよく使用するOSを記載します。

皆さんは、OSに関して「どこから勉強したら良いのか」と思うかもしれません。UNIX系は基本的な概念や操作感に大きな違いはなく、Windows ServerはOSの基礎があればパソコンと同じ感覚で理解していけるので、まずは入手しやすいRHELやCentOSでOSやUNIXの基礎を勉強するのが良いと思います。

ミドルウェア

ミドルウェアは、名前の通りアプリケーションとOSの中間的な役割を持つソフトウェアです（図7）。WebサーバはWeb機能、APサーバはアプリケーション機能、DBサーバはデータベース機能と、特化した機能を提供します。これらのミドルウェアを導入することで、サーバに役割を持たせることができます。

図7：ミドルウェアの立ち位置

図8は私がこれまでに経験してきたミドルウェア製品です。同じ種類のミドルウェアでも様々なメーカから提供されており、それぞれに特徴があります。プロジェクトによって使用する製品は異なるためさまざまな製品の知識が必要になりますが、1つの製品を経験すればその種類のミドルウェアについては概念を理解できるので、それほど恐れるものでもありません。

図8：主なミドルウェアの分類と製品

ミドルウェアも製品を選択していく必要がありますが、実際には「自社の製品を売りたい」という事情からシステム開発を主管する会社の製品を使う場面が多くなります。私たちのような独立系の会社では各社の製品に触れる機会がありますが、勉強が大変な一方で複眼が養われるという強みもあります。

＜コラム＞プロジェクトに関わるエトセトラ ：ウォーターフォール型開発の進め方

連載を通して、インフラエンジニアが関わる「プロジェクト」に注目し、さまざまな側面から解説していく本コラム。今回は、ウォーターフォール型開発の進め方について解説します。

まず、お客様からの「こんなITサービスを作りたい」という要望に「このくらいの予算で、このようなITサービスを提供します」と提案します。もちろん1社ではなく複数の企業が提案するので、お客様の採用を勝ち取ることで「プロジェクト」が発足します。 第1回の復習になりますが、ウォーターフォール型開発とは、誤解を恐れずに書けば「計画をしっかり立てて1回で完成品を作ろう」とするやり方です。「元に戻る、作り直す」ことはなく、下図のように各フェーズに分けてシステムを定義・設計し、構築していきます。

ウォーターフォール型開発

ここでは、ITインフラに特化して解説していきます。まずは「要件定義」フェーズです。アプリケーションが動く基盤として、どのように要件を実現していくかを決めていきます。続く「基本設計」では、どのOSを使用するか、どのミドルウェアを使用するか、そのミドルウェアを使用してどのように作っていくかを設計していきます。「詳細設計」フェーズでは、基本設計をベースにより細かく設定値などを決めていきます。ここまでが設計工程です。建設業で例えると設計図が書き終わったところです。

設計書ができあがったら実際に作り始め（「構築」フェーズ）、完成したら設計書通りに動くかテストします（「単体テスト」「結合テスト」「システムテスト」フェーズ）。最終的にすべてのテストをクリアするとシステムをリリースし、ITサービスとして一般の方々や使用者に公開します。このように、上から下まで水が流れるかのように作業を行い、手戻りせず進めていくことから「ウォーターフォール型開発」と呼ばれています。

ただ、実際には各フェーズでの考慮不足や、設計したものの構築フェーズで設計が間違っていたことに気付いて手戻りすることも多々あります。熟練したインフラエンジニアであれば経験則から予め気付くことも多いですが、それでも技術は日々進化しているため間違いは起こります。その中で「どのように解決していくか」を考えることもインフラエンジニアの役目です。次回からは、フェーズごとにもっと詳しく解説していきます。

（第3回へ続く）

周辺装置

ここまでサーバについて解説してきましたが、インフラエンジニアはサーバを補佐する周辺装置を扱う機会も多くあります。ここでは、よく使用する周辺装置について解説していきます。

1. ストレージ装置

ストレージ装置は、高性能なHDDを複数積んだ「データ保存に特化した装置」です。大きいものでは大型冷蔵庫くらいのものもあり、1セットで数億円というものも珍しくありません。データを失わないように耐障害性に優れ、サーバ内のHDDでデータを保持するよりもはるかに安全です。また、高速な読み書きを実現するために多くのパーツがHDDの周辺を固めています。

機能も豊富で、よく使用されるのは装置内のHDD間でデータを複製する機能です（図9）。例えば、HDD①に保存しているデータをあるタイミングでHDD②に複製し、さらにHDD②のデータをHDD③やHDD④に複製すれば二重でバックアップを取得できます。

図9：ストレージ装置における二重バックアップの仕組み

2. テープ装置

テープ装置は、ストレージ装置と同様に「データ保存に特化した装置」です。ストレージ装置は装置内部に搭載されたHDDにデータを保存しますが、テープ装置は装置内部に装填されたテープメディアにデータを保存します。主にバックアップをターゲットにした装置でテープメディアを取り出すこともできるため、システムとは別の場所に保管して災害などからデータを守るという考え方を取り入れているシステムもあります（図10）。

図10：テープ装置におけるバックアップ

テープ装置は、持ち運び性やデータ保存の単価が安いという点がメリットですが、慣れていないと少し操作が難しいため毛嫌いする人もいます。他の技術と同様にメリットやデメリットを整理して導入を検討することになります。

おわりに

今回は、「サーバ」について解説しました。OSやミドルウェア、またストレージやテープ装置など、サーバに関わるものは数多くあります。インフラエンジニアは、日々これらのものを様々に組み合わせながらインフラを設計・構築しています。

次回は、「ネットワーク」をテーマに解説します。インターネットもネットワークの集合体ですが、サーバと同様にインフラには欠かせない重要な要素です。サーバとは異なる観点が多く出てきますので、次回も楽しみにしていてください！