Yandex.Market 検索の仕組みとサーバーの XNUMX つが失敗した場合に何が起こるか

こんにちは、私の名前はエフゲニーです。 私は Yandex.Market 検索インフラストラクチャで働いています。 私は Habr コミュニティに市場のインナーキッチンについて伝えたいと思っています - そして伝えたいことがたくさんあります。 まず最初に、マーケット検索の仕組み、プロセス、アーキテクチャについて説明します。 緊急事態にどう対処するか: 100 つのサーバーがダウンしたらどうなるでしょうか? このようなサーバーが XNUMX 台ある場合はどうなるでしょうか?

また、一度に多数のサーバーに新しい機能を実装する方法についても学習します。 そして、ユーザーに迷惑をかけずに、複雑なサービスを本番環境で直接テストする方法についても説明します。 一般に、誰もが楽しい時間を過ごせるようにマーケット検索がどのように機能するか。

私たちについて少し: 私たちが解決する問題

テキストを入力したり、パラメータで製品を検索したり、さまざまな店舗で価格を比較したりすると、すべてのリクエストが検索サービスに送信されます。 検索は市場最大のサービスです。

当社は、market.yandex.ru、beru.ru、Supercheck サービス、Yandex.Advisor、モバイル アプリケーションなどのサイトからのすべての検索リクエストを処理します。 yandex.ru の検索結果には製品オファーも含まれます。

検索サービスとは、検索自体だけでなく、市場にあるすべてのオファーを含むデータベースも意味します。 その規模は次のとおりです。XNUMX 日あたり XNUMX 億件を超える検索リクエストが処理されます。 そして、すべてが中断されることなく迅速に動作し、常に望ましい結果が得られる必要があります。

内容: 市場アーキテクチャ

マーケットの現在のアーキテクチャについて簡単に説明します。 それは次の図で大まかに説明できます。

提携店舗が来店したとします。 彼は、私がおもちゃを売りたいと言っています。それは、キーキー鳴るこの邪悪な猫です。 そしてもうXNUMX匹、鳴き声を出さずに怒っている猫。 そしてただの猫。 次に、店舗はマーケットが検索するオファーを準備する必要があります。 ストアはオファーを含む特別な XML を生成し、アフィリエイト インターフェイスを通じてこの XML へのパスを伝達します。 次に、インデクサーはこの XML を定期的にダウンロードし、エラーをチェックして、すべての情報を巨大なデータベースに保存します。

このような保存された XML は多数あります。 このデータベースから検索インデックスが作成されます。 インデックスは内部形式で保存されます。 インデックスを作成した後、レイアウト サービスはそれを検索サーバーにアップロードします。

その結果、キーキー鳴らして怒った猫がデータベースに表示され、その猫のインデックスがサーバーに表示されます。

猫の検索方法については、検索アーキテクチャに関する部分で説明します。

市場検索アーキテクチャ

私たちはマイクロサービスの世界に住んでいます: 受信したすべてのリクエスト マーケット.yandex.ru 大量のサブクエリが発生し、その処理には数十のサービスが関与します。 この図にはほんの一部が示されています。

簡素化されたリクエスト処理スキーム

各サービスには素晴らしい機能があります。それは、独自の名前を持つ独自のバランサーです。

バランサーにより、サービス管理の柔軟性が向上します。たとえば、更新に必要になることが多いサーバーをオフにすることができます。 バランサーはサーバーが利用できないことを認識し、リクエストを他のサーバーまたはデータセンターに自動的にリダイレクトします。 サーバーを追加または削除すると、負荷はサーバー間で自動的に再分散されます。

バランサーの一意の名前はデータセンターに依存しません。 サービス A がサービス B にリクエストを送信すると、デフォルトでバランサー B はリクエストを現在のデータセンターにリダイレクトします。 サービスが利用できない場合、または現在のデータ センターにサービスが存在しない場合、リクエストは他のデータ センターにリダイレクトされます。

すべてのデータセンターに単一の FQDN を使用することで、サービス A を場所から完全に抽象化できます。 サービス B に対する彼のリクエストは常に処理されます。 例外は、サービスがすべてのデータセンターにある場合です。

