RoadRunner: PHP は死ぬために作られたものではなく、Golang がそれを助けるために作られたものではありません

おい、ハブル！ Badooで活動しています PHPのパフォーマンスに取り組んでいます、この言語ではかなり大規模なシステムがあり、パフォーマンスの問題はコストの節約の問題であるためです。 XNUMX 年以上前、私たちはこのために PHP-FPM を作成しました。これは最初は PHP 用のパッチ セットでしたが、後に正式な配布になりました。

近年、PHP は大きな進歩を遂げました。ガベージ コレクターが改良され、安定性のレベルが向上しました。現在では、PHP でデーモンや存続期間の長いスクリプトを問題なく作成できるようになりました。 これにより、Spiral Scout はさらに前進することができました。RoadRunner は、PHP-FPM とは異なり、リクエスト間でメモリをクリーンアップしないため、さらなるパフォーマンスの向上が得られます (ただし、このアプローチは開発プロセスを複雑にします)。 現在このツールを実験中ですが、まだ共有できる結果はありません。 待つ時間をもっと楽しくするために、 Spiral Scout からの RoadRunner 発表の翻訳を公開します。

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

お楽しみください！

過去 XNUMX 年間、私たちはリストから企業向けのアプリケーションを作成してきました。 フォーチュン500、対象ユーザーが 500 ユーザー以下の企業向け。 これまでずっと、当社のエンジニアは主に PHP でバックエンドを開発してきました。 しかし XNUMX 年前、当社の製品のパフォーマンスだけでなくスケーラビリティにも大きな影響を与える出来事がありました。当社は Golang (Go) をテクノロジー スタックに導入しました。

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

Go と PHP の組み合わせが実際の開発上の問題を解決するのにどのように役立つか、また Go と PHP が私たちにとってどのようにして、Go と PHP に関連する問題の一部を解決できるツールになったかを説明します。 PHP 消滅モデル.

日常の PHP 開発環境

Go を使用して PHP の消滅モデルを復活させる方法について説明する前に、デフォルトの PHP 開発環境を見てみましょう。

ほとんどの場合、nginx Web サーバーと PHP-FPM サーバーを組み合わせて使用​​してアプリケーションを実行します。 前者は静的ファイルを提供し、特定のリクエストを PHP-FPM にリダイレクトしますが、PHP-FPM 自体は PHP コードを実行します。 Apache と mod_php というあまり一般的ではない組み合わせを使用している可能性があります。 ただし、動作は少し異なりますが、原理は同じです。

PHP-FPM がアプリケーション コードをどのように実行するかを見てみましょう。 リクエストが届くと、PHP-FPM は PHP 子プロセスを初期化し、リクエストの詳細をその状態 (_GET、_POST、_SERVER など) の一部として渡します。

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

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

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

あなたがプロの PHP 開発者であれば、フレームワークの選択とともに、新しいプロジェクトをどこから始めるべきかを知っているでしょう。 これは、依存関係注入ライブラリ、ORM、翻訳、テンプレートで構成されます。 そしてもちろん、すべてのユーザー入力を 7 つのオブジェクト (Symfony/HttpFoundation または PSR-XNUMX) に入れることができます。 フレームワークってカッコいいですね！

しかし、すべてには値段がつきものです。 エンタープライズレベルのフレームワークでは、単純なユーザーリクエストやデータベースへのアクセスを処理するには、少なくとも数十のファイルをロードし、多数のクラスを作成し、いくつかの構成を解析する必要があります。 しかし最悪なのは、各タスクを完了した後、すべてをリセットして最初からやり直す必要があることです。開始したばかりのコードはすべて役に立たなくなり、その助けを借りて別のリクエストを処理できなくなります。 他の言語で書くプログラマにこのことを話したら、彼の顔には困惑の色が浮かぶでしょう。

PHP エンジニアは、賢い遅延読み込み技術、マイクロフレームワーク、最適化されたライブラリ、キャッシュなどを使用して、この問題を解決する方法を何年も探してきました。しかし、最終的には、アプリケーション全体をリセットして、何度もやり直す必要があります。 (翻訳者注: この問題は、 プリロード PHP 7.4 の場合)

Go を使用した PHP は複数のリクエストに耐えることができますか?

cron タスク、CSV パーサー、キュー ブレーカーなど、数分より長く存続する (最大で数時間または数日間) PHP スクリプトを作成することができます。 これらはすべて同じシナリオに従って動作します。つまり、タスクを取得し、実行し、次のタスクを待ちます。 コードは常にメモリ内に常駐し、フレームワークとアプリケーションを読み込むために多くの追加手順が必要となるため、貴重なミリ秒を節約できます。

しかし、長期間存続するスクリプトを開発するのは簡単ではありません。 エラーが発生するとプロセスが完全に強制終了され、メモリ リークの診断はイライラし、F5 キーを押してデバッグすることはできなくなります。

