はじめに
こんにちは、永川です。普段はインフラエンジニアとしてシステム開発・運用に携わっています。
今回は「Amazon RDS (以下 RDS) の MySQL マイナーバージョンアップ作業」に焦点を当て、ダウンタイム削減や運用負荷軽減を目的とした選択肢を検討した内容を共有します。
近年、RDS の MySQL のマイナーバージョンは利用可能になってから約1年でサポートが終了するようになったため、年次のバージョンアップが必要となっています。
1年に1回の作業ではありますが、対応負荷が高くチームのキャパシティを圧迫しているため、効率化の方法を模索しました。この記事では主に4つの選択肢をご紹介します。
チームにおけるMySQL マイナーバージョンアップの課題
私たちのチームでは、十数人のメンバーで十数のシステムを運用保守しています。
このような状況では運用効率の向上が非常に重要です。しかし、毎年必須となるバージョンアップ作業は負担が大きく、いくつかの課題がありました。
現状の構成・運用方法
構成
- 上記構成図のようなマルチAZ構成の RDS
バージョンアップ方法
- インプレースアップグレード(コンソールや CLI から直接バージョンを変更)
主な課題
1. ダウンタイムの発生
インプレースでバージョンアップする場合5~10分程度のダウンタイムが発生するため、サービスを一時停止する必要がある。
ダウンタイムが発生することにより、関係各所との調整や事前検証の工数がかかるため負担が大きい。
2. サポート期間が約1年と短い
- 1年周期でサポートが終了するため毎年のバージョンアップ対応が必須になっている。
同時期に複数のシステムの対応に追われるため、少人数で運用しているチームとしてはなかなか辛い作業です...
最適な選択肢を考える
前述した課題を踏まえ、ダウンタイムを削減する方法や頻度を軽減するための選択肢を検討しました。
以下の4つのアプローチを詳しく解説します。
マルチAZ DBクラスター移行
マルチAZ DBクラスター移行 ＋ RDS Proxy追加
ブルーグリーンデプロイ
Amazon Aurora 移行
① マルチAZ DBクラスター移行
マルチAZ DBクラスターは、2022年3月にRDSに追加された新しいデプロイオプションです。
通常のマルチAZ構成とは異なり、1つのライターDBインスタンスと2つのリーダーDBインスタンスが異なるアベイラビリティゾーン（AZ）に配置され、高い可用性と性能を提供します。
ダウンタイムが大幅に短縮されるため、MySQL のバージョンアップにも効果を発揮します。
メリット
ダウンタイムが35秒未満
MySQL マイナーバージョンアップに限らず通常のマルチAZ構成よりダウンタイムを短縮。DBの性能向上
読み取り専用のリーダーインスタンスにより、高負荷時の性能劣化を軽減。
デメリット
- コストが高い
3つのインスタンスが必要となるため、他方式と比較してAWS利用料が増加。
| 方法 | コスト ( インスタンスタイプ db.m5.xlarge、ストレージ 50GBの場合) |
|---|---|
| シングルAZ | 255.41 USD/月 |
| マルチAZ | 510.82 USD/月 |
| マルチAZ DBクラスター | 722.25 USD/月 |
- 移行の手間
現行のシングルインスタンスやマルチAZ構成から直接移行することはできず、スナップショットを介した移行が必要。
② マルチAZ DBクラスター移行 ＋ RDS Proxy追加
RDS Proxy は高可用性フルマネージド型データベースプロキシで、アプリケーションのスケーラビリティやデータベース障害に対する回復力と安全性を高める機能です。
先ほどのマルチAZ DBクラスター移行と組み合わせることで、RDS のマイナーバージョンアップにおいては 最短のダウンタイムを実現します。
メリット
ダウンタイムが1秒未満
今回の選択肢の中では最も少ないダウンタイムを実現。高いスケーラビリティ
RDS Proxy によりスケーラビリティや耐DB障害性が向上。
デメリット
コストがさらに高い
RDS Proxyの追加コストが発生。移行の手間がかかる
追加でRDS Proxy 用の設定が必要。
③ ブルー/グリーンデプロイ
ブルー/グリーンデプロイは、RDSで提供されている新しいデプロイ機能で、
グリーン環境とブルー環境の2つの環境を並行して運用し、問題がなければサービスを提供している環境を入れ替える方法です。
この方法により、アプリケーションへの影響を最小限に抑えつつ、データベースのアップデートを迅速かつ安全に行うことができます。
メリット
事前検証が可能
切り替え前に書き込み以外の操作や疎通確認などを検証することが可能。導入負荷が低い
RDS 標準機能のため、特別な環境構築が不要。また切り替え時に新しいブルー環境にエンドポイントが引き継がれるためアプリの修正が不要。
デメリット
- 整合性の問題
MySQLの非同期バイナリログレプリケーションを使用しているため、データの遅延や不整合が発生する可能性あり。（確実に整合性が保証されているわけではないため、システムによっては慎重に選択する必要がある。）
④ Amazon Aurora 移行
Amazon Aurora( 以下 Aurora ) は AWS から提供されている MySQL と PostgreSQL との互換性を持った高性能な DB サービスです。
長期サポート (LTS) リリースを利用することで、サポート期間を最大3年間に延長することができ、今回取り上げた選択肢の中ではマイナーバージョンアップの頻度を減らす唯一の選択肢になります。
また上記で紹介したブルー/グリーンデプロイも標準機能として使用することもできます。
メリット
バージョンアップ頻度が軽減
LTS リリースのバージョンを使用すれば、バージョンアップの頻度を3年に1回に軽減。DBの高性能化
標準の RDS より優れた性能と可用性を提供。
デメリット
- 移行の手間
RDS から移行する場合、 移行作業が必要。
4つの選択肢のまとめ
ダウンタイムについて
| 選択肢 | ダウンタイム | コスト (現状の構成比較) |
|---|---|---|
| インプレースアップグレード | 5 ~ 10分 | 変化なし |
| マルチAZ DBクラスター | 35秒未満 | 増加 |
| マルチAZ DBクラスター ＋ RDS Proxy | 1秒未満 | さらに増加 |
| ブルー/グリーンデプロイ | 1分以内 | 変化なし ※ブルー/グリーンデプロイ構成中は増加 |
| Aurora | 1分以内 ※ブルー/グリーンデプロイ使用時 |
微増 |
最もダウンタイムが短くなるのはマルチAZ DBクラスター移行 ＋ RDS Proxy追加の構成
1分以内のダウンタイムが許容できるのであれば、ブルー/グリーンデプロイが最も手軽にダウンタイムを削減可能
マルチAZ DBクラスターや RDS Proxyの追加 はダウンタイムを大きく短縮することができるが、コストがかさむ
頻度について
通常のRDSの場合、どの選択肢を取っても1年周期でサポート切れになることは変わらない
Aurora に移行し、長期サポート (LTS) リリースを使用することで3年に1回に減らすことができる
最後に
今回は、RDS MySQL のマイナーバージョンアップを効率化する4つの選択肢を紹介しました。
個人的にはブルー/グリーンデプロイが移行の手間がなく最も使い勝手が良いため、ぜひ取り入れたいと感じました。
これまでのインプレースアップグレードと比べてダウンタイムが削減できるだけでなく、事前に検証を行えるところが嬉しいポイントです。
ただ通常のRDSを使い続ける場合、1年に1回対応が必須なのは変わらないので、一番良いのはやはり Aurora 移行ですね...
また Aurora へ移行することになれば記事にしようと思います。
参考URL
