Database Migration Service による Cloud SQL ディスク容量の回復
Google Cloud Japan Team
※この投稿は米国時間 2022 年 3 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションに変更を加えたところ、ミスによって、思いがけずデータベースのデータ量が急増してしまったとします。データベース インスタンスでは、ディスク容量が不足しそうになると自動的にストレージを拡張する機能を適切に利用できるようになっています。多くの場合、この機能は有用であり、データベースが拡大し続けて容量不足に至ることによるダウンタイムを防げます。しかし、今回のストレージの急増は、想定をはるかに超えたものであったとします。幸いにも、アプリケーションのバグを修正し、データベースが容量を超過することはなくなりましたが、その影響が残り、ディスクが必要以上に大きくなってしまいました。よく言われるように、「ストレージは安価」であることに間違いはないでしょうが、購入ではなくレンタルする場合は、使用していない領域に費用をかけすぎないようにしたいものです。
Cloud SQL インスタンスのディスクのサイズを簡単に縮小する良い方法は（今のところ）ありません。ブロック ストレージは私たちが望むパフォーマンスを発揮しますが、残念ながらサイズを縮小することは少し困難です。ディスクを縮小するための手法としてよく見かけるアドバイスには、データをエクスポートし、新しいインスタンスを作成して、ディスクサイズが適切なインスタンスにデータをインポートするというものがあります。あるいは少し巧妙な方法として、外部レプリカ（通常のレプリカとは異なり、プライマリよりもディスクサイズを小さくすることが可能）を設定し、すべて同期されてからプロモートするというものもあります。
これらの手法をとることには何の問題もなく、実際、ディスクサイズを縮小するための非常に効果的な方法です。しかし、本番環境システムを稼働させながら（また、すべてのシステムで少なくともある程度のダウンタイムを伴いながら）、ディスクの縮小を適切に行うためのインフラストラクチャをセットアップすることは、費用対効果を考えると、単にディスクをそのままにして、それで十分とみなすという結果になりえます。
結局のところ、このプロセスは、不必要に大きくなった既存のインスタンスから、適切なサイズのインスタンスへの移行に似ています。Google は、移行を少しでも楽にするために、Database Migration Service を構築しました。Google のマネージド移行サービスを利用すれば、このプロセスは非常に簡単になります。ディスクを縮小する Cloud SQL ソース インスタンスの接続プロファイルを定義するだけで、DMS のガイドに従って、より小さいディスクを指定できる移行先インスタンスを作成することができます。
このプロセスを少し簡単にするために、いくつか考慮すべきことがあります。まず、インスタンスの移行の準備をする必要があります。設定によっては、データベースの再起動を伴う場合があります。データベースを移行したことがない場合は、MySQL と PostgreSQL についてのブログ投稿をご覧ください。
次に、アプリケーションが使用する IP アドレスは、プロモート後の新しいインスタンスを指す必要があるため、変更されることになります。ここで、DMS を使用すると、移行を設定する際にストリーミング移行として設定できます。そのため、通常必要となるエクスポートとインポートのキャッチアップについて心配することはありません。この状態は、新しいインスタンスをプライマリにプロモートするまで続きます。つまり、アプリケーションやその他のツールの準備と、カットオーバー前の新しいインスタンスのテストに必要な時間をかけることができます。
これは、すべてのアプリケーションをカットオーバーしながら、ターゲット インスタンスをレプリカとして残すことができるということです。このように、アプリケーションが新しい IP アドレスのキャッチアップを行う間、両方のインスタンスを稼働させたままにしておくことでカバーすることができます。そのため、ダウンタイムが最短になりますが、データベース内のデータがアプリケーションでどのように使用されているかによって、複雑な問題が発生する可能性があります。
これに備えるための方法としては、アプリケーションで Cloud SQL Auth Proxy を使用することがおすすめです。
もちろん、インスタンスが確立されている場合は、これによりダウンタイムが発生します。また、アプリケーションのロジックを変更して、プロキシを実行している場所（できればアプリケーションと同じマシン上）を指すようにし、カットオーバーする必要があります。この方法の利点は、古いインスタンスを指しているプロキシをシャットダウンし、新しいインスタンスを指しているプロキシを再起動する間、アプリケーションの再ポイントで生じるダウンタイムが最短になることです。
同様のことを行う他の方法としては、インスタンスの前にロードバランサや HTTP プロキシを置き、すべてのアプリケーションが一貫した IP アドレスで接続できるようにして、アプリケーションのコードを変更したり、再デプロイしたりすることなく、背後のデータベースを切り替えることができるようにすることです。インフラストラクチャの変更はアプリケーション コードから切り離されます。これらは必要に応じて複雑なものにも単純なものにもなりえます。たとえば、次の図は、ロードバランサを高可用性プロキシと組み合わせて読み取りオペレーションを分散させる方法を示しています。
Cloud SQL インスタンスへのプロキシ接続のさまざまな方法について詳しくは、こちらの記事をご覧ください。
いかがでしたか。何か問題が発生し、Cloud SQL インスタンスのディスク容量を取り戻す必要が生じた場合に、この投稿がお役に立てば幸いです。最後までお読みいただきありがとうございました。ご意見やご質問がございましたら、遠慮なく Twitter からダイレクト メッセージでご連絡ください。
- デベロッパー アドボケイト Gabe Weiss
