tyamazaki | wiki

Appearance

NASによるデータ管理設計 ​

NAS（Network Attached Storage）は、ネットワーク越しにファイル単位でデータを共有・保存するための中核的な仕組みである。適切な設計は、性能だけでなく、データの整合性、復旧可能性、アクセス制御を同時に満たす形で実現されるべきものである。

参考ドキュメント ​

  1. IPA（情報処理推進機構）ランサムウェア対策特設ページ（日本語）
    https://www.ipa.go.jp/security/anshin/measures/ransom_tokusetsu.html

  2. NIST Special Publication 800-34 Rev.1 Contingency Planning Guide for Federal Information Systems（英語）
    https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

  3. Microsoft Learn：SMB Security Enhancements / SMB Security（英語）
    https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-security

1. NASの位置づけと基本用語 ​

1.1 NASとは何か ​

NASは、クライアント（PC・ワークステーション・サーバ）がネットワーク経由でファイルを読み書きするためのストレージである。ホスト側に直接接続されるDAS（Direct Attached Storage）と異なり、複数利用者・複数機器からの共有を前提に、共有フォルダ（share/export）と権限管理を中心に構成される点が本質である。

1.2 NASと関連概念（DAS / SAN）の比較 ​

方式提供単位主なプロトコル/接続主要用途設計の要点
NASファイルSMB, NFS共有フォルダ、共同編集、研究データ保管名前空間、ACL、スナップショット、監査
DASブロック/ファイル（ホスト依存）SATA/SAS/NVMe直結単体サーバの高速ローカルI/Oホスト側の冗長化・バックアップが重要
SANブロックiSCSI, FC仮想基盤、DB、クラスタFSLUN設計、マルチパス、整合性運用

SANはブロックデバイスを提供するため、ファイルシステム管理はサーバ側で行うのが基本である。一方、NASはファイル単位の共有機能そのものがサービスであり、アクセス制御と整合性保持が中心課題である。

1.3 共有プロトコルの基礎（SMB / NFS / iSCSI） ​

  • SMB：Windows系との親和性が高く、ACLや監査、暗号化・署名などの機能が体系化されている。
  • NFS：UNIX/Linux環境で広く使われ、特に計算機環境ではNFSv4系（状態管理・権限モデルの整備）が重要である。
  • iSCSI：ネットワーク上でSCSIブロックデバイスを提供する方式であり、NASというよりSAN的に扱うのが基本である。

2. NAS設計で最初に決めるべき要求の分解 ​

2.1 要求を分離して考える ​

NASの設計要件は、次の軸に分解すると議論が安定する。

  1. 容量（Capacity）
  2. 性能（Performance：スループット、IOPS、レイテンシ）
  3. 可用性（Availability：止まりにくさ）
  4. 耐久性（Durability：データが壊れにくい・失われにくい）
  5. セキュリティ（Security：誰が何にアクセスできるか、漏えいしないか）
  6. 復旧可能性（Recoverability：どの時点まで戻れるか、どれだけ早く戻せるか）

これらは相互にトレードオフを持つため、先に優先順位を言語化することが合理的である。

2.2 復旧指標（RPO/RTO）の数式的定義 ​

復旧可能性は、しばしば次で表現される。

  • RPO（Recovery Point Objective）：許容できるデータ損失の最大時間RPO=tincident−tlast_recoverable
  • RTO（Recovery Time Objective）：復旧に許容できる最大時間RTO=tservice_restored−tincident

スナップショット間隔、バックアップ頻度、遠隔複製の遅延は、事実上RPOを規定する量である。

3. 冗長化（RAID等）と「戻れる」ことの違い ​

3.1 RAIDは消失をゼロにしない ​

RAIDは主に「ディスク故障に対して継続動作しやすくする」ための冗長化である。誤削除、論理破壊、マルウェア暗号化、広域災害に対してはRAIDだけでは保護にならない点を強調しておく必要がある。

3.2 RAID容量の基本式 ​

ディスク1本あたり容量をC、本数をNとする。

  • RAID0（冗長なし）Cusable=NC
  • RAID1（ミラー：2本単位の最小構成を想定）Cusable≈N2C
  • RAID5（1本分のパリティ）Cusable=(N−1)C
  • RAID6（2本分のパリティ）Cusable=(N−2)C
  • RAID10（ミラー＋ストライプ：2本単位のミラーを前提）Cusable≈N2C

RAID6は「同時2台故障に耐える」ことを目標にしたデータ配置方針であり、定義としても二重故障下での継続性が中心概念である。

3.3 冗長化方式の選択 ​

