PHPカンファレンス2014 当日レポート［更新終了］

10月11日、大田区産業プラザPiOにて「PHPカンファレンス2014」が開催されています。本稿では、本イベントの各セッションの模様を随時更新形式でレポートしていきます。

今年はセッショントラックが3つ、ワークショップトラックが1つ、計4トラック構成です。そのため、すべてのセッションはレポートできません。ご了承ください。

今年は4Fが受付になっています。

4F受付近辺にはスポンサーブースがあります。ぜひお立ち寄りください。

Ustreamの中継が行われています。

今年もWordCamp Tokyo 2014と共催です。WordCampの会場は1階です。

また、1Fにはジュンク堂書店が出張所を出しています。サイン会も予定されています。

オープニング

PHPカンファレンス2014委員長の前島有貴さんより、オープニングの挨拶がありました。今年のテーマは「知りたい、があなたを変えていく」です。様々なセッションを用意したので、ぜひイベントを楽しんでほしいと話しました。

今年は、スポンサーブースを回るスタンプラリーを用意したとのこと。全部回ると景品がもらえるそうです。

スタンプラリーについて

スタンプラリーの景品としては、書籍などがあるようです。

廣川類さん「基調講演⁠」⁠

オープニング後に、今年も廣川類さんによる基調講演がありました。

自己紹介

廣川さんは、次に挙げた活動を行っています。

PHPマニュアルの翻訳をされています！
mbstringエクステンション開発
PHPカンファレンス皆勤賞（15回連続！）

PHPの簡単な紹介

まずはPHPを紹介しました。PHPは主にWebアプリケーションで使われてきてました。早20年弱になり、Webとともに成長してきた言語と言えます。

W3Techs.com調べでPHPは次のようなシェアを持っています。

サーバサイドスクリプトとして8割近いシェア
CMSでもWordPress、Joomula、Drupalとシェア上位3つがPHP製

つまり、枯れてきていると言われていながらも、いまだに多くの人に使われているということです。

PHPのこれまで

2004年にバージョン5.0がリリース、その後毎年新しい5.Xバージョンをリリースしています。

2014年現在、5.3がまだ5割以上使われています。しかし今年でEnd Of Lifeになりました。

5.4はリリースから2年経ち、残りの1年はセキュリティFIXサポートのみになります。つまり、ライフサイクルとしては、リリースから2年がバグサポート期間、1年はセキュリティFIXのみサポートという3年サイクルになっています。

そして今年5.6がリリースされました。速度改善は5％程度で、既存の速度改善については大分やり尽くした感ありますと述べました。ベンチマークでは、5.4以降速度の変化は差程なくなってきています。

主な機能追加は、次のとおりです。

...構文
可変長引数
函数引数におけるデパック
phpdbgデバッガ標準化、SAPIで動く（一番大きい）
文字コード設定標準化
関数や定数のuseが使える

新しいPHPに向けて

今後のPHPに触れる前に、HackとHHVMについて触れました。HackはHHVM用言語（PHPの拡張）です。大規模開発の効率化に適しており、gradual typingが便利だそうです。HHVMはFacebookでおなじみHack実行環境です。リソース低減化と速度改善にスーパー威力発揮します。

そして5.7は、言ってしまうとPHP7までのつなぎ（メインの開発は7のほうに注力しているため）で、2015年8月予定で機能内容も未定だそうです。

PHPの未来

Hack、HHVMリリースのもつ意味として、「⁠Web進化に迅速に対応できているか」「⁠外部開発者との密な連携をとれているか」という点をこれから追いかけていくことになりそうです。しかしPHPとしてはこれまでの「初心者にやさしい言語」というのを続けていく方針とのこと。これはアイデンティティの一つですしね！

蒋池東龍さん「PHPコアから読み解くPHP5.5⁠」⁠

蒋池東龍さんは最初に、「⁠PHPコアとは？」「⁠Zend Engineとは？」「⁠オペコードとは？」についての説明を行いました。PHPコアを理解することは、PHPがどのように動いているのかを理解することになります。PHP5.5での新機能について、PHPコアから読み解き、紹介しました。

いくつかあるものから3つのポイントについて抜粋して紹介がありました。ジェネレーターyieldの追加、boolval()の追加等です。

ジェネレーター

ジェネレーターのyieldを使えば、共通するイテレーション処理を一度定義するだけで楽に書けます。その一般的なサンプル紹介ではなく、これをPHPコア（オペコード）の観点から比較しました。処理速度について、yeildを使うほうが早いので、皆さんyieldを使いましょうということです。

boolval

また、boolvalの関数の機能の紹介があった後で、同じ用途で利用できるcastとの比較がありました。結論として、できる限りcastを使いましょうと話しました。

鶴岡達也さん「フリマアプリ「メルカリ」の超高速開発を支えるPHP」

