ラテンアメリカ最大のストリーミング サービス、Cassandra から Bigtable に移行

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

編集者注: 今回は、Globoplay ストリーミング サービスを運営するラテンアメリカ最大のメディア グループ、Grupo Globo からお話を伺いました。この投稿では、Apache Cassandra から Bigtable への移行の概要と、その過程で学んだことをご紹介します。

ラテンアメリカ最大のメディア グループ Grupo Globo は、Globoplay ストリーミング サービスを所有および運営しています。このストリーミング サービスで、ユーザーはオンデマンドの動画や音声のコンテンツに加え、テレビのライブ配信にもアクセスできます。ユーザーの多くは、コンテンツを一度に消費するのではなく、複数のデバイスを切り替えて利用するため、中断したところからタイトルの視聴を再開できるのは、当社のサービスにとって重要な機能です。

当社の Continue Watching API（CWAPI）は、Go で記述されたアプリケーションで、音声と動画の視聴タイムスタンプを処理します。このワークロードは、85% の書き込みリクエストと 15% の読み取りリクエストで構成されています。このような書き込みトラフィックを効率の良い方法で処理するために、これまで、高い書き込みスループットと低い書き込みレイテンシで知られる Apache Cassandra を利用してきました。

当初、Cassandra は Globo 独自のデータセンターにある物理マシンにインストールされていました。既存のオンプレミスのセットアップへの適合性を考えると、Compute Engine のリフト＆シフト アプローチは当時最も理にかなっていました。このセットアップでもアプリケーションは問題なく機能しましたが、ユーザー トラフィックの変動に対応するためにはノードの追加と削除が必要で、これは時間のかかる作業でした。その結果、クラスタが過剰にプロビジョニングされ、インフラストラクチャのコストが上昇しました。Cassandra を運用することは、定期的にソフトウェアのパッチを適用することでもあります。これは見過ごされがちですが、運用上大きなオーバーヘッドとなります。

当社は、Cassandra に代わる可能性のある選択肢を評価するプロセスを開始しました。Bigtable が YouTube でどのように利用されているかを視聴していましたし、Spotify のような他のストリーミング サービスが Cassandra から Bigtable に切り替えて、最大 75% の節約を実現していることがわかったときは励みになりました。とはいえ、念のため、自社の特定のワークロードとトラフィックへの対応を使用して独自の評価を実施したいと考えました。

当初、Google Cloud の「Cassandra as a Service」ソリューションを検討しました。これは、コードを変更することなく、リフト＆シフトの利便性を提供するものでした。しかし、自社のデータでベンチマークを行い、負荷テストを実施した結果、Bigtable が最適であることがわかりました。Bigtable は、クラウド上のマネージド Cassandra と比較して、さらなる移行作業が必要になるとはいえ、所有コストが低く、追加機能も備えていました。

Bigtable を選んだ理由

Bigtable は、主に、高い読み取り / 書き込みスループットでの低レイテンシ、大量のデータに対する拡張性、復元力、組み込まれている Google Cloud とのインテグレーション、何十億人ものユーザーがいる Google のサービスで検証済みという特徴により、有力な選択肢であることは明らかでした。マネージド サービスであるため、セルフマネージド データベースに比べて運用も簡素化されます。高可用性、データ耐久性、セキュリティなどは、導入直後でも保証されています。

さらに、グローバルに分散されたリージョン間のマルチプライマリ レプリケーションは、可用性を高め、リクエストを最も近いリージョンに自動的にルーティングすることで、より高速なアクセスを保証するだけでなく、当社のユースケースに対応した書き込み後の読み取りの整合性を簡単に実現することにも役立ちました。Bigtable は、使用状況の指標ダッシュボードや Key Visualizer などのネイティブ ツールを備えていて、これはキーへのアクセス パターンを分析することで、パフォーマンス改善のポイントを見つける際に役立ちます。Bigtable のデータも、データをデータ ウェアハウスにコピーせずに、BigQuery からクエリを実行できます。

実装、データ移行、ロールアウト

Cassandra の代替には Bigtable が最適であると判断した後、チームは以下のステップで移行を計画しました。

Cassandra のコードを Bigtable に移植する

Bigtable は、Go などのさまざまなクライアント ライブラリを提供しています。当社は、データベース間でデータを移行できるように、最初にデータベースに書き込むコードパスに焦点を当てました。書き込みが終わると、読み込み機能を実装し、すべての Cassandra コードを問題なく Bigtable に変換できました。テストを作成し、各機能がシステムの他の部分と適切に統合されていることを確認しました。

両方のデータベースで重複する書き込みを有効にする

移行中に新しいデータが失われないように、両方のデータベースで重複する書き込みを有効にしました。まずは各データベースに 1% のデータを書き込み、問題がないことを確認しながら徐々に割合を増やしていきました。これにより、Cassandra が移行中も主要データベースを維持したため、ユーザーに影響を与えることなく、データベースとアプリケーションがどのように動作するかを検証できました。

データの移行

バッチ移行の実行には、Dataflow を使用したパイプラインを作成することにしました。Bigtable の Dataflow テンプレートを出発点として利用してみましたが、このアプローチは実装が簡単で、効率が非常に良いことがわかりました。

スクリプトでは、Cloud Storage のバケットに保存されていた Cassandra ダンプから静的ファイルを読み込みました。ファイルの各行は、Cassandra テーブルからの行を表します。その後、スクリプトでは Bigtable 用にデータが変換され、テーブルに挿入されます。同時に、CWAPI は Bigtable に新しいトラフィックを書き込みました。

