Expedia Group がベンダーへの支払いトランザクションを 1 日から数秒に短縮

Expedia Group は、Expedia、Vrbo、Hotels.com、Orbitz などの 20を超える予約サイトを擁しており、これを通して 70 か国以上からの旅行者が、宿泊施設やフライトなどを 80 を超える通貨で予約しています。グローバルプラットフォームビジネスとして、チームは、消費者とパートナーの両方の支払いに対応する必要があります。パートナーへの支払いの場合、Expedia は、ホテル、クルーズライン、航空会社など、その予約がプラットフォーム上で行われるプロバイダーとやり取りします。Expedia Collect モデルでは、Expedia は消費者から集金してからプロバイダーへの支払いを送金します。2019 年に、Expedia は、前年比 25％ 増の 76 億 USD のマーチャント型予約を処理しました。

しかし、Expedia の成長は、買掛金調整 (APRecon) セグメントで大損失を与え始めました。ボリュームが増えるにつれて、ジョブの実行に時間がかかるようになり、ユーザーに至るまでに遅延のカスケード効果が生じました。また、SQL Server の APRecon は、大量の手作業の介入が必要であり、同社のオペレーションスタッフに影響を与えていました。そして、オープンソースのデベロッパープラットフォームである .NET に構築された一部のサービスは、ベンダーロックインにつながり、サービスのデプロイを制限しました。

Expedia は、クラウド内の Java マイクロサービス主導のアーキテクチャに移行することを決定しました。「私たちは、AWS が提供する機能に合わせて簡単にスケーリングできるように、意図的に、マイクロサービス指向のアーキテクチャで新しいシステムを設計しました」と Expedia Group のソフトウェア開発担当シニアディレクターである Nirupama Jagarlamudi は説明します。SQL Server とクラウド製品の分析とコスト比較、さらにそれに続く SQL と PostgreSQL の分析を行った後に、同社は、Amazon Aurora PostgreSQL を選択しました。

Expedia は、Aurora PostgreSQL に段階的な移行を行うことを選択し、SQL Server から AWS に完全に移行する計画を立てています。初期段階では、まず、APRecon システムから宿泊事業を移行しました。それにより、SQL Server からの全ボリュームの 80％ を占める、Expedia の宿泊パートナーからのトランザクションが調整されます。データベースデベロッパーは、Flyway と呼ばれる新しいスキーマ移行ツールを使用して、SQL Server から Aurora PostgreSQL にスキーマをリファクタリングしました。「目的は、別のプロバイダーやサービスに切り替える必要がある場合に、縛られることなく簡単に切り替えられるように、サービス内のビジネスロジックを維持することです」とJagarlamudi は述べます。スキーマの更新などのデータベースの移行には、開発とテストに約 2 週間しかかかりませんでした。スキーマをリファクタリングした後に、チームは、.NET ソフトウェアフレームワークで構築されたコンポーネントをオープンソースの Linux と Java ベースのフレームワークである Spring Boot に移行しました。現在、Expedia には、Spring Boot スタック上に構築された 20 のマイクロサービスがあります。

マッチングおよび調整システム (MARS) と呼ばれる AWS の新しいシステムは、2020 年 5 月に稼働を開始しました。これは、Expedia のペイメントテクノロジースタックを統一するだけでなく、ベンダーのロックインを排除する AWS オープンソースサービスを使用します。Expedia は、フルマネージド型メッセージキューイングサービスである Amazon Simple Queue Service (Amazon SQS) を使用して、マイクロサービスを分離したりスケーリングしたりします。「Amazon SQS は、当社にとって、永続的な再試行機能を使ってプロセスに回復性を組み込むための簡単な方法です」と Jagarlamudi は言います。たとえば、Amazon SQS は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスである Amazon Simple Storage Service (Amazon S3) と連携して、ベンダーのリクエストを処理します。これにより、Expedia にイベント駆動型処理が提供されます。Amazon SQS は、組織に新しいベンダーのリクエストファイルを通知するため、チームはそれらを Amazon S3 からプルする必要がありません。

Expedia は、ユーザー、ベンダー、ビジネスインテリジェンス部門、およびオペレーションチームにほぼリアルタイムのデータを提供することができるようになりました。Expedia ポータルの運用ユーザーや外部のベンダーを含むすべての Expedia の支払いユーザーは、Amazon Elasticsearch Service (Amazon ES) を使用しています。これにより、ユーザーは、未払いの予約コストを効果的に検索、分析、可視化できます。予約が入ると、イベント駆動型処理は、データをオペレーションチームまたはベンダーに 1 秒未満で配信できます。以前のサーバーでのバッチ処理では 1 日以上かかっていたのに対し、上位 99 パーセンタイルのパフォーマンスは 2.6 秒です。その後、MARSは、その結果をユーザーと Expedia のビジネスインテリジェンス組織に伝えます。ユーザーは検索クラスターからデータを取得し、Expedia は、非常にスケーラブルで永続的なストリーミングサービスである Amazon Kinesis Data Streams を使用して、予約日、滞在時間、旅行者情報、ホテル情報、残金、決済履歴、チェーン予約など、各予約からのリアルタイムストリーミングデータを収集、処理、分析します。これらの重要なデータ属性により、Expedia のオペレーションチームは、問題を調査し、ベンダーの問い合わせをサポートできます。「ビジネスインテリジェンスとの統合は、極めて柔軟であり、このパターンにより、他の Expedia Group チームがこのデータを利用してビジネス機能を提供できる可能性があります」と Jagarlamudi は述べます。

マイクロサービス主導のアーキテクチャでは、MARS をスケールアップして、トラフィックでの突然の予測できないバーストに対処し、トラフィックが低下したらスケールダウンすることができます。たとえば、Expedia は、注文サービスをスケールアップして、15 か月の過去の予約の埋め戻しを調整し、2 週間にわたって1 秒あたり 200 件のトランザクションを維持することができました。その後、アクティビティの最後には、サービスをスケールダウンして、通常のトラフィックパターンに合わせました。また、Expedia は SQL Server (移行されていないレガシースタックに引き続き使用される) に伴うプロビジョニング、ストレージ、ライセンスの固定費を支払いますが、Aurora は、ライセンス料を取り除き、柔軟なコストとインフラストラクチャを提供します。Expedia は、データセンターの未使用容量にお金を費やす必要がなくなりました。「Aurora PostgreSQL では、使用した分のみ支払い、データの増加に応じて自動的に調整されます」と Jagarlamudi は話します。これにより、Expedia は COVID-19 のパンデミックの際に適応できました。また、フルマネージドの AWS システムを使用することは、Expedia がメンテナンスにかける時間がゼロであり、社内のデータベース管理者を必要としないことも意味します。

レガシーシステムを Aurora に移行し、他の AWS サービスを使用することで、Expedia は、データベースコストを削減し、ベンダーロックインを排除し、トラフィックのスパイクに合わせてスケーリングしました。その一方で、手作業による処理やデータベース管理の責任をチームから取り除きました。また、予約をほぼリアルタイムで処理するシステムも構築し、速いパフォーマンスをユーザーに提供し、ベンダーへの支払い操作の更新の高速化など、迅速なビジネスインサイトを可能にしました。