iPhone、Androidとマルチプラットフォームに展開中のフリーマッケットCMSを開発しているメルカリの鶴岡達也さんのセッションです（このセッションはタイトルは超高速参勤交代をインスパイア！したものだそうです⁠）⁠。

はじめに

最初にメルカリについて紹介しました。メルカリは、ものを売りたい人がスマホで撮って気軽に出品できるアプリです。メルカリがお金を一時的に受け取る形で、安心を提供しています。毎日10万件以上が出品されており、月間流通額は数十億円あります。テレビCMも開始しています。

サーバー構成

サーバー構成は現在は60台です。昨年の今頃はサーバーは1台（1万円程度）のみで運用してしいましたが、1年で60倍になりました。

現在の構成は実は3代目だと言います。2世代目でWEBとDBを切り離し、3代目でロードバランサとキャッシュを用いて負荷分散という成長を遂げてきました。

第1世代はキャッシュサーバーすらない状況で、Apache＋mod_php＋MySQLという構成でした。第3世代ではロードバランサとしてnginxを使っています。

メイン言語は実はPHP

開発にPHPを選んだ理由は、創業メンバとつながっている開発者の多くがPHP開発者で確保しやすかったということ、そして単に身近だったからだそうです。

安易に見えますが、実は重要だったこととして（後述のマインドの話にも共通しすが）「⁠現実的な問題」を解決したかったを挙げて強調していました（モダンな言語を駆使することが目的ではなかったとも話していました⁠）⁠。例えば、WordPressがPHP以外の言語でつくられていれば今ほどの勢いはなかったのではないかと指摘し、身近に問題解決していることの価値をもっと認めようと述べました。

さらに、現在のメルカリの平均レスポンスタイムは50ms台で、普通に使えるレベルです。簡単なのに実用的であること、他言語の技術者でも、すぐ習得できてしまう等のメリットがあることも付け加えられました。

とはいえ、現在のシステムで良くない点もあります。それはメルカリはバッチ処理が多いことです。データを大量に取り入れてプッシュ通知を送る処理は、PHPは不得意だと言及。これに対する対策は「得意な言語に任せる」のがよいとしました。

また、PHPのプログラムを常駐させていると、サーバのメモリを消費してしまうため、たいへんなことになります。できるだけプロセスを落として起動して……と現状は再起動を行っていますが、今後はネックになると考えており、いずれは先の例と同じく「得意な言語に任せる」という話になりそうだと述べていました。現在はサーバースペックでカバーしているそうです。

どんな考え方で開発してきたか

メルカリはまだ成長段階だと言います。日本に限った上では2013年一番成長した会社とは言われてますが、0から100に達する中で1に過ぎないと考えているそうです。会社としてはスピードが最も大事だと考えていて、リリースするまでのスピードを意識しています。具体的には「もっとゆっくり作ればよかった」ということはありえない、という意識を共有していると話していました。

サービスはいくら丁寧に作られていて良くできていても、誰も使わないのであれば意味がありません。そのため、次のことを念頭においているそうです。

継続して作るためには、スピードが必要。
実際スピードを出すのに難しいことって開発者、予算、時間どれも足りないのが普通。

そして、具体的な方法として次のことを挙げました。

1. 迷ったら単純なほうを選ぶ
- 「低機能だけど単純なもの」を選ぶと学習コストが低く、短期的に結果が出てくる。半年、1年先のメリットよりも今が大事。
2. 最高だと思うものの6割で出す
- 「完璧を目指すより、まず終わらせろ」というFacebookの考え方に似ている。
3. 最も重要なことにフォーカスする
- メルカリの場合はホーム画面に表示される商品の一覧にフォーカスし、良くなってきた。盛り込む機能は限界まで絞っていて、初期はAPIが95種類だった（現在は171種類ある⁠）⁠。また、インフラも最初は高性能な専用サーバ1台にすべて詰め込むことで、本番環境は1日で構築できた。2ヶ月で負荷限界になったが、それでも準備期間は短くなった。

しかし、スピードのためにすべてを捨ててはいけないと話します。具体的にはテストは省略しすぎないことを指しました。PHPUnitでどんなテストを書くべきかよく考えたそうです。

ただ、費用対効果の高いテストを書くのは、開発者のセンスが問われます。未来の開発者が救えるかどうかという視点が重要で、カバレッジではなくエンドツーエンドで正しさをテストすることを挙げました。エンドツーエンドのテストがあれば、安心して元のコードを大胆に変更できます。また、優れたテストがあれば、テストのためにコード品質が犠牲になっても許容できるとしました。

まとめ

最後に、「⁠PHPで素早くハイパフォーマンスなアプリを作りましょう。別の言語でつくろうとかではなくて、PHPで自信を持って出していきましょう！」と述べていました。

岸田健一郎さん「擬人化から始めるPHPerのためのオブジェクト指向超入門⁠」⁠

