Baiduの検索表示サービスの主な役割は、検索システムに結果を要求し、テンプレートの選択、リアルタイムの要約補完、データ適応、結果のレンダリングを順に実行することで、豊富で多様な形式でユーザーに検索結果を正確に提示することです。当初、このサービスはC言語で開発されていましたが、反復効率が不十分でした。製品の急速な反復と継続的な事業拡大に伴い、開発効率の問題がますます顕著になりました。このボトルネックを解決するため、検索表示サービスはPHPで開発され、HHVM上で動作するサービスへと進化しました。現在、検索表示サービスは数十の製品ラインと数百人の研究開発担当者によって共同開発されており、数百もの洗練されたビジネス表示戦略をサポートしています。しかし、検索ビジネスの複雑化と大規模生成モデルの台頭に伴い、検索表示サービスは開発難易度の上昇、アーキテクチャ能力の不足、再利用性の低さなど、複数の課題に直面しています。これらの課題は具体的には以下のとおりです。

2.1.1 コアアイデア:

△ 検索プレゼンテーション層アーキテクチャ図

2.1.2 インフラストラクチャ

GDP (Go 開発プラットフォーム) : Go をベースにした Baidu の社内ビジネス開発プラットフォーム。完全な RPC サーバーおよび RPC クライアント機能を備え、主に API、Web、バックエンド サービスの開発に使用されます。

ExGraph: Baidu 検索ディスプレイ チームが独自に開発したグラフ実行エンジン。

Datahold ：Baiduの検索ディスプレイチームが独自に開発したデータマネージャ。主にモジュールデータ（設定や辞書など）の依存関係と読み込みの問題に対処します。以下の機能を備えています。

パブリックライブラリ：さらに、インフラストラクチャ層では、udai（統合リモートデータアクセス用のcgo拡張）、Baidu独自の署名など​​のパブリックライブラリも提供されます。パブリックライブラリの構築には、車輪の再発明を避け、研究開発の効率を向上させるための統一されたアクセス標準があります。

2.1.3 一般的な演算子

検索表示の一般的なロジックをインターフェースとして抽象化し、グラフエンジンをベースに共通演算子を提供することで、一般検索や垂直検索など、複数のアプリケーションで利用可能な単一の視点からの開発を可能にします。現在、サンプリング、適応、劣化、レート制限、検索リクエスト、ランディングページポップアップ、レンダリングなど、数十種類の共通演算子が実装されており、すぐに使用できるため、新しい検索表示アプリケーションの構築を迅速にサポートできます。

2.1.4 アプリケーション層

共通演算子と各サービス独自の表示演算子を用いて実行グラフを構築し、アプリケーションのビジネスロジックを実装します。現在の検索表示サービスには、汎用検索表示サービス、垂直検索表示サービス、生成検索表示サービスが含まれます。

汎用検索は、垂直検索や他の業務アプリケーションよりも複雑です。本章では、汎用検索表示サービスを例に、その再構築とGoへの移行に向けた実装計画を紹介します。

△ リニューアル前後の総合検索表示サービスの比較表

再編と移行のプロセス中に、私たちは 2 つの主な課題に直面しました。

課題1は、主にアーキテクチャの分離とスムーズな移行メカニズムによって解決されます。課題2は、開発、テスト、展開プロセス全体にわたる安定性の確保によって解決されます。これら2つの側面については、以下で詳しく説明します。

2.2.1 ビジネスの分離とスムーズな移行

既存のビジネスプロセスの効率的な移行と反復処理、そして複数の製品ラインにまたがるビジネスプレゼンテーション戦略の移行を円滑に進めるために、アーキテクチャとビジネスプレゼンテーションロジックを分離するというアプローチが中心となります。アーキテクチャの移行はまずGo言語に移行しますが、ビジネスプレゼンテーション戦略はPHP言語上で引き続き実行されます。アーキテクチャの移行中は、ビジネスの反復処理がブロックされることはなく、同一のビジネスロジックがPHP言語とGo言語の両方で同時に開発されることは可能な限り避けられます。ビジネスプレゼンテーション戦略を事業ラインごとにGo言語ベースの検索・プレゼンテーションサービスに個別に移行するためのメカニズムが設計されています。複雑な移行プロセス全体は、最終的にプロジェクト全体の目標を達成するために、4つの段階に分けられています。

フェーズ 1: プレゼンテーション戦略のためのアーキテクチャとサービス指向アーキテクチャのグラフベースの移行 (Go+)。

これには、レート制限、パラメータ処理、取得要求、広帯域が含まれます。 検索リクエストやHTTPヘッダーレンダリングを含むアーキテクチャロジックコードは、GDP+Exgraphグラフアーキテクチャに基づいてGo言語に移行しました。Go言語ベースの汎用検索・表示サービスが検索データの統合処理を完了した後、PHPベースの表示戦略サービスに業務表示ロジックをリクエストしました。このアプローチにより、反復頻度の低いアーキテクチャロジックを最初にGo言語に移行し、その後の表示戦略の移行の基盤を築くと同時に、反復頻度の高い表示戦略は元の開発モデルに従って反復処理を継続できます。

フェーズ2: 非同期ダイジェストリクエストの完全移行

まず、非同期ダイジェストとは何かについてお答えしましょう。

