RAID 0とRAID 5。
どちらを選ぶかは、単なる「速度対耐障害性」という二項対立では片付けられません。
特に書き込み処理の実効速度と、障害発生後のリビルド(再構築)時におけるシステムへの影響は、想定以上に運用設計を左右するからです。
本稿では、この2つのアレイレベルを、書き込みレイテンシとリビルド負荷という現実的な指標で比較します。
まず基本をおさらいしましょう。
RAID 0はストライピングのみでパリティを持たないため、書き込み時に付加演算が不要です。
一方、RAID 5はパリティ生成のための読み出し・書き込み(Read-Modify-Write)が必ず伴います。
この差が、特にランダム書き込みや小容量トランザクションにおいて、明瞭な遅延差として現れます。
- RAID 0の書き込み遅延:パリティ演算ゼロ。ドライブ台数分の帯域をほぼ理論値通り活用可能。コントローラやCPUへの負荷も極めて低い
- RAID 5の書き込み遅延:パリティ用に最低2回の追加I/O(旧データ読み出し+旧パリティ読み出し+新データ書き込み+新パリティ書き込み)が発生。これが「書き込みペナルティ」=4倍のI/O負荷となる
では、具体的な数値イメージを下表にまとめます。
ただし、数値はコントローラ性能やキャッシュ実装で大きく変動するため、あくまで相対的な傾向値としてご覧ください。
| 評価項目 | RAID 0 | RAID 5(ハードウェア制御) | RAID 5(ソフトウェア制御) |
|---|---|---|---|
| シーケンシャル書き込み帯域 | 非常に高い(ほぼn倍) | 高い(パリティ演算で数%〜10%減) | 中程度(CPU依存で20%〜30%減) |
| ランダム書き込みIOPS | ドライブ合計に近い | ドライブ合計の約1/4〜1/3 | 同左だがさらにCPU競合で低下 |
| リビルド中の読み書き応答速度 | 対象外(障害=全損) | 通常時の50%〜70%に低下 | 通常時の30%〜50%に低下 |
| リビルド完了までの時間目安(4TB×4台) | − | 6〜12時間(専用コントローラ) | 12〜24時間以上(CPU負荷大) |
ここで見過ごせないのがリビルド時の振る舞いです。
RAID 5は障害ドライブを交換後、パリティからデータを再計算して全ドライブに書き戻します。
この間、コントローラまたはCPUは通常の書き込み処理に加えてリビルド用の演算とI/Oを優先割り当てする必要があり、結果としてユーザー書き込みのレイテンシが顕著に増大します。
特にソフトウェアRAIDでは、リビルドプロセスがシステム全体のスレッドコンテキストを消費し、他のアプリケーション性能にも影響を及ぼす点は重大です。
では、どちらが「パフォーマンスが高い」のか。
答えはワークロードで決まります。
単一の巨大ファイルを連続書き込みする映像編集やバックアップ用途であれば、RAID 0の圧倒的帯域が勝ります。
しかし、多数のクライアントからの小容量書き込みが頻発するデータベースや仮想マシン環境では、RAID 5の書き込みペナルティが無視できず、むしろRAID 0のほうが低レイテンシを維持できるケースすらあります。
もちろん、RAID 0はドライブ1台の故障で全データが消えるという致命的リスクと常に背中合わせです。
リビルド負荷を許容できるか。
それすらも性能評価の一部です。
RAID 5は「障害に強い」ではなく「障害時に著しく遅くなる」と捉えるべきで、その間に求められる応答品質を設計に組み込まねばなりません。
逆にRAID 0は、障害を前提とせず、バックアップや複製でデータを守る別経路を持っている場合にのみ、真価を発揮します。
結論を単純化しません。
書き込み遅延だけならRAID 0の圧勝。
しかし、運用中の総合的なスループットやメンテナンス性を含めた「実効パフォーマンス」としては、RAID 5も堅牢なコントローラと十分なキャッシュ(バッテリーバックアップ付き)を用意すれば、多くのビジネス用途で十分実用的です。
あなたのシステムが求めるのは、ピーク速度か、安定した平均応答か。
そこから逆算して選ぶべきです。
RAID 0とRAID 5、どちらのパフォーマンスが本当に優れているのか