しかし、このバランサーですべてがバラ色になったわけではありません。中間コンポーネントが追加されています。 バランサーが不安定になる可能性がありますが、この問題はサーバーを冗長化することで解決されます。 サービス A とサービス B の間には追加の遅延もあります。ただし、実際には 1 ミリ秒未満であり、ほとんどのサービスではこれは重要ではありません。

予期せぬ事態への対処: 検索サービスのバランスと回復力

崩壊が起こったと想像してください。鳴く猫を見つける必要がありますが、サーバーがクラッシュします。 またはサーバー 100 台。 どうやって抜け出すのか？ 本当に猫なしでユーザーを放っておくつもりなのでしょうか？

恐ろしい状況ですが、私たちはそれに備える準備ができています。 順番にお伝えしていきます。

検索インフラストラクチャは複数のデータ センターにあります。

設計時には、XNUMX つのデータセンターを停止する可能性も考慮しています。 人生は驚きに満ちています。たとえば、掘削機が地下ケーブルを切断することがあります（そうです、それは起こりました）。 残りのデータセンターの容量は、ピーク負荷に耐えるのに十分である必要があります。

単一のデータセンターを考えてみましょう。 各データセンターには同じバランサー操作スキームがあります。

XNUMX つのバランサーは少なくとも XNUMX つの物理サーバーです。 この冗長性は信頼性を確保するために設けられています。 バランサーは HAProx 上で実行されます。

HAProx を選択したのは、その高性能、リソース要件の低さ、および幅広い機能のためです。 当社の検索ソフトウェアは各サーバー内で実行されます。

XNUMX つのサーバーに障害が発生する可能性は低いです。 しかし、多数のサーバーがある場合、少なくとも XNUMX 台がダウンする可能性が高くなります。

これが現実に起こっていることです。サーバーがクラッシュします。 したがって、すべてのサーバーの状態を常に監視する必要があります。 サーバーが応答を停止すると、トラフィックから自動的に切断されます。 この目的のために、HAProxy にはヘルスチェックが組み込まれています。 HTTP リクエスト「/ping」により、XNUMX 秒に XNUMX 回すべてのサーバーに送信されます。

HAProxy のもう 1 つの機能: エージェントチェックにより、すべてのサーバーに均等に負荷をかけることができます。 これを行うために、HAProxy はすべてのサーバーに接続し、現在の負荷に応じて 100 ～ XNUMX の重みを返します。重みは、処理キュー内のリクエストの数とプロセッサの負荷に基づいて計算されます。

さて、猫探しについてです。 検索結果は次のようなリクエストになります。 /search?text=怒っている+猫。 検索を高速に行うには、cat インデックス全体が RAM に収まる必要があります。 SSDからの読み込みも十分な速度ではありません。

かつて、オファー データベースは小さく、1 台のサーバーの RAM で十分でした。 オファー ベースが拡大するにつれて、すべてがこの RAM に収まらなくなり、データはシャード 2 とシャード XNUMX の XNUMX つの部分に分割されました。

しかし、これは常に起こります。たとえ良い解決策であっても、別の問題が発生します。

バランサーは依然としてどのサーバーにもアクセスしていました。 しかし、リクエストが来たマシンにはインデックスが半分しかありませんでした。 残りは他のサーバーにありました。 したがって、サーバーは近隣のマシンに移動する必要がありました。 両方のサーバーからデータを受信した後、結果が結合され、再ランク付けされました。

バランサーはリクエストを均等に分散するため、すべてのサーバーはデータを送信するだけでなく、再ランキングに関与していました。

この問題は、隣接するサーバーが利用できない場合に発生しました。 解決策は、異なる優先順位を持つ複数のサーバーを「隣接」サーバーとして指定することでした。 まず、リクエストが現在のラック内のサーバーに送信されました。 応答がなかった場合、リクエストはこのデータ センター内のすべてのサーバーに送信されました。 そして最後に、リクエストは他のデータセンターに送られました。
提案の数が増えるにつれて、データは XNUMX つの部分に分割されました。 しかし、これが限界ではありませんでした。

