🐥

PHP が現役である必然性と未来

2024/07/28に公開1

こんにちは。やまゆです。

漠然としたタイトルですが、最近 PHP 言語に関して思っていることをまとめておきます。

PHP は 2024 年においても現役?

特定のユースケースにおいては使わない、使えない、とされることも確実に存在しますが、多くのユースケースでは PHP が最適と判断出来るでしょう。なぜなら、 Web 技術において HTTP/1.1 による通信は今でも多数存在し、その多くが RESTful API として「クライアント -> サーバー -> クライアント」という単純な通信を好んでいます。最近では、 Cookie ではなく Authorization Header を用いたステートレスな通信がメジャーとなり、より単純なサーバー要求が存在する状態です。

スケール性と複雑度

この単純な要求は、スケール性を得るために重要です。例えば WebSocket のようなステートフル(TCP コネクションを張り続ける状態を持つ)な通信の場合、複数マシンにスケールするには、どのマシンに繋がっても問題のない状態保持の仕組みを持ち、再接続の仕組みを持ち、意図しない切断に対する dispose の処理を持つ必要があり、必然的にサーバー実装の複雑度が高くなります。

昔の MMORPG では、サーバー1, サーバー2, ... のように、 1 つのサーバーに接続できる人数を制限することでスケールさせていました。最近ではそういうものは減ってきていますが、 TCP コネクションの場合は物理的なソケット制限がある以上、例えば 10 万人を 1 マシンで処理することは出来ないでしょう(100%不可能という意味ではありませんが、現実的な目線として)。

多くのバトルロワイアル系ゲームが、 「最大 100 人の同時対戦」 と、 100 人に制限しています。これは多すぎる人数がゲーム性を崩壊するリスクの回避もありますが、メモリ上で同時に表現可能なワールドとして、 100 人程度がベストアンサーとなっていて、それ以上の人数はメモリが不足したり、スケールの面で問題があるためだと考えられます。通信量やCPU/メモリ使用率を1人あたり半分にすれば 200 人対戦も出来ると思いますが、その労力は計り知れません。

ということで、元々 HTTP 通信を使っていなかった対戦ゲームや動画配信などのリアルタイム通信サーバーを除き、多くの HTTP 通信は今でもステートレスな per-request で完結する通信を利用しています。

PHP 言語の最大の強み

私が感じている PHP の最大の強みは 「メモリリークという認知コストがほぼゼロである」 部分です。 python や Ruby などでプロダクションの Web サーバーを運営したことがないのでそこと完全な比較が出来るわけではありませんが、 PHP は 「リクエストごとにメモリをほぼ全て破棄するため、メモリのアロケーション管理をアプリサイドで行う必要がない」 言語です。 node.js, python, golang など HTTP サーバーを serve できる言語は様々ありますが、その多くは同一のプロセスが長時間(数時間~数か月~数年!)動作し続けるモデルで、例えばどこかで循環参照が起きていて、気づかないうちにメモリ使用量が線形に増えていって突然動かなくなる、といったことが考えられます。 PHP は(一般的な利用法では)事前にプロセスを立ち上げておいて、リクエスト処理後にメモリを綺麗にしつつ、それでも破棄しきれない部分があっても大丈夫なように、 x 回リクエストを処理したらプロセスを立ち上げなおすという半ば強引な手法で、極力アプリケーションがメモリに詳しくなる必要のない仕組みをとっています。それが PHP の他にない強みであり、現在でも採用され続けている理由でもあると考えています。ステートレスであれば、後はプロセスとそのプロセスを展開するマシン数を増やせばいくらでもスケールすることが出来るので、スケール限界に悩むことも少なくなります(大体は RDB やロードバランサーなどが先にスケール限界にきます)。

要求の複雑化による RESTful API の限界

インターネット上の通信量は年々増加し、 IoT による接続デバイスの増加や、生成 AI などのリソース消費の激しいデータ処理も加わり、インターネット通信への需要は変わりつつあります。

例えば、 SNS で自分へのリプライが発生した場合スマホデバイスにその情報を送る 「プッシュ通知」 は、先ほどのようなステートレスな RESTful API では無駄なリソースが発生し、サーバーコストがかさんでしまうためそのまま採用は難しいです。

ブラウザを使っている時も、たくさんの画像の閲覧やストリーミング動画のダウンロードに、毎回 TCP コネクションを張って 1 つずつ取ってくる手法では応答速度に限界が出てきます。

最近のゲームは多くがオンライン対応で、常にサーバーとデータをやり取りしながらほかのユーザーと交流を取ったり、双方向なコミュニケーションが行われます。

