Expedia, Inc. は一流のオンライン旅行会社で、レジャー旅行とビジネス旅行の両方を世界中の顧客に提供しています。Expedia ブランドのポートフォリオは多岐にわたり、世界最大級のフルサービスオンライン旅行代理店としてそのサイトが 20 カ国以上向けにローカライズされている Expedia.com、60 カ国以上にサイトを持つホテル特化サイト Hotels.com、60 カ国以上にサイトを持つホテル特化サイト Hotwire.com、さらにその他の旅行ブランドを展開しています。

同社では、利用者に対してはレジャー旅行とビジネス旅行という価値を実現し、旅行提供側に対しては需要の増加とダイレクト予約を促進し、広告業者には Expedia Media Solutions を通じて、マーケット内の旅行利用者という高付加価値の対象者に達する機会を提供しています。Expedia はまた、世界の一流航空会社やホテルの予約、トップコンシューマーブランド、トラフィック数の多いウェブサイト、さらに数千のアクティブなアフィリエイトを Expedia Affiliate Network によって強化しています。

Expedia は AWS クラウドを利用して旅行ポータルを数か月で立ち上げる (3:25)

expedia-thumnail

Expedia は、顧客の優れたエクスペリエンスを創造するために、継続的なイノベーション、テクノロジー、およびプラットフォームの向上に力を入れてきました。Expedia Worldwide Engineering (EWE) は Expedia ブランド傘下のウェブサイトすべてをサポートする組織です。Expedia は、2010 年に Expedia Suggest Service (ESS) を開始するときに、アマゾン ウェブ サービス(AWS)の利用を開始しました。ESS は顧客が旅行、検索、ロケーションの情報を正しく入力するのを補助する、先読み型のサジェストサービスです。同社が測定した結果によれば、エラーページはサイトの利用をあきらめる主な理由です。Expedia では、世界中のユーザーが検索しているものを、すばやく、エラーなしで見つけてもらいたいと考えました。当時、Expedia は自社のサービスすべてをアリゾナ州 Chandler のデータセンターで運用していました。エンジニアリングチームは、高速で応答性に優れたサービスを最小限のネットワークレイテンシーで顧客に提供するためには、顧客に物理的に近い場所で ESS を運用する必要があることに気が付きました。

Expedia では、オンプレミスの仮想化ソリューションや他のクラウドプロバイダーも検討しましたが、最終的にアマゾン ウェブ サービス(AWS)を選んだ理由は、それがアジアパシフィックリージョンの顧客をサポートするためのグローバルなインフラストラクチャを有していた唯一のサービスだったからです。「アーキテクチャの観点から見ると、インフラストラクチャ、自動化、それに顧客から近いことが重要な要素でした」とテクノロジーディレクターの Murari Gopalan 氏は語ります。「AWS なしには解決できませんでした。」

「AWS を使うことで、3 か月で ESS サービスを構築し、提供できました」とプリンシパルアーキテクトの Magesh Chandramouli 氏は言います。ESS は、顧客の位置に基づいたアルゴリズムを使用し、これまでの顧客たちから得られたショッピングと予約のデータを集約して、顧客が入力を開始したときにサジェスチョンを表示します。例えば、シアトルに住むある顧客が飛行機の予約をするときに sea と入力すると、同サービスは Seattle、SeaTac、およびその他の関連目的地を表示します。

Expedia では ESS インスタンスを最初にアジアパシフィック(シンガポール)リージョンに設置し、すぐにサービスを米国西部(北カリフォルニア)リージョンと欧州(アイルランド)リージョンにレプリケートしました。Expedia のエンジニアは、当初 Apache Lucene やその他のオープンソースツールによってサービスを構築していましたが、最終的にはインデックスとクエリを保存する強力なツールを自社で開発しました。

ESS を AWS でデプロイしたことで、Expedia ではアジアパシフィックリージョンや欧州の顧客に対するサービスを改善できました。「最大の問題はレイテンシーでした」と Chandramouli 氏は言います。「AWS を使用して、平均ネットワークレイテンシーを 700 ミリ秒から 50 ミリ秒未満まで低下させました。」図 1 に AWS で運用されている ESS 先読みサジェストサービスを示します。

Expedia_arch

