フラグメンテーション徹底ガイド：メモリ・ストレージ・データベース・ネットワーク別の原因と実務対策
エバープレイ編集部フラグメンテーションとは
フラグメンテーション（fragmentation）とは、リソース（記憶領域、ファイル、ネットワークパケット、データベースページなど）が連続性や効率的な配置を失い、断片化してしまう現象を指します。断片化が進むと、アクセス性能の低下、ディスクやネットワークの余計な負荷、不要な書き込み（特にSSDでの書き込み劣化）などの問題が発生します。IT分野では「メモリ」「ファイルシステム／ストレージ」「データベース」「ネットワーク（IPパケット）」といった領域で主に用いられる概念です。
主な種類と概要
メモリフラグメンテーション
メモリ上で割り当てと解放を繰り返すうちに、小さな空き領域が散在し、要求する連続したサイズのブロックを割り当てられなくなる現象。内部フラグメンテーション（割当単位が大きすぎる）と外部フラグメンテーション（空き領域が細かく分散）の2種類に分けられます。ガベージコレクションやメモリコンパクション、スラブアロケータやバディシステムなどで対処します。
ファイルシステム／ディスクのフラグメンテーション
ファイルがディスク上で連続した領域に収まらず複数の断片（フラグメント）に分かれて配置される現象。HDDではシーク時間が増大して読み書き性能が低下します。ファイルの追記や削除・再作成、領域割当方式（ブロック単位 vs エクステント）により発生します。デフラグ（再配置）や拡張子/ファイルアロケータの改善で軽減します。
データベースのフラグメンテーション
テーブルやインデックスのページ分割（page split）や行の削除により、テーブル領域やインデックスの空きが断片化する状態。クエリ性能を悪化させるため、SQL ServerのALTER INDEX REBUILD/REORGANIZE、PostgreSQLのVACUUM/REINDEX/pg_repack、MySQLのOPTIMIZE TABLEなどで対処します。
ネットワーク（IPパケット）のフラグメンテーション
パケットが経路上のMTU（最大転送単位）より大きい場合に分割（フラグメント）される現象。IPv4では中継でフラグメント化されることがあり、IPv6では送信元のみが断片化を行います。断片の1つでも欠けると再構築できず通信が失敗しやすく、ICMPによるPMTUD（Path MTU Discovery）が関連します。セキュリティ面でも断片化を悪用した攻撃や検査回避が知られています。
ファイルシステム別のフラグメンテーション特性
FAT系（FAT32）：割当方式が単純で断片化しやすい。小容量・古いシステム向け。
NTFS（Windows）：MFTや小ファイルの割当で断片化することがあるが、Windowsは定期的な最適化（自動デフラグ）を行う。
ext4（Linux）：エクステントベースで設計されており、断片化は比較的起きにくい。ただし大量のランダム書き込み等で断片化する場合がある。e4defragなどで解析・最適化可能。
XFS：大きなファイル・大容量向けに最適化されており、断片化耐性が高い。リアルタイム割当戦略を持つ。
btrfs / ZFS / APFS（COW系）：コピーオンライト設計のため、独特の断片化パターンを持つ。一定条件下で細かく断片化するが、スナップショットや内部の最適化機構で管理される。SSD向けに最適化されたファイルシステムでは断片化のパフォーマンス影響が小さい場合が多い。
ネットワーク断片化（IP）の技術的要点と問題点
IPv4ではルータが断片化を行うことが可能。IPv6ではルータは断片化しない（送信元で行う）。RFC 791（IPv4）、RFC 8200（IPv6）が基本。
Path MTU Discovery（PMTUD）はICMP「Fragmentation Needed」を利用して最適なMTUを発見する（RFC 1191、後に強化や置換）。ICMPがフィルタリングされると「ブラックホール」問題が発生する。
断片化は再組立てコストとロスのリスクを高める。VoIPやストリーミングなどリアルタイムアプリは断片化を避ける設計が望ましい。
セキュリティ：断片化を利用したパケット検査回避や攻撃（オブスクレーション、重複・重積フラグメント）を防ぐために、ファイアウォールやIDS/IPSで断片化ポリシーが必要。
データベースにおける具体的な対処法
SQL Server：sys.dm_db_index_physical_statsで断片化状況を確認。ALTER INDEX ... REORGANIZE（軽い断片化向け）／ALTER INDEX ... REBUILD（強い断片化向け）で対応。fillfactor設定やバッチ更新の設計で予防。
PostgreSQL：VACUUM（通常）／VACUUM FULL（ファイルサイズ縮小だが排他ロック）／REINDEXや外部ツールpg_repack（オンラインでの再配置）を利用。
MySQL：MyISAMはOPTIMIZE TABLEで最適化。InnoDBはinnodb_file_per_tableが有効ならOPTIMIZE TABLEでテーブル再作成、またはALTER TABLEで再構築。オンラインDDLツール（pt-online-schema-change）でダウンタイム低減。
SSDとHDDの違い — デフラグは必要か？
HDDでは断片化は物理的なシーク増加に直結するため、定期的なデフラグで連続性を回復すると明確に性能が向上することがあります。一方、SSDはランダムアクセス性能が高く、物理的シークがないため断片化による読み取り遅延は小さいです。しかし、デフラグ作業自体が大量の書き込みを発生させ、SSDの書き込み耐性（寿命）を削る可能性があるため、一般にSSDでは頻繁なデフラグは推奨されません。OS側ではSSDを検出してデフラグではなくTRIMや最適化（Trim/GC支援）を行う設定が一般的です。
検出・測定ツール（代表例）
Windows：ファイルの断片化解析は「最適化ドライブ（Optimize Drives）」やコマンドの defrag.exe、Sysinternals の Contig。
Linux：filefrag（個別ファイルのフラグメント数表示）、e4defrag（ext4向け）、btrfs-defrag（btrfsのオンラインデフラグ）など。
データベース：SQL Server の sys.dm_db_index_physical_stats、PostgreSQL の pgstattuple、MySQL の INFORMATION_SCHEMA や OPTIMIZE TABLE の結果。
ネットワーク：tcpdump/wireshark でのフラグメント観測、path MTU の確認は ping -M do / ping -s や traceroute を活用。
実務での対策まとめ
原因を把握する：どの層（メモリ/ファイル/DB/ネットワーク）で断片化が起きているかを特定する。
予防策を設計に入れる：適切なアロケータ、エクステントベースのファイルシステム、テーブル設計（fillfactor・インデックス設計）、適切なMTU設定など。
運用での定期点検：OSやDBの診断ツールで定期的に断片化を監視し、閾値超過時に計画的メンテナンスを行う。
デバイス特性を尊重：HDDはデフラグ有効、SSDはTRIMとGCを優先し不必要なデフラグを避ける。
セキュリティ対策：ネットワーク断片化を利用した攻撃を防ぐためにFW/IDS設定で適切なフラグメント処理を行う。
結論
フラグメンテーションは多面的な現象で、発生箇所に応じて影響や対策が大きく異なります。原因を正しく特定し、システムやデバイスタイプに応じた予防・検出・修復を組み合わせることが重要です。特にSSD普及以降は「とにかくデフラグすれば良い」という発想は見直され、デバイス特性に合わせた運用設計が求められます。
参考文献
- RFC 791 - Internet Protocol (IPv4)
- RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification
- RFC 1191 - Path MTU Discovery
- RFC 4821 - Packetization Layer Path MTU Discovery
- Microsoft Docs - Defragmenting and Optimizing Drives
- PostgreSQL Documentation - Routine Vacuuming
- MySQL Reference Manual - OPTIMIZE TABLE
- Microsoft Docs - Reorganize and Rebuild Indexes
- Linux Kernel Documentation - ext4 defragmentation
投稿者プロフィール
