Cloud SQL の 2020 年アップデートを全部振り返る

Sophia Hu
12 min readDec 24, 2020

--

本記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 24 日目です。

今日はクリスマスイブですね〜クリスマスのプレゼント選びやお正月準備で忙しい毎日を送ってる方が多いと思いますが、年内に一年を振り返るゆっくりした時間は持ちたいですね。

さて、今日は Cloud SQL の 2020 年アップデートをまとめて振り返りたいと思います。

Cloud SQL が 2020 においてたくさんのアップデートがありました、下表でまとめました。主に 5 つのカテゴリになります。

  1. 利用可能なエンジンと対応なバージョン
  2. インスタンスの構成管理
  3. レプリケーションとデータ管理
  4. セキュリティ
  5. お得な料金プラン

今回のブログでは、カテゴリごとに少し説明を加えたい機能については [説明] 欄に [◯] を付けました。また、[Cloud SQL] と記載している行がありますが、該当する機能がサポートされているすべてのデータベース(MySQL、PostgreSQL、SQL Serverなど)全て適用されると意味します。

では個々の機能の説明に入りたいと思います。

利用可能なエンジンと対応なバージョン

上図は現状 Cloud SQL に利用可能なエンジンと対応なバージョンです、この1年で大分揃ってきました。

まず、新しいエンジンの種類として SQL Server をサポートするようになりました。Enterprise をはじめ 4 つのエディションが利用できます。インスタンスレベルの照合順序も変更可能ですので、日本語の取り扱いに問題ありません。

それから、既存の MySQL では、第一世帯をつい廃止になり、代わりに第二世帯の 5.6 と 8.0 の 2 つのバージョンを加えました。

さらに、PostgreSQL に 10、12、13 の 3 つのバージョンも GA になりました。

インスタンスの構成管理

MySQL

10 月 30 日に、Cloud SQL for MySQL では 80 のフラグもベータから GA になりました。

GA になってないので本番環境では設定できないフラグがあってお困りな方がいらっしゃるかと思いますが、このリリースによってその問題を解決できるかを一度 MySQL サポートされているフラグ をご確認いただけたらいかがでしょうか?

PostgreSQL

effective_cache_size の値指定が可能になりました。

effective_cache_size はカーネルや PostgreSQL の共有バッファなど、PostgreSQLが使用するバッファ領域の大きさの推定値です。このフラグの値を大きくすると、オプティマイザがインデックスを使用した問い合わせプランを選択する傾向が強くなります。このリリースによって移行元のサーバー設定に合わせ値を変更したり、利用サーバーのメモリのサイズに合わせ最適な値に調整できるようになりました。インスタンス設定の最適化には役立ちます。

12 つの拡張機能の追加サポート

  1. postgres_fdw:インスタンス間で外部テーブルにアクセスをサポート
  2. pg_repack:肥大化したテーブルやインデックスを再編成し、さらに指定したインデックスに従ってレコードを並び替えることが可能
  3. pgfincore:OS のディスクキャッシュに乗ったテーブルとインデックスのページを管理する関数
  4. postgresql-hll:HyperLogLog データ構造に新しいデータ型 hll の導入
  5. pageinspect:デバッグの際に有用となる低レベルなデータベースページの内容を調べる関数
  6. pg_freespacemap:空き領域マップ(FSM)を検査する手法を提供
  7. pg_visibility:可視性マップ(VM)とページレベルの可視性情報を検査する手法を提供
  8. Pl proxy:リモート DB 呼び出し用プロキシ言語 で、レプリケーションやパーティショニングの記述が可能
  9. dblink:PostgreSQL には異なるデータベース間で通信を行うためにデータベースリンクを利用
  10. ip4r:IPv4 および IPv6 のアドレスまたはアドレス範囲の格納に 6 種類のデータ型を使用可能
  11. prefix:電話番号のプレフィックスに対応できるデータ型
  12. pgAudit:pgAudit は PostgreSQL で監査ログを取得するためのオープンソースソフトウェア

Cloud SQL for PostgreSQLの新たな拡張機能についてより詳細な解説が入っているブログもあるので、お時間がある時是非ご覧になってください。Cloud SQL for PostgreSQL の新たな拡張機能: 接続性および新しいデータ型のサポート

Cloud SQL

2019 年メンテナンス通知とスケジュール変更機能のリリースに続き、今年は Cloud SQL の各エンジンの共通機能としてメンテナンス不要期間の管理機能がリリースされました。

1 年間に 1 回、1~90 日のメンテナンス不要期間を設定できるようになりました。現在は gcloud コマンドライン不要期間中、Cloud SQL はデータベース インスタンスのダウンタイムを発生させるメンテナンスが実行されません。メンテナンス不要期間は、年度末などビジネスにとって重要な時期のダウンタイムの可能性を減らすように設定できます。

既存のメンテナンス通知やスケジュール変更も利用可能ですので、メンテナンスの通知を受け取った後、アドホックにスケジュールを変更するか、メンテナンスをより長く防止したい場合は、不要期間を設定できます。

詳細については Cloud SQL で年末商戦期間中の計画的ダウンタイムを回避 をご覧ください。

レプリケーションとデータ管理

このカテゴリでは下記 機能について説明します。

MySQL 5.7/MySQL 5.8

  • リードレプリカのバイナリログの同期頻度の変更サポート
  • マルチスレッドレプリカのサポート

MySQL/PostgreSQL

  • クロスリージョンのレプリカのサポート
  • サーバーレスエクスポート

リードレプリカのバイナリログの同期頻度の変更サポート

この機能はリードレプリカのレプリケーションラグを減らすためのオプションで、 MySQL 5.7/MySQL 8.0 のリードレプリカ側でのみ利用可能です。