開発環境でスクリプトを検証した後、本番環境で実行できるように準備しました。データの量が多いため、ダンプファイルを複数のファイルに分割し、それぞれのサイズを約 190 GB にしました。この戦略により、Dataflow スクリプトの実行中に予期せぬエラーが発生した場合、データを再処理しなければならない可能性が軽減されました。

移行を検証する

移行を検証するために、シンプルな API を作成し、社内にデプロイしました。この API は 2 つのポートを公開しています。それぞれのポートのエンドポイントはパラメータとレスポンスが同じですが、データについては一方が Cassandra のデータベース、他方が Bigtable のデータベースに求めます。

この API は、2 つのデータベースの統合で使用されたコードを活用していることを強調しておく必要があります。これにより、本番環境の実装と異なる可能性のある新しい実装の必要性が排除されます。

この API は後に、当初 Twitter 社によって構築され、現在はオープンソースとなっているツール Diffy のデータソースとして使用されました。当社は Diffy を使用して移行を検証しました。新しいコードと古いコードのインスタンスを並べて使用することで、サービスの潜在的なバグを発見します。Diffy はプロキシのように動作し、受け取ったすべてのリクエストを実行中の各インスタンスにマルチキャストします。レスポンスを比較し、その比較から生じる可能性のある回帰を報告します。

「主要」アプリケーションと「候補となる」アプリケーションの 2 つのアプリケーションが先ほど説明したのと同じ検証アプリケーションで構成されるように、Diffy のインスタンスを構成しました。唯一の違いは、主要アプリケーションには Cassandra 用のポートを使用し、候補となるアプリケーションには Bigtable 用のポートを使用することです。このようにして両方のデータベースで同じクエリを比較することで、移行が成功したかどうかを比較できます。

Cassandra のデータを Bigtable に移行して CWAPI で両方のデータベースのデータを 100% 保存した後は、Bigtable のインテグレーションのロールアウトを開始するために、移行が正常に行われたことを確認する必要がありました。

この戦略では、GET リクエストのごく一部を Diffy に複製することにより、作成された検証アプリケーションを呼び出し、差分を含むレポートを生成しました。ただし、本番環境でリクエストに対応する Cassandra データベースに負担がかからないようにする必要があったため、リクエストの 1% をサンプリングすることにしました。

CWAPI アーキテクチャにはリバース プロキシとして動作する Nginx のインスタンスがあるので、そのインスタンスを活用して GET リクエストを複製し‘ました。そのためには、split_clients および mirror という 2 つのモジュールが不可欠でした。split_clients は、複製されるリクエストの割合とリクエストの複製に使われる mirror とを制御するためのモジュールです。

ロールアウト

すでに Bigtable を広範囲に使用してすべてのデータの書き込みを問題なく行っていたチームは、サンプリングに基づいて移行が正しいことを検証し、いくつかの不整合を修正した後、ロールアウトを開始する段階に入ったと判断しました。

そこで、サービス提供パスにも同じデプロイ戦略を使い、Bigtable によって提供される GET リクエストを 1% から徐々に 100% まで引き上げました。

Cassandra サーバーは、約 15 日間の短い「検疫」期間を経て廃止しました。

まとめ

この移行に使われた戦略は、確実にユーザーに影響を与えないようにするために非常に重要でした。両方のデータベースに書き込むことで、インテグレーションを継続し、問題を簡単に修正できました。Diffy と移行検証 API は、確実に移行が正しく実行され、ユーザーデータが影響されないようにするために不可欠でした。検証後の読み取りリクエストのロールアウトは、Bigtable がすでに高いサーバー トラフィック下にあり、データが検証されていたため、非常にスムーズに行うことができました。単体テスト、統合テスト、エンドツーエンド テストを行い、十分に抽象化された CWAPI コードのおかげで実装も簡素化され、すべてが適切であるという確信を持つことができました。

Bigtable は Cassandra の優れた代替であることが実証され、いくつかの注目すべきメリットをもたらしました。自動スケーリングと組み合わせた高可用性およびパフォーマンスにより、Cassandra のクラスタよりも低コストで信頼性の高い運用が可能になりました。当社では、パフォーマンスや機能を損なわずに、すでに約 60% の節約を達成しています。さらに、Redis Stream ベースのキュー ソリューションも Pub/Sub に移行しました。この移行は、アプリケーションのバックグラウンド処理能力を強化し、拡張性とパフォーマンスを向上させただけでなく、より効率的なメンテナンスと顕著な運用費用の削減にも貢献しました。

Google Cloud は、堅牢な技術ソリューションを提供し、当社の財務リソースを最適化することに役立つ戦略的な選択肢となっています。Bigtable に移行することで、メンテナンスの必要性が減り、データベースの拡張性が確実となり、より優れたオブザーバビリティ ツールが手に入り、他の Google Cloud プロダクトとの強固なインテグレーションを活用できるようになりました。進化し続けるビジネスの要求に応えるため、データベース管理を簡素化するこのパートナーシップを引き続き継続していきたいと考えています。

その他のリソース

Bigtable に移行することで、他社がどのようにしてサービスのパフォーマンス、拡張性、信頼性を向上させながら、クラウド費用を削減しているのかをご確認ください。

• Wunderkind がパフォーマンスの安定性を向上させるために DynamoDB から Bigtable へ移行
• Airship が Cassandra と HBase から Bigtable に移行して、管理オーバーヘッドの削減とパフォーマンスの信頼性向上を実現
• Reltio が Bigtable で Cassandra ワークロードをモダナイズ
• Box が HBase から Bigtable にどのように移行したか
• Choreograph が Couchbase から Bigtable に移行して広告ソリューションを拡張

Bigtable の無料トライアルをどうぞご利用ください。

ー Globo、ソフトウェア エンジニア、Michel Henrique Aquino Santos 氏