はじめに
こんにちは。SRE部ECプラットフォーム基盤SREブロックの石田です。
本記事では、Aurora Serverless v2を本番導入するにあたってどのような検討をし、どのように導入していったか、また導入後に得られた効果について紹介します。
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日時点の内容になります。
| Aurora Serverless v2 | Provisioned型Aurora MySQLバージョン3 | Provisioned型Aurora MySQLバージョン2 | |
|---|---|---|---|
| MySQL 8.0互換である | ○ | ○ | × |
| LTSバージョンに対応している | × | × | ○ |
| AWS CloudFormationによるIaC化ができる | ×（検討時） | ○ | ○ |
| アプリケーションのレイテンシー目標を達成できる | 要検証 | ○ | ○ |
| スケールアップ作業が不要 | ○ | × | × |
| インフラコストが抑えられる | ユースケースによる | ユースケースによる | ユースケースによる |
それぞれの比較内容について説明します。
- 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を採用する上での懸念は下記のようなものでした。
- LTSバージョンに対応していないこと
- 検討時点ではAWS CloudFormationによるIaC化ができないこと
- レイテンシー目標を達成できるか
- インフラコストを抑えられるか
これらを踏まえ、懸念について判断ポイントを設け、方針を決定しました。
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構成となります。
導入
方針で決めたことをもとに、導入に向けて対応したことや考慮した点を順に説明します。
- Aurora Serverless v2を手動で構築
- AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築
- AWS CloudFormationでAurora Serverless v2に移行
- 負荷試験・障害試験
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について、負荷試験・障害試験の実施内容と結果を説明します。
負荷試験
データベース観点で負荷試験を実施することで、アプリケーションのレイテンシー目標を達成できるか確認しました。
具体的には、Aurora Serverless v2のMax ACUは64に固定し、Min ACUを2から16まで変動させ、Min ACUによってレイテンシーがどのように変化するのか確認します。商用を想定したリクエストを5分間流し続けることで負荷をかけます。
負荷をかけるツールは弊チームで開発したOSSツールであるGatling Operatorを使用します。詳細は以前TECH BLOGに公開された下記記事をご参照ください。
負荷試験の結果は下記グラフの通りです。
これより、Min ACUが小さいとレイテンシーは高くなり、徐々に大きくしていくとレイテンシーは低くなりますが、大きくしすぎてもレイテンシーはそれほど変わらないことがわかります。レイテンシー目標としてはMin ACUが3で達成できたため、この値を採用しています。
障害試験
障害試験では、アプリケーションにリクエストを流しながらフェイルオーバーした際のサービス断時間や、ACU変更時にサービス断が発生するか確認しました。
試験結果は以下の通りです。
| 確認項目 | サービス断 |
|---|---|
| フェイルオーバー | 最大40秒 |
| Min ACU変更 | なし |
| Max ACU変更(再起動時) | 最大10秒 |
Max ACUの変更について補足すると、ACUの反映は即時ですが変更に伴うデータベースへの同時接続数などのパラメータを反映させるためには別途再起動が必要です。Reader Instanceのエンドポイントは現状使用していないため、Writer Instanceの再起動時のみ最大10秒のサービス断となりました。
運用としては1つずつInstanceを再起動可能ですが、再起動が含まれるフェイルオーバーで実施することにしています。これは、既存のProvisioned型Aurora MySQLではフェイルオーバーで実施しており、手順を統一させたいことが背景としてあります。緊急を要するようであればその時に応じて各Instanceの再起動を検討することとしています。
データベースへの同時接続数について触れましたが、Max ACUにより同時接続数が異なるため、考慮が必要です。その他含めACUのチューニングの詳細については公式ドキュメントのAurora Serverless v2でのパフォーマンスとスケーリングをご確認ください。
導入により得られた効果
Aurora Serverless v2を導入することにより得られた効果について説明します。
柔軟なスケーリング
負荷試験・障害試験の完了後、オンプレミス環境のデータベースからAurora Serverless v2へのデータ移行を実施しました。
データ移行時のACUの推移は下記グラフの通りです。
青色の線がWriter Instance、紫色の線がReader Instanceです。
Aurora Serverless v2は約14ACUまでスケーリングし、エラーなくデータ移行を完了させることができました。データ移行完了後は即座に縮退されていました。
このように柔軟なオートスケーリングにより、データ移行時のスケールアップやスケールダウンを実施する工数を削減できました。
インフラコスト
Aurora Serverless v2と、Provisioned型Aurora MySQLのインフラコストを比較し、どのような効果が得られたかを説明します。
まず、Aurora Serverless v2における3か月間のACUの大まかな推移は下記グラフの通りです。
商用環境ではスケールアップはほぼしない状況でした。一方で開発環境は必要な時にはスケールアップし、使用していない時には最小0.5ACUとなっており、柔軟にスケーリングしていることがわかります。
次に、3か月間使用したインスタンス利用料金の1か月平均をAurora Serverless v2とProvisioned型Aurora MySQLで比較した表は下記の通りです。
| Aurora Serverless v2 | Provisioned型Aurora MySQL | |
|---|---|---|
| 商用環境 | USD 893 | USD 781 |
| 開発環境 | USD 1,400 | USD 1,265 |
| 合計 | USD 2,293 | USD 2,046 |
Provisioned型Aurora MySQLはAurora Serverless v2でMaxにスケールしていたACUをインスタンスタイプに換算して試算しています。インスタンス利用料金の詳細は公式ドキュメントをご確認ください。
以上を単純に比較すると、現在の会員基盤の利用状況ではAurora Serverless v2よりProvisioned型Aurora MySQLの方がインフラコストは抑えられたという結果でした。
ただ、Provisioned型Aurora MySQLの運用時は、スケールアップなどの運用コストを抑えるために余裕をもったインスタンスタイプを用意しています。このことを考慮すると、インフラコストにあまり有意な差はなかったと判断しています。
今後、会員基盤では追加機能の開発や既存機能のリプレイスが計画されています。その際に、都度スケールアップを行うような運用コストが抑えられているという点ではポジティブに捉えています。
最後に
本記事では、Aurora Serverless v2を本番導入するにあたってどのような検討をし、どのように導入していったか、また導入後に得られた効果について紹介しました。
Aurora Serverless v2導入時には手動構築からAWS CloudFormation管理に移行したことやACUのチューニングには苦労しましたが、無事に本番導入できました。
Aurora Serverless v2を導入することにより、データ移行の高負荷時には柔軟にスケーリングし、手動でスケールアップするといった運用負荷をなくすことができました。またインフラコストについては、総括すると会員基盤の現状のユースケースでは、Provisioned型Aurora MySQLと比較してあまり有意な差はありませんでした。しかし、運用コストが抑えられているという点ではポジティブに捉えました。
今後の会員基盤においては、追加機能の開発や既存機能のリプレイスに伴い、最適な基盤を模索していきたいと考えています。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