MySQL 5.7 以降では、データ耐久性を向上させるために、バイナリログをディスクに同期する頻度を制御するパラメータの sync_binlog がデフォルトで安全値の 1 と設定され、トランザクションがコミットされる前にバイナリログをディスクに同期されます。

MySQL 5.7/MySQL 8.0 のリードレプリカ側では、sync_binlog のデフォルトの設定ではディスク書き込み数が多いため、パフォーマンスに悪影響を与えることがあります。この機能を利用し、レプリケーションの遅延を減らすには、 sync_binlog を 0 (バイナリログのディスクへの同期を無効にします) へ変更することを検討します。

また、リードレプリカがスタンドアロンサーバーにプロモートされると、設定はスタンドアロンサーバーの安全な値の 1 にリセットされます。

マルチスレッドレプリカのサポート

この機能はリードレプリカのレプリケーションラグを減らすためのオプションです。

MySQL のレプリケーションでは、レプリケーション SQL スレッドを使用して、リードレプリカのリレーログに収集されたトランザクションを実行します。Cloud SQL for MySQLでは、レプリケーションはデフォルトでシングルスレッドです。MySQL5.7/MySQL8.0 では複数のレプリケーション SQL スレッドを利用するように設定できます。

並列レプリケーションを有効にする手順は次のとおりです。

  1. リードレプリカで、レプリケーションを無効にします。
  2. リードレプリカで、並列レプリケーションのフラグを設定します。
  3. リードレプリカで、レプリケーションを有効にします。
  4. オプションで、プライマリインスタンスで、並列レプリケーションのパフォーマンスを最適化するようにフラグを設定します。

レプリカの読み取り用の並列レプリケーションのフラグ(変更する場合はサーバーの再起動は不要です。)

  1. slave_parallel_workers
  2. slave_parallel_type
  3. slave_preserve_commit_order
  4. slave_pending_jobs_size_max

クロスリージョンのレプリカのサポート

クロスリージョン レプリカとは、マスター インスタンスとは別のリージョンで、リードレプリカを作成できる機能です。

クロスリージョン レプリカの利点は主に下記 2 点あります。

  • アプリに近いリージョンにレプリカを配置することで読み取り性能を向上します。
  • レプリカはマスターへ昇格可能であり、DR サイトの構築が可能になります。

詳細についてCloud SQL のクロスリージョン レプリカ機能を紹介 をご覧ください。

サーバーレスエクスポート

Cloud SQLからの標準エクスポートの場合、エクスポートはデータベースがオンラインのときに実行されます。特に大規模なデータベースの場合は、エクスポートによってデータベースのパフォーマンスに悪影響が出ることがあります。オンライン業務に悪影響を最低限に抑えるために、サーバーレスエクスポートを利用します。

サーバーレスエクスポートとは、エクスポートをオフロードするために、別個の一時インスタンスを作成し、エクスポート操作を行います。データのエクスポートが完了すると、一時インスタンスは自動的に削除されます。

サーバーレスエクスポートは、一時インスタンスの作成に時間がかかるため、標準のエクスポートより少なくとも 5 分 (大規模DBの場合はそれ以上) かかることがあります。エクスポートの実行時間と元データベースのパフォーマンスへの影響は、トレードオフになります。

詳細についてパフォーマンスのオーバーヘッドなしで Cloud SQL からデータをエクスポート をご覧ください。

セキュリティ

プライベート IP によるクロスリージョンの接続

プライベート IP 経由で Cloud SQL への接続は、過去では同一リージョン内でしか通信ができませんでしたが、今年の機能改善でクロスリージョンでも接続できるようになりました。プライベート IP トラフィックは、パブリックインターネット経由しないのでよりセキュアな接続ができます。また、パブリック IP よりも低いネットワーク遅延を提供できます。

この構成は、プライベートサービスアクセスを使用して実装しています。具体的に、VPC ネットワークとクラウド SQL インスタンスが存在する基盤となる Googleサービス VPC ネットワーク間の VPC ピアリング接続しています。

下図は、プライベート IP(db1および db2)で構成された Cloud SQL インスタンスと同じ GCP プロジェクト内の GCE インスタンス(client-vm)を示しています。Cloud SQL インスタンスの IP アドレスは、プライベートサービスアクセスによって割り当てられた範囲内にあり、 VPC ネットワークにピアリング経由で接続できでいます。

お得な料金プラン

Cloud SQLの確約使用割引(CUD)の提供

Cloud SQLの確約使用割引(CUD)は、リージョンで Cloud SQL用のインスタンス (CPUとメモリ) を 1 年 (25% オフ) または 3 年 (52% オフ) 間継続して使用することを確約することで割引が適用された価格を提供します。

特徴と注意事項の説明:

  • 共有CPUマシンタイプ(db-f1-microやdb-g1-smallなど)は適用対象外です。
  • サポートされているデータベースエンジンの組み合わせで利用可能です。
  • ストレージ、バックアップ、IPアドレス、ネットワーク出力、またはライセンスは適用範囲外です。

購入方法と有効開始期間:

  • Google Cloud コンソールで CloudSQL のコミット済み使用割引を購入できます
  • 確約使用割引を購入した後、確約は次の1時間以内に有効になります。
  • リージョンごとに購入する必要があります。

詳細については Cloud SQL 確約利用割引 をご覧ください。

本日の紹介は以上になります。いかがでしょうか?

今年にリリースされた機能は中で大半はお客様やユーザー様にからのフィードバックによる改善でした。今後ともサービスを向上させるために、継続的に貴重なご意見、ご要望をいただけたら幸いです。

明日は今年最後の Google Cloud Japan Customer Engineer Advent Calendar 2020 の最終篇になります。お楽しみにしてください。

--

--

Sophia Hu

Customer Engineer at Google Cloud Japan. All stories are in my opinion.