1
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@neko718rs(neko718rs)

クラウドネイティブ時代におけるストレージ冗長化のベストプラクティス

1
Last updated at Posted at 2026-03-11

はじめに

オンプレミスやクラシックなベアメタルサーバー（BMS）環境で長年インフラを運用してきたエンジニアにとって、「ストレージの冗長化 ＝ RAIDを組む」は身体に染み付いた常識である。RAID5でパリティを守り、ホットスペアを待機させ、障害時はコピーバックで元の構成に復旧する。

しかし、クラウドネイティブな設計思想ではこの前提が根本的に異なる。

本記事では、オンプレ・ベアメタルの運用経験者がクラウドネイティブへ移行する際に理解すべきストレージ冗長化の考え方のパラダイムシフトと、そのベストプラクティスを整理する。

1. パラダイムシフト：「ディスクを守る」から「データを正しい場所に置く」へ

旧来の思想（オンプレ・BMS）

データを守る ＝ ディスクを冗長化する（RAID）
前提：サーバーは壊れない。ディスク障害から守れば十分。

クラウドネイティブの思想

データを守る ＝ データの保存先を用途に応じて分離する
前提：インスタンスは壊れる。いつでも捨てて作り直せる設計にする。

この思想転換を理解しないまま、クラウド上でもローカルディスクにRAIDを組んでデータを守ろうとすると、クラウドのメリットを享受できない運用に陥る。

2. クラウドネイティブにおけるストレージの3層構造

クラウドネイティブな設計では、ストレージを用途と永続性のレベルに応じて3層に分類する。

┌──────────────────────────────────────────────────┐
│  Layer 3: オブジェクトストレージ（最終的な耐久性）    │
│  Amazon S3 / IBM COS / Google Cloud Storage       │
│  耐久性: 99.999999999%（イレブンナイン）             │
│  用途: バックアップ、ログアーカイブ、静的データ       │
├──────────────────────────────────────────────────┤
│  Layer 2: ブロックストレージ（永続データ）            │
│  Amazon EBS / VPC Block Storage / Persistent Disk  │
│  インフラ側で自動冗長化（ユーザーはRAIDを意識しない） │
│  用途: DB、ステートフルなワークロード                │
├──────────────────────────────────────────────────┤
│  Layer 1: ローカルストレージ（揮発性・一時データ）    │
│  インスタンスストア / ローカルNVMe                   │
│  冗長性なし。失われる前提で設計する                   │
│  用途: キャッシュ、一時処理用バッファ                │
└──────────────────────────────────────────────────┘

重要なのは、Layer 2とLayer 3ではユーザーがRAIDやホットスペアを管理する必要がないという点である。冗長化はクラウドベンダーのインフラ層で自動的に行われる。

3. なぜローカルディスクにRAIDを組まないのか

3.1. ブロックストレージの裏側

例えばAmazon EBSの場合、1つのEBSボリュームは同一AZ内の複数の物理ストレージに自動的にレプリケートされている。ユーザーがRAIDを意識する必要はなく、ディスク障害はAWSが透過的に処理する。

方式 冗長化の責任
オンプレ / Classic BMS + RAID ユーザーがRAIDレベル・ホットスペアを管理
EBS / VPC Block Storage クラウドベンダーが裏側で自動レプリケーション
S3 / COS クラウドベンダーが3AZ以上に自動分散

3.2. NVMe時代のストレージ接続

最近のクラウドBMSやベアメタルインスタンスでは、ローカルストレージとしてNVMe SSDが採用されている。NVMeはCPUにPCIeバスで直結しており、間にハードウェアRAIDコントローラが存在しない。

SAS/SATA:  ディスク → RAIDコントローラ → OS
NVMe:      ディスク → PCIeバス → CPU に直結（RAIDコントローラなし）

したがって、NVMe環境でRAIDを構成する場合はソフトウェアRAID（Linux mdraid等）を自分で組む必要がある。しかし、クラウドネイティブな設計思想ではそもそもローカルNVMeに永続データを置かないため、その必要がない。

4. ベストプラクティス：6つの設計原則

原則1：Cattle, not Pets（ペットではなく家畜）

オンプレ・BMS（ペット） クラウドネイティブ（家畜）
サーバーに名前をつけて大事に育てる インスタンスはIDで管理。壊れたら破棄して再作成
RAIDでディスクを守り、障害時は修理する インスタンスごと破棄。ローカルに永続データを置かない
コピーバックして元の構成に戻す IaCで同一構成を数分で再構築

原則2：ステートレス設計

アプリケーションサーバーはステートレスに設計し、データは外部サービスに分離する。

ローカルディスクには一時データしか置かないため、RAIDもホットスペアも不要となる。

原則3：データベースはマネージドサービスを利用する

