RAID 1とRAID 10のパフォーマンス性能を徹底比較！用途に合わせた失敗しない構築方法をレクチャー

RAID 1とRAID 10。
この二つは、ストレージ構成を検討する際に必ず候補に上がるミラーリング系のアレイですが、その選択を誤ると、せっかくの高速ディスクやNVMeドライブの性能を十分に引き出せないばかりか、予期せぬI/Oボトルネックに悩まされることになります。

そもそもRAID 1は、単純なミラーリングによりデータを二重化する、いわば「堅牢性」を最優先した古典的な手法です。
一方のRAID 10は、ストライピング（RAID 0）とミラーリングを組み合わせたハイブリッド構成であり、速度と冗長性の両立を狙ったもの。
しかし、カタログスペック上の理論値だけで判断すると、実運用で痛い目を見るケースは少なくありません。

まずは両者のパフォーマンス特性を、下記の比較表で俯瞰してみましょう。

評価項目	RAID 1	RAID 10
シーケンシャル読み込み	単一ドライブと同等（コントローラ次第で向上可）	ストライプ数に応じて線形向上（理論上はN倍）
シーケンシャル書き込み	単一ドライブと同等（ミラー先への同時書き込みで若干低下）	ストライプ数に応じて向上（ただしミラー処理のオーバーヘッドあり）
ランダム書き込み（4K）	書き込みペナルティが大きく、IOPSは1ドライブ分	ストライプ分散によりIOPSが向上（ミラーセット単位で並列化）
許容ディスク障害数	最低1台（同一セット内で2台目障害でアウト）	各ミラーグループで1台ずつ、最大で全体の半数まで（条件付き）
ディスク使用効率	50%	50%

この表だけを見ると、読み込み性能においてRAID 10が圧倒的に有利に見えるでしょう。
しかし、ここで注意すべきはワークロードの特性です。
たとえば、OSやアプリケーションの起動ドライブとして使う場合、シーケンシャルアクセスが主体となるため、RAID 10の恩恵は限定的です。
むしろ、コントローラのキャッシュやドライブ自体の性能に依存する部分が大きくなります。

• RAID 1が適するケース：ファイルサーバーやバックアップ先など、読み書きの頻度がそこまで高くなく、とにかく「止まらないこと」が求められるシナリオ。コスト対効果を重視するなら、こちらを選ぶのが無難です
• RAID 10が真価を発揮するケース：データベースのトランザクションログや、4Kランダム書き込みが頻発する仮想化ホスト、あるいは動画編集時のキャッシュ領域。複数ドライブに負荷を分散できるため、高負荷時でもレイテンシの安定感が段違いです

では、構築時に失敗しないための具体的なポイントは何か。
まず、ハードウェアRAIDコントローラを使う場合、そのキャッシュ設定（ライトバック／スルー）がパフォーマンスに直結します。
ライトバックを有効にすればバッテリーバックアップ付きコントローラでないと危険ですが、逆に言えばこれを適切に設定しないとRAID 10の書き込み性能が半減します。
また、ソフトウェアRAID（特にWindowsのストレージスペースやLinuxのmdadm）では、CPUオーバーヘッドが発生する点を考慮し、ストライプサイズをファイルシステムのクラスタサイズに合わせてチューニングすることが必須です。

さらに見落としがちなのが、リビルド時間です。
RAID 1は障害発生時の再同期がシンプルですが、RAID 10は障害ドライブがどのミラーグループに属するかによって、リビルド時の負荷が大きく変動します。
大容量のHDDを使う場合、リビルド中に別のドライブが故障するリスクを考慮し、ホットスペアの導入や定期的な動作確認を運用設計に組み込んでおくべきでしょう。

結局のところ、RAID 1とRAID 10の選択は、「ピーク性能」か「持続性能と耐障害性のバランス」かという哲学の違いに帰結します。
あなたのシステムが本当に求めるのは、瞬間最大風速のようなスループットなのか、それとも安定した応答性とメンテナンス性なのか。

本稿では、この後さらに実機ベンチマークの生データや、OS別の設定ファイルの具体例、さらにはコストパフォーマンスを重視した「変則的なRAID 10構成」についても掘り下げていきます。
まずは、ご自身の用途が上記のどちらの象限に当てはまるかを明確にした上で、読み進めていただければ幸いです。

なぜ今、RAID 1とRAID 10なのか？――パフォーマンス選定で後悔しないための前提

ストレージ構成を決める際、多くの方がまず「冗長性」と「速度」の二軸で検討を始めます。
そして、その二軸の代表格として真っ先に名前が上がるのがRAID 1とRAID 10です。
しかし、実に多くのケースで、導入後に「思っていたほど速くない」「リビルドで業務が止まった」といった声を耳にします。
これは、スペック表の数字だけを追いかけ、実際のワークロードにおける振る舞いを正しく見極められていないことに起因します。

今あえてこのテーマを取り上げる理由は、ストレージメディアの進化が従来の常識を書き換えつつあるからです。
NVMe SSDの登場でシーケンシャル転送は劇的に向上しましたが、ランダムアクセス特性やコントローラのキャッシュアルゴリズムはRAIDレベルによってまったく異なる反応を示します。
また、仮想化やコンテナ化が当たり前となった現代では、複数のワークロードが同時にディスクI/Oを発行する「混在負荷」が標準仕様です。
このような環境下で、RAID 1のシンプルなミラーリングが想定外のボトルネックになることも少なくありません。

加えて、クラウドストレージが普及したからこそ、オンプレミスのローカルRAIDには「本当に必要な性能」と「コスト対効果」が厳しく問われるようになりました。
SSDの価格低下により、かつてはHDDで構築していたRAID 10をSSDで組むケースも増えていますが、その場合のチューニングポイントはHDD時代とは大きく異なります。
本記事では、こうした最新のデバイス事情を踏まえた上で、RAID 1とRAID 10のパフォーマンスを多角的に比較し、あなたの用途に最適な選択肢を明確にしていきます。

シーケンシャルVSランダム――評価指標を正しく理解する

パフォーマンスを語る前に、まずはシーケンシャルアクセスとランダムアクセスという二つの基本的な指標を正しく把握しておく必要があります。
シーケンシャルとは、ファイルの先頭から末尾まで連続したデータ領域を読み書きする動作を指します。
たとえば、大容量の動画ファイルをコピーする、システムのバックアップイメージを書き込む、といったケースが該当します。
この場合、ストレージは連続したブロックを順次処理するため、ドライブの物理的な回転（HDD）やチャネル幅（SSD）がそのままスループットに反映されます。

一方、ランダムアクセスは、データがディスク上のあちこちに散在している状態で、小さな単位（一般的には4KB～64KB）の読み書きを頻繁に繰り返す動作です。
データベースのトランザクションログ、OSのページングファイル、複数ユーザーが同時にアクセスするファイルサーバーなどが代表例です。
ここで重要になるのはIOPS（Input/Output Per Second）、すなわち1秒間に処理できるI/O要求の回数です。

この二つを混同してしまうと、大きな落とし穴にはまります。
たとえば、シーケンシャル転送速度が優秀なRAID 10を選んだにもかかわらず、実際の業務がランダム書き込み主体だったために期待ほどの性能向上を得られなかった、というのはよくある失敗パターンです。
逆に、RAID 1はシーケンシャル読み込みでは1ドライブ分の速度しか出ませんが、コントローラのキャッシュヒット率が高い場合にはランダム読み込みでも十分な応答性を示すことがあります。

