OkCupidの出会い系サイトの不可欠な部分は、潜在的なパートナーの推薦です。それらは、あなたとあなたの潜在的なパートナーが示した多くの好みの重複に基づいています。ご想像のとおり、このタスクを最適化する方法はたくさんあります。

ただし、潜在的なパートナーとしてあなたを推薦する（または他の人の潜在的なパートナーとしてあなた自身を推薦する）人に影響を与える要因は、あなたの好みだけではありません。ランク付けせずに、条件に一致するすべてのユーザーを表示するだけの場合、リストはまったく最適ではありません。たとえば、最近のユーザーアクティビティを無視すると、サイトにアクセスしていない人との会話により多くの時間を費やすことができます。あなたが指定する好みに加えて、私たちはあなたが見るべきだと思う人々をあなたに推薦するために多くのアルゴリズムと要因を使用します。

可能な限り最高の結果と、ほぼ無限の推奨事項のリストを提供する必要があります。コンテンツの変更頻度が少ない他のアプリケーションでは、推奨事項を定期的に更新することでこれを行うことができます。たとえば、Spotifyの「DiscoverWeekly」機能を使用すると、推奨トラックのセットを楽しむことができます。このセットは来週まで変更されません。 OkCupidでは、ユーザーは自分の推奨事項をリアルタイムで際限なく表示します。推奨される「コンテンツ」は本質的に非常に動的です（たとえば、ユーザーは設定、プロファイルデータ、場所を変更したり、いつでも非アクティブ化したりできます）。ユーザーは誰をどのように推薦できるかを変更できるため、特定の時間に一致する可能性のあるものが最適であることを確認したいと思います。

さまざまなランク付けアルゴリズムを利用してリアルタイムの推奨を行うには、ユーザーデータで常に更新され、潜在的な候補をフィルタリングしてランク付けする機能を提供する検索エンジンを使用する必要があります。

既存の一致検索システムの問題は何ですか

OkCupidは、独自の内部検索エンジンを何年も使用しています。詳細については説明しませんが、高レベルの抽象化では、ユーザースペースシャード上のmap-reduceフレームワークであり、各シャードには関連するユーザーデータの一部がメモリに含まれ、さまざまなフィルターや並べ替えをオンザフライで有効にするときに使用されます。検索語はすべてのシャードで分岐し、最終的に結果が組み合わされて上位k個の候補が返されます。私たちが書いたこのペアリングシステムはうまく機能したのに、なぜ今それを変更することにしたのですか？

今後数年間でさまざまな推奨ベースのプロジェクトをサポートするために、システムを更新する必要があることはわかっていました。私たちのチームが成長することはわかっていましたし、プロジェクトの数も増えました。最大の課題の1つは、スキーマの更新でした。たとえば、新しいユーザーデータ（設定の性別タグなど）を追加するには、テンプレートに数百行または数千行のコードが必要であり、展開には、システムのすべての部分が正しい順序で展開されるように注意深く調整する必要がありました。カスタムデータセットをフィルタリングしたり、結果をランク付けしたりする新しい方法を追加しようとすると、エンジニアの時間は半日かかりました。彼は、各セグメントを手動で本番環境に展開し、潜在的な問題を監視する必要がありました。さらに重要なことに、システムの管理と拡張が困難になっています。シャードとレプリカは、ソフトウェアがインストールされていないマシンのフリート全体に手動で配布されたためです。

2019年の初めに、ペアリングシステムの負荷が増加したため、複数のマシンにサービスインスタンスを手動で配置して、レプリカの別のセットを追加しました。作業はバックエンドと開発者のために何週間もかかりました。この間、組み込みサービスの検出やメッセージキューイングなどのパフォーマンスのボトルネックにも気づき始めました。これらのコンポーネントは以前は正常に機能していましたが、これらのシステムのスケーラビリティに疑問を呈するようになりました。私たちの仕事は、ワークロードのほとんどをクラウドに移動することでした。このペアリングシステムの移植は、それ自体が面倒な作業ですが、他のサブシステムも含まれます。

現在、OkCupidでは、これらのサブシステムの多くがより堅牢でクラウドに適したOSSオプションによって提供されており、チームは過去2年間で大きな成功を収め、さまざまなテクノロジーを採用しています。ここではこれらのプロジェクトについては説明しませんが、代わりに、上記の問題に対処するために行った手順に焦点を当て、開発者にとってより使いやすくスケーラブルな検索エンジンであるVespaに移ります。

