【図解】ストレージの基本完全ガイド｜物理（SAN/NAS）から仮想化・クラウドへの進化と現場の罠

「クラウド時代だから、物理ストレージの仕組みなんて知らなくてもいいでしょ？」

もしそう考えているなら、それは大きな誤解です。AWSやAzureといったクラウドサービスの上で動くストレージも、その裏側（物理層）ではオンプレミス時代から培われてきたアーキテクチャがそのまま息づいています。

基礎を知らないまま設計・運用を続けると、思わぬ性能劣化や、予期せぬ「容量パンク」の罠に陥る大失敗を招きかねません。

この記事では、大手SIerで18年間インフラ運用に携わってきたプロの視点から、サーバーとストレージの物理的関係、SAN/NASの違い、仮想ボリューム技術、そしてクラウドへのつながりまでを現場のリアルな失敗談を交えて徹底解説します！

そもそもなぜサーバーとストレージを分けるのか？

私たちが普段使っているパソコンは、データを処理する「CPU・メモリ」と、データを保存する「SSD・HDD」がひとつの箱に収まっています。しかし、エンタープライズ（企業向け）の大規模システムでは、計算を行う「サーバー」と、大量のデータを貯める「ストレージ（専用筐体）」を物理的に切り離して設置するのが一般的です。

なぜ、わざわざ高価な専用機器を使って分けるのでしょうか？それには、大規模運用に欠かせない3つの圧倒的なメリットがあるからです。

1. リソースの集約と柔軟な割り当て

サーバー内にディスクを内蔵してしまうと、「Aサーバーは容量がパンク寸前なのに、Bサーバーはスカスカ」という無駄が発生します。ストレージを独立させて巨大な「データのプール」を作ることで、必要なサーバーに必要な分だけ容量を柔軟に切り分けて渡すことが可能になります。

2. データの共有（高可用性システムの実現）

複数のサーバーから同じストレージ領域を同時に見せることが可能になります。これにより、万が一ひとつのサーバーが物理的に故障して停止しても、別の待機サーバーが即座に同じストレージのデータを引き継いで処理を継続する「クラスタ構成（高可用性構成）」が組めるようになります。

3. 高度なデータ保護と運用性の向上

専用のストレージ筐体には、ディスクが故障してもデータを失わない「RAID技術」や、一瞬でバックアップを作成する「スナップショット機能」がハードウェアレベルで備わっています。サーバーのOSやハードウェアのメンテナンスを行う際も、データ領域に影響を与えずに作業を進められるため、運用効率が劇的に向上します。

RAID技術について詳しく知りたい方は以下の記事もチェックしてみてください。

どう繋ぐ？ストレージ接続方式の3大分類（DAS・SAN・NAS）

サーバーとストレージを切り離すということは、それらを何らかの方法で「接続」しなければなりません。実務で登場する接続方式は、大きく分けて「DAS」「SAN」「NAS」の3種類です。ここの違いを整理することが、インフラエンジニアとしての第一歩です。

接続方式	概要	主な接続プロトコル/ケーブル	主な用途・特徴
DAS (Direct Attached Storage)	サーバーに1対1で直接接続する方式。	SAS、SATA、NVMe	単一サーバーの高速ローカル領域。共有はできない。
SAN (Storage Area Network)	ストレージ専用の高速な独立ネットワークを構築する方式。	FC (Fibre Channel)、iSCSI	データベースなど、超高速・低遅延・高信頼性が求められる基幹システム。
NAS (Network Attached Storage)	一般的な社内LAN（IPネットワーク）に接続する方式。	NFS、CIFS/SMB (イーサネット)	ファイルサーバーなど、複数のサーバーやPCから手軽にファイルを共有する用途。

「ストレージ専用道路」を通るFCと共通言語「SCSI」

大規模システムで最もよく使われるのはSANです。なかでも主に光ファイバーを用いたFC（ファイバチャネル）と呼ばれる専用の線とスイッチでネットワークを構築します。

