ライターを直接変更すると、その間ずっと書き込みが止まる
Aurora PostgreSQLのスケールアップで、コンソールからライターを選んでインスタンスクラスを変更する手順は、作業ステップ数だけ見ればいちばん短く済みます。ただしこの操作では、ライターの再起動が終わってavailableに戻るまでコミットできません。
計画的なインスタンスクラス変更は障害検知の対象ではないため、Auroraは自動フェイルオーバーしません。代替の書き込み窓口は用意されず、変更の所要時間がそのまま書き込み停止時間になります。変更が終わると、同じインスタンスがライターとして戻ってきます。
Cluster Cache Management（CCM）を有効にしたクラスターには、もう一つ前提があります。CCMはライターとPromotion Tier 0のリーダーが同じインスタンスクラスであることを前提にした機能です。バッファキャッシュの容量はインスタンスのメモリ量に依存するので、Tier 0リーダーのクラスが小さいとライターのワーキングセットを同じだけ保持できません。ライターとTier 0リーダーのどちらか一方だけを変更した状態で作業を終えられない、という制約になります。
Tier 0リーダーを先に変更し、手動フェイルオーバーで寄せる
ライター1台とTier 0リーダー1台を含む構成なら、次の3段階で進めます。書き込みが止まる区間をフェイルオーバーの1回だけに限定できます。
最初にTier 0リーダーのインスタンスクラスを変更します。停止するのは当該リーダーだけで、ライターは動き続けます。リーダーの変更をきっかけにフェイルオーバーが起きることもありません。
aws rds modify-db-instance \
--db-instance-identifier <CCM対象リーダー> \
--db-instance-class <新しいインスタンスクラス> \
--apply-immediately
リーダーが新しいクラスでavailableに戻ったら、そのリーダーをターゲットに指定して手動フェイルオーバーします。昇格先は既に新クラスで、CCMによってバッファキャッシュもウォームな状態です。書き込みの中断と、その後の性能の落ち込みをどちらも短く抑えられます。
aws rds failover-db-cluster \
--db-cluster-identifier <クラスター識別子> \
--target-db-instance-identifier <CCM対象リーダー>
--target-db-instance-identifierは必ず明示してください。省略するとクラスター側がPromotion Tierの設定にもとづいて昇格先を選ぶため、ウォームにしていたリーダー以外が新ライターになる可能性があります。
最後に、リーダーへ降格した旧ライターを同じ新クラスへ変更します。書き込みは新ライターが受けているので、ここでも停止しません。作業後はライターとTier 0リーダーのクラスが一致していること、Tier 0が重複していないことを確認して締めます。
作業前に見る3点
手を動かす前に、クラスターのメンバー構成とPromotion Tierを確認します。
aws rds describe-db-clusters \
--db-cluster-identifier <クラスター識別子> \
--query 'DBClusters[0].DBClusterMembers[].{Instance:DBInstanceIdentifier,Writer:IsClusterWriter,Tier:PromotionTier}' \
--output table
IsClusterWriterがtrueのものが現ライター、PromotionTierが0のリーダーがCCM対象候補です。Tier 0が複数いる構成や、Tier 0のリーダーが存在しない構成になっていないかもここで見ます。
残りの2点は、apg_ccm_enabledの値と、各インスタンスの現在のクラス・ステータス・AZです。パラメータグループを変更済みでも、インスタンスへの反映がpending-rebootで止まっていることがあります。グループ側の値とインスタンス上で効いている値（SHOW apg_ccm_enabled;）を両方確認してください。AZを記録しておく理由は、手動フェイルオーバーでライターのAZが入れ替わるためです。available以外のインスタンスが残っている状態では作業を始めません。
「ダウンタイムは数秒」と手順書に書けない理由
フェイルオーバーの所要時間は、接続数やコネクションプールの構成、実行中の長時間トランザクション、クライアント側のDNSキャッシュのTTL、アプリのリトライ設計に左右されます。後ろの2つはインフラ側の手順では縮まりません。Aurora側の切り替えが完了していても、アプリが古い接続を掴み続ければ、ユーザーから見た断時間は長くなります。
見積もりを手順書に書くなら、検証環境で実測した値を根拠にしてください。クラスターエンドポイントへ一定間隔で書き込みを続け、投入レコードの時刻差から最大ギャップを求める方法で測れます。
詳しくは
元記事では、手順を逆にした場合に書き込みが二度止まる理由、スケールダウン固有の注意点、計測用テーブルと投入ループを使った中断時間の実測手順を具体的に書いています。あわせてpg_stat_databaseのヒット率やPerformance Insightsの待機イベントでCCMの効果を確認する方法、ライターとTier 0のクラス一致を定期チェックするスクリプトの考え方、Aurora Serverless v2を検討する判断材料も扱っています。
Aurora インスタンスクラス変更のダウンタイム最小化手順
Auroraの仕様や制限値は変更されることがあります。作業計画を確定する前に、CCM、インスタンスクラス変更、フェイルオーバーに関するAWSの公式ドキュメントで最新の仕様を確認してください。