Ctrip ホテル検索エンジン AWS クラウド実践

著者について: Gong Xian、Ctrip のシニア バックエンド開発エンジニア。 Ctrip のシニア バックエンド開発エキスパート、Spike 氏。

Ctrip の国際ビジネスが急速に進展するにつれ、ユーザー エクスペリエンスの重要な部分である検索エンジンをクラウドに移行することが必須となりました。この記事では主に、ホテル検索エンジンを AWS に移行するための調査と実践のプロセスを紹介します。内容は、ゲートウェイにリクエストを送信する APP から、イントラネット上の複雑なマイクロサービス、そして最終的にそれが依存するさまざまな永続ストレージに至るまで、HTTP リクエストの完全なリンク処理プロセスを網羅します。

1. マイクロサービスアーキテクチャがもたらす課題

今回クラウド化される事業は売れ筋の事業であり、ユーザーの直感的な体験は、TRIP APPのホテル検索ページでホテルステイケーションのお得な情報をクリックすることです。

Ctrip は主流のマイクロサービス アーキテクチャを採用しています。一見単純な検索機能は、実際には BAT 呼び出しチェーンの監視を通じて何百ものアプリケーションに関係します。 BAT は、Ctrip のオープンソース CAT の改良版です。次の図は、BAT で人気のあるアプリケーションの呼び出しチェーン全体を示しています。(この関係を CAT で整理しようとすると、非常に時間がかかります。CAT の UI では、アプリケーションが依存する下流の第 1 レベルのアプリケーションしか表示できないため、ユーザーは手動で 1 つずつトラバースする必要があります)

開発コストの観点から見ても、ハードウェア コストの観点から見ても、依存するすべてのアプリケーションをそのままクラウドに移行することは合理的ではありません。これは、移行中にマイクロサービス アーキテクチャが直面する課題も反映しています。ポータル アプリケーションは数百のダウンストリーム アプリケーションに依存していますが、通常、アプリケーションには複数の API が含まれます。しかし、調査の結果、この人気ビジネスでは実際には 1 つの API しか使用されていないことが判明しました。では、移行を実装するために 1 つの API のみをデプロイすることは可能ですか?

API ディメンションでの依存関係クエリをサポートしてくれた BAT に感謝します (CAT はアプリケーション ディメンションのみをサポートします)。調査の結果、人気のある API に実際に依存しているアプリケーションの数はわずか 8 つであることが判明し、トンネルの出口に光が見えてきました。

次のステップは展開です。数年前に AWS を使用していたときに、コマンドラインを使用して公開したことを覚えています。当時、私は権限の問題を懸念していました。間違ったコマンドを入力すると、クラスター全体がクラッシュする可能性があります。同時に、各クラウドベンダーは独自のリリースシステムを持っており、学習コストは無視できません。幸いなことに、Ctrip 独自のオープンソース パブリッシング システム TARS は、AWS や Alibaba などのクラウド リリースに接続されています。現在、どのクラウドを展開する場合でも、統一された UI インターフェース セットを使用しています。

9 つのアプリケーションを正常に導入した後、新たな問題が発生しました。

1) 現在、Ctrip GATEWAY はサービスディメンションに基づいてトラフィックを転送することしかできず、 API に基づいて転送することはできません。つまり、AWS の IDCA から GATEWAY にトラフィックが入る場合、人気のある API のみを IDC A に転送し、残りの API を IDC B に転送することはサポートできません。

2) アプリケーション自体は、起動時に 12 を超える Redis、MySQL、およびその他のサービスに依存します。しかし、セキュリティ上の問題により、AWS IDC 間のストレージは相互に直接アクセスすることができず、最終的にはアプリケーションの起動に失敗します。もちろん、各フレームワーク コンポーネントをスケジュールして、点火の動的構成をサポートし、現在の IDC 構成に基づいて、どのコンポーネントを点火する必要があるかを判断することもできます。しかし、これによってフレームワークとアプリケーション自体の両方が煩雑になることは間違いなく、その合理性については議論する価値があります。逆に、これらのストレージ依存関係が各 IDC に繰り返し展開されると、必然的にハードウェアと開発コストの無駄につながります。

上記 2 つの問題により、コード リポジトリを維持し、複数の IDC を同時にリリースするという本来のアーキテクチャは実現不可能になりました。人気のある API を別のアプリケーションに抽出することは可能ですか?抽出後、コアビジネス コードが複数のアプリケーションと複数のウェアハウスに分散されることを想像してください。各 IDC が独立したコードセットを持つことは可能ですか?しかし、これにより、将来の日常的な開発とメンテナンスにおいて重複やエラーが発生しやすくなります。

そこで、コアビジネスロジックを別の JAR に抽出し、IDC ごとに個別のコードリポジトリを作成しようとしました。新しく作成されたアプリケーションは、ビジネス JAR に内部的にアクセスする Web サービス シェルにすぎません。このようにして、コードが重複することはなくなり、アプリケーションの責任が抽象化され、分離されます。

しかし、これは開発に問題をもたらします。新しい機能が開発されるたびに、まずビジネス jar リポジトリに書き込む必要があり、次にデバッグのために Web サービス アプリケーションを通じて最新の jar を参照する必要があります。コードを変更するたびに、jar を再生成して中央の Maven リポジトリにアップロードし、POM 参照バージョンをアップグレードしてローカルにダウンロードする必要があり、必然的に開発効率が低下します。幸いなことに、Ctrip の現在の単体テスト率は 80% 以上が必須であるため、これにより、Web サービスとの統合テストを実行する際の開発コストが削減され、より高品質の単体テストの作成の開発が促進されます。解決策は完璧ではありませんが、トレードオフとなります。