岸田健一郎さんの発表です。今日はオブジェクト指向のプログラミングではありません！と述べ、セッションが始まりました。

class Hogeやら、class Fuga implements FugaInterfaceとかのオブジェクト指向を実現するための構文はさておき、現実世界の話を例に、オブジェクト指向とはなにか？を理解することを目的としたセッションです。

そもそもオブジェクトとは、複雑なタスクを実行するためにコミュニケーションを取り、協調して課題を解決するためにあるもの。いくつかのステップを経てオブジェクト指向を理解していきましょうと話しました。

「生命と知性を与える」「⁠対話形式を用いる」ことにより、実世界に見えない存在も考えだすと言います。つまり、擬人化できます。そしてオブジェクト指向の場合、次の6パターンのいずれかの役割になるそうです。

情報保持役
- モデルやエンティティ。情報を知ってる。保持するデータから計算するのはOK。
構造化役
- ざっくりグループ化する。リストや配列、ハッシュとかキューとか。エンティティの関連とかを表現する。
サービス提供役
- 特殊な処理を提供する。WorkerやWriterみたいに、-erになっているクラスを見つけたら、それは大抵サービス提供役。
制御役
- 他の複数のオブジェクトから状況を聞き出して判断する。判断した結果を支持する。
調整役
- あるオブジェクトから情報を受け取って、他のオブジェクトに渡す。
インターフェース役
- イベントを受け取って、誰かに依頼したりする。

まずは、それぞれの性格（ロール）を決めます。フレームワークでよくあるcontrollerが太るとかは、MVCの3つという枠組みだと、1つのクラスが肥大化してしまうことです。

ここで、実現したい機能について役割を書き出してみます。その際、「⁠適切な名前をつけること」「⁠6つの中の役割にあてはめてみること」を考えるようにします。次の例を挙げて説明しました。

1. 社長が雑談している時の社長の発言を保存したいとき
- (登場人物)社長、秘書、広報、事務
- 社長→秘書「⁠今日xxxなことがあってさ。社長語録に書き留めて、SNSに投稿しておいて」
- 秘書→事務「⁠社長語録に記録しといて」
- 秘書→広報「⁠SNSで広めておいて」
2. コピーを10部ソートしてホッチキスとめしたいとき
- (登場人物) 社長、コピー係、複写係、ソート係、ホチキス係
- 社長→コピー係「⁠コピーしといて」
- コピー係→複写係「⁠印刷しておいて」
- コピー係→ソート係「⁠並べ替えておいて」
- コピー係→ホチキス係「⁠ホチキス留めておいて」

この時、上記の関係を図に書くことが重要だそうです。性格が決まると責務はおのずと決まってきます。

オブジェクトの相互作用も明確になります。PHPにおいての関連性は、「⁠クラス名＝役割」「⁠プロパティ＝性質」「⁠メソッド＝できること」になります。

最後に、実現したい機能を、まずは擬人化して図を書くことから始めると学びやすいこと、オブジェクトデザインを入門書として読んでみてほしいと述べていました。

do_akiさん「mysqlnd 徹底解説⁠」⁠

do_akiさんはmysqlndを解説しました。

PHPとMySQLの間のアクセスは、現在すべてlibmysqlまたはmysqlnd（MySQLNativeDriver）のどちらかを介して行われています。mysqlndで注目されている新機能には、非同期クエリやパフォーマンス統計があります。

libmysql vs mysqlnd

do_akiさんは、双方の違いを説明していきました。

libmysqlclient：Oracleによって開発
mysqlnd：PHP communityによって開発

したがって、当たり前ですがコンパイル方法が違います。mysqlndはPHP5.3以前では使えません。5.3からバンドルされるようになり、5.4になってmysqlndがdefaultになりました（libmysqlはオプショナルに⁠）⁠。

なぜ似たような機能をもつものが2つあるのか、という疑問に対しては、ライセンス問題の解消が主な目的であるとのことです。libmysqlはGPLv2という若干特殊なライセンスであり、同梱して別のところに配布ができないのに対し、mysqlndはPHP Licenseであり、基本的にライセンス面を気にしなくてよいです。

また、libmysqlは、他の言語でも使えるのに対し、mysqlndはPHPのみでしか使えないという点も挙げていました。互換性にも問題があり、mysqlndで使えなくなった機能があります。PHPのバージョンを上げたことによりライブラリもmysqlndに変わり、それによって正しく動かなくなることがあるので注意が必要です。

mysqlndの内部

プリペアドステートメントを使う際、mysqlnd内部の特徴として型の問題があります。今までPHPではstring型で格納されていたものが、カラムの型そのままで入るようになります（気づかずに、はまりやすい！とのこと⁠）⁠。この変更はPDOを使った場合のみで、mysqliの場合は元々binary protocolでカラムの型で取ってきます。

また、mysqlndはメモリ使用量が少なくなると言われていますが、それは次の理由があります。