それは偶然です！OkCupidがVespaと友達になった理由

歴史的に、私たちのチームは小規模でした。検索エンジンの選択は非常に難しいことを最初から知っていたので、私たちに役立つオープンソースのオプションを検討しました。2つの主要な候補はElasticsearchとVespaでした。

Elasticsearch

これは、大規模なコミュニティ、優れたドキュメント、およびサポートを備えた人気のあるテクノロジーです。たくさんの機能があり、Tinderでも使用されています。 PUTマッピングを使用して新しいスキーマフィールドを追加でき、構造化されたREST呼び出しを使用してクエリを作成できます。クエリ時間によるランク付け、カスタムプラグインを作成する機能などがサポートされています。スケーリングとメンテナンスに関しては、シャードの数を定義するだけで済みます。、およびシステム自体がレプリカ配布を処理します。スケーリングには、より多くのシャードを使用して別のインデックスを再構築する必要があります。

Elasticsearchを廃止した主な理由の1つは、メモリに真の部分的な更新がないことでした。インデックスを作成しようとしているドキュメントは、いいねやメッセージなどのために頻繁に更新する必要があるため、これはユースケースにとって非常に重要です。これらのドキュメントは、広告や写真。ほとんどが一定の属性を持つ静的オブジェクトです。したがって、更新時の非効率的な読み取り/書き込みサイクルは、パフォーマンスの大きな問題でした。

ベスパ

ソースコードはほんの数年前に開かれました。開発者は、ビッグデータをリアルタイムで保存、検索、ランク付け、整理するためのサポートを発表しました。Vespaがサポートする機能：

( , 40-50 . )
,
(, TensorFlow)
YQL (Yahoo Query Language) REST
Java-

スケーリングとメンテナンスに関しては、シャードについてはもう考えません。コンテンツノードのレイアウトを設定すると、Vespaがドキュメントのシャーディング、データの複製、配布の方法を自動的に処理します。さらに、ノードを追加または削除するたびに、データが自動的に復元され、レプリカから再配布されます。スケーリングとは、単に構成を更新してノードを追加することを意味し、Vespaがこのデータをリアルタイムで自動的に再配布できるようにします。

全体として、Vespaは私たちのユースケースに最適であるように思われました。 OkCupidには、ユーザーが最適なものを見つけるのに役立つさまざまな情報が含まれています。フィルターと並べ替えだけで、100を超えるパラメーターがあります。常にフィルターと並べ替えを追加するため、このワークフローを維持することは非常に重要です。エントリとクエリの点では、Vespaは既存のシステムに最も似ています。つまり、私たちのシステムでは、メモリ内の高速な部分更新の処理と、一致要求中のリアルタイム処理も必要でした。 Vespaは、はるかに柔軟でシンプルなランキング構造も備えています。 Elasticsearchのクエリの構造が不便であるのとは対照的に、もう1つの優れたボーナスはYQLでクエリを表現できることです。スケーリングとメンテナンスの観点から、その後、Vespaの自動データ配信機能は、比較的小規模なチームにとって非常に魅力的であることが証明されました。全体として、Vespaは、Elasticsearchよりも保守が容易であると同時に、ユースケースとパフォーマンス要件をより適切にサポートすることがわかりました。

Elasticsearchはよく知られているエンジンであり、Tinderの経験から恩恵を受けることができますが、どのオプションでも大量の予備調査が必要になります。同時に、Vespaは、Zedge、数十億の画像を備えたFlickr、1秒あたり10万回を超えるクエリを備えたYahoo Gemini Ads広告プラットフォームなど、本番環境で多くのシステムにサービスを提供し、月間10億人のアクティブユーザーに広告を配信しています。これにより、これは戦闘でテストされた効率的で信頼性の高いオプションであるという確信が得られました。実際、VespaはElasticsearchの前から存在していました。

また、Vespaの開発者は非常に発信的で役立つことが証明されています。Vespaはもともと広告とコンテンツのために建てられました。私たちの知る限り、それはまだ出会い系サイトで使用されていません。独自のユースケースがあったため、最初はエンジンを統合するのは困難でしたが、Vespaチームは非常に応答性が高く、システムを迅速に最適化して、発生したいくつかの問題に対処できるようにしました。

