「最新の高速NVMe SSDを積んだし、クラウドのインスタンスも最上位にした。なのに、なぜかDBのI/Oが詰まって夜中にアラートが鳴り止まない」
インフラの現場で、顔を青ざめさせたエンジニアからこんな泣きつきをされることが定期的にある。コンソールを開いてリソース使用率を見れば、CPU使用率はスカスカなのに「iowait」だけが天井に張り付き、プロセスが窒息死している。
原因は極めてシンプルだ。彼らは「ディスクI/O」の力学を何一つ理解していない。
AWSやGCPで高額なストレージを契約し、マネージドの画面をポチポチして満足している連中は、ディスク特性も、スワップの罠も、OSのカーネルパラメータすら知らない。ハードウェアを物理で札束ビンタしたところで、OSとディスクの噛み合わせが悪ければ、超高級なNVMeもただの「高価な文鎮」と化す。
そもそもディスクI/Oとは何か：IOPSとスループットを混同する素人たち
ディスクI/O（Input/Output）とは、要するにストレージとのデータの読み書き処理だ。だが、この世界には初心者が必ず踏み抜く「2つの指標の罠」がある。
- IOPS（Input/Output Operations Per Second）：1秒間に何回の読み書きリクエストを処理できるかという「回数（手数）」の指標。
- スループット（MB/s）：1秒間にどれだけのデータ量を転送できるかという「帯域（太さ）」の指標。
この違いを理解していない人間は、「IOPSが高いストレージを選んだから大丈夫」と無邪気に思い込む。
例えば、Webアプリのログ出力やDBのインデックス探索のように「小さく細切れのデータを大量に叩く」処理には高いIOPSが必要だ。一方で、巨大なバッチ処理やバックアップのように「大きな塊を一気に流し込む」処理には太いスループットが必要になる。
小さなスプーンで何万回も掬うのか、ドラム缶で一気に流し込むのか。この特性を無視して、「とにかく速いディスク」を盲信した結果、IOPSは余っているのにスループット上限にぶち当たって死ぬか、その逆の地獄を見る。
クラウドのデフォルトに「スワップ領域がない」という罠
さらに酷いのが、近年のクラウド環境における「メモリとスワップ」の認識不足だ。
AWSのEC2などで標準のAMIを使ってLinuxを立ち上げると、デフォルトではスワップ領域が一切設定されていないことが多い。これは「メモリを使い切ったら、OOM（Out of Memory） Killerが容赦なくプロセスを叩き殺す」という仕様だ。
アクセスが一時的に急増し、メモリがカツカツになった瞬間、DBやWebサーバのプロセスが何の前触れもなく突然死する。深夜に叩き起こされた初心者は「メモリリークだ！」と大騒ぎするが、単にセーフティネットとしてのスワップが1バイトも確保されていないだけだ。
そして、ここからが本当の喜劇（現場にとっては悲劇）の始まりである。
慌てたエンジニアがネットの断片的な記事を検索し、「スワップファイルを作ればいいのか」と設定する。だが、彼らは「そのスワップをどのディスク特性の領域に置いたか」を一切考えていない。
- コスト削減のために接続した低速な安物ボリューム（EBSの標準ストレージなど）の上にスワップを配置する。
- メモリが溢れてスワップイン／スワップアウトが発生した瞬間、ディスクの低速I/Oに引きずられてシステム全体のレスポンスが秒単位でフリーズする（スラッシング）。
結果、OOM Killerで即死するよりもタチの悪い「生き地獄のような超低速ハングアップ」を引き起こす。ディスクの特性を知らずに打つ場当たり的な対策は、毒を毒で薄めるような自爆行為でしかない。
速ければいいのではない：バランスとカーネルパラメータの現実
では、すべてを最高速のプロビジョンドIOPSやNVMe SSDで固めれば解決するのかといえば、そうではない。ここでも「バランス」が崩れればシステムは破綻する。
NVMeのような超高速ストレージの性能を限界まで引き出す鍵を握っているのは、ハードウェアではなくLinuxカーネルのパラメータだ。
- I/Oスケジューラ：昔の回転するHDD時代と違い、現代の高速NVMeであればカーネルのI/Oスケジューラは
noneまたはkyberなどのマルチキュー（blk-mq）前提で動かさなければ、スケジューラ自体のCPUオーバーヘッドで詰まる。 - ダーティページのフラッシュ制御（dirty_ratio / dirty_background_ratio）：メモリ上の変更データ（ダーティページ）をどのタイミングでディスクに書き戻すかの閾値。ここがデフォルトのままだと、大量の書き込みが発生した瞬間にカーネルが一気にフラッシュを始め、システム全体に強烈なI/Oのスパイク（プチフリ）が発生する。
しかし、ここで絶対にやってはならないのが「ネットで拾ってきた複雑怪奇なカーネルチューニングをコピペすること」だ。
海外のテックブログに書かれていた怪しげな sysctl.conf のパラメータを何十行も貼り付け、一時的にベンチマークの数値が上がったと喜ぶ。だが、そんなブラックボックスの設定を本番に持ち込めば、いざ不可解なカーネルパニックやパフォーマンス劣化が起きた際、どの設定が原因なのか誰一人として特定できなくなる。
カーネル設定は、シンプルかつ自分たちが挙動を説明できる最小限に留めるのが鉄則だ。事故が起きたときに原因追究ができないパラメータは、ただの時限爆弾である。
クラウドだからこそOSを学べ：インフラを舐めたツケは夜中に回ってくる
「クラウド時代だから、OSのレイヤーやディスクの物理特性なんて知らなくてもインフラは組める」
そうタカをくくっているアプリケーションエンジニアや、なんちゃってSREがあまりにも多すぎる。マネジメントコンソールでボタンを押せばサーバが生えてくるからこそ、その裏側でLinuxカーネルがどうI/Oキューを捌き、メモリとディスクの間でどうデータをやりくりしているのかという「基礎」が決定的な差になるのだ。
金で解決しようとして無駄なハイスペックインスタンスを契約し、会社の予算をドブに捨て、それでも夜中にアラートで叩き起こされて青ざめるのか。
それとも、ディスク特性とOSの呼吸を正しく理解し、最小のコストで盤石なシステムを組むのか。
クラウドを言い訳にしてOSの勉強を放棄するな。インフラを舐めて手抜きをしたツケは、必ず深夜の障害という形で、お前の睡眠時間を奪いにやってくる。
