要約

  • RDSで一度増えたストレージ割り当ては、同じDBインスタンス上では減らせない。データ使用量が下がっても、確保した容量の課金はそのまま残る。
  • 対応するMySQL環境では、より小さいグリーン環境へ切り替えられる。ただし旧環境の復元履歴は移らず、移行中と保管中の費用も節約額に影響する。

接続先の名前は引き継げても、過去は引き継げない

データベースの移行には、見た目より深い継ぎ目がある。アプリケーションが使う接続先の名前が同じでも、その先にいる資源まで同じとは限らない。Amazon RDSのブルー／グリーンデプロイでは、この違いがストレージ削減後の費用にまで響く。

AWSの制約と考慮事項によると、新たな本番インスタンスには、旧本番インスタンスの特定時点への復元履歴が引き継がれない。新環境の履歴は、グリーン環境を作成した時点から始まる。旧ブルー環境は削除するまで自分の履歴と自動バックアップを保持する。

それ以前の業務状態へ戻せる期間が必要なら、旧環境を残す判断が生じる。AWSは、稼働させたまま保持するブルー環境にはコンピューティングとストレージの料金が続くと説明している。小さな新環境が無事に本番を引き受けた日と、支出が減り始める日が一致しない理由だ。

移行の完了報告には緑色の印を付けられる。それで古い請求対象まで消えるわけではない。

増やした容量は、空になっても同じ大きさ

そもそも、なぜ小さな環境を別に作るのか。RDSのストレージ自動スケーリングは、空き容量が足りなくなったときに割り当てを増やす仕組みだからだ。一度割り当てたストレージを同じDBインスタンス上で減らす機能はない。自動化を無効にしても、すでに行われた拡張は取り消されない。手動のインスタンス変更でも元の小さな容量へ戻せない。

一方、RDS for MySQLの料金は確保されたストレージ容量に基づく。月の途中で容量が変われば期間に応じて計算されるが、保存しているデータの量と確保した容量は別の値だ。整理によってファイルシステムの空きが増えた場合でも、割り当てが減らなければ、この容量に対する課金の基準は下がらない。

自動拡張は役に立っている。データベースが満杯になる危険を減らし、担当者が緊急に容量を足す負担を軽くする。問題は、一時的に必要になった大きさが、その後も必要かどうかを誰も判断しない場合だ。可用性を守るための決定が、次の予算の初期値として居座る。

空き容量が十分ある状態は、運用上は安心材料になる。経理から見れば、その安心のうちどこまでが必要な購入なのかという問いが残る。両者の答えをそろえる作業は、拡張の自動化には含まれていない。

小さな本番環境を先に用意する

AWSは、対応するエンジンならブルー／グリーンデプロイで小さいグリーン環境を作り、そこへ本番を移す方法を案内している。ほかには、小さい新規インスタンスを用意して手動でデータを移し、接続先を切り替える経路がある。どちらも同じ容器を縮める操作ではなく、別の容器への移動だ。

作成手順では、縮小先の容量を現在の使用量より少なくとも20％大きくする必要がある。計算例として、割り当て500GiB、使用率50％なら使用量は250GiBで、文書の算式による最低目標は300GiBとなる。実際の構成で選べる値かどうか、作成中の増加に余裕があるかは別途確認する。この計算に顧客の請求額や節約実績は含まれていない。

縮小に伴うストレージ構成の更新は入出力を多く使い、環境作成を長引かせることがある。したがって、容量の数字を小さく設定してから本番へ渡すまでには、複製と検証を終える工程がある。

ここでの対象は、ブルー／グリーンデプロイに対応するRDS for MySQLインスタンスだ。対応表はMariaDBやPostgreSQLについてもバージョン条件を示す。Db2、SQL Server、Oracleでは、この機能は使えない。同じRDSという看板の下でも、縮小経路はエンジンごとに確認する必要がある。

二つの環境を一つの節約額にまとめる

本番切り替えでは、複製の健全性や遅延などを確認し、新たな書き込みを止め、接続を切り、グリーン環境の同期を待つ。インスタンス名とエンドポイント名を引き継いだ後、新しい本番への接続と書き込みを許可する。グリーンのインスタンスを単独で手動昇格させる操作は、この切り替えとは違い、デプロイの複製関係を壊してしまう。

切り替え後も、旧環境の扱いは残る。デプロイ自体の削除はブルー環境に影響しない。管理上のまとまりを消すことと、料金の発生する資源を片付けることは別の作業だ。MySQLインスタンスを停止するだけでも、ストレージ料金は続く。

節約額を確定するには、実際の料金、二つの環境が重なる期間、必要な復元期間と移行作業費が要る。そこが分からなければ純額は出せない。それでも、削減策の評価はできる。新しい割り当て容量だけを見るのをやめ、旧環境の仕事がいつ終わるかまで数える。データを減らした成果を、購入する容量の削減へ変えるには、その最後の工程が必要になる。