[速報] I/O最適化されたEC2 Im4gn/Is4genインスタンスが発表されました！ #reinvent

Nitro SSDが更に進化。Graviton 2プロセッサー向けに、ストレージに最適化されたIM4gnとIS4genインスタンスが発表されました。

AWS re:Invent 2021

#AWS Graviton2

#ARM

#Amazon EC2

#AWS Graviton

#AWS

quiver

2021.12.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2021で、ストレージに最適化されたインスタンス Im4gnとIs4genが発表されました。

インスタンスタイプに「g」の文字があるように、ArmベースのGraviton 2です。

I/O最適化されたインスタンスとしては、2017年から I3、2019年から I3enが存在しました。

I系第4世代は最新の第2世代AWS Nitro SSDカードを搭載し、I系第3世代に比べて

I/O レイテンシーが60％削減
I/O レイテンシーのばらつきが75%削減

しています。

Im4gn は MySQL やファイルシステムI/Oが大量に発生するアプリケーションを動作させるのに向いています。I3 に比べて性能が最大で40％向上し、ストレージの単価は最大で44%安くなりました。

Is4gen は全EC2の中でSSDの単価が最も安く、最大容量も 4 x 7500GB=30TBもあります。大量のデータに対してランダムI/Oするような、ストリーム処理、監視サービス、ログ基盤などが向いています。 I3en に比べて性能が最大で48％向上し、ストレージの単価は最大で15%安くなりました。

スペック表

im4gnとis4genを large サイズで比較します。

インスタンス	vCPU	メモリ（GiB）	NVMe	リードスループット(128 KB Blocks)	EBS帯域幅	ネットワーク帯域幅
im4gn.large	2	8	937 GB	250 MB/s	最大 9.5 Gbps	最大 25 Gbps
is4gen.large	2	12	1.875 TB	500 MB/s	最大 9.5 Gbps	最大 25 Gbps

is4gen 系は im4gn よりもメモリが若干多く、ローカルストレージ、リードスループットは倍であることがわかります。

最大スペックで比較します。

インスタンス	vCPU	メモリ（GiB）	NVMe	リードスループット(128 KB Blocks)	EBS帯域幅	ネットワーク帯域幅
im4gn.16xlarge	64	256	30 TB	8 GB/s	38 Gbps	100 Gbps
is4gen.8xlarge	32	192	30 TB	8 GB/s	19 Gbps	50 Gbps

is4gen 系は im4gn よりも一つ小さい 8xlarge までしかないため、EBS/ネットワーク帯域は劣りますが、NVMeストレージ、リードスループットは同じです。

利用可能リージョン

これら I4g 系インスタンスは以下のリージョンで利用できます。

オレゴン
オハイオ
北部バージ内
アイルランド

残念ながら、現時点では東京リージョンでは利用できません。

ストレージ最適第4世代のIntel系 I4i も同時発表

I4g の発表と時を同じくして、Intel 版の I4i も同時に発表されています。

Im4gn をKafka クラスターに導入

Honeycomb は CPU/ストレージ/ネットワーク帯域要件がシビアな Kafka クラスターを大規模に運用しています。

現行の i3en.3xlarge は性能上限に近づいています。ひとつ上の i3en.6xlarge はコストが倍増し、c6gd.12xlarge は Kafka にはバランスが悪いのに対し、わずかにコストが増える im4gn.4xlarge に移行すると、ピーク時であっても CPU/ストレージ/ネットワークの各種メトリクスが余裕をもって処理できる事例が紹介されています。

Scaling Kafka at Honeycomb - Honeycomb

Without further ado: this is how @honeycombio scaled out Kafka #observability pipeline by 10x in 2 years, while limiting TCO to +20%. In it, we give a detailed report about brand new #Graviton2 im4gn instances and Confluent's Kafka distribution. https://t.co/27my7sxU9x

— Liz Fong-Jones (方禮真) ???+? (@lizthegrey) November 30, 2021

NVMe ストレージをマウント

EBSルートボリュームと異なり、ローカルストレージは明示的にマウントします。

$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          3.8G     0  3.8G   0% /dev
tmpfs             3.9G     0  3.9G   0% /dev/shm
tmpfs             3.9G  408K  3.9G   1% /run
tmpfs             3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/nvme0n1p1    8.0G  1.5G  6.5G  19% /
/dev/nvme0n1p128   10M  3.8M  6.3M  38% /boot/efi
tmpfs             779M     0  779M   0% /run/user/0

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1       259:0    0     8G  0 disk
├─nvme0n1p1   259:2    0     8G  0 part /
└─nvme0n1p128 259:3    0    10M  0 part /boot/efi
nvme1n1       259:1    0 872.7G  0 disk             # ローカルNVMeストレージ

nvme1n1 がローカルの NVMe ストレージです。

これをマウントします。

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

$ sudo mkdir /data

$ mount /dev/nvme1n1 /data

$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          3.8G     0  3.8G   0% /dev
tmpfs             3.9G     0  3.9G   0% /dev/shm
tmpfs             3.9G  408K  3.9G   1% /run
tmpfs             3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/nvme0n1p1    8.0G  1.5G  6.5G  19% /
/dev/nvme0n1p128   10M  3.8M  6.3M  38% /boot/efi
tmpfs             779M     0  779M   0% /run/user/0
/dev/nvme1n1      873G  922M  872G   1% /data

Im4g.large インスタンスで fio を 1並列でランダムリードを計測してみましょう。

$ sudo fio --directory=/data --name fio_test_file --direct=1 --rw=randread --bs=128k --size=1G --numjobs=1 --time_based --runtime=60 --group_reporting --norandommap
fio_test_file: (g=0): rw=randread, bs=128K-128K/128K-128K/128K-128K, ioengine=psync, iodepth=1
fio-2.14
Starting 1 process
Jobs: 1 (f=1): [r(1)] [100.0% done] [239.4MB/0KB/0KB /s] [1915/0/0 iops] [eta 00m:00s]
fio_test_file: (groupid=0, jobs=1): err= 0: pid=30986: Wed Dec  1 11:09:28 2021
  read : io=14600MB, bw=249176KB/s, iops=1946, runt= 60001msec
    clat (usec): min=204, max=3279, avg=513.04, stdev=52.68
     lat (usec): min=204, max=3279, avg=513.12, stdev=52.68
    clat percentiles (usec):
     |  1.00th=[  211],  5.00th=[  498], 10.00th=[  502], 20.00th=[  506],
     | 30.00th=[  516], 40.00th=[  524], 50.00th=[  524], 60.00th=[  524],
     | 70.00th=[  524], 80.00th=[  540], 90.00th=[  540], 95.00th=[  540],
     | 99.00th=[  548], 99.50th=[  548], 99.90th=[  548], 99.95th=[  572],
     | 99.99th=[  596]
    lat (usec) : 250=2.83%, 500=3.72%, 750=93.45%
    lat (msec) : 4=0.01%
  cpu          : usr=0.40%, sys=1.01%, ctx=116814, majf=0, minf=40
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=116803/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=14600MB, aggrb=249175KB/s, minb=249175KB/s, maxb=249175KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  nvme1n1: ios=116609/0, merge=0/0, ticks=59261/0, in_queue=59261, util=99.96%

リードスループットは 249176KB = 243MB とカタログ値の 250MB に近いですね。

また、レイテンシー(lat/clat) についても、標準偏差(stdev)が52.68マイクロ秒と非常に安定していることがわかります。 99を超えたパーセンタイルでも、安定していますね。