EC2の揮発性ストレージ「インスタンスストア」を使ってみよう！

EC2のブロックストレージには、Amazon Elastic Block Store(EBS)以外にも、インスタンスストアという揮発性の個性的なストレージも存在します。

EC2のリリース当初のブロックストレージはインスタンスストア一択でしたが、現在は特定のインスタンスタイプでしか利用できないため、触れる機会が減っているようです。

今回は、この特徴的なブロックストレージ「インスタンスストア」について簡単に紹介します。

インスタンスストアとは

インスタンスストアは揮発性のため、一時ストレージにしか利用できませんが、そのトレードオフとして、高いパフォーマンスを発揮します。

公式ドキュメントから引用します。

インスタンスストアは、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージに最適です。また、インスタンスのフリート全体でレプリケートされるデータ (負荷分散されたウェブサーバープールなど) にも適しています。

インスタンスストアはすべてのEC2インスタンスタイプに付属するわけでは有りません。

• 第5・6世代ではC5d, M6gdのように「d」がつくインスタンスタイプ
• I3、F1

など一部のインスタンスタイプでのみ利用できます。

EBSとインスタンスストアの比較・使い分け

AWS Storage Services の特性理解と選択指針 | AWS Summit Tokyo 2019 - YouTube の登壇資料から引用します。

パフォーマンス

Nitro世代のインスタンスストアはNVMeで接続されています。

上述の「EBSとインスタンスストアの比較」の表のように

• SSD EBS より高い IOPS
• HDD EBS より高いスループット
• EBS より低いレイテンシー

といった特徴があります。

インスタンスストアは揮発性

インスタンスストアはEBSよりパフォーマンスが優れている一方で、データは揮発性です。

具体的には、次のいずれの状況でも、データは失われます。

• 基盤となるディスクドライブで障害が発生した
• インスタンスが停止した
• インスタンスが終了した

また、EBSのようにスナップショットを取得することもできません。

ただし、再起動ではデータは維持されます。

コスト

EBSは

• ボリューム
• IOPS(タイプによる)
• スナップショット

で費用が発生するのに対し、インスタンスストアの費用はEC2に含まれています。

ただし、C5/C5dのように、インスストアの有り・無しを選択できるインスタンスタイプの場合、付属するインスタンス(C5d)は付属しないインスタンス(C5)に比べて若干高価です。

例えば東京リージョンでC5とC5dの利用費を比較すると、

• c5.large : $0.107/時間
• c5d.large(1 x 50 NVMe SSD付属) : $0.122/時間

というように14%ほど高価です。具体的な価格差は、EC2の価格表をご確認ください。

インスタンスストア向けのNitro Card

最新のEC2基盤であるNitro Systemでは処理ごとにカードが作成され、インスタンスストア向けのカードも存在します。同カードでは

• NVMe対応
• 書き換えブロックの平準化(ウェアレベリング)※NAND型フラッシュメモリのSSDは書き換え上限があるため
• 不良ブロックのモニタリング ※不良ブロックが増えすぎると、IOPSが大幅に劣化
• 暗号化

といった処理が行われています。

インスタンスストアを利用する

Nitro Systems世代のインスタンスを例に、インスタンスストアを利用してみます。

インスタンスの起動

EC2起動時にインスタンスストアが付属するインスタンスタイプを選択します。

インスタンスタイプにより

• f1のように必ず付属するもの
• C5/C5d のように付属する/しないの2パターンがあるもの。付属すると、18%程度高い
• T3のように付属しないもの

の3ケースが有ります。

インスタンスストアが付属すると「インスタンスストレージ」列が「EBSのみ」ではなく「SSD」で表示されます。

ストレージ画面では、ボリュームタイプが

• ephemeral0
• NVMe SSD

となっています。

インスタンスストアの初期設定

インスタンスストアを利用するには、ファイルシステムの作成とマウントが必要です。 手順はEBSボリューム追加時と同じです。

起動直後はマウントされていません。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  392K  3.8G   1% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/nvme0n1p1  8.0G  1.3G  6.8G  16% /
tmpfs           773M     0  773M   0% /run/user/1000

lsblk でストレージデバイスを確認します。

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme1n1       259:0    0 46.6G  0 disk            # インスタンスストア
nvme0n1       259:1    0    8G  0 disk
├─nvme0n1p1   259:2    0    8G  0 part /
└─nvme0n1p128 259:3    0    1M  0 part

同デバイスにXFSのファイルシステムを作成します。

