QCon London 2026: Booking.comのAI進化の裏側：磨かれていない物語
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
Booking.comのシニアプリンシパルエンジニアであるJabez Eliezer Manuel氏が、QCon London 2026で同社の過去20年の進化とAI導入の課題について発表した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Booking.com のシニアプリンシパルエンジニアである Jabez Eliezer Manuel 氏は、QCon London 2026 で「Behind Booking.com's AI Evolution: The Unpolished Story」と題した講演を行い、過去 20 年間にわたり Booking.com がどのように進化し、AI を取り入れる過程でどのような課題に直面してきたかについて議論しました。
QCon London の第 20 回大会を称えるため、Manuel 氏は講演の冒頭で 2005 年の技術状況を紹介しました。特に、Motorola Razr V3 は人気のある携帯電話であり、Web 2.0 が台頭し始め、Booking.com も設立から 9 年目でした。
2005 年 2 月、Booking.com は最初の A/B テスト（A/B testing）実験を開始しました。当時、並行して 1000 件以上の実験を行い、累計で 15 万件の実験を遂行していました。しかし、成功率は 25% に満たないことが観察されました。Manuel 氏は、目標は正解を出すことではなく、素早く学ぶことにあったと述べています。これらの実験が最終的に、同社のデータ駆動型 DNA を構築しました。
Manuel 氏の講演は、データ管理（Data Management）、機械学習エンジニアリング（Machine Learning Engineering）、ドメインインテリジェンスの 3 つのレイヤーをカバーするものでした。
データ管理
Booking.com の初期の技術スタックは、Perl ライブラリと MySQL を基盤として構築されており、非同期レプリケーションと商用サポートを提供していました。2005 年にはマスターデータベースが 1 つだけでしたが、2020 年までに約 6800 のデータベースインスタンスに成長しました。同社の MySQL 設定はユニークで、専用ハードウェア、ストアドプロシージャ、ユーザー定義関数（UDF）、データベースビュー、キャッシュ層を持っていません。
マヌエル氏が「秘密のソース」と表現したものは、非揮発性メモリ Express (NVMe) ソリッドステートドライブに収まる小規模なデータベース（2TB 制限）で構成されていました。彼らは 350 マイクロ秒未満のポイントクエリを観測しました。
このモデルはデータが膨大になるまで成功を収めていましたが、その課題に対処するため、Booking.com は大規模な分散ストレージと処理のために Apache Hadoop を導入しました。2011 年までに、同社はそれぞれ約 6 万コアと 200 ペタバイトのハードディスク容量を備えたオンプレミス環境の Hadoop クラスターを 2 つ運用していました。
Hadoop は長年にわたり機械学習パイプラインを支えてきましたが、システムにひび割れが生じたことが判明しました。機械学習科学者の視点から見ると、これらのひび割れには、1 つの不良クエリがクラスターを詰まらせる「ノイジーな隣人」問題、GPU サポートの欠如、ピーク時の過負荷や障害を引き起こすキャパシティの問題が含まれていました。2018 年に Hadoop の廃止が決定されましたが、Hadoop から移行しアップグレードするプロセスには約 7 年を要しました。
Booking.com の移行戦略には 5 つのフェーズがありました：
- 全エコシステムのマッピング
- スコープ縮小のための利用状況分析
- Google Search PageRank アルゴリズムの適用
- ウェーブによる段階的移行
- Hadoop の段階的廃止
マヌエル氏は、成功の鍵は統合されたコマンドセンターにあったと述べています。
機械学習エンジニアリング
Booking.com の機械学習スタックの進化は、2005 年の Perl ライブラリと MySQL から始まり、2025 年にはエージェント型システムへと移行しました。その間には、Python を用いた Apache Oozie、MLlib を備えた Apache Spark、H2O.ai、ディープラーニング、そして生成 AI（GenAI）が導入されました。
Manuel は、2015 年が Booking.com にとって決定的な年であったと主張しました。その理由は、大規模なオンライン推論によるリアルタイム予測の実現と、トレーニングおよび推論のための特徴量エンジニアリングという 2 つの核心的課題を解決したからです。
2024 年現在、同社の機械学習推論プラットフォームは、480 以上の機械学習モデル、1 日あたり 4,000 億回の予測処理、そして 20 ミリ秒未満のレイテンシを誇っています。
ドメインインテリジェンス
Manuel は、4 つのドメイン固有の機械学習プラットフォームとそれぞれのユースケースについて議論しました。最初の 3 つは以下の通りです：トリッププランニング、スマートフィルター、レビュー要約などのユースケースを持つ生成 AI（GenAI）；ホテルの詳細コンテンツなどを含む画像およびレビュー分析、テキスト生成を担う機械学習コンテンツハブであるコンテンツインテリジェンス；顧客向けにパーソナライズされたコンテンツを表示するためのユースケースを持つレコメンデーションです。
パーソナライズされたリアルタイム順序付けのための 4 つ目のドメイン固有プラットフォームであるランキングは、より複雑な課題でした。Booking.com の 3 軸最適化の課題には、「選択と価値」、「露出と成長」、「効率性と収益」が含まれていました。
彼らの2005年のランキングアルゴリズムは、予約数や閲覧数といったパラメータと乱数関数を組み合わせた単純な関数でした。その後、キャンセル率、距離に基づくランキング、部屋の空き状況、ホテルの評価といった要素を取り入れてアルゴリズムの進化を試みました。しかし、機械学習を用いてランキングアルゴリズムを置き換えようとした際、インフラストラクチャの制約により、マヌエルが指摘したようにそのアルゴリズムは「無敵」であることが判明しました。
彼らの実験は通常2〜4週間行われましたが、改善点を模索していました。A/Bテストの実験手法を適応させ、インターリービング（interleaving）という技術を導入しました。これは各実験セットの50%を実質的に1つの実験に織り交ぜる手法です。これにより、より少ないトラフィックで多様なバリアントをテストできるようになりました。そこで、インターリービングによる事前選定を行い、A/Bテストで検証するという方針が決定されました。
マヌエルは、ドメイン固有のプラットフォームがオーケストレーション層のために統合された現状について述べてプレゼンテーションを終えました。
著者紹介
マイケル・レッドリッチ（Michael Redlich）氏は、過去25年にわたりJavaコミュニティで活動しています。2001年にはガーデンステイトJavaユーザーグループ（旧ACGNJ Java Users Group）を設立し、現在も継続して運営されています。
2016 年以来、マイクは InfoQ の Java コミュニティニュース編集者を務めており、その貢献には月次ニュース記事、技術文書の作成、技術レビューが含まれます。彼は Oracle Code One、エンタープライズ向け新興技術カンファレンス、トレントン・コンピュータフェスティバル (TCF)、TCF IT プロフェッショナル会議、および多数の Java ユーザーグループなどで登壇してきました。マイクは Jakarta NoSQL および Jakarta Data の仕様におけるコミッターを務め、Jakarta EE アンバサダーのリーダーシップ評議会にも参加しています。彼は 2023 年 4 月に Java チャンピオンに選出されました。
33 年半にわたる勤務の後、マイクはニュージャージー州クリントンにあるエクソンモービル・テクノロジー&エンジニアリングを最近退職しました。そこではカスタムの科学実験室用アプリケーションや Web アプリケーションの開発における経験があります。また、Ai-Logix, Inc.（現在の AudioCodes）でテクニカルサポートエンジニアとして勤務した経験もあり、顧客向けに技術サポートを提供し、電話通話アプリケーションを開発していました。
もっと見る 表示を隠す
原文を表示
Jabez Eliezer Manuel, senior principal engineer at Booking.com, presented Behind Booking.com's AI Evolution: the Unpolished Story at QCon London 2026, where he discussed how Booking.com has evolved over the past 20 years and the challenges they faced on their journey to incorporate AI.
Paying tribute to the 20th edition of QCon London, Manuel kicked off his presentation with a look at technology from 2005. In particular, the Motorola Razr V3 was a popular cell phone, Web 2.0 had started to emerge, and Booking.com was nine years old.
In February 2005, Booking.com started its initial set of A/B testing experiments, for which it had more than 1000 experiments in parallel and 150,000 total experiments. However, they observed a less than 25% success rate. Manuel stated that the goal wasn't to be right; it was to learn fast. These experiments ultimately built their Data-Driven DNA.
Manuel's presentation covered three layers: Data Management, Machine Learning Engineering, and Domain Intelligence.
Data Management
Booking.com's original tech stack was built on Perl libraries and MySQL, which offered asynchronous replication and commercial support. They had only one master database in 2005 that has grown into approximately 6800 database instances in 2020. Their MySQL setup is also unique because they don't have specialized hardware, stored procedures, Universal Disk Formats (UDFs), database views, or a cache layer.
Their "secret sauce," as Manuel characterized it, consisted of smaller databases (with a 2TB limit) that fit in Non-Volatile Memory Express (NVMe) solid state drives. They observed point queries that were less than 350 microseconds.
This model was successful until their data grew too large. To remedy this, Booking.com added Apache Hadoop for distributed storage and processing at scale. By 2011, they had two on-premise Hadoop clusters that each contained approximately 60,000 cores and 200 PB of hard disk space.
Hadoop had powered their machine learning pipeline for many years until they discovered cracks in the system. From a machine learning scientist's perspective, these cracks included: noisy neighbors where one bad query clogged a cluster; no GPU support; and capacity issues that caused overloads and outages at peak times. By 2018, it was decided to sunset Hadoop, but the process to upgrade and migrate away from Hadoop took approximately seven years.
There were five phases in Booking.com's migration strategy:
Map their entire ecosystem
Analyze usage to reduce scope
Apply the Google Search PageRank algorithm
Migrate in waves
Phase out Hadoop
Manuel stated that the key to their success was a unified command center.
Machine Learning Engineering
The evolution of Booking.com's machine learning stack started with Perl libraries and MySQL in 2005 and moved to agentic systems in 2025. In between, there was Apache Oozie with Python, Apache Spark with MLlib, H2O.ai, deep learning, and GenAI.
Manuel maintained that 2015 was a pivotal year for Booking.com as they solved two core problems: real-time predictions using online inference at scale, and feature engineering for training and inference.
As of 2024, their current machine learning inference platform has more than 480 machine learning models, 400 billion predictions per day, and a latency of less than 20 milliseconds.
Domain Intelligence
Manuel discussed four domain-specific machine learning platforms and their respective use cases. The first three are: GenAI with use cases that include trip planning, smart filters, and review summaries; Content Intelligence, a machine learning content hub for image and review analyses and text generation, includes use cases such as detailed content for hotels; and Recommendations with use cases for displaying personalized content for their customers.
Ranking, the fourth domain-specific machine learning platform for personalized real-time ordering, was a more complex task. Booking.com's three-way optimization challenge included: choice and value; exposure and growth; and efficiency and revenue.
Their 2005 ranking formula was simply a function that included parameters such as bookings and the number of views, plus a random number function. They tried to evolve their formula with factors such as cancellations, distance-based ranking, room availability, and hotel impressions. As they attempted to replace the ranking formula with machine learning, it was discovered that their formula was "undefeatable," as characterized by Manuel, due to infrastructure limitations.
Their experiments typically ran for two to four weeks, but they looked for improvement. They adapted their A/B testing experiments to include a technique of interleaving, where 50% of each set of experiments was essentially interwoven into a single experiment. This allowed for more variants with less traffic. So it was decided to preselect with interleaving and validate with A/B testing.
Manuel concluded his presentation with how the domain-specific platforms are now unified for their orchestration layer.
About the Author
Michael Redlich
Michael Redlich has been an active member within the Java community for the past 25 years. He founded the Garden State Java User Group (formerly the ACGNJ Java Users Group) in 2001 that remains in continuous operation.
Since 2016, Mike has served as a Java community news editor for InfoQ where his contributions include monthly news items, technical writing and technical reviews. He has presented at venues such as Oracle Code One, Emerging Technologies for the Enterprise, Trenton Computer Festival (TCF), TCF IT Professional Conference, and numerous Java User Groups. Mike serves as a committer on the Jakarta NoSQL and Jakarta Data specifications and participates on the leadership council of the Jakarta EE Ambassadors. He was named a Java Champion in April 2023.
With 33-1/2 years service, Mike recently retired from ExxonMobil Technology & Engineering in Clinton, New Jersey with experience in developing custom scientific laboratory and web applications. He also has experience as a Technical Support Engineer at Ai-Logix, Inc. (now AudioCodes) where he provided technical support and developed telephony applications for customers.
Show moreShow less
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み