PHP Archive

9/28に京セラドームで開催されたJAWS FESTA Kansaiの1トラックとして、関西PHP勉強会を開催しました。

Photo by omoon.

午前のセッションにも関わらず、多数の方に参加頂き、ありがとうございました。

いまどきのPHP

今回の勉強会では、3セッションを行ったのですが、私のセッションでは「いまどきのPHP」について発表しました。

いつもの勉強会とは違い、JAWS FESTA Kansai の中で開催したので、PHPユーザ以外の方（普段は別の言語で開発している、以前は書いていたけど最近の動向は知らない）が参加されるかもと思い、いま多くの言語で行われているオブジェクト指向開発がPHPでもきるんだよということを伝えたくて、PHPのオブジェクト指向機能をメインにしました。

結果としては、ほとんどの方がPHPをメインで使われているとのことだった（まあ、PHP勉強会なので当たり前になのですが:)）ので、おさらい程度の内容だったと思うのですが、熱心に聴いて下さる方もいたので、話して良かったです。

じゃんけん大会

勉強会の終わりには、「PHPエンジニア養成読本」をかけたじゃんけん大会を行いました。

ちょうど隣の WordBench 大阪のセッションが終わった頃だったので、多数の方に参加頂いて、盛り上がりました:D 獲得された方は、簡単な内容で良いので、レビューなど書いて頂ければ嬉しいですm(_ _)m

blog を書くまでが勉強会

数年前の勉強会では良く言われていたフレーズです。私自身の開催する勉強会では必ずこの話をしていたのですが、TwitterやFacebookなど気軽に短文を投稿できるメディアが広がってからはあまり聞かなくなりました。

その頃から、勉強会やカンファレンスなどのイベントへの参加blog記事が少なくなってきたような気がします。私自身も以前は書いていた参加エントリも書かなくなりました。（一時期はスライドすら公開しないことも＞＜）

今回は初心に戻って、勉強会の最初と最後で伝えたのですが、すると早速いくつかのエントリを書いて頂けました！一時期に比べるとblogを書く人が減っているのはあるとは思うのですが、きちんと伝えれば反応してくれる人はいるのだとあらためて思いました。

勉強会の運営やセッションでの発表などは一方通行のものではなく、参加した人との相互作用で成り立つものだと思います。その場でお話するのももちろん良いのですが、できればblogなどでのフィードバックがあると今後の参考になりますし、なにより「開催して良かった」「次はこうしよう」など今後へのモチベーションにもなりますので、可能な範囲で書いて頂けると嬉しいです。（自戒も込めて）

発表資料や参加エントリはKansai PHP Users Group の Facebook グループにて。

Kansai PHP Users Group として別イベントへの参加

Kansai PHP Users Group として活動してから、3 年以上が経つのですが、ようやく別のイベントにコミュニティとして参加する機会が増えてきました。

8 月には WordBench 大阪にてセッションを行いました。今回は JAWS FESTA Kansai にて勉強会を開催しました。これまで参加したいとは思いつつ、タイミングが合わず実現していなかったのですが、ここ最近はそれが一気に来ました。

実は、10 月にはInnovation EGG、そして11月にはKOFへの参加を予定しています。

関西の中で、それぞれのコミュニティが分断しているのではなく、一緒に何かやりたいというのは以前から頭にはあったのですが、色々な人の出会いのおかげで、それが少しづつ形になってきています。今後もこういったコラボレーションを行っていきたいですね。

2013/09/15に開催されたPHPカンファレンス2013でVagrantに関する発表をしてきました。

発表資料はこちらです。