$ sudo mkfs -t xfs /dev/nvme1n1
meta-data=/dev/nvme1n1           isize=512    agcount=4, agsize=3051758 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=12207031, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=5960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

ボリュームのマウントポイントディレクトリを作成します。

$ sudo mkdir /data

マウントします。

$ sudo mount /dev/nvme1n1 /data

マウントされていることを確認します。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  396K  3.8G   1% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/nvme0n1p1  8.0G  1.3G  6.8G  16% /
tmpfs           773M     0  773M   0% /run/user/1000
/dev/nvme1n1     47G   80M   47G   1% /data

/dev/nvme1n1 が見えています。

書き込みできることを確認してください。

$ sudo touch /data/test

最後に、リブート後にインスタンスストアが自動マウントされていることを確認してください。

$ sudo reboot

インスタンスをいったん停止(≠リスタート)するとハードが変わってしまうため、新規スタートのたびにインスタンスストアをマウントする必要があります。

NVMe インスタンスストアのベンチマーク

M5d の比較

汎用型の M5d でベンチマークを取得しました。

EBS最適化をサポートする M5d のようなインスタンスタイプでは、最大パフォーマンスを 24 時間につき少なくとも 30 分間維持することができます。

バースト可能な時間を超過すると、それぞれのインスタンスタイプに応じたベースラインパフォーマンスになります。

M5d のベースラインとバースト時のパフォーマンスを比較します。

参考 Amazon EBS 最適化インスタンス - Amazon Elastic Compute Cloud

この前提の上で、以下の環境でベンチマークを取得しました。

• OS：Windows Server 2019
• インスタンスタイプ : M5d
• ツール：CrystalDiskMark 7.0.0

ストレージ

Real World Performance

Peak Performance

ひとことメモ

• EBS利用直後のため、EBSのバースト機能が有効になっています。
• io1の場合、Peak Performanceを計測すると、EBSのバースト上限に近いスループット、IOPSが出ています。
• gp2 でもベースライン(81.25MB/秒)以上のスループットが出ています。
• NVMe SSDインスタンスストアはランダムI/Oのスループット/IOPS、低レイテンシーが際立っています。

AWS Nitro Systemでインスタンスストアが復活した理由

EC2リリース当初のブロックストレージはインスタンスストア一択でした。当時のEC2はディスポーザブルなリソースとしてしか扱えなかったわけです。クラウドネイティブですね。

ほどなくして、永続的なブロック・ストレージのEBSが登場し、ルートデバイスにもEBSを選択(EBS backedインスタンス)できるようになります。

EBS登場後も長期に渡ってインスタンスストアが付属するのが当然でしたが、第4世代(C4など)では付属しなくなり、第5世代のd系インスタンスタイプ(C5dなど)で復活しました。

理由はネットワーク帯域幅です。

大昔のEC2のネットワーク帯域幅はせいぜい1Gbpsでした。 この時代は、パフォーマンスがネットワーク帯域幅に律速されないインスタンスストアのほうが高パフォーマンスでした。

ネットワーク帯域幅が10Gbpsになると大きく変わります。EBSのスループットが大幅に向上し、インスタンスストアのメリットが薄れ、第4世代のC/M/R系インスタンスではインスタンスストアが付属しなくなります。

Nitro Systemの登場で再び状況が変わります。

インスタンスストアはNVMe、EBSはNVMe Over Fabricsで接続され、再びインスタンスストアのパフォーマンスがEBSよりも良くなり、C/M/R系でもスタンスストアを選択できるようになりました。

Nitro SystemやNitro Card(VPC、EBS、インスタンスストアなど)の開発背景に興味のあるかたは、re:inventでの開発者による発表をご覧ください。

最後に

EC2の揮発性ブロックストレージ「インスタンスストア」はEBSに比べ高IOPS、高スループット、低レイテンシーのため、高いI/Oパフォーマンスが求められる一時ストレージに最適です。 ただし、揮発性であったり、スナップショットを取れないなど、データの永続化には向いていません。

インスタンスストアは取り扱いが難しいところもありますが、用途がマッチすると、非常によくできる子です。 インスタンスストアのことを頭の片隅に置いておき、ここぞというタイミングで採用しましょう。

それでは。

参考

• Amazon EC2 インスタンスストア - Amazon Elastic Compute Cloud
• AWS Storage Services の特性理解と選択指針 | AWS Summit Tokyo 2019 - YouTube
• AWS re:Invent 2018: Powering Next-Gen EC2 Instances: Deep Dive into the Nitro System (CMP303-R1) - YouTube
• AWS Nitro System – Perspectives