そういった需要を HTTP/1.1 の RESTful API で全て行うことは比較的難しいし、リソースの無駄にもつながります。そのため、近年では TCP コネクションを張りっぱなしにし、サーバーが主体となってデータをストリーミングする手法や、 UDP ソケットを利用したオーバーヘッドの小さい通信が好まれるようになってきました。複雑な要求を満足させるため、プロトコルレベルでの変革が行われたのです。

HTTP/2, HTTP/3

HTTP/1.1 は今も根強くインターネットを支えていますが、現在は HTTP/2 や HTTP/3 による通信も増えてきています。これらは、 HTTP/1.1 で起こっていた諸問題を解決するだけでなく、リソースの利用効率を最大化するために作られました。

しかし、 PHP 言語はどうでしょうか?現在の PHP 言語は、そもそも PHP 処理系単体で HTTP を処理することはあまりありません(!)。

どういうことかというと、 HTTP の通信処理自体は Apache や nginx のようなソフトウェアが行って、パースされた後の具体的なドメインロジックを PHP プロセスが担当するという2層構成になっていることが多いです。

最近では Swoole や Amphp など、 PHP 処理系だけで TCP ソケットを受け持ち、処理する仕組みが増えてきましたが、プロダクションで使われている比率は低いと思います(ゼロではないでしょう)。

そうなってくると、 HTTP/2, HTTP/3 プロトコルの恩恵をフル活用出来ないことになります。例えば、ライブ放送の映像バイナリデータを PHP を使って配布することは考えづらいです。それであれば、 PHP を通せず nginx の機能で直接配布した方が良いでしょう。

PHP の役目は何かと言えば、 「サーバーサイドによるドメイン処理」 です。今 JavaScript や CDN, nginx だけでは達成できないことを PHP が受け持つことが出来ます。

そのドメイン処理の多くは、 「リクエストデータのバリデーション処理」や「データの永続化処理」、「キャッシュ出来ないユーザーデータの返却処理」 などがあてられます。

未来の PHP と私

ドメイン処理はどの時代にも必要なものであり、何かしらの言語がそれを受け持つ必要があるでしょう(生成 AI によるサーバーがそれら全ての処理を完璧にトレース出来るとは考えづらいです)。

その仮説でいけば、 PHP は未来でも続投を続けるものであり、仕事がゼロになることはないと考えています。もちろん、 PHP で達成出来ない要求が増える可能性は高いです。そうなってくると、仕事としての割合が PHP 10 : 他の言語 0 ではなく、 PHP 5 : 他の言語 5 のように内容が変わるかもしれません。 PHP さえ出来ていれば顧客の全ての要求をカバーできる、という時代が長かったのですが、それは次の時代には持ち越せないのではないかと考えています。

PHP はコミュニティが今でも盛んです。カンファレンスは毎月のように全国各地で行われ、たくさんの登壇者が様々なアプローチで PHP に関する話をしています。言語自体の進化も積極的に行われていて、より堅牢で、より高速なアプリケーションを開発出来るようになっています。このコミュニティが廃れない限りは、 PHP は未来においてもうまくやっていくことでしょう。

PHP の役目自体を変えていく流れもあります。ドメイン処理だけでなく、エッジ処理を任せてみたり、ステートフルなリアルタイム性を持たせてみるアプローチが進められています。

私は PHP 言語という 「1ジャンル」 に縛られて身動きを取りづらくするよりは、別の言語にも触れてみて、 PHP では出来ないことが簡単に出来ることを学んだり、それを PHP に持ち帰ることも出来るのではないかと考えて最近行動するようにしています。 RoadRunner のように、 PHP のスケール性を向上させるために golang を前段に持ってきたりなど、他言語と親和性を向上させることもかなり面白いやり方だと考えています。

HTTP サーバーへの要求が複雑化してくる一方、特にバックエンドである永続化データの要求はあまり変わっていません。ユーザーの識別情報、所持物、フレンド情報など、プロトコルは変わってもドメインは変わらないものです。

Web フロントエンドとの親和性で Next.js を使った TypeScript 完結型のシステムも増えました。もちろん使う技術は少ない方が学習コストも下げられますし、セキュリティリスクの管理もしやすいなど利点はあります。

「PHP じゃないとダメ」「Next.js じゃないとダメ」という制約を自分で課すより、 「××言語も良いかもしれない」「◇◇プロトコルの勉強もしてみよう」 という風に、開放的に考える方が、今後の世界をうまく生きられる方法なのかもしれません。

論理的な話としてまとめられたわけではありませんが、雑記としてここに置いておきます。結論を簡単にまとめると、 PHP はコミュニティが元気なら元気に使えるし、他の言語やプロトコルの勉強をするのも良い、って所です。

Discussion