私のチームでは今Amazon Aurora PostgreSQLのdb.r5.largeインスタンスを利用しています。最近インスタンスタイプの変更を検討したいという話が出ました。そこで、AWS Gravitonインスタンスタイプへの移行によるコストパフォーマンスの向上について、簡単に検討してみようと思います。
AWS Gravitonとは
簡単に言うと、AWSが独自で開発した64ビットのArmプロセッサです。x86系CPUを使うインスタンスより安価で利用することができます。
AWS Gravitonの大きな特徴の１つは、vCPUの数と物理コアの数が一致することです。CPUには 「物理コア」 があり、x86系のインスタンスでは1つの物理コアが 2つのスレッド（仮想的な作業単位）を同時に処理できるようにして、物理コアを効率的に利用してきました。しかし、利用状況によってはスレッド同時の競合が起きたりして待ち時間が発生するなどのデメリットも生じてしまします。Gravitonでは、 1 vCPU= 1物理コア なので、競合が起きることなく物理コアを利用することができます。
引用元: https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Graviton_0430_v1.pdf
ここで注意したいのは、「同じvCPUの数でGravitonのほうが物理コアの数が多いので性能がよい」ことではないことです。物理コア１つの性能自体についてはまた違う比較対象となるため、実際の検証を通じて確認する必要があります。正しい例なのかちょっと怪しいですが、２人乗り自転車があったとしても、ロードバイクには勝てない可能性もありますよね。したがって、AWSでもGravitonのメリットとして性能ではなく「コストパフォーマンスがよい」とアピールしています。
また、x86系ではなくarmプロセッサーという点で、既存のプログラムが互換されない可能性もあるので、利用しているOSやアプリケーションがArm CPUに対応しているかを確認する必要があります。多くのDBエンジンではarmの対応をしているので、DB系では互換性の考慮が不要なり、比較的に移行のコストは低いといわれています。
最後に、省電力である点もGravitonの特徴として挙げられます。
机上調査
スペックの比較
まず、Auroraで利用できるdb.XX.largeのインスタンスで、r5,r6i,r6g,r7g,r8gのスペックを調べてみました。料金は東京(ap-northeast-1)基準です。
| db.r5.large | db.r6i.large | db.r6g.large | db.r7g.large | db.r8g.large | |
|---|---|---|---|---|---|
| プロセッサ | Intel Xeon Platinum 8175 | Intel Xeon Platinum 8375 | AWS graviton 2 | AWS graviton 3 | AWS graviton 4 |
| アーキテクチャ | x86_64 | x86_64 | arm64(Neoverse N2) | arm64(Neoverse V1) | arm64(Neoverse V2) |
| vCPU | 2 | 2 | 2 | 2 | 2 |
| メモリ(GiB) | 16 | 16 | 16 | 16 | 16 |
| 最大 EBS 帯域幅 (Mbps) | 最大 4,750 | 最大 10,000 | 最大 4,750 | 最大 10,000 | 最大 10,000 |
| ネットワーク帯域幅 (Gbps) | 最大 10 | 最大 12.5 | 最大 10 | 最大 12.5 | 最大 12.5 |
| 料金 | 0.35ドル/時間 | 0.35ドル/時間 | 0.313ドル/時間 | 0.33ドル/時間 | 0.33ドル/時間 |
| その他 | 大阪は未リリース | 大阪は未リリース |
r5を基準にCPU以外の性能を比較すると
- r6g以外のインスタンスではEBSとネットワークの帯域幅が向上している
- r6iはr5と同価格で、Graviton系インスタンスはよりやすくなる
このことから、同じx86アーキテクチャのr6iに移行するだけでも、現在と同じ料金でEBSとネットワークの性能向上が期待できます。また、Graviton系では、最も低コストを重視するならr6g、性能と価格のバランスを重視するならr7gまたはr8gが選択肢となりそうです。
db.r7g, db.r8gは大阪リージョン未対応
残念ながら、db.r7gとdb.r8gインスタンスは大阪リージョンではまだリリースされていません（なお、EC2インスタンスではr7gまでリリース済みです）。我々のシステムでは、Global Databaseを使用して東京と大阪でDR構成を組んでいるので、r6gを選ぶしかなさそうでした。
しかし、AWSサポートに確認したところ、東京リージョンでr8g、大阪リージョンでr6gというように、リージョンごとに異なるインスタンスタイプでクラスターを構成できることがわかりました。運用中の特に大きくデメリットはないものの、DR発動時には大阪のr6gがメインとなるため、それに伴うパフォーマンスの低下が発生します。できればインスタンスタイプは統一したいところですが、r7g、r8gのコストパフォーマンスが圧倒的に優れている場合は、選択肢の１つとして考慮できると思っています。
余談ですが、ライターはr8g、リーダーはr6gのように、同じリージョンのクラスター内でも異なるインスタンスタイプを使用してコストを削減することが可能です。ただし、この場合、リーダーの性能がライターの変更に追いつけず、問題発生の可能性があります。
ネットでの検証結果調査
Gravitonのインスタンスの検証については、AWS側での検証結果や先人たちの性能検証の情報がネットに多くあります。
それらの記事を読むと、「性能は一律に向上するわけではなく、パフォーマンスの低下を許容できるかどうかの判断が必要」とのことでした。例えば、Gravitonインスタンスで特定のテーブルの応答が遅くなったとしても、そのテーブルの利用頻度が低く、ユーザーのサービス利用にほとんど影響がない場合は、コスト削減のメリットを活かしてGravitonを選択する余地があると考えられます。
実際の検証
検証パターン
STG環境で以下の条件で検証を行いました。より厳密な検証では、Performance InsightsでクエリのレイテンシーやCPUの負荷状況を確認すべきですが、今回は「Gravitonってどう？」レベルの検証として、ジョブの実行時間のみで比較することにしています。
| 項目 | 値 |
|---|---|
| インスタンスタイプ | r5.large, r6i.large, r6g.large, r7g.large, r8g.large I/O-Optimized オプションあり、なし（r5除く） 合計 ９パターン |
| リージョン、AZ | 東京(ap-northeast-1)、AZは同一 |
| DBエンジン | Amazon Aurora PostgreSQL 16.4 |
| テスト方法 | 各インスタンスでテストジョブを実行し、完了時間を比較する |
| テストジョブ | 約５万行のCSVから情報を読み取り、SELECT後、状況によってINSERTとUPDATEが発生する |
| 計測回数 | ３回 |
Aurora I/O-Optimized について
今回はインスタンスごとの比較に加えて、Aurora I/O-Optimizedの有無による性能差についても比較することにしました。
まず、Auroraの料金はインスタンス＋ストレージ＋I/Oオペレーション料金の合計で構成されています。
ここでI/O-Optimizedを利用すると、
- インスタンス料金が約1.3倍になります
- ストレージの料金が約2.25倍になります
- I/Oオペレーション料金が発生しません
になります。
つまり、インスタンスとストレージの利用料金は高くなりますが、I/Oオペレーションの料金が発生しないという特徴があります。日常的にI/O処理の多いワークロードでは、Auroraの利用料金を節約できるオプションです。AWSによると、I/Oオペレーションの料金がAuroraの全体料金の25％以上を占める場合、最大40％のコスト削減ができるとアピールしています。また、I/O-Optimizedへの変更は30日に1回のみ可能となっています。
また、I/O-Optimizedを利用する場合、コスト面ではなく性能向上の面でも向上が見込められるような記事がありました。
Aurora PostgreSQL I/O-Optimized cluster configuration introduced smart batching to optimize database write operations. At its core, this feature uses an adaptive algorithm to dynamically adjust batch flush size and frequencies based on real-time storage performance feedback. The storage client process continuously monitors how quickly the distributed storage processes write batches and automatically optimizes batch sizes to minimize latency while maintaining efficient write throughput.
Aurora PostgreSQL I/O最適化クラスタ構成は、データベースの書き込み操作を最適化するスマートバッチングを導入しました。 この機能の中核は、リアルタイムなストレージ性能のフィードバックに基づき、バッチフラッシュサイズと頻度を動的に調整する適応型アルゴリズムを使用することです。 ストレージクライアントプロセスは、分散ストレージの書き込み処理速度を継続的に監視し、効率的な書き込みスループットを維持しながら、レイテンシを最小化するためにバッチサイズを自動的に最適化します。
記事ではインスタンスタイプの違いだけではなくPostgreSQLのバージョンの違いもあるので、I/O Optimizedで性能が向上したとははっきり言えないところもありますが、仕組み的には効率的なスループット、レイテンシの最小化を目指して最適化するとの説明があったので、今回の検証で一緒に確認してみることにしています。
検証結果
以下の検証結果となります。ioとついているのはI/O-Optimizedを利用したときの件かです。料金は東京リージョンの時間単位料金となります。コスパについては、インスタンス時間料金 x (実行時間/3600) で計算して、ジョブの１回実行にかかるコストを計算しています。I/Oオプションではインスタンス料金とストレージ料金が異なるので、一旦実行時間だけを比較してコスパ比較では除外しています。
| r5 | r6i | r6i(io) | r6g | r6g(io) | r7g | r7g(io) | r8g | r8g(io) | |
|---|---|---|---|---|---|---|---|---|---|
| １回目 | 11:34 | 06:32 | 06:29 | 11:43 | 08:24 | 07:29 | 07:18 | 06:23 | 06:18 |
| ２回目 | 11:42 | 06:59 | 06:18 | 11:29 | 08:20 | 07:25 | 07:12 | 06:24 | 06:16 |
| ３回目 | 11:41 | 06:44 | 06:16 | 09:08 | 08:04 | 07:08 | 07:17 | 06:22 | 06:18 |
| 平均 | 11:39 | 06:45 | 06:21 | 10:47 | 08:16 | 07:21 | 07:16 | 06:23 | 06:17 |
| 平均比較 | 100% | 173% | 183% | 108% | 141% | 159% | 160% | 183% | 185% |
| 料金 | 0.35 | 0.35 | 0.313 | 0.33 | 0.33 | ||||
| コスパ | 0.067(100%) | 0.039(173%) | 0.056(121%) | 0.040(168%) | 0.035(194%) |
表から確認すると
- 性能は r8g > r6i > r7g > r6g >= r5
- コスパは r8g > r6i > r7g > r6g > r5
という結果となりました。
r8gはx86系プロセッサのr6iと比較しても、料金面と性能面の両方で優れており、東京リージョンではr8gを選択するのが最適だと考えられます。また、今回の比較ではr7iは比較していませんでした（現在r8系はr8iはなくr8gだけがリリースされています）。しかし、r7iの料金も0.35ドル（東京リージョン）でr6iと同一であるため、r7iがr8gより性能が良い場合は、性能を取るかコストパフォーマンスを取るかで選択が分かれることになると思います。
また、r5、r6gとその他インスタンスで、実行時間が約4~5分ほと差があるのは、EBSとネットワークの帯域幅が上がったのが影響されていると思われます。
I/O Optimizedオプションは全インスタンスで性能が若干向上する結果となりました。特にr6gでは実行時間が最大4分短縮され、より検証してみる必要があると思いました。I/O Optimizedはダウンタイムなしで適用できるため、r5でも同様の実行時間短縮ができるのであれいば、ぜひ適用したいと思います。我々の環境では月1万円程度のコスト削減もできる見込みなのでなおさらですね。
最後に、我々の環境はlargeインスタンスを使用する小規模システムであり、検証に使用したジョブも11分程度で完了する軽めのものでした。より大規模なインスタンスを使用するシステムや、より負荷の高いジョブで比較した場合、この性能差はさらに大きくなると考えられます。
結局AuroraのインスタンスはGravitonにするのがいいのか
今回の結果からみると、最新のGravitonインスタンスであるr8gを使ったほうがいいと思います。しかし、r7iでも検証がまだであることと、単純にジョブの実行時間だけを比較した検証だったため、完全には「はい！」とは言い切れないところがあると思っています。
本格的な検討フェーズでは、クエリのレイテンシやCPU利用率など、さまざまな指標について総合的な検証・評価が必要となります。
ただし、コストの安さという点では現時点でも非常に魅力的で、性能も世代を重ねるごとに着実に向上しています。「はい！Gravitonを使うべきです！」と自信を持って言える日も、そう遠くないかもしれません。
とりあえず、我々のインスタンスはr5から移行したほうがよさそうです(笑)