図 1. AWS での Expedia Suggest Service アーキテクチャ

2011 年までに、Expedia は Global Deals Engine (GDE) などの非常に重要で、大きなボリュームを持ついくつかのアプリケーションを AWS で運用していました。GDE はプランをオンラインパートナーに送り、パートナーは Expedia の API と製品インベントリツールを使用してカスタムウェブサイトやアプリケーションを作成することができます。

Expedia は、Amazon Elastic Map Reduce (Amazon EMR) を使用して、Expedia サイトのグローバルネットワークから来るデータのストリームを分析し、処理するための Hadoop クラスターをプロビジョニングしています。ストリームには主にクリックストリーム、ユーザーの操作、サプライデータが含まれ、データは Amazon Simple Storage Service (Amazon S3) に保存されます。Expedia では、1 秒間当たり約 240 のリクエストを処理しています。「AWS のメリットは、従来のデータセンターのようにピーク時の負荷に合わせたキャパシティーを維持する必要がなく、Auto Scaling を使用して要求される負荷に合わせられることです」と Gopalan 氏はコメントします。Expedia では AWS CloudFormation を Chef で使用し、フロントエンドとバックエンドのスタック全体を Amazon Virtual Private Cloud (Amazon VPC) 環境にデプロイしています。アプリケーションに弾力性を持たせるため、Expedia はマルチリージョン、マルチアベイラビリティーゾーンのアーキテクチャを専用 DNS サービスとともに利用しています。AWS での GDE サービスのアーキテクチャを図 2 に示します。

expedia_arch_diag_2

図 2. AWS での Expedia の Global Deals Engine アーキテクチャ

Expedia は、インフラストラクチャについて心配することなく、GDE やその他のボリュームの大きなアプリケーションを管理する新しいクラスターを追加できています。「もし同じアプリケーションを自社のオンプレミスデータセンターでホストしていたら、このレベルの CPU 効率は得られなかったでしょう」と Chandramouli 氏は言います。「あるアプリケーションが 1 秒間当たり 3,000 リクエストを処理するとすれば、ラックの過熱を防ぐため、物理サーバーは 30 パーセントぐらいのキャパシティーで動作するよう設定することになったでしょう。AWS では、いつでもスケールアウトできるので、CPU 利用率を 70 パーセント近くまで押し上げられます。基本的に、AWS での運用によってデータ処理の CPU 利用効率 230 パーセントが可能になっています。重要なアプリケーションを AWS で運用するのは、インフラストラクチャを効率的にスケーリングし、使用することができるからです。」

GDE の管理を簡素化するため、Expedia では AWS Identity and Access Management (AWS IAM) および AWS Security Token Service (AWS STS) を利用した ID フェデレーションブローカーを開発しました。フェデレーションブローカーによって、システム管理者と開発者は既存の Windows Active Directory (AD) アカウントを使って AWS マネジメントコンソール にシングルサインオン(SSO)できます。これにより、Expedia では、IAM ユーザーを作成してユーザー ID を保存するために複数の環境をメンテナンスする必要がなくなりました。フェデレーションブローカーのユーザーが既存の Active Directory 認証情報を使用して Windows コンピュータにサインインし、フェデレーションブローカーをブラウズすると、透過的に AWS マネジメントコンソールにログインできます。こうすることで、Expedia では既存のディレクトリ内部でパスワードと権限の管理を強化し、グループポリシーやその他のガバナンスルールを実施することが可能になっています。さらに、従業員が退社した場合やロールが変更された場合、Expedia では AWS 内部で変更を加える代わりに Active Directory に変更を加え、これだけで AWS のユーザー権限の廃止や変更が行えます。

ESS と GDE サービスで得られた成功はその他の Expedia 開発チームの興味を引くことになり、地域的なプロジェクトに AWS が使われるようになりました。2012 年の時点で、Expedia は米国東部(バージニア北部)、欧州(アイルランド)、アジアパシフィック(シンガポール)、アジアパシフィック(東京)、米国西部(北カリフォルニア)の各リージョンでアプリケーションをホストしています。Expedia Worldwide Engineering ではこれらのプロジェクトからベストプラクティスを選び出し、全リージョンでの標準化されたデプロイメント設定を作成しました。プリンシパルソフトウェアエンジニアの Jun-Dai Bates-Kobashigawa 氏はこう説明します。「当社では Chef を使って Amazon Elastic Compute Cloud (Amazon EC2) サーバーの設定を自動化しています。数分あれば、どの AWS イメージでも、Chef に保存してあるスクリプトを使ってマシンを構築し、あるチーム向けにカスタマイズされたインスタンスをスピンアップできるのです。」