まず結論めいたことを先に述べます。
「単純な速度」で見ればRAID 0が優位であり、「障害時の総合的な実効スループット」で見ればRAID 5にも十分な価値がある。
ただし、この二択はトレードオフの塊です。
多くの記事では「RAID 0は速いが危険」「RAID 5は安全だが遅い」と二分されがちですが、実際の運用では書き込みパターン、コントローラの性能、ドライブの種類、さらには障害発生後のリカバリータイムまで含めた「体感パフォーマンス」が問われます。
では、なぜこれほど評価が分かれるのか。
その理由は、RAIDの動作原理そのものにあります。
RAID 0はデータを複数ドライブに単純に分散書き込みするだけです。
パリティと呼ばれる誤り訂正用の冗長データを一切生成しないため、書き込み時に余計な演算が入りません。
その結果、CPUやコントローラへの負荷は最小限に抑えられ、理論上はドライブ台数分の帯域をほぼそのまま引き出せます。
たとえば1GB/s出るSSDを4台でストライピングすれば、シーケンシャル書き込みで3.5GB/s超えも夢ではありません。
これがRAID 0の最大の魅力です。
一方、RAID 5はパリティを各ドライブに分散保持します。
書き込みが発生するたびに、対象データの旧値と旧パリティを読み出し、新しいパリティを計算してから新データと新パリティを書き込むという、いわゆるRead-Modify-Writeプロセスが走ります。
このプロセスでは1回のユーザー書き込みに対して最低でも4回の内部I/Oが発生するため、特にランダムな小容量書き込みでは、RAID 0と比較して顕著な遅延増加が観測されます。
ただし、シーケンシャルな大容量書き込みでは、コントローラがパリティ演算を効率化するため、その差は数パーセントから10%程度に収まることも少なくありません。
ここで重要なのは、パフォーマンスを「帯域(スループット)」と「応答時間(レイテンシ)」の二軸で捉えることです。
帯域だけ見ればRAID 0の圧勝ですが、応答時間の観点では、コントローラに搭載された大容量キャッシュやバッテリーバックアップ付きライトバックキャッシュが効けば、RAID 5でも体感上の差は劇的に縮まります。
つまり、同じRAID 5でも実装によってパフォーマンスは桁違いに変わるという事実を無視できません。
また、ドライブの種類も大きく影響します。
HDDのようにシーク時間が支配的なストレージでは、RAID 5の追加I/Oが物理的なヘッド移動を増やし、遅延が顕著化します。
対して、ランダムアクセスに強いSSDでは、パリティ演算のオーバーヘッドが相対的に目立ちますが、その分、コントローラの処理能力がボトルネックになりやすいという特徴があります。
では、実際のワークロードでどれほどの差が出るのか。
一般的なベンチマークでは、RAID 0に対してRAID 5のランダムライトIOPSは約25%〜35%程度にまで低下するという報告が多数あります。
これは理論上の4分の1に近い数字であり、データベースのトランザクションログや仮想マシンのスワップファイルなど、頻繁に小さな書き込みが発生する用途では、RAID 5を選択することがパフォーマンス上の致命的なボトルネックになり得ることを示しています。
とはいえ、読み取り性能はRAID 5もRAID 0とほぼ同等か、むしろパリティを複数ドライブから並列読み出しできるため、シーケンシャルリードではRAID 5がRAID 0を上回るケースすらあります。
つまり、読み書きの比率が9対1のようなワークロードであれば、RAID 5の書き込みペナルティは実質的に無視できる水準となります。
ここで、パフォーマンス評価の落とし穴にも触れておきます。
多くのベンチマークツールは、完全な空の状態で測定を行うため、断片化や経年劣化を考慮していません。
実際の運用では、RAID 5はパリティの更新が繰り返されることでドライブ内部のフラグメンテーションが進みやすく、長期的にはRAID 0以上に書き込み性能が低下する傾向があります。
この点も含めると、「初期性能」だけで判断するのは危険です。
さらに、コントローラのファームウェア実装によっては、パリティ演算を専用のASICやFPGAでオフロードしているものと、CPUの汎算ユニットに依存しているものがあります。
後者のソフトウェアRAIDでは、書き込み時にCPU使用率が20%〜40%も跳ね上がることも珍しくなく、その結果、システム全体の応答性が損なわれるという二次的なパフォーマンス劣化も考慮すべきでしょう。
結論として、RAID 0とRAID 5の「どちらがパフォーマンスが高いか」は、使用するドライブの種類、コントローラの賢さ、そして何よりあなたのアプリケーションが書き込み主体か読み取り主体かで答えが分かれます。
速度だけを追い求めるならRAID 0。
しかし、障害時のリビルド負荷やデータ保全をパフォーマンスの一部と捉えるなら、RAID 5も十分に有力な選択肢です。
次の章では、この書き込み遅延のメカニズムをさらに掘り下げていきます。
書き込み処理の仕組みの違いがパフォーマンスを分ける