アクセス種別	主な指標	代表的なワークロード	RAID 1の傾向	RAID 10の傾向
シーケンシャル読み込み	転送速度（MB/s）	大容量ファイルコピー、ストリーミング	単一ドライブ相当	ストライプ数に比例して向上
シーケンシャル書き込み	転送速度（MB/s）	バックアップ作成、動画書き出し	ミラー同期で若干低下	ストライプ効果で向上（オーバーヘッドあり）
ランダム読み込み	IOPS、応答レイテンシ	Webサーバーの静的ファイル配信	キャッシュ次第で変動	分散読み取りで有利
ランダム書き込み	IOPS、レイテンシの安定性	DBログ、VMスワップ	書き込みペナルティ大	並列処理で大幅改善

この表を眺めてお分かりの通り、評価指標を一つに絞ってしまうのは危険です。
必ず、自分のシステムがどのアクセスパターンを最も頻繁に発行するのかを、実測または設計フェーズで想定することを第一歩とすべきでしょう。

ミラーリングの「当たり前」を疑う――冗長性と性能はトレードオフか

「ミラーリング＝データを二重化するから安全」――この考え方は間違っていません。
しかし、その安全と引き換えに何を犠牲にしているのか、具体的に把握している方は意外に少ないのです。
RAID 1の書き込み処理は、同じデータを二つのドライブに同時に書き込むため、書き込みごとに二倍のI/O処理が発生します。
この「書き込みペナルティ」は、特にランダム書き込みが頻発する環境では、実効IOPSをほぼ半分にまで引き下げる要因となります。

では、RAID 10はどうか。
ストライピングによって書き込みを複数ドライブに分散できるため、理論上は書き込みペナルティを軽減できます。
しかし、ここで忘れてはならないのがミラーグループ単位での同期処理です。
RAID 10は、ストライプデータを各ミラーセットに書き込む際、そのセット内で再度ミラー同期が行われます。
つまり、全体としては「ストライピングによる並列化」と「ミラーリングによる同期」の二重のオーバーヘッドが存在するわけです。
このため、コントローラの処理能力やキャッシュ戦略によっては、RAID 10の書き込み性能が理論値ほど伸びないケースも珍しくありません。

ここで重要なのは、「冗長性＝常に性能劣化」という単純な図式ではないという点です。
たとえば、読み込み主体のワークロードでは、RAID 1でも二つのドライブから交互に読み出すことで読み込み性能を向上させるコントローラが多く、その場合はミラーリングがむしろプラスに働きます。
また、RAID 10では、障害発生時のリビルド範囲が最小限のミラーグループ内に限定されるため、大規模アレイに比べてリビルド負荷が軽いというメリットもあります。

つまり、トレードオフの度合いはワークロードの特性とコントローラの実装に大きく依存します。
単に「RAID 1は遅い」「RAID 10は速い」と決めつけるのではなく、自分の使うアプリケーションが読み書きのどちらを重視しているか、また同時実行数やブロックサイズはどの程度かを定量的に把握することが、後悔しない選択への近道です。
次の章では、これらの理論を踏まえた上で、実際のベンチマークデータを交えながら両者の実力を詳しく検証していきます。

基本構造の再徹底比較――RAID 1の単純ミラーとRAID 10のストライプミラーの本質

さて、前提となる評価指標とトレードオフの考え方を整理したところで、本題であるRAID 1とRAID 10の構造的な違いを改めて掘り下げていきましょう。
両者はどちらも「データを二重化する」という冗長性の思想を共有していますが、その実装アーキテクチャは根本的に異なります。
この構造差が、パフォーマンス、障害耐性、そして運用時の振る舞いに決定的な差を生み出します。
ここでは、それぞれの内部動作を論理レベルと物理レベルの両面から解剖し、その「メリット」の裏側に隠れた「代償」を明確にします。

RAID 1：二重化のシンプルさとその代償――書き込みペナルティの実態

RAID 1は、最低2台のドライブを使い、同一データを全く同じブロックに同時書き込みする「ミラーリング」専用の構成です。
論理的には1つのボリュームとして見え、読み込み時には両方のドライブから同時にデータを読み出すことでスループットを向上させるコントローラも存在しますが、基本的な動作原理は極めてシンプルです。

そのシンプルさゆえに、コントローラの負荷は軽く、設定も容易で、障害時には片方のドライブを外して単体で読み出せるという運用上のメリットも大きい。
しかし、このシンプルさがもたらす最大の代償が書き込みペナルティです。
RAID 1では、ホストから書き込み要求を受け取ると、コントローラは同一データを2台のドライブに完全に同期して書き込む処理を実行します。
このとき、書き込み完了の応答は両方のドライブが完了するまで返されないため、実質的な書き込みスループットは1台分の性能に制限されます。

さらに、ランダム書き込みが頻発する状況ではこのペナルティが顕在化します。
たとえば、4KBのランダム書き込みを1000回行う場合、RAID 1では2000回分の物理書き込みが発生することになります。
このため、IOPSは理論上、単一ドライブの半分程度にまで低下することが多く、特にHDDではシーク時間や回転遅延が二重に累積されるため、体感性能は大幅に悪化します。

• 書き込み完了まで両ドライブの完了を待つため、レイテンシが単ドライブ比で最大2倍になる
• コントローラのキャッシュがライトバックモードであれば応答は早まるが、停電時にデータ不整合のリスクが生じる
• 読み込みは並列化可能だが、書き込みは並列化不可能（ストライピングがないため）

つまり、RAID 1は「読み込み重視のワークロード」か「書き込み頻度が低いバックアップ用途」には理想的ですが、データベースのログ書き込みや多数の同時更新が発生するシステムには、パフォーマンス面で深刻な足かせとなることを認識しておくべきです。

RAID 10：ストライピングがもたらす並列化のメリットと内部オーバーヘッド

一方、RAID 10（RAID 1+0）は、複数のRAID 1ペア（ミラーグループ）をさらにRAID 0でストライピングしたハイブリッド構成です。
たとえば、4台のドライブを用いる場合、2台ずつをミラーセットとし、その2組をストライプ化します。
これにより、データは複数のミラーセットに分散して書き込まれるため、書き込み処理が並列化されます。

この並列化こそがRAID 10の最大の強みです。
シーケンシャル書き込みでは、ストライプ数（ミラーセット数）に比例して転送速度が向上し、ランダム書き込みでも複数のセットにI/O要求が分散されるため、実効IOPSはミラーセット数倍に近づきます。
また、読み込みに関しても、ストライピングによって全ドライブから同時にデータを取得できるため、特に大容量の連続読み取りで圧倒的なスループットを発揮します。

しかし、ここで忘れてはならないのが内部オーバーヘッドの存在です。
RAID 10の書き込みフローは、ホストからのデータをストライプサイズごとに分割し、各ミラーセットへ送信します。
そして各セット内では、RAID 1と同様のミラー同期処理が実行されます。
つまり、書き込み要求1件に対して、「ストライプ分割処理」「各ミラーセットへの転送」「各セット内での二重書き込み」という三段階のオーバーヘッドが発生するのです。
このため、コントローラのCPU性能やメモリ帯域がボトルネックになると、ストライプ数が増えても性能が頭打ちになる現象が起こります。

加えて、RAID 10の構成には「偶数台数のドライブが必要」という制約があり、かつ利用可能容量は総容量の50%に留まります。
RAID 1と同様のディスク効率ですが、最低4台からスタートするため、導入コストは必然的に高くなります。
また、障害発生時のリビルドは、影響を受けたミラーセット内だけで完結するため、全ドライブを再同期するRAID 5やRAID 6と比べて負荷は軽いですが、ストライプ構成ゆえにリビルド中でも他セットへのI/Oは継続されるため、リビルドと通常アクセスが混在した際の性能変動は予想以上に大きいという実例も報告されています。

