GCE Local SSD向けのチューニング

こんにちは、インフラエンジニアの久保です。

今回は、GCE(Google Compute Engine)のLocal SSDのチューニングとベンチマーク結果についてご紹介したいと思います。

Local SSDとは

GCEではPersistent Disk(ネットワーク ディスク)、Local SSD、Cloud Storage Bucket、RAM Diskの４種類のディスクサービスを提供しています。
今回利用したLocal SSD はPersistent Disk(ネットワーク ディスク)と異なり、仮想マシンインスタンスのホストとなるサーバーに搭載されているSSDに直接接続されているため、非常に高速です。
Persistent Diskに比べて低レイテンシかつ高IOPSであるため、非常に高い性能が求められている環境においては非常に有用かと思います。
また、今回の試験では利用していないのですが、RAM Diskはメモリ上にデータを格納するため、Local SSDより高い性能が期待できます。

メリット

• コスパが良い($0.218/GB/month)
• 1 VMで4個まで追加できる(4x375GB)
• 最大IOPS(read 680,000/write 360,000)
• GCEのインスタンスライブマイグレーションにも対応

デメリット

• NVMe版はDebianOS8の一部のみ対応
• Local SSDを利用している際に以下のイベントができない
  • SSDの容量は375GB固定で、インスタンスを停止せずにディスク追加(拡張)ができない
  • インスタンスのサーバスペックを自由に変更できない
• インスタンスの停止ができない(詳細は以下)

対象のインスタンスを選択しても 「停止」がグレーアウトしていて押せなくなっています。インスタンスの詳細から停止を押すことはできますが、
停止できない旨を表示するポップアップが現れて結局停止はできません。

 サーバにsshして

 $sudo shutdown -h now

で、停止することができます。
ただし、停止してしまうと一生起動することができません。
このあたりは公式にも記載されているので確認してみてください。

無理やり停止させたインスタンスを起動させようとすると･･･このように怒られます！

 JdbcRunner(MySQL Benchmark)で負荷検証

今回、社内のとあるタイトルが利用しているDBデータを使用して負荷検証を実施しました。ターゲットDBはMySQL5.5で、負荷検証ツールはJdbcRunner(version:1.2)を利用しました。
JdbcRunnerのagentを利用してユーザのゲーム内での動作を模擬し、同時に100プロセスのagentでデータベースに書き込み・読み込みなどの操作を1分間実行し続けるという負荷検証を行いました。
※検証結果で使われているTPSはTransaction per secの略

ゲームデータベース(MySQL)向けにLocal SSDをチューニングしてみる

テストサーバ情報:

一回目: Diskのmountオプションのチューニング(Local SSD 一枚)

チューニング前:

$sudo sh -c "echo '/dev/disk/by-id/google-local-ssd-0 \
/data xfs discard,defaults 0 0' | tee -a /etc/fstab"

チューニング後:

$sudo sh -c "echo '/dev/disk/by-id/google-local-ssd-0 \
/data xfs rw,noatime,nobarrier,defaults,discard 0 0' | tee -a /etc/fstab"

テスト結果:
ファイルシステムはxfsで一緒ですが、rw,noatime,nobarrierのオプションを付けただけでMySQLの性能が3倍程向上しました。

二回目: Diskタイプのチューニング(Local SSD 二枚,RAID0を組む)

チューニング前:

$sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/disk/by-id/google-local-ssd-0 /dev/disk/by-id/google-local-ssd-1
$sudo mkfs.ext4 -F /dev/md0
$sudo sh -c "echo '/dev/md0 /data ext4 rw,noatime,nobarrier,defaults,discard 0 0' | tee -a /etc/fstab"

チューニング後:

$sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/disk/by-id/google-local-ssd-0 /dev/disk/by-id/google-local-ssd-1
$sudo mkfs.xfs -s size=4096 -b size=4096 /dev/md0
$sudo sh -c "echo '/dev/md0 /data xfs rw,noatime,nobarrier,defaults,discard 0 0' | tee -a /etc/fstab"

テスト結果:

ファイルシステムをxfsにした場合、ext4より1.25倍程性能が向上しました。

三回目: MySQLのSSD向けのチューニング(Local SSD 二枚,RAID0を組む)

チューニング後(下のパラメータをmy.cnfに追加):

innodb_buffer_pool_size=45G
innodb_read_io_threads = 8
innodb_write_io_threads = 16
innodb_io_capacity = 2000
innodb_max_dirty_pages_pct = 30
innodb_adaptive_flushing = ON
innodb_log_file_size=1280M

チューニング内容について:
innodb_buffer_pool_sizeはデータやindexをメモリ上にキャッシュしてデータの検索を高速化させる値です。
MySQLのパフォーマンスを改善するため、実装されているメモリーの70%程度を割り当てるのが良いとされているので、今回は45GBを割り当てました。
また、innodb_log_file_sizeの数値を大きくすることでデータの変更があった際にメモリ上のinnodb_buffer_poolに貯めておき、設定サイズ以上になったときにDBに書き込むようにするため、パフォーマンスを改善することがきます。今回は1280Mに設定しました。
詳細は下記URLを参照してください。
MySQL公式リファレンス
簡単なMySQLチューニングを行った上で計測した結果が以下になります。

テスト結果:
上記のパラメータを追加後、チューニング前と比べて2倍以上性能が向上しました。
また、弊社でリリースしているタイトルの負荷テスト結果(ioDriveを使用)と比べても、ほぼ変わらない結果になりました。

最後に、Local SSDの2枚、3枚、4枚でRAID0を組んでDiskIOを検証してみました。

結果まとめ

Local SSDの使い勝手をまとめると

Cloud SQL＆RDSなどのクラウドサービスの1/3のコストで低レイテンシ、高IOPSが利用でき、GCEのライブマイグレーションにも対応されていることは素晴らしいと思います。
しかしながら高性能故に周りのハードウェアがボトルネックとなり、十分な性能が発揮できない恐れもあると感じました。
また、NVMeは一部OSのみ対応だったり、再起動できなかったりと制約がまだまだある為、Local SSDを最大限に利用するのであれば、それなりのインスタンスを用意し、要件にあった状況で利用することで真価を発揮すると思いました。