Expedia Group が AWS に全てを移行することで俊敏性と回復性を向上

Expedia Group は AWS に全てを移行し、今後 2〜3 年以内にミッションクリティカルなアプリの 80％ をオンプレミスのデータセンターからクラウドに移行する計画です。AWS を使用することで、Expedia Group の回復性が向上しました。Expedia Group の開発者が数百万 USD を削減しながら、迅速なイノベーションを達成した方法をご覧ください。Expedia Group は旗艦サイトである Expedia.com および世界中の約 200 件の旅行予約サイトで、旅行予約サービスを提供しています。

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

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

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

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

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

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

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

Expedia Group はインフラストラクチャについて心配することなく、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 Group では、IAM ユーザーを作成してユーザー ID を保存するために複数の環境をメンテナンスする必要がなくなりました。フェデレーションブローカーのユーザーが既存の Active Directory 認証情報を使用して Windows コンピュータにサインインし、フェデレーションブローカーをブラウズすると、透過的に AWS マネジメントコンソールにログインできます。これで、Expedia Group では既存のディレクトリ内部でパスワードとアクセス許可の管理を強化し、グループポリシーやその他のガバナンスルールを実施することが可能になります。さらに、従業員が退社した場合やロールが変更された場合、Expedia Group では AWS 内部で変更を加える代わりに Active Directory に変更を加え、これだけで AWS のユーザー権限の廃止や変更が行えます。

ESS と GDE サービスで得られた成功はその他の Expedia Group 開発チームの興味を引くことになり、地域的なプロジェクトに 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 Group では、Amazon EC2 セキュリティグループファイアウォール設定を適用して、アプリケーションとサービスを保護しています。Amazon VPC は Expedia Group のラボと本番環境に完全に統合されています。「開発者にとって、Amazon VPC の操作感は完全にシームレスです」と Bates-Kobashigawa 氏は言います。「開発者は認証用に同じ Active Directory サービスを使用します。ログオンしているサーバーの一部が AWS で運用されていることにさえ気付かないかもしれません。独自のサブネットと複数レイヤーを持つ物理インフラストラクチャのような感じです。VPN を使用してオンプレミスインフラストラクチャに接続するのも簡単です。」

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

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

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

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

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

AWS がエンタープライズ IT のニーズをどのように満たすのかについて詳しくは、エンタープライズクラウドコンピューティングの詳細ページをご参照ください。