Vespaの仕組みとOkCupidでの検索の様子

Vespaの例に飛び込む前に、その仕組みの概要を簡単に説明します。 Vespaは多数のサービスのコレクションですが、各Dockerコンテナは、admin / configホスト、ステートレスJavaコンテナホスト、および/またはステートフルC ++コンテンツホストとして構成できます。その他の構成、部品、MLモデルとアプリケーションパッケージを経由して展開することができている状態のAPIコンテナおよびコンテンツクラスタへの変更の適用を処理する構成クラスタ内。フィード要求およびその他の要求は、フィードの更新がコンテンツクラスターに到着する前、または分散要求の実行が発生するコンテンツレイヤーに要求がフォークされる前に、HTTPを介してステートレスJavaコンテナー（処理のカスタマイズを可能にする）を通過します。ほとんどの場合、新しいアプリケーションパッケージの展開には数秒しかかかりません。また、Vespaはこれらの変更をコンテナとコンテンツクラスタでリアルタイムに処理するため、何も再起動する必要はほとんどありません。

検索はどのように見えますか？

Vespaクラスタードキュメントには、さまざまなユーザー固有の属性が含まれています。スキーマ定義は、ドキュメントタイプフィールドと、適用可能なランキング式のセットを含むランキングプロファイルを定義します。次のようなユーザーを表すスキーマ定義があるとします。

search user {

    document user {

        field userId type long {
            indexing: summary | attribute
            attribute: fast-search
            rank: filter
        }

        field latLong type position {
            indexing: attribute
        }

        # UNIX timestamp
        field lastOnline type long {
            indexing: attribute
            attribute: fast-search
        }

        # Contains the users that this user document has liked
        # and the corresponding weights are UNIX timestamps when that like happened 
        field likedUserSet type weightedset<long> {
            indexing: attribute
            attribute: fast-search
        }
        
   }

    rank-profile myRankProfile inherits default {
        rank-properties {
            query(lastOnlineWeight): 0
            query(incomingLikeWeight): 0
        }

        function lastOnlineScore() {
            expression: query(lastOnlineWeight) * freshness(lastOnline)
        }

        function incomingLikeTimestamp() {
            expression: rawScore(likedUserSet)
        }

        function hasLikedMe() {
            expression:  if (incomingLikeTimestamp > 0, 1, 0)
        } 

        function incomingLikeScore() {
            expression: query(incomingLikeWeight) * hasLikedMe
        }

        first-phase {
            expression {
                lastOnlineScore + incomingLikeScore
            }
        }

        summary-features {
            lastOnlineScore incomingLikeScore
        }
    }
    
}

この表記indexing: attributeは、これらのフィールドの読み取りおよび書き込みパフォーマンスを最高にするために、これらのフィールドをメモリに格納する必要があることを示しています。

これらのカスタムドキュメントをクラスターに入力したとしましょう。次に、上記のフィールドのいずれかでフィルタリングしてランク付けできます。たとえば、デフォルトの検索エンジンhttp://localhost:8080/search/にPOSTリクエストを送信して777、現在地から50マイル以内で、タイムスタンプ以降オンラインで、1592486978最後のアクティビティでランク付けされ、上位2つの候補を維持している自分のユーザー以外のユーザーを検索します。また、summaryfeaturesを選択して、ランキングプロファイルの各ランキング式の寄与を確認しましょう。

{
    "yql": "select userId, summaryfeatures from user where lastOnline > 1592486978 and !(userId contains \"777\") limit 2;",
    "ranking": {
        "profile": "myRankProfile",
        "features": {
            "query(lastOnlineWeight)": "50"
        }
    },
    "pos": {
        "radius": "50mi",
        "ll": "N40o44'22;W74o0'2",
        "attribute": "latLong"
    },
    "presentation": {
        "summary": "default"
    }
}

次のような結果が得られます。