RAID 0とRAID 5のパフォーマンスギャップを正しく理解するには、まず「書き込み」という操作がストレージ内部でどのように処理されているのかを分解する必要があります。
表面のスペック表だけを見ていても、なぜランダムライトでこれほど差が開くのかは見えてきません。
ここでは、それぞれのアレイレベルが書き込み要求を受け取ってから完了するまでの内部シーケンスを、ステップ単位で比較していきます。
RAID 0の書き込み遅延
RAID 0の書き込みは、実にシンプルです。
コントローラがホストからデータブロックを受け取ると、それをストライプサイズ(通常64KB〜256KB)に分割し、各ドライブに並列で書き込み指令を発行します。
このとき、パリティ計算は一切発生しません。
また、書き込み前に既存データを読み出す必要もありません。
単純に「書くべき場所に書く」だけです。
この単純さがもたらす利点は二つあります。
一つは、CPUやコントローラ上の演算ユニットがほぼアイドル状態を保てること。
もう一つは、書き込み完了までのレイテンシが、実質的にドライブ単体の応答時間とストライピングによる並列化効果の合計で決まることです。
たとえば、4台のドライブにそれぞれ4KBのデータを分散書き込みする場合、各ドライブは4KB分の書き込みを同時に実行するため、全体の完了時間は1台分の書き込み時間とほぼ等しくなります。
- パリティ生成のための計算コストがゼロ
- 読み出しを伴わないため、ディスクの回転待ちやシーク遅延が追加発生しない
- 書き込みキャッシュが有効な場合、コントローラは即座にホストへ完了応答を返せる
ただし、RAID 0にもボトルネックは存在します。
それはストライプサイズをまたがる書き込みです。
たとえば、512バイトのような小さなデータがストライプ境界をまたぐ場合、コントローラは複数ドライブに跨る処理を調整する必要が生じ、わずかにオーバーヘッドが増加します。
とはいえ、その増加分はパリティ演算と比較すれば微々たるものです。
総じて、RAID 0の書き込み遅延は「ドライブの物理性能にほぼ直結する」と言って差し支えありません。
RAID 5の書き込み遅延
ここからが本題です。
RAID 5の書き込みは、表面の帯域数値だけを見ていると見落としがちな複雑な内部処理を伴います。
RAID 5では、書き込み対象のデータに対してパリティを生成し、それをストライプグループ内の別ドライブに格納する必要があります。
しかし、パリティは「そのストライプグループ内の全データブロックのXOR」で計算されるため、新しく書き込むデータだけではパリティを確定できません。
そこで登場するのがRead-Modify-Write(RMW)という処理手順です。
RMWは以下の4ステップで進行します。
- 書き込み対象のデータブロックに含まれる旧データを該当ドライブから読み出す
- 同じストライプグループ内の旧パリティをパリティドライブから読み出す
- 旧データと旧パリティと新データを使ってXOR演算を行い、新パリティを算出する
- 新データを対象ドライブに、新パリティをパリティドライブにそれぞれ書き込む
この4ステップが、ユーザーから見た1回の書き込み要求に対して内部的に実行されます。
つまり、RAID 5のライトペナルティは理論上「4」であり、IOPSベースで比較すると、同じドライブ構成のRAID 0に対して約4分の1のランダム書き込み性能しか発揮できないことになります。
ただし、実際にはコントローラのキャッシュや書き込みの連続性によってこのペナルティは緩和されます。
たとえば、フルストライプ書き込み(ストライプサイズ全体を一度に書き換えるケース)では、旧データの読み出しが不要になるため、ペナルティは「2」(新データ書き込み+新パリティ書き込み)まで低下します。
ここで見逃せないのが、部分書き込みが頻発するワークロードにおける悪影響です。
データベースのログファイルやメタデータ更新のように、4KB〜16KB単位のランダムライトが主体となる環境では、ほとんどの書き込みがRMWの対象になります。
その結果、ドライブの物理的なヘッド移動が増え、SSDであればコントローラ内部のGC(ガベージコレクション)とRMWが競合し、さらにレイテンシが変動します。
この変動性こそが、RAID 5が「予測しにくいパフォーマンス」と評される所以です。
また、パリティ演算そのものも無視できない負荷です。
ソフトウェアRAIDではXOR演算がメインCPUのリソースを消費し、特に古いプロセッサやエントリーモデルのNASでは、書き込み時にCPU使用率が50%を超えることも珍しくありません。
その結果、システム全体の応答性が低下し、ネットワークスループットや他のアプリケーション性能にも影響が波及するという二次的な遅延が発生します。
さらに、コントローラがライトバックキャッシュを搭載している場合、ホストへの完了応答はキャッシュへの書き込み完了時点で返されるため、見かけ上の遅延は大幅に短縮されます。
しかし、これはあくまで見かけ上の遅延であり、キャッシュから実際のドライブへのフラッシュ処理は非同期で後続するため、キャッシュが満杯になった瞬間に急激なレイテンシスパイクが発生する点には留意が必要です。
これらの違いを整理すると、RAID 0が「単純で速い」のに対し、RAID 5は「賢いが重い」という構造的トレードオフがあることが明確になります。
書き込み遅延だけで評価するなら、RAID 0に軍配が上がるケースが大半ですが、その差はワークロードのパターンとコントローラの実装次第で大きく変動するというのが実情です。
シーケンシャル書き込みとランダム書き込みで結果はこう変わる

前章ではRAID 0とRAID 5の書き込み処理の内部構造を比較しましたが、実際の運用で最も影響が大きいのは「書き込みパターン」です。
同じRAID 5でも、大きなファイルを連続して書き込む場合と、小さなデータを無秩序に書き込む場合では、体感性能がまったく異なります。
ここでは、シーケンシャル書き込みとランダム書き込みという二つの代表的ワークロードに分けて、両者の実効パフォーマンスを定量的に評価します。
まずシーケンシャル書き込み、つまり映像ファイルやバックアップデータのように、連続したアドレスに大量のデータを書き込むケースです。
この場合、RAID 0は各ドライブに均等にデータを振り分けるため、総帯域はほぼドライブ台数に比例して増加します。
たとえば200MB/sのHDDを4台使えば、理論上の上限は800MB/sですが、実際にはコントローラのオーバーヘッドやバス帯域の制約で700MB/s前後が現実的な値となります。
一方、RAID 5のシーケンシャル書き込みでは、パリティ演算が発生するものの、書き込み対象がストライプサイズ(典型的には64KB〜1MB)よりも大きい場合、フルストライプ書き込みが連続するため、Read-Modify-Writeのペナルティが大幅に軽減されます。
具体的には、新データと新パリティの2回の書き込みで済むため、理論上のペナルティは「2」にまで下がります。
その結果、RAID 0との差は帯域で10%〜20%程度に収まることが多いです。
コントローラがハードウェアオフロードに対応している場合は、その差は5%未満にまで縮まるケースもあります。
ただし、ここで注意すべきはディスクの物理特性です。
HDDの場合、シーケンシャル書き込みはプラッタの回転に沿ってヘッドが移動するため、シーク時間がほぼゼロに近くなります。
そのため、RAID 5の追加書き込みも比較的スムーズに処理されます。
しかしSSDの場合は、シーケンシャル書き込みでもコントローラ内部のウェアレベリングやブロック消去が入るため、RAID 5のパリティ演算負荷が相対的に目立ちやすく、差が15%〜25%に拡大する傾向があります。
では、ランダム書き込みはどうでしょうか。
ここで一気に両者の差が開きます。
ランダム書き込みでは、書き込み対象がストライプサイズ未満の小さなブロック(4KB〜16KB)になることが多く、RAID 5はほとんどの書き込みでRead-Modify-Writeの4ステップを強制されます。
その結果、RAID 5のランダム書き込みIOPSは、RAID 0の約25%〜35%に低下します。
これはドライブ台数や容量に関わらず、ほぼ一律に現れる構造的なペナルティです。
具体的な数値を挙げましょう。
エンタープライズ向けの10K rpm SAS HDDを4台使用した構成で、4KBランダムライトを測定した場合、RAID 0で約600 IOPS出るのに対し、RAID 5は多くても150〜200 IOPS程度にとどまります。
SSD(SATAベース)の場合は、RAID 0で約40,000 IOPS、RAID 5では10,000〜12,000 IOPSという結果が一般的です。
この差は、データベースのトランザクションログやメールサーバのスプール領域など、頻繁に小さな書き込みが発生するシステムにおいて、致命的なボトルネックとなり得ます。
ここで、ワークロードごとの特徴を整理するために、以下の表をご覧ください。
| ワークロード | RAID 0の実効帯域 | RAID 5の実効帯域(HWコントローラ) | RAID 5の実効帯域(SWコントローラ) | 主なボトルネック |
|---|---|---|---|---|
| シーケンシャル大容量(1MB以上) | ドライブ台数×性能の90%〜95% | 同80%〜90% | 同65%〜80% | バス帯域 / CPU演算 |
| シーケンシャル中容量(64KB〜1MB) | 同85%〜90% | 同70%〜80% | 同55%〜70% | ストライプ境界オーバーヘッド |
| ランダム小容量(4KB〜16KB) | ドライブ単体IOPS×台数の80%〜90% | 同25%〜35% | 同15%〜25% | RMWプロセス / シーク時間 |
| ランダム大容量(64KB以上) | 同70%〜80% | 同30%〜45% | 同20%〜35% | キャッシュヒット率 / ディスク回転待ち |
この表から読み取れるのは、RAID 5の弱点は「小さいランダム書き込み」に極めて集中しているという事実です。
逆に言えば、ワークロードがシーケンシャル主体であれば、RAID 5のデメリットは実用上ほとんど気にならないレベルまで緩和されます。
また、コントローラのキャッシュ容量が大きい場合、ランダム書き込みでもキャッシュ上でまとめられてからフラッシュされるため、見かけ上のIOPSは向上します。
ただし、キャッシュが溢れた瞬間にスパイク状の遅延が発生する点は、リアルタイム性が要求されるシステムではリスク要因となります。
加えて、ファイルシステムの種類やフォーマット時のアライメント設定も無視できません。
たとえば、NTFSやext4のデフォルトクラスタサイズが4KBである場合、RAID 5のストライプサイズ(通常64KB〜256KB)とのミスマッチが発生し、部分書き込みの頻度がさらに高まります。
この場合、ストライプサイズをファイルシステムのクラスタサイズに合わせて調整することで、ペナルティを若干軽減できる可能性があります。
結局のところ、シーケンシャル主体ならRAID 5でも十分実用的な帯域が出るが、ランダム主体ならRAID 0か、あるいはRAID 10などの別構成を検討すべきです。
「どちらが速いか」ではなく、「自分の書き込みパターンがどちらに近いか」で判断することが、正しい選択への第一歩となります。
コントローラとキャッシュが遅延に与える影響

