2023年9月にAurora/RDSのMySQL/PostgreSQLのサポートを有償で延長するAmazon RDS延長サポートが発表されました。
Aurora/RDSのMySQL/PostgreSQLはコミュニティ版よりも少し長い独自のサポート期間が設定されています。
従来であれば、Aurora/RDSの定めるサポート期間を超えると、自動的にメジャーアップグレードされていました。 Amazon RDS延長サポートの導入に伴い、従来のサポート期間終了後も最大で3年間メジャーアップグレードが自動的に先延ばされ、セキュリティ修正とバグ修正が提供されます。
メジャーアップグレードは互換性や性能評価が不可欠です。
アップグレード検証の時間が取れない、アップグレードのサイクルを数年からその倍に伸ばしたい、あと数年でデータベース(サービス)を閉じる予定といった状況下に置いて、延長サポートは福音です。
一方で、延長サポートは追加費用が伴います。 利用者が何もアクションを取らなければ、通常サポートの終了とともに自動的に延長サポートモードになるため、利用費の増加で初めて延長サポートの存在に気づくケースもあるかもしれません。
本記事では、Amazon RDS延長サポートとの付き合い方について、述べます。
まとめ
- 自動で有効化されるAmazon RDS延長サポートにより、Aurora/RDS MySQL/PosotgreSQLのサポート期間が最大で３年伸びる
- Amazon RDS延長サポートは費用を伴う。１~２年目と３年目で別れ、３年目は１~2年目の倍かかる
- 延長期間突入後は、延長サポート対象バージョンへ自動的にマイナーアップグレードされる
- メジャーアップグレードする場合は、ダウンタイムの短いBlue/Greenか操作が簡単なインプレースを選択する
Amazon RDSサポート期間について
非常に大事な点として、Aurora/RDSのサービス、MySQL/PostgreSQLのデータベースエンジン、バージョンの差異によってサポート期間はまちまちであり、未定の期日もあるため、最新情報は以下のドキュメントを参照してください。
なお、Aurora/RDSに関係なく、延長サポートは「Amazon RDS Extended Support」とRDSが接頭します。 Auroraの文章や表でRDSが登場するのは少し気持ち悪いですが、気にしないようにしましょう。
PostgreSQL 11のサポート期間
次に、Aurora/RDS MySQL/PostgreSQL のサポート期間について、直近で標準サポートの終了を控えているMySQL 5.7とPostgreSQL 11を例に確認します。
まずはPostgreSQL 11です。
PostgreSQL 11はAuroraとRDSで同じライフサイクルをたどります。標準サポートの終了を2024年2月末に迎えたあと、延長サポートモードになります。 ただし、費用が発生するのは2024年4月以降です。
RDS Extended Support for PostgreSQL 11 starts on March 1, 2024, but will not be charged until April 1, 2024. Between March 1 and March 31, all PostgreSQL version 11 DB instances and clusters on RDS are covered under RDS Extended Support.
https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html
延長サポート費用は1-2年目(year 1 pricing)と3年目(year 3 pricing)の2種類の価格設定があり、3年目は1-2年目の約2倍です。
2027年3月末に延長サポートが切れたあとはメジャーアップグレードされます。
MySQL 5.7のサポート期間
次にMySQL 5.7です。
MySQL 5.7はAuroraとRDSでライフサイクルが大きく異なります。
RDSの場合、標準サポートの終了を2024年2月末に迎えたあと、無償期間を挟まずに即時に有償の延長サポートが始まります。 3年目の2026年3月からはyear 3 pricingとなり、1年後の2023年2月末に延長サポートが切れたあとはメジャーアップグレードされます。
Auroraの場合、標準サポートの終了はRDSの8ヶ月後の2024年10月末です。そこから1ヶ月の無償期間を経て、2024年12月からyear 1 pricingの延長サポートが始まります。 year 3 pricingの開始時期は現時点では未定で、延長サポートの終了はRDSと同じく2027年2月末です。
RDS延長サポートの費用
次のブログでは、実際に発生した費用とAWSコンソールでの見え方を例に、RDS 延長サポートのコスト面について詳細に述べています。
延長サポートの単価は最初の2年と3年目の2種類が存在し、3年目は1~2年目の約2倍です。 また、この費用はvCPUごとに発生します。
vCPUも考慮したインスタンスあたりのRDS延長サポート単価はオンデマンドのインスタンス単価程度かかるように設計されているように見受けられます。
東京・大阪リージョンは1~2年目が$0.12/vCPU-Hour、3年目が$0.24/vCPU-Hourです。
vCPUが4個あるdb.ｍ7g.xlargeの場合、1-2年目の1時間単価は$0.48であり、RDS PostgreSQLの東京リージョンのdb.m7g.xlargeのオンデマンド単価($0.468/Hour)とほぼ同じです。3年目はインスタンス:延長ライセンス=1:2になります。
オンデマンド単価はvCPU数に比例しているため、m7g系の他のインスタンスタイプでも同じ比率になります。
例外として、medium以下のサイズのインスタンスはvCPU数がlargeと同じ2に固定されています。そのため、medium以下のインスタンスサイズを利用している場合、オンデマンド単価に比べて何倍もの費用を支払うことになります。xlargeのvCPU数は4、largeのvCPU数は2、medium以下のvCPU数も2です。RDS PostgreSQLの東京リージョンの db.t3.micro(理論的vCPU数はlargeの1/8で0.25だけど2)のオンデマンド単価は $0.028/Hour のため、インスタンス:1年目の延長ライセンス= 0.028 : 2*0.12 = 1:8.5 という具合です。つまり、これまでの約9.5倍=10倍近いインスタンス費用が発生します。
medium以下の小さなスペックのインスタンスタイプの場合、インスタンス単価に比べてかなり割高な延長ライセンス費用をしはらう点にご注意ください。
マルチAZなRDSの場合、インスタンス利用費と同じく、延長サポート費もプライマリとセカンダリの2台分かかります。
Auroraも考え方はRDSと同じで、単価は以下のとおりです。
| Aurora | 1~2年目 | 3年目 |
|---|---|---|
| $/vCPU-Hour | 0.12 | 0.24 |
| $/ACU-Hour | 0.102 | 0.204 |
メジャーアップグレードを先延ばしした場合のTCOと移行コストを比較しましょう。
延長サポート移行時のマイナーバージョンアップグレード方法
延長サポートは、特定のマイナーバージョンでのみサポートされています。
RDSを例に取ると、MySQLは5.7.44、PostgreSQLは11.22です。
マイナーバージョンの自動アップグレードを有効にしている場合、すでにこの最新マイナーバージョンにアップグレードされているはずです。
無効にしている場合、標準サポートの終了に伴い、延長サポート対象バージョンへ自動アップグレードされます。 ただし、自動アップグレードの実施タイミングは言及されておらず、メンテナンスウィンドウ中に実施される保証はありません(2024/01/10確認)。
アップグレードのタイミングをコントロールしたい場合、標準サポートが終了する前に、以下のどちらかを実施してください。
- 手動で実行
- メンテナンス･ウィンドウを調整し、マイナーバージョン自動アップグレードを有効
メジャーアップグレード方法
AWSのマネージドの機能を利用してAurora/RDSをメジャーアップグレードしたい場合、主にインプレースとBlue/Greenの2方式があります。
手順を極限までシンプルにしたい場合は、インプレース方式がオススメです。
クラスターのバージョンを変更するだけで操作が完了します。 ただし、操作開始とともに一連のメジャーアップグレード処理を一気通貫で行うため、移行が長時間に及び、そもそものダウンタイムを読みづらいです。
ダウンタイムを抑えたい場合は、Blue/Greenデプロイ方式がオススメです。
異なるメジャーバージョン間でレプリケーションを張り、ダウンタイムはスイッチオーバーの一瞬だけです。エンドポイントの切り替えもフルマネージドで行われます。 Aurora・RDSの両方に対応し、切り戻しも簡単です。
Amazon RDS延長サポートはオプトインではなくなりました
RDS延長サポートが発表された2023年9月時点では、追加費用を伴う延長サポートの利用はユーザーに委ねる予定でした(オプトイン)。その後、利用者からのフィードバックを受け、自動メジャーアップグレードしてダウンタイムが発生し、互換性問題が顕在化することよりも、追加費用が発生してでも、サービスを安定して提供し続けることを優先する決断をしました。
16