{
    "root": {
        "id": "toplevel",
        "relevance": 1.0,
        "fields": {
            "totalCount": 317
        },
        "coverage": {
            "coverage": 100,
            "documents": 958,
            "full": true,
            "nodes": 1,
            "results": 1,
            "resultsFull": 1
        },
        "children": [
            {
                "id": "index:user/0/bde9bd654f1d5ae17fd9abc3",
                "relevance": 48.99315843621399,
                "source": "user",
                "fields": {
                    "userId": -5800469520557156329,
                    "summaryfeatures": {
                        "rankingExpression(incomingLikeScore)": 0.0,
                        "rankingExpression(lastOnlineScore)": 48.99315843621399,
                        "vespa.summaryFeatures.cached": 0.0
                    }
                }
            },
            {
                "id": "index:user/0/e8aa37df0832905c3fa1dbbd",
                "relevance": 48.99041280864198,
                "source": "user",
                "fields": {
                    "userId": 6888497210242094612,
                    "summaryfeatures": {
                        "rankingExpression(incomingLikeScore)": 0.0,
                        "rankingExpression(lastOnlineScore)": 48.99041280864198,
                        "vespa.summaryFeatures.cached": 0.0
                    }
                }
            }
        ]
    }
}

結果のランク付けを照合してフィルタリングした後、結果をランク付けするための第1フェーズ（第1フェーズ）の計算された式。返される関連性（relevance）は、クエリで指定したランキングプロファイル（rank-profile）の最初のフェーズのすべてのランキング機能を実行した結果としての全体的なスコアですranking.profile myRankProfile。リストに50ranking.featuresを定義しますquery(lastOnlineWeight)。これは、使用する唯一のランキング式によって参照されますlastOnlineScore。属性のタイムスタンプが現在のタイムスタンプと比較して最近のものである場合、1に近い数値である組み込みのランキング関数 freshnessを使用します。すべてが順調に進んでいる限り、ここで複雑なことは何もありません。

静的コンテンツとは異なり、このコンテンツは、ユーザーに表示されるかどうかに影響を与える可能性があります。たとえば、彼らはあなたを好きかもしれません！好きなユーザーのIDをキーとして、それが発生したときのタイムスタンプを値として含む、各ユーザードキュメントの加重フィールドにインデックスを付けることができますlikedUserSet。次に、あなたを好きな人を除外するのは簡単です（たとえば、likedUserSet contains \”777\”YQLに式を追加する）が、ランク付け中にこの情報を含めるにはどうすればよいですか？結果で私たちの人を好きなユーザーのtogrを増やす方法は？

以前の結果ではincomingLikeScore、これらのヒットの両方でランキング式は0でした。ユーザーは6888497210242094612実際にユーザーを気に入りました777しかし、私たちが入れたとしても、現在ランキングでは利用できません"query(incomingLikeWeight)": 50。我々は使用することができますランク機能をYQL（第1および機能への唯一の最初の引数はrank()文書が一致しているかどうかを判断しますが、すべての引数は、ランキングスコアを計算するために使用されている）、その後、使用ドット積を、この場合には（店舗への私たちのYQL順位式の中で、生のスコアを取得しますユーザーが私たちを気に入ったときのタイムスタンプ）、たとえば、次のように：

{
    "yql": "select userId,summaryfeatures from user where !(userId contains \"777\") and rank(lastOnline > 1592486978, dotProduct(likedUserSet, {\"777\":1})) limit 2;",
    "ranking": {
        "profile": "myRankProfile",
        "features": {
            "query(lastOnlineWeight)": "50",
            "query(incomingLikeWeight)": "50"
        }
    },
    "pos": {
        "radius": "50mi",
        "ll": "N40o44'22;W74o0'2",
        "attribute": "latLong"
    },
    "presentation": {
        "summary": "default"
    }
}

{
    "root": {
        "id": "toplevel",
        "relevance": 1.0,
        "fields": {
            "totalCount": 317
        },
        "coverage": {
            "coverage": 100,
            "documents": 958,
            "full": true,
            "nodes": 1,
            "results": 1,
            "resultsFull": 1
        },
        "children": [
            {
                "id": "index:user/0/e8aa37df0832905c3fa1dbbd",
                "relevance": 98.97595807613169,
                "source": "user",
                "fields": {
                    "userId": 6888497210242094612,
                    "summaryfeatures": {
                        "rankingExpression(incomingLikeScore)": 50.0,
                        "rankingExpression(lastOnlineScore)": 48.97595807613169,
                        "vespa.summaryFeatures.cached": 0.0
                    }
                }
            },
            {
                "id": "index:user/0/bde9bd654f1d5ae17fd9abc3",
                "relevance": 48.9787037037037,
                "source": "user",
                "fields": {
                    "userId": -5800469520557156329,
                    "summaryfeatures": {
                        "rankingExpression(incomingLikeScore)": 0.0,
                        "rankingExpression(lastOnlineScore)": 48.9787037037037,
                        "vespa.summaryFeatures.cached": 0.0
                    }
                }
            }
        ]
    }
}

