SAS 7,200rpmはgp3何個分か — オンプレストレージのEBS換算ガイド

オンプレからの移行サイジングで最初に困るのが、ストレージです。オンプレの性能は「SAS 15,000rpm×8本のRAID6」のように回転数とRAID構成で語られ、AWSの性能は「gp3で3,000 IOPS」のようにIOPSとスループットで語られる。単位が違うので直接比較できません。この記事は、その翻訳表です。

01回転数→IOPSの換算表（1本あたりの目安）

機械式ディスクのランダムI/O性能は、ほぼ回転数で決まります。実務で使われてきた目安は次のとおりです。

• SAS 15,000rpm — 約175〜210 IOPS
• SAS 10,000rpm — 約125〜150 IOPS
• NL-SAS／SATA 7,200rpm — 約75〜100 IOPS
• SATA 5,400rpm — 約50〜80 IOPS

注意すべきは、これはランダムI/Oの数字だということ。シーケンシャル読み書きなら7,200rpmでも120〜180MB/s程度出ます。つまり「遅いディスク」でもバックアップやログ書き込みでは意外に働いていた、ということが移行時の性能見積もりを狂わせます。

02gp3が1本で、7,200rpm約30本分

EBS gp3のベースラインは容量と無関係に3,000 IOPS・125MB/sです。ランダムI/Oでいえば、7,200rpm換算で約30本、15,000rpm換算でも約15本のRAIDグループに相当します。オンプレで筐体を並べて稼いでいた性能が、ボリューム1個のデフォルト値で出る——ここが翻訳の出発点です。

逆に、大容量のシーケンシャル一本勝負（数百MB/sをHDDアレイのストライプで出していたケース）では、gp3のベースライン125MB/sが下回ることがあります。この場合はgp3のスループットを追加購入（最大2,000MiB/s。8,000 IOPS以上・16GiB以上で到達。Outposts環境では1,000MiB/s）するか、EBS選定記事で解説したst1も候補になります。

03RAIDグループの「実効IOPS」を計算してから比較する

現行構成の性能は、ディスク単体ではなくRAIDグループの実効値で見ます。読み取りはおおむね本数分が効きますが、書き込みにはRAIDペナルティがかかります（RAID10＝2、RAID5＝4、RAID6＝6）。

例：NL-SAS 7,200rpm（85 IOPS/本）×8本のRAID6なら、読み取りは約680 IOPS、書き込みは 8×85÷6 ≒ 約113 IOPS。この「書き込み113 IOPS」で回っていた業務なら、gp3のデフォルトで7倍以上の余裕があります。移行後にストレージが遅くなる心配は、ほとんどの場合、逆方向の心配です。

04いちばん確実なのは、オンプレ側での実測

換算表はあくまで初期見積もりです。確定サイジングは、移行前のサーバでI/O統計を取るのが確実です。LinuxならiostatやsarでIOPS（r/s＋w/s）と転送量を、Windowsならパフォーマンスモニタ（Disk Transfers/sec、Disk Bytes/sec）を、業務のピークを含む2週間収集し、ピーク値を基準にEBSを選びます。

この実測値があれば、「gp3のベースラインで足りるか、IOPS追加が要るか、io2が要るか」の判断は機械的に決まります。移行後の検証はCloudWatch側で同じ数字を見るだけです。

05翻訳時の落とし穴2つ

• インスタンス側の帯域上限 — ボリュームを速くしても、インスタンスのEBS帯域（小さいサイズはベースラインが低い）が先に詰まります。ストレージとセットで確認を（詳細）
• 「本数＝容量」の名残 — オンプレでは性能のためにディスク本数を積み、結果として容量が余っていたはず。EBSは性能と容量が独立なので、容量は実使用量＋成長分だけで買い直せます。ここでコストが大きく下がります