RoadRunner：PHPが死なない、またはGolangが助けになります

こんにちは、Habr！ Badoo ではPHP言語のパフォーマンスに積極的に取り組んでいます。この言語にはかなり大きなシステムがあり、パフォーマンスの問題はお金を節約するためです。 10年以上前、私たちはこのPHP-FPM用に作成しました。これは、最初はPHPのパッチセットでしたが、後に公式ディストリビューションに入りました。



近年、PHPは大きな進歩を遂げました。ガベージコレクターが改善され、安定性のレベルが改善されました。今日、PHPで悪魔や長命のスクリプトを問題なく書くことができます。 これにより、スパイラルスカウトはさらに先へ進むことができました。PHP-FPMとは異なり、RoadRunnerはリクエスト間のメモリをクリアしないため、パフォーマンスが向上します（ただし、この方法では開発プロセスが複雑になります）。 現在、このツールを試していますが、共有できる結果はまだありません。 彼らを待つのがもっと楽しかったので、 スパイラルスカウトからのRoadRunnerの発表の翻訳を公開します。



この記事のアプローチは私たちに近いものです。問題を解決するとき、多くの場合、PHPとGoの束を使用し、両方の言語を活用し、一方を放棄せずに他方を優先します。



お楽しみください！

---

過去10年間で、 フォーチュン500企業と、ユーザー数が500人以下の企業向けのアプリケーションを作成しました。 この間ずっと、当社のエンジニアは主にPHPでバックエンドを開発しました。 しかし2年前、何かが製品のパフォーマンスだけでなく、そのスケーラビリティにも大きく影響しました。Golang（Go）を技術スタックに導入しました。



すぐに、Goを使用すると、最大40倍のパフォーマンスでより大きなアプリケーションを作成できることがわかりました。 これにより、PHPで作成された既存の製品を拡張し、両方の言語の利点を組み合わせて製品を改善することができました。



GoとPHPの組み合わせが実際の開発問題の解決にどのように役立ち、 PHPの「死にかけている」モデルに関連する問題の一部を軽減できるツールになったことを説明します 。

毎日のPHP開発環境

GoがPHPの「死にゆく」モデルをどのように活気づけるのかを説明する前に、標準のPHP開発環境を見てみましょう。



ほとんどの場合、nginx WebサーバーとPHP-FPMサーバーの組み合わせを使用してアプリケーションを起動します。 1つ目は静的ファイルを提供し、特定のリクエストをPHP-FPMにリダイレクトし、PHP-FPM自体がPHPコードを実行します。 おそらく、Apacheとmod_phpからあまり人気のないバンドルを使用しているのでしょう。 ただし、動作は少し異なりますが、原則は同じです。



PHP-FPMがアプリケーションコードを実行する方法を検討してください。 リクエストが到着すると、PHP-FPMは子PHPプロセスを初期化し、リクエストの詳細をその状態の一部（_GET、_POST、_SERVERなど）として渡します。



PHPスクリプトの実行中に状態を変更することはできません。そのため、入力データの新しいセットを取得する方法は1つしかありません。プロセスメモリをクリアし、再度初期化することです。



この実行モデルには多くの利点があります。 メモリの消費についてあまり心配する必要はありません。すべてのプロセスは完全に分離されており、そのうちの1つが停止しても自動的に再作成され、他のプロセスには影響しません。 しかし、このアプローチには、アプリケーションのスケーリングを試みるときに現れる欠点もあります。

通常のPHP環境の欠点と非効率性

PHPでプロフェッショナルな開発に携わっている場合、フレームワークを選択することで、新しいプロジェクトをどこから開始するかがわかります。 依存性注入、ORM、翻訳、テンプレート用のライブラリです。 そしてもちろん、すべてのユーザー入力は1つのオブジェクト（Symfony / HttpFoundationまたはPSR-7）に便利に配置できます。 フレームワークはクールです！



しかし、すべてに価格があります。 エンタープライズレベルのフレームワークでは、単純なユーザーリクエストを処理したり、データベースにアクセスしたりするには、少なくとも数十のファイルをダウンロードし、多数のクラスを作成し、いくつかの構成を作成する必要があります。 しかし、最悪の部分は、各タスクを完了した後、すべてをリセットして再起動する必要があることです。開始したばかりのコードは役に立たなくなり、別のリクエストを処理できなくなります。 他の言語で書いているプログラマーにそれについて話すと、彼の顔に戸惑いが見えます。



