|
Sogouは、C++サーバーエンジンであるSogou C++ Workflowをオープンソース化しました。このエンジンは、高性能と軽量なデプロイメントを実現するだけでなく、タスクフローの概念を導入し、コンピューティングタスクと通信タスクの統合的かつ協調的なスケジューリングを実現します。 報道によれば、このエンジンは現在、あらゆる検索サービス、クラウド入力方式、オンライン広告など、Sogou のバックエンド C++ オンライン サービスのほぼすべてをサポートしており、毎日数百億件のリクエストを処理しているという。 Sogou C++ Workflowは、創業以来、高性能と軽量設計という2つの基本原則を堅持してきました。長年にわたり、業界におけるサーバーパフォーマンスの最適化は、CPU使用率の最大化と、個々のネットワークリクエストに対する極めて高速な応答時間の確保に主眼を置いてきました。しかし、新たにリリースされたSogou Workflowは、特定のスケジューラを通じて様々なネットワークリソースを管理し、その可用性を最大化することに重点を置いています。 一方、複数の通信リソースとコンピューティングリソースを統合したソリューションは、ワークフローエンジンのパフォーマンスをさらに向上させます。これまで、開発者が高スループットネットワークフレームワークを選択する際には、コンピューティングリソースの割合に応じて、異なるサイズのスレッドプールを手動で割り当てる必要がありました。しかし、コンピューティングリソースの種類ごとに具体的なリソース要件は動的に変化し、その重要性も異なり、バックエンドの応答時間も動的に変動します。Sogou C++ Workflowは、C++サーバーエンジンでGo言語と同様にネットワークリソースの非同期スケジューリングを実現し、コンピューティングリソースとディスクリソースをさらに統合します。 このプロジェクトの最大のハイライトは、おそらくタスクフローという概念の革新的な導入でしょう。Sogou C++ Workflowはリソースを高度にカプセル化しているため、ユーザーはAIO実行時に接続プール、スレッドプール、さらにはファイルディスクリプタ（fds）や様々な非同期通知メカニズムを操作する必要がなくなりました。つまり、開発フェーズでは、開発者は内部の詳細を気にすることなく、ビジネス関係性を理解するだけで済み、複雑なビジネスロジックを実装できるようになります。 開発者は、Sogou C++ Workflow によってカプセル化された様々なタスクを使用して、動的または静的に独自のビジネスロジックを構築できます（下図参照）。異なる種類のタスクをシリアル化または並列化することも可能です。 入手可能な情報によると、Sogou C++ Workflowは、様々な革新的な設計に加え、ユーザーフレンドリーなエクスペリエンスも備えています。Sogou C++ Workflowは、HTTP、Redis、MySQL、Kafkaなどのプロトコルをネイティブにサポートしており、これらのプロトコルのクライアントとして直接使用できます。さらに、よりユーザーフレンドリーなSogou RPCが開発されており、brpcやthriftとの相互運用性を実現し、HTTP+JSONまたはIDLを介した言語間通信も可能になっています。 開発チームは、Sogou RPC プロジェクトも近い将来にオープンソース化されることを明らかにしました。 HTTP サーバーのパフォーマンス テスト: Sogou C++ ワークフロー vs nginx、brpc Sogou チームは、Sogou C++ ワークフローと 2 つの主流システム (nginx と brpc) の HTTP サーバーのパフォーマンス比較も提供しました。 テスト環境:
テスト 1: 同時実行レベルの違いが QPS に与える影響 (高いほど良い) 結論：同時負荷テストの数が増加するにつれて、サーバーのQPSも向上しました。WorkflowのQPSは、同時実行数が少ない場合も高い場合も、特に同時実行数が128を超える場合、nginxやbrpcよりも高い値を維持していることがわかります。Workflowは小さなパケットに対して概ね50万QPSを保証しており、ネットワークリソースの高同時実行スケジューリングに内部的に多くの最適化が施されていることがわかります。 テスト 2: データ サイズの違いが QPS に与える影響 (大きいほど良い) 結論：ここでのレスポンスパケットサイズは、HTTPリクエストボディのサイズを指します。レスポンスパケットサイズが増加すると、QPSは低下します。QPSが可能な限り安定し、急激に低下しないことを期待しています。ワークフローのパフォーマンスは、同じ同時実行性において他の2つのシステムよりも優れており、ネットワーク送受信と他の呼び出し間のスケジューリングと調整が優れていることを示しています。 テスト 3: 固定 QPS での遅延分布 CDF プロット (左向きの方が良く、まっすぐなほど良い) 結論：このテストでは、wrk2を用いて固定QPS負荷テストを実施しました。これには1%のロングテールリクエスト（Outiler）が含まれています。実環境下で通常のリクエストが迅速に処理されるかどうかをシミュレートすることに重点を置いたため、ロングテールリクエストは結果に含まれていませんでした。nginxは他のテストでわずかにパフォーマンスが劣っていたため、CDF比較は実施していません。異なるディストリビューション間で、Workflowのレイテンシが低く、レイテンシが最も遅いグループ（0.99～1.00）ではレイテンシの増加も比較的緩やかであることがわかります。これは、Workflowがロングテールリクエストをより迅速に処理していることを示しています。 |
