レポート

PHPの生みの親,ラスマス・ラードフ氏インタビュー

この記事を読むのに必要な時間:およそ 15.5 分

PHPはひどいコードを動かすのが驚くほど得意

ラスマス:英語にはまるで整合性がありませんが,誰でも多少は分かりますし,それはいいことです。すごく下手にしか話せなくても,たいていの場合,意思疎通の役には立つ。英語をほとんど話せない者同士でもなんとかやりとりはできるのです。そしてPHPは,ひどいコードを動かすのが驚くほど得意です。非常に寛容なのです。

世界最悪のコードを書いたとしても,PHPならまだ動くし,実際速度も出るし,スケーリングも可能です。シェアード・ナッシング・アーキテクチャなので,スケーリング対応は最初から組み込まれているようなものです。世界最遅のコードを書いたとしても,サーバを余分に投入すればいい話です。しかもサーバを買うのはすこしも難しくない。ただ追加のEC2インスタンスをスピンアップすればいいだけです。あとは資金源があって,それを注ぎ込む気さえあれば――たとえばアクセスが増えるとお金が儲かる仕組みがあれば――さらにインスタンスを投入できます。すばらしい。それで資金を作れれば,頭の切れる開発者を何人か雇って元のPHPコードを直してもらうこともできます。

もっと他のこともできるでしょう。PHPは確かにひどい言語といわれることもあります。もっといい言語がある,たとえばHaskellはすばらしい,すべてHaskellに書き換えるべきだと。結構,やればいいじゃないですか。しかし誰かが市場を見つけてソリューションを作らなければ仕事にはならないのです。PHPが今なお人気を保ちつづけている理由はそれかもしれません。あとは一種の慣性ですね。WordPressとかそういうものの勢いが大いに残っていると思います。PHPがひどい言語だというならWordPressを他の言語で書き直しますか? がんばってください,5年後に会いましょう(笑)

マルチコアプログラミングはPHPには興味深い事態

―――― この10年,20年でハードウェアは大きく変化しました。かつてのシンクレアと今日のマシンはずいぶん違います。プログラミング言語やプログラミング自体にはどんな変化が起きたと思いますか。

ラスマス:この20年間に?

―――― はい。できれば,これから10年間についての予想もお願いします。

ラスマス:分かりました。この20年間でハードウェアに起きた大きな変化の一つは,使えるコアが増えたことです。昔は2コアあるだけですごいことでした。今では8コア,16コア,32コアのマシンがありますし,Intelを信じるなら5年か10年先には数千コアのマシンも実現するでしょう。一つひとつは超高速というほどでなくても,それが2,048個集まれば……そういう意味では,時代はマルチコアプログラミングの方向に動いていると思います。

PHPにとって,これはいささか興味深い事態です。というのも,PHPは非常にシングルスレッド的な言語ですが,Webで使われることがほとんどです。そしてWebアプリケーションを単一コンカレントリクエスト前提で書く人はいません。ともかく,そうなのです。世界のどこかにはそういう変わり者のイントラネットシステムも存在するかもしれませんが,一般的にWebでは大量のコンカレントリクエストを扱うものです。ですから,コア数が増えてもPHPのアプローチはほとんど変わりませんでした。

ただ,より多くのコンカレントリクエストを処理できるようになっただけです。ApacheでいえばMaxClientsを引き上げられるようになったのです。昔は20コンカレントリクエストぐらいが精一杯でしたが,今なら32コアのマシンを使えばたぶん80ぐらいまで上げられるでしょう。それを処理できるだけのCPUがあるからです。ですから,アーキテクチャの面ではコア数が増えるほど一台のマシンでスケールアウトできる幅が大きくなります。同じトラフィック量をさばくのに,昔なら10台必要だったところが,今では4台で足りるわけです。

こう考えると,コア数の増加は今後もPHPのアプローチに影響を与えることはないでしょう。しかし他の,Web以外の部分については,数千コアのCPUを活用できるように設計された新しいコンパイラや言語が出てくるでしょうね。

―――― しかしWeb用途については……。

ラスマス:そう,Web用途については,Webは本質的にコンカレントだという,うまい言い訳があるので,シングルリクエスト内で処理する必要を感じません。要はレイテンシーの問題です。1リクエストで物事を30個ぐらい同時にやらせようとすると,リクエストが複雑になりすぎます。そういうときはすこしモジュール化すべきです。ただ複数リクエストを受けつけるようにすればいいのです。特にHTTP/2では複数リクエストの受信の仕方が改善されてますから。だからエンドポイントをもっと小さくして,各エンドポイントの処理を特化させるべきです。

将来は数千コア使えるようになるとすれば――たとえばあるページが2,000のHTTP/2リクエストで構成されているとしましょう。2,000リクエストはPHPレベルで2,000エンドポイントを叩いた後,その数千コアに分散します。それぞれのリクエストが小分けにされていれば,テストも簡単だし,スケールアウトもしやすいし,スケーリングする上で粒度が高まる。一部のエンドポイントへの負荷が高まった場合に分散しやすくなります。あるタイプのエンドポイントにつきサーバファームを一つ,別のタイプのエンドポイントにもサーバファームを一つ,という使い方ができる。そういう意味で,PHPはアーキテクチャ的にはうまくいっていると思います。

