Illustration by Freepik Stories
株式会社アビストAIソリューション事業部 AI-Plant Bamboo 開発チームの吉田です。
AI-Plant Bambooではβ版をリリースした際に本番環境のRDSをAurora ServerlessからAuroraへ移行を行いました。
AuroraとAurora Serverlessはそれぞれ便利なリレーショナルデータベースのサービスなのですが、それぞれ少し違った特徴があり、適材適所があります。
そこで今回はAurora・Aurora Serverlessとは何か、またAurora ServerlessからAuroraへの移行方法について書いていきたいと思います。
- Aurora
- Aurora Serverless
- Aurora ServerlessからAuroraへの移行方法
- 1. スナップショットを作成
- 2. スナップショットからAuroraの立ち上げ
- 終わりに
Aurora
Auroraの概要
AWSの中で最も有名なサービスであるAmazon RDSのサービスの一部であり、完全マネージド型のリレーショナルデータベースエンジンです。
MySQLとPostgreSQLに互換性を持っていて、通常のMySQLやPostgreSQLに比べて数倍のスループットを実現することができます。
また他のRDSのサービスと違った構造を持っており、クラスターという概念が存在します。
クラスターとは1つ以上のDBインスタンスとDBインスタンスのデータを管理する1つのクラスターストレージボリュームで構成されます。
DBインスタンスは普通のRDSにもありますが、EC2インスタンスのようなコンピューティングリソースです。
一方でクラスターストレージボリュームとはストレージ（ボリューム）が3つのAZにそれぞれ2ずつ配置され、それぞれにデータがレプリケーションされている仮想データベースストレージボリュームで、かなり高い可用性が担保されています。（おまけにS3にバックアップデータが常に保存されています）
通常のRDSではDBインスタンスにはストレージボリュームであるEBSが2つ接続されているのですが、Auroraの場合はインスタンスとストレージが完全に分離されていてこれが構造的に大きな違いとなっています。
Auroraにはまだまだ他にもたくさんの機能や特徴がありますが、有名なサービスで他にも記事がたくさんあるので、詳しくはAWS公式やクラスメソッドさんの記事を参照ください。
Aurora Serverless
Aurora Serverlessの概要
まず、Aurora Serverlessという名前ですが、今流行りのサーバーレスアーキテクチャを支えるサービスではありません。
起動、スケール、停止が自動的に行われるという意味でServerlessという言葉が使われています。
Auroraではスケールの設定などをする必要がありましたが、Aurora Serverlessではその設定も必要なく自動でスケーリングを行ってくれるため、一時的に負荷が増えた時や収まった時のことを考える必要がありません。（スケールの強制オプションなど少し考えることはありますが）
もちろんAuroraで必要だったインスタンスの管理の必要もないので運用や保守の手間も省くことができます。
Aurora Serverlessの料金や注意事項について
AuroraではクラスターやDBインスタンスなどというものがありましたが、Aurora Serverlessにはそんな概念は存在せず、ACU（Aurora Capacity Unit）という単位でサービスが運用され、ACUを使った時間分課金されます。
設定できる最低ACUは1（PostgreSQL互換の場合は2）で、1ACUにつき2GBのメモリ相当のコンピューティング性能を持ち、負荷によって自動でACUが調整されます。
また、アクセスがなく一定期間アイドル状態となった場合は、デフォルトの設定では一時停止状態となり、料金がかからなくなるため、非常にコスト面で優しいサービスです。
しかし、再起動する場合は20秒から1分程度かかり、その間はレスポンスが帰ってこないため注意する必要があります。
このため開発環境であったり、社内に対してだけサービスを公開するなど、その挙動について理解の得れる環境でのみ使用するか、アイドル状態でも一時停止状態にならないようにするスケーリングオプションをつける必要があります。
料金の詳細などに関してはAWS公式情報をご覧ください
コストが低い点、スケーリングの複雑な設定がいらず自動でスケーリングしてくれる点で 開発環境、新規アプリケーションで需要がわからない場合、使用頻度の低いアプリケーションなどのユースケースに対してAurora Serverlessは最適だと思われます。
Aurora Serverlessからの移行について
一時停止状態になることが許容できなくなる場合、Auroraのより高度な機能を使用したい場合、ある程度DB需要の予測がついた場合などにAurora ServerlessからAuroraへの移行が考えられます。
※一時停止は前述したようにオプションで回避できますが、Auroraでインスタンスを常駐させてるのと変わらないのでServerlessを使う必要性が小さくなります。
コストは一般的にはAurora Serverlessが高負荷状態が続いている場合を除いて、Auroraの方が高くなりますが、リザーブドインスタンスを使用することによって20%から55%ほどAuroraの費用を抑えることも可能なので、移行も検討しながらサービス運用を考えることも必要かと思います。
AI-Plant Bambooではそれまで社内公開のみだったのが、β版リリースで一般公開されるタイミングで本番環境をAuroraに移行することにしました。（開発環境では今でもAurora Serverlessを使用しています）
Aurora ServerlessからAuroraへの移行方法
それでは実際の移行方法について説明します。
注意事項
- 移行作業中にAurora Serverlessに書き込まれた情報は失われるのでメンテナンス時間を設けるなどの対応を行ってください。
- 貼り付けたAWSコンソール等の画像中のDB名などはchromeの開発者ツールで編集して書き換えたもので、実在するものではございませんのでご安心ください。
1. スナップショットを作成
はじめにAurora Serverlessのスナップショットを作成します。
RDSのコンソールにアクセスしましょう。
1.1. 移行対象のAurora Serverlessを選択
データベース一覧の画面に移動し、移行対象のAurora ServerlessのDBを選択します。
1.2. 「スナップショットの取得」を選択
DBを選択状態のまま、「アクション」のメニューから「スナップショットの取得」をクリックします。
1.3. スナップショットの取得
スナップショット名を入力し、「スナップショットの取得」をクリックします。するとスナップショットの作成が始まります。
2. スナップショットからAuroraの立ち上げ
2.1. 作成したスナップショットを選択
スナップショット一覧の画面に移動し、先ほど作成したスナップショットを選択します。
2.2. 「スナップショットの復元」を選択
スナップショットを選択状態のまま、「アクション」のメニューから「スナップショットの復元」をクリックします。
※スナップショットの取得には時間がかかる場合があり、取得が完了するまでスナップショットの復元は実行できません。スナップショット一覧で進行状況を確認してください。
2.3. キャパシティタイプの設定
スナップショット復元の設定画面に遷移したら、「DBの仕様」のキャパシティタイプを「１つのライターと複数のリーダー」になるように選択します。
2.4. DBインスタンス名の入力
「設定」でDBの名前となる「DBインスタンス識別子」を入力します。
2.5. DBインスタンスサイズの選択
Auroraを作成した時のインスタンスのサイズを選択します。
MySQL互換かPostgreSQL互換かで選べるインスタンスタイプが少し異なります。サービスに適したインスタンスタイプを選ぶことが重要ですが、
Serverlessからの移行の場合はそこまで大きいインスタンスタイプは選ぶことはないと思うのでdb.t3.mediumやdb.r5.largeで十分だと思います。
詳しいインスタンスタイプの説明についてはこちらをご覧ください。
2.6. DBインスタンスの復元
上記の設定が終わったら画面の一番下にある「DBインスタンスの復元」をクリックします。
2.7. Auroraの作成
2.6.までの作業を完了すると、データベース一覧にAuroraのクラスターとインスタンスが現れ、作成が始まります。
作成が完了し、利用可能となるまでしばらく待ちましょう。
2.8 設定の確認とアプリケーションのDB接続情報の切り替え作業
インスタンスとクラスターの作成が完了したら、セキュリティグループなどの基本的な項目がちゃんと設定されているかを確認します。
確認後、利用可能となったら利用しているアプリケーションの接続情報の変更を行います。DBのマスターパスワードやマスターユーザー名は以前のものが引き継がれますが、 エンドポイント名が変わります。
データベース一覧から作成したAuroraのクラスターをクリックします。クラスターの画面に遷移すると「エンドポイント」に書き込みエンドポイントと読み込みエンドポイントが表示されています。
種類が「書き込み」となっている、書き込みエンドポイントの文字列を保存し、アプリケーションのDB接続情報をServerlessのエンドポイントからAuroraのエンドポイントに変更します。（アプリケーションが使用しているAWSサービスや構成によって変更箇所は違います）
2.9. Aurora serverlessの削除
DB接続情報を変更後、アプリケーションが正常に動いていることが確認できたらAurora Serverlessを削除します。
データベース一覧から削除するAurora Serverlessを選択し、アクションから「削除」をクリックします。
念のため最終スナップショットを作成し「DBクラスターの削除」をクリックすると削除が開始されます。
以上でAurora ServerlessからAuroraへの移行作業は終了です。
終わりに
今回はAurora・Aurora Serverlessの概要とAurora ServerlessからAuroraの移行方法について書きました。
株式会社アビストAIソリューション事業部では、このような技術者向けの記事を今後も公開する予定です。 Twitterアカウントもあるので、ぜひフォローしてください。
記事の内容に関するご指摘や、コメントもお待ちしております。
アビスト AIソリューション事業部 公式Twitterアカウント @abist_ai