68888497210242094612彼は私たちのユーザーが好きで、それincomingLikeScoreは完全な意味を持っているので、今、ユーザーはトップに引き上げられます。もちろん、より複雑な表現で使用できるように、実際には彼が私たちを気に入ったときのタイムスタンプがありますが、今のところは単純なままにしておきます。

これは、ランキングシステムを使用して結果をフィルタリングおよびランキングするメカニズムを示しています。ランキングフレームワークは、クエリ中に一致する式（ほとんどは数学的なもの）を適用する柔軟な方法を提供します。

Javaでミドルウェアを設定する

別のルートを使用して、このdotProduct式を暗黙的にすべてのリクエストの一部にしたい場合はどうなりますか？これがカスタムJavaコンテナレイヤーの出番です。カスタムサーチャーコンポーネントを作成できます。これにより、任意のパラメーターを処理し、クエリを書き直して、特定の方法で結果を処理できます。Kotlinの例を次に示します。

@After(PhaseNames.TRANSFORMED_QUERY)
class MatchSearcher : Searcher() {

    companion object {
        // HTTP query parameter
        val USERID_QUERY_PARAM = "userid"

        val ATTRIBUTE_FIELD_LIKED_USER_SET = “likedUserSet”
    }

    override fun search(query: Query, execution: Execution): Result {
        val userId = query.properties().getString(USERID_QUERY_PARAM)?.toLong()

        // Add the dotProduct clause
        If (userId != null) {
            val rankItem = query.model.queryTree.getRankItem()
            val likedUserSetClause = DotProductItem(ATTRIBUTE_FIELD_LIKED_USER_SET)
            likedUserSetClause.addToken(userId, 1)
            rankItem.addItem(likedUserSetClause)        
       }

        // Execute the query
        query.trace("YQL after is: ${query.yqlRepresentation()}", 2)
        return  execution.search(query)
    }
}

次に、services.xmlファイルで、このコンポーネントを次のように構成できます。

...       
         <search>
            <chain id="default" inherits="vespa">
                <searcher id="com.okcupid.match.MatchSearcher" bundle="match-searcher"/>
            </chain>
        </search>
        <handler id="default" bundle="match-searcher">
            <binding>http://*:8080/match</binding>
        </handler>
...

次に、アプリケーションパッケージを作成してデプロイし、カスタムハンドラーにリクエストを送信しますhttp://localhost:8080/match-?userid=777。

{
    "yql": "select userId,summaryfeatures from user where !(userId contains \"777\") and rank(lastOnline > 1592486978) limit 2;",
    "ranking": {
        "profile": "myRankProfile",
        "features": {
            "query(lastOnlineWeight)": "50",
            "query(incomingLikeWeight)": "50"
        }
    },
    "pos": {
        "radius": "50mi",
        "ll": "N40o44'22;W74o0'2",
        "attribute": "latLong"
    },
    "presentation": {
        "summary": "default"
    }
}

以前と同じ結果が得られます！Kotlinコードでは、変更後にYQLビューを出力するためのトレースバックを追加したためtracelevel=2、URLパラメーターで設定すると、応答も表示されることに注意してください。

...
                    {
                        "message": "YQL after is: select userId, summaryfeatures from user where ((rank(lastOnline > 1592486978, dotProduct(likedUserSet, {\"777\": 1})) AND !(userId contains \"777\") limit 2;"
                    },
...

Javaミドルウェアコンテナは、サーチャーを介してカスタム処理ロジックを追加したり、レンダラーを使用して結果をネイティブに生成したりするための強力なツールです。Searcherコンポーネントをカスタマイズします上記のようなケースや、検索で暗黙的に作成したいその他の側面を処理するため。たとえば、私たちがサポートする製品コンセプトの1つは、「相反性」のアイデアです。特定の基準（年齢範囲や距離など）でユーザーを検索できますが、候補者の検索基準も満たす必要があります。 Searcherコンポーネントでこれをサポートするために、検索しているユーザーのドキュメントをフェッチして、フィルタリングとランク付けのための後続のフォークされたクエリでその属性の一部を提供することができます。ランキングフレームワークとカスタムミドルウェアは一緒になって、複数のユースケースをサポートする柔軟な方法を提供します。これらの例では、いくつかの側面のみを取り上げましたが、ここでは詳細なドキュメントを見つけることができます。

