本記事は『バックエンドエンジニアのためのインフラ・クラウド大全』（著者：株式会社X-Tech5、馬場俊彰）の「第1章 情報システムとインフラの基礎知識」から抜粋したものです。掲載にあたって編集しています。
情報システムとインフラの基礎知識
まずはシステム全体の基本的な構造について話します。
いわゆるシステム構成図はシステムを上から見た構成を表しています。もちろん論理的なものもありますから上も下もないと言えばないのですが、筆者はシステム全体を俯瞰するイメージから上からと言っています。
従前からウェブシステムの構成は複数の構成要素が関連するものでしたが、クラウドサービスの普及、フロントエンドアプリケーションの高度化、モバイルアプリケーションの登場でよりいっそう構成要素が増えました。サーバーサイドレンダリングやGraphQL / REST変換が必要なフロントエンドアプリケーションを持つシステムの構成要素は典型的には次のようになります。
実際の構成ではサーバーサイドレンダリングがなくBFFがなかったり、静的コンテンツ保持とウェブサーバーとBFFとモバイルAPIゲートウェイを同居したりといった複雑化と簡素化のバランスをとる試みが行われます。
バックエンドエンジニアがどの要素のどの部分を領域とするかは現場ごとに異なります。ブラウザー、静的コンテンツを配信するウェブサーバー、BFFはフロントエンドエンジニアで、モバイルAPIゲートウェイとアプリケーションサーバーより後ろはバックエンドエンジニアというパターンもあれば、フロントエンドエンジニアはブラウザーがメインでその他はバックエンドエンジニアというパターンもあったりします。本書ではバックエンドエンジニアが主に扱う領域は、アプリケーションサーバーを中心に広げていくものと仮定します。
ジュニアレベルであればまずはアプリケーションサーバーで稼働するプログラムとそこから直接利用するデータベースやKVS、オブジェクトストレージ、そしてそれらを直接利用するロードバランサーやモバイルAPIゲートウェイ、BFF、それらの手前のロードバランサー、CDNなどに守備範囲を順次広げていくものと想定します。
一方で技術要素を横から見るとそれぞれを構成する階層が見えてきます。それぞれのサーバーは典型的には以下のような階層構造になっています。詳しくは後々に学習していくので、いまのところは「階層構造になっているんだな」「この単語は聞いたことがあるぞ」というレベルで眺めておいてください。
バックエンドエンジニアから見ると「自分たちが書いたアプリケーション以外は全部インフラという感じだと思いますが、実は中はいろいろと分かれています。学習を進めていくとそれぞれの階層の仕組みがわかってきます。
ほとんどの場合はそれぞれの階層の中も階層化されています。たとえば、上記のうちOSに着目すると典型的には以下の階層構造になっています。全体の階層構造と重複する部分がありますが詳細は書籍で紹介します。ここではLinuxを前提に扱います。
またネットワークは典型的には以下のような階層構造になっています。
学習を進めてシステム全体の解像度を高めていくと、トラブルシューティングやパフォーマンスチューニングなど総合力が必要なシーンで大変役に立ちます。楽しみですね。
なおここではウェブサイト、ウェブサービス、ウェブシステムをおおむね以下のように呼び分けることとします。
- ウェブサイト：ウェブを通じて主に情報を提供するもの
- ウェブサービス：ウェブを通じて主に機能を提供するもの
- ウェブシステム：ウェブサイトやウェブサービスを実現するためのコンポーネント群
サーバーとは何か
ところでサーバーという言葉を確認します。よく聞くけれど、前述の「表：システムの階層構造」のスタックに登場していません。
サーバーは「何らかの機能を提供（Serve）する主体の、ハードウェアないしソフトウェア」です。
アーキテクチャにおいてウェブの機能（ここではクライアントからのHTTP通信を受け付けて応答する動作を実現すること）を提供する役割を持つ構成要素をウェブサーバーと呼びます。アーキテクチャ視点でのウェブサーバーの中でウェブの機能を提供するソフトウェアもウェブサーバーと呼びます。あるいはウェブの機能を提供するソフトウェアを動かす機器のこともウェブサーバーと呼びます。ややこしいですね。
呼び分ける場合は、ソフトウェア部分だけを指すときにはウェブサーバープログラムやウェブサーバーアプリケーション、ウェブサーバーミドルウェアと呼びます。物理機器部分や物理機器相当の仮想機器ソフトウェア部分だけを指すときにはウェブサーバー機器やウェブサーバーVM（ブイエム：Virtual Machine）、ウェブサーバーインスタンスと呼ぶことがあります。
常時稼働して要求に対する処理を行うプログラム動作形態をデーモン（Daemon）と呼ぶので、ウェブサーバープログラムはデーモンとして動作することが多いです。何らかの機能を提供する主体としてのサーバーの話に戻ります。わたしたちがサーバーを利用する場合は以下のパターンがあります。執筆時点の2025年前半ではクラウドサービスを利用して論理的なハードウェアを借りるパターンがほとんどです。
- 物理的なハードウェアを（買って｜借りて）、（自宅｜オフィス｜データセンターなどの専門施設）に設置する
- 論理的なハードウェアを借りる｜（所有する｜借りた）ハードウェアに建てる
具体例：
- 物理的なハードウェアを買って、オフィスに設置する → HPEのProLiantを買って、オフィスのサーバールームに設置する
- 物理的なハードウェアを借りて、専門施設に設置する → さくらインターネットの「さくらの専用サーバ PHY」を利用する
- 論理的なハードウェアを借りる → さくらインターネットの「さくらのVPS」を利用する、AWSの Amazon EC2を利用する
- 論理的なハードウェアを借りたハードウェアに建てる → さくらインターネットの「さくらの専用サーバ PHY」でKVMを利用する
ちなみにいわゆるサーバーレス（Serverless）は、基本的な構造は論理的なハードウェアを借りるパターンです。このパターンをベースに、いい感じユーザーの利便性が高くなるようパッケージングしたものをサーバーレスと銘打っていることが多いです。
情報システムの価値は有用性と保証
受託開発の観点だと、要求された機能要件と非機能要件を満たすという考え方になりがちです。しかしウェブサービスをはじめ多くの情報システムの存在意義は、それを作りたい人の願いを実現することではなく、システムのユーザー（利用者）に価値を提供することです。直感的に価値と言うと考え方はいろいろありますが、有用性と保証の2つの観点で考えるとわかりやすいです。
- 有用性：生産性の向上を実現する機能や、不可能を可能にする機能を提供すること
- 保証：安心や信頼を実現して提供すること
有用性と保証それぞれについて詳しく見ていきます。
有用性：生産性の向上を実現する機能や、不可能を可能にする機能を提供すること
生産性の向上を実現する機能を提供することは、その情報システムを利用することで作業工程の削減や、所要時間の短縮を実現することです。
例：大量の帳簿から、特定の日時・店舗の売上情報を取得する
生産性の向上は非常にわかりやすいIT活用の例です。電子化やデジタル化とも呼ばれます。いままでのやりかたの延長線上で、実現手法を変えて省力化や時短などの効率向上を実現します。ステップアップするイメージです。
一方不可能を可能にする機能を提供することは、その情報システムを利用することでいままでは実現不可能だったことを可能にすることです。
例：一般家庭でペットのリモート見守りを実現する
発明・発見の要素が大きく、たいていは何らかの変革を伴います。デジタルトランスフォーメーション（DX：Digital Transformation）とも呼ばれます。いままでのやりかたをやめて、延長線上にない新しいやりかたを取り入れて、ジャンプアップするイメージです。
ユーザー価値の有用性要素は、システムを開発する段階になると、主に機能要件という形で具現化します。しかしユーザー価値を実現するためには有用性要素だけでなく保証要素も不可欠です。有用性要素と保証要素は両輪であり、したがって機能要件と非機能要件はどちらも不可欠です。
安心や信頼は主観的な側面が強いものですが、しかし欠かせないものです。
ユーザーからの期待値がベースラインです。ユーザーからの期待値は、価格、ブランディング、そのサービスの業種や扱う情報の特性などにより大きく異なります。
たとえば、消しゴムの感想を扱うシステムと健康情報を扱うシステムでは、社会的に求められる安心や信頼の内容や水準、方向性が異なります。もちろん健康情報を扱うシステムのほうが一般にユーザーからの期待値が高く、ユーザーからは提供者がコンピューターシステムのプロフェッショナルであるだけでなく健康情報を扱うプロフェッショナルでもあることが期待されます。
安心や信頼を考えるうえで代表的な観点は以下のとおりです。
- 信頼性（Reliability）：サービスが期待どおりに動作し続けること
- 可用性（Availability）：サービスが利用可能であること
- キャパシティ（Capacity）：サービスが利用を量的に受容できること
- パフォーマンス（Performance）：サービスが快適に利用できること
- セキュリティ（Security）：サービスが安全に利用できること
- 持続性（Sustainability）：（経済的・社会的・環境的な観点や、平常時・災害時など状況変化を考慮したうえで）サービスが長期的に健全に存続できること
他には耐久性（Durability：故障しづらいこと）、回復性（Resiliency：故障したとき速やかに回復すること）、移植性（Portability：異なる動作環境や基盤に移行しやすいこと）、保守性（Maintainability：迅速安全に容易に効率よく、変更しやすいこと）、運用性（Manageability：迅速安全に容易に効率よく、運用しやすいこと）、拡張性（Scalability：迅速安全に容易に効率よく柔軟に、性能や容量を拡張できること）、継続性（Continuity：不測の事態が起きても継続して利用できること）、コンプライアンス（Compliance：迅速安全に容易に効率よく法規やルールに準拠し、またそれを維持・証明できること）などの観点があります。
ユーザー価値の保証要素はシステム開発の段階になると、主に非機能要件という形で具現化します。繰り返しになりますが、機能要件・非機能要件いずれも、有用性と保証を、すなわちユーザー価値を実現するために欠かせないものです。
非機能要件についてはIPA（情報処理推進機構）の非機能要求グレードが参考になります。
またシステムの保証要素を総合的に考える枠組みとしてRAS（Reliability：信頼性、Availability：可用性、Serviceability：保守性）やRASIS（RASに加えてIntegrity：完全性、Security：機密性）があります。
それぞれ参照する基準によって微妙に表現やカバー範囲が異なります。ユーザー価値の保証要素を実現することに技術的観点だけでない困難が伴い、それを解決することが難しく、すなわちその実現はプロフェッショナルとしての価値になるということの表れでもあります。
たとえば、信頼性は非常に広い概念です。信頼性の実現は2010年代後半からとくに注目されています。GoogleによりSRE（エスアールイー：Site Reliability Engineering：サイト信頼性エンジニアリング）が提唱され、本書『バックエンドエンジニアのためのインフラ・クラウド大全』を執筆している2025年時点で広く普及しています。SREについて詳しくは本書で紹介します。
インフラを設計するときに考えること：物理的な限界を超える！
繰り返しになりますが、情報システムでユーザー価値を実現するには、有用性と保証を実現しなければなりません。このうち、とくに保証はインフラによって下支えされ、また達成可能水準の上限が決まることが多いです。高い水準の保証はインフラ領域での技術的な工夫によって物理的な限界を超えることで実現できます。
たとえば、利用可能であることを表す可用性の限界について考えます。どんなものも必ずいつかは、ほとんどの場合は突然に壊れます。したがって、サーバーが1台しかない場合は必ずいつかは、そのサーバーが突然壊れ、そのサーバーで提供していたサービスが突然停止します。しかし複数のサーバーを用意して2つ同時に利用できれば、1つのサーバーの可用性の限界を超えられます。
これは会計レジが1台のコンビニだとその会計レジが壊れると、会計レジが直るまでコンビニのレジ業務が全停止しますが、会計レジが2台あれば残りの1台でレジ業務が継続可能になるのと同じ理屈です。またデータを保存するディスクは必ずいつかは壊れます。しかし同じデータを複数のディスクに保存しておけば、1つのディスクの持続性の限界を超えデータ損失を避けられます。
たとえば、キャパシティやパフォーマンスの限界について考えます。1つのCPUで1秒間に計算できる回数は上限があります。どんなにお金を出しても本書執筆時点（2025年4月）で入手可能なCPUのクロック数は3～5GHz程度です。
しかしCPUを複数用意して処理を分担すれば、1秒間に計算できる回数を増やし、CPUクロック数の上限を超えられます。ディスクやネットワークの読み書き速度や領域サイズも、複数用意して分担すれば1つあたりの性能限界を超えられます。
これはコンビニの会計レジ1台で10分あたりに対応できる客数で考えると、1台あたりの店員アサインを増やしても2～3人で効率化は上限になりますが、会計レジを複数台用意すると会計レジ1台では達成できない10分あたり対応客数を達成できるのと同じ理屈です。
たとえば、持続性の限界について考えます。経済的な側面としてコストパフォーマンスは重要です。可用性・パフォーマンス・キャパシティ・セキュリティ・持続性を実現するには大なり小なりコストがかかります。目指す実現レベルと必要な金銭・工数投資のバランスが崩れると、遠からずサービスが提供できなくなりますから、コストパフォーマンスも持続性を支える重要な要素です。
もちろんこれらを実現するためには前提条件や制約事項、技術的課題が多々あります。多くの場合はインフラ領域でのエンジニアリングは十分条件ではなく必要条件ですから、インフラ領域だけでは解決できない場合が多く、アプリケーションプログラムの作り方が前提条件になることが多々あります。物理的な限界を超えていくところが、インフラ領域を含めたエンジニアリングの大きな魅力です。
インフラの設計を考えることは、構成要素ごとに物理的な限界を超えるための工夫を積み重ねることです。インフラ設計を理解ないし実践するためにはアーキテクチャの階層構造と構成要素を知ることと、それぞれの構成要素の特性を理解し物理的な限界を知ることから始めるとよいです。
システムは階層構造になっている
バックエンドエンジニアの視点で、管理者ごとにざっくり見ると、アプリケーション／アプリケーションライブラリー（サードパーティーライブラリー）／インフラ、くらいの見え方でしょう。
- アプリケーション：自分たちで、PythonやTypeScriptで書くやつ
- アプリケーションライブラリー：pipやnpmでインストールするやつ
- インフラ：それらを動かすための諸々
このうちインフラを詳しく見ると、おおまかに以下のような階層があります。詳しくは本書を通じて学んでください。なお前述のとおり、これらのそれぞれも、中を詳しく見ると階層化されています。たとえば、ネットワークの階層構造について階層モデルという言葉を聞いたことがあるかもしれません。
ある階層が十分に機能するためには、それより下の階層が十分に機能していなければなりません。
階層が低いほうを、俗に低レイヤー（Low Layer）と呼びます。低レイヤーであるほど物理法則の影響を受けます。建物がなければ機器が置けず、電気がなければ機器が動かず、ハードウェアがなければシステムが動かず、ケーブルの長さが足りなければ接続できません。とくに低レイヤーでは、温度・湿度・騒音・振動など物理的な事象が動作不良につながりやすくなります。
まず以下のことは覚えておいてほしいです。
- ユーザーに価値を届けるためには全部が必要
- ユーザーのことを考えると、自分に関係がないことはない
ここでは階層構造をきれいに例示しましたが、実際にはそれぞれの階層は直列ではなく複雑に支え合っていて、階層をまたぐ依存関係があったり、垂直統合していたりといろいろなプロダクトがあります。パフォーマンスやセキュリティの実現のような技術的な理由に由来する複雑さもあれば、ベンダーの事業展開の都合のような経済的な理由に由来する複雑さもあります。
そんなわけで現実は複雑ですが、とはいえ基本的な構造を把握することは複雑さを解きほぐす手がかりになるので有用です。
階層化と互換性
階層間のやりとりは、インターフェイスを定めて行います。やりとりのためのインターフェイスを一般にAPI（Application Programming Interface）と呼びます。
インターフェイスが定まることで、それぞれの階層の実装が入れ替え可能になります。バックエンドエンジニアとしては、パソコンで書いたプログラムがサーバーで動いてくれないと困りますね。手元のmacOS上で書いたPythonプログラムがLinuxサーバーでも同じように動くのは、OSやシステムライブラリーの違いをアプリケーションランタイムであるPythonランタイムが吸収しているからです。
別の例だと、あるウェブサイトのJavaScriptがmacOS上のGoogle ChromeでもWindows上のGoogle Chromeでも同じように動作するのは、ウェブブラウザーがOS～アプリケーションライブラリーの違いを吸収しているからです。
階層の実装が入れ替え可能であることを互換性があると言います。また広く互換性があることをポータビリティ（可搬性）が高いと言います。あるプログラムのポータビリティが高いということは、そのプログラムがいろいろなところで動く・動かせるという意味です。
アプリケーションプログラムやアプリケーションライブラリーの中には、システムライブラリーやOSと直接やりとりするタイプのものもあります。PythonやRubyのプログラムを動かしたいだけなのにOSに何かをインストールしなければならないことがままありますよね。たとえば、「libxmlをインストールしなければならない」「OpenSSLが必要」などと見聞きしたことがあれば、それはシステムライブラリーを利用しているパターンです。
階層化と分担
一般にインターフェイスによって分割することで、複数人で分担しやすくなります。それぞれの領域が、それぞれ複雑な事情を抱えており、専門家が担当するのが効果的です。
それぞれの領域のエンジニアリングの専門家を○○エンジニアと呼ぶことがあります。バックエンドエンジニアやフロントエンドエンジニアがまさにそうですね。
インフラ領域では、ネットワーク階層を主に担当するネットワークエンジニア、OS・システムライブラリー・アプリケーションランタイムまでを主に担当するサーバーエンジニアなどを聞いたことがあるかもしれません。
それぞれに専門性が高いため、たとえばサーバーの中でもOSを活用することに特化したエンジニアや、OS自体を書くことに特化したエンジニアなどの分掌があります。
また、分掌を踏まえたうえで、技術スタック全体を縦断する専門性を持つことを志向したフルスタックエンジニアや、開発サイクルを横断する専門性を持つことを志向したフルサイクルエンジニアという呼び方があります。
コンピューターシステムにおけるインフラがどの階層を指すか厳密な定義はありません。少なくとも筆者は社会的に合意され広く一般に流通し採用されている定義ドキュメントを知りません。大手求人サイトの募集要項などを見ると、多くの場合はハードウェア～アプリケーションランタイムを守備範囲とすることを期待されているようです。
とはいえ、みんな自分の担当階層から下はインフラとみなすことが多いように感じます。
情報システムを構築・運用するうえでインフラが必要なわけですが、現代ではパブリッククラウドがファーストチョイス（第一に検討する選択肢）になっています。
パブリッククラウドを採用した環境があまりに多いため、多くの場合にインフラエンジニアに対する期待値の重要な要素としてパブリッククラウドの活用能力が含まれます。なお、クラウドサービスを対象とすることを強調するためにクラウドエンジニアと呼ぶことがあります。
パブリッククラウドはサービスのジャンルとしてIaaS（Infrastructure as a Service） / PaaS（Platform as a Service） / SaaS（Software as a Service）があります。これはおおまかにどの階層までクラウドサービスプロバイダーが担当するかで区分しています。
現代のシステム開発のキーワード "You build it, you run it"
ここまで階層をもとにした区切りの上モノ／足回り（インフラ）の話をしてきましたが、本節では時系列の開発／運用の話です。
You build it, you run itはAmazon CTOのWerner Vogelsさんの言葉です。
端的には開発した本人が実行（運用）せよということです。
現代のさまざまな開発や運用、プロダクト運営や改善、さらには市場競争で勝つためのさまざまなプラクティスは、このように開発と運用の壁を取り払うことが前提になっています。You build it, you run itは開発した本人自身が運用することを指していますが、程度の差はあれ開発（Dev：Developers）と運用（Ops：Operators）の壁を取り払うべきです。このようなDevとOpsの壁を取り除く取り組みをDevOpsと呼びます。
このような取り組みの背景ですが、現代はVUCA時代と言われています。VUCA（ブーカ）とはVolatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字で、変化が早く、不確実性が高く、将来予測が予測困難なさまを表しています。
情報システムは社会の中で利用されるものですから、前提条件である社会が変化したら、その変化に適応しなければなりません。予測が困難なので先取り頼みにはできず、社会の変化の中で生き残るためには社会の変化に適応し、自分たちが柔軟に迅速に変化しなければなりません。
ですから市場競争下で生き残るためには、情報システムは作って終わりとはいきません。以前は変化がそこまで速くなかったため作って終わりを繰り返してそれなりに社会環境や市場環境の変化に適応できていたのですが、現代はそうはいかなくなりました。
ユーザーのためにシステムを継続的に改善しなければならないわけですが、その際に機能開発に責任を持つ開発チームと、システムの稼働に責任を持つ運用チームに分け、両者を完全に分離することがほとんどでした。
開発した機能が有用性と保証の両面を確実に果たせれば問題はないのですが、実際には動かしてみたら有用性も保証も問題が発覚することがままあります。開発チームの主な役割をユーザー価値の有用性を実現することと位置づけた場合にはこのあとの軌道修正も開発チームが主に担うのが自然ですよね。
本書が扱うインフラ領域のエンジニアリングは、運用フェーズでは避けて通れない事柄です。実際に業務の上でその領域を担う責任を負うかは別として、You build it, you run itを胸にプログラムが動作しユーザーに有用性と保証を届けることに関連するすべてが自分に関係があることだという認識を持ち続けてください。