libmysqlではMySQLから返ってくるデータに対し二回変数コピーが走っているイメージ
mysqlndは単純にデータをそのままPHPスクリプトに返す

ただ見た目上のメモリ（get_usage_memory()で取れるメモリ）は増えていたりするため、memory_limitを設定している場合はひっかかってFatalエラーになりやすくなる、という盲点があるそうです。

最後に結論として、使い方によっては便利なmysqlndですが、PDOの場合はあまり使用量が変わらなかったりするので、フルで使いたいなら現状はmysqliを使いましょうと述べていました。

徳丸浩さん「安全なPHPアプリケーションの作り方2014 ～必要最低限のセキュリティ対策はこれだ～⁠」⁠

徳丸浩さんは、安全なPHPアプリケーションのセキュリティ対策について発表しました。これまで何回も同じ題目で話してこられていますが、今日は基礎的なことにフォーカスしました。

PHP自体の脆弱性

IPA「セキュアプログラミング講座」によると、脆弱性対策として「例えばPHPを避ける」ことが挙げられています（会場笑い⁠）⁠。これは、PHP自体に脆弱性が多いという観点からのものですが、徳丸さんに言わせると、それは過去の話であるとのこと。

たしかに比較演算子などはゆるい部分もあったり、たまにすごい脆弱性が出てくるのも事実ですが、それはどの言語でもありえるのでPHP特有の問題ではありません。一番大変なのは、ほぼ毎月行われるバージョンアップについていくことで、その情報をキャッチアップして対策していくことです。

この対策に対する基本的な選択肢は、次のことを挙げました。

PHPバージョンアップにとことん付き合う（毎月確認する）
影響を受ける脆弱性がある場合のみバージョンアップする
LinuxディストリビューションのパッケージとしてPHPを導入してバッチを適用する

また、ハウジング、Iaas/VPS, Paas, Saasそれぞれの脆弱性対処のメトリクスを示しました。ハウジングで自分たちで対策を行うことは脆弱性対処の責任も負うことであるのに対し、クラウドであれば基本的には行ってくれます。ただし細かいパッチ適用など、ベンダーによっては要確認であると注意喚起しました。

アプリケーションの脆弱性を対処しよう

次に、CSRF（クロスサイトリクエストフォージェリ）を説明しました。昨年今年と巷を騒がせた片山被告の最初の事件と同様のCSRFをサイトに仕込み、犯行予告の書き込みをデモンストレーションしてみせました。また、日本で最も売れているPHP教科書でCSRF対策していないと、チクリ刺すのも忘れていません。

続いて、XSS（クロスサイトスクリプティング）の説明では、「⁠ぼくはまちちゃん！」をデモしました。

「出力をエスケープしましょう」というこれまでのアドバイスに加えて、特筆すべき注意喚起としては、「⁠JavaScriptの動的生成はやめましょう」とのことです。「⁠JavaScriptのエスケープ処理は人類には難しすぎる！ので、HTML上に値を生成して、それをgetElementBy**()などで取得したほうがよい」と言及しました。

また、最近はブラウザ側で対処してくれることが多いですが、まだIE6を使ってる人も実際存在しますし、他の脆弱性の可能性もあるので、サーバサイドで対処しておくのもまだ忘れないようにしましょうと指摘しました。

最後にSQLインジェクションを取り上げました。最近になって、MySQL＋PDOでもDB改ざんの可能であることが判明しました。これはおそらく最もよくあるパターンなので、今もまだ多くの開発者が対応しなければなりません。

具体的な対応法は、これまで同様に次のようになります。

プレースホルダーを使いましょう
静的のほうがよい
接続時に文字エンコーディングを必ず指定する

その他、HTTPヘッダインジェクション、セッションID固定化の問題にも触れ、この後の大垣さんとのセッションへの布石も打っていました。

まとめ

アプリケーション脆弱性対策は、現在のPHPの実状に沿った現実的な対策を上記例を挙げて説明しました。プラットフォームの脆弱性を対策については、「⁠自分でビルドするのか、プラットフォームの脆弱性対策に任せるのかの判断が大切である」と述べていました。

梅田昌太さん「PHPerがAWSと出会ってDevOpsを目指した話⁠」⁠

アプリケーションエンジニアである梅田さんが、Rettyのサービス拡大とともに発生した問題とどう向き合ってきたかについて紹介しました。スタートアップで、サービスの機能を追加していくことと、ユーザーが増えて発生する問題の解決を両立させて進めていくために、という話はとても興味深かったです。

まずは、Rettyのサービスについて紹介しました。インフラ構成別で分類すると次のようになっています。

retty.me レティのサービス
news.retty.me レティのニュース配信サービス
owners.retty.me レティの飲食店様向けのサービス

次に、サービスの成長に伴うインフラの構成と、その際に発生した問題を説明しました。

