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

Bigtable の利点: Flipkart がデータを最大限に活用している方法

2024年8月21日
Aditya Tiwari

SDE III, Data Platform, Flipkart

Savitha Sethuram

Manager, AI Solutions, Google

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

編集者注: インドの大手 e コマース プラットフォームである Flipkart は、テクノロジー インフラストラクチャの強化と将来の成長の支援を求めて Google Cloud と連携しました。同社の取り組みにおける重要なステップの一つは、ストリーミング分析インフラストラクチャを Apache HBase から Bigtable に移行したことでした。これにより、最小限のコード変更で、開発者の生産性、データベースのパフォーマンス、顧客の需要の大きな変動への対応力が向上しました。


インドの活気ある e コマースの世界において、リーダー的地位を確立している Flipkart は、4 5,000 万人を超えるユーザーにサービスを提供し、140 万人の販売者を抱えています。この巨大な EC モールでは、1 5,000 万点という膨大な数の商品が販売されており、毎日何百万もの配送を処理しています。

Flipkart の最も重要なイベントは Big Billion DayBBD)セールで、これは世界的なショッピングの祭典であるブラック フライデーやサイバー マンデーのようなものです。Big Billion Day セールは 9 月と 10 月の数日間にわたって開催され、インドの活気あるお祭りシーズンと重なります。この期間中、Flipkart ではトランザクション量が通常業務(BAU)の 68 倍に急増します。

Flipkart は、技術的環境を再構築して事業の将来性を確保しようとしていました。そのため Google Cloud とのパートナーシップを開始しました。中枢的なプラットフォームである Flipkart Data PlatformFDP)の立ち上げに成功したことで、その成果はすでに実を結びつつあります。

fStream: Flipkart のストリーミング プラットフォーム

Flipkart のデータ オペレーションの中核となるのは、社内の共通ストリーミング プラットフォームである fStream です。fStream は、Dataproc を使用して Apache Spark Apache Flink でシームレスに動作します。

fStream に不可欠なコンポーネントの一つは、耐久性のある StateStore で、これは次のようなさまざまな重要な機能の永続性レイヤとして機能します。

  • インデックス作成: 受信したストリーミング データを StateStore に保存し、特定のキーに基づいて他のストリームと結合できるようにします。

  • 結合: 共通キーに基づいて 2 つ以上のストリーミング ソースのデータを照合してマージし、結合された出力を生成してさらに処理するか保存します。これには、受信遅延データと、StateStore に保存されている関連メタデータを順不同で処理するための必須結合が含まれます。

  • 集計: 複数のキー、項目、時間バケットにわたる集計結果を保存します。集計により、他の fStream パイプラインで処理するための中間データの保存と、リアルタイム レポートを生成するために fStream API によってクエリされる最終データの保存という 2 つの目的が達成されます。

  • チェックポイント: Kafka などのソースの外部チェックポイントを維持します。

  • 重複除去: ストリーミング データソースから重複レコードを識別して削除し、以降の処理や保存のために一意のレコードのみが保持されるようにします。
https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_SA1pmYx.max-1500x1500.png

図 1. ステートフル ストリーム処理パイプラインの Statestore

オンプレミスにおける展開では、Flipkart は、堅牢な機能を備えた Apache HBase StateStore として使用していました。しかし、Google Cloud に移行する際には、Bigtable のクラウドネイティブ機能を活用できるようにしたいと考えていました。そのため、チームは Google Cloud の高度な機能とスケーラビリティを最大限に活用するために、HBase から Bigtable への移行に取り組みました。

移行プロセスの概要

Apache HBase が提供する機能は複雑でクリティカルな性質を持つため、Bigtable への移行は、以下のようないくつかの重要なステップを含む細かいプロセスでした。

  1. HBase クラスタ テーブルのスナップショットを取得する。

  2. HBase ユーティリティ(MapReduce ジョブ)を使用して、スナップショットを別のディレクトリ内の同じ HDFS クラスタにコピーする。

  3. HBase ユーティリティと gcs-hadoop コネクタ(MapReduce ジョブ)を使用して、スナップショット データを Cloud Storage バケットに転送する。

  4. 必要なスキーマと構成を使用して、Bigtable に宛先テーブルを作成する。

  5.  Dataflow 経由で Bigtable HBase 移行ツールを使用して、Cloud Storage スナップショット データを Bigtable にインポートする。

  6. 完全なデータ移行が確実に行われるように、スナップショット Bigtable 間の行 / リージョン レベルのハッシュを検証する。