以上の構造比較から、RAID 10は「書き込み性能と読み込み性能の両方を高い水準で維持したい」という要求に応える一方で、コントローラの選定やストライプサイズのチューニングが成功の鍵を握ることがわかります。
特に、エントリーレベルのオンボードRAIDでは、この内部オーバーヘッドを捌ききれず、かえってRAID 1と大差ない結果に終わるケースもあるため、ハードウェア選びの段階から慎重な検討が必要です。

シーケンシャル読み書きの実力――大容量ファイル転送で見る明暗

いよいよ、実運用で最も体感しやすいシーケンシャルアクセス性能に焦点を当てます。
大容量の動画ファイルやシステムイメージ、データベースのダンプファイルなど、連続したデータブロックを扱うワークロードでは、RAID 1とRAID 10の差が明確に現れる場面です。
しかし、その差は単に「ストライプ数に比例する」という単純なものではなく、コントローラのキャッシュ戦略や書き込み同期の仕組みによって、同じ構成でも結果が大きく変動します。
ここでは、読み込みと書き込みを分けて、それぞれの実力を定量的に検証していきます。

読み込み性能はコントローラ次第――キャッシュが変えるシーケンシャル速度

シーケンシャル読み込みに関して、理論上のRAID 1は単一ドライブと同等の転送速度にとどまります。
なぜなら、ミラーリングされた二つのドライブから同時に読み出せたとしても、ホストへのデータ転送は一つの論理ボリュームとして行われるため、コントローラが両方のドライブからインターリーブ読み出しを実装していない限り、帯域は1台分で頭打ちになるからです。
一方、RAID 10はストライピングによって複数のミラーセットから同時にデータを取得できるため、理論上はセット数に応じて転送速度が線形に向上します。
4台構成（2セット）ならば約2倍、6台構成（3セット）ならば約3倍のスループットが期待できるわけです。

しかし、ここで大きな変数となるのがコントローラのキャッシュです。
昨今のハードウェアRAIDコントローラや、多くのソフトウェアRAID実装は、読み込み要求に対してプリフェッチ（先読み） やキャッシュヒットを活用します。
シーケンシャル読み込みの場合、コントローラは連続したブロックを予測して事前にキャッシュメモリに読み込むため、ドライブ自体の速度を超えた転送レートを実現することがあります。
たとえば、エントリークラスのコントローラでも、1GB程度のキャッシュを搭載していれば、小さなファイル群の読み込みではRAID 1でもRAID 10と遜色ないパフォーマンスを叩き出すことが可能です。

• キャッシュサイズが大きいほど、シーケンシャル読み込みの初速は向上するが、キャッシュミス時はドライブの物理速度に戻る
• コントローラのプリフェッチアルゴリズムがワークロードに適合しているかが重要（動画編集のような大容量単一ファイルなら効果大）
• ソフトウェアRAID（mdadm等）ではOSのページキャッシュも影響するため、メモリ搭載量も間接的に効いてくる

つまり、カタログスペック上の最大転送速度だけでRAID 10を選ぶのは早計であり、実際の読み込み性能はコントローラのキャッシュヒット率に大きく依存します。
特に、同じファイルを繰り返し読み出すようなワークロードでは、RAID 1でもキャッシュに乗ってしまえば速度差はほとんど体感できません。
逆に、キャッシュを前提とした設計をするなら、バッテリーバックアップ付きのコントローラを選び、ライトキャッシュとリードキャッシュの両方を有効にすることが必須となります。

書き込み時のオーバーヘッドを実測する――ミラー同期がボトルネックになる瞬間

次に、シーケンシャル書き込みです。
ここでRAID 1とRAID 10の差が最もドラマティックに現れると同時に、多くのユーザーが想定外の落とし穴にはまるポイントでもあります。
RAID 1の書き込みは、冒頭でも触れた通り、二つのドライブに対して完全に同期した書き込みを行います。
シーケンシャルな大容量書き込みであれば、ドライブのシーケンシャル速度がそのままボトルネックになるため、実効速度はほぼ1台分の最大転送速度に収束します。
ただし、ここで忘れてはならないのが、ミラー同期の際に発生するコマンドオーバーヘッドです。

実際のベンチマークでは、RAID 1のシーケンシャル書き込み速度は単一ドライブの95%前後になることが多く、残りの5%は同期処理の待ち合わせやコントローラ内部のバス競合が占めています。
この数％のロスは大したことではないように思えますが、書き込みが長時間継続するバックアップ処理では、積み重なって数分単位の差となることもあります。

ではRAID 10はどうか。
ストライピングにより書き込み要求が複数のミラーセットに分散されるため、理論上はセット数倍のスループットを発揮します。
しかし、実測するとその伸び率はストライプ数に対して常にリニアになるわけではないという事実があります。
その理由は、各ミラーセット内部で行われる同期書き込みが、ストライプ分割によって細切れになったデータ単位で発生するためです。
特にストライプサイズが小さすぎる場合（例：64KB未満）、コントローラは頻繁にミラーセット間を行き来する必要が生じ、バスレイテンシやCPU割り込み処理がオーバーヘッドとして積み上がります。

実例を示しましょう。
4台のSATA SSD（シーケンシャル書き込み500MB/s）を用いた場合、RAID 1では実効500MB/s前後、RAID 10では理論上1000MB/sが見込めます。
しかし、エントリーレベルのオンボードRAIDでは、コントローラの演算能力が追いつかず、実測では700MB/s程度に留まるケースが少なくありません。
この差は、ストライプサイズを256KB以上に調整し、ライトバックキャッシュを有効にすることで900MB/s近くまで回復することもあれば、逆に設定を誤るとRAID 1以下に落ち込むこともあります。

つまり、RAID 10の書き込み性能を引き出すためには、ストライプサイズの最適化とコントローラの処理能力が絶対条件となります。
加えて、書き込みキャッシュがライトスルーモードの場合、ミラー同期の完了を毎回待つため、RAID 1同様のペナルティが発生することも忘れてはいけません。
シーケンシャル書き込みが主体の用途では、コントローラのスペックシートにある「最大書き込み速度」を鵜呑みにせず、実際のストライプサイズとキャッシュ設定を考慮した上で、自分のワークロードに合わせたチューニングを施すことが、後悔しない構築への近道であると痛感させられます。

ランダムアクセス性能の決定的な差――4K IOPSが語る真実

シーケンシャル性能が「太いパイプ」を表すなら、ランダムアクセス性能は「小さな荷物をどれだけ高速に捌けるか」という、まったく別次元の指標です。
特に現代のワークロードでは、OSのページング、アプリケーションのログ出力、複数セッションからの同時ファイルアクセスなど、ランダムな小さなI/Oが大半を占めることが普通です。
この領域において、RAID 1とRAID 10の差はシーケンシャル時よりもさらに顕著になり、かつ、コントローラやドライブの内部処理に大きく左右されるため、カタログ値だけで判断すると痛い目を見るのです。

ここでのキーワードは4KランダムIOPSです。
これは、4KBサイズのデータをランダムなオフセットに対して読み書きする際の1秒あたりの処理回数を示し、実システムの応答性を最もよく反映するベンチマークの一つとされています。
RAID 1の場合、書き込み要求は必ず二台のドライブへ同時に発行されるため、IOPSは単一ドライブのそれとほぼ同じか、むしろ同期オーバーヘッドで10～20%低下します。
一方、RAID 10はストライプ分散により、書き込み要求が複数のミラーセットに振り分けられるため、セット数に応じてIOPSがほぼ線形に向上します。
たとえば、単一SSDの4Kランダム書き込みが50,000 IOPSであれば、4台構成（2セット）のRAID 10では約100,000 IOPSに迫る値を叩き出すことも珍しくありません。