(2013/10/09追記）
PHP開発環境を構築するサンプル Vagrantfile をアップしました。
PHP開発環境のサンプルVagrantfile

第7回関西PHP勉強会で発表した下記の内容をベースに、より実践的な内容を追加しました。

PHPシステムの開発環境をVagrantで作ることを題材に、基本的な流れをお話しました。

ポイントは、プロビジョニングにシェルを使う部分と、やはり synced_folder ですね。AWS上にも同じ環境を構築できる部分ももう少し深くお話したかったのですが、時間が足りませんでした＞＜

また、Vagrantfile があるディレクトリ（vagrant upしたカレントディレクトリ）も synced_folder となっていて、仮想マシンでは /vagrant としてアクセスできるということも知っておくと便利です。これを利用するとChefのtemplateリソースのように設定ファイルをあらかじめ用意しておいて、所定の場所にコピーするなどが簡単にできます。

発表後には何人かの方にフィードバックを頂いて、Vagrant + Chef-solo を一気にやって躓いたという方やPHPでプロビジョニングをやることもできるという点に気付いた方もいて、シェルスクリプトをプロビジョニングに使う方法もあるよということが伝わって良かったです。

なかには、PHPを使っていないけど、Vagrantの話を聞きにきました！という方もいて、個人的にはとても嬉しかったです。

ちなみにスライドにある「Vagrantが見せる夢」は、今年のPHPカンファレンスのテーマが「PHPの夢を語ろう。」となっているからです:D Vagrantを使うとより多くの人が簡単にPHP開発環境を手にすることができる、というのは実際に思うところです。

今回は 2F 小展示ホールで発表したのですが、ここは以前のPHPカンファレンスではメイン会場として使われていた場所で、落ち着いて発表することができました。会場の雰囲気も良く、あっという間に発表時間が過ぎました。参加頂いたみなさんありがとうございました！

発表でも触れましたが、Vagrant はじめの一歩として執筆したVagrant入門ガイドは下記です。こちらも合わせて、よろしくおねがいしますm(_ _)m

PHPエンジニア養成読本

9/13に発売された「PHPエンジニア養成読本」をイベント会場内のジュンク堂さんにて販売して頂きました。おかげさまで持ち込まれていた在庫は全て完売ということになりました。ご購入いただいた、みなさんありがとうございましたm(_ _)m

途中、サイン会なども開かれていて、購入して頂いた方と少しお話することができ、楽しかったです。

LT 司会

カンファレンスの最後といえば LT 大会！今回も WordCamp Tokyo とPHPカンファレンスとで合同の LT 大会だったのですが、PHPカンファレンス側の司会として登壇しました。スタッフでも無いのに申し訳ない気もしたのですが、後で聞くと皆さんオーバーワークだったようで（5トラックもあったので。。。）、少しでも負担減に協力できたのなら良かったです。

ただ、もしかするとスタッフの中でやってみたい方もいたかもしれないので、次回は手を挙げると良いと思います。

カンファレンスセッション

今回は特に色々とやることが多かったので、他の方のセッションはほとんど参加できませんでした。。。PHP言語系やRubyからPHPへの話、あとインフラ系の話は面白そうだと思っていたのですが、自身のやることと、あと久しぶりに会う人と話すのが楽しく、気がつくと終わっていました。TLを見ると、かなり面白そうな内容だったようなので、あとでUstやスライドを見てみます。

今年は 5 トラックということで、運営は大変だったと思うのですが、スピーカーとして参加した私はとても快適に過ごすことができました。運営スタッフのみなさん、本当にありがとうございました。

2013/9/13に「PHPエンジニア養成読本」というムック本が技術評論社から出ます。

この本の巻頭記事を執筆させて頂きました。巻頭記事では本書のイントロダクションとして、PHP5.3/5.4/5.5の新機能と「いまどき」のPHP開発を紹介する2章構成になっています。

PHPを取り巻く環境は大きく変わっていっています。普段からそういった変化を追いかけている人は良いのですが、日常の開発に没頭しているとついそういった動きに気づかないままということがあります。また、昔のPHPのままのイメージで止まっている人も多いかもしれません。

そこで、PHP が大きく変化した 5.3（名前空間、クロージャ、LSB）から、5.4（トレイト、配列の短縮構文、ビルトインサーバ）、最新の 5.5（ジェネレータ、finally、パスワードハッシュ関数）を第1章で紹介しています。

第2章では「いまどきのPHP開発」ということで、環境構築やフレームワークの活用、Xdebug、OPcache、PSRなど、PHP開発の現場で活用している技術や方法を書いています。

この記事をベースに、以降の各特集記事に進んでいきます。

各特集記事についてもここでご紹介したいのですが、それぞれの著者の方がblogを書かれると思うので、キーワードだけ。

Composer、フレームワーク、PHPUnit、PhpStorm、Vim、コード品質、クラウド、基礎知識といったところです。内容が気になりますね:D

ムック本なので、この一冊で全てが分かるというわけではないですが、いまどきのPHP、開発現場でのPHPを手軽に知ることができる内容になっていると思いますので、一度読んで頂ければ嬉しいです。

なお今年のPHPカンファレンスは、なんと本書発売日の翌日（2013/09/14）です！私もPHPカンファレンスに参加しますので、もし会場でお会いできれば、感想など教えてください:D

PHP5.5 リリースにより、再び盛り上がってきた phpenv + php-build 環境を Vagrant で作ってみました。

CentOS6.4 + phpenv + php-build + nginx という構成になっています。

nginx + phpenv + php-build の環境構築については hnw さんの下記エントリがとても参考になりました。

php-buildで複数バージョンのPHP-FPMを用意する – hnwの日記

インストール

https://github.com/shin1x1/vagrant-phpenv-phpbuild

github へ Vagrantfile + Chef レシピファイルをアップしています。こちらの README に書いたとおりですが、手順としては以下になります。

1. VirtualBox インストール
2. Vagrant インストール
3. git clone
4. vagrant up

1 / 2 はインストール済であれば不要です。（なお VirtualBox 4.2.14（2013/07/01 時点の最新版） は、Vagrant との組み合わせで問題が発生する場合があるので、現時点では 4.2.12や4.2.8など旧バージョンのインストールをお勧めします。）

4 は、box ファイルのダウンロードや PHP のビルドでかなり時間がかかる場合があります。コマンドを実行した後はのんびりお待ちを。

SSH でアクセス

vagrant ssh でログインすると、phpenv コマンドが利用できます。

php コマンドで実行される PHP バージョンを変更したり、さらに別バージョンの PHP をインストールすることが可能です。

HTTP でアクセス

Vagrant で起動した仮想サーバには IP アドレスに 192.168.33.14 を付与しています。
稼働サーバでは nginx が動作しており、ポート毎に各バージョンの php-fpm が割り当てられています。

• http://192.168.33.14:8053/ -> PHP5.3
• http://192.168.33.14:8054/ -> PHP5.4
• http://192.168.33.14:8055/ -> PHP5.5

ドキュメントルート

仮想サーバ内の /public_html ディレクトリが nginx のドキュメントルートになっています。

このディレクトリはホスト側の public_html ディレクトリをシェアしているので、このディレクトリに PHP ファイルを設置すれば、仮想サーバの nginx+php-fpm で実行することができます。

例えば、下記のように echo.php をホスト側の public_html ディレクトリ以下に作成すると、http://192.168.33.14:8053/echo.php で実行することができます。

$ ls .
README.md   Vagrantfile cookbooks   public_html
$ echo "<?php echo PHP_VERSION;" > public_html/echo.php

Vagrantfile をカスタム

Vagrantfile をカスタムすることで、インストールする PHP バージョンを変更したり、configure オプションを追加することが可能です。
詳しくは README にて。

参考

• https://github.com/phpenv/phpenv
• Vagrant で自分の PC に「作って、壊して、元に戻せる」サーバを作る

CakePHP（1.2.x 以降全て）の Paginate / PaginatorComponent にて SQL インジェクション可能な脆弱性が見つかりました。

すでに cakephper さんの blog でも注意勧告されていますが、 連休中にリリースされた情報ということで見落としている人もいると思うので、こちらでも。

内容

この脆弱性を悪用すると Paginate / PaginatorComponent にて SQL インジェクションが可能となります。
現在は影響の大きさを考慮して、公式サイトでは脆弱性の詳細は明らかにされていませんが（一定期間、ユーザのアップグレードを待って公開するようです。）、私が開発環境で試したところ、SQL インジェクション可能であることが確認できました。

対象

Paginate / PaginatorComponent を利用している全ての CakePHP アプリケーションが対象となります。
Paginate / PaginatorComponent を利用していない場合は、本脆弱性は存在しませんが、今後利用する可能性も考慮して、可能であれば対応しておいた方が良いです。

簡易的ですが、Paginate / PaginatorComponent を利用しているか否かは以下のコマンドで調べることができます。1 件でも該当行があれば、Paginate / PaginatorComponent を利用している可能性があるので、下記対応を検討して下さい。

$ cd /path/to/cake
$ find ./app -type f -name "*.php" | xargs grep -i paginat

対応方法

下記のいずれかの方法で対応を行なって下さい。b. についてはフレームワークを理解している必要がありますので、内容が理解できないようであれば a. の方法をおすすめします。

a. 最新版にアップグレードする

この脆弱性の修正版（1.2.12 / 1.3.16 / 2.2.8 / 2.3.4）がリリースされていますので、こちらのバージョンへアップグレードして下さい。

Security Release – CakePHP 1.2.12, 1.3.16, 2.2.8 and 2.3.4 :: The Bakery: Everything CakePHP

b. 修正箇所を自分で適用する

ただちに CakePHP のアップグレードができないようであれば、今回の脆弱性に関する修正箇所を自分で適用する方法もあります。
各バージョンごとに差分を確認して適用を行なって下さい。

• CakePHP2.3.x
  https://github.com/cakephp/cakephp/commit/c327bdc4bd309ce07fe2c20a2a9123f2165cae76#lib/Cake/Controller/Component/PaginatorComponent.php
• CakePHP2.2.x
  https://github.com/cakephp/cakephp/commit/b4efeb48b8554aba316d80eb89424a20b3be0b27#lib/Cake/Controller/Component/PaginatorComponent.php
• CakePHP1.3.x
  https://github.com/cakephp/cakephp/commit/8fc6b3fa9afc1e6859a138b4c86c0cb4d554caaf
• CakePHP1.2.x
  https://github.com/cakephp/cakephp/commit/db39c242cc8001106bae4530434bdac5878bf438

CakePHP を利用した OSS も対応を

CakePHP 自体の脆弱性なので、CakePHP をベースとした OSS もこの脆弱性が存在する可能性があります。随時それぞれの OSS にてセキュリティフィックス版がリリースされるかと思いますが、まだの場合は上記のとおりアップグレードを検討して下さい。

• baserCMS は、2.1.1にてセキュリティフィックス版（1.2.12）に更新されています。
• candycane は、master ブランチにてセキュリティフィックス版（2.3.4）に更新されています。

AWS SDK for PHP2 に実装されている Amazon S3 stream wrapper で S3 を操作してみました。

Amazon S3 stream wrapper を使うと「s3://bucket/foo/bar.txt」といったパスで mkdir() や file_get_contents() などの標準関数から S3 を操作することができます。

Amazon S3 stream wrapper の使い方

Amazon S3 stream wrapper は AWS SDK for PHP2 に含まれているので、SDK をインストールしておきます。インストール方法などは下記をどうぞ。

AWS SDK for PHP 2 をインストールして AutoScaling の設定を行う

s3://バケット名/キー（パス）

s3://bucket1/folder/foo.txt

$ php s3_stream_wrapper.php
s3://shin1x1-tokyo/dir1/dir2/file1.txt = file1
s3://shin1x1-tokyo/dir1/dir2/file2.txt = file2
s3://shin1x1-tokyo/dir1/dir2/file3.txt = file3

• Amazon S3 stream wrapper
  http://docs.aws.amazon.com/aws-sdk-php–2/guide/latest/service-s3.html#amazon-s3-stream-wrapper

PHP5.5 から標準バンドルされる Zend OPcache を PHP5.4 にインストールしてみました。

インストールする環境は Vagrant 上の CentOS6.4 です。PHP は remi リポジトリからインストールしています。

$ php -v
PHP 5.4.14 (cli) (built: Apr 11 2013 11:04:32)
  Copyright (c) 1997-2013 The PHP Group
  Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Zend OPcache のインストール

remi リポジトリには Zend OPcache は存在しないようなので、github からソースをダウンロードしてビルドしました。
手順は Zend OPcache の github ページに記載されている内容そのままです。

なおビルドに際して php-devel が必要となるので、これもインストールしておきます。

$ sudo yum install php-devel --enablerepo=remi

$ git clone https://github.com/zend-dev/ZendOptimizerPlus.git
$ cd ZendOptimizerPlus
$ phpize
$ ./configure --with-php-config=/usr/bin/php-config
$ make
$ make install

これで /usr/lib64/php/modules/ 以下に opcache.so が作成されます。（ディレクトリは環境によって異なります。）

$ ls /usr/lib64/php/modules/opcache.so
/usr/lib64/php/modules/opcache.so

あとは php.ini にて、opcache.so を読み込むように設定を追加します。

$ sud vim /etc/php.ini
; 以下を追加
zend_extension=/usr/lib64/php/modules/opcache.so

php -v を実行すると 「with Zend OPcache」表示され、Zend OPcache が有効になっていることが分かります。

$ php -v
PHP 5.4.14 (cli) (built: Apr 11 2013 11:04:32)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
  with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies

ベンチマーク

Zend OPcache の効果を確認するために簡単なベンチマークを取ってみます。

• ベンチマークは ab にて行う（ ab -c 50 -n 1000 http://localhost/helllo ）
• httpd stop & start 後に6 回計測して、5回分の平均値を算出（初回はキャッシュ処理を行うので除外）
• 対象アプリケーションは CakePHP2.3.2 で “Hello!” を表示するだけのもの。（ソース）

PHP のみ、PHP + Zend OPcache の他に比較として PHP + APC（3.1.13 / pecl でインストール）も計測しました。

結果は以下になります。
Zend OPcache を組み込むと 5 倍近くパフォーマンスが向上しています。APC も速くなっていますが、Zend OPcache の方が 20% ほど速いようです。

ためしに Zend OPcache と APC を同時に有効にしてみましたが、サンプルアプリケーションでは問題無く動作しました:D

PHP5.4 で使うなら Zend OPcache ? APC ?

ここ数年は PHP でコードキャッシュなら APC が定番でしたが、PHP5.4 以降対応版がまだ beta となっています（概ね問題無いようですが）。一方、Zend OPcache はパフォーマンスで APC と同等もしくは上回っており、PHP5.5 からは標準バンドルされるということで、今後を考えると Zend OPcache を利用するのが良さそうです。

ただし Zend OPcache 自体もまだ開発が進んでいる段階ですので、本番環境での利用についてはリスクを承知の上でお願いします。

PHP5.5 からコードキャッシュとして標準バンドルされた Zend OPcache を試してみました。

第6回関西PHP勉強会で Zend OPcache についてLTしたのでインストールやベンチマークなどはこちらで。

• beta4時点では、Zend OPcache は拡張で提供され、opcache.so インストールされる。
• Zend OPcache を使うには、php.ini で zend_extension=opcache.so の記述が必要。
• やっぱりデフォルトでインストールされるのは楽。
• PHP5.5リリースと共に使えるので安心。（PHP5.4 対応の APC はまだ beta）
• ユーザデータのキャッシュはできないので、別の方法が必要。

OCP – OPcache Control Panel

Zend OPcache の利用状況（設定、キャッシュ量など）が確認できるスクリプトが gist にあったので試してみました。

OCP – Opcache Control Panel

1 スクリプトなので、設置して、ブラウザからアクセスするだけです。アクセスすると下のようにキャッシュ状況などが表示されます。

参考

Zend OPcache (Zend Optimizer+) のソース、設定項目

Zend OPcache のソースコードは、github にて公開されています。こちらに設定項目の解説などもあります。

zend-dev/ZendOptimizerPlus · GitHub

Zend OPcache(Zend Optimizer+) を PHP5.5 に入れる RFC

PHP: rfc:optimizerplus [PHP Wiki]

Zend OPcache と APC とのベンチマーク比較

OPcode Cache Benchmarks

• PHP5.5.0-dev + FastCGI / APC 3.1.15-dev（現在はリポジトリから削除）/ Zend OPcache
• 概ね Zend OPcache が APC より数%から20%弱速い
• Zend Framework1.5 だけ異常に速い（149%！）optimize が合っている？

APC の現在の状況など

setup – Is APC compatible with PHP 5.4 or PHP 5.5

• APC の PHP5.4 以降対応は現在も beta（概ね問題無いようだけど）
• APC の開発状況を見ると PHP5.5 対応は無いかも。
• Zend Optimizer+ は、PHP5.2以上なら対応しているので、PHP5.4 でも APC の代わりに使ってみようかな。

PHP から AWS を操作するためのライブラリ「AWS SDK for PHP」の新バージョン「AWS SDK for PHP 2」を触ってみました。

AWS SDK for PHP 2 リリース直後は対応サービスが少なかったのですが、現在は主要なサービスは網羅しているようです。

AWS SDK for PHP 2 の主な特徴

https://github.com/aws/aws-sdk-php

• PHP5.3.3以降
• PSR-0, PSR-1, PSR-2対応
• Composer, PEAR でのインストール、phar ファイルの配布
• Guzzleベース
• namespace, Iterators, Waiters, Enums, レスポンスモデル, 例外など、いまどきの実装に対応

AWS SDK for PHP 2 のインストール

AWS SWK for PHP 2 は、phar ファイル、Composer 、PEAR のいずかれの方法でインストールすることができます。
phar ファイルが一番お手軽（ダウンロードするだけ）なのですが、ソースが読みづらいのと、APC が効かないという話もあるので、ここでは Composer でインストールします。

まず composer.json を作成します。

$ vim composer.json
{
  "require": {
    "aws/aws-sdk-php": "2.*"
  }
}

次に Composer をインストールします。

$ curl -s "https://getcomposer.org/installer" | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /path/to/composer.phar
Use it: php composer.phar

Composer で AWS SDK for PHP 2 をインストールします。依存ライブラリもダウンロードするので時間がかかる場合があります。

$ php composer.phar install
Loading composer repositories with package information
Installing dependencies
  - Installing symfony/event-dispatcher (v2.2.1)
      Loading from cache

        - Installing guzzle/guzzle (v3.3.1)
      Loading from cache

        - Installing aws/aws-sdk-php (2.2.1)
      Loading from cache

      symfony/event-dispatcher suggests installing symfony/dependency-injection (2.2.*)
  symfony/event-dispatcher suggests installing symfony/http-kernel (2.2.*)
  aws/aws-sdk-php suggests installing doctrine/cache (Adds support for caching of credentials and responses)
  aws/aws-sdk-php suggests installing monolog/monolog (Adds support for logging HTTP requests and responses)
  aws/aws-sdk-php suggests installing symfony/yaml (Eases the ability to write manifests for creating jobs in AWS Import/Export)
  Writing lock file
  Generating autoload files

インストールが完了すると以下のようなファイル、ディレクトリが存在します。

$ ls
composer.json composer.lock composer.phar vendor

AWS SDK for PHP 2 の参考情報

• github

基本的な情報が README.md にあります。下記の User Guide や API リファレンスなどへのリンクもあります。

https://github.com/aws/aws-sdk-php/

• User Guide

AWS SDK for PHP 2 の情報ならこれが一番分かりやすいです。SDK にも aws/aws-sdk-php/docs 以下に含まれていますが、下記サイトからも参照できます。
インストール方法やサンプルソース、アーキテクチャ、パフォーマンスガイド、旧バージョンからのマイグレーションなど充実しています。

AWS SDK for PHP 2 — AWS SDK for PHP 2.2.1 documentation

Auto Scaling の設定

現行は API でしか操作できない Auto Scaling の設定を AWS SDK for PHP 2 でやってみましょう。
ELB 配下に立てる Web サーバのインスタンスを Auto Scaling で起動するイメージです。
必要な ELB と Web サーバの AMI はあらかじめ用意しておきます。

Auto Scaling の設定

Auto Scaling の設定を行います。
AWS SDK for PHP 2 の書き方としては、AWS の API へのパラメータを連想配列で渡す形になります。基本は全てのパラメータを連想配列で渡すだけなので分かりやすいですね。（このあたりは CakePHP っぽい）

Auto Scaling 設定内容を確認

Auto Scaling の内容は Management Console では確認できないので、API で確認します。

実行すると以下のように設定された AutoScaling が確認できます。

array(2) {
  'AutoScalingGroups' =>
  array(1) {
    [0] =>
    array(18) {
      'Tags' =>
      array(0) {
      }
      'SuspendedProcesses' =>
      array(0) {
      }
      'AutoScalingGroupName' =>
      string(2) "as"
      'HealthCheckType' =>
      string(3) "ELB"
      'CreatedTime' =>
      string(24) "2013-04-16T15:10:20.753Z"
      'EnabledMetrics' =>
      array(0) {
      }
      'LaunchConfigurationName' =>
      string(7) "as_conf"
      'Instances' =>
      array(2) {
        [0] =>
        array(5) {
          'HealthStatus' =>
          string(7) "Healthy"
          'AvailabilityZone' =>
          string(15) "ap-northeast-1c"
          'InstanceId' =>
          string(10) "xxxxxxxxxxxx"
          'LaunchConfigurationName' =>
          string(7) "as_conf"
          'LifecycleState' =>
          string(9) "InService"
        }
        [1] =>
        array(5) {
          'HealthStatus' =>
          string(7) "Healthy"
          'AvailabilityZone' =>
          string(15) "ap-northeast-1c"
          'InstanceId' =>
          string(10) "xxxxxxxxxxxx"
          'LaunchConfigurationName' =>
          string(7) "as_conf"
          'LifecycleState' =>
          string(9) "InService"
        }
      }
      'DesiredCapacity' =>
      string(1) "2"
      'AvailabilityZones' =>
      array(1) {
        [0] =>
        string(15) "ap-northeast-1c"
      }
      'LoadBalancerNames' =>
      array(1) {
        [0] =>
        string(2) "as"
      }
      'MinSize' =>
      string(1) "2"
      'VPCZoneIdentifier' =>
      array(0) {
      }
      'HealthCheckGracePeriod' =>
      string(3) "200"
      'DefaultCooldown' =>
      string(3) "300"
      'AutoScalingGroupARN' =>
      string(125) "arn:aws:autoscaling:ap-northeast-1:xxxxxxxxxxxxxxxxxxxxxxxxx"
      'TerminationPolicies' =>
      array(1) {
        [0] =>
        string(7) "Default"
      }
      'MaxSize' =>
      string(1) "5"
    }
  }
  'ResponseMetadata' =>
  array(1) {
    'RequestId' =>
    string(36) "xxxx"
  }
}

Auto Scaling を停止、削除

Auto Scaling をそのままにしておくとインスタンスを停止しても、また起動してしまうので、停止、削除を行います。この処理を行うと Auto Scaling で起動したインスタンスも停止します。

Auto Scaling の 注意点

• HealthCheckType=ELB の時は、HealthCheckGracePeriod の指定が必要。
• HealthCheckGracePeriod が短すぎると、インスタンス起動してELBのヘルスチェックが通るまでに異常とみなされて、インスタンスが終了する。
  => インスタンスが MinSize に足りなければ、起動->終了を繰り返して課金だけされる恐れがある。（EC2 インスタンスは一度起動すると最低 1 時間分は課金される。）
• ヘルスチェックで異常とみなされたインスタンスは強制的に Terminate される。
• 試した後は Auto Scaling を止めておく。

3回目を迎えてすっかり定番となってきましたPHPカンファレンス関西を6/1に開催します。

今年のテーマは「PHPの未来を関西から」ということで、関西をキーワードに準備を進めています。
また、昨年はその前年の方式をより発展させた形式でしたが、今年は色々と新しい試みを盛り込んでいます。

その中の一つとして、関西で活躍されている様々なプログラム言語コミュニティの方々とのパネルディスカッションを考えています。
今のところ、下記の言語コミュニティの方に登壇頂ける予定です。

• Java
• Scala
• Python
• node.js(JavaScript)
• PHP

PHPを外から見たり、他の言語を知ることによって、あらためてPHPを深く知るきっかけになればと思います。

他にもまだまだあるのですが、参加申込を開始するまでしばしお待ちを。参加申込は5月入った頃を予定していますので、まずは6/1のスケジュールを確保しておいて下さい:D

そんなPHPカンファレンス関西2013なのですが、現在は下記のような内容を絶賛募集中です。

スピーカー募集中

今年もセッションを公募していますので、PHPに関するセッションを発表したい方からの応募をお待ちしています。
今年は「関西」がテーマとなっていますので、関西PHPerの方からの応募を熱烈にお待ちしています。

ちなみにセッションで発表すると以下の特典があります。

• PHPカンファレンス関西2013「オリジナルTシャツ」贈呈
• 懇親会に無料でご招待

さらに加えると以下ももれなく付いてきます。

• 懇親会でもてる

応募は以下から！

セッション講演者募集

企業、個人スポンサー募集中

PHPカンファレンス関西2013をご支援頂ける企業、個人を募集しています。詳細については下記をご参照ください。

企業スポンサーを募集します – PHPカンファレンス関西2013
個人スポンサーを募集します – PHPカンファレンス関西2013

ブース出展コミュニティ募集中

ブース出展を行なって頂けるコミュニティを募集しています。PHPに関連するソフトウェア、技術などの勉強会などを開催されているコミュニティの方からの出展をお待ちしています。

なおこちらでは有志による非営利のコミュニティを想定していますので、企業などのブース出展については、上記のスポンサー募集からお問い合わせ下さい。

お問い合わせフォーム（件名に「ブース出展について」と明記下さい。）