～5万ユーザ：VPSで稼働。
10万ユーザ～：AWSに移行（EC2のみで稼働⁠）⁠。
50万ユーザ～：AWSアーキテクチャを意識し、EC2からサービスを分離。
100万ユーザ～：EC2の冗長化をして、スケールアウトし始めた。また、Nagios, Monitによる死活監視を始めた。
200万～400万ユーザ：サブドメインをAWS＋VPCに移行。32bit amazon linuxから64bit amazon linuxにし、MySQL・PHPのversionをバージョンアップした。
～500万ユーザ：ログをTreasureDataに移行し、CIはCircleCIで回すようにした。

また、Opsを楽にしてくれたサービスたちの個人的ランキングも紹介しました。

1. Elastic Beanstak（オートスケールｘ自動デプロイ⁠）⁠
- Heroku toolみたいなもの。gitのリポジトリをデプロイできる。Environemnetとコミットを指定してデプロイ。
2. RDS
- 高いが、Multi_AZは素晴らしい。メンテフリーで、気軽にスケールアップできる。
3. S3
- EBSで、でかいインスタンスを用意するのはあまり良くない。

最後に、大事だと思うこととして、「⁠自前で解決することもできるが、コストがかかっても、運用コストを下げてアプリケーションの開発に専念すること」「⁠AWSが推奨するアーキテクチャに乗って、インフラはAWSに任せること」を挙げていました。

中野拓さん「PHPにおけるI/O多重化とyield⁠」⁠

中野拓さんは、1つ1つのマイクロサービスを複数のAPIでコンポーネント化して実現する際に、増えるI/OをPHPでどのように多重化するかについて説明しました。

まずは、マイクロサービスはどうしてI/Oが遅くなるかを紹介しました。

マイクロサービスとは、ライブラリではなくweb APIによってアプリケーションをコンポーネント化してつくることを指します。その際、ネットワークI/Oは遅いので多重化します。このI/Oを多重化のためにPHPの非同期APIを使うことになります。

真のI/O多重化としてcurl_multiを取り上げましたが、これを書くのは大変だと紹介し、書きやすく抽象化したいと言います。

例えば、node.jsは1スレッド1プロセスですが、同時に複数のリクエストをさばくことができます。また、あらゆるI/Oが徹底的に非同期・多重化されています。このnode.jsを真似たものにReactPHPというのがあります。ただ、callbackが使いづらく、既存のPHPライブラリが使えません。

そこで、中野さんはyield（ジェネレータ）を薦めました。関数を一時停止・再開できる機能です。これを用いることで、既存のコードにほとんど手をいれずに処理を多重化できることを説明しました。

まとめ

最後に、まとめとして次のことを挙げました。

I/O多重化してマイクロサービスに備えよう
PHPにcallbackスタイルはつらい
curl_multiでI/Oを多重化できるが書くのが大変
yieldでも多重化を書きやすく抽象化してくれる

祖山寿雄さん「今日から始める PHPエンジニアのためのアクセスログ解析基盤構築入門⁠」⁠

アクセスログはネットワークエンジニアにお任せしない風潮になってきていて最近辛いところです。祖山寿雄さんは、アクセスログ解析基盤構築について発表しました。

PHPとログ

PHPはWebアプリケーションを作るための言語ですが、Webアプリケーションを運用するとログが残ります。ログはどこにあるのかというと、アクセスログなら/var/log/wwwや/app/tmp/logなどにあります。

これら生ログを目視するのは、泣きたくなります。grepすると多少ましになりますが、sed&awkなどの職人芸を必要とする場合が出てこないことを祈るばかりです。さらに、古いログは圧縮されています。これを展開して編集して……ということは、したくないはずです。

簡単にログを調べたい

アクセスログは行動履歴なので、きちんと使うことで、会員登録後にアクティブになったユーザとそうでないユーザの行動にどんな違いがあるか？等の情報も取得できます。

もしもHadoopとかRedshiftとかはよく分からず、分析自体はExcelとかRとかに任せるとして、必要なデータを簡単に分析したい時は次の2つのプロセスを考えるのが良いと言います。

ログ調査を効率化しよう
ユーザーの行動解析をしよう

1. ログ調査を効率化しよう

ログ調査を効率化するために、ElasticsearchとKibanaを薦めました。Elasticsearchはオープンソースの検索エンジン。Solrとよく比較されます。Kibanaは表示したり、クエリを作ったりします。検索的にログを調べられて便利です。また、静的ファイルとして存在しているので、軽いのがメリットです。

2. ユーザーの行動解析をしよう

解析にはBigQueryがお薦めだと言います。BigQueryではSQLライクなクエリが書けるのと、とにかく安いのが素晴らしいとのこと（1Tの検索でも5ドル程度⁠）⁠。ただ、スキーマレスではないので、JSONなりCSVなりで入れてやる必要はあります。