Flipkart のデータ エコシステムにはパイプラインの入り組んだ依存関係も含まれており、移行プロセスをさらに複雑にしていました。インデックス、結合、集計など、さまざまなタイプのパイプラインが、移行に固有の課題をもたらしました。たとえば、これらのパイプラインは、リアルタイム プロセスとして、移行期間中でもダウンタイムなしで稼働し続ける必要がありました。また、集計パイプラインでの二重カウントや、結合パイプラインでの受信遅延データの提供などの問題を防ぐために、2 つのセットアップでデータを正確に一度のみ処理する(たとえば、一度のみ集計する)必要がありました。

以下では、これらのパイプラインを移行するための Flipkart のソリューションの概要を説明します。

インデックス パイプライン

移行プロセスを開始するために、Flipkart Kafka ソーストピックを Pub/Sub に複製しました。同時に、チームは重要なデータセットを含む HBase テーブルのスナップショットを取得し、それを Bigtable に転送しました。その後、Google Cloud でインデックス パイプラインを起動し、Pub/Sub で利用可能な最も古いメッセージから始めました。こうして新しい環境でのデータ処理が開始されました。

Google Cloud には、HBase レプリケーション ライブラリを介して、ダウンタイムをほぼゼロに抑えて HBase から Bigtable に移行するツールが用意されています。しかし、Flipkart の最終的なアーキテクチャでは Google Cloud で実行するインデックス パイプラインが必要であったため、レプリケーションにパイプラインを使用して、HBase スナップショットのコピー中に 2 つのデータセットを同期させる方法をとった方が運用上効率的でした。

集計パイプライン

集計パイプラインを移行するために、Flipkart はプラットフォーム内の既存のパイプラインを一時停止し、HBase テーブルのスナップショットを取得して、ソースの Kafka チェックポイントを記録しました。ダウンタイムなしで稼働し続ける必要がある場合は、その後に元の集計パイプラインを再起動しました。そこから、HBase 集計テーブルを Bigtable に転送しました。次に、チームは Google Cloud で並列パイプラインを起動し、Kafka からデータを読み取って Bigtable に書き込みました。「ingestedAt」タイムスタンプにフィルタを適用し、「someTimestamp」より前のデータが含まれるようにしました。次に、記録された Kafka チェックポイントを使用して、「someTimestamp」までのすべてのデータが Bigtable で適切かつ確実に集計されるようにしました。その後、Google Cloud で集計パイプラインを起動し、フィルタ(「ingestedAt> someTimestamp)を使用して、コピーしたデータの最後または指定した将来の日付より後のデータを Pub/Sub から読み取り、処理を引き継ぎました。

集計パイプラインの移行を完了するために行った手順は次のとおりです。

  1. HBase で実行されている集計パイプラインを一時停止する。

  2. HBase テーブルのスナップショットを取得し、ソース Kafka チェックポイントを記録する。

  3. 稼働し続ける必要がある場合は、集計パイプラインを再起動する。

  4. HBase 集計テーブルを Bigtable に転送する。

  5. Google Cloud で、Kafka からデータを読み取って Bigtable に書き込む並列集計パイプラインを起動する。「ingestedAt」タイプスタンプに基づいてフィルタを適用し、「someTimestamp」より前のデータが確実に含まれるようにする。

  6. 手順 2 で取得したチェックポイントを、この Kafka ジョブのソース チェックポイントとして使用する。これにより、「someTimestamp」までのすべてのデータが BigTable で適切かつ確実に集計されるようになる。

  7. Google Cloud で、逆の「ingestedAt」フィルタ(> someTimestamp)を使用して集計パイプラインを起動する。このパイプラインは Pub/Sub からデータを読み取り、「someTimestamp」から処理を引き継ぐ。「someTimestamp」には将来の日付(たとえば、1 日先)を設定できる。

