FFN がクラウド上のフルマネージド データベースへの移行を加速した方法

※この投稿は米国時間 2021 年 4 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、テクノロジーを活用したソリューションを提供し、消費者の経済的安定の確立と債務問題の解決を支援する Freedom Financial Network にお話を伺います。Google Cloud SQL への移行をスピードアップするため、同社は Google の Database Migration Service を利用しました。

Freedom Financial Network の商品とサービスは、何十万人もの消費者の債務の減額や整理に活用されています。著しい成長を遂げている一方で、当社は、収益をさらに伸ばすためにはモノリシックなアーキテクチャを Google Cloud 上のマイクロサービスに移行しなければならないと考えました。そうすれば、当社の消費者向け商品群を拡張しやすくなります。その移行の一環として Google の Database Migration Service（DMS）を利用し、本来であれば数日を要するフルマネージド Cloud SQL への移行を数時間に短縮しました。当初は 2～3 時間のダウンタイムを覚悟していましたが、DMS を使用したおかげで、移行したアプリケーションあたり 10 分以下のダウンタイムで合計 1 TB のデータを移行できました。

オンプレミス インフラストラクチャからの開始

Google のデータクラウドに移行する前、当社のシステムは Rackspace でホストされていて、そのアーキテクチャは 3 つのビジネス ユニットに分割されていました。各ビジネス ユニットは約 600 GB のディスク スペースを持つ高可用性 MySQL クラスタを 1 つずつ備え、末端に接続された SAN にある 1.8 TB の共有ディスク スペースが 3 つのクラスタに均等に分けられていました。これら 3 つのクラスタはそれぞれ、MySQL を実行している 2 台のサーバーで構成されていましたが、一度にアクティブになるサーバーはそのうち 1 台だけでした。サーバーには自動フェイルオーバーが構成されていたため、一方のサーバーで障害が発生すると、もう一方のアクティブなサーバーに切り替わりました。3 つのビジネス ユニットに分割した理由は、あるビジネス ユニットでデータベースが必要になった場合にそれをそのビジネス ユニット固有のクラスタにセットアップしたかったからです。したがって、各ビジネス ユニットは実質的に、3～4 つのシステムを含むモノリスでした。

これらの大部分は、アプリケーションの規模や用途がさまざまに異なる MySQL 上の InnoDB データベースであり、コールセンター エージェントをサポートする多くの内部システムが含まれていました。これらのシステムのうち最大のものは、たった 1 つのスキーマで約 500 GB を使用していました。この他に、補助的なシステムや一般公開されているウェブサイトもありました。

これらのクラスタの運用を開始したのは 2013 年からで、3 つのビジネス ユニットを 2 名という少人数のチームで常に管理していました。各ビジネス ユニットは、それぞれが技術的に 3～4 つのサービスに分けられていたとはいえ、実質的にモノリスでした。今回マイクロサービス アーキテクチャに移行した動機の中には、各ビジネス ユニット間のコミュニケーションを管理するという側面もありました。

Rackspace では、ディスクサイズの変更のようなちょっとしたことでも、かなりの時間がかかりました。ディスクの割り振りや構成を依頼するサポート チケットを送信する必要がありました。これは詰まるところ手作業の介入であり、更新には 2～3 週間かかりました。

クラウドへの移行の検討

クラウドに移行するかどうかを決定し、使用するプロバイダとツールを選択するうえで、当社のクラスタは早期に検討しなければならない大きな問題でした。クラスタは大幅にオーバープロビジョニングされており、前述の理由から必要な量をはるかに超えるリソースを持っていました。

Cloud SQL の、クラスタを分割して適切なサイズに設定できる機能は本当に便利です。また、MySQL の上位バージョンに移行したかったため、柔軟性が高い点も助かりました。クラスタの構造が原因で、インプレースでアップグレードすると相当な時間と労力が必要になります。クラスタは一度に 1 つずつアップデートしなければならず、個々のクラスタはおそらくエンジニアリング チームの 60～70% に影響すると思われました。その調整は、考えるだけで悪夢です。Cloud SQL では、クラスタを別々のデータベース インスタンスに移行した後、環境のアップデートを 1 チームずつ、またはアプリごとにゆっくりと行うことができました。

Database Migration Service の選択

当初、自動移行ソリューションは検討していませんでした。特に小さなデータベースについては、移行はさほど複雑ではなかったからです。アプリケーションを停止してデータベースをエクスポートし、それを Cloud SQL にインポートしてからアプリケーションを再起動するだけで済みました。当社のアプリケーションのほとんどは、この方法で問題ありませんでした。