整合性を考慮すべきなのはPHPより上のレベルです。大きな変更を行う必要は,少なくとも近い未来にはないでしょう。もちろん,私の予想が完全に間違っている可能性はありますよ。もしかしたら今後コンピュータの世界にまったく新しい概念が入ってくるかもしれません。たとえばカエルの脳とかを使ったバイオチップみたいなのができるとか(笑) しかし私にとって,将来解決されてほしいのはコンパイラの問題ですね。ロジックを記述してCPUで動くコードに変える決定的な手段が必要です。

―――― ラスマスさんから見て,過去20年間でいちばん顕著なトレンドを一つ挙げるとすれば,何だと思いますか?

ラスマス:それは難しい質問ですね。いくつか候補はありますが――たとえばSSDの登場はデータベースへのアプローチをかなり変えましたね。特にモバイルでの。たしか5年前ぐらいから,モバイルのネイティブアプリが出てきて何もかもが変わりました。

ここ2,3年はどの携帯電話も画面が昔よりずっと高解像度になって,フルブラウザも使えるようになっている。ChromeもFirefoxも携帯で完全に動きますよね。今ではモバイルはデスクトップと張りあえる。事実上ほとんど同じレベルです。私はiPadを持っていますが,大きな画面がついているのにモバイルサイトが表示されてしまうので,たびたびわずらわしい思いをしています。そのたびにいちいちボタンをタップして,いいからデスクトップサイトを見せてくれ,フルブラウザで操作させてくれ,携帯電話用のちまちました簡易サイトなんて必要ないんだ,と伝えなければならないぐらいです。だからこの2年でいえば,モバイルWebがいちばんの大きな変化でしょうね。将来的にはモバイルWebが主流になればいいなと思います。

ネイティブアプリは危険です。いわば壁で囲われた庭のようなものです。昔でいえばAOLです。Webエクスペリエンスというものは,すべてがシンボリックリンクやハードリンクで相互接続された巨大な集合体のようなものであるべきで,ネイティブアプリの中から他のサービスをほとんど意識せずに使えることが望ましい。ユーザーをアプリ内に囲い込んでしまって,AOLみたいにその中でできることしかさせないというのは,一つの方法ではあると思いますが,Webにとっては良くないことだと思うのです。だからネイティブアプリに依存しないでやっていけるようになれば,もっと快適になるでしょう。

PHP7のテストに協力してください

―――― では最後の質問です。PHPのよりよい未来のために,私たち開発者ができることはなんですか?

ラスマス:今すぐできることでいえば,PHP7のテストに協力してください。今はリリース準備を整えていて,いろいろなコードを使ってテストしてくれる人が一人でも多く必要です。まだPHP7に移行する予定がなくても,テストだけはやってくれると助かります。もし動かないところがあれば,どうぞ私たちに知らせてください。その際は,できる範囲で問題を特定してくださるようにお願いします。

ただ「自分のコードが動かない」と言われても対処できません。コードを見て,どの部分が動かないのかを絞り込んでみてください。なぜ動かないのか分からないときは,バグとして報告してください。バグでなければなぜ動かないのか説明しますし,そうでなければ「やあ,これはバグですね。報告ありがとうございます,直しておきますよ」と言います。PHP7がリリースされるときには,あなたのコードはちゃんと動くはずです。私たちに協力すれば,あなたの利益にもなるのです。どうぞご協力をお願いします。難しいことではありません。PHP7を動かす方法はいくらでもあります。

―――― なるほど,PHP7をテストすることですね。

ラスマス:皆さんが作ったものをPHP7「で」テストしてください。もっと何か貢献したいというお気持ちがあれば,バグの修正,ドキュメントの編纂,新機能に関するRFCの作成,手伝っていただけることはたくさんあります。もし特に追加してほしい機能があれば,PHPのWikiからRFCを提出してください。

しかし,まずはバグの修正を手伝っていただけると助かります。いずれPHPのコア部分の開発に関わりたいと考えていますか? いま関わっている人々の大部分はバグ修正から入ってきたのです。実のところ,自分で報告したバグを自分で直そうとしたという場合がほとんどです。たとえば,バグを見つけて報告したのに,6か月経っても誰も反応しない。くそっ,俺のバグ直せよ……とまあ,そんなふうに入ってきた人がほとんどで,別に特別な人たちではないのです。

私たちは毎日PHPを使います。バグに困っていないとき,私は暇を見てときどきバグデータベースを通して眺めるときもありますが……PHP開発に関わる人々はみなPHPユーザーでもあって,自分で使っていて出たバグに集中する傾向があります。もしバグに行き当たったら,自分で直してバグデータベースのバグをクローズすれば,あなたもPHPコード開発者です。そうやってバグの半分をクローズしたら,あなたはもう立派なPHPのコア開発者です。@php.netのEメールアドレスをさしあげます。おめでとう! これで,あなたも私と同じように人々からバグを直せとせっついてもらえますよ(笑)

さて,今日は話を聞いてくださってありがとう。

―――― 長時間本当にありがとうございました。大変興味深いお話をうかがえて,うれしく思います。

画像

コメント

コメントの記入