はじめに

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などを䜿わずにより容易に移行できるようになるこずに期埅したいです
今回はドキュメントから読み取れる範囲での抂芁から実際の蚭定時の泚意事項たでを蚘茉したしたが、次回は実際にやっおみた内容に぀いお、蚘茉したいず思いたす。