【TECH BLOG】Aurora Serverless v2を本番導入した話 〜検討や導入時のポイント・得られた効果について〜

はじめに

こんにちは。SRE部ECプラットフォーム基盤SREブロックの石田です。

本記事では、Aurora Serverless v2を本番導入するにあたってどのような検討をし、どのように導入していったか、また導入後に得られた効果について紹介します。

• はじめに
• Aurora Serverless とは
• 背景
• 比較検討
• • 比較内容
  • 方針の決定
• アーキテクチャ
• 導入
• • 1. Aurora Serverless v2を手動で構築
  • 2. AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築
  • 3. AWS CloudFormationでAurora Serverless v2に移行
  • 4. 負荷試験・障害試験
  • 負荷試験
  • 障害試験
• 導入により得られた効果
• • 柔軟なスケーリング
  • インフラコスト
• 最後に

Aurora Serverless とは

Aurora Serverlessとは、Amazon AuroraにおいてオンデマンドのAuto Scaling設定が行えるデータベースです。アプリケーションニーズに応じて自動的に起動・停止が可能で、データベース容量を管理することなく、スケールアップ・スケールダウンが可能です。

Aurora Serverlessのデータベースの容量は、ACU(Aurora Capacity Unit)という単位が用いられています。1ACUあたり約2GiBのメモリと対応するCPU、ネットワークが組み合わされています。

また、Aurora Serverlessには、Aurora Serverless v1とAurora Serverless v2が存在します。v1とv2の比較は公式ドキュメントをご確認ください。

背景

ZOZOTOWNではシステムリプレイスを進めており、2022年の春に会員基盤のクラウド化・マイクロサービス化をはじめました。これまでデータベースにはSQL Serverを使用していましたが、リプレイス後はMySQLを使うことが決まっていました。

私たちは2022年6月頃にAWS側で用意するMySQLデータベースの選定を始め、下記のような背景がありAurora Serverless v2の採用を検討しました。

• コミュニティMySQL 5.7のEOLは2023年10月であり、EOL対応が必要になるため新規構築のタイミングでMySQL 8.0を採用したい
• セールなどの高負荷時に備えて手動でスケールアップするといった運用負荷をできる限りなくしたい

比較検討

検討を進める上では、Provisioned型のAurora MySQLバージョン3とProvisioned型のAurora MySQLバージョン2を比較して検討しました。

比較内容

選定ポイントとなる項目に対する比較表が下記の通りです。

Aurora Serverless v1は、マルチAZに対応していないことやスケーリング速度がv2より遅いことが懸念としてあったため、比較対象からは除外しています。

本検討は2022年6月27日時点の内容になります。

それぞれの比較内容について説明します。

• MySQL 8.0互換である
• • MySQL 8.0互換はEOLまで期間があり直近でのバージョンアップ作業は不要です。Provisioned型Aurora MySQLバージョン2はMySQL 5.7互換のため、EOLを迎える前にバージョンアップ作業が必要になります。
• LTSバージョンに対応している
• • LTSバージョンに対応していない場合、強制アップデートの回数は多くなり、アップデート通知からの猶予期間も短い可能性があります。
  • 2022年2月27日現在でもAurora Serverless v2及びProvisioned型Aurora MySQLバージョン3はLTSバージョンに対応していません。
• AWS CloudFormationによるIaC化ができる
• • 弊チームではIaCによる環境構築を徹底しており、AWSリソースであれば、可能な限りAWS CloudFormationにて管理できるものを選択しています。
  • 検討時点ではAurora Serverless v2はAWS CloudFormationには対応していませんでしたが、2022年10月5日にサポートを開始したことを発表しました。