Elasticsearchのクエリはネストが続くため、人間の視認性が悪い。なのでそこだけはBigQueryが良いそうです。データを投げるだけでGoogleがやってくれるので便利だと述べていました。BigQueryもKibanaほどではないにしてもダッシュボードを作ることができますが、ガチャガチャと打ち込むとクエリ課金なので注意が必要です。

ログを入れるためのfluentd

BigQueryやElasticsearchにログを入れるには、fluentdを使います。fluentdを使うことで、phpやsyslog、apache、それぞれのミドルウェア毎のログを整形したり、いろいろな形式で取り出すことができます。通常はこのような作業は大変です。しかしfluentdが代わりにやってくれます。設定のテンプレートも公開されています。

また、ログのフィルタリングができるので、必要なログだけBigQueryやElasticsearchに渡すことができたりするとのことです。

フローの制御はタグをつけることで実装します。具体的にはX行目のタグはABCみたいな感じです。

ログを送るデモ

そして、nginxのログをBigQueryとElasticsearchに送るデモを行いました。

注意点として、BigQueryはクエリ課金なので、できるだけ絞ったほうが良いとのこと。例えば、静的ファイルはいらない、などです。

また、fluentdのconfigは65k程度で書けます。項目にタグ付けをして、フィルタするイメージです。タグ付けされた項目に応じて送り込むテーブルを変更したりすることもできることを説明しました。

PHPとはかなりかけ離れていましたが、是非これらを使ってみたいと思ったセッションでした。

大垣靖男さん、徳丸浩さん対談「ウェブエンジニアに必要なセキュリティスキルとは⁠」⁠

大垣靖男さん、徳丸浩さんのセキュリティスキルについての対談です。司会は小山哲志さんです。まずはじめに小山さんから、この対談の経緯について説明がありました。

「元はお二人のブログでの応酬が細かい方向に行っていて、一般の人には分かり辛い流れになってしまっていた（参考まとめ⁠）⁠。そこで、まずここでお互いの立ち位置の違いを明確にして話し合うことで、一般の方々の知見を深める場としましょう！」というのが今回の趣旨です。

会場は希望者が入りきらずに多くの方がサテライト会場に回るほどの盛況の中、対談がスタートしました。

さっくり双方の主張としては、次のようになります。

大垣さん：開発者が考え方を改める必要がある
徳丸さん：正しくプログラムを書くことがセキュリティにつながる

ただ、いきなりまとめから入ってしまうと、双方論点がかみ合わず！（リアル討論でも難しかった）という印象でした。

徳丸さんは、「⁠理想としては全開発者がセキュリティ意識を持ち知識を身につけてもらうのが私もいいとは思う」と一部同意しつつ、「⁠だが現実として、意識が高い開発者ばかりではないし、絶望的になる書籍も多い。それらが書店に並び、誤った知識が量産されている現実社会を考えれば、人でなくツールでカバーすべき」と主張しました。それに対して、大垣さんは「開発者が信頼境界線を自分で認知するという基本を抑え、入力バリデーションは必ず設定すべき」と返す、というあまり互いの土俵には乗っからない相撲になってしまいました。

途中から「どうしましょうか」「⁠どうしましょうか」（⁠会場笑い）と、このままでは並行線の様相。話していくうちに「意外とこことここは共通点ですよね？」というポイントを見つけて雰囲気が和らぐという流れになりました。その点を整理しておきます。

ネットで拾ったコードをそのまま流用したりして、誰でも脆弱性を大量に生み出せてしまう時代である
Webアプリにおいては、入口出口は決まったパターンが多いので、全体設計までいかなくとも局所的な最適化でカバーできる
開発者として一人前になるためにセキュリティ以外にも覚えることがたくさんある
SQLインジェクションのようなシステムの中の設計対策はどちらにせよ重要である
WAFは以前はホワイトリストで売ろうとしていたが、ホワイトリストはWebアプリでやるところ（徳丸さんも深く同意⁠）⁠。

今のWAF導入は以前より遥かに有効な対策になっているとの双方の見解でした。また、これからのセキュリティの話で、徳丸さんが「Webアプリに関しては、各種FWが対応していることで、プログラマが個別対応しなくてもよい方向になっていく（いる⁠）⁠」⁠ というのに対して、大垣さんも「セキュリティを気にせずに、プロダクトを作っていくことができるようになる、というのは当然の流れ」と同じ見解を示していました。「⁠ただ、現実問題として、危険なテキスト処理があまりにも簡単にできるという部分がある」（⁠大垣さん）と、警鐘を鳴らすのは忘れていません。

徳丸さんの「そもそも注意しなければならないのがけしからん」「⁠人間の注意力には限界がある」という言葉が個人的には重かった気がします。

最後に

単なる二項対立ではなく、「⁠開発者が最低限抑えておくべき基礎を、どこのレベルに定めるか」という議論に集約されるように感じました（筆者感想⁠）⁠。これは何が正しいか簡単に答えが出る問題でもないですから、大垣派、徳丸派、両方いていいですし、これからも意見をぶつけあってよりよい解を見つけていけばいいのかと思います。