このチームはすべての AWS アカウントを 1 つの AWS アカウントに統合し、各リージョンに 1 つずつ Amazon VPC ネットワークをプロビジョニングしました。これにより、各リージョンは独立したファイアウォール、アプリケーション層、データベース層を有する、分離されたインフラストラクチャを持つことが可能になります。Expedia では、Amazon EC2 セキュリティグループファイアウォール設定を適用してアプリケーションとサービスを保護しています。Amazon VPC は Expedia のラボと実稼働環境に完全に統合されています。「開発者にとって、Amazon VPC の操作感は完全にシームレスです」と Bates-Kobashigawa 氏は語ります。「開発者は認証用に同じ Active Directory サービスを使用します。ログオンしているサーバーの一部が AWS で運用されていることにさえ気付かないかもしれません。独自のサブネットと複数レイヤーを持つ物理インフラストラクチャのような感じです。VPN を使用してオンプレミスインフラストラクチャに接続するのも簡単です。」

Expedia では、ブルー/グリーンデプロイメントアプローチを使用して AWS に並列的な実稼働環境を作成し、継続的デプロイと市場投入時間の短縮を実現しています。「成功を測る基準の 1 つは、チーム内でデプロイする時間の短縮です」と Gopalan 氏は言います。「このメソッドを使って、従来のデプロイメントに比べ相当スピーディーにアプリケーションをリリースしています。さらに、ロールバックのコストがゼロに減るということは、大胆にデプロイできるということです。」Expedia の AWS での標準デプロイメントアーキテクチャを図 3 に示します。

expedia-blue-green-deployment-arch-diagram

図 3. Expedia の AWS での標準デプロイメントアーキテクチャ

Expedia は、アプリケーション開発スピードの向上、大規模データ処理向けのスケーリング、問題のトラブルシューティングの迅速化のために AWS を使用しています。AWS を使用した標準開発モデルの構築によって、開発チームは新しいプロジェクト用のインフラストラクチャをすばやく作成できます。重要なアプリケーションをさまざまなリージョンにある複数のアベイラビリティゾーンで運用することにより、データを常時利用することができ、災害対策ともなっています。Expedia Worldwide Engineering は、モニタリングインフラストラクチャをすべてのリージョンに構築し、単一のインフラストラクチャに移行することに取り組んでいます。

一般に、AWS では開発と運用に対するチームのコントロールが向上します。Expedia がクライアントロギングサービスの変換で問題を経験したとき、エンジニアは 2 日間以内に重大な問題を追跡し、特定することができました。Expedia では、もしそのサービスが物理環境で運用されていたとしたら、スクリプトのエラーを見つけるまでに 6 週間かかっただろうと推測しています。

Expedia は以前、最大負荷シナリオに合わせてデータセンターにサーバーをプロビジョニングしなければなりませんでした。「自社のオンサイト施設を使ってアプリケーションをデプロイするには、物理的なインフラストラクチャについても考えなければなりません」と Bates-Kobashigawa 氏は説明します。「100 のラックが運用されているとすれば、そこから 20 のラックを取り分けて新しいコードを適用する必要があったでしょう。AWS を使えば、キャパシティーを取り分ける必要はありません。新しいキャパシティーを追加して、トラフィックをそこに送るだけのことです。」

Chandramouli 氏はこう言います。「私が開発者だったころは、アプリケーションに一定のめどがつくまで、アーキテクチャに投資しようとは思いませんでした。事前にプランを立て、概念を実証し、利害関係者に説明しなければならなかったのです。AWS を使えば、スループット制限や CPU キャパシティーに縛られることがありません。私が AWS のことを考えたときに最初に浮かぶ単語は "自由" ですね。」

AWS がエンタープライズの IT ニーズをどのように満たすのか、詳しくはエンタープライズ企業と AWS のページ http://aws.amazon.com/enterprise-it/ にアクセスしてください。