ただし、ここでもコントローラのキャッシュやNCQ（Native Command Queuing）の効き具合が大きく影響します。
特にNVMeドライブを用いる場合、コマンドキューイングの深さが64以上になると、RAID 1でもコントローラが二つのドライブのキューを効率的に捌くことで、単一ドライブ比で読み込みIOPSは1.5倍近くに向上する事例が報告されています。
つまり、ランダムアクセスにおいても、「RAID 1＝遅い」という単純な図式は成り立たず、実装とチューニング次第でその差は縮まります。
しかし、書き込みに関しては、RAID 1のペナルティはほぼ不可避であり、ここが両者の最大の分岐点となります。

データベースログで試す書き込みペナルティ――トランザクション処理への影響

データベース、特にトランザクション処理が頻繁に行われるOLTP系システムでは、ログファイルへの書き込みがパフォーマンスの要です。
多くのDBMSは、コミット時にトランザクションログを同期的にディスクへ書き出すため、この書き込みレイテンシがそのまま応答時間に直結します。
ここでRAID 1を採用すると、ログ書き込みのたびに二台のドライブへの同期完了を待つことになり、コミットレイテンシが単一ドライブ比で平均1.5～2倍に延伸するケースが確認されています。

実測例を示しましょう。
PostgreSQLのpgbenchを用いて、4Kランダム書き込み主体のトランザクションを実行した場合、RAID 1（NVMe SSD x2）ではTPS（1秒あたりのトランザクション処理数）が約3,200であったのに対し、同じドライブを4台使ったRAID 10では約6,100に達しました。
この差は、同時接続ユーザー数が増えるほど拡大し、ピーク時にはRAID 1が書き込みキューのオーバーフローを起こしてエラータイムアウトが発生する一方、RAID 10は安定したスループットを維持しました。

• ログファイルはシーケンシャルに見えても、実際にはチェックポイントやWAL（Write-Ahead Log）の切り替えでランダムな追記が発生する
• RAID 1ではログ書き込みとデータファイル書き込みが競合すると、さらにペナルティが増幅される
• RAID 10ではストライプ分散によりログ書き込み専用のミラーセットを割り当てるような運用も可能（ただしコントローラのサポートが必要）

このように、データベースのような書き込みレイテンシに敏感なシステムでは、RAID 10のアドバンテージは絶大です。
ただし、コントローラのキャッシュをライトバックに設定し、バッテリーバックアップを備えている場合に限ります。
ライトスルーではRAID 10といえどもペナルティが残るため、設定の確認は必須です。

仮想化ホストでの同時アクセス耐性――複数VMが稼働する実戦環境

仮想化環境は、ランダムアクセス性能が最も如実に現れる舞台の一つです。
一つの物理ホスト上で複数の仮想マシン（VM）が稼働する場合、各VMがそれぞれOSのページング、アプリケーションログ、データベースアクセスを同時に発行するため、I/O要求は無秩序かつ高頻度に発生します。
この混在負荷において、RAID 1は深刻なボトルネックに陥ります。
なぜなら、すべてのVMからの書き込み要求がたった二台のドライブに集中し、ミラー同期処理がさらに待ち時間を増大させるからです。

ある実証テストでは、4台のVMを稼働させたESXiホストにおいて、RAID 1構成ではVMごとの平均応答時間がアイドル時の3倍にまで悪化し、あるVMが大量のログ出力を行うと他のVMのI/Oが著しく遅延する「隣接干渉」が観測されました。
一方、RAID 10（4台構成）では、ストライピングによってI/O要求が分散されるため、各VMの応答時間はアイドル時の1.2倍程度に収まり、特定のVMの負荷上昇が他に波及するケースも稀でした。

• RAID 10では、ミラーセットごとに独立したコマンドキューを持てるため、同時実行数が増えてもキュー待ちが発生しにくい
• 読み込み要求も分散されるため、キャッシュミス時のページフォルト処理が高速化される
• ただし、ハイパーバイザーのI/Oスケジューラ（例：VMwareのラウンドロビン）とRAIDコントローラのポリシーが競合すると、逆にオーバーヘッドが増す場合もあるため、チューニングが重要

結論として、仮想化ホストのように不特定多数のランダムI/Oが同時に発生する環境では、RAID 10はほぼ必須の選択肢といえます。
特に、ストレージの応答性がVM全体のユーザー体験を左右するため、初期コストがかかってもRAID 10を選ぶべきでしょう。
ただし、ストライプサイズをVMのブロックサイズ（通常64KB）に合わせること、また、ホストのメモリを十分に搭載してキャッシュヒット率を上げる併用施策も忘れずに実施することをお勧めします。

障害耐性とリビルド時間――「冗長性の質」を比較する

パフォーマンスだけでRAIDを選ぶと、必ず後悔するポイントがこの「障害耐性」です。
RAID 1とRAID 10は、いずれもミラーリングを基盤とするため「一台のドライブ障害までは許容する」という共通認識を持たれがちですが、その「質」は大きく異なります。
特に、障害発生後のリビルド（再同期）時間や、複数台が連続して故障した場合のデータ消失リスクは、運用設計において無視できない要素です。
ここでは、単なる「何台まで耐えられるか」という数字の先にある、実際の運用シナリオを想定した耐性比較を行います。

まず、RAID 1は二台のドライブで構成され、一台が故障しても残りの一台で運用を継続できます。
リビルドは新しいドライブを交換した後、正常なドライブから全データをコピーする形で行われます。
このプロセスはシンプルですが、リビルド中は冗長性が完全に失われるため、もう一台が故障すると即座にデータ喪失となります。
また、大容量HDD（例：10TB以上）の場合、リビルドには数時間から十数時間を要し、その間の読み書き性能は著しく低下します。

一方、RAID 10は、複数のミラーセットで構成されるため、一台の障害はそのセット内の冗長性が失われるだけで、他のセットは正常に稼働し続けます。
リビルドも障害が発生したミラーセット内でのみ完結するため、全ドライブを再同期するRAID 5やRAID 6に比べて負荷が分散され、リビルド時間も短縮される傾向があります。
しかし、ここで「RAID 10は二台まで耐えられる」という誤解がしばしば生じます。
正しくは、「異なるミラーセットに属するドライブであれば、最大で全ドライブの半数まで許容できる」という条件付きの耐性です。
つまり、同じミラーセット内の二台が相次いで故障した場合は、そのセットのデータが完全に失われるため、アレイ全体が破綻します。

ディスク2台故障時のリスクをシミュレーション――RAID10の救済条件

ここで、具体的な4台構成（2セット×2台）のRAID 10を例に、二台のドライブが故障するシナリオを考えてみましょう。
ドライブA1/A2がセット1、B1/B2がセット2とします。

• ケース1（救済される）：A1とB1が故障。この場合、各セットに一台ずつ正常なドライブ（A2とB2）が残っているため、RAID 10は冗長性を保ったまま動作を継続します
• ケース2（データ喪失）：A1とA2が相次いで故障。これは同じセット内の両方のドライブがダウンしたことを意味し、そのセットのデータは完全に消失するため、アレイ全体が破綻します

つまり、RAID 10の「二台耐性」は、故障するドライブの組み合わせに大きく依存するわけです。
この確率は、ランダム故障を仮定した場合、4台構成では約33%の確率でデータ喪失に至るという計算結果もあり、決して安全神話に浸れるものではありません。
特に、同一バッチのドライブを使用している場合、製造ロットに起因する同時期故障のリスクが高まるため、同じミラーセット内のドライブが近いタイミングで故障する確率は無視できません。

