目次
はじめに
こんにちは。SREの二橋です。最近の楽しみは、キャンプと釣りの動画を見ながら、お家で妄想を膨らませることです。
この度、TypetalkのEC2のインスタンスをインテルプロセッサを搭載したM5系からARMベースのAWS Graviton2を搭載したM6g系に完全移行しました。そこで、Graviton2の概要から移行しようと思った理由、作業内容、移行の効果などをお伝えしたいと思います。
AWS Graviton2とは？
Graviton2はAWSがArm Neoverse コアをベースに独自開発したプロセッサです。2020年夏にAmazon EC2で一般用途向け(M6gとM6gd)、コンピューティング最適化(C6gとC6gd)、メモリ最適化(R6gとR6gd)がGAされました。(2020/09/15追記: 汎用ワークロード向けのT4gが利用可能になりました！)「g」はGraviton2、「d」はNVMeのローカルSSDストレージを表しています。AWS Graviton2はEC2で利用することができて、主要な Linux ディストリビューション(Amazon Linux 2, RHEL, Ubuntuなどなど)に対応しています。
他のマネージドサービス(Elastic Load BalancingやAmazon ElastiCacheなど)でも利用できるように進んでいるそうです。先日はAmazon Relational Database Serviceでプレビューが開始がアナウンスがされていました。また、Amazon EKSのワーカーノードとしてGraviton2を搭載したインスタンスタイプを利用できるようになりました。
AWS GravitonとAWS Graviton2の違い
第1世代のGravitonは、A1インスタンスとして2018年冬にGAされました。スペックに関して、第2世代のGraviton2では第1世代よりも、7倍のCPU性能、4倍のvCPU数、5倍のメモリアクセスを実現したとのことです。インスタンスファミリーに関して、第1世代は一般用途向けのA1しかサポートされていませんでした。第2世代では前述したようにコンピューティング最適化インスタンスとメモリ最適化インスタンスも提供されています。インスタンスサイズに関しても、第1世代では小さめのものしか提供されていませんでしたが、第2世代では16xlargeなどのより大きいサイズが選択できるようになりました。
x86ベースの現世代との比較
AWSによると、EC2で利用できるx86ベースの現世代(M5とC5とR5)とGraviton2を比較すると、20%のコストダウンと40%のコストパフォーマンスの向上を実現できたとのことです。AWSが公表している性能比較や他社の事例では、CPUベンチマーク/ロードバランシング/メモリキャッシュ/機械学習など様々な分野において性能の向上が確認できます。また、インスタンスサイズの違いもあります。x86ベース現世代では、largeサイズ(M6gの場合、2 vCPUと8GiBメモリ)が最小でしたが、Graviton2ではより小さいmediumサイズ(M6gの場合、1 vCPUと4GiBメモリ)も提供されています。また、x86ベースの現世代ではHyper-Threadingにより2つのvCPUが1物理コアに相当するのに対し、Graviton系では1つのvCPUが1物理コアに相当するという違いもあります。
re:Invent 2019の資料に詳細が書かれておりますので、興味がある方は是非見てください。
AWS Graviton2に移行しようと思った理由
移行しようと思った主な理由は、下記の3つです。
1. 性能向上とEC2の費用削減が期待できるため。
前節のx86ベースの現世代との比較や他社の事例を見ると、幅広いユースケースにおいて性能向上とEC2の費用削減が期待できるように感じました。仮に性能にほとんど変化がない場合でも、同じサイズのEC2の料金が約20%安くなっているので、検証を実施する価値は十分あると思いました。
2. 世の中の動きに追従するため。
3. 移行コストが低かったため。
AWS Graviton2移行に必要だった作業
移行に当たり、下記の作業をしました。参考までに、1と2が1週間程で終わりました。3は作業としてはほとんど時間がかからなかったのですが、カナリアリリースを交えて様子を見ながら3週間かけてゆっくり入れ替えました。
1. パッケージの移行
利用していたパッケージをx86用の代わりにaarch64用をインストールするようにしました。パッケージマネージャーが対応している場合、構成管理ツールを利用していれば変更作業は必要ありません。多くのメジャーなパッケージは対応していると思います。パッケージマネージャーが未対応な場合、パッケージを直接ダウンロードしていた場合、ソースからビルドしていた場合は、aarch64対応のものをダウンロードしたりソースからビルドしたりする必要があります。また、TypetalkはJVM上で動くアプリケーションのため、移行前後でビルド成果物は同じものをそのまま利用することができました。Amazon CorrettoやOpenJDKも対応しており、パッケージマネージャ経由でインストールして利用できます。
Getting started with AWS Gravitonに最適化のTipsや各言語の考慮点などが記載されておりますので、是非こちらも参照してください。
2. 性能検証
Graviton2移行により、プロセッサとインスタンスサイズの変更があったため、性能検証を実施しました。公式のベンチマーク資料や他社の事例ではかなり有効なデータが確認できます。しかし、絶対に改善が保証される訳ではないので、測定は実施する方が良いと思います。Typetalkでは性能検証の結果、改善が見られたため完全移行に踏み切りました。
3. インスタンス入れ替え
Graviton2に移行するには、インスタンスを作り直して入れ替える必要があります。TypetalkはAWS CodeDeployとEC2 AutoScalingを使ったBlue/Greenデプロイで、アプリケーションリリースの度に自動的にインスタンスの入れ替えを行っています。そのため、特に作業はしてないですがカナリアリリースを交えて、メトリックやパフォーマンスの変化には気を配りました。
AWS Graviton2に移行した効果
1. 性能向上によるレスポンスタイムの改善
今回の移行で、ロードバランサーやアプリケーションサーバなど、Typetalkを構成するすべてのEC2インスタンスをGraviton2に置き換えました。これにより、最終的な本番環境の全体のレスポンスタイムの分布は、下図のようになりました。Graviton2移行後は、0-0.01sの短時間で処理できた割合が約30%増加しており、明らかに改善されたことが確認できます。
下図は負荷試験ツールGatlingを本番環境と同じ構成の検証環境に実行した結果です。Response Time Distributionのヒストグラムを比べると、短くなっていることが分かると思います。横軸のスケールを揃えるとより分かりやすかったのですが、ご了承ください。また、Response Time Percentiles over Timeを比べると、maxの時間が安定してることが読めると思います。
2. EC2の費用削減
1年分のRIの費用を移行前後で比較すると、約30%削減することができました。M6gの料金は、M5の同じサイズのものと比較して、約20%程安くなります。さらに、M5ではなかったmediumサイズがM6gでは使えるので、オーバースペックだった箇所を入れ替えることでさらに安くすることができました。
AWS Graviton2を使う際の注意点
執筆時点では、Graviton2は東京リージョンのAZだと2つしか対応していませんでした。将来的に3AZ対応されるとは思います。もし東京リージョンで稼働しているサービスで3AZ以上などを必要とされる場合、ご注意ください。
また執筆時点では、検証環境向けの小さいインスタンスサイズが提供されていません。t3系のような小さいのが提供されると嬉しいですね。(2020/09/15追記: 汎用ワークロード向けのT4gが利用可能になりました！)ちなみにt3aは、ARMプロセッサではなくてAMDプロセッサなのでご注意ください。
他にもたくさん注意事項を書きたかったのですが、特に問題にぶつかることなく終わってしまいました。
おわりに
Graviton2に移行してみて、期待を上回る効果があって驚きました。移行作業もほとんど時間をかけずにできて、AWSのありがたみをひしひしと感じております。AWSの今後の展開がとても楽しみです。
本記事を読んでGraviton2に興味を持った方は、是非試してみてください。
私たちと一緒に楽しく働きたいと思った方は、下記のリンクより応募をお願いします！