現在、XNUMX つのシャードの構成が使用されています。 さらに、メモリをさらに節約するために、インデックスは検索部分 (検索に使用されます) とスニペット部分 (検索には関与しません) に分割されました。

XNUMX つのサーバーには XNUMX つのシャードのみの情報が含まれます。 したがって、完全なインデックスを検索するには、異なるシャードを含む XNUMX つのサーバーで検索する必要があります。

サーバーはクラスターにグループ化されます。 各クラスターには XNUMX つの検索エンジンと XNUMX つのスニペット サーバーが含まれています。

スニペット サーバーは、静的データを含むキーと値のデータベースを実行します。 これらは、例えば鳴く猫の説明などの文書を発行するために必要です。 検索サーバーのメモリに負荷をかけないように、データは特別に別のサーバーに転送されます。

ドキュメント ID は XNUMX つのインデックス内でのみ一意であるため、スニペットにドキュメントが存在しない状況が発生する可能性があります。 そうですね、XNUMX つの ID に対して異なるコンテンツが存在することになります。 したがって、検索が機能し、結果が返されるためには、クラスター全体で一貫性が必要でした。 一貫性を監視する方法については以下で説明します。

検索自体は次のように構成されています。検索リクエストは 1 つのサーバーのいずれかに送信されます。 彼がサーバー XNUMX に来たとしましょう。このサーバーはすべての引数を処理し、何をどのように探すべきかを理解しています。 受信リクエストに応じて、サーバーは必要な情報を得るために外部サービスに追加のリクエストを行うことができます。 XNUMX つのリクエストの後に、外部サービスへのリクエストを最大 XNUMX 件続けることができます。

必要な情報を収集した後、オファー データベースでの検索が開始されます。 これを行うには、クラスター内の XNUMX つのサーバーすべてに対してサブクエリが実行されます。

応答を受信すると、結果が結合されます。 最終的に、結果を生成するには、スニペット サーバーへのさらにいくつかのサブクエリが必要になる場合があります。

クラスター内の検索クエリは次のようになります。 /shard1?text=怒っている+猫。 さらに、次の形式のサブクエリがクラスター内のすべてのサーバー間で XNUMX 秒に XNUMX 回継続的に作成されます。 /スターテス.

問い合わせ /スターテス サーバーが利用できない状況を検出します。

また、検索エンジンのバージョンとインデックスのバージョンがすべてのサーバーで同じになるように制御します。そうしないと、クラスター内でデータが不整合になります。

XNUMX つのスニペット サーバーが XNUMX つの検索エンジンからのリクエストを処理するという事実にもかかわらず、そのプロセッサの負荷は非常に軽いです。 そのため、現在、スニペット データを別のサービスに転送しています。

データを転送するために、ドキュメント用のユニバーサル キーを導入しました。 現在、XNUMX つのキーを使用して別のドキュメントのコンテンツが返される状況は不可能です。

しかし、別のアーキテクチャへの移行はまだ完了していません。 次に、専用のスニペット サーバーを削除します。 そして、クラスター構造から完全に離れます。 これにより、簡単に拡張を続けることができます。 さらに、鉄分を大幅に節約できるというメリットもあります。

そして今度はハッピーエンドの怖い話へ。 サーバーが利用できないいくつかのケースを考えてみましょう。

何かひどいことが起こりました: XNUMX 台のサーバーが利用できません

XNUMX つのサーバーが利用できないとします。 その後、クラスター内の残りのサーバーは引き続き応答できますが、検索結果は不完全になります。

ステータスチェック経由 /スターテス 隣接するサーバーは、XNUMX つのサーバーが利用できないことを認識します。 したがって、完全性を維持するために、リクエストごとにクラスター内のすべてのサーバーが / ping 彼らはバランサーに対して、自分たちも利用できないと応答し始めます。 クラスター内のすべてのサーバーが停止したことがわかりました (これは真実ではありません)。 これがクラスタ スキームの主な欠点です。だからこそ、それを回避したいのです。