旧来:  BMS上にDB2/Oracleをインストール → RAIDで冗長化 → 自分でバックアップ
現代:  Amazon RDS / Aurora / IBM Databases
       → レプリケーション、バックアップ、フェイルオーバーは全て自動

ストレージの冗長化だけでなく、DBの可用性設計をマネージドサービスに委託することで、運用負荷を大幅に削減できる。

原則4：可用性はRAIDではなくアーキテクチャで担保する

障害レベル オンプレ・BMS クラウドネイティブ
ディスク1本故障 RAID + ホットスペア ブロックストレージが裏で自動処理
サーバー障害 DRサイトへ手動切替 別AZのインスタンスが自動引き継ぎ
DC全体障害 別拠点で復旧（数時間〜日） 別リージョンで自動フェイルオーバー

RAIDはサーバー内部のディスク障害にしか対応できない。クラウドネイティブでは、マルチAZ・Auto Scaling・ロードバランサーの組み合わせにより、サーバー単位・DC単位の障害にも自動で対応する設計が可能である。

サーバー1台が丸ごと落ちても、別AZのインスタンスが自動でトラフィックを引き継ぐ。RAIDでは実現できないレベルの可用性である。

原則5：バックアップは「3-2-1ルール + イミュータブル」

3: データのコピーを3つ持つ
2: 2種類以上の異なるサービス/メディアに保存
1: 1つはリージョンの外（別リージョン or 別クラウド）
+α: イミュータブル（変更不可）バックアップでランサムウェアから保護

旧来は「RAIDが壊れなければ大丈夫」に頼りがちだったが、クラウドネイティブではハードウェア障害だけでなく、論理的な破壊（誤操作・ランサムウェア）からも守る設計が前提となる。

原則6：Infrastructure as Code で再構築可能にする

# Terraform でインフラ全体をコード管理
resource "aws_instance" "app" {
  ami           = "ami-xxxxx"
  instance_type = "m5.xlarge"
  # ローカルストレージにはデータを置かない設計
}

resource "aws_ebs_volume" "data" {
  availability_zone = "ap-northeast-1a"
  size              = 500
  type              = "gp3"
  # EBS自体がインフラ側で冗長化済み
}

resource "aws_s3_bucket" "backup" {
  bucket = "myapp-backup"
  # S3は3AZ以上に自動分散。イレブンナインの耐久性
}

ディスクが壊れたら修理するのではなく、コードからインフラ全体を数分で再作成する。これがクラウドネイティブにおける究極の冗長化である。

5. オンプレ経験者が陥りやすいアンチパターン

アンチパターン クラウドネイティブでの正解
ローカルディスクにDBデータを置いてRAIDで守る マネージドDBを使う。ローカルにデータを置かない
サーバーのホットスペアを多めに積む ブロックストレージの冗長化はベンダーに任せる
ディスク障害時にサポートチケットを切って復旧を待つ インスタンスを破棄して新しく作り直す
1台のサーバーの可用性を極限まで上げる 複数台に分散し、1台の障害を許容する設計にする
バックアップを同一サーバーの別ディスクに取る オブジェクトストレージにクロスリージョンで保存
サーバー構成を手順書で管理する IaCでコード管理。環境はいつでも同一構成で再作成可能

6. それでもRAIDが必要なケース

クラウドネイティブな設計が万能というわけではない。以下のケースでは、クラウド上でもRAIDが必要になることがある。

ケース 理由
ローカルNVMeの高速I/Oが必要なDB（リアルタイム処理） EBSのネットワークレイテンシーが許容できない場合
規制要件で物理ディスクの管理が求められる 金融・医療等の業界固有の要件
Classic BMSのように物理RAIDコントローラが搭載された環境 コントローラのスロット管理・ホットスペア運用が必要

ただし、これらは例外的なケースであり、まずはクラウドネイティブなストレージ設計を検討した上で、要件を満たせない場合にのみRAIDを採用するのが現代のアプローチである。

まとめ

観点 旧来（オンプレ・BMS） クラウドネイティブ
冗長化の単位 ディスク（RAID） アーキテクチャ（マルチAZ）
冗長化の責任 ユーザー クラウドベンダー + ユーザー（設計）
障害対応 修理・復旧 破棄・再作成
データの置き場 ローカルディスク 外部サービス（EBS, S3, RDS）
構成管理 手順書・台帳 Infrastructure as Code

クラウドネイティブにおけるストレージ冗長化の本質は、「RAIDを組む」から「データを正しい場所に置き、インスタンスを使い捨て可能にする」への思想転換である。

冗長化の責任がユーザーからインフラへ移り、エンジニアは物理ディスクの管理ではなく**アーキテクチャ設計（どこに何を置くか、どう復旧するか）**に集中すべき時代になっている。

参考

1
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?