【爆速進化】Amazon MQがRabbitMQ 4系への「インプレース・アップグレード」に対応！データ移行不要の衝撃リリース

Amazon MQは、RabbitMQブローカーのメジャーバージョンアップグレードを「インプレース」で実行可能にしました。これにより、RabbitMQ 3.13から4.2へ、新規ブローカーの作成やデータの移行作業なしで直接アップグレードが可能です。ブローカーの設定、キュー、エクスチェンジ、バインディング、ユーザー、ポリシーなどの主要な設定・データはそのまま保持されます。ただし、アップグレードにはmq.m7g (Graviton3) インスタンスの使用が必須であり、クラシックミラーリングキューを使用している場合はクォーラムキューへの事前移行が必要です。

🛠️ エンジニアの苦悩、ついに解決へ

これまでRabbitMQのメジャーアップデートとなると、新しいブローカーを立てて、データを丁寧に移行して、テストして……という「重労働」が当たり前でした。今回のインプレース・アップグレード対応は、まさに運用工数の劇的な削減を意味します。

📍 日本国内での利用状況（検証済み）

最新のリージョン状況を確認したところ、東京リージョン (ap-northeast-1) および大阪リージョン (ap-northeast-3) の両方で利用可能です！日本の開発現場でも、すぐにでも検討できるアップデートといえます。

⚠️ 移行時の「落とし穴」と運用のポイント

非常に強力な機能ですが、いくつか注意すべき技術的制約があります。

1. インスタンスの要件: 今 mq.m5 などを使っているなら、先に mq.m7g (Graviton3) への変更が必要です。
2. 破壊的変更への対応: RabbitMQ 4.2では「クラシックミラーリングキュー」が廃止されます。アップグレード前に専用のキュー移行ツールを使って、クォーラムキューへ変換しておきましょう。
3. ダウンタイムの発生: アップグレード実行中はブローカーが一時的に利用不可となります。メンテナンスウィンドウでの実施が厳っても推奨されます。

🚀 次に何をすべきか？

まずはステージング環境のブローカーで、アップグレードの挙動を確認することをおすすめします。特にキューの深度（滞留メッセージ量）が多い場合、ダウンタイムが延びる可能性があるため、事前にメッセージを整理しておくのがスマートな運用です。

参考資料:

• Amazon MQ release notes
• Amazon MQ developer guide