MakeMyTrip は Databricks を使用してミリ秒単位のパーソナライゼーションを大規模に実現する方法

リアルタイムでの大規模パーソナライゼーションの実現

旅行者がホテル、フライト、または体験を検索する際、1ミリ秒でも無駄にはできません。インド最大のオンライン旅行代理店であるMakeMyTripは、リアルタイムの速度と関連性で競争しています。その最も重要な機能の1つは「最後に検索した」ホテルです。ユーザーが検索バーをタップすると、システムとのインタラクションに基づいて、最近関心を持ったものがリアルタイムでパーソナライズされたリストとして表示されることが期待されます。

MakeMyTripの規模では、そのような体験を提供するには、消費者および法人旅行の両方の事業部門にサービスを提供する、数百万人の日次ユーザーを対象とした本番パイプラインでサブ秒レベルのレイテンシが必要です。Databricksのリアルタイムモード（RTM）—Apache Spark™ Structured Streamingの次世代実行エンジン—を実装することで、MakeMyTripはミリ秒レベルのレイテンシを達成し、コスト効率の高いインフラストラクチャを維持しながら、エンジニアリングの複雑さを軽減することに成功しました。

課題：アーキテクチャの断片化なしに超低レイテンシを実現する

MakeMyTripのデータチームは、すべての事業部門にわたる「最後に検索した」ホテルのワークフローでサブ秒レベルのレイテンシを必要としていました。彼らの規模では、わずか数百ミリ秒の遅延でもユーザー体験に摩擦を生じさせ、クリック率に直接影響します。

Apache Sparkのマイクロバッチモードは、チームが広範なチューニングを行っても打破できなかった固有のレイテンシ制限を導入し、一貫して1〜2秒のレイテンシを提供していましたが、これは要件には遅すぎました。

次に、約10個のストリーミングパイプラインでApache Flinkを評価しましたが、これはレイテンシ要件を解決しました。しかし、Apache Flinkをセカンドエンジンとして採用すると、長期的に重大な課題が生じる可能性がありました。

• アーキテクチャの断片化：リアルタイム処理とバッチ処理のために別々のエンジンを維持する
• 重複するビジネスロジック：ビジネスルールを2つのコードベースに実装および維持する必要がある
• 運用オーバーヘッドの増加：複数のパイプラインにわたる監視、デバッグ、ガバナンスの労力が倍増する
• 整合性のリスク：バッチ処理とリアルタイム処理の結果に差異が生じるリスク
• インフラストラクチャコスト：2つのエンジンを実行およびチューニングすると、コンピューティング費用とメンテナンスの負担が増加する

リアルタイムモードを採用した理由：単一のSparkスタックでミリ秒単位のレイテンシを実現

MakeMyTripはデュアルエンジンアーキテクチャを望まなかったため、Apache Flinkは長期的な選択肢ではありませんでした。チームは、スタックを断片化するのではなく、Apache Sparkがより高速になるのを待つという意図的なアーキテクチャ上の決定を下しました。
そのため、Apache Spark Structured StreamingがRTMを導入したとき、MakeMyTripはそれを採用した最初の顧客となりました。RTMにより、Apache Sparkでミリ秒レベルのレイテンシを達成し、別のエンジンを導入したりプラットフォームを分割したりすることなく、リアルタイム要件を満たすことができました。

2つのエンジンを維持することは、複雑さとバッチ計算とリアルタイム計算の間でロジックが乖離するリスクを倍増させることを意味します。私たちは、維持するエンジンを2つではなく、1つのソースオブトゥルース—1つのSparkベースのパイプライン

RTMは、マイクロバッチ実行に固有のレイテンシソースを排除するために連携する3つの主要な技術革新を通じて、継続的な低レイテンシ処理を提供します。

• 継続的なデータフロー：データは、定期的なチャンクに離散化されるのではなく、到着次第処理されます。
• パイプラインスケジューリング：ステージはブロックすることなく同時に実行され、下流タスクは上流ステージが完了するのを待たずにデータを即座に処理できます。
• ストリーミングシャッフル：データはタスク間で即座に渡され、従来のディスクベースのシャッフルのレイテンシボトルネックを回避します。

これらの革新により、Apache Sparkは、これまで特殊なエンジンでしか不可能だったミリ秒単位のパイプラインを実現できます。RTMの技術的基盤について詳しくは、ブログ「Breaking the Microbatch Barrier: The Architecture of Apache Spark Real-Time Mode」をお読みください。

アーキテクチャ：統合されたリアルタイムパイプライン

MakeMyTripのパイプラインは、高性能なパスに従います。