検索システムでは、コンピューティングリソースと応答速度を最適化するために、サブシステム内でキャッシュを利用することがよくあります。キャッシュの有効期限は通常数分以上、場合によっては数日かかることもあります。しかし、動画の再生回数、記事のいいね数、ユーザーエンゲージメント情報を検索結果に表示するなど、数秒以内に更新する必要がある要素では、キャッシュの効率性が低下します。そこで、非同期要約機能が役立ちます。検索リクエストが返された後、検索結果に基づいて高効率な要約サービスが要求されます。この要約リクエストは通常​​の表示戦略と並行して非同期的に完了するため、ユーザー応答速度の低下を防ぎながら、リアルタイムの要約更新を実現します。

プレゼンテーション戦略が徐々に Go に移行していく中で、非同期ダイジェストリクエストの時間を並列処理で短縮する必要が生じることを避けるため、バイパスシステムが導入されています。非同期ダイジェスト戦略は数十種類あり、その反復頻度は通常のプレゼンテーション戦略に比べて比較的低くなっています。すべてのリクエストはまとめて Go に移行されます。成功した非同期ダイジェストリクエストはバイパスシステムに書き込まれます。通常のプレゼンテーション戦略がすべて実行された後 (Go に移行されているか PHP に保持されているかに関係なく)、PHP ベースの戦略サービスはバイパスシステムを通じてすべての非同期ダイジェストを取得し、リアルタイムのダイジェスト補足を実行します。バイパスシステムの導入自体も通信オーバーヘッドを引き起こしますが、これは以下の方法で軽減されます。

フェーズ3: 戦略移行の実証

様々な製品ラインと連携し、ディスプレイ戦略グループ1、ディスプレイ戦略グループ2、ディスプレイ戦略グループ3をGoベースの検索・ディスプレイサービスに移行します。このフェーズでは、戦略粒度と小規模なビジネスボリュームに基づいた製品ラインの移行をサポートします。同時に、Goベースの検索・ディスプレイサービスをベースに、新しいディスプレイ戦略（非同期サマリー戦略を除く）を直接開発できます。

移行ガイドライン：プレゼンテーション戦略に依存関係があるかどうかに基づいて移行します。一般的な依存関係のシナリオ：戦略の実行が、このビジネスに含まれない他のプレゼンテーション戦略に依存しており、その戦略が最初に実行される場合、依存する戦略を最初に移行する必要があります。また、戦略が内部的にアーキテクチャ機能に依存しているが、Goなどのこれらの機能は移行されない場合も移行します。

移行の優先順位:

フェーズ4: 完全移行

非同期要約戦略の移行、レンダリング、および後タスクの移行のプロセス全体が完了しました。

このロジックの部分は比較的頻繁に繰り返されないので、事前に Go に移行してみませんか?

主な制限要因は応答速度です。PHPベースのプレゼンテーション戦略サービスをレンダリングと後処理のためにGoベースのプレゼンテーションサービスに送り返すと、PHP→Goプロセスによってシリアライズ、デシリアライズ、そして通信時間がさらに発生し、速度低下を引き起こします。この速度低下はGoへの移行では補うことができません。

2.2.2 エンドツーエンドの安定性保証

総合検索表示サービス再構築プロジェクトにおけるユーザーエクスペリエンス、収益、そしてサービスの安定性は、主にエンドツーエンドの安定性保証によって確保されます。エンドツーエンドの安定性保証には、主に開発、テスト、そして導入段階における安定性保証が含まれます。

研究開発サポート

移行プロセスは、単なる機能移転ではありませんでした。総合検索表示サービスは数十年にわたって繰り返し使用されてきたため、データの冗長性、多数の歴史的ループホール、コードの再利用性の低さなど、多くの不合理な設計上の欠陥を抱えていました。これらの問題に対処するため、データガバナンスを実装し、レガシーループホールを解消し、共通演算子を再設計しました。これにより、開発品質に対する要求は高まりました。一方で、ユニットテストと自動化されたパイプラインテスト（テスト保証セクションで説明したデータ差分とUI-DIFF）を通じてコード品質を確保しました。他方、ログ分析を用いてレガシー問題を積極的に排除し、不合理で不要な移行を回避しました。

テスト保証

機能テスト:

安定性テスト: オンライン トラフィックを駆動してオンライン動作環境をシミュレートし、オンライン サービスの安定性を確保することで、長期ストレス テストを実施します。

パフォーマンス テスト: パフォーマンス フレーム グラフを通じてシステム パフォーマンスのホットスポットと最適化ポイントを特定し、一般的なオンライン インスタンスのピーク QPS でパフォーマンス テストを実施し、極端な負荷テストを実行してサービスの最大 QPS を取得し、オンライン リソースの容量が十分かどうか、応答データが劣化していないかどうかを事前に推定します。

オンラインサポート

展開フェーズ中に安定性を確保するための主な手段には、 展開前のリソース/応答時間の見積もりに基づく安定性レビューの実施、監視とアラーム、ダウングレード、内部テスト、小規模ネットワーク トラフィックの監視などがあります。

本稿では、検索表示サービスの開発プロセスと、現在直面している主な課題（研究開発の難易度の高さ、アーキテクチャ能力の不足、再利用性の低さ）について紹介します。次に、グラフ実行エンジン、共通演算子、そしてリファクタリングと移行のためのGo言語的なアプローチに基づくソリューションを提案します。最後に、一般的な検索表示サービスを用いたソリューションの実装について詳しく説明します。本稿は、検索表示サービスのリファクタリングに関する知見を共有し、皆様の参考とメリットとなることを願っています。もちろん、不十分な点もあるかもしれませんので、ご意見やご議論をお待ちしております。