SQLインジェクションに関しての捉え方など、細かいポイントで有用な専門知識にも踏み込んでいましたので、ぜひ録画を確認してみてください。

@yuya_takeyamaさん「Good Parts of PHP and The UNIX Philosophy⁠」⁠

@yuya_takeyamaさんは、UNIXの哲学を踏まえたよいPHPパーツ作りについて発表しました。

まずは、UNIX哲学とは何なのか！という話から始まります。@yuya_takeyamaさんは、次の事柄を挙げました。

ひとつのことをうまくやれ
すべてのプログラムをフィルタに
部分の総和は全体よりも大きい

最後が少し難解ですが、大きな機能をつくるよりも小さなものを合わせたほうが、結局は大きいものになるとのことだそうです。

今回のセッションの対象者はライブラリを書く人だそうです。「⁠日々パーツをたくさん作っておいて、いつか使ってくれればいいと思う」と話していました。

哲学を実践すると、思いつく限りの再利用性の高いコード、組み合わせられるコードが書けるようになるそうです。

今回、次のものを取り上げられました。

STREAM
ITERATOR
GENERATOR

STREAMについては、実装の方法として外から見える様相がSTREAMだったりITERATORだったりするよう（一般的なもの）にしていれば、より使いやすいものになるということです。

ITERATORとGENERATORについても説明しましたが、セッションの時間が切れてしまいました。

秋山顕治さん「Webアプリのデプロイ今昔物語⁠」⁠

秋山顕治さんは、Webアプリのデプロイの歴史について発表しました。

アプリケーションを動く状態に持っていくことが、デプロイです。このセッションは4つの時代に区切って説明しました。

レンタルサーバー時代

レンタルサーバーの時代……、つまりPerl5.6やPHP4、Windows2000とかそういう時代は、金銭的にも技術的にも選択肢がありませんでした。デプロイはFTPでアップロードです。

この問題点として、次の事柄を挙げました。

FTPなのでセキュリティが甘い
共通アカウントでコンテンツ管理
アカウントがわかれば何でもできる

さらに、アプリの肥大化、肥大化するアプリの処理速度を改善しようとする試みが同時に進みましたが、mod-cgi等はレンタルサーバーでは使えないなど、強いストレスでした。

vps時代

Perl5.8やPHP5、Ruby on Railsが初公開された2005年頃になり、CPUやメモリ、HDD以外は自由に設定できるようになりました。通信方式もSSHを使えるようになり、Linuxクライアントからのrsync、コマンドラインからSSHを通してアクセスが一般化しました。

問題点として、「⁠プロセスを永続化したい」「⁠静的ファイルだけは別サーバーにしたい」「⁠Javascriptを難読化したい」といったことが出てきました。対処方法はスクリプトを書くことでしたが、秘伝のタレになってしまいました。

デプロイツールの誕生

そういった事情から、デプロイツールが誕生しました。Capistranoは現在のバージョンは3.2です。

Capistranoの優れているのは「だいたい上手くいく」ことであり、ベストプラクティスが積まれています。deploy taskは空のタスクで、必要に応じて上書きすることでカスタマイズできること。

その結果、デプロイの長い手順が2行にになったり、デプロイに1時間かかっていたのが5分になったりしました。例えば、アプリケーション独自のコマンドを実行したり、php-fpmをリスタートしたりできます。

ただ、それでも問題は存在しています。スケールアウトするのはとても大変です。

PaaS時代

Engine YardやHeroku、Git、Ruby1.9が出てきた、PaaS（Platform as a Service）時代に入ります。この時代は、ホストの管理はサービス事業者任せ、負荷分散は自動、デプロイはgit pushだけ、というようになりました。

ベストプラクティス的なところを強制する流れになったとも言えます。例えば、データーベースアクセス用のパスワードをリポジトリに含めてはいけない、アプリをポータブルにすることを強制する、ログやセッション情報などをアプリから分離させる、などです。

IaaS時代

そしてAWSが出てきました。APIによる操作ができるようになりました。そして、「⁠よいVPSではない」周辺サービスが充実してきました。つまり、サーバを使い捨てできるようになりました。これはサーバの状態を管理しないというパラダイムシフトをもたらしました。

次に挙げたことができるようになり、今のところみんなが幸せな時代になりましたた。

サーバの内容を変更するのではなく、完成したサーバと現行サーバを切り替える
できあがったサーバを作成し、切り替える（アプリがポータブルになった結果）

IaaSがよいVPSではないけれど、進化した形であるというのは非常に納得の話でした。

LT CMS/DB

CMSなどを紹介するLTが行われました。

baserCMS

滝下真玄さんは、CakePHPベースのコーポレートサイト向けCMS「baserCMS」を紹介しました。また、アドオン販売サイト「ベーサーマーケット」も取り上げました。

