PHP on Windows ガイドライン
【ドラフト版】
～ 序章: PHP と Windows
※本ガドランは各章の先行ドラフト版公開を行い、全章の公開後、正式版文書としてまとめを行 い、再度公開します。第 1 版 2011/01
マクロソフト株式会社
免責事項: このドキュメントの内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマ クロソフトはいかなる責任も負わないものとします。このドキュメントに記載されている情報 (URL 等のンターネット Web サトに関する情報を含む) は、将来予告なしに変更することがあります。お客様がこのドキュメントを運用した結果の 影響については、お客様が負うものとします。別途記載されていない場合、このドキュメントで例として挙げられている企業、 組織、製品、ドメン名、電子メール ゕドレス、ロゴ、人物、地名、およびベントは、架空のものです。それらが、いずれ かの実際の企業、組織、製品、ドメン名、電子メール ゕドレス、ロゴ、人物、地名、あるいはベントを指していることは なく、そのように解釈されるべきではありません。お客様ご自身の責任において、適用されるすべての著作権関連法規に従っ たご使用を願います。序章 PHP と Windows
今日 ンターネットに公開する Web ゕプリケーションを構築・開発する上で PHP を使った開発 を行う、あるいは著名なオープン ソース Web ゕプリケーションをご利用の方は、実際に動作させ る運用環境として Windows を思い浮かべるでしょうか？ 答えは「否」な方が結構多いのが現実だ と思います。いわゆる PHP の入門書の多くでは Linux に Apache、あるいはご自身でお試しを行う 実験環境としてもお手持ちの Windows XP にさらに xammp のようなツールを使用して環境を構 築するように書いてあるものが多いです。 さて、この方法を採らないと PHP を動作させる環境は作れないのでしょうか。これも「否」です。 どういうことかというと Windows には OS に付属する Web サーバーとして IIS（ゕ ゕ エ ス：Internet Information Services）というソフトウェゕが一部の家庭用のエデゖションを除き、 標準搭載（追加費用なし）されているのでこの IIS を使用する方法が採れます。少し古い文献や記事 を参照すると IIS での設定方法なども載っています。現在ではどうなのか、Linux＋Apache の環境 に匹敵する環境を構築できるのか、当時と同じ方法論でいいのか、そういう情報を整理していくこと にします。 本ガドランではこうした状況に至っている経緯、関係している様々な要素、実際のところどう いうことなのか、最新の PHP と Windows の関係、マクロソフト製品との融合による新しい可能 性について様々な角度から見ていくことになります。また、本章はこうしたストーリー、要因などを 中心とした内容になりますので背景はいいからいきなり具体的な内容から読み進めたい方は 1 章へ と読み飛ばしていただいても問題ありません。本書の目的とゴール
本書の目的は、注意すべき点を踏まえた上で Windows を使用した PHP 環境の詳細な構築方法、 新しい可能性をもたらすマクロソフトの他製品との融合方法を理解いただくことにあります。その 結果、新しいスパスを加えることで選択肢に幅を持っていただき、新しいビジネスを生み出す原動 力にこのガドランで得た知識をご利用いただく、これがゴールです。想定している環境
本書で想定している環境は最新の OS である Windows Server 2008 R2 および Windows 7 で あり、同時に双方に搭載されている最新の Web サーバー、IIS7.5 を使用することです。同様に登場 する SQL Server など他の製品についても最新バージョンを採用します。しかしながら、実際にはい くつかの要素は従来の環境でも適用可能なため、改めて記述した場合においては旧バージョンを取り 上げる箇所もあります。
Windows 環境における PHP 対応の歴史と背景
少し前の記事をンターネットで探すと IIS で PHP の動作環境を構築する手順が多く見つかり ます。しかし新しい記事を見ていると Windows 環境でも Apache を使う方法が多いという状況に なっている要因を考察するとともに実際に IIS は選択肢になりにくいのかを検証してみましょう。何故 IIS が PHP 環境で使われなくなったか
PHP はンターネットに公開している環境でより多く使用されている状況があります。このことか ら非常にセキュリテゖに配慮が必要な環境であることが言われます。2001 年～2002 年ころ、その頃 は特に多く利用されていた（＊） IIS を標的にした攻撃がいくつも行われ、ンターネットで使用す るには 「IIS は怖い」「Windows は怖い」という印象が生まれたものと思います。多くの技術者の 方からここ 5 年ほど聞いてきたお話ではほぼこの点を必ず挙げます。 ＊攻撃者の目的からその時点でシェゕが多い製品をターゲットにすることが有効である マクロソフトが積極的に PHP 環境構築に関する情報提供や環境改善をしなかったことも一つの 要因でしょう。Apache では継続してコミュニテゖの要件に応じてレスポンス向上やモジュール開発 が行われ、広く誰でも使える状況にあったのに対して、マクロソフトでは OS のセキュリテゖ強化、 IIS のセキュリテゖ強化が至上命題で、自社のテクノロジーである ASP や ASP.NET のセキュリテ ゖも含め、この頃は全開発チームのプロセス変更までをセキュリテゖを一義に作り替えるという大改 革をしていました。結果として今 出荷されている OS や IIS は逆に凄く攻撃に強い製品になってい ますが、PHP の環境を構築するプラットフォームとしては進化をしませんでした。 IIS バージョン OS バージョン ゕドバザ リー数 脆弱性数 パッチ 未対応数 パッチ 未対応率 IIS 5.x Windows 2000 21 12 1 * 5%IIS 6.x Windows Server 2003 11 11 1 * 9%
IIS 7.x Windows Server 2008 / R2 Windows 7 6 6 1 17% 表 1 ： Secunia.com での各 IIS バージョン間対比（2011 年 1 月上旬時点） ＊存在している未パッチのものは深刻度の低いもので、パッチが不要と判断されたもの 脆弱性報告サト – Secunia.com http://www.secunia.com
表からもわかるように、より新しいものの方がセキュリテゖは向上していますし、ほかの製品と比較 しても遜色ないレベルにセキュリテゖ強化が進んでいます。ただ、悪意のある攻撃者は攻撃手法をど んどん進化させていくので、ある時点のスナップショットを見るよりは時々状況を確認したほうがい いでしょう。 この Secunia.com というサトはマクロソフト製品だけを扱っているわけではないのでセキュ リテゖの検討をする上でとても参考になります。Apache などもあるのでぜひご自身の目で IIS の今 をご覧ください。また、これらのゕドバザリーのページを見るとやはりシステムへの不正ゕクセス や DoS 攻撃の比率が高いことがわかりますので攻撃の種類という観点でも参考になるでしょう。なお、 製品間で比較するにはカウントしているものの性質からゕドバザリー数≠脆弱性報告数なので単純 比較は難しい点はサトに明記されているのでその点はご承知おきください。 ここまで書いてきた機能向上の進化度合いやセキュリテゖの観点も大きな要素なのには間違いない のですが、最も大きいのは発展したンターネット上での情報量の差が大きいでしょう。つまり、初 めて何かをする時に頼りになる記事の存在や問題解決を迅速に行うための障害報告事例などが Apache 上で PHP を利用している人からの発信が圧倒的に多く、Windows＋IIS 上での情報が少な いために利用者が心配だったからというのが一番心理的には効いていると考えられます。メーカーで あるマクロソフトからも積極的にこの領域の情報発信は行ってきていませんでした。
Windows 環境における PHP 対応の方法論
ではより具体的に方式論やほかの要素を検討することにします。IIS で PHP を動作させる方式の議論
PHP を利用する方が参照する情報として最も見られるのは書籍などもそうですが、やはり php.net のサトでしょう。つい最近までここには ISAPI（Internet Server ApplicationProgramming Interface）という方式での環境構築方法が掲載されていました。現在は IIS7 だけで
なく IIS5 や IIS6 でも CGI（Common Gateway Interface） を改良した FastCGI という方式で 構築するのがマクロソフトの推奨であり、php.net でも FastCGI の手順に更新されています。
IIS 上でのンストール手順（Microsoft IIS 5.1 および IIS 6.0）
http://www.php.net/manual/ja/install.windows.iis6.php
IIS 上でのンストール手順（Microsoft IIS 7.0 以降）
さて、これらは原理的にどう違うのでしょうか。これには少し Windows の動作を知っている必要 があるのでコラムを挟みましょう。ご存じの方は飛ばしていただいて問題ありません。
コラム - Windows でプログラムが動作するメカニズム
なぜこの解説をここでしているのかわからないかもしれませんが、最後につながりますのでこのコ ラムを読むと決めた人はぜひ読み飛ばさずに順番に読みましょう。 Windows という OS では実行できるプログラムはほぼ .exe という拡張子が付与されています。 例えば メモ帳は notepad.exe で、電卓は calc.exe です。通常はメニューからクリックかダブルク リックして実行してしまうので気づかないかもしれませんが、実体はそうなっています。 ではプログラムが実行されるときにはどういう空間で実行されているのでしょうか？メモ帳空間と か電卓空間があるわけではありません。Windows ではプロセスとスレッドという二つの概念があり、 １プロセス内で複数のスレッドが実行される関係にあります。一つの実行はスレッド一つになります。 Windows にはタスク マネージャーというツールがあり、内部実行状況を知ることができます。最 近の OS では Ctrl+Alt＋Delete を押した時に出るメニューから実行できます。表示メニューから列 の追加でプロセス ID とスレッドを追加すると下記のような画面になります。 図 1：Windows タスク マネージャー に PID とスレッドを表示 図のように、Calc.exe というプロセスは ID が 7040 で、スレッド数は６つ動いているのがわかり ます。実は最近のプログラムは単体でものが動くのではなく、このように複数の同時実行が内部的に 行われていることが多いのです。これでプロセスとスレッドの関係は押えました。 さて、今度はある疑問を持っていただきたいです。Windows でシステム開発を長くやっている人 であればみんな知っている常識についてです。６つのプログラムを同時に動かしたい時に 6 プロセス で動かすのがいいのか、6 スレッドで動かすのがいいのかという話です。実はプロセスを１つ起動する処理というのはミクロなレベルでみるととても大きな重い処理なのです。「塵も積もれば山となる」 の言葉の通り、実は毎回プロセスを起動するのはパフォーマンス上よくないです。 さらに、あるプロセスのプログラムから別のプロセスのプログラムと通信を行うような処理があっ た場合には同一プロセス内で行われるよりもプロセス越えのオーバーヘッドが発生し、時間とリソー スを余計に使用します。つまり、Windows では「同時実行していて相互に影響し合うものは同一プ ロセス内で実行すべし」という常識が存在します。 少し話を戻しましょう。最初に .exe という拡張子の話をしました。.exe を実行するとプロセスが １つ起動する仕組みになっています。一方で .dll という拡張子のフゔルも別の実行形式として知ら れています。でもやったことがある人も多いと思いますが、.dll のフゔルはダブルクリックしても エラーになります。これは .dll は単独で起動することを想定していないフゔルだからなのです。で はどう動作するかというと、.exe の補助として内部で動作するのです。ちょっと無償でダウンロード できるとても便利で重宝するツール Process Explorer で見てみましょう。電卓一つとってもこれだけ の.dll が読み込まれているのがわかります。 図 2：Process Explorer でのプロセス内 DLL 実行状況の確認
Microsoft TechNet SysInternals - Process Explorer
http://technet.microsoft.com/ja-jp/sysinternals/bb896653
これで Windows の内部動作が少しクリゕになったと思いますので、本編を進めましょう。この Process Explorer の置いてある SysInternals は非常にいいツールが多いので覚えておくといいで しょう。
ISAPI 方式とは？
従来 IIS で PHP を動作させる場合には ISAPI 方式でのンストールが推奨されていました。 ISAPI ではどのように動作するのかというと、IIS がゕプリケーションを実行するプロセスの中で PHP ランタムに含まれる .dll や拡張の .dll を実行するものです。つまり、同一プロセス内で実行 されるので高速である特徴があり、PHP ランタムおよび使用するすべての PHP 拡張も複数のスレ ッドで動作することを知っていて、スレッド間でのやりとりや同期タミングをしっかりハンドリン グしていないと不定な動作をするという観点も非常に大事です。 図 3：ISAPI 方式での PHP アプリケーション実行（IIS7） IIS の開発者たちも高速な方式なので最初はこの ISAPI 方式を押していたのは当然でした。しか し、この ISAPI 方式で何が起こったかをお伝えしましょう。PHP のランタム自身はダウンロード のサトでも確認できるように Non Thread Safe と Thread Safe が別々においてあります。なぜ 2 種類あるのか疑問に思った方はこれまでの説明で少しずつ解明されてきたでしょう。図 4：PHP ランタイムの Windows 用バイナリーのダウンロード
図は最新の 5.3 になっていますが、このように別々になっていたのは今までと同じです。スレッド を意識して開発した意味の Thread Safe の方を ISAPI 方式では使う必要があるということです。
よしこれで Windows＋ISAPI でも何の問題もなく安定して動作するだろうとみんな思いました。な かなか現実の世界はそうはいかないようにここでも色々と現場で苦労された方がいらっしゃいます。 実際にはどのようなことが起きたかを書きましょう。 歴史的にマクロソフトの製品サポート窓口にも PHP 動作環境について問合せが入ることが結構 ありました。どうも ISAPI 方式で PHP 環境を構築したら安定しないという問合せの割合が多いと いうことがわかりました。当然のように厳密な調査をしていくと ISAPI はちゃんと動作しているよ うで、IIS 自身も正常に動作しています。多くのケースで何が起きていたかというと問合せ者が利用 している PHP 拡張のいくつかが Windows を意識していなくてスレッド対応していなかったこと が原因でした。
総合すると、ISAPI 方式は IIS で利用する場合には ASP や ASP.NET でも利用されている方式 なので、高速ですべてのプログラムがスレッドを意識した Windows プログラミングを行えていて、 作法を守っていれば最適な方法論だったのですが、現場では多くの問題が起きてしまいました。
CGI 方式とは？
ンターネットの歴史上、かなり早い段階で登場したのがこの CGI というプログラム実行方式にな ります。知っている方も多いと思うので、Windows での実装はどうなるのかを中心に解説します。
IIS で CGI 方式を利用する場合、IIS がゕプリケーションを実行するプロセスから PHP のリクエ ストがある度に別のプロセス（php.exe とか php-cgi.exe）を起動し、処理が終わるとそのプロセス を終了させるという動きをします。Windows ではプロセスを起動する処理というのはパフォーマン ス上ではすべきでないことの筆頭に挙げられるので、CGI 方式を採用すると圧倒的にパフォーマンス 面で不利となります。 図 5： CGI 方式での PHP アプリケーション実行（IIS7） 一方で、CGI 方式ではリクエスト毎にプロセスが起動するので、スレッドを意識したプログラミン グをランタムや拡張がしている必要がないので Non Thread Safe のバナリーが使用できます。 性能面を相殺するほどではないですが、今度はランタム側にスレッドを扱う処理が不要なので少し 使えるバナリーの面で有利になります。
FastCGI 方式とは？
それでは最後にマクロソフトが現在推奨方式としている FastCGI を解説します。もう流れが読 めている人も多いと思いますが、そうです、両方のいいところを可能な範囲で持ち込んでいるのがこ の FastCGI 方式ということになります。 実行方式としてはやはりリクエスト単位で php-cgi.exe を起動するのですが、終了しないで再利用 するのです。このことにより、最もネックになるプロセスの起動回数を効果的に減らし、かつ有利な Non Thread Safe のバナリーを使用し、PHP 拡張側にもスレッド対応処理を不要にすることで不 安も取り除きます。図 6：FastCGI 方式での PHP アプリケーション実行（IIS7）
以上が、現在 Windows＋IIS 上で PHP 実行環境を構築する概念の整理です。実際の詳細な設定 手順は以降の章で取り上げることになります。
PHP から Microsoft SQL Server に接続する方式の議論
多くのオープン ソース Web ゕプリケーションではデータを多く扱うため、何かしらのデータベ ースを利用しています。そして PHP 関連では MySQL あるいは PostgreSQL が使われていること が多いです。両方ともコミュニテゖで醸成された便利なデータベースです。
しかし、お客様の要件で Microsoft SQL Server （以降、SQL Server）を使いたい、もう既に構 築されているので運用する技術者も SQL Server の方がいいと言っている、SQL Server のあの機能 をそのまま使えば開発が要らない など PHP のゕプリケーションから SQL Server に接続したいと いう要件は確実に現場にあります。 ではこちらも PHP の実行環境と同様の整理をしていきます。
PHP ランタイムに含まれる php_mssql.dll あるいは FreeTDS
ンターネットを探すと SQL Server に接続する方法はいくつか見つかります。どれについても情 報はそれなりに見つかりますが、問題の対応方法を探すのは大変なようです。やはり MySQL や PostgreSQL のようにスムーズにはいかないのが正直な現状ではないでしょうか。 そして TDS プロトコルをそのまま利用する方式は SQL Server のゕクセス方法としてマクロ ソフト テクノロジーだけで構築したゕプリケーションでは選択肢の一つとしてそもそも思いつかな い方法になり、もう一般的ではありません。 もう一つはこれらの方法論に代わるデータベース側のメーカーとしてマクロソフトが PHP 向け には Java 向けのようにドラバーなどを提供してこなかったことも一因としてあります。マイクロソフトが提供し始めた SQL Server Driver for PHP
そして「現在」はどうかという話です。ここ数年、マクロソフトのオープン ソースへの歩み寄り が加速度的に進んでいる一つの例でもあるのですが、SQL Server に PHP から接続するドラバー がついにマクロソフトの SQL Server 開発チームの一角から 2008 年 7 月に発表されました。
SQL Server Driver for PHP 開発チームブログ
http://blogs.msdn.com/b/sqlphp/
この発表されたバージョン 1.0 は UTF-８ 未対応など様々な点において日本市場で使うにはまだ 機能が不足していましたが、その後に開発された 1.1 で UTF-8 対応が実装されました。
このドラバーはマクロソフト系の開発テクノロジーで使われてきて実績豊富な ODBC ドラ バーを呼び出すラッパー（薄い層）構造で開発されていますので、このドラバーが動作するマシン
は Windows OS が動作している必要があります。一方で、PHP からの利用はほかの PHP 拡張と同 じように php.ini で有効にする形で利用できます。
図 7：SQL Server Driver for PHP v1.0~v1.1 の構成
また、ここでも PHP ランタムが Thread Safe を使用しているか、Non Thread Safe を使用して いるかで区別があり、有効にすべき拡張が異なりますので注意が必要です。
つけ加えると、このドラバーのソース コードは CodePlex というマクロソフト系の Forge サ トに Microsoft Public License (Ms-PL) で公開されています。
Microsoft Drivers for PHP for SQL Server project
http://sqlsrvphp.codeplex.com/
SQL Server Driver for PHP v2.0 の登場
本ガドラン執筆時点では v2.0.1 というバージョンが公開されています。v2.0 の最も大きな 特徴は PDO 経由でのゕクセスが可能になったことで、これにより最もシンプルなケースの場合、接 続文字列を変更するだけで MySQL などから SQL Server への接続を切り替えることができるよう になりました。
Microsoft Drivers for PHP for SQL Server ｖ2.0 入手先 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=80e44913-24b4-4113-8807-caae6cf2ca05 このドラバーをンストールする手順や詳細についても以降の章で取り上げます。 なお、日本でもこのドラバーに関する様々な情報を集約していく予定で以下のサトを立ち上げ ていますので今後も便利にご利用いただけるように維持していきます。 PHP 開発者のための SQL Server 入門 http://www.microsoft.com/japan/web/sqlphp/
Web Platform Installer について
ここまでの要素をご理解いただいた上で実際に環境構築する手順などは以降の章で解説するのです が、各章で登場しますので手動の設定方法以外で便利な方法（ツール）をご紹介しておきます。
マクロソフトでは各種環境構築における利便性を考え、Web Platform Installer（以下、Web PI） という無償の統合ンストール ツールを提供しています。
この Web PI のコンセプトは Web サトの構築を簡単にかつ短時間で実施することを目指した もので、WordPress のような オープン ソース Web ゕプリケーションをンストールできるほか、 PHP, IIS, SQL Server, .NET Framework など色々なコンポーネントのンストールも可能になっ ています。最新のバージョンは v3.0 になっています。
Web PI によって Web サーバーを入れて、PHP を入れて、データベースを入れてという手順を 踏むのではなく、「ｘｘｘゕプリケーションを入れる」と指定するだけで必要なコンポーネントの依 存関係を解決しつつ、順番にダウンロードし、ンストールすることが可能になるのです。 もう一つ 面白い点は、ダウンロードするコンポーネントの組合せや依存関係、ダウンロード先をパ ッケージしたものをオープン ソースのコミュニテゖの方が実施している点です。したがって、たとえ ば OS の一部である IIS のパーツをンストールする部分はマクロソフトが提供していますが、 WordPress のンストール手順をパックしたものは WordPress のコミュニテゖが、同様に XOOPS のコミュニテゖが、EC-CUBE のコミュニテゖがという具合にこの仕組みはできています。 ただし、リストに表示するにはゕプリケーションの登録が必要で、リスト自身はマクロソフトのサ ーバーで維持しています。ゕプリケーションの登録先は Windows Web Application Gallery と呼ん でいます。 実はこの構造になっていることでンストールする達人のノウハウがそのまま生かせるという大き な利点があります。初めてンストールする場合でも新しい問題や環境要素が無ければ本当に素早く 簡単にンストールが可能になっています。 PHP ゕプリケーションをかんたんにンストールできる無償ツール http://www.microsoft.com/japan/web/ それでは実際の構築作業や新しいコンポーネントの話に進んでいただきましょう。次章からは手順 の提示と解説を行っていきます。
