インフラ

インフラとは

IT におけるインフラ (インフラストラクチャ) とは、アプリケーションやサービスを動かすための土台となる基盤全体を指す。サーバー、ネットワーク、ストレージ、OS、データベース基盤などが含まれる。アプリが「建物」なら、インフラはそれを支える「土地・水道・電気」にあたり、普段は意識されないが、止まればすべてが止まる縁の下の力持ちだ。

構成する要素

要素	役割
サーバー	処理を実行する計算機
ネットワーク	通信経路、ルーティング、負荷分散
ストレージ	データの保管
OS・ミドルウェア	アプリを動かす実行環境

これらを組み合わせ、安定して動き続ける環境をつくるのがインフラの役割になる。

オンプレミスからクラウドへ

かつてインフラは、自社で物理サーバーを購入・設置・保守するもの (オンプレミス) だった。クラウドでは同じ資源を API 経由で即座に調達できるため、構成を設定ファイルに書いて実行すれば環境が揃う。この調達方法の変化が「Infrastructure as Code (IaC)」を実務に載せた土台であり、インフラ構築は手順書を人が追う作業から、コードで何度でも再現できる対象へと変わった。

ただしクラウドへ移してもインフラの仕事が消えるわけではなく、責任の線が引き直されるだけだ。AWS は責任共有モデルとして、クラウドを動かす施設・ハードウェア・ネットワークの保護を事業者側の責任 (security of the cloud)、その上で使うゲスト OS の更新・ファイアウォールの設定・データの暗号化・権限付与を利用者側の責任 (security in the cloud) と区分している。物理層の調達と保守が減る分、設定と権限の設計に重心が移ると捉えるのが実態に近い。

求められる視点

インフラの良し悪しは、平常時には見えにくく、障害時に初めて顕在化する。そのため「壊れない設計」より「壊れても素早く復旧できる設計」、単一障害点をなくす冗長化、監視とアラートの整備が重要になる。

どこまで冗長化するかは感覚ではなく、可用性目標から許容停止時間を逆算して決める。月間 99.9% を目標に置くなら 30 日で許される停止は約 43.2 分で、人が気づいて手作業で切り替える運用では到達が難しい。99.99% (約 4.3 分) まで求めるなら自動切り替えと切り戻し手順の事前準備が前提になる。目標値を先に置けば、二重化の費用が過剰なのか不足なのかを費用対効果として議論できる。また、過剰なスペックはコストの無駄、過小なら障害の元になるため、需要に見合った構成を選ぶ判断力が問われる。地味だが、サービスの信頼性を根底で決める領域だ。

入口としては、自分が触っているシステムの構成を計算・ネットワーク・ストレージの 3 層に分けて図に描き、各層が落ちたときに何が止まるかを書き足してみるとよい。単一障害点と監視の空白が同時に浮かぶため、どの領域から学ぶべきかもそこで決まる。