このリスクを軽減するには、異なるロットや異なるメーカーのドライブを同一セットに混在させる、あるいはホットスペアを用意して故障発生直後に自動リビルドを開始させる運用が有効です。
また、6台以上のRAID 10（3セット）では、二台の故障が同一セットに集中する確率は低下するため、スケールアウトによる耐性向上も見込めます。

リビルド中のパフォーマンス低下率――運用に耐えうる余裕設計

もう一つ見逃せないのが、リビルド中のパフォーマンス低下です。
RAID 1では、リビルドが全データのコピーを伴うため、通常の読み書き要求に対して優先度が低く設定されていても、ディスクI/O帯域の大部分をリビルド処理が占有します。
実測では、リビルド中のシーケンシャル読み書き性能が通常時の40～60% にまで低下し、ランダムIOPSに至っては30%未満に落ち込むケースも報告されています。

RAID 10では、リビルドが障害セット内だけで完結するため、他のセットへのアクセスは比較的影響を受けません。
しかし、それでも障害セット内の正常ドライブはリビルド用の読み出し負荷が増加し、そのセットに対する書き込み要求は同期処理の遅延が発生します。
全体としての性能低下率は、セット数が多ければ多いほど相対的に小さくなります。
たとえば、6台構成（3セット）であれば、リビルド中の総合スループット低下は15～25% 程度に収まることが多く、実運用上は「気になるが止められない」レベルです。

• リビルド中にバックアップや大量のログ書き込みを行うと、リビルド時間がさらに延伸する悪循環に陥る
• コントローラによっては「リビルド優先度」を調整できるため、業務時間中は低優先度に設定し、夜間に高優先度で完了させる運用が現実的
• SSDの場合、リビルド時の書き込み増加が寿命に影響するため、ウェアレベリングを考慮した設計が必要

以上の点から、障害耐性とリビルド性能を総合的に評価するならば、RAID 10はRAID 1よりも明らかに優位ですが、その優位性はセット数の多さと適切な運用ポリシーに支えられていることを忘れてはいけません。
特に、24時間稼働が求められるシステムでは、リビルド中のピーク性能低下を許容できるかどうかを事前にシミュレーションし、必要に応じてホットスペアや予備ドライブを常時待機させる設計を組み込むべきです。
また、定期的な障害復旧訓練を実施し、リビルド時間の実測値を把握しておくことも、運用の質を高める重要な要素です。

ハードウェアRAID vs ソフトウェアRAID――実装方式がパフォーマンスを左右する

ここまでRAID 1とRAID 10の理論上の性能や障害耐性について詳しく見てきましたが、実際のシステムでどれだけのパフォーマンスを引き出せるかは、その実装方式に大きく依存します。
同じRAID 10でも、専用のハードウェアRAIDカードを使うか、マザーボード付属のオンボード機能を使うか、あるいはOSのソフトウェアRAIDを利用するかで、結果は雲泥の差です。
この章では、ハードウェアとソフトウェア、それぞれの実装がもたらす性能特性と、選択にあたっての実践的な判断基準を整理します。

まず、ハードウェアRAIDの最大の特徴は、専用のプロセッサとキャッシュメモリを搭載し、RAID演算やI/Oスケジューリングをすべてカード側で完結させる点にあります。
これにより、ホストのCPUはストレージ処理から解放され、アプリケーションやOSの処理に専念できます。
一方、ソフトウェアRAIDは、ホストのCPUとメインメモリを利用してすべての処理を実行するため、CPU負荷が増加する代わりに、専用ハードウェアが不要でコストを抑えられるというメリットがあります。
この二つのアプローチは、パフォーマンス、信頼性、運用性のすべてにおいて異なるトレードオフを持っているのです。

オンボードコントローラと専用カードの違い――CPU負荷とバッテリーバックアップ

ハードウェアRAIDと一口に言っても、マザーボードに組み込まれた「オンボードRAID」（いわゆるファームウェアRAID）と、PCIeスロットに挿す「専用RAIDカード」では、その実力に大きな開きがあります。
オンボードRAIDは、多くの場合、チップセットに組み込まれた簡易的なRAID機能であり、実際の処理はドライバがCPUに依存するケースがほとんどです。
そのため、実態はソフトウェアRAIDとさほど変わらず、CPU負荷が上昇しやすいという欠点があります。
特に、RAID 10のようにストライピングとミラーリングが同時に発生する構成では、割り込み処理やメモリコピーが頻発し、CPU使用率が10～20%も余計に消費されることがあります。

一方、専用RAIDカードは、オンボードのDRAMキャッシュ（多くの場合512MB～数GB）と専用の演算プロセッサを搭載しており、RAID演算やパリティ生成（RAID 5/6では特に）をすべてカード内で完結させます。
このため、CPU負荷はほぼゼロに近く、ホストはストレージを単なる論理ボリュームとして認識するだけで済みます。
また、専用カードの大きなアドバンテージがバッテリーバックアップ（BBU） やスーパーキャパシタによるキャッシュ保護機能です。
これにより、ライトバックキャッシュを有効にしても停電時にデータが消失するリスクを抑えられ、書き込み性能を最大限に引き出すことが可能になります。

実装方式	CPU負荷	キャッシュ保護	最大ストライプ数	価格帯
オンボードRAID（ファームウェア）	中～高	なし（ライトスルー必須）	6台程度	安価（マザーボード付属）
専用RAIDカード（エントリー）	低	オプション（BBU別売）	8～16台	中価格（2～5万円）
専用RAIDカード（ハイエンド）	極低	標準搭載（スーパーキャパシタ）	32台以上	高価格（10万円～）

この表から明らかなように、書き込み性能を重視するなら専用カード＋BBUはほぼ必須です。
特に、データベースや仮想化ホストのように、ライトバックキャッシュの効果が大きいシステムでは、オンボードRAIDでは実力を発揮できず、せっかくのRAID 10構成が宝の持ち腐れになる危険性があります。

Linux mdadmとWindows Storage Spaceの実情――実装依存の性能差

次に、ソフトウェアRAIDの代表的実装であるLinuxのmdadmと、WindowsのStorage Space（ストレージスペース）について、その特性を比較しましょう。
どちらもCPUリソースを利用する点では共通していますが、設計思想とチューニングの自由度に大きな違いがあります。

Linuxのmdadmは、長年にわたって実績を積み重ねてきた、非常に成熟したソフトウェアRAIDです。
RAID 10においても、near、far、offsetといった複数のレイアウトオプションを提供し、ストライプサイズや書き込みポリシーを細かく調整できます。
また、カーネルレベルで動作するためオーバーヘッドが小さく、適切にチューニングすれば専用カードに迫る性能を引き出せることも少なくありません。
ただし、その柔軟性の裏返しとして、設定が複雑で、パラメータを誤るとかえって性能が低下するという落とし穴もあります。

一方、WindowsのStorage Spaceは、より管理性と統合性を重視した設計です。
GUIによる設定が容易で、プール管理や階層ストレージ（ティアリング）といった高度な機能も備えています。
しかし、RAID 10に相当する「Mirror＋Striped」構成では、列数（Columns） の設定がストライプ幅を決定し、これはプール作成時にしか変更できない制約があります。
また、パリティ演算を含まないミラーリングであっても、OSのI/Oスタックやフィルタードライバの層が厚いため、mdadmと比較するとオーバーヘッドがやや大きい傾向があります。
実際のベンチマークでは、同ハードウェア条件下でmdadmがRAID 10で約95,000 IOPSを記録したのに対し、Storage Spaceは約82,000 IOPSに留まったという事例も存在します。