しかし、プロセスも終わりに差し掛かった頃、2 つのアプリケーションが残りました。前年に、そのうち一方のアプリケーションの移行プロセスを試みましたが、データベースの段階で行き詰まりました。ダンプとロードのプロセスに時間がかかりすぎたためです。必要なダウンタイムは 12～15 時間で、このアプリケーションが当社ビジネスのバックボーンであることを考えると、この方法は受け入れられませんでした。これほど長時間システムが使用できなくなると、当社ビジネスにとって、金銭面だけにとどまらず、目に見えた影響が生じます。そのため、新しいソリューションが必要でした。

当社製品チームが Google の担当者と話し合い、そこで Google Cloud の Database Migration Service（当時は限定公開プレビュー版でした）について知りました。このサービスは、MySQL から Cloud SQL for MySQL へのサーバーレス移行を追加費用なしの継続的なデータ レプリケーションによって実現するというものです。DMS に出会う前、オフライン移行や外部マスター（Google Cloud の DMS 以前のソリューション）などの方法を検討しましたが、いずれも当社のケースには適していませんでした。

テストしてから移行を実施

まず、DMS がうまく機能するかどうかを検証するために、ステージング データベースでテストランを行いました。使い方に関する問題をいくつか修正し、すべてを適切に構成した後、DMS は想定したとおりに機能しました。続いて、移行プロセスを開始しました。以前移行に失敗したバックボーン アプリケーションについて、その担当チームが再び移行に着手し、その間バックグラウンドで本番環境インスタンスのレプリカを設定してチームがステージングを管理できるようにしました。

Rackspace では、アプリケーションは仮想マシン（VM）で稼働して MySQL インスタンスに接続していました。Google Cloud への移行には、アプリケーションを Google Kubernetes Engine（GKE）上のコンテナに移行することも含まれていました。

3 つの移行を DMS で実施し、そのうち 1 つは 4 つのアプリケーションが関係していました。毎回、アプリケーション チームがアプリケーションを GKE 上の将来の本番環境にデプロイしましたが、すぐには本番稼働しませんでした。DMS を使用して導入したステージング データを含む Cloud SQL インスタンスを使ってアプリケーションをテストし、アプリケーションが正しく動作することを確認しました。次に、DMS で移行を開始し、両方の環境が同期してカットオーバー日が決まったら、あとは Rackspace 上のアプリケーションを停止して DNS レコードの宛先を Google Cloud に更新するだけでした。

結局、3 つのクラスタにおいて、データサイズが 240～500 GB とさまざまに異なる 5 つの論理データベースを移行し、その合計データサイズは約 1 TB でした。

ダウンタイムは数時間ではなく数分

DMS による移行は、予想よりはるかに短時間で完了しました。データベースをダンプして Cloud SQL インスタンスにロードするよう指示してから、それが完了して完全に同期した状態になるまでの時間は 12～13 時間で、その間手動の介入は不要でした。午後に処理を開始すると、翌朝出社する時刻までにはすべて完了していました。実際はこの作業のために数日確保していたので、これは大きな利点でした。

移行を計画した当初、2～3 時間のダウンタイムは、理想的とは言えないものの、許容範囲であると考えていました。しかし、DMS を十分に使いこなせるようになると、データベース側から見た各アプリケーションの実際のダウンタイムは長くても 10 分ほどでした。これは当社のどのチームにとっても大きな利点でした。

DMS には順を追った手順書が用意されており、これに沿うことで、データを失わずに移行を成功させることができました。DMS と Google Cloud の支援のおかげで、当社はモノリシック アーキテクチャを GKE にデプロイされたマイクロサービス アーキテクチャに移行し、サイドカー コンテナ パターンの Cloud SQL Proxy、または Go プロキシ ライブラリを使用して Cloud SQL に接続できるようになりました。

今は、安全で多目的かつ強力なデータクラウド インフラストラクチャを存分に活用しており、Google Cloud によるフルマネージドのおかげで開発者はお客様向け商品の拡張により多くの時間をかけられるようになりました。

Freedom Financial Network の Cloud SQL への移行の詳細については、最近のブログ投稿をお読みください。DMS に関心をお持ちの場合は、こちらの短い動画で詳細をご確認ください。

-Freedom Financial Network プリンシパル エンジニア Christopher Testroet