この記事では、C ++でWebサービスを開発した経験を共有したいと思います。 私の意見では、これは非常に興味深いトピックです。Web開発にC ++を使用することはまれであり、多くの場合ITサークルを困惑させるからです。 インターネットには、このアプローチを支持しない多くの議論があります。 ポインタの使用、メモリリーク、セグメンテーションフォールト、ウェブ標準のサポートの欠如-これは、このテクノロジーの選択を決定する前に、私たちが慣れ親しんでいたものの不完全なリストです。



この記事で問題となっている開発は2015年に完了しましたが、その前提条件はかなり早く現れました。 それはすべて、2008年に、メールアドレスや電話番号などのユーザーの連絡先情報を標準化および修正するためのWebサービスを開発するというアイデアがあったという事実から始まりました。 Webサービスは、特定のユーザーが任意のテキスト形式で指定した連絡先データをREST APIを介して受信し、このデータを整理することになっています。 実際、このサービスは、任意のテキスト文字列でユーザーの連絡先データを認識する問題を解決することになっています。 さらに、そのような処理中に、サービスは住所のタイプミスを修正し、欠落している住所コンポーネントを復元し、処理されたデータを構造化された形式にする必要がありました。 このサービスは、クライアントの連絡先情報の正確さが重要な要素であるビジネスユーザーのニーズに合わせて開発されました。 まず、これらは大規模な組織のオンラインストア、配信サービス、CRMおよびMDMシステムです。



非構造化テキストデータは処理の対象となるため、コンピューティングに関しては、タスクは非常に困難でした。 したがって、すべての処理はC ++で実装され、適用されたビジネスロジックはPerlで記述され、FastCGIサーバーとしてフレーム化されました。



ソリューションのアーキテクチャを再検討することを余儀なくされた新しいタスクに直面するまで、6年間、このサービスは正常に機能しました。 新しいタスクは、ユーザーが入力したメールアドレス、姓、名、愛称のリアルタイムプロンプトを生成することでした。

リアルタイム処理

リアルタイムプロンプトの形成は、連絡先情報をフォームに入力する過程で、ユーザーが郵送先住所または名前の次の文字を入力するたびに、ユーザーから新しいHTTPリクエストを受信することを意味します。 要求の一部として、サービスはこれまでにユーザーが入力したテキスト文字列を受け取り、それを分析して、完了のためのいくつかの最も可能性の高いオプションを生成します。 ユーザーはサービスから受け取ったプロンプトを見て、適切なオプションを選択するか、入力を続けます。 実際には、このように見えるはずです。











このタスクは、フォームの入力中に同じユーザーがより多くのリクエストを生成するという点で、サービスが最初に設計された入力済みの連絡先データの標準化とは異なります。 さらに、これらの要求の処理速度は、ユーザーがキーボードで入力データを入力する速度を超える必要があります。 それ以外の場合、ユーザーはすべてのデータを手動で入力する時間があり、プロンプトは必要ありません。



許容可能な応答時間を評価するために、調整可能な遅延を使用して一連の実験を実行しました。 その結果、応答時間が150ミリ秒を超えると、ヒントが役に立たなくなるという結論に達しました。 サービスの元のアーキテクチャにより、40人のユーザーが同時に作業しながらこのフレームワーク内に留まることができました（これらのインジケーターは、2つのコアと8GBのRAMを備えたサーバーで取得されました）。 この数を増やすには、サーバーハードウェアのプロセッサの数を増やす必要があります。 また、メールアドレスと名前のヒント関数は誰もが自由に使用できるように開発されたため、より多くのプロセッサとサーバーが必要になることがわかりました。 したがって、サービスのアーキテクチャを変更することでリクエストの処理を最適化できるかどうかという疑問が生じました。

ソースアーキテクチャ

改善が必要なサービスアーキテクチャは次のとおりです。











このスキームに従って、ユーザーアプリケーション（たとえば、Webブラウザー）は、Webサーバーが受信するHTTP要求を生成します（この場合、軽量のlighttpd Webサーバーが使用されます）。 クエリが静的を処理していない場合、それらはFastCGIインターフェイスを介してWebサーバーに接続されているアプリケーションサーバーに送信されます（この場合、アプリケーションサーバーはPerlで記述されています）。 要求が連絡先データの処理に関連している場合、それらは処理サーバーに渡されます。 ソケットは、処理サーバーと対話するために使用されます。



このスキームで処理サーバーをデータベースサーバーに置き換えると、php_fpmを実行するPHPだけでなく、PythonまたはRuby用の一般的なフレームワークを使用して開発された従来のWebアプリケーションで使用されるかなり一般的なスキームが得られることがあります。