これは一般的な社内LANのトラフィックと完全に分離された「ストレージ専用の高速道路」であるため、大量のデータ転送が発生しても遅延（レイテンシ）が極めて低いのが特徴です。

この高速道路を通ってサーバーとストレージが会話するための共通ルール（規格・プロトコル）がSCSIです。サーバーが「○番地のセクタにあるデータを読んで！」「はい、了解！」とやり取りするブロックレベルの通信は、これらの言語で行われています。

限られた資源を限界まで活かす「仮想ストレージ」の魔法とリアル

物理的に繋がった巨大なストレージの塊（筐体）ですが、そのままではサーバーから利用できません。そこで、物理ディスクを論理的に切り分けた「仮想ボリューム（LUN：Logical Unit Number）」を作成し、必要なサーバーに割り当てます。この仮想化をさらに進化させ、限られたリソースを限界まで使い倒すための魔法の技術が「シンプロビジョニング」と「重複排除」です。

魔法の容量水増し術「シンプロビジョニング」

通常、サーバー担当者から「100GBのボリュームが欲しい」と言われたら、物理的にも100GBのディスクを確保して割り当てます（シックプロビジョニング）。しかし、実際には構築初期段階では10GB程度しか使わず、残りの90GBは長期間「空き地」のまま眠ってしまうことが多々あります。

そこで登場するのがシンプロビジョニングです。これは、サーバー側には「100GBの空き容量があるよ」と嘘をついて見せかけつつ、物理ストレージ側では実際にデータが書き込まれた分（例：10GB）だけを消費していく技術です。これにより、初期投資を抑えたスモールスタートが可能になり、ディスクの利用効率が劇的に向上します。

🔴【実録】プロが冷や汗をかいた、現場の「物理ディスク枯渇」の恐怖

インフラの利用効率を高めてくれるシンプロビジョニングですが、私は一度、この技術の「影」の部分で生きた心地がしない経験をしました。

当時、複数のシステム担当者から「容量が足りなくなりそうなので拡張してほしい」という要望が相次いでいました。「シンプロビジョニングだから、見せかけの容量を増やしても物理ディスクがすぐ減るわけじゃない。はい、どうぞ！」と、将来の厳密なキャパシティ管理を怠ったまま、二つ返事で仮想ボリュームを大盤振る舞いしてしまったのです。

結果、ある月の夜間バッチ処理やデータ移行が重なり、複数のシステムが一斉に本気でデータを書き込み始めました。「見せかけの容量」を物理的な限界を超えて割り当てていた（オーバープロビジョニング）ため、ある日突然、物理ストレージ全体の空き容量が残り数％まで底をつきかける緊急事態に発展したのです。もし100%に達すれば、すべてのシステムが同時に書き込みエラーを起こし、データベースが破損してシステムが全面停止する大惨事になるところでした。

【どう対処したか？】

ハードウェアの追加発注には数週間かかるため、一刻の猶予もありませんでした。すぐに各システムのアプリ担当者と連携し、以下の緊急大掃除を断行しました。

1. 長年放置されていたテンポラリファイルや古いログの完全削除
2. データベース内の不要領域のクリーンアップ（インデックス再構成等による容量解放）

これでなんとか数GBの物理空き容量を絞り出し、物理ディスクの増設キットが届くまで首の皮一枚で持ちこたえることができました。

この時私は、便利なスペックや機能に甘えるだけでなく、「物理リソースの限界を管理する重要性」、そして「インフラ側だけでなくアプリやデータの持ち方まで踏み込んで最適化してもらう重要性」を骨の髄まで痛感しました。

さらに容量を節約する秘密兵器「重複排除」

シンプロビジョニングとセットで導入されることが多いのが重複排除（Deduplication）です。これは「中身が完全に同じデータブロックなら、ストレージ内には1つだけ保存して、あとはポインタ（参照情報）だけを記録する」という技術です。

