コンテンツに移動
データベース

Google Nest が Google Cloud の Cloud SQL に移行するまでの道のり

2024年3月14日
Google Cloud Japan Team

Gemini 1.5 モデル をお試しください。

Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。

試す

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

編集者注: スマートホーム プロダクトの分野をリードする Google Nest では、ダウンタイムを最小限に抑え、サービスの停止もデータの消失や破損もなく、以前のサービスを Google Cloud に移行しました。この記事では、担当チームがインフラストラクチャの費用削減、パフォーマンスの改善、システムの信頼性強化をどのように実現したのかをご紹介します。


Google Nest はスマート スピーカー、スマート ドアホン、スマート サーモスタットといった、さまざまスマートホーム プロダクトを生み出しています。Google Nest の プロダクトは効果的に連携して、お客様が欲しい情報をさっとチェックでき、自宅で安心に過ごせるほか、友だちや家族とのつながりに活用できます。

主要なレガシー システムが抱える費用、複雑化、リスクの課題

Google は 2014 年にスマートホーム企業の Nest Labs を買収したとき、同社のテクノロジー インフラストラクチャも引き継ぎました。その中にはデータベース管理に Amazon EC2 インスタンスを利用する、AWS にデプロイされた重要なサブスクリプション サービスも含まれていました。

こうしたサブスクリプションを継続させるためにインフラストラクチャを維持するのは、大変な仕事でした。アプリケーションの面では、サブスクリプションの管理に使用する SAP Hybris インスタンスを含め、多様なサービスを管理していました。この以前のインフラストラクチャには、テラバイト規模のサブスクリプション データが保存された複数の MySQL データベースもあり、すべてが Amazon EC2 で稼働していました。これらのワークロードのいくつかはセルフマネージド サービスであったため、Google のサイト信頼性エンジニア(SRE)は、年中無休の 24 時間体制でシステムをモニタリングおよび管理するという困難な役割を担っていました。

実現目標: MySQL ワークロードの持続可能な未来

私たちは、以前のインフラストラクチャを稼働し続ける現在のアプローチは長続きしないとわかっていました。そして、以前の MySQL データベース環境の制限に代わるクラウドベースのアーキテクチャを構築したいと考えました。最も重要なのは、メンテナンスのオーバーヘッドを削減するために、マネージド サービスを利用することです。また、真の水平方向のスケーラビリティと迅速な弾力性、システムの可用性と復元力の明らかな向上に加え、これらを含む移行後の KPI に対する状況を正確に示す堅牢なモニタリング ツールを必要としていました。

選定結果: Cloud SQL が突出

Cloud SQL は、以前のサブスクリプション データを管理するのに最適なソリューションでした。安全でフルマネージドの自動化されたサービスである Cloud SQL を導入することで、データベース管理を任せて、運用費用を削減し、重要なサブスクリプション サービスに必要な信頼性とパフォーマンスを維持できるようになりました。また、Cloud SQL は、幅広いモニタリングや分析のツールなど、他の Google Cloud サービスとシームレスに統合するため、ダウンタイムをほぼゼロに抑えてシンプルに移行することができました。

目指すべき姿を定めてから、移行を大きく 2 つの段階に分けました。最初に、以前のインフラストラクチャ上にあるサブスクリプション サービスを Google Kubernetes Engine(GKE)に移行してから、以前の MySQL データベースを Cloud SQL for MySQL に移行しました。それから、ダウンタイムとサービスの停止を回避し、データの消失や破損のリスクを最小限に抑え、移行したデータを検証するためのツールを探し始めました。移行プロセスを通して、次の 2 つの優れた機能が大きな違いをもたらしました。

  1. Database Migration Service(DMS)を使用したことで、データベース移行中に想定していた運用上の負担を大幅に軽減できました。このフルマネージド サービスで、サーバーのプロビジョニングから、自動モニタリング、自動スケーリングの対応まで、移行のほぼすべての局面にシームレスに対処できました。また、DMS は変更データ キャプチャ(CDC)モデルを活用し、システム リソースにかかる負荷を大幅に抑え、継続的なレプリケーションへの遅延がゼロに近いリアルタイムのデータベース移行を可能にします。
  2. データ検証ツール(DVT)を使用することで、テラバイト規模のサブスクリプション データを検証しながらも、移行での合計ダウンタイムを 1 時間未満に抑えられました。

以前のサブスクリプション インフラストラクチャを移行するプロセスに取りかかった時点で、迅速な行動が重要であることは認識していました。一方で、複数の MySQL インスタンスとテラバイト規模のデータが存在する環境に適していない移行方法を選ぶと、費用、複雑化、リスクを受け入れざるを得ない状況になることも理解していました。Cloud SQL チームと一緒に取り組むなかで、次の点によって、AWS 環境から迅速に移行できることを確認しました。

  • 継続的な移行プロセスと安全な接続を利用し、この規模の移行に伴いがちなパフォーマンスと信頼性、データ完全性に対するリスクをほぼ排除する
  • ユーザーデータの消失または破損が発生しない
  • 以前のインフラストラクチャをセットアップして、長期にわたって継続的に費用削減を達成する
  • 今後の移行プロジェクトの基準を定める

大きなメリット: Cloud SQL が優れた処理能力を発揮

Cloud SQL はあらゆる場面で私たちの期待に応えるだけでなく、期待を上回り続けています。たとえば、以前のデータベースをフルマネージドのクラウド環境に移行したことで、SRE の貴重な作業時間を少なくとも 10% 以上解放し、付加価値の低いメンテナンス作業や管理タスクからより戦略的なプロジェクトに切り替える機会を得られました。Cloud SQL の導入で、期待どおりに運用費用を削減できました。インフラストラクチャの管理、バックアップやレプリケーションへの対応、ストレージ容量の追加、その他の日常業務に費やす時間がほぼなくなりました。最後に、以前のサブスクリプション インフラストラクチャを Google Cloud 上で統合したことで、主要な p50 レイテンシ指標で 25% の改善が見られるなど、すでにパフォーマンスが大幅に向上しています。

移行計画を立てるうえで Cloud SQL は間違いなく有益な経験をもたらしてくれました。次の機会にも Cloud SQL のあらゆるメリットを享受したいと考えています。

使ってみる

-Legacy Nest Aware Infrastructure Migration 担当テクニカル リーダー Arpit Goyal

投稿先