NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ
    トップ > クラウド > Aurora Global DatabaseのバージョンUpdateで詰まった点

    Aurora Global DatabaseのバージョンUpdateで詰まった点

    クラウド AWS Aurora

    こんにちは、NRIネットコム入社1年目の中川です。
    8月にインフラチームに配属されもうすぐ5か月、まだまだ分からないことだらけで日々修行中です！

    今回のテーマ

    今回のテーマについてですが、下記にある通り、2024年1月15日でAurora MySQLのversion3.01並びに3.02 (MySQL 8.0.23 互換)がサポート対象外となり廃止されます。

    docs.aws.amazon.com

    それに伴い、Aurora MySQLのマイナーバージョンUpdate検証をやってみたところ、公式ドキュメントを見ただけでは分からない落とし穴がいくつもあったため、それらをご紹介できればと思います。

    今回の本題となる構成

    今回検証を行ったDBの構成は上図の通りです。
    Global Databaseを利用し、東京リージョンに構築されたプライマリクラスターからオレゴンリージョンに構築されたヘッドレスのセカンダリクラスターにリアルタイムでデータを同期するようなAWS構成です。
    私が初めてこの構成を見たときの心情は「 グローバルデータベース…？ヘッドレス…？オウチカエリタイ( - " - ) 」でした。
    私と同じ状況に陥った方のために、次はAuroraのGlobal Database、ヘッドレスクラスターについて説明したいと思います。

    Aurora Global Databaseとは？

    Global Databaseは、複数のリージョンにまたがってAuroraクラスターを構成できる機能です。
    Global Databaseを利用することで、データベースが高負荷になってもリージョン間のレプリケーションのラグは1秒未満、さらにリージョン障害が起こったとしても1分未満でリカバリーができるとドキュメントにあります。このため、災害対策の目的で利用されることが多いです。また、グローバルに展開するサービスではユーザに近いリージョンで処理を行うことでプライマリリージョンと通信するより低レイテンシーでデータベース操作が行えるという利点もあります。
    より詳しい内容については下記の公式ドキュメントをご覧ください。

    docs.aws.amazon.com

    ヘッドレスクラスターとは？

    Auroraは「クラスター」という単位で構成されています。クラスターはDBサーバーからなるDBインスタンスと、データを管理するクラスタボリュームから成り立っています。つまり、SQLなどの処理を行うインスタンスとデータを保存するストレージが分離しているのです。
    ヘッドレスクラスターはインスタンスのないクラスターのことです。
    インスタンスがないため接続等はできませんが、ストレージはあるのでコンピューティングに対する費用を削減しつつ、データを保持できます。
    AuroraのグローバルDBの構築方法やヘッドレスクラスターについては下記の公式ドキュメントが参考になります。

    docs.aws.amazon.com

    当初想定していたUpdate手順

    Aurora Global DatabaseではプライマリとセカンダリのDBクラスターを同じバージョンにアップグレードすることが推奨されています。プライマリとセカンダリのDBクラスターが同じエンジンバージョンの時しか自動的なフェイルオーバー(セカンダリリージョンをプライマリへ昇格してくれる)機能が働かないためです。

    参考文献：
    Amazon Aurora Global Database のアップグレード - Amazon Aurora

    そのため、Updateの手順としては以下の2パターンを考えていました。
    パターン① Global DatabaseにセカンダリクラスターをアタッチしたままコンソールからUpdate
    ドキュメントを読む限り今回のUpdateではデタッチが必要そうだったのですが、一応期待も込めてセカンダリクラスターを直接アップデートできないかやってみました。
    パターン② Global DatabaseからセカンダリクラスターをデタッチしてコンソールからUpdate
    想定していた具体的な手順は次の通りです。

    手順 作業内容
    １ Global Databaseからセカンダリクラスターをデタッチ
    ２ セカンダリクラスターのマイナーバージョンをコンソールからUpdate
    ３ プライマリクラスターのマイナーバージョンをコンソールからUpdate
    ４ セカンダリクラスターをGlobal Databaseへ再アタッチ

    この時はわりとスムーズにいくのでは・・・♪と予想していました。が、実際は躓きに躓きまくりました。

    実際に検証して分かったこと

    ① エンジンバージョンによってはGlobal Databaseにセカンダリクラスターをアタッチしたままバージョンアップはできない
    これは何となくそんな気がしていたのですが、やっぱりできませんでした。Aurora MySQLのバージョンを3.03以上、またはバージョン2.12へバージョンアップするには、Global Databaseからセカンダリクラスターを削除する必要があるそうです。
    参考文献：
    Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード - Amazon Aurora

    ② いきなりGlobal Databaseからセカンダリクラスターを削除することはできない
    Global Databaseにアタッチされた状態のセカンダリクラスターは削除はできず、一度デタッチする必要がありました。

    ③ ヘッドレスのセカンダリクラスターのバージョンアップはできない
    バージョンアップは少なくとも1つのDBインスタンスがないとできないようです。
    参考文献：
    Amazon Aurora Global Database のアップグレード - Amazon Aurora

    ④ヘッドレスクラスターへのインスタンス追加はコンソールではできない
    マネジメントコンソールではセカンダリクラスター作成時にインスタンスも同時に作成する必要があり、既存のヘッドレスクラスターに対してインスタンスを後から追加することはコンソールでは対応していませんでした。
    そのため、CLIから以下のようなコマンドを打って作成することになります。参考にした公式ドキュメントも下に載せていますので、適宜必要なパラメータを追加してもらえればと思います。

    REGION=<セカンダリクラスターのリージョンを入力>
INSTANCE_CLASS=<インスタンスタイプを入力>
CLUSTER_IDENTIFIER=<セカンダリクラスター名を入力>
INSTANCE_IDENTIFIER=<インスタンス名を入力>
ENGINE=<使用するDBエンジン名を入力>
AVAILABILITY_ZONE=<インスタンスを立てるAZを入力>
PARAMETER_GROUP=<DBのパラメータグループ名を入力>

aws rds --region $REGION \
  create-db-instance \
  --db-instance-class $INSTANCE_CLASS \
  --db-cluster-identifier $CLUSTER_IDENTIFIER \
  --db-instance-identifier $INSTANCE_IDENTIFIER \
  --engine $ENGINE \
  --availability-zone $AVAILABILITY_ZONE \
  --db-parameter-group-name $PARAMETER_GROUP \
  --no-publicly-accessible \
  --no-auto-minor-version-upgrade

    参考文献：
    Amazon Aurora Global Database の開始方法 - Amazon Aurora

    ⑤Global Databaseへのセカンダリクラスター再アタッチはできない
    ここまでやってきて今さら…と思うかもしれませんが、私も同じ気持ちです(´･_･`)
    Global Databaseから一度デタッチしたクラスターの再アタッチはできませんでした。そのためGlobal Databaseに新規でクラスターを再作成するしかありません。

    今回実施したUpdate手順

    試行錯誤を経て今回実施したUpdate手順がこちらです。

    手順 作業内容
    １ Global Databaseからセカンダリクラスターをデタッチ
    ２ セカンダリクラスターを削除
    ３ プライマリクラスターのマイナーバージョンをコンソールからUpdate
    ４ ヘッドレスのセカンダリクラスターを再構築

    セカンダリクラスターを再作成するにあたり、データの同期が再度行われるため、想定より時間がかかることも分かりました。

    さいごに

    最初に検証を行ったときは事前に用意していた手順書が全く通用せず、全然うまくいかない…と焦りましたが、試行錯誤してなんとかUpdateを完了させることができました。 この検証を通して、ドキュメントとにらめっこするだけでなく、実際に手を動かしてみないと分からないことがたくさんあるということを学びました。
    拙い文章ではありますが、参考になれば幸いです！

    執筆者：中川舞雪 新米インフラエンジニア