見出し画像

RDSからAuroraへの移行でパフォーマンス向上とコスト削減の両方を実現した話

ONE CAREER Tech Blog

はじめに

Hi everyone!

ワンキャリアでインターンをしている渡邉です。
私はSREチームに所属し、プロダクトチームと連携しながらサービスの信頼性向上を目指して運用・監視の自動化やインフラの強化に注力しています。
SREチームについてはこちらの記事をご覧ください。

今回は一部のデータベースエンジンをAmazon  RDSからAmazon Auroraに移行し、Graviton プロセッサーを利用することで、パフォーマンスの向上と同時にコストの削減を実現した事例について共有します。




きっかけ

元々AWSで利用しているデータベースリソースは主に、RDSのインスタンスを使用していました。それを Aurora に置き換えることにより、性能面での向上(RDSの3倍のスループットを許容) やReadReplica を自動的に増減することによる Auto Scaling 機能を使用できます。また、性能面のパフォーマンスが高いため一 RDS インスタンスをAuroraサービスに、プロセッサーをコストパフォーマンスが高いGravitonに移行することにしました。

Gravition プロセッサーとは

AWSが独自開発するプロセッサで、ARM 64bit アーキテクチャ(arm64)で動作します。x86 アーキテクチャを採用するインスタンスを選択するよりもコストパフォーマンスが高くなる傾向があります。このBlogの執筆時点では、第3世代までリリースされています。詳細は、AWS Blackbelt の記事をご参照ください。

参考：AWS Graviton AWS Black Belt Online Seminar

Graviton のユースケース

コストパフォーマンスが高いメリットを生かして、AWS利用料を削減し、ランニングコストを下げたい場合に選定することをおすすめします。

ただし、条件によって選べる場合・選べない場合があったり、選ぶことでのリスクや対応負担がありますので、十分に検討してください。

マイグレーションにおけるAWSサービスごとの検討

Graviton プロセッサーを選定する際、AWS マネージドサービスであればアーキテクチャ差異を吸収するため、採用難易度は低くなる傾向があります。

  • 難易度：低（データベースエンジンがOSやアーキテクチャ差異を吸収する）

    • AWSサービス：RDS、Aurora、ElastiCache

    • 古いバージョンでは、Graviton が未サポート

  • 難易度：中（検討事項はあるが、そのままマイグレーション可能なケースあり）

    • AWSサービス：ECS , Fargate , Lamdba

    • イメージファイルはマルチCPUに対応するケースが多いが、コンパイルが必要なケース有り

  • 難易度：高（原則アプリケーションの再コンパイルや改修が必要）

実際に行ったこと

今回のAurora移行で実施したことは大きく2つあります。

  • インスタンスのDBエンジンをPostgreSQLからAurora PostgreSQLに移行

    • 同時にインスタンスのアーキテクチャをGravitonに移行

  • リザーブドインスタンスの購入（使用するリソースを前払いするシステムで、オンデマンドに比べて2-3割ほどの割引がもらえる）

今回は以下の流れで実施しました。

  • 現状調査

    • Aurora 移行への影響度合いの確認

    • Aurora インスタンスの選定

  • 移行検証

    • 検証環境で手順と性能を確認する

  • 本番作業

    • 実際に RDS から Aurora へ移行

    • インスタンス識別子が変更になることから、メトリクス監視の変更

  • 効果測定

    • 性能比較

    • Reserved Instanceの購入

    • コスト比較

SREチームとプロダクトチームの力も借りながら、検証から本番反映まで無事に完了することができました。

DBエンジンをAuroraに移行するだけでなく、インスタンスのアーキテクチャもIntelのプロセッサ(m4)からGraviton(r6g)というプロセッサに移行しました。

成果

今回はRDSのインスタンスサイズに近いGravitonプロセッサーを使ったAurora に移行しました。データベースの書き込みレイテンシーが10 〜 50msでしたが、移行後は1ms程度まで速くなりました！アーキテクチャを変更することで、ここまで改善されるとは思っていなかったので、正直驚きました。

また、アーキテクチャのGraviton移行とRIの購入を含めるとクラスターのコストを半分にまで削減することができました。

↑ (Auroraへの移行は23年4月の上旬に実施)

ちなみに、SREチームでは他にもAWSリソースのコストを最適化するために様々な取り組みを行っています！

  • 不必要なリソースの削除、インスタンスサイズの見直し

  • Savings PlanやReserved instanceの購入

  • 検証環境リソースの夜間停止＆自動化

  • ECSサービスやRDSインスタンスのGraviton移行

学んだこと

RDSのAurora移行では、SREチームだけでなく開発チームとの連携の大切さを特に感じました。今回は、開発チームに検証や本番適応のサポートをお願いしました。本業である開発リソースを一部いただくことになるため、移行による効果、リスク、検証から終わりまでの手順をしっかり伝える必要があります。特に規模が大きい企業にとって、プロダクトの改善に大きく関わる作業を遂行するためには、開発チームと認識を揃えることが必要不可欠ですね。

終わりに

いかがでしたか？他のDBエンジンからAuroraに移行してみようと思っている方や、AWSリソースのコスト最適化を実施している方の参考になれば嬉しいです。
ちなみにワンキャリアでは、エンジニアを絶賛募集中です！
ご興味のある方はぜひカジュアルにお話しをしましょう！


▼ワンキャリアのエンジニア組織のことを知りたい方はまずこちら

▼カジュアル面談を希望の方はこちら

▼エンジニア求人票

この記事が参加している募集

オープン社内報

21,893件

この記事が気に入ったらサポートをしてみませんか？