しばたです。
本日よりAmazon RDSのうちRDS for PostgreSQL、RDS for MySQL、RDS for MariaDBにおいてトランザクションログを専用のボリューム(Dedicated Log Volume : DLV)に保存できる様になりました。
AWSからのアナウンスはこちらになります。
機能詳細
この機能は大量のトランザクションを要するRDS環境に対するものであり、トランザクションログの保存先を個別の専用ボリュームに分離することでパフォーマンスを確保するものになります。この様な方式自体は昔からよくあるメジャーな手法かと思いますが、2023年の今になって改めて登場するのは面白いですね。
専用ログボリュームを使うには以下の条件を満たす必要があります。
- 以下のバージョンを満たすRDS for PostgreSQL、RDS for MySQL、RDS for MariaDBであること
- PostgreSQL 13.1以降, 14.7以降, 15.2以降
- MySQL 8.0.28以降
- MariaDB 10.6.7以降
- ストレージタイプが「プロビジョンド IOPS SSD (io1)」であること
あくまでもRDS向けでAuroraは対象外です。
そして、この機能を有効にするとトランザクションログ用に「3000 IOPS, 1000 GiB」の専用ボリュームが割り当てられます。
現時点においてIOPSやサイズは固定で変更することはできません。
Multi-AZ環境では各AZに専用ボリュームが追加され、Read Replica環境においてはプライマリDBで機能を有効にした後に作成されたレプリカにだけ専用ボリュームが作成されます。機能の有効化前から存在するレプリカに対しては明示的な設定変更をする必要があるとのことです。(AWSとしては全てのレプリカに専用ボリュームを追加することを推奨しています)
この機能は既存のインスタンスに対しても適用可能ですが、設定変更後は再起動が必要になります。
推奨環境
AWSとしてはストレージサイズが5TiB以上の環境で使うことを推奨しています。
5TiBに満たない環境でも機能を有効にすることはできますが、1000GiBの専用ボリュームなのでデータ量が少ない環境ではコスト面で割に合わないでしょう。
料金
追加した専用ボリューム「3000 IOPS, 1000 GiB」分の料金が別途必要になります。
例えば東京リージョンのSingle-AZ環境でこの機能を使う場合、本日時点のio1の料金が
- 0.12 USD/IOPS-月 (2023年10月時点)
- 0.15 USD/GiB-月 (2023年10月時点)
なので
- 0.12 * 3000 + 0.15 * 1000 = 360 + 150 = 510 USD/月
の追加費用となります。
Mulit-AZ環境ならさらに倍です。
- 参考 : Database storage costs (RDS for PostgreSQL)
試してみた
今回は新規環境で機能を設定するところだけ試してみます。
(まともに性能評価できる大規模環境は持ってないので...)
私の検証用アカウントの東京リージョンにRDS for PostgreSQL 15.4の環境を新規作成していきます。
VPC等のリソースは予め作成済みです。
マネジメントコンソールからRDSインスタンスの新規作成を開始し、本日時点で最新の「PostgreSQL 15.4-R2」を選びます。
ストレージタイプを「プロビジョンド IOPS SSD (io1)」にすると「専用ログボリューム」欄が表示されるので、「専用ログボリュームを有効にする」にチェックを入れます。
その他の設定は従来通り変わり無いので環境に応じた内容にしてください。
最後の利用費概算には専用ログボリュームの費用は含まれていませんでした。
作成した結果はこんな感じで、設定欄に専用ログボリュームが有効である旨が追加されます。
ログファイルなどからボリュームに対する詳細を得ることはできず、pg_ls_waldir()やpg_settingsあたりを調べてみても面白そうな情報を見つけることはできませんでした。
CloudWatchメトリクスでは通常のFreeStorageSpaceとは別にFreeStorageSpaceLogVolumeメトリクスで専用ログボリュームの残サイズを確認できました。
他にも
- DiskQueueDepthLogVolume
- ReadIOPSLogVolume
- ReadLatencyLogVolume
- ReadThroughputLogVolume
- WriteIOPSLogVolume
- WriteLatencyLogVolume
- WriteThroughputLogVolume
といった性能周りのメトリクスも通常ボリュームとは別に分かれていました。
手動バックアップ(スナップショット)を取ってみた結果はこんな感じです。
専用ログボリュームは「オフにしました」とある様にスナップショットからは除外される様です。
トランザクションログなので当たり前といえば当たり前の挙動ですね。
無効にする場合
一度設定した内容を無効にするには「専用ログボリュームを有効にする」のチェックを外すだけです。
変更にはデータベースの再起動を伴いダウンタイムが発生します。
最後に
簡単ですが以上となります。
機能としては分かりやすいのですが、io1では最大256000 IOPSまで指定可能なのに対して専用ボリュームが3000 IOPS, 1000 GiB固定というのは少し心許ない印象を受けました。
「専用ボリュームではなくIOPSで殴る方が性能が出るのでは？」という疑問がちょっとあります...
が、IOPSではなくスループットを個別に確保しておきたいのであれば専用ボリュームの方が良さそうでもあります。
そんな感じで個人的には少し使いどころに悩んでいます。
大規模向けで費用もそれなりにかかる機能ですので導入に際しては入念に検証すると良いでしょう。
16