ここまでの比較では、RAID 0とRAID 5の書き込み遅延を「アーキテクチャ上の原理」として論じてきました。
しかし現実のストレージシステムにおいて、この理論値はコントローラの実装とキャッシュ戦略によって大きく覆されます。
同じRAID 5でも、安価なソフトウェア実装と高価なハードウェアRAIDカードでは、体感速度に数倍の開きが出ることは珍しくありません。
本章では、コントローラとキャッシュという「見えない要素」が書き込み遅延にどう影響するのかを掘り下げます。
まず、コントローラの役割を再定義しましょう。
コントローラはホストからのI/O要求を受けて、RAIDアルゴリズムに従って各ドライブへのアクセスをスケジューリングする処理中枢です。
このとき、パリティ演算をどこで行うかが最初の分水嶺になります。
ソフトウェアRAIDでは、メインCPUがXOR演算を担当するため、書き込み処理中はCPUリソースが消費されます。
特にランダムライトが頻発すると、CPU使用率が30%〜50%に達し、システム全体の応答性が損なわれます。
一方、ハードウェアRAIDコントローラは専用のXORエンジンやASICを搭載しており、パリティ演算を完全にオフロードします。
この場合、CPUはI/O要求の発行と完了割り込みの処理だけで済むため、システム負荷は大幅に軽減されます。
結果として、RAID 5の書き込みペナルティが理論値の4倍から実質2倍近くまで圧縮されることもあります。
つまり、同じRAID 5でもコントローラ次第でパフォーマンスが倍以上変わるというのが実情です。
次にキャッシュの存在です。
キャッシュには主に二つの種類があります。
一つはコントローラ上の揮発性メモリ(DRAM)を用いたライトバックキャッシュ。
もう一つはドライブ自身が持つ内蔵キャッシュです。
このうち、ライトバックキャッシュが有効な場合、ホストからの書き込み要求はドライブへの実際の書き込み完了を待たずに、キャッシュへ格納された時点で「完了」として応答されます。
これにより、書き込みレイテンシはキャッシュのアクセス速度(通常は数マイクロ秒)まで短縮され、RAID 0とRAID 5の差がほぼ消滅するという現象が起こります。
ただし、この効果は永遠に続くわけではありません。
キャッシュが満杯になると、コントローラはキャッシュ内容をドライブへフラッシュする必要が生じ、その間の新規書き込み要求は待たされることになります。
このフラッシュ処理中には、RAID 5のRMWプロセスがそのまま実行されるため、一瞬ですが大きなレイテンシスパイクが観測されます。
リアルタイム性が要求されるシステムでは、このスパイクが問題になることも少なくありません。
加えて、キャッシュの保護機構も考慮すべきです。
バッテリーバックアップユニット(BBU)やスーパーキャパシタを搭載したコントローラでは、停電時でもキャッシュデータを保護できるため、ライトバックキャッシュを安全に有効化できます。
しかし、これらの保護機構がない場合は、ライトスルーキャッシュ(書き込み完了をドライブ実書き込みまで待つ)に強制されることが多く、その場合、RAID 5の遅延はほぼ理論値通りに現れます。
ここで、コントローラとキャッシュの組み合わせによる影響を整理するために、以下の表をご覧ください。
| コントローラ種別 | キャッシュモード | RAID 5のランダムライトIOPS(4台SSD) | 遅延スパイクの有無 | 停電時のリスク |
|---|---|---|---|---|
| ソフトウェアRAID | ライトスルー(不可) | 8,000〜10,000 | なし(常に高遅延) | 低(即時書き込み) |
| エントリーハードウェア | ライトバック(BBUなし) | 15,000〜20,000 | あり(フラッシュ時) | 高(データ損失可能性) |
| ミドルレンジHW+BBU | ライトバック(保護あり) | 25,000〜35,000 | あり(但し頻度低) | 低(バッテリ保護) |
| ハイエンドHW+大容量キャッシュ | ライトバック+最適化 | 35,000〜50,000 | ほぼなし(適応制御) | 極低(冗長保護) |
この表から分かるのは、コントローラへの投資がRAID 5の実効性能を決める最大の要因であるということです。
また、キャッシュ容量も重要で、大容量キャッシュ(2GB以上)を搭載したコントローラでは、複数のランダムライトをキャッシュ上でまとめてシーケンシャルなフラッシュに変換する「ライトアグリゲーション」機能が働き、実質的なペナルティをさらに低減できます。
ただし、ここで落とし穴もあります。
キャッシュに依存しすぎると、ベンチマーク時には極めて高いスコアが出る一方で、長時間の高負荷時にはキャッシュオーバーフローによる急激な性能低下が発生します。
この「持続性能」と「ピーク性能」のギャップは、特に動画編集や大規模データベースのような継続的ライトワークロードでは致命傷になり得ます。
結論として、RAID 5の書き込み遅延を語るなら、コントローラとキャッシュの仕様を無視することはできません。
同じRAID 5でも、OS標準のソフトウェアRAIDと、2GBキャッシュ+BBU搭載のハイエンドカードでは、実用上のパフォーマンスが別物です。
予算と要件に応じて、この中間領域をどう設計するか。
それが、RAID選択における第二の重要な判断軸となります。
リビルド時の負荷

