はじめに

Google Cloud のデータベースのマネージドサービスである、Cloud SQL から新たに Enterprise と Enterprise Plus というエディションがGAされました。
Enterprise Plus では従来の Cloud SQL からパフォーマンスが最大3倍ということで、注目される内容について見ていきます。

概要

GA された Enterprise と Enterprise Plus ではどのような違いがあるのか、公式のブログの内容を元にざっくり記載し、後半になるにつれて、深掘りし、実際の設定時の注意事項も記載します。

Enterprise

実は従来の Cloud SQL がこのエディションとなり、2023/7/12 より前の時点で作成されたものはすべてこのエディションとなります。
そのため、こちらについては、価格、機能含めて特に新たに変更になるものはございません。
こちらのエディション概要内の「注：」箇所にもその旨記載されております。

Enterprise Plus

こちらのブログの案内に記載がありますが、現在の Cloud SQL と比較し以下が強化されています。

パフォーマンス向上
計画的メンテナンスのダウンタイムが60秒未満→10秒未満に大幅低減し、99.99%のSLA(ドキュメントも更新されてました)
ポイントタイムリカバリのログ保持が7日間→35日間となりデータ保護の強化

上記以外も含めた比較表はドキュメント内に記載があります。

それぞれの強化ポイントについて少し深掘りします。

パフォーマンス向上

性能の向上のポイントとしては以下3点記載されています。

ソフトウェアの最適化
マシンの種類と構成の改善
データキャッシュ( ※ MySQL のみ)

パフォーマンスの向上については、MySQL の方はデータキャッシュの機能もあり、より性能の向上見込めると考えられます。
ブログの書き方をみてても、MySQLの性能向上を強く押し出しているように見受けられます。

計画的メンテナンスのダウンタイムが60秒未満→10秒未満に大幅低減

ダウンタイム低減のポイントとしては以下の記載があります。

計画されたメンテナンスの間、Enterprise Plus インスタンスは裏でのローリングアップデートと追加のハードウェアリソースを使用し、ダウンタイムを 10 秒未満に短縮します。

利用者側視点で意識する箇所ではありませんが、設備側の考慮により改善が見られたことがわかります。
なお、これを実現するために、利用者側でも考慮する事項がありましたので、そちらについては後述します。
また SLA についても向上していました、99.95 → 99.99 %となり、これは大きいです！

ポイントタイムリカバリのログ保持が7日間→35日間となりデータ保護の強化

お客様要件によっては、復旧要件が厳しい場合があり、Cloud SQL では満たせないケースもあったかと思いますが、こちら強化により、利用ケースが広がるのではないか、と考えています。
こちらについては、設備側の記載や、どうやって実現するか、のような記載は見受けられませんでしたので、コメントのみとします。

利用者視点での注意事項

確認できた範囲での注意事項記載していきます。

料金面

日本語ページでは記載がありませんが、英語ページでは記載がありました。
ご覧いただくとわかりますが、全体的(データキャッシュを除く)に従来の Cloud SQL の1.3倍の料金になっています。
また、MySQL のみに追加される機能のデータキャッシュについては、 0.0003 per GB と記載があり、HAの場合は金額が倍額の 0.0006 per GB となります。

SLA

SLAの記載はHA構成時のものとなるため、シングル構成では 99.99 % となりませんので、注意ください。
ドキュメントにも記載があります。

対象バージョン

こちらのドキュメント上には MySQL 8.0、PostgreSQL 14、15、しか記載がございません。
MySQLについては、8.0.31から対象エディションに対応しておりますので、変更前に事前にマイナーバージョンアップが必要となります。
なお、Postgres マイナーバージョンが複数ありませんので意識する必要はありません。

既存のエディションからの変更

こちらに記載がありますが、既存のデータベースのエディションを変更するにはDMSを使って移行する必要があるように見受けられます。

設定方法

公式のブログに記載がありますが、CLI及びAPIで先行して利用可能となっているとのことです。
2023/7/17までにはコンソール対応するようですので、コンソールで行いたい場合、もう少し待つ必要があるかもしれません。

ダウンタイム低減に向けた設定

ダウンタイム低減の恩恵を受けるためにはMySQLはこちら、Postgresはこちらの設定が必要且つ、制約がありますので、事前に確認ください。

共通して言われているプライベートIPについては特に注意が必要そうです。
初めはグローバルIPがデフォルトで設定されるため、それがあるとこの制限に抵触しそうです。

※以下上記URLの文面引用します

MySQL

プライベート IPのみが有効になっている必要がある
グローバルアドレスが有効になっている場合、その点から見直しが必要になります。
次のフラグのいずれかを使用している場合は、デフォルト値に設定する

sync_binlog：1
innodb_flush_log_at_trx_commit：1
replica_skip_errors：OFF
binlog_order_commit：ON

GTID が有効になっている外部レプリカがある場合は、GTID ベースの自動位置決めを使用するようにそれらのレプリカを構成する必要があります。そうしないと、メンテナンス後にレプリケーションが中断されます。
MySQL サーバーの UID はメンテナンス中に変更されます。
メンテナンス中、データベースログには 2 つの異なる VM からのメッセージが記録されます。
計画されたメンテナンス中に DDL が発行された場合、変更の作成または変更のタイムスタンプがメンテナンスのタイムスタンプより後になる可能性があります。

Postgres

インスタンスではプライベート IPのみが有効になっている必要があります。
max_wal_sendersCloud SQL for PostgreSQL Enterprise Plus エディションインスタンス上のリードレプリカの数は、およびフラグに設定された値よりも小さい必要がありますmax_replication_slots
計画されたメンテナンスの後、ログに記録されていないテーブルは空になります。
メンテナンス中、データベースログには 2 つの異なる VM からのメッセージが記録されます。
計画されたメンテナンス中に DDL が発行された場合、変更の作成または変更のタイムスタンプがメンテナンスのタイムスタンプより後になる可能性があります。

対象リージョン

https://cloud.google.com/sql/docs/editions-intro#editions-regions
日本だと東京リージョンは対応済みですが、大阪リージョンは未対応となりますので、DR環境構築予定の場合は特に注意ください。

所感

Postgres 互換では AlloyDB がありましたが、MySQL (Postgresも今回含まれますが)に関してもより強力なデータベースのマネージドサービスが GA されました。
スループットや可用性においても強力な機能になっていると思っており、今まで Cloud SQL を避けていたようなケースでも利用範囲が大きく広がるのではないか、と感じました。
また、個人的には SLA が 99.99 % になったことと、メンテナンス時のダウンタイムが大幅に短縮されたことで、運用面で得られる恩恵が大きいと感じました。
今後はすでに作成されているものについても、Enterprise エディションから Enterprise Plus エディションへDMSなどを使わずにより容易に移行できるようになることに期待したいです！
今回はドキュメントから読み取れる範囲での概要から実際の設定時の注意事項までを記載しましたが、次回は実際にやってみた内容について、記載したいと思います。

Cloud SQLのパフォーマンス向上！ダウンタイム短縮！ Cloud SQL Enterprise Plus エディションが発表！！

はじめに

概要

Enterprise