PHP 7 のリリースで状況は改善されました。信頼できるガベージ コレクターが登場し、エラーの処理が容易になり、カーネル拡張機能はリーク防止になりました。 確かに、エンジニアは依然としてメモリに注意し、コード内の状態の問題に注意する必要があります (これらのことを無視できる言語はありますか?)。 それでも、PHP 7 には、私たちにとって驚くべきことがほとんどありません。

長期間存続する PHP スクリプトを扱うモデルを採用し、それを HTTP リクエストの処理などのより単純なタスクに適応させ、それによってリクエストごとにすべてを最初からロードする必要をなくすことは可能でしょうか?

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

私たちは、純粋な PHP (PHP-PM) または C 拡張機能 (Swoole) を使用して Web サーバーを作成できることを知っていました。 そして、それぞれの方法には独自のメリットがありますが、どちらのオプションも私たちには合わなかったので、もっと何かが欲しかったのです。 私たちは単なる Web サーバー以上のものを必要としていました。私たちは、PHP の「ハードスタート」に伴う問題から私たちを救ってくれると同時に、特定のアプリケーション向けに簡単に適応および拡張できるソリューションを手に入れることを期待していました。 つまり、アプリケーション サーバーが必要でした。

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

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

まず最初に、XNUMX つ以上のアプリケーションがどのように相互に通信するかを決定する必要がありました。

たとえば、次のように使用します。 素晴らしい図書館 Alex Palaestras 氏、PHP と Go プロセス間でメモリを共有することが可能でした (Apache の mod_php と同様)。 しかし、このライブラリには、問題を解決するための使用を制限する機能があります。

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

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

PHP側で使用したのは パック機能、そして Go 側では、ライブラリ エンコード/バイナリ.

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

複数の PHP ワーカーにタスクを分散する

インタラクションメカニズムを実装した後、タスクを PHP プロセスに転送する最も効率的な方法について考え始めました。 タスクが到着すると、アプリケーション サーバーはそれを実行するための空きワーカーを選択する必要があります。 ワーカー/プロセスがエラーで終了するか「死亡」した場合、それを削除し、新しいワーカー/プロセスを作成して置き換えます。 そして、ワーカー/プロセスが正常に完了した場合は、タスクの実行に使用できるワーカーのプールにそれを返します。

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

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

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

PSR-7 は不変であると考えられているため (技術的には不変ではないという人もいます)、開発者は原則としてリクエストをグローバル エンティティとして扱わないアプリケーションを作成する必要があります。 これは、存続期間の長い PHP プロセスの概念によく適合します。 最終的な実装はまだ名前が付けられていませんが、次のようになります。

ロードランナーのご紹介 - 高性能PHPアプリケーションサーバー

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

このソリューションを置き換えるために、2018 年初めに最初の PHP/Go アプリケーション サーバーをデプロイしました。 するとすぐに驚くべき効果が現れました！ 502 エラーを完全に取り除くことができただけでなく、サーバーの数を XNUMX 分の XNUMX に減らすことができ、多くの費用とエンジニアやプロダクト マネージャーの頭痛薬を節約することができました。

今年の半ばまでに、私たちはソリューションを改良し、MIT ライセンスに基づいて GitHub で公開し、その名前を付けました。 ロードランナー、したがって、その驚異的な速度と効率が強調されます。

RoadRunner が開発スタックをどのように改善できるか

アプリケーション ロードランナー これにより、Go 側で Middleware net/http を使用して、リクエストが PHP に到達する前に JWT 検証を実行できるだけでなく、Prometheus で WebSocket や状態の集約をグローバルに処理できるようになりました。

組み込みの RPC のおかげで、拡張ラッパーを作成せずに、PHP 用の Go ライブラリの API を開くことができます。 さらに重要なのは、RoadRunner を使用すると、新しい非 HTTP サーバーを展開できることです。 例には、PHP でのハンドラーの実行が含まれます。 AWSラムダ、信頼性の高いキュー ブレーカーを作成し、追加することもできます。 gRPC 私たちのアプリケーションに。

PHP および Go コミュニティの支援により、ソリューションの安定性が向上し、一部のテストでアプリケーションのパフォーマンスが最大 40 倍向上し、デバッグ ツールが改善され、Symfony フレームワークとの統合が実装され、HTTPS、HTTP/2、プラグイン、PSR-17。

まとめ

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

これらすべてに対して私は答えたいと思います。もう一度考えてください。 PHP に制限を設定しているのはあなただけであると私たちは考えています。 自分のニーズにぴったり合う言語を見つけようとして、ある言語から別の言語に移行することに一生を費やすこともできますし、言語をツールとして考え始めることもできます。 PHP のような言語の想定される欠陥が、実際にはその成功の理由である可能性があります。 また、Go などの別の言語と組み合わせると、XNUMX つの言語の使用に限定される場合よりもはるかに強力な製品を作成できます。

私たちは Go と PHP をたくさん使ってきたので、それらが大好きだと言えます。 私たちは、一方を他方のために犠牲にするつもりはありません。逆に、このデュアル スタックからさらに多くの価値を得る方法を模索します。

UPD: RoadRunner の作成者および元の記事の共著者にこんにちは - ラケシス

出所： habr.com