ここまでは正常時における書き込みパフォーマンスに焦点を当ててきました。
しかし、RAIDの真価が問われるのは障害発生時です。
特にRAID 5はドライブ1台の故障を許容する代わりに、交換後のリビルド(再構築)プロセスにおいて、システム全体の応答性が著しく低下するという代償を払います。
このリビルド負荷は、単なる「復旧時間」だけでなく、その間のユーザー書き込み応答にまで深刻な影響を及ぼします。
本章では、リビルドが実際のパフォーマンスにどう波及するのかを、定量的かつ多角的に検証します。
リビルド中の書き込み応答はどこまで劣化するか
リビルド中、コントローラは障害ドライブに代わってパリティからデータを再計算し、新しいドライブへ書き戻すという膨大なI/O処理を実行します。
この処理は通常のユーザーI/Oと競合するため、書き込み応答時間は常時の2倍から4倍に延長されるのが一般的です。
具体的な事例を挙げると、4TBのHDDを4台で構成したRAID 5において、リビルド中に4KBランダムライトを発行した場合、平均レイテンシが常時5msから15ms〜20msに悪化したという測定結果があります。
この劣化のメカニズムは単純です。
コントローラはリビルド用の読み取り(パリティ+他ドライブのデータ)と書き込み(新ドライブへの復元データ)に帯域を割くため、ユーザー書き込みに割り当てられる内部I/Oキューが圧迫されます。
特にRAID 5では、ユーザー書き込み自体がRMWで4回の内部I/Oを要するため、リビルドI/Oが加わることでキュー深度が容易に飽和状態に達します。
さらに悪いことに、リビルド中の書き込みはランダムアクセスであるほど影響が顕著です。
シーケンシャル書き込みであれば、コントローラがリビルドとユーザーI/Oを時間軸で分割して処理できるため、帯域の割合を調整することである程度の応答を確保できます。
しかしランダム書き込みでは、シークやコマンド再 ordering のオーバーヘッドが重なり、結果として両方の処理が非効率になります。
リビルド時間を左右する要因
リビルド完了までの時間は、単に「ドライブ容量÷書き込み速度」では計算できません。
実際には以下の要因が複雑に絡み合います。
- ドライブの容量と回転数(またはSSDのNAND種類):大容量ほどリビルド対象データ量が増える。また、HDDは内周と外周で転送速度が異なるため、完了時間にばらつきが生じる
- コントローラのリビルド優先度設定:多くのRAIDコントローラはリビルド優先度を「低・中・高」で調整可能。優先度を上げるとリビルド時間は短縮されるが、その分ユーザーI/Oが犠牲になる
- アレイの稼働率:リビルド中にユーザーからの読み書き要求がどれだけあるか。アイドル状態ならリビルドは最大速度で進行するが、負荷が高いと著しく遅延する
- パリティの分散配置とストライプサイズ:ストライプサイズが大きいほど1回のリビルド読み取りで取得できるデータ量が増え、効率が向上する傾向がある
具体例として、4TBドライブ4台(実効容量約12TB)のRAID 5を、ハードウェアコントローラでリビルドする場合、アイドル時で6〜10時間が目安です。
しかし、ファイルサーバとして常時100MB/s前後の読み書きが発生している環境では、完了までに24時間以上を要することも珍しくありません。
この間に次のドライブが故障すれば、アレイ全体がクラッシュする二重障害のリスクが現実のものとなります。
ソフトウェアRAIDとハードウェアRAIDのリビルド負荷差
ここで、リビルド負荷の差が最も顕著に現れるのが、ソフトウェアRAIDとハードウェアRAIDの比較です。
ソフトウェアRAID(LinuxのmdadmやWindowsのストレージスペースなど)では、リビルド処理がすべてメインCPUのスレッドとして実行されます。
そのため、リビルド中はCPU使用率が常時20%〜40%上昇し、システム上の他のプロセス(Webサーバやデータベース)に直接影響を与えます。
特にエントリーレベルのCPU(Intel CeleronやAMD Athlonなど)では、リビルドだけでCPUリソースが枯渇し、ユーザー書き込みの応答が数秒単位で遅延することもあり得ます。
また、ソフトウェアRAIDはI/OスケジューリングがOSの汎用スケジューラに依存するため、リビルドとユーザーI/Oの優先制御が粗くなりがちです。
結果として、リビルド中のランダムライトIOPSは、常時の30%〜50% まで低下するというデータが複数のベンチマークで報告されています。
これに対してハードウェアRAIDコントローラは、リビルド専用の演算ユニットと独立したI/Oプロセッサを搭載しており、リビルド処理を完全にバックグラウンドで実行できます。
そのため、CPUへの負荷はほぼゼロに等しく、ユーザーI/Oへの影響も相対的に小さくなります。
ただし、それでも帯域競合は避けられず、ランダムライトの応答は常時の60%〜80% 程度に低下するのが実状です。
さらに、ハイエンドコントローラでは「リビルドレート」を動的に調整する機能が搭載されており、ユーザーI/Oが活発なときはリビルドを自動的に減速させ、アイドル時に再加速させる適応制御が可能です。
この機能により、リビルド中のピークレイテンシを抑えつつ、完了時間もある程度確保できるというメリットがあります。
総合すると、リビルド負荷を軽視してRAID 5を選ぶと、障害時に「使えないストレージ」と化すリスクがあります。
リビルド中のパフォーマンス劣化を許容できるかどうか。
それもまた、RAID選択における重要な判断材料です。
ワークロード別 最適なRAIDレベルを選ぶ基準