PHPエンジニアは、長年、遅延読み込み、マイクロフレーム、最適化されたライブラリ、キャッシュなどのよく考えられた方法を使用して、この問題を解決する方法を探していました。 （翻訳者のメモ：この問題は、PHP 7.4のプリロードの出現により部分的に解決されます）

PHPは、Goを使用して複数の要求を乗り切ることができますか？

たとえば、cronタスク、CSVパーサー、キューブレーカーなど、数分（最大数時間または数日）より長く存続するPHPスクリプトを作成できます。 これらはすべて、1つのシナリオに従って機能します。タスクを抽出し、完了し、次のシナリオを待ちます。 コードは常にメモリ内にあり、貴重なミリ秒を節約します。フレームワークとアプリケーションをダウンロードするには多くの追加手順が必要になるためです。



ただし、長寿命のスクリプトの開発はそれほど単純ではありません。 エラーが発生するとプロセスが完全に終了し、メモリリークの診断が腹立たしくなり、F5を使用したデバッグができなくなります。



PHP 7のリリースにより状況は改善されました。信頼できるガベージコレクターが登場し、エラーの処理が容易になり、カーネル拡張機能がリークから保護されるようになりました。 確かに、エンジニアはメモリを慎重に処理し、コード内の状態の問題を覚える必要があります（これらを無視できる言語はありますか？）。 それにもかかわらず、PHP 7では、驚きはほとんどありません。



存続期間の長いPHPスクリプトを操作するためのモデルを採用し、HTTPリクエストの処理などのより些細なタスクに合わせて、すべてのリクエストですべてをゼロからダウンロードする必要をなくすことは可能ですか？



この問題を解決するには、最初にHTTPリクエストを受け入れ、毎回PHPワーカーに殺すことなく、それらを1つずつリダイレクトできるサーバーアプリケーションを実装する必要がありました。



純粋なPHP（PHP-PM）またはC拡張（Swoole）を使用してWebサーバーを作成できることはわかっていました。 そして、それぞれの方法にはメリットがありますが、どちらのオプションも私たちには向いていませんでした。 単なるWebサーバー以上のものが必要でした。PHPの「ハードスタート」に関連する問題から私たちを救うソリューションを手に入れたいと思っていました。 つまり、アプリケーションサーバーが必要でした。



Goはこれを支援できますか？ この言語はアプリケーションを単一のバイナリファイルにコンパイルするため、それができることはわかっていました。 クロスプラットフォームです。 独自の非常にエレガントな同時実行モデルと、HTTPを操作するためのライブラリを使用します。 そして最後に、何千ものオープンソースのライブラリと統合が利用可能になります。

2つのプログラミング言語の組み合わせの難しさ

まず、2つ以上のアプリケーションが相互に通信する方法を決定する必要がありました。



たとえば、 Alex Palaestrasの優れたライブラリを使用して、PHPおよびGoプロセスによるメモリ共有を実装することができました（Apacheのmod_phpと同様）。 しかし、このライブラリには、問題を解決するための使用を制限する機能があります。



ソケット/パイプラインを介してプロセス間の相互作用を構築するために、別のより一般的なアプローチを使用することにしました。 このアプローチは、過去数十年にわたって信頼性が実証されており、オペレーティングシステムレベルで十分に最適化されています。



まず、プロセス間でデータを交換し、伝送エラーを処理するための単純なバイナリプロトコルを作成しました。 最も単純な形式では、このタイプのプロトコルは、パケットのタイプ、サイズ、およびデータの整合性をチェックするためのバイナリマスクに関する情報を含む、固定サイズのパケットヘッダー （この場合は17バイト）を持つネットストリングに似ています。



PHP側ではpack関数を使用し、Go側ではエンコーディング/バイナリライブラリを使用しました。



1つのプロトコルでは十分ではないように思われました。また、PHPから直接net / rpc Go-servicesを呼び出す機能を追加しました。 後で、GoライブラリをPHPアプリケーションに簡単に統合できるため、これは開発に大いに役立ちました。 この作業の結果は、たとえば、他のオープンソース製品Goridgeで見ることができます。

複数のPHPワーカー間のタスクの分散