2. クラウド上のデータの永続性

新しいアプリケーションが抽出された後、イグニッション内の無関係な Redis と MySQL の依存関係は回避されましたが、一般的な API 自体が依存している 2 つの Redis と 1 つの MySQL は回避されませんでした。解決策の 1 つは、IDC 間に専用回線を直接構築することです。通常、Redis は数ミリ秒で応答しますが、ネットワークの遅延は不安定で、極端な場合には数百ミリ秒にも及ぶことがあります。したがって、専用回線のネットワーク遅延は、リアルタイム サービスには許容できません。一歩引いて考えてみると、たとえ一部の事業がネットワークの遅延を許容できたとしても、Ctrip事業全体がこの方式でデータにアクセスすると、この専用回線が将来ボトルネックになるだろう。

そこで、人気製品が依存している Redis と MySQL を複数の AWS IDC にデプロイしてみました。導入プロセス中に、Redis を Ctrip が独自に開発した永続 KV ストレージ Trocks に置き換え、ハードウェア コストの削減という目標を達成しました。

アプリケーションは正常に起動しましたが、次の問題はデータの同期です。同期は必要でしょうか?同期するにはどうすればいいですか?一方向のレプリケーションですか?双方向レプリケーション?遅延許容範囲はどのくらいですか?

人気商品は 2 つの Redis に依存しています。 1 つの Redis が http リクエストに基づいてキャッシュを担当するため、同期の必要がなく、フレームワーク コードを変更する必要もありません。デフォルトでは、IDC ローカル コンピュータ ルームの Redis にアクセスします。つまり、IDC A のアプリケーションは IDC A の Redis インスタンスを読み書きし、IDC B のアプリケーションは IDC B の Redis インスタンスを読み書きします。

他に、Redis と MySQL が検索エンジンで使用されています。ビジネス特性は読み取り専用であり、書き込み専用ではありません。他のデータ ソースからの大量のデータがリアルタイムで同期されるため、一方向の同期のみが必要となり、レイテンシ要件は低くなります。最終的なストレージ構造は次のようになります。

Redis の一方向レプリケーション分散では、Ctrip が独自に開発したオープンソースの XPipe が使用されます。

MySQL の一方向レプリケーション分散技術は、Ctrip が独自に開発した DRC を使用します。私たちのプロジェクトでは一方向のレプリケーション機能のみを使用しましたが、実際には双方向のレプリケーションもサポートされています。

すべてのデプロイメントが完了すると、アプリケーションは起動して正常に動作できるようになります。レプリケーションと配信の遅延は通常数百ミリ秒ですが、最大でも数秒程度に抑えられる可能性があり、これは予想どおりです。

3. クラウド上でのファイルの保存と共有

人気のある API のコア検索エンジンは、ローカル ファイルの読み取りと書き込みのテクノロジを使用します。アプリケーションはこれらのファイルを IDC イントラネットで転送および共有しますが、これらのファイルの中には最大 10G の非常に大きなファイルもあります。異なるコンピューター室をどのように共有できますか? 1 つの解決策は、これらのアプリケーションを各 AWS IDC に 1 回ずつデプロイすることです。しかし、移行後、依存データベースを再度デプロイする必要があるのでしょうか。あるいは、データベースの背後にある巨大な Hadoop クラスターを再度デプロイする必要があるのでしょうか。

KISS 原則に基づいて、まず AWS IDC A のサービスが専用回線を介して IDC B のファイルに直接アクセスできるようにします。しかし、ネットワーク上の不明な理由により、ファイルは転送できるものの、成功しません。しかし、たとえ成功したとしても、多くの隠れた危険が伴います。例えば、このような大きなファイルは、専用回線の帯域を瞬時に長時間占有してしまい、本当にリアルタイム性が求められる通信は滞ってブロックされてしまいます。最後に、AWS S3 サービスを介して異なる IDC 間でファイルを共有しようとしましたが、これは成功し、パフォーマンスはビジネス要件を満たしました。

ソリューション選択の観点から、AWS S3 の使用シナリオは議論する価値があります。一般的に、クラウド製品を使用する場合、特定のクラウドの特定の製品に過度に依存するという懸念があります。後から別のクラウドに切り替える場合、移行コストが高額になります。たとえば、AWS の S3 API は次のようにカスタマイズされています。

Ctrip のような企業が複数のクラウドを同時に使用する場合でも、複数のコード セットのメンテナンス コストが発生します。現在の解決策は、さまざまなクラウド ファイル ストレージ API と互換性のある JAR を社内で統合することです。使用時には、該当するクラウドのセキュリティ暗号文を設定するだけで済みます。

IV.結論

Ctrip の技術プラットフォーム部門がクラウド移行の初期段階で行った大量のインフラストラクチャ研究開発の恩恵により、ビジネス部門がクラウドに移行するハードルが低くなりました。人気のあるビジネスをクラウドに移行することは、氷山の一角にすぎません。海外に進出する企業が増えるにつれ、さらなる課題が待ち受けています。この記事が、クラウド移行計画を持つチームのアイデアを広げるきっかけになれば幸いです。

クラウドへの移行を経験した後は、新しいアーキテクチャを設計するたびに、ためらうことなくいくつかの質問を自問することになります。このアーキテクチャ設計は、将来クラウドに移行する必要があるでしょうか?クラウドに移行するのは便利ですか?クラウド間での展開は便利ですか?