ここまで、書き込み遅延とリビルド負荷という二つの軸からRAID 0とRAID 5を比較してきました。
しかし、最終的な選択は理論値だけで決まるものではなく、実際のワークロードが何を要求しているかに尽きます。
同じ「速度が欲しい」という目的でも、動画編集とデータベース処理では求められる特性が根本的に異なります。
本章では、具体的なユースケースごとに、どちらのRAIDレベルが適しているかを整理します。
RAID 0が向くユースケース
RAID 0の最大の強みは、書き込み帯域の高さとレイテンシの低さです。
そして、その裏返しとして「障害耐性がゼロ」というリスクを許容できる環境でこそ、真価を発揮します。
具体的には以下のようなワークロードが該当します。
- 映像編集や3Dレンダリングのキャッシュ領域:巨大な中間ファイルを高速に読み書きする必要があるが、データは元のソースから再生成可能であるため、障害時の損失が作業ロスだけで済む
- ゲームのインストールドライブ:ロード時間の短縮が目的で、セーブデータは別途クラウドや別ドライブにバックアップする運用が前提
- スクラッチディスクや一時ファイル用ストレージ:PhotoshopやAfter Effectsのスクラッチ領域など、再作成が容易で高速性が最優先される領域
- 高性能なキャッシュサーバー:RedisやMemcachedのようなインメモリキャッシュのスワップ先として、速度が求められるがデータ永続性は二の次
これらのケースに共通するのは、「データの冗長性よりもスループットを優先する」という明確な意思決定があります。
また、RAID 0はリビルドという概念が存在しないため、障害時は単純にバックアップからリストアするだけです。
その分、運用中のパフォーマンス変動が極めて少なく、予測可能な応答時間が得られる点も見逃せません。
ただし、注意点もあります。
RAID 0を採用する場合、バックアップの頻度と復旧手順を徹底的に見直す必要があります。
たとえば、1時間ごとの増分バックアップと、毎日のフルバックアップを組み合わせるなど、障害時のデータ損失量を許容範囲に収める運用設計が必須です。
また、ドライブ台数が増えるほど故障確率は線形に上昇するため、4台以上で組む場合は「いつ壊れてもおかしくない」という覚悟を持ってください。
RAID 5が向くユースケース
RAID 5は、「一定の速度を維持しながら、単一ドライブ障害からの復旧を自動化したい」という要件に応えるアレイです。
書き込みペナルティは存在するものの、読み取り性能はRAID 0とほぼ同等であり、シーケンシャル主体のワークロードでは実用上問題になりません。
具体的なユースケースは以下の通りです。
- ファイルサーバーやNAS(ネットワークアタッチトストレージ):複数ユーザーが同時にアクセスするオフィス環境では、読み取りが大多数を占め、書き込みも大容量ファイルが中心となるため、RAID 5のペナルティが相対的に小さい
- バックアップ用ストレージ:夜間のバッチ書き込みが主体で、リビルド中の速度低下も許容できる。容量効率の良さ(総容量のn-1台分)がメリットとして大きい
- 監視カメラの録画ストレージ:シーケンシャル書き込みが継続的に発生するが、書き込み遅延よりも総容量と障害耐性が重視される
- 小規模なWebサーバーやメールサーバー:読み取り要求が圧倒的に多く、書き込みは設定変更やログ出力程度。RAID 5の冗長性がシステム停止リスクを軽減する
- ソフトウェア開発のビルドマシン:ソースコードのリポジトリやビルド中間物を格納する領域。書き込みはコンパイル時に発生するが、読み取り頻度がそれを上回る
ここで重要なのは、RAID 5は「書き込みが少なく、読み取りが多い」環境で最も効果を発揮するという点です。
もしあなたのシステムが読み書き比率で9:1以上であれば、RAID 5はほぼ理想的な選択肢と言えます。
また、ハードウェアコントローラに十分なキャッシュを搭載すれば、ランダム書き込みのペナルティもかなり緩和されるため、汎用ファイルサーバーとしては非常にバランスの取れた構成です。
ただし、RAID 5が不向きなケースも明確です。
それはトランザクションログやデータベースのWAL(Write-Ahead Log)のように、頻繁な小容量ランダムライトが発生する領域です。
このようなワークロードでは、書き込みペナルティが直接応答時間に響くため、RAID 5は避けるべきです。
その場合はRAID 10(ストライピング+ミラーリング)や、そもそもRAIDを使わずに高速なNVMe SSDを単体で運用するほうが賢明です。
最終的には、「速度」「容量効率」「障害耐性」「運用コスト」の4つのバランスをどう取るかが問われます。
RAID 0は速度と容量効率に極振りし、障害耐性を運用で補う選択。
RAID 5は速度をやや犠牲にして障害耐性と容量効率を両立させる選択。
この軸を、自身のワークロードに当てはめて判断してください。
障害時のリスクと運用コストをどう見積もるか