このアーキテクチャは、負荷を増やしながらサービスを簡単に拡張できるため、非常に成功しているように見えました。このため、新しい処理サーバーが追加されるだけです。 しかし、パフォーマンスは多くの点で望まれていたため、リクエスト処理のさまざまな段階でサービスが費やす時間を測定することにしました。 結果は次の図です。











この図は、リクエストが処理チェーン全体またはその一部のみを通過する場合に、リクエストが送信されてからWebクライアントがレスポンスを受信するまでにかかる時間をパーセンテージで示しています。 この実験中、クライアントとサーバーは同じローカルネットワークに配置されました。



たとえば、図の最初の数字は、時間の25％がWebクライアントからの要求の送信、Webサーバーパスを介した応答、およびWebクライアントへの応答の返送に費やされていることを示しています。 同様に、他のすべての段階では、順方向の要求の通過と、反対方向の同じチェーンに沿った応答の戻りの両方が考慮されます。 つまり、リクエストがさらに進むと、FastCGIインターフェースを介してアプリケーションサーバーに届きます。 このインターフェイスを通過するには、さらに25％の時間がかかります。



次に、要求はアプリケーションサーバーを通過します。 これにさらに20％の時間が費やされます。 この場合、アプリケーションサーバーによる要求の処理は実行されません。 アプリケーションは、HTTP要求を解析し、処理サーバーに渡し、それから応答を受信し、FastCGIインターフェイスに戻すだけです。 実際、アプリケーションはスクリプト言語で実装されているため、時間の20％が要求の解析とインタープリターのコストに費やされています。



さらに20％の時間は、アプリケーションを処理サーバーに接続するために使用されるソケットインターフェイスを介したデータの受け渡しに費やされます。 対応するプロトコルとその実装がはるかに単純であるため、このインターフェイスはFastCGIと比較して少し速く動作します（20％対25％）。 リクエスト自体の処理は、ユーザーが入力したデータのプロンプトの形成で構成されており、合計時間の10％しかかかりません（テストは処理の観点から最も難しいリクエストの1つを使用しました）。



実行された実験のタスクの詳細はすべて最終段階でのみ明らかになり、この段階は生産性の観点から最も疑問が少ないことを強調したいと思います。 残りの手順は非常に標準的です。 そのため、イベントWebサーバーを使用します。これは、リッスンされているHTTPポートに関連付けられた1つのソケットから受信した要求を抽出し、このデータをFastCGIソケットに入れます。 同様に、アプリケーションサーバー-FastCGIソケットからデータを抽出し、処理サーバーソケットに転送します。 アプリケーション自体には、全体として最適化するものは何もありません。



応答時間のわずか10％が有用なアクションに起因するという憂鬱な状況から、アーキテクチャの変更について考えさせられました。

新しいサービスアーキテクチャ

元のアーキテクチャのオーバーヘッドを排除するには、ソケットインターフェイスを排除するだけでなく、インタープリター言語のアプリケーションを取り除くことが理想的です。 この場合、サービスを拡張する機能を維持する必要があります。 次のオプションを検討しました。

イベントサーバーアプリケーション

このオプションの一部として、たとえばNode.jsやTwistedにイベントアプリケーションサーバーを実装する可能性が考慮されました。 この実装では、リクエストが通過するソケットインターフェイスの数は同じままです。各リクエストはバランシングWebサーバーに到着し、それをアプリケーションサーバーインスタンスの1つに渡し、それがリクエストを処理サーバーに送信するためです。 リクエストの合計処理時間は変わりません。 ただし、ソケットの非同期使用により、同時に処理されるリクエストの数が増加します。 大まかに言えば、1つの要求がソケットインターフェイスを介して移動している間、別の要求は同じインスタンス内のアプリケーションのビジネスロジックを通過できます。



古いアーキテクチャの1つのボトルネック（アプリケーションと処理サーバー間のソケットインターフェイス）を排除するためだけに完全に非同期のアプリケーションを実装することは不当であると考えたため、この実装オプションを放棄する必要がありました。 ロギング、ユーザー統計の修正、メールの送信、古いアプリケーションの他のサービスとのやり取りなどの残りのI / O操作は、別々のスレッドで延期されたため、非同期は必要ありませんでした。 さらに、このアーキテクチャでは、1つのリクエストの処理時間を短縮できないため、APIを介してサービスを操作するユーザーアプリケーションはパフォーマンスの向上を享受できません。

アプリケーションとWebサーバーの統合

