はじめに
この記事は、ミロゴス Advent Calendar 2023 4日目の投稿です。
本記事では、Gravitonへ移行した背景と学んだ内容について紹介できればと思います。
背景、目的
弊社では積極的にコスト削減に取り組んでおり、最近の調査でRDSとElastiCacheの稼働コストが膨大であることが判明しました。
この情報を踏まえ、Gravitonプロセッサへの移行を選択し、これによってコストの最適化を図っています。
※ EC2に関しては、アプリケーションで使用されているツールやライブラリの互換性、および使用しているOSの変更などからくる課題により、現段階ではEC2のプロセッサーの変更は実施しておりません。
Gravitonとは
Gravitonは、AWSが開発した独自のプロセッサで、ARM 64ビットアーキテクチャ（arm64）を採用しています。
以下はその主な特徴です。
低価格
GravitonプロセッサはARMアーキテクチャを利用し、その低消費電力性がコスト効率の向上に寄与しています。
これにより、低価格で高性能なコンピューティングリソースを提供し、クラウドリソースのランニングコストを削減できます。
高性能
多数のCPUコア（コア数）を搭載したGravitonプロセッサは、高い並列処理能力を実現しています。
これにより、マルチスレッド処理に優れ、複数のタスクを同時に処理が可能です。
そのため、さまざまなワークロードに柔軟に対応できます。
環境への配慮
Gravitonプロセッサはエネルギー効率が向上し、二酸化炭素排出量の削減に寄与しています。
省電力性を備えたこのプロセッサは、エコフレンドリーな選択肢として注目されており、環境への負荷を低減します。
AWS Graviton Black Belt Online Seminar
AWSの技術担当者によるGravitonの解説資料です。
要件
コストの把握
まず、コスト削減の手法を適用する前に現状のコストを把握します。
サービス一覧から「Cost Explorer」を選択し、現在のコストを確認します。
インスタンス（ノード）タイプの調査
移行先のインスタンスタイプがどのような種類と性能があるのかを確認します。
主要なインスタンスタイプには以下のようなものがあります。
（詳細については下記の参照リンクから確認してください。）
T系
T 系インスタンスクラスは、低コストで柔軟性のあるリソースを提供することが特徴です。
バースト性能を活かし、一時的な処理が発生する場合に効果的です。
CPU クレジット制度を採用しており、クレジットが残っている限り、一時的に高いパフォーマンスを発揮できます。
ただし、長時間にわたる高負荷のワークロードには向かないことがあります。
M系
M 系インスタンスクラスは、バランスの取れた一般的なワークロードに適しています。
中程度の計算能力とメモリ容量を提供し、多岐にわたるアプリケーションに使用されます。
汎用性が高く、安定したパフォーマンスが求められる場面で選ばれることがあります。
R系
R 系インスタンスクラスは、メモリ集中型のワークロードに特化しています。
大規模データベースやメモリ集中型アプリケーションにおいて、高いメモリ容量を提供します。
データの処理と分析が主要な要素となる場合に有用です。
RDS インスタンスタイプ
インスタンスタイプ一覧です。DB インスタンスクラス
インスタンスタイプ一覧の解説です。Redis ノードタイプ
Redis ノードタイプ一覧です。Memcached ノードタイプ
Memcached ノードタイプ一覧です。
移行対象のリソース調査
Gravitonへの移行を検討する際、対象となるリソースの調査が重要です。
特にRDSやElastiCacheなどのデータベースやキャッシュが対象となる場合、以下のステップを踏んで確認することが必要です。
エンジンのサポート
Gravitonプロセッサがサポートするエンジンを確認し、対象のインスタンス（ノード）タイプがそのエンジンを使用しているか確認します。
もし低い場合は、Gravitonへ移行する前にエンジンバージョンのアップデートを手順に追加する必要があります。
インスタンスタイプでサポートされている DB エンジン
インスタンスタイプごとにサポートされているエンジンバージョン一覧です。サポートされているノードの種類
ノードタイプごとにサポートされているエンジンバージョン一覧です。
パフォーマンスの予測
Gravitonプロセッサの特性を考慮し、移行後のパフォーマンスを予測します。
弊社ではCloudWatchのメトリクスを確認し、現状の稼働状況を詳細に検討した上で、移行後のインスタンス（ノード）タイプの決定に至りました。
以下は検討の観点です。
RDSの場合
CPUUtilization（CPU 使用率）
高いCPU使用率は、処理能力の限界に達しており、それ以上の負荷を処理できない可能性があります。
現在の使用率から適切なインスタンスタイプを選択し、十分な処理能力を確保します。
ReadLatency（読み取りレイテンシ） / WriteLatency（書き込みレイテンシ）
インスタンスタイプの性能が低い場合、ディスク I/O 処理に対する制約が生じ、読み取り/書き込みレイテンシが増加する可能性があります。
高いレイテンシを防ぐためには、適切なインスタンスタイプを選択することが必要です。
CPUCreditBalance（CPU クレジット残量）
インスタンスサイズが小さい場合、CPU クレジットがバーストを起こし残量が0になると、料金が発生します。
したがって、適切なインスタンスサイズを選択することが重要です。
DatabaseConnections（データベース接続数）
データベース接続数が増加すると、システムへの負荷が増す可能性があります。
現在の最大接続数から適切なインスタンスサイズを選択し、十分な接続を処理できるようにします。
Amazon RDS の Amazon CloudWatch メトリクス
メトリクス一覧の説明です。
ElastiCacheの場合
CPUUtilization（CPU 使用率）
CPU 使用率はシステムの負荷を示し、Gravitonへの移行がCPUパフォーマンスにどれだけ影響を与えるかを示します。
現在の使用率から適切なインスタンスタイプを選択し、十分な処理能力を確保します。
SwapUsage（スワップ使用量）
スワップの使用が増加するとディスク I/Oが発生し、パフォーマンスが低下する可能性があります。
このメトリクスを監視して、現在のメモリ確保が十分かどうかを確認し、必要に応じて適切なインスタンスタイプやサイズへの変更を検討します。
Redis メトリクス
Redis メトリクスの説明です。Redis モニタリングすべきメトリクス
CloudWatchアラームの設定おすすめ一覧です。Memcached メトリクス
Memcached メトリクスの説明です。Memcached モニタリングすべきメトリクス
CloudWatchアラームの設定おすすめ一覧です。
削減コストの推測
Gravitonへの適用はリスクもあるため、料金の削減度合いを事前に調査しておきます。
AWS Pricing Calculatorを活用して、対象のAWSサービスを指定して、移行前のインスタンスタイプと移行後のGravitonを比較します。
手順
- 対象のサービスを選択します。
- サービスに応じて項目を埋めます。
- 移行前のインスタンスタイプと移行後のGravitonの月額コストを記録します。
- 差額を計算することで削減コストを記録します。
各リソースごとの差額を合計することで全体の削減コストの予測を立てることができます。
弊社では、おおよそ10%程度の削減が見込まれると推測しておりました。
関係部署との調整
影響範囲の共有
移行が関係する部署やチームと協力して、移行がもたらす影響範囲を共有します。
関係部署と連携して、移行がもたらす潜在的な変更点やプロセスへの影響を深堀りし、関係者全体が一貫した理解を持てるように努めます。
移行計画の調整
関係者と協力して、移行のスケジュールや手順を検討し、適切な移行計画を策定します。
計画の進捗を透明に共有し、変更が生じた際には素早く調整できる柔軟性を確保します。
トラブルシューティングの準備
移行中に発生する可能性のある問題に備え、トラブルシューティングの手順や対応策を関係部署と協力して準備します。
円滑な問題解決に向け、チーム全体での認識と対応力を強化します。
これらのステップを踏んで、移行可能なリソースを確認することでGravitonへの移行を実現できます。
（参考）弊社で起きたエラーについて
特に注意すべきポイントとして、Connections数が挙げられます。
弊社では、CPUやメモリの利用状況を見てGravitonへの変更と同時にインスタンスサイズを下げた結果、最大接続数が減少し、それによって処理が停止してしまいました。
接続数が最大まで達すると、新しい接続が受け入れられなくなります。
したがって、各インスタンスサイズがどの程度の最大接続数（maxConnections）をサポートしているかを計算し、正確に評価する必要があります。
接続数の管理は、システムの安定性と性能に直結するため、慎重に行う必要があります。
- 例：maxConnectionsの計算方法（PostgreSQL、db.t4g.microの場合）
- デフォルト値（式）
- LEAST({DBInstanceClassMemory/9531392}, 5000)
- 計算
- DBInstanceClassMemory = 1 GB = 1024 メガバイト = 1024 × 1024 キロバイト = 1024 × 1024 × 1024 バイト
- 1024 × 1024 × 1024 / 9531392 = 112 (最大接続数)
- デフォルト値（式）
データベース接続の最大数
最大接続数に関する計算方法などが載っています。
（参考）AZによって特定のインスタンスタイプが適用できない可能性について
弊社では、ElastiCacheのGraviton移行をする際にインスタンスタイプとしてcache.m7g.largeをコンソール上から選択しようとしましたが、選択肢一覧に表示されませんでした。
別の手段としてAWSのコマンドを使用して移行を試みると、以下のエラーメッセージが表示されました。
$ aws elasticache modify-replication-group --replication-group-id test-cluster --cache-node-type cache.m7g.large
An error occurred (InsufficientCacheClusterCapacity) when calling the ModifyReplicationGroup operation: cache.m7g.large (VPC) is not currently supported in the availability zone ap-northeast-1a.
Retry the launch with no availability zone or target: ap-northeast-1c, ap-northeast-1d.
上記をAWSサポートへの問い合わせの結果、以下の回答が返ってきました。
調査いたしましたところ、ノードが配置されているアベイラビリティーゾーンに起因して、コンソールでのクラスター変更における対象ノードタイプの選択可否が変化する状況を確認いたしました。
また、当方の検証環境でも "ap-northeast-1a" にノードが配置されている場合に、コンソールでのクラスター変更に cache.m7g.large などが選択できないことを確認しております。
つきましては、クラスターのノードが ap-northeast-1c および ap-northeast-1d のみに配置されている状態で、ノードタイプの変更をご検討いただけますでしょうか。
弊社ではシステムの都合上、別のインスタンスタイプでの移行で対処しましたが、クラスターのノードをサポートされているAZを対象に配置した状態で変更をすれば選択できるようになります。
（注）上記の例は 2023 年 9 月 14 日時点のものであり、アップデートにより変更される可能性があります。
作業
RDSの場合
スナップショットの作成
障害に備えて、スナップショットを作成しておきます。
- 対象となるRDSデータベースを選択します。
- データベースの詳細画面で「スナップショットの取得」を選択します。
- スナップショット名を記載します。
- 「スナップショットの取得」のボタンを押下します。
リソースの適用
Gravitonの適用方法は以下の手順になります。
- 対象となるRDSデータベースを選択します。
- データベースの詳細画面で「変更」を選択します。
- インスタンスの設定から対象のインスタンスタイプ（Graviton）を選択します。
a. ※ エンジンバージョンが低い場合、対象のインスタンスタイプをサポートしていない場合があります。
先にエンジンバージョンのアップデートを実行しましょう。 - 変更を保存します。
ElastiCashの場合
バックアップの作成
障害に備えて、バックアップを作成しておきます。
- 対象となるElastiCacheのキャッシュクラスターを選択します。
- キャッシュクラスターの詳細画面で「バックアップを作成」を選択します。
- 新しいバックアップ名を記載します。
- 変更を保存します。
リソースの適用
Gravitonの適用方法は以下の手順になります。
- 対象となるElastiCacheのキャッシュクラスターを選択します。
- キャッシュクラスターの詳細画面で「変更」を選択します。
- 「クラスター設定」->「ノードのタイプ」から対象のノードタイプ（Graviton）を選択します。
- ※ エンジンバージョンが低い場合、対象のノードタイプをサポートしていない場合があります。 先にエンジンバージョンのアップデートを実行しましょう。
- 変更を保存します。
効果について
コスト推移
社内プロダクトのRDSとElastiCacheをGravitonに移行した結果、9月初旬以降、毎月のコストが約10％削減されました。
今後、移行を検討される方については、現状のコストから10%減を目安として良いかと思います。
さいごに
Gravitonへの移行は、RDSやElastiCacheの場合において比較的スムーズかつ手軽に実行できるため、おすすめです。
また、移行の準備を進める中で、AWSサービスに関する知識も身につけることができるため、試して良かったと感じました。
次回のコスト削減についても紹介できればと考えています。