Vespaクラスターを構築して本番環境に移行する方法

2019年春、新システムの企画を開始しました。この間、Vespaチームにも連絡を取り、ユースケースについて定期的に相談しました。運用チームはクラスターの初期設定を評価および構築し、バックエンドチームはさまざまなVespaのユースケースの文書化、設計、およびプロトタイプ作成を開始しました。

プロトタイピングの最初の段階

OkCupidバックエンドシステムはGolangおよびC ++で記述されています。カスタムVespaロジックコンポーネントを作成し、Java Vespa HTTPフィードクライアントAPIを使用して高いフィードレートを提供するには、JVM環境に少し慣れる必要がありました。Vespaコンポーネントの構成時とフィードパイプラインでKotlinを使用することになりました。

アプリケーションロジックを移植してVespa機能を発表し、必要に応じてVespaチームに相談するのに、数年かかりました。マッチエンジンのシステムロジックのほとんどはC ++で記述されているため、現在のフィルターとソートデータモデルを、RESTを介してVespaクラスターに発行する同等のYQLクエリに変換するロジックも追加しました。早い段階で、ドキュメントの完全なユーザーベースでクラスターを再作成するための優れたパイプラインの作成にも取り組みました。プロトタイピングには、使用する正しいフィールドタイプを決定するために多くの変更を含める必要があり、誤ってドキュメントフィードを再送信する必要があります。

モニタリングとストレステスト

Vespa検索クラスターを作成したとき、2つのことを確認する必要がありました。それは、予想される量の検索クエリとレコードを処理できることと、システムが提供する推奨事項の品質が既存のペアリングシステムと同等であることです。

負荷テストの前に、Prometheusメトリックをいたるところに追加しました。Vespa-exporterは大量の統計を提供し、Vespa自体も追加のメトリックの小さなセットを提供します。これに基づいて、1秒あたりのリクエスト数、待ち時間、Vespaプロセスによるリソース使用率など、さまざまなGrafanaダッシュボードを作成しました。また、vespa-fbenchを実行してクエリのパフォーマンスをテストしました。 Vespa開発者の助けを借りて、私たちは比較的高いためにそれを決定しました静的な要求のコストは、私たちのグループ化された既製のレイアウトは、より高速な結果を提供します。フラットレイアウトでは、ノードを追加すると、基本的に動的クエリ（つまり、インデックス付けされたドキュメントの数に依存するクエリの部分）のコストが削減されるだけです。グループ化されたレイアウトとは、構成された各サイトグループにドキュメントの完全なセットが含まれるため、1つのグループが要求を処理できることを意味します。静的リクエストのコストが高いため、ノードの数を同じに保ちながら、スループットを大幅に向上させ、フラットグループの数を1つから3つに増やしました。最後に、静的ベンチマークの信頼性に自信が持てるようになったときに、報告されていない「シャドウトラフィック」もリアルタイムでテストしました。

パフォーマンスの最適化

チェックアウトのパフォーマンスは、私たちが早い段階で直面した最大のハードルの1つでした。当初、1000 QPS（1秒あたりのリクエスト数）でも更新の処理に問題がありました。加重セットフィールドを多用しましたが、最初は効果がありませんでした。幸いなことに、Vespaの開発者は、これらの問題やデータ配布に関連する他の問題の解決を迅速に支援しました。彼らは後に、フィードのサイズ設定に関する広範なドキュメントも追加しました。これは、ある程度使用しています。大きな加重セットの整数フィールドは、可能であれば、visibility-delay複数の条件付き更新を使用し、属性フィールド（つまり、メモリ内）に依存するとともに、fmdovパイプラインの操作を圧縮およびマージすることにより、クライアントからのラウンドトリップパケットの数を減らします。現在、パイプラインは定常状態で3000 QPSを静かに処理しており、このようなスパイクが何らかの理由で発生した場合、私たちの謙虚なクラスターは11KQPSの更新を処理しています。

推奨の品質