ここでは、Webサーバーによって直接呼び出されるJavaサーブレットまたは.Netアプリケーションとしてのアプリケーションの実装を調べました。 この場合、FastCGIインターフェースと、同時に解釈される言語を取り除くことができます。 処理サーバーとのソケットインターフェイスが保存されます。



このアプローチを支持しない意思決定は、選択されたテクノロジーをサポートする特定のWebサーバーへのソリューション全体のバインドの影響を受けました。 たとえば、.Netを使用する場合、Javaサーブレット用のTomcatまたはMicrosoft IIS。 アプリケーションとlighttpdおよびnginxサーバーとの互換性を維持したかったのです。

Processing Serverとのアプリケーション統合

この場合、FastCGIインターフェースが保存されるため、特定のWebサーバーへのバインディングはありません。 アプリケーションはC ++で実装され、処理サーバーと統合されます。 したがって、インタープリター言語の使用を避け、アプリケーションと処理サーバー間のソケットインターフェイスを排除しています。



このアプローチの欠点は、大規模なプロジェクトで非常に人気があり、テストされているフレームワークがないことです。 候補のうち、CppCMS、TreeFrog、およびWtを検討しました。 最初の部分では、プロジェクトのWebサイトに長い間新しい更新がなかったため、開発者によるプロジェクトの将来のサポートについて懸念がありました。 TreeFrogはQtに基づいています。 このライブラリはオフラインプロジェクトで積極的に使用していますが、冗長であり、タスクに十分な信頼性がないと考えています。 Wtの観点では、フレームワークはGUIに非常に重点を置いていますが、この場合、GUIは二次的なものです。 これらのフレームワークの使用を拒否した追加の要因は、サードパーティライブラリの使用に関連するリスクを最小限に抑えたいという欲求でした。これは、原則として、サードパーティライブラリのデバッグが不十分であるために破損したくない既存の作業サービスのリワークがあったため、原則として省くことができます。



しかし、そのようなプロジェクトの存在自体が、C ++でのWebアプリケーションの開発はそれほど絶望的ではないという考えに至りました。 そのため、C ++ Webアプリケーションの開発に使用できる既存のライブラリの調査を実施することが決定されました。

既存のライブラリ

Webサーバーと対話するには、アプリケーションは、WebサーバーでサポートされているHTTP、FastCGI、またはSCGIプロトコルのいずれかを実装する必要があります。 FastCGIとその実装をlibfcgiとして決定しました。



HTTPリクエストの解析とHTTPレスポンスの生成のために、cgiccライブラリが登場しました。 このライブラリは、HTTPヘッダーのすべての解析、要求パラメーターの取得、受信したメッセージの本文のデコード、およびHTTP応答の生成を行います。



Xercesは、REST APIのフレームワーク内でサービスユーザーから送信されるXMLリクエストを解析するために選択されました。



C ++では、「すぐに使用できる」Unicodeサポートがないため、すべての文字列データを常にUTF-8で表現するという内部合意が必須である場合、テキストを操作するために標準のSTL文字列を使用することにしました。



外部サービスおよびメールサーバーと対話するために、libcurlを使用し、ハッシュを生成することが決定されました-openssl。

録音コンポーネント

HTMLビューを生成するには、単純なテンプレートエンジンが必要でした。 古いサービスの実装では、HTML ::テンプレートがこれらの目的で使用されていたため、C ++に切り替えるときは、類似の構文と類似の機能を持つテンプレートエンジンが必要でした。 CTPP、Clearsilver、Google-ctemplateを使用してみました。



テンプレートを使用する前にテンプレートをバイナリコードに転送し、それを実行する仮想マシンを作成する必要があるため、CTPPを使用するのは不便であることが判明しました。 これらすべての困難により、コードが不当に扱いにくくなります。



Clearsilverでは、インターフェイス全体が純粋なCで実装されており、それを使用するには、印象的なオブジェクトラッパーを作成する必要がありました。 Google-ctemplateは、サービスの古いバージョンで使用されていたHTML :: Templateのすべての機能をカバーしていませんでした。 最大限に活用するには、表現の形成を担当するロジックを変更する必要があります。 したがって、テンプレートエンジンの場合は、独自の自転車を開発する必要がありました。



独自のC ++テンプレートエンジンの開発には約3日かかりましたが、上記の既製のソリューションの検索と研究には2倍の時間を費やしました。 さらに、テンプレートエンジンでは、「else if」構成要素を追加することで、HTML ::テンプレート構文を拡張でき、変数をテンプレート内の定義済みの値と比較するための演算子も追加されました。