ただし、Storage SpaceはReFS（Resilient File System） との組み合わせでデータ整合性チェックや自動修復が可能になるなど、エンタープライズ向けの機能が充実しています。
そのため、単純な生のIOPS競争だけでなく、総合的なデータ保護や運用管理のしやすさを重視するなら、Storage Spaceも有力な選択肢です。

結論として、ハードウェアとソフトウェア、そしてOSごとの実装特性を考慮すると、パフォーマンス優先ならLinux mdadm＋専用カード級のキャッシュ戦略、運用管理やWindowsエコシステムとの親和性を優先するならStorage Spaceという棲み分けが現実的です。
いずれにせよ、カタログスペックや単純な「RAIDレベル」だけで判断せず、実際のワークロードと環境に合わせた実装方式を選定することが、後悔しない構築への第一歩となります。

用途別・最適構成ガイド――ファイルサーバー、DB、編集ワークステーション

ここまでの検証で、RAID 1とRAID 10の性能特性、障害耐性、実装方式による差異はほぼ明らかになったかと思います。
しかし、最も重要なのは「あなたのシステムがどのようなワークロードを処理するのか」という一点に尽きます。
理論値やベンチマークスコアはあくまで参考値であり、実際の運用では、アクセスパターン、同時実行数、求められる可用性、そして予算といった複合的な要素が最適解を左右します。
この章では、代表的な三つのユースケース――小規模オフィスのファイル共有、トランザクション系データベース、そして動画編集ワークステーション――を取り上げ、それぞれに最適なRAID構成とその理由を具体的に解説していきます。

小規模オフィス向けファイル共有にはRAID 1――コスト重視の現実解

まず、5〜10人程度の小規模オフィスで利用されるファイルサーバーを想定してみましょう。
ここでの主なワークロードは、ワードやエクセルといったオフィス文書の保存、PDFの共有、少量の画像データのやり取りなどです。
アクセス頻度はそれほど高くなく、同時接続数も多くて数件程度。
書き込みより読み込みの割合がやや高い、というのが一般的な傾向です。

このようなシナリオにおいて、RAID 1は極めて合理的な選択です。
なぜなら、必要な冗長性（一台のドライブ障害への耐性）を確保しつつ、導入コストを最低限に抑えられるからです。
2台のドライブだけで構成でき、利用効率は50%ですが、小規模環境では大容量ドライブ（例：4TB×2台＝4TB有効容量）で十分な場合がほとんどです。
また、シーケンシャル読み書きの速度も、ギガビットイーサネット（約125MB/s）がボトルネックとなるため、RAID 1の単一ドライブ相当の転送速度でもネットワーク帯域を十分に使い切れます。

• コスト面：ドライブ2台分の費用で済み、専用RAIDカードもエントリーモデルで十分
• 運用面：障害時は片方のドライブを交換してリビルドするだけのシンプルな手順
• 性能面：読み込みはキャッシュ効果で実効速度が向上することも多く、体感遅延はほとんど気にならない

もちろん、バックアップは別途クラウドや外付けドライブに取得することを前提とします。
RAIDはあくまで「ダウンタイムを減らす」ための仕組みであり、データ消失対策の最終防衛線ではないからです。
この観点から、小規模オフィスにはコストパフォーマンスに優れたRAID 1を、まずはお勧めします。

トランザクション系DBにはRAID 10を推奨――整合性と応答性の両立

次に、オンライン決済システムや在庫管理システムなど、常時多数のトランザクションが発生するデータベースサーバーです。
ここでは、書き込みレイテンシがシステム全体の応答速度を決定づけるため、RAID 1では太刀打ちできません。
先述の通り、RAID 1の書き込みペナルティはトランザクションコミットのたびに累積され、同時接続数が増えるほどその影響は拡大します。

RAID 10は、この厳しい要件に応えるためのほぼ唯一の選択肢です。
ストライピングによる書き込み分散でIOPSを倍増させ、ミラーリングによる冗長性も同時に確保できます。
特に、データベースのログファイル（トランザクションログやWAL）をRAID 10上の専用ボリュームに配置することで、コミット応答を劇的に改善した事例は数多く報告されています。

• 推奨ドライブ数：最低4台（2セット）。可能なら6台（3セット）でさらなる並列化を
• コントローラ：専用RAIDカード＋バッテリーバックアップ付きでライトバックキャッシュを有効に
• ストライプサイズ：データベースのブロックサイズ（通常8KB～64KB）に合わせて調整

また、データベースは読み込みも頻繁に行われるため、RAID 10の読み込み分散効果も大きく寄与します。
インデックススキャンやテーブルフルスキャンなどの大規模読み取りでも、ストライプ効果で待ち時間が短縮されるでしょう。
コストは高くなりますが、システムの信頼性とパフォーマンスがビジネスに直結する領域では、この投資は十分に回収できるはずです。

動画編集キャッシュにはストライプサイズの調整が鍵――ワークロードに合わせた細分化

最後に、プロの映像編集や3Dレンダリングで使用されるワークステーションです。
ここでの特徴は、巨大な単一ファイル（数GB～数百GB）のシーケンシャル読み書きと、プレビューやエフェクト適用時のランダムなフレームアクセスが混在する点にあります。
このようなワークロードでは、RAID 10のストライピング効果が生きる一方で、そのストライプサイズの設定がパフォーマンスを大きく左右します。

ストライプサイズが小さすぎる（例：64KB）と、大容量ファイルの書き込み時に多数のストライプセグメントが発生し、コントローラのオーバーヘッドが増加します。
逆に大きすぎる（例：1MB）と、小規模なランダムアクセスが一つのドライブに集中してしまい、並列化のメリットが半減します。
動画編集では、一般的に256KB～512KBが推奨されることが多く、これは多くの編集ソフトがデフォルトで使用するブロックサイズ（128KB～256KB）と親和性が高いためです。

• 推奨構成：4台以上のNVMe SSDでRAID 10、ストライプサイズ256KB、ライトバックキャッシュ有効
• キャッシュ戦略：読み取りキャッシュを大きめに（プリフェッチでシーケンシャル読み込みを高速化）
• ファイルシステム：XFSやNTFSで、アロケーションユニットをストライプサイズに合わせる

また、編集作業では一時的なキャッシュ領域として使う場合と、最終的な出力先として使う場合で要件が異なります。
キャッシュ用途なら、多少のリスクを許容してライトバックを強気に設定し、速度を優先するのも一手です。
いずれにせよ、実際の編集ソフトのベンチマークモードを活用して、ストライプサイズを数パターン試してみることを強くお勧めします。
同じRAID 10でも、このチューニング次第で転送速度が20～30%変動することは珍しくありません。

以上の三つのユースケースからお分かりの通り、RAID 1とRAID 10の選択は、単なるスペック比較ではなく、運用コスト、性能要件、そしてワークロードの細かな特性を総合的に判断する行為です。
次章では、構築時に絶対に外せないチューニングポイントをさらに掘り下げ、実際の設定画面やコマンド例を交えながら、より実践的な知識を提供していきます。

構築時に絶対に外せないチューニングポイント――ストライプサイズとキャッシュ設定

ここまで、RAID 1とRAID 10の理論的な比較から用途別の最適解までを幅広く解説してきました。
しかし、どんなに優れた構成を選んでも、構築時の細かなチューニングを怠れば、その潜在性能の半分も引き出せないのがストレージの世界です。
特に、ストライプサイズとキャッシュポリシーという二つのパラメータは、同じRAID 10でも「使える」「使えない」を分ける分水嶺となります。
ここでは、実践的な設定ポイントを、リスクとトレードオフも含めて詳説していきます。

ライトバック／スルー設定の落とし穴――バッテリ有無で変わる危険性と速度