クラスタが負荷を処理できることを確認した後、推奨事項の品質が既存のシステムよりも悪くないことを確認する必要がありました。ランク付けの実装にわずかな違いがあると、推奨事項の全体的な品質と全体的なエコシステムに大きな影響を及ぼします。実験システムを適用しました一部のテストグループではVespaが使用されましたが、コントロールグループでは引き続き既存のシステムが使用されました。次に、いくつかのビジネスメトリックが分析され、Vespaグループがコントロールグループよりも優れているとは言えないまでも、パフォーマンスが向上するまで問題が繰り返され、文書化されました。Vespaの結果に自信が持てれば、一致リクエストをVespaクラスターに転送するのは簡単でした。すべての検索トラフィックを問題なくVespaクラスターに起動することができました。

システム図

簡略化した形式では、新しいシステムの最終的なアーキテクチャ図は次のようになります。

Vespaの現在の仕組みと次のステップ

Vespaペアファインダーの状態を以前のシステムと比較してみましょう。

スキーマの更新
- 以前：数百行の新しいコードを含む1週間、複数のサブシステムと慎重に調整された展開
- :
/
- :
- : . , !
- : ,
- : , Vespa . -

全体として、Vespaクラスターの設計と保守の側面は、すべてのOkCupid製品の開発に役立っています。2020年1月末に、Vespaクラスターを本番環境に移行し、ペアの検索におけるすべての推奨事項を提供します。また、今年はStacksなどのすべての新機能をサポートするために、数十の新しいフィールド、ランキング式、およびユースケースを追加しました。また、以前のマッチメイキングシステムとは異なり、クエリ時にリアルタイムの機械学習モデルを使用するようになりました。

次は何ですか？

私たちにとって、Vespaの主な利点の1つは、テンサーを使用したランキングの直接サポートと、TensorFlowなどのフレームワークを使用してトレーニングされたモデルとの統合です。これは、今後数か月で開発する主な機能の1つです。すでにいくつかのユースケースでテンサーを使用しており、ユーザーの結果と一致をより正確に予測できるように、さまざまな機械学習モデルの統合を間もなく検討します。

さらに、Vespaは最近、完全にリアルタイムで、同時に検索可能で、動的に更新される多次元最近傍インデックスのサポートを発表しました。リアルタイムの最近傍インデックス検索の他の使用例を調査することに非常に興味があります。

OkCupidとVespa。行く！

多くの人がElasticsearchを聞いたり、使用したりしていますが、Vespaの周りにはそれほど大きなコミュニティはありません。他の多くのElasticsearchアプリケーションがVespaでより適切に機能すると信じています。 OkCupidにとっては素晴らしいことであり、切り替えてよかったです。この新しいアーキテクチャにより、新しい機能をはるかに迅速に進化および開発することができました。私たちは比較的小さな会社なので、サービスの複雑さについてあまり心配しないのは素晴らしいことです。これで、検索エンジンをスケールアウトする準備が整いました。 Vespaがなければ、過去1年間の進歩は確かにあり得ませんでした。 Vespaの技術的機能の詳細については、@ jobergumのeコマースガイドラインにあるVespaAIを確認してください。

私たちは最初の一歩を踏み出し、Vespa開発者が好きでした。彼らは私たちにメッセージを送り返しました、そしてそれは偶然であることがわかりました！ Vespaチームの助けがなければ、これを行うことはできませんでした。感謝@jobergumと@geirstランキングとクエリ処理に関する推奨事項については、および@kkrauneと@vekterli彼らのサポートのため。 Vespaチームが私たちに与えてくれたサポートと努力のレベルは本当に驚くべきものでした-私たちのユースケースへの深い洞察からパフォーマンスの問題の診断とVespaエンジンの即時の改善まで。同志@vekterliはニューヨークの私たちのオフィスに飛んで、エンジンの統合を支援するために1週間私たちと直接協力しました。 Vespaチームに感謝します！

結論として、Vespaの使用法のいくつかの側面に触れただけですが、過去1年間のバックエンドチームと運用チームの多大な作業がなければ、これは不可能でした。既存のシステムと最新のテクノロジースタックとの間のギャップを埋めるために、多くの固有の課題に直面しましたが、これらは他の記事のトピックです。

Vespaは、Elasticsearchよりも数百万の男性と女性を一致させるのに優れています