エラーで失敗したリクエストは、他のサーバー上のバランサーによって再送信されます。
バランサーは、停止したサーバーへのユーザー トラフィックの送信も停止しますが、ステータスのチェックは継続します。

サーバーが利用可能になると、サーバーは応答を開始します。 / ping。 停止したサーバーからの ping に対する通常の応答が到着し始めるとすぐに、バランサーはユーザー トラフィックをそこに送信し始めます。 クラスターの動作が回復しました。万歳。

さらに悪いことに、多くのサーバーが利用できなくなります

データセンター内のサーバーの大部分が削減されます。 何をすべきか、どこに逃げるべきか？ バランサーが再び助けに来ます。 各バランサーは、現在のライブサーバーの数をメモリに常に保存します。 現在のデータセンターが処理できる最大トラフィック量を常に計算します。

データセンター内の多くのサーバーがダウンすると、バランサーは、このデータセンターがすべてのトラフィックを処理できないことを認識します。

その後、超過トラフィックが他のデータセンターにランダムに分散され始めます。 すべてがうまくいき、誰もが幸せになります。

やり方: リリースの公開

次に、サービスに加えられた変更を公開する方法について説明します。 ここでは、プロセスを簡素化する道を選択しました。つまり、新しいリリースのロールアウトはほぼ完全に自動化されています。
プロジェクトに一定数の変更が蓄積されると、新しいリリースが自動的に作成され、ビルドが開始されます。

その後、サービスはテストに展開され、動作の安定性がチェックされます。

同時に、自動パフォーマンステストが開始されます。 これは特別なサービスによって処理されます。 それについては今は説明しません。その説明は別の記事にする価値があります。

テストでの公開が成功すると、事前安定版でのリリースの公開が自動的に開始されます。 Prestable は、通常のユーザー トラフィックが送信される特別なクラスターです。 エラーが返された場合、バランサーは本番環境に再リクエストを行います。

プレ安定版では、応答時間が測定され、運用環境の以前のリリースと比較されます。 すべてが正常であれば、人が接続し、グラフと負荷テストの結果を確認してから、本番環境へのロールアウトを開始します。

ユーザーに最善を尽くします: A/B テスト

サービスへの変更が実際の利益をもたらすかどうかは、必ずしも明らかではありません。 変更の有用性を測定するために、人々は A/B テストを考案しました。 Yandex.Market検索でどのように機能するかについて少し説明します。

すべては、新しい機能を有効にする新しい CGI パラメータを追加することから始まります。 パラメータを次のようにします。 マーケット_新しい機能=1。 次に、フラグが存在する場合、コード内でこの機能を有効にします。

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

新しい機能は運用環境に展開されています。

A/Bテストを自動化するために、詳細な情報を提供する専用サービスがあります ここで説明されています。 サービス内に実験が作成されます。 トラフィックシェアは、例えば１５％に設定される。 パーセンテージはクエリに対してではなく、ユーザーに対して設定されます。 実験の期間も、たとえば 15 週間などと示されます。

複数の実験を同時に実行できます。 設定では、他の実験との交差が可能かどうかを指定できます。

その結果、サービスは自動的に引数を追加します マーケット_新しい機能=1 ユーザーの 15% に。 また、選択したメトリクスも自動的に計算されます。 実験が完了すると、アナリストは結果を調べて結論を導き出します。 調査結果に基づいて、本番環境に展開するか改良版に展開するかが決定されます。

市場の巧みな手: 本番環境でのテスト

運用環境で新しい機能の動作をテストする必要がある場合がよくありますが、高負荷下の「戦闘」条件で機能がどのように動作するかがわかりません。

解決策はあります。CGI パラメータのフラグは、A/B テストだけでなく、新しい機能のテストにも使用できます。

私たちは、サービスをリスクにさらすことなく、数千台のサーバーの構成を即座に変更できるツールを作成しました。 ストップタップといいます。 当初のアイデアは、レイアウトなしで一部の機能をすぐに無効にできるようにすることでした。 その後、ツールは拡張され、より複雑になりました。

サービス フロー図を以下に示します。