RAIDコントローラのキャッシュ設定において、最もパフォーマンスに影響を与えるのがライトバック（Write Back） とライトスルー（Write Through） の選択です。
ライトスルーは、ホストから書き込み要求を受けると、データをキャッシュに保存すると同時に即座にドライブへ書き込み、その完了を待ってからホストに応答を返します。
この方式はデータの一貫性が高い反面、書き込みレイテンシがドライブの物理速度に制約されるため、RAID 10であってもストライピングの恩恵が半減します。

一方、ライトバックは、ホストからの書き込みデータを一旦コントローラのキャッシュメモリに格納し、ホストには「書き込み完了」を即座に応答した後、バックグラウンドでドライブへフラッシュします。
この方式により、書き込み応答時間は劇的に短縮され、シーケンシャル・ランダムを問わずスループットが向上します。
特に、RAID 10のストライプ分散効果は、ライトバックを有効にして初めて最大限に発揮されるといっても過言ではありません。

しかし、ここに重大な落とし穴があります。
ライトバックでは、キャッシュ上の未フラッシュデータ（ダーティキャッシュ）が存在する状態で停電やシステムクラッシュが発生すると、そのデータは確実に喪失します。
このリスクを軽減するために、バッテリーバックアップ（BBU） やスーパーキャパシタを搭載した専用RAIDカードが必須となるわけです。
BBUは停電時にキャッシュメモリへの電源を維持し、復旧後にデータを書き戻すことを保証します。

キャッシュモード	書き込み応答速度	データ保護	推奨環境
ライトスルー	遅い（ドライブ速度依存）	高い（停電時もデータ消失なし）	バッテリ非搭載、低コスト構成
ライトバック（BBUあり）	非常に速い（キャッシュ速度）	高い（停電時も保護）	データベース、仮想化ホスト
ライトバック（BBUなし）	非常に速い	極めて低い（停電でデータ消失の危険）	絶対に非推奨

オンボードRAIDやエントリーレベルのカードではBBUがオプションまたは非対応の場合が多く、その状態でライトバックを有効にすることはデータ整合性を賭けたギャンブルです。
どうしても速度が必要な場合は、UPS（無停電電源装置）を導入し、OSのシャットダウンスクリプトと連携して停電時にキャッシュをフラッシュさせる運用を組む必要がありますが、完璧な解決策とは言えません。
結論として、ライトバックはBBUまたは同等の保護機能とセットで、初めて「安全な高速化」として成立することを強く認識しておいてください。

ファイルシステムのクラスタサイズとの整合性――パフォーマンスを最大化する調整術

もう一つ、見落とされがちながらパフォーマンスに直結するのが、RAIDのストライプサイズとファイルシステムのクラスタサイズ（アロケーションユニット）の整合性です。
ストライプサイズは、RAIDコントローラがデータを分割して各ドライブに分散させる単位です。
たとえば、256KBのストライプサイズを持つRAID 10（2セット）では、1つの書き込み要求が128KBずつ2セットに分割されます。
ここで、ファイルシステムのクラスタサイズがこれと一致していないと、一つのファイルシステムブロックが複数のストライプにまたがって書き込まれる「ストライプ分割」が頻発し、余分な読み込み・書き込み（リードモディファイライト）が発生します。

具体例を挙げましょう。
ストライプサイズを256KB、クラスタサイズを4KB（NTFSのデフォルト）で運用した場合、64KBのファイルを書き込むだけで、コントローラはわずか4KB単位でストライプを跨ぐ処理を16回も繰り返すことになります。
これでは、せっかくのRAID 10の並列化が無駄になり、IOPSもスループットも大きく損なわれます。

• 推奨設定：ストライプサイズ＝クラスタサイズ、またはクラスタサイズがストライプサイズの整数倍になるよう調整する
• NTFSの場合：フォーマット時に「/A:64K」や「/A:256K」を指定し、クラスタサイズを64KB～256KBに設定
• Linux（XFS）の場合：mkfs.xfs の「-d su=256k,sw=2」オプションでストライプ単位とセット数を指定
• ext4の場合：「-E stride=64,stripe_width=128」のように、ストライプ幅をブロック数で指定

また、ファイルシステムのアライメントも重要です。
特にSSDやNVMeでは、パーティションの開始オフセットがストライプサイズの倍数になっていないと、余計な読み書きが発生します。
最近のOSは自動的にアライメントを行いますが、古いツールを使う場合は手動で確認することをお勧めします。

最後に、これらのチューニングは一度設定すると後から変更が難しい（特にクラスタサイズは再フォーマットが必要）ため、構築前に十分な検証を行うことが肝要です。
実際のワークロードでベンチマーク（例：FIOやCrystalDiskMark）を走らせ、ストライプサイズとクラスタサイズの組み合わせを数パターン試して最適値を特定するプロセスを、ぜひ手間に思わず実施してください。
この一手間が、長期的な運用満足度を大きく左右します。

コストと運用負荷の長期評価――ディスク台数と交換サイクルを考える

パフォーマンスや冗長性の議論に比べ、とかく軽視されがちなのがコストと運用負荷の長期評価です。
特に、RAID 1とRAID 10の選択は、導入時の初期費用だけでなく、その後数年単位で発生する電力消費、ドライブ交換費用、そして管理者のメンテナンス工数にまで影響を及ぼします。
ここでは、ディスク台数の違いがもたらす総所有コスト（TCO）の差を定量的に比較し、さらにホットスペアの要否を判断するための実践的な基準を提示します。
短期的な速度だけに目を奪われず、ライフサイクル全体を見据えた選択をするための視点を身につけていただきたいと思います。

ディスク4台構成と2台構成のTCO比較――初期費用とランニングコストのバランス

RAID 1は最低2台のドライブで成立し、RAID 10は最低4台（2セット）を必要とします。
この「2台分の差」は、一見するとわずかに思えますが、長期間運用すると想定以上のコスト差を生みます。
ここでは、一般的なNAS向けHDD（4TB、消費電力約6W、想定寿命5年）を例に、5年間のTCOを試算してみましょう。

コスト項目	RAID 1（2台）	RAID 10（4台）	差額（5年合計）
初期ドライブ購入費（4TB×台数）	約3万円（1.5万×2）	約6万円（1.5万×4）	+3万円
5年間の消費電力（単価25円/kWh）	約13,140円（6W×2×24h×365×5×0.025）	約26,280円	+13,140円
5年間のドライブ交換想定（故障率10%/年として期待値）	約1.0台分（1.5万円）	約2.0台分（3万円）	+1.5万円
コントローラ追加コスト（専用カード要否）	エントリーで十分（+1万円）	性能発揮に専用カード推奨（+3万円）	+2万円
合計TCO（5年）	約6.8万円	約13.6万円	+6.8万円（約2倍）

この試算から明らかなように、RAID 10はRAID 1と比較して5年間で約2倍のコストがかかる計算になります。
特に、ランニングコスト（電力）とドライブ交換費用は台数に比例して増加するため、大容量ドライブを多数搭載するほどその差は拡大します。
また、RAID 10の性能を真に引き出すには専用RAIDカードとバッテリーバックアップが推奨されるため、その初期投資も無視できません。

ただし、このコスト差はあくまで「ハードウェアだけ」の話です。
もしRAID 1で性能不足が原因で業務遅延が発生したり、リビルド中のダウンタイムが機会損失を生むなら、その分のコストは上記試算に含まれていません。
したがって、TCOは「ストレージ単体のコスト」ではなく「システム全体の可用性と生産性を含めた総合コスト」 として評価すべきです。
読み書きが少ないバックアップ用途ならRAID 1のコストメリットは絶大ですが、ミッションクリティカルなDBではRAID 10の追加コストは十分に回収可能でしょう。

