はじめに
この記事は Safie Engineers' Blog! Advent Calendar 2022 23日目の記事です。
セーフィー株式会社 開発本部のソフトウェアエンジニア 斎藤です。 Safie のクラウド録画サービス の安定運用に寄与するべく、インフラ周りの構築・運用を主に担当しています。
今回は Amazon Aurora MySQL をバージョンアップグレード (5.6 -> 5.7) したお話です。
前回、私が執筆したブログ記事は GitHub Actions で小さな不便を解消してみた でした。約2年振りですね。
アップグレードする必要性
Preparing for Amazon Aurora MySQL-Compatible Edition version 1 end of life
そもそも何故アップグレードするのかについては、上記記事の通りです。 Amazon Aurora MySQL バージョン 1(MySQL 5.6 互換) は、2023 年 2 月 28 日にサポートを終了する予定です。
そのため、Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換) または Amazon Aurora MySQL バージョン 3 (MySQL 8.0 互換) にアップグレードする必要があります。
アップグレード手順候補案
インプレースアップグレード方式
マネジメントコンソール もしくは (CLI/API) を使って簡単に 5.6 -> 5.7 へのアップグレードができます。 ただし、アップグレード中はクラスターエンドポイントに接続できないためダウンタイムが発生します。
※弊社環境での事前検証だと約1時間でした。環境によってダウンタイム時間は前後します。
また、 rollback (切り戻し) したい場合、気軽に出来ないところがデメリットになります。 前バージョンのスナップショットからクラスターを復元するなど、時間が掛かります。
レプリケーション && DNS 切り替え方式
Blue/Green デプロイ手法で最後にアプリケーションの向き先を変える方法です。
ざっくり説明すると以下のイメージです。
- 現在動いている Aurora を Blue 環境とし、Blue からクローン、Green 環境を作ります
- Green (Older) をインプレースアップグレードします
- Blue とインプレースアップグレードした Green (Newer) でレプリケーションします
- 最後にアプリケーションの向き先をインプレースアップグレードしたクラスターに変更します
この方法でもダウンタイムは少なからずどうしても発生します。 ただし、インプレースアップグレード方式よりもダウンタイムは短くできます。
検討する上での比較項目
| ↓比較項目 | インプレースアップグレード方式 | レプリケーション && DNS 切り替え方式 |
|---|---|---|
| 手順がシンプルかどうか | ✅ | ❌ |
| ダウンタイムの長さ | ❌ | ✅ |
| 切り戻しがしやすいか | ❌ | ✅ |
実際に採用した手順
レプリケーション && DNS 切り替え方式を採用しました。 採用した理由は以下のとおりです。
- ダウンタイムは極力短くしたい。
- 弊社サービスの性質上 、カメラの録画欠損はなるべくさせたくない。
こちらの理由が一番強い決め手となりました。 ※手順が少し複雑になる所は許容範囲としました。
実際の作業イメージ
前提条件
レプリケーションには AWS DMS Database Migration Service を利用します。
現在動いている Aurora MySQL の方で、 バイナリログ出力有効 (binlog_format=ROW 形式) になっていることが必須です。
- https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.AmazonManaged
Set the binlog_format parameter to "ROW".
step1 から step3 までは事前準備です。 (既存サービスには影響ありません)
- 最後の step4 だけダウンタイムを伴う、停止メンテナンスが必要です。
step1
Clone して Clone 先クラスターをインプレースアップグレードします。
step2
AWS DMS (Database Migration Service) でレプリケーションします。
step3
rollback (切り戻し) 用の 5.6クラスターを追加します。
基本的には rollback は必要無いはずですが、念には念を入れて準備しました。
DMS を中継することで、5.7 -> 5.6 への (ダウングレード) レプリケーションも可能になります。 ※ AWS サポートに質問し、可能と回答頂きました。担当サポートの方、誠にありがとうございました。
step4
step3 までの事前準備が完了したら、いよいよダウンタイムを伴う停止メンテナンスを実施します。
- (停止メンテナンス) DNS 切り替え
- CNAME 変更 (aurora56 -> 57)
step4 の詳細手順
DNS 切り替えの手順イメージは、以下のとおりです。
API などのリクエストを 503 Service Unavailable 固定レスポンスにし、メンテナンス中にします。
古いクラスター (5.6) への書き込みを止めます。 (db-cluster-parameter-group 変更で read_only にします)
新しいクラスター (5.7) へのレプリケーション遅延が無いことを確認します。
DMS の CloudWatch メトリクスで確認できます。
- CDCLatencySource
- CDCLatencyTarget
- これらの値が 0 になると、レイテンシー (レプリカラグ)が無いと判断出来ます。
DMS のレプリケーションを停止します。
Route53 ルーティング先変更します。 (5.6 -> 5.7)
API などの 503 Service Unavailable 固定レスポンスを解除します。
古いクラスター (5.6) を reboot します。(各アプリケーションの接続を強制的に切断する意味合いです)
以上でメンテナンス完了です。
万が一の rollback 手順
今回は rollback (切り戻し) しませんでしたが、基本的には step4 と似たような手順で実施可能です。
- 現行クラスター (5.7) への書き込みを止めます。 (read_only にします)
- rollback クラスター (5.6) へのレプリケーション遅延が無いことを確認します。
- DMS のレプリケーションを停止します。
- Route53 ルーティング先変更します。 (5.7 -> 5.6-for-rollback)
- 現行クラスター (5.7) を reboot します。
おわりに
以上、Amazon Aurora MySQL をバージョンアップグレード (5.6 -> 5.7) したお話でした。
余談ですが、2022年11月27日に Blue/Green デプロイ手法でダウンタイムを最小限に抑えつつデータベースを更新する方法が一般公開されました。 New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS
次回、データベースのアップグレードをする際には、こちらの Blue/Green デプロイメントを試してみたいと思っています。
セーフィーでは、夢を語りまきこみやりきる 方を歓迎します。 ご興味のある方のご連絡をお待ちしてます。