フラグ値はAPI経由で設定されます。 管理サービスはこれらの値をデータベースに保存します。 すべてのサーバーは XNUMX 秒ごとにデータベースにアクセスし、フラグ値を出力し、これらの値を各リクエストに適用します。

停止タップでは、XNUMX 種類の値を設定できます。

1) 条件式。 いずれかの値が true の場合に適用されます。 例えば：

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

値「3」は、リクエストがロケーション DC1 で処理されるときに適用されます。 beru.ru サイトの 4 番目のクラスターでリクエストが処理される場合、値は「XNUMX」になります。

2) 無条件の値。 どの条件も満たされない場合、デフォルトで適用されます。 例えば：

価値、価値！

値が感嘆符で終わる場合、その値の優先順位が高くなります。

CGI パラメータ パーサーは URL を解析します。 次に、停止タップからの値を適用します。

次の優先順位を持つ値が適用されます。

1. 停止タップ (感嘆符) からの優先度が高くなります。
2. リクエストからの値。
3. 「停止」タップからのデフォルト値。
4. コード内のデフォルト値。

条件値で示されるフラグは多数あります。これらは、私たちが知っているすべてのシナリオに十分です。

• データセンター。
• 環境: 本番、テスト、シャドウ。
• 会場：ベルのマーケット。
• クラスター番号。

このツールを使用すると、特定のサーバー グループ (たとえば、XNUMX つのデータ センターのみ) で新しい機能を有効にし、サービス全体に特別なリスクを与えることなくこの機能の動作をテストできます。 どこかで重大な間違いを犯し、すべてがダウンし始め、データセンター全体がダウンした場合でも、バランサーはリクエストを他のデータセンターにリダイレクトします。 エンドユーザーは何も気づきません。

問題に気付いた場合は、すぐにフラグを以前の値に戻すことができ、変更はロールバックされます。

このサービスには欠点もあります。開発者はこのサービスを非常に気に入っており、すべての変更を Stop Tap にプッシュしようとすることがよくあります。 私たちは悪用と闘うよう努めています。

ストップ タップのアプローチは、運用環境にロールアウトする準備ができている安定したコードがすでにある場合にうまく機能します。 同時に、まだ疑問があり、「戦闘」条件でコードをチェックしたいと考えています。

ただし、Stop Tap は開発中のテストには適していません。 「シャドウ クラスター」と呼ばれる開発者用の別のクラスターがあります。

秘密のテスト: シャドウ クラスター

いずれかのクラスターからのリクエストはシャドウ クラスターに複製されます。 しかし、バランサーはこのクラスターからの応答を完全に無視します。 その動作図を以下に示します。

実際の「戦闘」状態にあるテスト クラスターを取得しました。 通常のユーザー トラフィックはそこに流れます。 両方のクラスターのハードウェアは同じであるため、パフォーマンスとエラーを比較できます。

また、バランサーは応答を完全に無視するため、エンド ユーザーにはシャドウ クラスターからの応答が表示されません。 したがって、間違いを犯すことは怖くないのです。

所見

では、マーケット検索をどのように構築したのでしょうか?

すべてをスムーズに進めるために、機能を別のサービスに分割します。 こうすることで、必要なコンポーネントのみをスケールし、コンポーネントをよりシンプルにすることができます。 別のコンポーネントを別のチームに割り当てて、そのコンポーネントに取り組む責任を共有するのは簡単です。 そして、このアプローチによる鉄の大幅な節約は明らかなプラスです。

シャドウ クラスターも役立ちます。ユーザーの邪魔をせずにサービスを開発し、そのプロセスでテストできます。

もちろん、本番環境でのテストです。 数千台のサーバーの構成を変更する必要がありますか? 簡単です。ストップタップを使用してください。 こうすることで、既製の複雑なソリューションをすぐに展開し、問題が発生した場合は安定したバージョンにロールバックできます。

成長を続けるオファーベースでどのようにして市場を迅速かつ安定させているかをお見せできれば幸いです。 サーバーの問題を解決し、膨大な数のリクエストに対処し、サービスの柔軟性を向上させ、作業プロセスを中断することなくこれを行う方法。

出所： habr.com