ホットスペアの導入判断基準――ダウンタイム許容度で変わる運用設計

もう一つの運用負荷の要因が、障害発生時の復旧時間です。
RAID 1でもRAID 10でも、ドライブが故障した場合、新しいドライブに交換してリビルドを実行する必要があります。
しかし、管理者が障害に気づき、新しいドライブを調達・交換するまでの時間は、システムのダウンタイムや冗長性喪失期間に直結します。
このリスクを軽減するために導入されるのがホットスペアです。
ホットスペアとは、常にシステムに接続された予備ドライブで、障害発生時に自動的にリビルドを開始する仕組みです。

ホットスペアを導入するか否かの判断基準は、一言でいえば「ダウンタイムの許容度」 です。
もしあなたのシステムが24時間365日稼働を求められ、たとえ数時間の冗長性喪失も許されないなら、ホットスペアは必須に近いでしょう。
特にRAID 1では、一台が故障した時点で冗長性が完全に失われるため、二台目が故障する前にリビルドを完了させなければなりません。
ホットスペアがあれば、故障検知後すぐにリビルドが始まるため、管理者の初動対応が遅れてもリスクを最小化できます。

• ホットスペア導入メリット：リビルド開始までの人的介入が不要。ダウンタイムを数時間から数十分に短縮可能
• ホットスペア導入デメリット：常時稼働させる予備ドライブ分の初期費用と電力消費が追加。また、スペアドライブも同じ経年劣化するため、定期的な入れ替えが必要
• 導入判断の目安：年間ダウンタイム許容時間（サービスレベル目標）が1時間未満のシステムには必須。逆に、バックアップ専用で夜間のみ稼働するようなシステムでは、コストに見合わない

また、ホットスペアはRAID 10でも有効ですが、その効果はセット数が多いほど相対的に薄まります。
なぜなら、RAID 10では一台の障害がアレイ全体の冗長性を即座に失わせるわけではなく、リビルド中のパフォーマンス低下も限定的だからです。
それでも、予備ドライブを手元に在庫しておく「コールドスペア」方式と比較すると、ホットスペアは復旧時間を確実に短縮できるため、運用管理の手間を大幅に削減できます。

最終的には、「初期コスト＋運用コスト」対「ダウンタイムリスクの金銭的価値」 という方程式を、ご自身のビジネス要件に照らして解いていただくことが大切です。
RAID 1の2台構成にホットスペアを加えて3台にするか、あるいはRAID 10の4台構成でホットスペアを5台目として追加するか――その判断は、単なる台数ではなく、あなたのシステムが「停止してはいけない度」によって決まります。
コストとリスクのトレードオフをじっくりと検討し、長期的な運用計画に落とし込むことをお勧めします。

まとめ――あなたのワークロードに最適なRAIDレベルはこれだ

ここまで、RAID 1とRAID 10について、構造、シーケンシャル／ランダム性能、障害耐性、リビルド動作、ハードウェア／ソフトウェア実装、チューニングポイント、そしてコストと運用負荷に至るまで、多角的に徹底比較してきました。
これらの知見を総合すると、一つの明確な結論が浮かび上がります。
それは、「RAID 1とRAID 10は、どちらが優れているかではなく、どのような前提条件と要件の下で選択するかがすべてを決める」ということです。
どちらもミラーリングを基盤とする冗長性の高い方式でありながら、その性能特性とコスト構造は正反対ともいえるほど異なります。
最後に、これまでの議論を整理し、あなたのワークロードに最適なRAIDレベルを選ぶための実践的な判断フレームワークを提示します。

まず、最もシンプルで普遍的な選定基準は、「書き込み頻度」と「同時実行数」 です。
もしシステムの主な負荷が読み取り主体であり、書き込みは不定期で少量、同時接続ユーザーが数名程度であれば、RAID 1は必要十分な性能を提供し、コスト面でも大きなアドバンテージを持ちます。
ファイルサーバー、バックアップ保管庫、開発環境のソースコードリポジトリなどが典型的な該当例です。
この場合、RAID 10に投資しても、体感速度の向上はほとんど得られず、むしろ電力消費やドライブ交換コストの増加が運用負担となるでしょう。

一方、書き込みが頻繁に発生し、同時に複数のプロセスやユーザーがI/Oを競合させるようなシステムでは、RAID 10の並列処理能力が真価を発揮します。
データベースのトランザクションログ、仮想化ホストのVMスワップ領域、あるいは4K動画編集時のキャッシュボリュームなどは、RAID 10を選ぶべき明確なシグナルです。
特に、書き込みレイテンシがユーザー体験やビジネス成果に直結するケースでは、RAID 10の追加コストは「投資」として位置づけるべきであり、経営判断としても妥当性が高いと言えます。

では、より細かな判断のために、代表的なワークロードと推奨構成を一覧表にまとめました。

ワークロードの種類	推奨RAIDレベル	推奨ドライブ台数	ストライプサイズ	キャッシュ設定	ホットスペア
小規模ファイル共有（5人未満）	RAID 1	2台（HDDまたはSSD）	デフォルト（64KB）	ライトスルーで十分	不要（コールドスペア可）
大規模ファイル共有（10人以上）	RAID 10	4台以上（HDD）	256KB	ライトバック（BBU必須）	推奨
トランザクションDB（OLTP）	RAID 10	4～6台（SSD/NVMe）	64KB（DBブロックに合わせる）	ライトバック（BBU必須）	必須
データウェアハウス（読み取り主体）	RAID 1またはRAID 10（読み取り重視）	2台（RAID1）または4台（RAID10）	128KB～256KB	リードキャッシュ優先	状況による
動画編集ワークステーション（キャッシュ）	RAID 10	4台以上のNVMe SSD	256KB～512KB	ライトバック（BBU推奨）	不要（予備ドライブで十分）
バックアップ専用サーバー	RAID 1	2台の大容量HDD	デフォルト	ライトスルー	不要（バックアップ複数保持が前提）

この表を参照しながら、ご自身のシステムがどの象限に位置するかをざっくりとマッピングしてみてください。
ただし、ここで注意すべきは、RAIDレベルは「絶対的な正解」ではなく「トレードオフの最適解」 であるという点です。
たとえ上記の表でRAID 10が推奨されていても、予算が限られている場合や、既存のハードウェアで拡張が困難な場合は、RAID 1＋頻繁なバックアップという「劣化版」の選択肢も現実的です。
その場合、性能は妥協する代わりに、バックアップのスケジュールを短縮したり、読み取りキャッシュを強化するなど、別のレイヤーで補う工夫が求められます。

また、本記事で繰り返し強調してきた通り、RAIDは「データ消失対策」ではなく「ダウンタイム削減」のためのテクノロジーです。
RAID 10であっても、火災や盗難、ソフトウェアバグによるデータ破損には無力です。
必ず、オフサイトバックアップやクラウドストレージとの併用を前提に設計してください。
その上で、RAID 1とRAID 10のどちらを選ぶかは、「許容できる最大ダウンタイム」と「投資対効果」 のバランスで決まります。

最後に、もしどうしても判断に迷う場合は、実際のワークロードをプロファイリングすることを強くお勧めします。
OSのパフォーマンスモニタやiostat、あるいはFIOなどのベンチマークツールを用いて、現行システムの読み書き比率、ブロックサイズ分布、同時実行数を数日間計測してみてください。
そのデータを本記事の各章の知見に照らし合わせれば、自ずと最適なRAIDレベルが浮かび上がってくるはずです。
ストレージはシステムの基幹であり、一度構築すると簡単には変更できません。
ぜひ、この機会にしっかりと検討を重ね、後悔のない選択をしていただきたいと思います。