セッション管理も独立して実装する必要がありました。 今回のケースのセッションには、ユーザーの行動をリアルタイムで反映する非常に多くの情報が格納されるため、開発されたサービスの詳細が影響を受けます。 実際、REST APIを介したデータ処理に加えて、通常のユーザーは、たとえば、特定の住所の郵便番号を見つける必要がある場合に、参照サービスとしてサービスにアクセスすることがよくあります。 時々、ユーザーは、これを目的としたREST APIを使用する代わりに、ブラウザーで人の作業を模倣するWebボットを開発することにより、連絡先情報の標準化を自動化することになります。 このようなボットはサービスに無用な負荷をかけ、他のユーザーの作業に影響を与えます。 ボットと戦うために、サービスはセッション内のユーザーの行動を反映する情報を蓄積します。 この情報はその後、ボットの認識とブロックを担当する別のサービスモジュールで使用されます。



おそらく、私たちが独自に実装しなければならなかった重要な標準はJSONです。 C ++では、別の実装を作成する前に分析したオープン実装の多くがあります。 独自の実装を作成する主な理由は、動的な割り当てとメモリの解放の操作を高速化するために処理サーバーで使用された非標準のメモリアロケータと組み合わせたJSONの使用です。 このアロケーターは、小さなブロックの割り当て/解放の大量操作で、標準のアロケーターよりも2〜3倍速く動作します。 JSONでの作業はこのパターンに適合するため、JSONオブジェクトの解析と構築に関連するすべての操作のパフォーマンスを無料で向上させたいと考えました。

最終結果

最終的なソリューションのアーキテクチャを次の図に示します。











モノリシックサーバーのフレームワーク内では、アプリケーションロジックと連絡先データの処理の両方が統合されています。 着信要求を処理するために、サーバーは実行スレッドのプールを提供します。 API要求の処理中に実行する必要があるすべてのI / O操作は遅延します。 これらの目的のために、非同期I / Oの実行を担当するサーバー上にスレッドの別個のプールが作成されます。 このような操作には、たとえば、有料のAPI関数を使用する場合のユーザー統計の更新や、費用の減額が含まれます。 どちらの場合も、データベースに記録する必要があります。メインスレッドで実行するとデータベースがブロックされます。



このアーキテクチャにより、モノリシックサーバーの追加インスタンスを実行することでサービスを拡張できます。この場合、Webサーバーにはバランサーの追加の役割が与えられます。



前に示した図によると、新しいアーキテクチャに切り替えると、1つの要求を処理するときのサービスの応答時間が約40％短縮されるはずです。 実際の実験では、減少は43％発生したことが示されました。 これは、モノリシックソリューションがRAMのより効率的な使用になったという事実によって説明できます。



また、ストレステストを実施して、プロンプトを使用しながら新しいサービスが対応できるユーザー数を決定し、150ミリ秒以下の応答時間を提供しました。 このモードでは、サービスは120人のユーザーの同時操作を提供できました。 古い実装の場合、この値は40だったことを思い出してください。この場合、生産性の3倍の増加は、要求フローの処理に関与するプロセスの総数の減少によって説明されます。 以前は、要求はアプリケーションの複数のインスタンスによって処理されました（実験では、インスタンスの数は5から20まで変化しました）が、サービスの新しいバージョンでは、すべての要求は単一のマルチスレッドプロセスの一部として処理されます。 各インスタンスは独自の個別のメモリで動作しますが、それらはすべて一緒に1つのプロセッサキャッシュを奪い合い、その使用は非効率になります。 1つのモノリシックプロセスの場合、そのような競合はありません。

おわりに

この記事では、リアルタイムのリクエスト処理を提供する必要がある場合に、Webサービスを開発するための非標準的なアプローチを検討しました。 プロンプトを生成するタスクの例は、応答時間を長くするとサービスの機能がユーザーにとって実質的に役に立たなくなるというWebサービスの異常な状況を示しています。 例は、そのような要件の出現がアーキテクチャの大幅な変更につながる可能性があることを示しています。



パフォーマンスを向上させるには、アプリケーションサーバーとデータ処理サーバーをC ++で実装された単一のモノリシックサーバーに結合する必要がありました。 このソリューションにより、単一の要求を処理する際の応答時間が半分になり、大量使用によりサービスパフォーマンスが3倍に向上しました。



主な問題を解決することに加えて、行われた作業の楽しいボーナスは、リファクタリングの簡素化でした。なぜなら、厳密なタイピングにより、コードの名前変更に負担をかけないためです。 エラーが発生した場合、プロジェクトは単に組み立てられません。 また、1つの言語で記述されたビジネスロジックとデータ処理ロジックを備えた唯一のサーバーがあるため、結果のプロジェクト全体の保守が容易になりました。