パフォーマンス比較の最終局面で、必ず立ちはだかるのが「障害時のリスク」と「それを支える運用コスト」です。
RAID 0は高速ですが、ドライブ1台の故障で全データが消失します。
RAID 5は1台の障害を許容しますが、リビルド中のパフォーマンス劣化と、その間に2台目が壊れる二重障害リスクを抱えています。
ここでは、これらのリスクを数値化し、さらにバックアップ体制や交換作業まで含めた総合的な運用コストを評価します。
まず、RAID 0の障害リスクは極めて直感的です。
ドライブがn台あれば、年間故障率(AFR)が例えば2%の場合、アレイ全体の年間故障確率はおよそ 1 – (0.98)^n で計算されます。
4台構成なら約7.8%、8台なら約15%に達します。
これは「4年に1回は何かが壊れる」という現実的なリスクです。
このリスクに対して、RAID 0ではバックアップからのリストアが唯一の復旧手段となります。
リストア時間はバックアップ媒体の速度とデータ量に依存し、数十TBのデータであれば丸1日以上かかることも珍しくありません。
その間、システムは完全に停止します。
一方、RAID 5の年間故障確率は、単一ドライブのAFRだけでなく、リビルド中の追加故障確率も考慮する必要があります。
一般的に、リビルド時間が10時間、その間のドライブ負荷が高まると、AFRが一時的に2倍から3倍に上昇すると言われています。
この条件で4台構成のRAID 5を運用する場合、年間の二重障害(データ喪失)確率は約0.5%〜1%程度と試算されます。
これはRAID 0と比較すれば桁違いに低いですが、決してゼロではないという事実は肝に銘じるべきです。
ここで、リスク評価においてしばしば見落とされるのが「サイレントデータ破損」の問題です。
RAID 5はパリティを用いて障害ドライブのデータを復元できますが、読み取り時にパリティ不一致が発生した場合、どのドライブのデータが正しいのかを自動判別することはできません。
特にビットローテーションやファームウェアバグによるサイレントエラーは、RAIDの冗長性をもってしても検出が難しい領域です。
このため、エンタープライズ向けのRAIDコントローラでは定期的なパトロールリードや整合性チェック機能が実装されていますが、これらは運用負荷を追加する要因でもあります。
運用コストの観点では、RAID 0は「バックアップ運用の厳格化」という人的コストが主です。
毎日または数時間おきのバックアップジョブの監視、リストア手順の定期訓練、バックアップメディアの枯渇管理など、運用者のスキルと工数が求められます。
また、障害発生時は即座に代替ドライブを手配し、リストアを開始するためのオペレーション体制が必要です。
これらのコストは、システムの重要度に比例して指数関数的に増加します。
RAID 5の運用コストは、バックアップに加えて「スペアドライブの在庫管理」と「リビルド監視」が追加されます。
障害が発生した場合、コントローラは自動的にリビルドを開始しますが、その進行状況を監視し、異常な遅延や停止が起きていないかを確認する作業が発生します。
また、リビルド中はシステム負荷が高まるため、ユーザーへの影響を最小化するために、リビルド優先度の調整や業務時間外のリビルド実行など、計画的な運用設計が求められます。
さらに、RAID 5ではドライブの交換作業そのものにもコストがかかります。
ホットスワップ対応の筐体であれば稼働中に交換可能ですが、非対応の場合はシステム停止が必要です。
また、交換用ドライブは同一ファームウェアバージョンや同一ロット番号で揃えることが推奨されるため、調達コストや在庫管理の手間が無視できません。
異なるロットのドライブを混在させると、リビルド中にパフォーマンスにばらつきが生じ、完了時間が予測以上に延長されるリスクがあります。
これらのリスクとコストを定量的に比較するために、以下の表を用意しました。
年間想定障害率、復旧時間、運用工数を総合的に評価しています。
| 評価項目 | RAID 0(4台HDD) | RAID 5(4台HDD) | RAID 5(4台SSD) |
|---|---|---|---|
| 年間データ消失確率(推定) | 7%〜8% | 0.5%〜1% | 0.3%〜0.7% |
| 障害発生時の復旧時間目安 | リストア時間(8〜24時間) | リビルド時間(6〜12時間) | リビルド時間(2〜4時間) |
| 復旧中のユーザー影響 | 全停止(リストア完了まで) | 性能低下(60%〜80%の応答) | 性能低下(70%〜85%の応答) |
| 月間運用監視工数(目安) | バックアップ確認で2時間 | バックアップ+リビルド訓練で3時間 | 同左+SSD寿命監視で4時間 |
| スペアードライブ在庫コスト | 不要(バックアップのみ) | 1台分の調達費用(年間維持) | 同左(SSDはより高額) |
この表から読み解けるのは、RAID 5は障害確率を大幅に低減する代わりに、運用の複雑性と監視コストが増加するというトレードオフです。
また、SSDを採用すればリビルド時間は短縮されますが、その分、書き込み寿命(TBW)の監視という新たな運用項目が加わります。
最終的には、このリスクとコストを「許容できるか」で判断します。
重要なのは、RAIDレベル自体がバックアップの代替にはならないという原則です。
RAID 5でも、火災や盗難、ランサムウェアなどの物理的・論理的障害には対応できません。
したがって、オフサイトバックアップやクラウド複製など、RAIDとは別階層の冗長化を必ず併用することが、真のデータ保護戦略となります。
その上で、RAID 0を選ぶのかRAID 5を選ぶのかは、速度と運用コストのバランスをどう取るかという経営的判断に委ねられます。
パフォーマンス評価の総合結論 速度と安定性のどちらを優先するか

