Yahoo カレンダーがハードウェア キューと DBA ボトルネックから解放された方法

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

編集者注: Yahoo Mail は、Google Cloud への移行によって数百ペタバイトのサービスをモダナイズするという、これまでで最大規模のインフラストラクチャ変革の真っ只中にあります。Yahoo Mail の移行は、数億人の Yahoo Mail ユーザーにとってエクスペリエンスの不可欠な部分である Yahoo カレンダーから始まりました。これは、大規模な常時稼働のワークロードです。これは、ミスが許されない大規模な取り組みでしたが、結果として、お客様に影響を与えることなくスムーズに移行することができ、

Cloud SQL は、Yahoo のオペレーションの複雑さとスピードに対応できました。また、手動のオーバーヘッドを削減し、デベロッパーのアジリティを高め、次のステップへの基盤を築くことで、Yahoo の働き方を変えることにもなりました。

Yahoo では、基幹プラットフォームである Yahoo メールをクラウドに移行することが、これまでで最も重要なインフラストラクチャの取り組みの一つになることを認識していました。500 ペタバイトを超える相互接続されたシステムがあるため、早期に信頼を築くには、影響の大きい小規模なワークロードから始める必要があることがわかっていました。こうして、数億人の Yahoo Mail ユーザーにとってエクスペリエンスの重要な一部である Yahoo カレンダーが、最初に移行する本番環境サービスとなりました。

毎日ユーザーが利用するサービスを中断することなく、大規模な常時稼働サービスを移行する必要がありました。移行に失敗すれば、何百万人もの人々がスタンドアップ ミーティングや誕生日ディナー、予約した歯医者の予約を逃してしまう可能性があります。

Google Cloud を選んだのは、マネージド インフラストラクチャで運用をモダナイズし、手作業を減らし、大規模な変革のために信頼できるエコシステムを活用するためです。Yahoo カレンダーの移行は、Cloud SQL でミッション クリティカルなサービスを実行するための実証の場となり、Yahoo メールに関する数年間の移行計画のペースを設定することになりました。

招待を 1 件も逃さずにインフラストラクチャをモダナイズ

置き換えの対象となったインフラストラクチャには、数十のオンプレミス MySQL（Percona）インスタンスが含まれていました。堅牢ではありましたが、運用のスピードを重視したものではありませんでした。スケーリングは、ハードウェア リクエストを提出し、数週間から数か月待つことを意味していました。バックアップやアップグレードなどのルーチンタスクは、別のデータベース管理（DBA）チームが担当する必要がありました。需要の増加に伴い、アジリティの必要性も高まりました。増大するニーズに、より柔軟かつ迅速に対応するため、Google は大規模な取り組みに着手しました。

• 複数のリージョンにわたる数十個のデータベース シャードの移行

• 20 TB を超えるストレージ（レプリカを除く）の移行

• 100 万 QPS の読み取りと 2,500 QPS の書き込みのピーク トラフィックをサポート

• 数億人の Yahoo Mail ユーザーのカレンダー エクスペリエンスをサポートするために、アプリケーション スタックを Google Kubernetes Engine（GKE）上で実行するようにリプラットフォーム

Cloud SQL は、既存の MySQL ワークロードを最小限の変更でサポートしているため、完全な再アーキテクチャを行わずにオンプレミスのシャードを複製できます。この互換性が、フルスタックを再構築するための基盤となりました。すべてを機能させるために、UI、API、バックエンドを GKE に移行し、すべてを複数の Google Cloud リージョンの Cloud SQL デプロイメントに接続しました。これらすべてを、一般ユーザーのダウンタイムなしで段階的に移行する必要がありました。トラフィックは既存のエンドポイントを流れ続け、プロキシレイヤは各ユーザーの場所と移行状態に基づいてリクエストをルーティングしました。データベース シャードの準備が整うと、Cloud SQL で読み取り / 書き込みモードに慎重に切り替え、バックエンドを段階的に移行しながら、カレンダー ユーザーがスケジュールどおりに利用できるようにしました。

こうした大規模な移行にはバックアップが必要

Google Cloud の Professional Services Organization（PSO）は、その実現に重要な役割を果たしました。初期段階から、彼らは私たちのチームに組み込まれていました。Cloud SQL の評価 Database Migration Service（DMS）を使用して、概念実証作業をガイドし、移行アーキテクチャのストレステストを実施しました。

DMS を使用したデータのレプリケーションで障害が発生したとき、PSO は Cloud SQL エンジニアリング チームと社内のセキュリティ チームおよび DBA チームと緊密に連携して、カスタムの回避策を設計しました。カットオーバーの際には、容量の制約のデバッグやシャドウ トラフィック中の接続スパイクのトラブルシューティングなど、問題が発生したときにすぐにサポートしてくれました。また、権限の変更が原因で発生した逆方向のレプリケーションの失敗を解決するのにも役立ちました。これは、Google のガイダンスがなければ予測できなかったエッジケースです。

Cloud SQL のおかげで重要なことに時間を割けるようになった

マネージド インフラストラクチャにより、手動操作が大幅に減り、データベース管理のオーバーヘッドが削減され、待つことなくスケールアップできるアジリティが向上しました。アプリケーション チームは、手動プロセスに頼ることなく、Infrastructure as Code（IaC）を使用してデータベース シャードをデプロイおよび管理できるようになりました。バックアップ、パッチ適用、フェイルオーバーが自動化され、リスクと手作業が軽減されます。使用状況と費用のモニタリングが組み込まれているため、全体的な最適化に役立っています。また、セキュリティ プロトコルとの緊密な統合により、大規模な一般向けサービスを高い信頼性で運用できます。

現在、Yahoo カレンダーは 1 秒あたり数十万件のクエリを処理し、障害復旧（DR）を備えた 26 個の Cloud SQL インスタンスを運用しています。また、データベースだけで 2,500 個の仮想 CPU と 17 TB のメモリを含むインフラストラクチャ上で実行されています。アプリケーション層は 850 個の Pod と 2,200 個の vCPU に及び、10 TB のメモリに対応しています。ハードウェアやハンドオフを待つことなく、自信を持って大規模に実行できるようになりました。

カレンダーの次の予定

インフラストラクチャが敵ではなく味方になってくれることのメリットを実感しています。しかも、スケーリング、パフォーマンス、セキュリティを損なうことなく、すべてを実現しています。移行戦略を徹底的にテストし、クラウドでの運用方法を改良したことで、500 ペタバイトを超える Yahoo Mail の環境全体に対応する準備が整いました。

今後数年間は、スマートなスケーリング、俊敏性の維持、モダナイゼーションが必ずしも混乱を意味するわけではないことの証明が重要になります。しかし、あらゆる移行で最も難しい部分（出発）を終え、カレンダーは Cloud SQL で実行されるようになり、すべて予定通り進んでいます。

詳細:

• Cloud SQL でビジネスを変革する方法を確認する。今すぐ無料トライアルをお試しください。

• IDC レポートをダウンロードして、Cloud SQL への移行によってコストの削減、アジリティの向上、デプロイの高速化を実現する方法をご確認ください。

• Ford と Lightricks が Cloud SQL でモダナイズして、高いパフォーマンスを実現し、費用を削減した方法をご確認ください。

-Yahoo、ソフトウェア アプリケーション エンジニアリング担当ディレクター、Sunitha Reddy 氏 
-Yahoo Mail、シニア エンジニアリング マネージャー、Lee Atkins 氏