観点RAID5RAID6RAID10
最小構成3本4本4本
故障耐性1本2本各ミラーで1本（配置依存）
書込みオーバヘッド中大小〜中
再構築（リビルド/リシルバー）中の余裕小中構成に依存して中
大容量HDDでの心理的安心感低くなりやすい高くなりやすい中

ここで重要なのは、RAIDは「継続運転」の道具であり、「過去の状態へ戻す」能力は別の仕組みで担保するという分離である。

4. 「過去へ戻す」ための仕組み ​

4.1 概念の差（同じに見えて用途が異なる） ​

仕組み主目的代表例強み限界
スナップショットある時点の状態を保持ZFS snapshot, Btrfs snapshot速い作成、差分保持、復旧が容易保持先が同一筐体だと災害に弱い
複製（レプリケーション）別系統へコピーを保つZFS send/receive, rsync系, NAS間同期機器故障・サイト障害への備え論理破壊も複製してしまう場合がある
バックアップ復旧点を独立に保管世代管理、遠隔/オフライン保管ランサムウェア・誤操作への耐性復旧手順と検証が必要

4.2 スナップショット（ZFS/Btrfsに代表されるCoW系） ​

スナップショットは「読み取り専用の時点コピー」であり、作成直後は追加容量をほとんど消費せず、変更が進むほど差分を保持する方式である。ZFSではスナップショットが高速に作成できること、さらにスナップショットを基に転送（send/receive）できることが、遠隔複製と親和性を与える。

Btrfsもまたスナップショットと送受信に相当する仕組みを備え、オンラインでの整合性検査（scrub）やチェックサム検証を機能として含む。

4.3 データ完全性（Integrity）を支えるチェックサムとスクラブ ​

ストレージは「壊れたことが即座に分からない破損（サイレント破損）」が本質的に問題である。ZFSはエンドツーエンドのチェックサムにより、読み出し時に破損検出を行い、冗長構成があれば自己修復を試みるという立て付けで設計されている。Btrfsもオンライン検証（scrub）を機能として掲げ、整合性の検証を設計要素に含める。

4.4 ランサムウェアを前提にした「隔離された複製」 ​

ランサムウェアは「感染端末からアクセス可能な場所」に影響が及ぶため、常時接続の外付け媒体やネットワーク共有が暗号化対象になるという前提がある。したがって、バックアップ/複製は「アクセス経路を分離する」「オフライン性や改変困難性を持たせる」ことが重要になる。

この文脈では、少なくとも以下の考え方が要になる。

  • バックアップをネットワーク上で常時書換可能にしない設計であること
  • 暗号化やアクセス制御により、バックアップ領域そのものの改変を抑えること
  • 復旧そのものの訓練（復元の検証）を定期的に行い、戻れることを確認すること

5. アクセス制御 ​

5.1 権限モデルの基本 ​

NAS共有においては「認証（誰か）」「認可（何ができるか）」を明確化する必要がある。

  • UNIX系：UID/GID、POSIX権限、必要に応じてPOSIX ACLを併用する設計である。
  • Windows/SMB系：SIDを基礎とするACLが中心であり、AD（Active Directory）連携が実装上の標準となりやすい。

混在環境では、IDマッピング（UID/GIDとSIDの対応）が曖昧になると、権限が意図せず拡大・縮小するため、最初に「どのディレクトリ階層をどちらの世界観で管理するか」を決めるのが基本である。

5.2 監査と追跡可能性 ​

研究データや組織データでは「誰がいつ変更したか」の追跡可能性が問題になりやすい。SMBでは監査や署名・暗号化が体系的に議論されており、ネットワーク上での改ざん耐性を高める方向に進化している。

6. ネットワークと性能の基礎：ボトルネックの同定 ​

6.1 性能の分解 ​

NASの体感性能は概ね次に分解できる。

  • ネットワーク帯域（NIC、スイッチ、配線、輻輳）
  • NAS内部のストレージ性能（HDD/SSD、RAID/冗長、キャッシュ）
  • プロトコルの特性（SMB/NFS、暗号化、署名、同期書込み）
  • アクセスパターン（大きい連続I/Oか、小さいランダムI/Oか、メタデータが多いか）

単純化すれば、上限スループットは

Throughput≤min(Network_BW, Storage_BW, Protocol_BW)

で抑えられる。

6.2 小ファイル問題とメタデータ ​

研究用途では「小さなファイルが大量」という形が頻出し、メタデータ処理（ディレクトリ探索、属性更新、ロック）が支配的になる。対策としては、階層設計、アーカイブ形式の利用、メタデータを別系統で管理する設計、キャッシュ戦略などが考えられるが、前提として「ファイル数・ディレクトリ深さの増大は性能劣化の原因になりやすい」という観察を共有する必要がある。