ここまで、書き込み遅延、リビルド負荷、コントローラの影響、ワークロード別の適性、そして障害リスクと運用コストに至るまで、多角的にRAID 0とRAID 5を比較してきました。
では、最終的にどちらを選ぶべきなのか。
その答えは「あなたのシステムが求める優先順位」によって一意に決まります。
本章では、すべての要素を統合した上で、判断軸を明確に示します。
まず大前提として、RAID 0は「速度」に全振りしたアーキテクチャです。
書き込みレイテンシは最も短く、シーケンシャル帯域もドライブ台数に比例して伸びます。
演算オーバーヘッドがほぼゼロであるため、CPU負荷も最小限です。
ただし、その代償として障害耐性がまったくなく、1台の故障が即座に全データ消失へ直結します。
このリスクを許容できるのは、データが常に別の場所に複製されているか、再生成が容易な場合に限定されます。
一方、RAID 5は「安定性と容量効率のバランス」を重視した設計です。
1台のドライブ障害に耐えられる冗長性を持ちながら、実効容量は総容量のn-1台分と、ミラーリング(RAID 1やRAID 10)よりも効率的です。
ただし、書き込み時には必ずパリティ演算と読み出しが伴うため、特にランダムライトではRAID 0と比較して著しい性能低下が発生します。
また、リビルド中はユーザー応答が劣化し、その間に2台目の障害が起きるリスクもゼロではありません。
ここで重要なのは、「パフォーマンス」の定義をどこに置くかです。
ピークスループットを重視するのか、平均応答時間の安定性を重視するのか、あるいは障害発生時を含めた長期的なスループットを重視するのか。
この定義が異なれば、最適解も変わります。
たとえば、深夜のバッチ処理で最大帯域が必要なシステムと、営業時間中のトランザクション応答が命題のシステムでは、まったく異なるRAIDレベルが求められるでしょう。
以下の総合比較表は、これまでの議論を一つの表に集約したものです。
評価項目ごとに、どちらのRAIDが優位かを「◎」「○」「△」「×」で示しています。
| 評価項目 | RAID 0 | RAID 5 | 備考 |
|---|---|---|---|
| シーケンシャル書き込み帯域 | ◎ | ○(HW制御で◎に近づく) | RAID 5はフルストライプ時はほぼ同等 |
| ランダム書き込みIOPS | ◎ | ×(SW制御では△) | ペナルティ4倍が大きく影響 |
| 読み取り性能 | ◎ | ◎ | 両者ほぼ差なし(並列読み出し効果) |
| 障害耐性(単一ドライブ故障) | × | ○ | RAID 0は全損、RAID 5は継続運用可能 |
| リビルド中の応答安定性 | −(該当なし) | △ | 帯域・IOPSともに30%〜50%低下 |
| 容量効率(n台構成) | ◎(100%) | ○((n-1)/n) | RAID 5は1台分の容量をパリティに消費 |
| 運用監視コスト | ○(バックアップ管理のみ) | △(リビルド監視+スペア管理) | RAID 5は障害時のオペレーションが複雑 |
| CPU負荷(ソフトウェアRAID時) | ◎(ほぼゼロ) | △(書き込み時20%〜40%上昇) | HWコントローラでこの差は解消される |
この表を眺めて、真っ先に気づくのは「RAID 0の優位性は書き込み性能とコスト効率に偏っており、RAID 5の優位性は障害耐性と読み取り性能に偏っている」という単純な構図ではないことです。
実際には、コントローラのグレードやキャッシュ戦略によって、RAID 5の弱点は大幅に緩和されるため、予算に余裕があるならハードウェアRAID+BBU搭載キャッシュを導入することで、RAID 0にかなり接近した書き込み性能を実現できます。
では、具体的な選択基準を提示します。
以下の条件に一つでも当てはまるなら、RAID 0を検討してください。
- データのバックアップが完全に別系統で確保されており、リストア時間が許容範囲内である
- 書き込み性能がシステムのボトルネックであり、かつ書き込みパターンがシーケンシャルまたは大容量ブロック主体である
- ドライブ台数が少なく(2〜3台)、障害確率が統計的に無視できる水準にある
- 開発環境や検証環境など、ダウンタイムより速度が優先される非本番システムである
逆に、以下の条件に該当するなら、RAID 5を選ぶべきです。
- 24時間365日稼働する本番システムであり、単一ドライブ障害でもサービス継続が求められる
- 読み取り要求が書き込みの3倍以上を占めており、書き込みペナルティの影響が相対的に小さい
- ストレージ容量を効率的に使いたいが、RAID 10ほどの予算やドライブ本数を割けない
- ハードウェアRAIDコントローラを導入でき、かつバッテリーバックアップキャッシュでライトバックを有効化できる
最後に、どちらを選んだとしても、RAIDは「高可用性」の一部であって「バックアップ」ではないという原則を忘れないでください。
RAID 5は単一障害に強いだけで、ファイルシステムの破損やオペミス、ランサムウェアには無力です。
したがって、RAID 0を選ぶにせよRAID 5を選ぶにせよ、オフサイトバックアップやスナップショット機能を必ず併設することを強く推奨します。
結局のところ、速度と安定性はトレードオフの関係にあります。
そのトレードオフをどこで折り合いをつけるかは、あなたの運用哲学と予算次第です。
この記事が、その判断のための羅針盤となれば幸いです。


コメント