エクストーンの豊田です。先日AWSのAurora 1.x系バージョンが2/28に終了するために、エクストーンが運用しているいくつかのサービスでバージョンアップを行う必要がありました。 理想はダウンタイムなしでのバージョンアップができればいいのですが、構成によってはダウンタイムが発生してしまうため、運用しているサービスやAuroraの形態によってそれぞれ異なる対応を行いました。
メンテナンスによる対応
あるサービスではサイトでメンテナンスを行い、ユーザーからのリクエストをシャットダウンしたうえでバージョンアップを行いました。これが許されるなら一番トラブルが少なく確実なバージョンアップ方法かと思います。 このサービスでは適用していなかったのですが、ユーザーに対して影響を最小限に抑えるために日常的にメンテナンスウィンドウを設定する方法があります。ユーザーのアクセスが最も少なくなる時間帯に定期的に短時間のメンテナンスを行う方法です。メンテナンス内容があろうとなかろうと実施するようにします（頻度としては週一が現実的）。
AWSのAuroraやRDSではメンテナンスウィンドウが設定でき、DBのマイナーバージョンアップ等は基本的にこのメンテナンスウィンドウで実施することができます。
メンテナンスウィンドウの時間設定はUTCなので、日本時間で設定したい場合は+9時間する必要があります。上記の画像の例だと月曜日午前5時～5時半をメンテナンスウィンドウとして設定しています。
Auroraのアップグレードに関してはクラスターの再起動が発生するため、DBのダウンタイムが発生します。数十秒から数分程度の長さですが、再起動処理中にバイナリログデータの処理を行うため、バイナリログの量が多いとその分復旧時間が長くなります。ダウンタイムを許容するかどうかの判断を行う際に、DBに対する書き込みリクエストが多いサービスかどうかを確認しておくといいかと思います。 例えばデータの少ない検証環境でほとんど実感できるダウンタイムがなかったからと言って、本番で実施すると検証環境より長くダウンタイムが発生する可能性があるので注意が必要です。
Blue/Greenデプロイメントによる対応
別のサービスではAuroraのBlue/Greenデプロイメントを利用して実施することでダウンタイムを発生させないようにしました。Aurora Serverless v1でBlue-Greenデプロイメントを利用することができないため、こちらを利用している場合はダウンタイムの発生を避けることが難しいです。こちらのケースではサービスのメンテナンスを行うことを検討してください。
また、Blue/Greenデプロイメントを設定するためにはバイナリログが有効になっている必要があるため、事前にパラメータグループでクラスターの binlog_format の値を設定する必要があります。
こちらの設定も有効にする際にクラスターの再起動が発生するので、サービス当初から有効にしておくことをお勧めします。変更の際にクラスター内のインスタンスの再起動も必要になりますので忘れないようにしてください。
Blue/Greenデプロイメント用のクラスターを作成すると、以下のようにBlueとGreenの2系統のデータベースクラスタが作成されていることを確認できます。最初に設定した際はGreen系統のDBへはアクセスが流れてこないため、Green系統のバージョンアップやインスタンスタイプの変更等を気軽に行うことができます。切り替え時は ブルー/グリーンデプロイ ロールのリソースを選択し、アクションから 切り替え を選択することで無停止でGreen系統のクラスタを本番投入できます。
切り替えの際にDB識別子が変更になるため、識別子の名前に依存した設計を行っていると予期せぬ不具合が発生することがあるのでその点だけ気を付けましょう。IAM等で細かく接続権限をコントロールしている場合に影響があるかもしれません。 また、Blue系統とGreen系統のデータの同期はバイナリログによるレプリケーションの仕組みを利用して行っているため、レプリケーションに影響のないスキーマ変更等の適用を行うこともできます。
Blue/Greenデプロイメントを利用した際、読み込みに関してはダウンタイムなしで実現できるのですが、書き込みに関しては双方の環境に対するブロックが行われデータの整合性を維持するため、レスポンスの遅延が発生する可能性はあります。基本的にはアクセスの少ない時間帯に切り替え作業を行うことをお勧めします。
また運用コストとして2系統のDBクラスターが常に実行されるため、インスタンスの維持にかかる費用は単純に2倍になります。DBクラスターの更新を頻繁に行わない場合はバイナリログ等の設定など必須の要件だけ満たすようにしつつ、Blue/Greenデプロイメントの作成をDB更新時に都度行い、更新完了後に削除するという方法もあるので、こちらも検討してみるといいかと思います。
おわりに
AWSにおけるDBのバージョンアップはサービスの特性（書き込みが多いかどうか等）と現在動いている設定（バイナリログが有効かどうか等）によって、Blue/Greenデプロイメントで無停止で実施するか、サービスのメンテナンスを行うかを事前に検討する必要があります。
例えばバイナリログが無効の場合、Blue/Greenデプロイメント環境をそのクラスターから作成することができないためSer、その設定更新のためにDBのダウンタイムが発生します。日常的に運用しているサービスの構成がどうなっているかを把握していないと、いざバージョンアップ直前になって困ることになります。
また、書き込みが多いサービスについては、どうしても書き込みリクエストのブロックが発生してしまうということもあり、安易なBlue/Greenデプロイメントの切り替え実施はお勧めしません。サービスの規模やアクセス数に応じて、適切な時間帯を選ぶなりメンテナンスを行うなりの判断をちゃんと行うようにすることをお勧めします。
