ITインフラの全体像を理解しよう
はじめに
本連載では、これからIT業界（特にインフラエンジニア）に踏み出そう、または踏み出したいと思っている方向けにインフラの基礎知識を解説していきます。
「インフラ」は大学の情報学科でもなかなか教えていない分野で認知度も低く、特に新卒採用では仕事内容を理解してもらうところに最も力を入れます。私たちはインフラエンジニア250名を擁する会社として数々のシステムに携わってきましたが、その経験を基に現場の状況を織り交ぜつつ生の雰囲気をお伝えしたいと思っています。
第1回の今回は、システム開発に関わるインフラ全般の概要を解説し、第2回以降は各要素に特化した内容を昨今のトレンドを考慮しつつ、全8回（予定）で解説していきます。
インフラ（インフラストラクチャー）とは
1. 生活や産業の基盤となる設備・施設
インフラ（インフラストラクチャー）とは、もともと「下部構造（インフラが下部、ストラクチャーが構造）」のことで、辞書的に言うと「生活や産業の基盤となる設備・施設」です。身近なところでは水道・電気・ガスの設備や道路などがインフラに該当します。
例えば、道路にフォーカスすると、道路を車が走ることにより移動や流通が成り立ちます。道路だけでもダメですが、車だけでもダメという関係性があります。車が活躍するための下部構造を道路が提供しているというわけです。 この道路の例のように、個々にフォーカスしていくとイメージしやすくなるため、下記のように単語を組み合わせて使うことも多いと思います。
- 社会インフラ
- 通信インフラ
- 産業インフラ
- 交通インフラ
- ITインフラ
”インフラ”と単体で言うと抽象的で性質上捉えどころがないイメージですが、上記のように単語を組み合わせて使用することである程度範囲が限定されてイメージがしやすくなります。
2. システム＝アプリケーション＋インフラ（ITインフラ）
本連載で解説するのは上記で言うITインフラですが、それでは“システムにおけるインフラ”、ITインフラとは何を指すのでしょうか。「分けることは、分かること」とはよく言いますが、ここでインフラの構成要素を少し分解しながら見ていきたいと思います。
システムを要素分解すると第2階層、「アプリケーション」と「インフラ」に分けることができます（図1）。道路のくだりを思い出してほしいのですが、この場合はアプリケーションを車、インフラを道路にたとえることができます。アプリケーションを動作させるための下部構造をインフラが提供しているのです。
図1：システムの要素を分解した第2階層
ここで、本筋からはズレますがアプリケーションについて補足します。例えば、八百屋の販売業務をシステム化する際には、まず野菜を販売する人が行っていることを理解する必要があります。領収書が必要と言われて発行する時もあれば、買物客の献立を聞いておすすめ（レコメンド）することもあるでしょう。そのようなすべての起こりうる業務や処理をJavaなどのプログラム言語を使用して事前に作りこんだものがアプリケーションです。通常は業務ごとにカスタマイズして作りますが、世の中の様々なありふれた業務はすでにパッケージ（製品）が提供されていることもあります。
もともとアプリケーションは「アプリケーションソフトウェア（応用ソフトウェア）」の略でソフトウェアの一種ですが、ここでは「業務やサービスに合わせて個別に作るもの」というイメージで理解しておいていただければ良いと思います。
3. インフラ＝ハードウェア＋ソフトウェア（システムソフトウェア）
まだ分かりにくいと思いますので、もう少し要素分解していきます。さらにインフラを要素分解すると第3階層、「ハードウェア」と「ソフトウェア（システムソフトウェア）」に分けることができます（図2）。本連載を読んでいるインフラエンジニアを目指す皆さんは、この両方をしっかり理解することが求められます。
図2：システムの要素を分解した第3階層
4. ハードウェア
昨今インフラエンジニアが扱う代表的なハードウェアには、下記のものがあります。
- パソコン
普段慣れ親しんでいる個人使用を前提としたコンピュータ。業務で導入する場合は、台数が多いこともあり個別にセットアップするのではなく、ひな形となるものを数種類作成し、それを複製するといったことが行われる。 - サーバ
24時間365日稼働、高速処理といった要件のシステムで使用するため、パソコンに比べて様々なパーツが高速化、冗長化されているコンピュータ。数十万円～数千万円のものがよく使用される。また、最近では「仮想化」や「クラウド」といった環境で使用される仮想サーバを扱うケースも増えてきている。 - ストレージ
年々肥大化するデータの格納やデータを高速に読み書きするといった要件に合わせたデータ保存に特化した機器。大容量化、高速化、耐障害化が施されており、高いものでは一式数億円といったものも珍しくない。 - テープ
災害等に備えて、主にバックアップデータをテープに保管するシステムで使用する。最近ではLTO（Linear Tape-Open）といった規格により読み書き性能が向上してきている。 - ネットワーク
パソコンやサーバ、ストレージなどを相互に接続したり、通信を制御したりするための機器。
余談ですが、弊社が関わる大規模システムは10～30人くらいのインフラエンジニアで作っていくことが平均的ですが、この規模になるとサーバ系に強い人はサーバエンジニアとしてサーバを担当し、ネットワークに強い人はネットワークエンジニアとしてネットワークを担当する、といった分業制になることが多くなります。
また、上記以外にもハードウェアを設置するための「ラック」や電源まわりに関する話題を扱うこともあります。電源や荷重などの機器仕様を考えながらラックへの搭載位置を設計したり、機器の搬出入や各種工事を調整したりなど、大きなプロジェクトになると専任で複数名が必要になるくらいの仕事量になります。この作業に当たるエンジニアはインフラエンジニアの中でも特に「ファシリティエンジニア」と呼ばれたりします。
ラックとは
企業のシステムは通常、データセンタや企業内のサーバルームに設置されますが、その際に「効率良くハードウェアを設置できるように」と規格化された収納製品のことです。通常は大型冷蔵庫のような大きさがあり、設置したい機器を支柱などに固定して収納していきます（図3は弊社の研修室に設置されたラック。研修用のサーバが整然と収納されている）。
図3：BFT社内の研修室に設置されたラック
5. ソフトウェア
一方、インフラエンジニアが扱う代表的なソフトウェアには、以下のものがあります。
- OS
アプリケーションやミドルウェアが共通で使用する機能を集めて提供するソフトウェア。例えば、画面出力や通信機能、各アプリケーションやミドルウェア間のリソース調整機能などを提供する。 - ミドルウェア
OSとアプリケーションとの間に存在するソフトウェア。世の中のアプリケーションが共通して使用するものに特化して機能を提供する。例えば、アプリケーションサーバ製品であればデータベースとのコネクション管理機能などを提供することで、アプリケーション側でそれらの機能の実装を最小限にできる。
こうして見るとあっさりしていますが、さらに要素分解すると実際には多くの種類のソフトウェアがあります。OSであれば「Windows Server」や「Red Hat Linux」や「Ubuntu」などのLinux、「HP-UX」や「AIX」などのUNIX、ミドルウェアであればアプリケーションサーバ製品やデータベース製品などがあります。ミドルウェアの場合は「WebLogic」や「Oracle Database」といった製品名を聞いた方がピンとくるかもしれません。
6. 結局“インフラ”とは何なのか？
ここまで解説した内容をまとめると、インフラとは多くの要素で成り立っていることが分かります（図4）。改めて“インフラ”という領域の広さと奥深さを実感すると思います。これらの要素は技術革新により日々バージョンアップされ、また要素自体が追加されたり減少したりするため、インフラエンジニアは常に世の中にアンテナを張り巡らして勉強し続けています。
図4：インフラは多くの要素で成り立っており、その領域の広さと奥深さが実感できる
今回は各要素や専門用語等について細部まで解説しませんでしたが、次回以降は下記の予定で詳しく解説していきます。
第2回：サーバ
第3回：ネットワーク
第4回：仮想化、クラウド
第5回：ミドルウェア（Web、AP、DB）
第6回：ミドルウェア（システム運用）
第7回：構築とテスト
第8回：インフラエンジニアの仕事
本コラムでは、連載を通してインフラエンジニアが関わる「プロジェクト」に注目して、さまざまな側面から解説していきます。
システムを作ることが決まると「プロジェクト」が発足されます。このプロジェクトの進め方にはいくつか方法がありますが、日本における大規模システムでは「ウォーターフォール型」を採用しているプロジェクトが多数派を占めます。2017年現在で弊社が携わるプロジェクトもほとんどこの型です。
ウォーターフォール型開発とは、誤解を恐れずに書けば「計画をしっかり立てて1回で完成品を作ろう」とするやり方です。カレー作りに例えると、食べる人達の食材や味付けの好みをしっかりとヒアリングし、材料や作業を漏れなく設計して作っていくやり方です。メリットはカレーを提供できる時間やコストを事前に把握できることですが、デメリットは材料が足りなかったり作業が遅れたりした時に弱いことです。
ユーザー企業からすると事前に予算やコストが分かるので、上司や役員に報告しやすく都合が良いという側面があるのもメリットと言えるでしょう。
しかし、1人で作るカレーなら漏れなく計画できそうですが、何千人も関わって作る大規模なシステムならどうでしょうか。実際にプロジェクトの終盤になって「必要な作業が計画されていなかった」とか「この日数では作りきれない」、「できると宣言したけどできなかった」といったことが起きています。
これらのメリットやデメリットをどのように捉えるかで、ウォーターフォール型に批判的な考えもあります。できるインフラエンジニアはこのようなことが少なくなるように知識や経験を積んだり、普段から色々なプロジェクトの情報を仕入れたり、自分で事前に検証したりしています。
（第2回へ続く）
システムにおけるインフラ
1. クライアント・サーバシステム
ここまで、インフラについて大まかに理解できたのではと思います。ここからは実際のシステム構成を見ながら、もう少しイメージを膨らませていきましょう。
図5は、企業における一般的なシステム構成です。様々なコンピュータがそれぞれの役割を担いながら、相互に接続することで1つのシステムが成り立っています。
図5：企業における一般的なシステム構成図
まず特筆すべきは、「クライアント」と「サーバ」に役割が分かれている点です。システム利用者が使うコンピュータであるクライアントと、サービスを提供するコンピュータであるサーバに分けて、相互にネットワークで接続する形をとっています。このような構成を「クライアント・サーバシステム」と呼びます。皆さんがこれから関わるシステム構成もこの形が多いのではと思います。
2. Webシステム
クライアント・サーバシステムの中でも、最近ではさらにクライアント側のソフトウェアとして「Webブラウザ」を使用するシステムが主流となっています。一昔前まではクライアント側に専用のクライアントアプリケーションをインストールして、サーバ側のアプリケーションと通信するといったシステムが主流でした。インターネットの普及とともにWebブラウザの汎用性や画面表示能力が上がってきたため、クライアントソフトウェアとしてWebブラウザを使用するシステムが選択されるようになってきています。
私がまだ新人の頃に某銀行のシステム更改に携わったことがありますが、行員が使用する数千台のパソコン（クライアント端末）に専用のクライアントソフトウェアをインストールして設定し、サーバとの通信を確認するという単純作業を休日3日返上で実施したことがあります。現在ではWebブラウザがデフォルトでインストールされているので、このような作業は不要になりました。
3. Web3層構造
「Web3層構造」とはWebシステムの典型的な構成であり、下記の3つの役割のサーバから成り立っています。
- Webサーバ
主に静的コンテンツを提供する役割のサーバ。HTMLファイルや画像などのコンテンツを配置して、APサーバから提供された動的コンテンツとともに表示を行う。 - APサーバ
主に動的コンテンツや業務処理を提供するサーバ。このサーバ上にアプリケーションを実装することが多い。 - DBサーバ
データを提供するサーバ。主にAPサーバからのデータ要求に従ってデータを返す。性能を求められるケースが多いためサーバ自体も性能の高いものにする、扱うデータ量が多いためストレージを接続する、などの使い方が一般的。
システムによってはWebサーバとAPサーバを1台に統合したり、Webサーバがなかったりなどしますが、基本的には上記の3層でクライアントからの処理に対応する構成をとります。
弊社が行っているLinuxでWeb3層システムを構築する研修では、実際に3台のサーバと1台のストレージを使用しています。各サーバの役割は受講者が決めることができるので、OSをインストールする際は図6のように付箋で目印をつける人もいます。実際にはデータセンタに置かれているサーバにはテプラを使用したきれいな識別テープを貼るのですが、テープをインフラエンジニアが作成することもあり、普段の頭を使う仕事から離れて妙に単純作業に没頭してしまうといった話はインフラエンジニアあるあるかもしれません。
図6：各サーバーの役割を示す付箋の目印
4. システムにおける“インフラ”とは
上記の3つのサーバを中心に、さらにユーザー認証が必要なシステムであれば「認証サーバ」や監視・ジョブ管理などを行う「運用関連サーバ」などが周辺を固めていきます。また、それぞれのサーバを接続したり、アクセスを制御したりするために各種のネットワーク機器やセキュリティ機器が配置されていきます。
このように、インフラエンジニアは上記のハードウェアやソフトウェアの設計・構築を行い、アプリケーションが動く“インフラ“を提供しています。
おわりに
今回は、第1回として“インフラ全般”をテーマに全体を広く浅く解説しました。今回の内容を読んで、インフラが扱う領域の広さに期待と不安が入り混じった感情をおぼえたのではと思います。本連載を通じて現場の状況等も加味しながら、そのような不安を少しでも解消できるように分かりやすく解説していきます。
次回は、インフラエンジニアにとって切っても切り離せない”サーバ”をテーマに解説します。併せてストレージやOSについても解説しますので、楽しみにしていてください！