concrate5

菱川拓郎さんは「concrate5」の紹介しました。5.7からComposer.jsonが始まったことなを取り上げました。最近ではLaravelを使っている人が流入しているそうです。

ownCloudアドオン

髙橋祐樹さんは「ownCloudのアドオン」の作り方を紹介しました。GitHubからダウンロードして、雛形を利用して作る方法を説明しました。

eZ Publish

サニエエリックさんは「eZ Publish」の新しいバージョン5を取り上げ、これまでの経緯と違いを紹介しました。バージョン5はユーザのための移行バージョンだそうです。

NewSQLを使った次世代アプリケーション

竹澤有貴さんは、RDBMSとNoSQLの性能を併せ持つNewSQLを使ったアプリケーションの作り方を紹介しました。DBとしては、NuoDBとVoltDBを取り上げました。

LT無差別級

恒例のライトニングトークです。

kinzalさん「PHP+伺かで始める新しい通知の形」

kinzalさんは、これまでの通知は可愛くないということで、さくらさんに喋ってもらう方法を紹介しました。

大西啓太郎さん「ひよこテスト駆動開発⁠」⁠

大西啓太郎さんは、はじめてユニットテストをした時に遭遇した問題を取り上げ、いかに解決したかを紹介しました。また、Jenkinsを使ったテストについても言及しました。

リッチー大佐＠シェルショッカー日本支部さん「恐怖!シェルショッカー1号男⁠」⁠

リッチー大佐＠シェルショッカー日本支部さんは、同人誌をネットで販売するために、シェルショッカー秘密結社に入ったそうです。そして、他のウェブページでも購入ボタンがつける機能をシェルスクリプトで実装しました。

hanhan1978さん「中年以降エンジニアの成長戦略⁠」⁠

hanhan1978さんは数年前「技術レベルが停滞している」と感じていたそうです。そこでキャズムを飛び越えるべく、「⁠制約する、的を絞る」「⁠勇気を出し、健康を保つ」ということを守り、実践していることを紹介しました。

後藤健さん「スロークエリとの戦い(ほとんどORM)⁠」⁠

後藤健さんは、O/Rマッパーを使う時はクエリで注意したほうがよいと言います。無駄なクエリが出ないように、投げるクエリを意識すべきだとしました。また、そのための環境として、スロークエリランキングを作ったそうです。

菊池佑太さん「ログ解析の基礎⁠」⁠

菊池佑太さんは時代はOne toOneマーケットだとし、それには機械学習が重要だと話します。そして、機械学習は難しくないと例を示しました。そして話は変わり、魔法少女推定を紹介しました。言語や画像処理から、人物推定を推定するものだそうです。

hnwさん「PHPNGの現状を知る⁠」⁠

hnwさんは、PHP界隈は性能関連の話題がホットだとし、PHP本体ではPHPNGがそれを担うと言います。そして、PHP7に入ってくるPHPNGについて紹介しました。zaval大改造した結果、ベンチマークではPHPとHHVMとほぼ互角までいっているそうです。ユーザー目線では何もせずに2倍近く早くなるのでは、と述べていました。

深澤ひかりさん「PHPer女子が語る！こんなコードを書くヒトはモテない～きほん編～⁠」⁠

PHPer女子の深澤ひかりさんは、「⁠さわりたくない」「⁠一緒に仕事をしたくない」と思う非モテコードを3つ紹介しました。「⁠いみのわからない、なまえ」「⁠foreachじごく」「⁠{}のないif文」を挙げました。かっちょいいコードを書いて、女子エンジニアにモテちゃえ！と伝えていました。

moriyoshiさん「よいことも悪いこともぜんぶPHPが教えてくれた⁠」⁠

PHPのコミッターでもあるmoriyoshiさんは、PHPを2000年頃から触り始めいています。PHPは1994に生まれ今年で20年。今回、PHPの教えてくれたこととして、「⁠Webアプリの落とし穴を教えてくれた」「⁠文字コードの問題を教えてくれた」「⁠一貫性が大事なことを教えてくれた」ことを挙げました。

倉知真太郎さん「PHPでAIプログラミングコンテスト準優勝するまでの軌跡⁠」⁠

倉知真太郎さんはCEDEC 2014で行われたAIプログラミングコンテストでPHPを使い、準優勝しました。その軌跡を紹介しました。コンテストの環境を上手くついたとのこと。AIプログラミングではPHPは使わないほうがよいけれども、xhprofは便利だったとのことです。

クロージング

前島さんより、クロージングの挨拶がありました。来年のPHPカンファレンスは10月3日に開催される予定であることが告知されました。

懇親会&LT

同会場にて、懇親会が催されました。じゃんけん大会やライトニングトークがあり、賑やかに行われました。

レポートは以上になります。最後までお読みいただきまして、ありがとうございました。