結合パイプライン

必須結合でない場合、特別な移行ソリューションは必要ありませんでした。必須結合の場合、fStream 同期はべき等性に対応しているため、アプローチは前述の集計パイプラインの場合と同様です。必須結合パイプラインを移行するには、インデックス パイプラインの移行を開始して、完了するまで待機します。次に、パイプラインを一時停止し、HBase テーブルのスナップショットを取得して、それを Bigtable に転送します。必要に応じて、通常オペレーションを保護するために必須結合を再開します。その後、Google Cloud で並列パイプラインが起動し、すべてのデータが読み取られて Bigtable に書き込まれると、最終的に処理が引き継がれます。

まとめ

全体として、Bigtable とやり取りするパイプラインの移行プロセスはうまくいき、べき等データを管理するパイプラインの 70% は、シームレスに移行され、中断のないオペレーションが確保されました。非べき等データを処理する残りの 30% のパイプラインは、一度再起動する必要がありましたが、ダウンタイムは最小限に抑えられました。この戦略的なアプローチにより、パイプライン全体をスムーズに移行でき、継続性と効率性が保証されました。

  1. インデックス パイプラインの移行を開始する。

  2. インデックス パイプラインの移行が完了するまで待つ。

  3. 結合パイプラインの移行の場合は、集計パイプラインと同じ手順(17)を行う。

必要に応じて、Flipkart Google Cloud の両方のパイプラインを一時的に共存させて、重複する処理を受け入れることもできます。

Flipkart にとって Bigtable HBase より有利な点

Flipkart Bigtable に移行したことで、これまでにない効率性と柔軟性が得られ、何百万人ものお客様にシームレスなショッピング体験を提供できるようになりました。

Bigtable の自動スケーリング ポリシーにより、Flipkart はリソースの使用を最適化し、リソース効率と費用対効果を高めることができました。スケールアップまたはスケールダウンは、ユーザー インターフェースで 1 回クリックするだけで簡単に行うことができるため、リソース管理エクスペリエンスが向上しました。実際、Big Billion Day イベント中にプラットフォームを 4 倍にスケールアップしましたが、容量の問題やパフォーマンスへの影響はありませんでした。また、コンピューティングとストレージの分離も可能になり、負荷の再分散の速さが増し、パフォーマンスがさらに向上しました。

加えて、最小限のコード変更だけで、HBase から Bigtable へシームレスに移行できました。Bigtable では、互換性のある HBase シェル インターフェースを使用してユーザー エクスペリエンスが強化されており、プラットフォーム チームとユーザーチームのどちらも楽に操作できます。さらに、詳細な指標と Key Visualizer などのツールが用意されているため、効果的なトラブルシューティングが可能です。

Flipkart Bigtable への移行によって得られたもう一つの利点は、メンテナンス作業から解放されて、さまざまな運用の複雑さを解消し、開発者の時間を節約できたことです。たとえば、Bigtable ではクラスタ間のレプリケーションをより効率的に行うことができ、シームレスでトラブルのないエクスペリエンスが確保されます。また、堅牢なインスタンス レベルの分離が可能なため、一つのテーブルの問題がクラスタ全体に影響を及ぼすことがありません。

Flipkart の移行への取り組みは、最先端のテクノロジーによる変革の力を証明するものであり、データ マネジメントが効率的になるだけでなく、発想をもたらすものとなる未来への道を切り開きます。

HBase からの移行にご関心をお持ちですか?HBase から Bigtable にデータを移行する方法の詳細をご覧ください


この投稿に多大な貢献をしてくださった Flipkart データ プラットフォーム アーキテクト Robin Chugh 氏に深く感謝いたします。

ー Flipkart、データ プラットフォーム、SDE III Aditya Tiwari 氏

ー Google、AI ソリューション担当マネージャー Savitha Sethuram

投稿先