相互作用メカニズムを実装した後、タスクをPHPプロセスに最適に転送する方法について考え始めました。 タスクが到着すると、アプリケーションサーバーは無料のワーカーを選択してタスクを完了する必要があります。 ワーカー/プロセスがエラーで終了したか「死亡」した場合、それを取り除き、代わりに新しいものを作成します。 そして、ワーカー/プロセスが正常に機能した場合、タスクを完了するために利用可能なワーカーのプールにそれを返します。







アクティブなワーカーのプールを保存するためにバッファ付きチャネルを使用しました;プールから予期せず「死んだ」ワーカーを削除するために、エラーとワーカーの状態を追跡するメカニズムを追加しました。



その結果、バイナリ形式で提示されたリクエストを処理できる機能的なPHPサーバーを取得しました。



アプリケーションをWebサーバーとして動作させるには、着信HTTPリクエストを表示するための信頼できるPHP標準を選択する必要がありました。 私たちのケースでは、Goからnet / httpリクエストをPSR-7形式に変換するだけで、現在利用可能なほとんどのPHPフレームワークと互換性があります。



PSR-7は不変であると見なされるため（技術的には不変であると言う人もいます）、開発者は原則として要求をグローバルエンティティとして処理しないアプリケーションを作成する必要があります。 これは、長寿命のPHPプロセスの概念によく合います。 まだ名前を受け取っていない最終的な実装は、次のようになりました。

高性能PHPアプリケーションサーバーであるRoadRunnerの紹介

最初のテストタスクはAPIバックエンドであり、これにより定期的に予測できない要求のバーストが発生しました（通常よりもはるかに頻繁に発生しました）。 ほとんどの場合、十分なnginx機能がありましたが、予想される負荷の増加に対してシステムのバランスを十分に取れなかったため、502エラーが定期的に発生しました。



このソリューションを置き換えるために、2018年の初めに、最初のPHP / Goアプリケーションサーバーを展開しました。 そしてすぐに信じられないほどの効果を得ました！ エラー502を完全に取り除いただけでなく、サーバーの数を3分の2に削減し、エンジニアとプロダクトマネージャーの頭痛の種を大幅に節約しました。



年の半ばまでに、私たちはソリューションを改善し、MITライセンスの下でGitHubに公開し、 RoadRunnerという名前を付け、信じられないほどの速度と効率性を強調しました。

RoadRunnerが開発スタックを改善する方法

RoadRunnerを使用すると、Go側のミドルウェアネット/ httpを使用して、リクエストがPHPに到達する前にJWT検証を実行し、WebSocketを処理し、Prometheusで状態をグローバルに集約することができました。



ビルトインRPCのおかげで、拡張ラッパーを作成せずにPHPのGoライブラリのAPIを開くことができます。 さらに重要なことは、RoadRunnerはHTTP以外の新しいサーバーを展開できることです。 例には、PHPでのAWS Lambdaハンドラーの実行、堅牢なキューリゾルバーの作成、さらにアプリケーションへのgRPCの追加が含まれます。



PHPおよびGoコミュニティの助けを借りて、ソリューションの安定性を向上させ、一部のテストでは、アプリケーションのパフォーマンスを最大40倍に高め、デバッグツールを改善し、Symfonyフレームワークとの統合を実装し、HTTPS、HTTP / 2、プラグイン、PSR-17のサポートを追加しました。

おわりに

いくつかは、WordPressプラグインの作成にのみ適した、遅くて扱いにくい言語としてのPHPの時代遅れの概念にまだ魅了されています。 これらの人々は、PHPにはそのような制限があるとさえ言うことができます。アプリケーションが十分に大きくなったら、より「成熟した」言語を選択し、長年にわたって蓄積したコードベースを書き換える必要があります。



私はこれにすべて答えたいと思う：もう一度考えなさい。 あなただけがPHPの制限を設定していると信じています。 ある言語から別の言語に切り替えて生涯を過ごし、ニーズとの完璧な組み合わせを見つけようとするか、言語をツールとして認識し始めることができます。 PHPのような言語の想像上の欠陥は、実際にその成功の理由になり得ます。 また、Goなどの別の言語と組み合わせると、1つの言語の使用に制限されていた場合よりもはるかに強力な製品を作成できます。



たくさんのGoとPHPで作業した後、私たちはそれらを愛していると言えます。 私たちは一方を他方に有利に犠牲にするつもりはありません-反対に、この二重スタックからさらに多くの利益を引き出す方法を探します。



UPD：RoadRunner作成者および元の記事の共著者へようこそ-Lachezis