🆙

Amazon Aurora MySQLのバージョンを5.7系から8系にアップグレード

2024/11/26に公開

弊社サービスで運用しているAmazon Aurora MySQLを5.7系から8系にアップグレードしました。
その時に行った準備、アップグレード当日についての議事録になります。

実稼働しているDBクラスター2個のアップグレードを行いました。

  • 一つはインプレースアップグレード
  • もう一つはBlue/Greenデプロイ

を用いてアップグレードを行いました。

Aurora周りのサービス構成

Aurora周りのサービス構成

一般的な構成ですが、特徴としてはSnowflakeを使っており、データ連携にはDMSとKinesisを用いています。

準備

B/Gデプロイで行うか、インプレースアップグレードで行うかを決める

データ量の多い方のDBクラスター

実際にアップグレードするクラスターのクローンを作成してインプレースアップグレードを行ったところ、非常に時間がかかってしまったためB/Gデプロイによるアップグレードを検討しました。

ただ、B/Gデプロイの問題点として考えられるのはDMSで連携しているデータの整合性でした。
B/Gデプロイによってクラスターが変わるため、DMSで用いているbinlogファイルも新しく作成されてしまい整合性が保てずDMS再起動、snowflakeのフルロードが必要になる点は注意です。

DMS再起動もデータが多いと時間がとてもかかってしまうため、データ量の多いテーブルはDMSでの連携を停止し、firehoseで連携する手段を取りました。

データ量の少ない方のDBクラスター

クローンしてインプレースアップグレード行ったところ、そこまで時間がかからなかったためインプレースアップグレードで行いました。

メンテナンスありでDBへの書き込みを止めているのでDMSは再起動ではなく再開で済みました。

アップグレード事前チェック

当日の作業手順の確認

今回はB/Gデプロイでもインプレースアップグレードでもメンテナンスありで行いました。
深夜作業になるため、できる限り具体的な作業手順書を作成しました。
クローンを作成して、インプレースアップグレード、B/Gデプロイ両方試し手順を確認しました。

B/Gデプロイによるアップグレード本番

メンテナンス前にGreenを作成しておく。(10分くらい)
Greenを作成

メンテナンスの準備開始。(PM02:00~)
ALBでメンテナンス画面を出す、ECSのタスクを止めるなどなど。

Blue(今まで稼働していたもの)とGreen(新しく作成したもの)を切り替える。(PM02:10~)
エンドポイントなども今まで稼働していたものと同じものにしてくれます。
switch over

切り替え中はこのような画面になる。(切り替え自体は2,3分くらい)
b/gデプロイ作成中

ライターインスタンスだけパラメータグループが再同期必要になったため再起動を行った。

動作確認を行い問題ないかを確認する。(PM02:20~)

DMS再起動をする。(PM02:40~)
(間違えて「再開」をしてしまい翌日再起動することになったことは一旦置いておく)

意外と簡単!

インプレースアップグレードによるアップグレード本番

ボタンを押すだけなので省略します。

まとめ

大きな事前準備はDMSで連携していた一部のテーブルをFirehoseで連携するくらいでした。(チームメンバーの方がやってくれました。感謝)
アップグレードのためにアプリケーション上で修正することもなかったため、比較的大きな負担はなかったなと思います。

準備でやっておいてよかったなと思ったことは、

  • アップグレード対象のDBのクローンを作成してアップグレードしてみる
  • できる限り具体的な当日の手順書を作成する

でした。

クローンを作成してアップグレードをすれば、なんらかの原因でアップグレードできない場合検知でき、実際の手順やかかる時間もわかるのでとても安心です。

また、できる限り具体的な当日の手順書を作成しておけば、深夜どれだけ判断が鈍ってもその通りに行っていけばいいので安心です。(それでも間違えてDMSを「再開」してしまったことは置いておく)

sirok engineer's blog

Discussion