6.3 10GbE/25GbE/100GbEと現実の到達点 ​

ネットワーク速度を上げれば直ちに速くなるわけではなく、暗号化や多数クライアントの同時アクセスでCPUが支配的になることがある。SMBでは暗号化や署名アルゴリズムが更新され、CPUのAES命令などで加速される設計になっているため、機能を有効化する際はCPU余裕も含めた評価が必要である。

7. データ構造と命名：長期維持のための設計 ​

7.1 ディレクトリ設計の原理 ​

ディレクトリは単なる棚ではなく、アクセス制御・検索性・復旧範囲を同時に規定する「データモデル」である。基本として、次の3つを衝突させない設計が望ましい。

  • プロジェクト単位（責任と共有範囲）
  • 時系列単位（世代・版・測定日）
  • データ種別単位（raw/processed/reportなど）

たとえば「rawを最上流として不変に近いものとして扱う」「processedは再生成可能性を前提に置く」など、再現性と復旧戦略の観点で層を分けるのが基本である。

7.2 メタデータとFAIRの接点 ​

NASはファイルを保存するが、研究データ管理においては「見つかる」「理解できる」「再利用できる」ことが重要である。ここでFAIR原則（Findable, Accessible, Interoperable, Reusable）との接点が生じる。NASディレクトリに最小限のメタ情報（README、測定条件、機器設定、作成者、版）を付与するだけでも、将来の復旧・再解析の品質が変わる。

8. セキュリティ：保存と通信の両面から考える ​

8.1 通信の保護（暗号化・署名） ​

SMBでは暗号化必須をクライアント側で要求する設定も可能であり、暗号化に対応しない相手との接続を拒否する運用が想定されている。また、署名は改ざん検知の観点で重要である。

8.2 保存の保護（暗号化・鍵管理） ​

保存時暗号化（at-rest encryption）は、ディスク持ち出しや廃棄時の情報漏えいリスクを低減する。一方、鍵を失えば復旧不能になるため、鍵管理（KMS、分離保管、更新、権限分掌）は設計要素である。

8.3 ランサムウェアに対する隔離 ​

重要なのは「感染端末から見えるバックアップ」を減らすことである。オフラインバックアップや、改変困難なバックアップを維持し、復旧可能性を検証しておくことが求められる。

9. 運用観測：壊れる前に兆候を拾う ​

NASはストレージ・ネットワーク・認証基盤・OS/FSが結合した系であるため、障害は多面的に現れる。したがって、次のような観測が重要になる。

  • ディスク健全性：SMART、I/Oエラー、リビルド状況
  • ファイルシステム整合：scrub、チェックサムエラー、修復履歴
  • 容量圧迫：スナップショット増大、世代保持の肥大
  • ネットワーク：帯域飽和、遅延、パケット損失、輻輳
  • 認証・権限：ログイン失敗、権限変更履歴、監査ログ

ここで「観測しない限り、壊れ方が分からない」という点が学術的にも工学的にも重要である。

10. 設計のまとめ表 ​

10.1 ファイルシステム/機能の比較 ​

観点ZFS系Btrfs系従来FS（ext4等）
CoWありあり基本はなし
スナップショットありあり実装や外部機構に依存
エンドツーエンドチェックサム中心機能機能として含む基本は限定的
スクラブ重要機能重要機能機構依存
差分転送send/receivesend/receive別手段で構成

ここでは「どれが唯一正しいか」ではなく、「想定する故障モデルに対して、どの程度まで整合性を組み込めるか」が比較の軸である。

10.2 プロトコル選定の比較 ​

観点SMBNFSiSCSI
提供単位ファイルファイルブロック
主な対象Windows混在、一般共有Linux/UNIX、計算環境仮想基盤、DB等
セキュリティ機能署名・暗号化の体系が明確認証方式の設計が重要ネットワーク分離が重要
注意点暗号化でCPU負荷増になる場合があるUID/GID・権限モデルの整合が要るファイル整合性は上位で担保

まとめと展望 ​

NASによるデータ管理は、単なる「大容量の置き場」ではなく、整合性（壊れていないこと）、復旧可能性（戻れること）、アクセス制御（適切に共有できること）を同時に満たすシステム設計である。今後はランサムウェアを前提とした改変困難な複製や、チェックサムと監査に基づくデータ完全性の体系化がより重要になり、NASは研究データ管理と情報セキュリティの交点として発展していくと考えられる。

参考文献 ​

© 2025- tyamazaki