例えば、50台の仮想サーバーがあり、それぞれに同じWindows OSがインストールされているとします。通常ならOSのシステムファイルだけで膨大な容量を消費しますが、重複排除を有効にすると「これ、全部同じデータだね」と自動検知され、物理ディスクに書き込まれるのは実質1台分＋αの容量だけで済みます。特に同じようなファイルが大量に作られるVDI（デスクトップ仮想化）環境などでは、ストレージ容量を7〜8割も削減できるほどの劇的な効果を発揮します。

クラウド時代への架け橋｜オンプレミスとクラウドストレージの対応関係

現代のシステム開発はクラウドファーストが主流ですが、ここまで説明してきた「オンプレミスのストレージ設計思想」は、形を変えてクラウドにもそのまま適用されています。AWS（Amazon Web Services）を例に、その対応関係を見てみましょう。

• ブロックストレージ（SANに相当） ➔ AWSでは「Amazon EBS」EC2サーバーに1対1で接続し、OSやデータベースをインストールする高速・低遅延な領域。裏側では、ネットワーク（SANに類似した環境）経由で仮想ボリュームが切り出されてサーバーに提供されています。
• ファイルストレージ（NASに相当） ➔ AWSでは「Amazon EFS」複数のEC2サーバーから同時にマウントして、共通のファイルを読み書きできる領域。まさにオンプレミスのNFS/NASそのものの挙動をクラウド上で実現しています。
• オブジェクトストレージ（クラウド特有の広大な保管庫） ➔ AWSでは「Amazon S3」ファイル単位ではなく「オブジェクト」としてデータを扱い、インターネット経由でAPIを使って読み書きするストレージ。オンプレミスの概念にはない、クラウド時代に爆発的に普及したフラットで無限に近い拡張性を持つストレージです。

クラウドを使う場合でも、「このシステムはIOPS（引き込み性能）が必要だからEBSのタイプを調整しよう」「複数サーバーでファイル共有したいからEFSにしよう」といった判断を下すには、物理ストレージや接続方式の基礎知識が絶対に欠かせないのです。

まとめ：技術の「光と影」を理解し、現場で信頼されるエンジニアへ

今回ご紹介したシンプロビジョニングや重複排除、クラウドストレージは、限られたリソースを最大限に活用し、ビジネスを加速させるための「魔法の技術」です。しかし、その魔法を安全に使いこなすためには、エンジニアが以下の視点を持つことが大切です。

1. 「仕組みそのもの」の裏側を理解する便利なGUIツールを使えば、中身を知らなくてもストレージの切り出しはできてしまいます。しかし、トラブルが起きたとき、あるいはキャパシティ設計を行うときに差が出るのは、裏側でデータがどう動いているかという「構造の理解」です。
2. デメリット（影）から目を背けないどんなに便利な技術にも、必ずトレードオフ（デメリット）が存在します。シンプロビジョニングによる物理枯渇リスク、重複排除によるコントローラーのCPU負荷や性能への影響など、「光」の部分だけでなく「影」の部分をセットで理解して初めて、プロの設計と言えます。
3. システム全体を俯瞰する視点を持つ「自分はインフラ（ストレージ）担当だから、アプリやDBの中身は関係ない」という壁を作ってはいけません。実録で紹介したように、インフラの危機を救うのはアプリ側のクリーンアップだったりします。広い視野を持つことで、真に頼られるインフラエンジニアを目指していきましょう！

ストレージの基本をマスターしたら、次はさらに実務に直結する「RAID構成の選定基準」や「バックアップ・スナップショットの運用のリアル」について学んでいきましょう。現場で生き抜くための実践的な知恵を別記事でも詳しく解説していますので、ぜひチェックしてみてください！

ストレージに関連して、RAID構成やバックアップ、スナップショットの記事もあります。気になる方はチェックしてみてください。