• 統合された取り込み：B2CおよびB2Bのクリックストリームトピックは、単一のストリームにマージされます。すべてのパーソナライゼーションロジック—エンリッチメント、ステートフルルックアップ、イベント処理—は、両方のユーザーセグメントに一貫して適用されます。
• RTM処理：Apache Sparkエンジンは、同時スケジューリングとストリーミングシャッフルを使用して、ミリ秒単位でイベントを処理します。
• ステートフルエンリッチメント：パイプラインは、Aerospikeで低レイテンシのルックアップを実行し、各ユーザーの「最後のN件」のホテルを取得します。
• インスタントサービング：結果はUIキャッシュ（Redis）にプッシュされ、アプリは50ミリ秒未満でパーソナライズされた結果を提供できるようになります。

RTMの設定：1行のコード変更

ストリーミングクエリでRTMを使用するために、ビジネスロジックを書き直したり、パイプラインを再構築したりする必要はありません。必要なコードの変更は、次のコードスニペットに示すように、トリガータイプをRealTimeTriggerに設定することだけです。

インフラストラクチャに関する考慮事項は1つだけです。クラスターのタスクスロットは、ソースおよびシャッフルステージ全体のアクティブなタスクの総数以上である必要があります。MakeMyTripのチームは、本番環境に移行する前に、十分な同時実行性を確保するために、Kafkaパーティション、シャッフルパーティション、およびパイプラインの複雑さを事前に分析しました。

RTMの共同開発：本番稼働に向けて

RTMの最初の採用者として、MakeMyTripはDatabricksエンジニアリングと直接協力して、パイプラインを本番稼働準備完了の状態にしました。いくつかの機能では、構築、チューニング、および検証のために両チーム間の積極的な協力が必要でした。

1. ストリームユニオン：B2CとB2Bを単一パイプラインにマージ
   MakeMyTripは、2つの別々のKafkaトピックストリーム—B2CコンシューマーのクリックストリームとB2B法人旅行—を単一のRTMパイプラインに統合する必要がありました。これにより、同じパーソナライゼーションロジックを両方のユーザーセグメントに一貫して適用できるようになります。Databricksエンジニアリングとの1か月にわたる緊密な協力の後、機能が構築されリリースされました。その結果、すべてのビジネスロジックが1か所に存在する単一のパイプラインが実現し、ユーザーセグメント間のロジックの乖離リスクがなくなりました。
2. タスク多重化：パーティション数を増やし、コア数を減らす
   RTMのデフォルトモデルでは、1つのKafkaパーティションに1つのスロット/コアが割り当てられます。MakeMyTripの本番環境では64個のパーティションがあるため、これは64個のスロット/コアに相当し、彼らの規模ではコストがかかりすぎます。これに対処するために、DatabricksチームはKafkaのMaxPartitionsオプションを導入しました。これにより、複数のパーティションを単一のコアで処理できるようになります。これにより、MakeMyTripはスループットを犠牲にすることなくインフラコストを削減するための手段を得ました。
3. パイプラインの強化：チェックポインティング、バックプレッシャー、およびフォールトトレランス
   チームは、チェックポイントの頻度と保持期間のチューニング、タイムアウトの処理、クリックストリーム量の急増時のバックプレッシャーの管理など、高スループット、低レイテンシワークロードに特有の運用上の課題に取り組みました。64個のKafkaパーティションへのスケーリング、バックプレッシャーの有効化、およびMaxRatePerPartitionを500イベントに制限することにより、チームはスループットと安定性を最適化しました。バッチ構成、パーティション分割、および再試行動作のこの反復的なチューニングを通じて、彼らは毎日数百万人のユーザーにサービスを提供する、安定した本番グレードのパイプラインに到達しました。

結果

RTMは、インスタントパーソナライゼーションと応答性の向上、クリック率で測定されるエンゲージメントの向上、および単一の統合エンジンの運用上のシンプルさを可能にしました。主要なメトリクスを以下に示します。

リアルタイムエンジンとしてのApache Spark

MakeMyTripのデプロイメントは、Spark上のRTMがリアルタイムアプリケーションに必要な非常に低いレイテンシを実現できることを証明しています。RTMは、使い慣れたSpark API上に構築されているため、バッチおよびリアルタイムパイプライン全体で同じビジネスロジックを使用できます。リアルタイム処理のために第2のプラットフォームや個別のコードベースを維持するオーバーヘッドはもう必要なく、1行のコードでSpark上のRTMを有効にするだけで済みます。

リアルタイムモードにより、複数のストリーミングエンジンを管理することなく、インフラストラクチャを圧縮し、リアルタイムエクスペリエンスを提供できるようになりました。AIエージェントの時代に進むにつれて、それらを効果的に誘導するには、データストリームからリアルタイムコンテキストを構築する必要があります。Spark RTMを実験して、エージェントが最善の意思決定を行うために必要な、最もリッチで最新のコンテキストを供給しています。” — Aditya Kumar, Associate Director of Engineering, MakeMyTrip

リアルタイムモードの開始方法

オンデマンドビデオで開始方法を確認するか、ドキュメントを参照して、リアルタイムモードの詳細をご確認ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事