Aurora Serverless V2 への移行について

オンデマンドにオートスケールするAurora Serverless v2がGAしたことに伴い、弊社でも、各プロジェクトへの導入が勧められています。

その導入過程や、手順について書いていきたいと思います。

今回紹介するのはAurora MySQL バージョン 3からAurora Serverless v2へのインプレースでのアップグレードの方法です。

現状は、Aurora MySQL バージョン 3　しかServerlessに対応していないので、インスタンスをAurora MySQL バージョン 3にしないと使えません。

Aurora MySQL バージョン 2以下のインスタンスは、一旦、Aurora MySQL バージョン 3にインプレースアップグレードしてから、移行する必要がある点にご注意ください。

ちなみに、Aurora MySQL バージョン 2からAurora MySQL バージョン 3への移行がインプレースアップグレードでできるようになったのは最近です。
https://aws.amazon.com/jp/about-aws/whats-new/2022/09/amazon-aurora-supports-in-place-upgrades-mysql-5-7-8-0/

これまではスナップショットを復元する方法しかありませんでしたので割と大変でした。
https://qiita.com/Dai_Kentaro/items/f0821de653e0f706b64e

Aurora Sereverlessとは

• インスタンスのCPU、メモリ、ネットワークなどのリソースの使用率を追跡していずれのかの容量が逼迫すると自動的にスケーリングしてくれる
• 新規事業等でどれくらいのユーザーがつくかわからない時に、事前に大きめのインスタンスを用意して過剰なプロビジョニングを行う必要がなく、動的なスケーリングを行える

※注意
AWSから公式回答としては、アクセスがほとんどなくても、「Aurora Serverless v2 の CPUUtilizaton 及び ACUUtilization は完全にゼロ」になることはないそうです。アクセスがほとんどなくても、管理機構は動いているので、メトリクスのServerless Database Capacity が 0.5 で ACUUtilization が 3 程度で推移する事象は、正常な動作の範囲とのことでした。なので、自動スケーリングについては、最低ライン以上下回ることはないようです。

料金

移行の手順

• 流れ
  • リーダーをサーバレス化→→→リーダーのサーバレス化完了→→→手動フェイルオーバー（ここで一瞬だけダウンタイム）→→→元ライター（現リーダー）のサーバレス化→→→元ライター（現リーダー）のサーバレス化完了

リーダーをサーバレス化（10min程度）

• サーバレスに設定
• 容量の範囲

  • 各 ACU が約 2 GiB のメモリに対応する

• 変更の適用
  • すぐに適用

リーダーをサーバレス化に更新した後

• リーダーをサーバレスに変更した瞬間一旦全部のインスタンスが変更中になる

  • 

  • 

  • ライターインスタンスへの接続は落ちない

    • 

  • リーダーのサーバレス化が完了するとこうなる

  • 

フェイルオーバー（10min程度、ダウンタイムが10s程度）

• フェイルオーバー
  • serverless化したリーダーをライターに昇格させる

• 数秒だけライターが落ちた（リーダーがライターに昇格する切り替えのタイミングでちょうど落ちた模様）

  • 

• フェイルオーバーしてserverless化したリーダーがライターに昇格

  • 

元ライター（現リーダー）のサーバレス化（10min程度）

• クラスター内のインスタンスをサーバレス化してあるとクラスターの設定として反映され、同じACUしか選択しかできない模様

• 

• 優先順位はTier0にする

  • Tier0 および Tier1 のリーダーインスタンスはライターインスタンスと共に自動スケーリングされていくので、ACUがライターに合わせて増加する

• 変更の適用

  • すぐに適用
  • ライターをサーバレスに変更した瞬間一旦全部のインスタンスが変更中になるのは先ほどの作業時と同じ

• 元ライター（現リーダー）のサーバレス化完了

  • 

メトリクスの確認/ACU値の調整について

Aurora Serverless v2 でのパフォーマンスとスケーリング

ACUUtilization。これは Aurora Serverless v2 での新しいメトリクスです。この値は割合 (%) で表されます。
これは、ServerlessDatabaseCapacity メトリクスの値を DB クラスターの最大 ACU 値で割った値です。このメトリクスを解釈してアクションを実行するには、以下のガイドラインを考慮してください。
このメトリクスが 100.0 値に近づいた場合、DB インスタンスは限りなく大きくスケールアップしたことになります。クラスターの最大 ACU 設定を引き上げることを検討してください。これにより、ライターとリーダーの両方の DB インスタンスを、より大きな容量にスケーリングできます。

• Serverless のデータベース容量 (カウント)
  実際に使っているACUのカウントがどれくらいか
  

• ACU Utilization(パーセント)
  ACUの使用率について使用率が上がってきて100%に近づくと、ACUのマックスの設定値でも足りなくなってきている状態なので、自動スケールの幅を上げるためにマックス値を上げることを検討する必要がある

• 最大値を上げた場合は、実際にアクセスが集中するような一時的なタイミングだけスペックが上昇するような形になるので、恒常的な予算の上昇はなさそう
• 逆に、最小値を上げると、常時、その最小値で　スペックを配備することになるので、時間単位が大きくなるので予算の上昇への影響がある
• リーダーの優先順位をTier0 および Tier1の設定にしていると、リーダーインスタンスもライターインスタンスのスケールと同調した動きになる

基本的なACU設定値の調整方針

• ACU Utilization(パーセント)をみて逼迫してそうならACUの最大値を上げる
• Serverless のデータベース容量 (カウント)が常時、最小値を超えているようなら、ACUの最小値を上げてみる