要約

  • Google Cloudは9月8日、Cloud SQL for MySQLの管理API向け地域別エンドポイントを一般提供すると発表した。5月にはプレビュー版が公開されていた。
  • 地域化されるのは管理要求を受けるフロントエンドであり、バックエンドの依存関係や復旧手順まで一律に地域内へ閉じるわけではない。

地域を指定できることと、その地域だけで運用が完結することは違う。Cloud SQLの管理APIに加わった選択肢は、この区別を調達と運用の双方に持ち込む。管理画面で普段行う操作と、障害時に必要な操作が、同じ境界を通るとは限らないからだ。

Google Cloudの9月8日の更新情報は、Cloud SQL for MySQLの地域別管理APIエンドポイントを一般提供とした。MySQLの更新履歴には5月11日のプレビュー公開が記されている。今回を地域別アクセスそのものの初登場と捉えるのは正確ではない。

一覧が減っても、削除されたとは限らない

利用文書によると、地域別エンドポイントへの要求は、グローバルなロードバランサーを経由する方式とは異なり、指定地域のフロントエンドで扱われる。地域一致が必要な操作では、対象リソースと入口の地域が異なると4xxエラーになる。

一方、インスタンス一覧の違いはエラーとして現れるとは限らない。グローバルな入口なら複数地域のインスタンスが返るが、地域別の入口ではその地域のものだけになる。呼び出しが正常終了したという監視結果だけでは、全社の資産を把握できたかどうかは分からない。件数の減少も、それだけで削除の証拠にはならない。

したがって、入口を切り替える際には、一覧をどの範囲で集め、誰が地域横断で照合するかを決める必要がある。これは機能の欠陥を指摘する話ではない。APIが約束する範囲と、利用者が一覧に期待する範囲を一致させる仕事だ。

復旧経路には別の規則がある

文書は、APIの一部のバックエンド依存先やメタデータが、引き続きグローバルな構成要素に依存し得ると明記している。入口が地域別になったことを、サービス全体の完全な分離や法的要件への適合保証に置き換えることはできない。

バックアップ資源は地域をまたぐ復元に備えてグローバルな資源として扱われ、Google Cloudはアクセスや復旧にグローバルな入口を使うことを勧める。地域別の利用が全面的に禁止されるわけではない。さらに、BackupRunsはインスタンスの地域の入口から提供される別の扱いだ。二つをまとめて「バックアップも地域内で完結」と説明してはならない。

ツールの経路もそろっていない。gcloudとTerraformでは手動の上書き設定によって地域別入口を利用できるが、コンソールとConfig Connectorは未対応で、Cloud SQLのリモートMCPサーバーはグローバルな入口を使う。認証方法、要求本文、APIのパスとバージョンは変わらない。

現在の地域別管理エンドポイントは公共ネットワーク経由の接続に限られ、プライベート接続と複数地域をまとめたアドレスには対応しない。これは管理APIへの接続条件であり、非公開のデータベースを外部公開するよう求めるものではない。新しい料金や実測の顧客節約額も示されておらず、選択肢の価値は具体的な運用経路を見て判断することになる。