• アプリケーションのレイテンシー目標を達成できる
• • Provisioned型Aurora MySQLは運用実績があったため、レイテンシー目標を達成できる見込みがありました。Aurora Serverless v2は運用実績がなく、レイテンシー目標を達成できるかどうかは検証が必要です。
• スケールアップ作業が不要
• • Aurora Serverless v2はオートスケールするため、セールなどの高負荷時にスケールアップ作業は不要です。Provisioned型Aurora MySQLはスケールアップする作業が発生します。
• インフラコストが抑えられる
• • Provisioned型Aurora MySQLはある程度の商用負荷を想定して大きめのスペックを用意する必要があります。Aurora Serverless v2は検討時点では通常時やピーク時のリクエスト数に対するスペックは不確定なため、比較してインフラコストが抑えられるかはまだ不明の状況でした。

方針の決定

ZOZOTOWNの会員基盤がAurora Serverless v2を採用する上での懸念は下記のようなものでした。

1. LTSバージョンに対応していないこと
2. 検討時点ではAWS CloudFormationによるIaC化ができないこと
3. レイテンシー目標を達成できるか
4. インフラコストを抑えられるか

これらを踏まえ、懸念について判断ポイントを設け、方針を決定しました。

1つ目のLTSバージョンに対応していないことについては、深夜帯にメンテナンスを設け、数十秒のサービス断であれば問題ないと判断しました。

2つ目のIaC化については、パフォーマンスを評価する負荷試験の実施前までにAWS CloudFormationがサポートされれば良いと考えました。そのため、開発期間中は手動で構築したAurora Serverless v2を活用することとしました。

3つ目のレイテンシーについては、負荷試験にてデータベースの観点でレイテンシー目標を達成できなければ、Provisioned型Aurora MySQLバージョン3に切り替えることとしました。

4つ目のコストについては、負荷試験後に概算し許容できるかを判断することとしました。

アーキテクチャ

ZOZOTOWN会員基盤の大まかなアーキテクチャは下図の通りです。

アプリケーションはEKSで稼働し、Aurora Serverless v2はWriter Instance 1台、Reader Instance 1台のマルチAZ構成となります。

導入

方針で決めたことをもとに、導入に向けて対応したことや考慮した点を順に説明します。

1. Aurora Serverless v2を手動で構築
2. AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築
3. AWS CloudFormationでAurora Serverless v2に移行
4. 負荷試験・障害試験

1. Aurora Serverless v2を手動で構築

方針決定後の時点でもAurora Serverless v2はAWS CloudFormationに対応していなかったため、公式ドキュメントを参考に手動で構築しました。

2. AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築

負荷試験が始まる前、Aurora Serverless v2はAWS CloudFormationにまだ対応していませんでした。そのため、方針決定時の判断ポイントに従ってAWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築しました。

この時、アプリケーション開発中でありデータを保持する必要があったため、新規で構築して切り替えるといったことができませんでした。そのため、mysqldumpでバックアップを取得し、AWS CloudFormationで構築したProvisioned型Aurora MySQLバージョン3にリストアを実施しました。

3. AWS CloudFormationでAurora Serverless v2に移行

Provisioned型Aurora MySQLバージョン3を再構築した同じタイミングで、Aurora Serverless v2がAWS CloudFormationのサポートを開始しました。負荷試験が始まる直前でしたが、このタイミングを逃したくないと考え、AWS CloudFormationでAurora Serverless v2へ移行することにしました。

基本的な移行の流れは、公式ドキュメントに従ってAWS CloudFormationで作業していきます。Aurora Serverless v2への移行はフェイルオーバーで切り替えが必要なため、一時的に接続できなくなりますが、再構築は不要でアプリケーション開発には影響なく移行できました。

Aurora Serverless v2をAWS CloudFormationで定義する際の注意点としては、Aurora Serverless v1とは異なるパラメータがあることです。例えば、ServerlessV2ScalingConfigurationなどです。AWS::RDS::DBClusterの「Amazon Aurora Serverless v2 DBクラスターの作成」をよく確認する必要があります。

4. 負荷試験・障害試験

移行したAurora Serverless v2について、負荷試験・障害試験の実施内容と結果を説明します。

続きはこちら