Shin x blog

PostgreSQL で、トランザクション処理中にあるテーブルに INSERT 文を発行すると、並列で実行している別処理にて、そのテーブルの外部キーの被参照テーブルへのEXCLUSIVE ロックが取得できない現象があったのでメモ。

再現

検証用にテーブルを2つ（products, orders）を用意します。orders テーブルの product_no には products テーブルへの外部キーを設定します。

CREATE TABLE products (
  product_no integer PRIMARY KEY,
  name text,
  price numeric
);

CREATE TABLE orders (
  order_id serial PRIMARY KEY,
  product_no integer REFERENCES products (product_no),
  quantity integer
);

products テーブルにレコードを登録しておきます。

test=> INSERT INTO products VALUES(1, 'item1', 1000);

トランザクションを開始して orders テーブルへ INSERT 文を実行します。トランザクションは実行中のままにしておきます。

test=> BEGIN;
BEGIN
test=> INSERT INTO orders(product_no, quantity) VALUES(1, 1);
INSERT 0 1

別ターミナルを開いて、psql を実行します。こちらで products テーブルの EXCLUSIVE ロックを取得しようとするとロック待ちになります。

% psql test
test=> BEGIN;
BEGIN
test=> LOCK TABLE orders IN EXCLUSIVE MODE;

pg_locks でロック状態を確認すると、products テーブルに ROW SHARE ロックがかかっていることが分かります。これが EXCLUSIVE ロックに競合しているために、ロック待ちが発生しました。

% psql test
test=> SELECT relname,pg_locks.mode FROM pg_locks INNER JOIN pg_class ON pg_class.oid=pg_locks.relation WHERE mode<>'AccessShareLock';
   relname   |       mode
-------------+------------------
 orders      | RowExclusiveLock
 products    | RowShareLock
(2 rows)

PostgreSQL のドキュメントを見ると ROW SHARE ロックは、SHARE ROW EXCLUSIVE ロック以下であれば競合しないので、SHARE ROW EXCLUSIVE MODE に変更するとロックを取得することができました。

% psql test
test=> BEGIN;
BEGIN
test=> LOCK TABLE orders IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE

INSERT 以外では、UPDATE 文で外部キーを更新（上記例では orders.product_no を更新）した場合も同様に外部キーの被参照テーブル（products）に ROW SHARE ロックがかかりました。

前にも

実際に INSERT や UPDATE を実行しているテーブルへロックがかかるのは容易に想像できるのですが、外部キーの被参照テーブルだとうっかり見落としがちなので注意が必要ですね。

実はこの現象を調べてたところ、7 年前に自分で書いたエントリが見つかりました（PHP4 + PostgreSQL7.4!）。すっかり忘れていた内容だったので書いてて良かったのですが、同じとこで躓くのが成長していないというかアホというか;-p

参照

制約 | PostgreSQL9.2.4文書
明示的ロック | PostgreSQL9.2.4文書

勉強会に参加したらたった一つで良いので、アクションを起こして帰りましょう。

Photo by omoon.

このエントリは PHP カンファレンス関西2013リレーブログです。
前日は @omoon さんの「PHPカンファレンス関西2013に来てドラ娘に会おう」でした。毎年異様な盛り上がりを見せるドラ娘の登場ですが、今年も期待して下さい:D

勉強会やカンファレンスに参加すること自体がアクションではあるのですが、ただ聞いて帰るのはもったいない。

セッション聞いて、高揚した気分も、週明けの日常に入ると一週間もしないうちに収まってしまいます。せっかく受けた刺激をより刻みこむためにも何かアクションを起こして帰りましょう。

では、どんなアクションを起こすのが良いか。

質問する

セッションの終わりには質疑応答の時間があります。そこで手を挙げて、セッションの内容で気になった点を聞いてみます。わりと勇気がいることですが、スピーカーに直接疑問を投げかけられる良い機会です。

「こんな初歩的なこと聞いても大丈夫？みんな実分かっていて、自分だけ知らないのでは。。。」と思って、質問を躊躇していませんか？そういった疑問はたいてい隣の人も疑問に思っていたりするものです。

またスピーカーとしても質問があるのは嬉しいものです。セッションの内容が届いたから質問が出るわけです。スピーカーへお礼を言う意味でも質問をしてみて下さい。

話してみる

セッションで偶然隣に座った人にセッションの内容などについて話してみる、というのが出来れば良いですが、さすがにこれはハードル高そうです。そこで話しやすような人を探してみましょう。

スピーカー。良いですね。セッションが終わった後なら、解放感もあって気軽にお話してくれると思います。
スタッフ。運営でバタバタしてるかもしれませんが、大丈夫です。

でも一番話しやすい人は誰でしょう？それはブースの人です。ブースは参加者の方に足を止めてもらってこそなので、来てもらってお話をすることを心待ちにしています。いっちょ話して見ようという方はぜひブースへ行ってみて下さい。

懇親会に参加するのも一つのアクションですね。懇親会では人と話すハードルがグッと下がります。一日を一緒に過ごした者同士、楽しみましょう。

PHPカンファレンス関西2013 懇親会申込

発表する

発表すれば、セッションを聞くだけとは比べものにならない刺激を受けます。発表がうまくできても、うまくできなくても確実に記憶に残ります。当日に発表内容を考える強者もいますが、事前に準備をしておけば、イベントへ参加する気持ちも高まりますし、何より「自分のイベント」という感情が芽生えます。

まずは LT をやってみるのはどうでしょう。

LTはちょっと長い自己紹介のようなものです。自分が興味あること、調べたこと、面白いと思っていることを 5 分間聞いてもらう時間です。一緒にイベントに行く人がいない、知り合いがいない、という人こそ LT しておけば、後の懇親会では話しかけられること請け合いです:D

ちなみに PHP カンファレンス関西2013 では、まだ LT 募集中です！いっちょやってみよう、という方はぜひどうぞ。

PHPカンファレンス関西2013 LT 申込

前のめりで

受け身ではなく、一歩前に出てアクションを起こすと勉強会やカンファレンスはもっと楽しいものになります。参加したからにはぜひ何かアクションを起こしてみましょう。

明日のPHP カンファレンス関西2013リレーブログは、 @msng さんです。よろしく！

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 の代わりに使ってみようかな。

2年ぶりに関西アンカンファレンスを大阪で開催します。

アンカンファレンスって何？の方は、以前開催したエントリをご参照下さい。

• 大阪でアンカンファレンスを12月か1月にやります

前回開催の様子はこちらから。

• 第２回関西アンカンファレンス セッション一覧
• 第2回関西アンカンファレンス – Togetter
• 関西アンカンファレンス – Google 検索

関西アンカンファレンスの良さ

関西アンカンファレンスの良さといえば、気軽に発表できる、ということです。当日会場に行ってから、発表者が自ら発表を申し出る方式なので、その場の雰囲気で発表することができます。

もちろん、がっつりスライドを作って準備していくのも良いのですが、スライドは一切準備していなくても、ブラウザやツールなどをプロジェクタで映して話すというのもありです。一人で不安なら二人で掛け合いのように発表しても大丈夫です。

参加者の内、3割くらいの人が発表者になるので、各セッションに積極的に参加しよう、盛り上げようという雰囲気ができあがります。（不思議なもので、自分が運営や発表側に回ると自然と前のめりで参加しようという気分になります。）

こういった雰囲気なので、発表に慣れていない人が試してみる場としては格好の機会だと思います。

もちろん、色々な方の発表を聞くだけでも楽しいのですが、できれば発表してみるとより楽しめると思うので、ぜひ発表してみて下さい。

• 勉強会を楽しむなら発表しよう！

開催概要

開催概要は以下になります。

■ 開催概要
・日時：2013/05/18（土） 10:30-17:00（開場：10:00）
・場所：靭テニスセンター地下 会議室
・地図：http://www.utsubogroup.com/
・参加費：1,000円 / 4,500円（懇親会セット）

発表会場

発表会場は隣接する2部屋です。同時に 2 セッションが進行するので、発表する方も聞く方もお好きな方へ移動して下さい。

発表枠

発表枠は通常枠と短め枠の２つがあります。

通常枠は「1セッション20分（15分発表＋5分移動、準備）」です。こちらの枠が基本となります。

短め枠は「1セッション10分（08分発表＋2分移動、準備）」です。こちらは少し時間短めなので、発表初心者の方やちょっと話したいという方向けです。（もちろん、発表初心者の方が通常枠を取って頂いてもokです）

発表内容

発表内容は IT / Web に関する内容であれば何でも ok です。前回、前々回のセッション一覧を見て頂ければ、多岐に渡ることがお分かりかと:D

• 第２回関西アンカンファレンス セッション一覧
• 関西アンカンファレンス セッション一覧

ただ、色々なバックグラウンドを持つ方が集まるイベントなので、何かを貶めたり攻撃したりするような内容は避けましょう。

発表枠の申し込み

当日にホワイトボードに時間枠を記載しますので、発表したい時間、部屋のところに付箋を貼っていくだけです。いつ発表するか、どんな発表が出るかは当日のお楽しみです。

参加申込

参加申し込みは下記サイトからお願いします。

今回は参加費、懇親会費ともにお申込み時に頂く形になっていますので、参加される方は下記サイトより申込をお願いします。決済はクレジットカード、paypalの他にコンビニでも可能です。

では、みなさんからの参加お待ちしていますー！

第3回関西アンカンファレンス
※ちなみに 5/18 は関西では多くのイベントが行われますが、途中抜け、途中参加も可能です:D

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に関連するソフトウェア、技術などの勉強会などを開催されているコミュニティの方からの出展をお待ちしています。

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

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

最近、話題のPHP5.3のサポート終了（End Of Life=EOL）について。

当初は2013/03末でEOL を迎えるという話だったのですが、これを延長する案が php-internals で流れていました。

PHP: rfc:php53eol [PHP Wiki]で投票が行われるくらいまでは追いかけていたのですが、結局どうなったのかなと気になってたところで @kenji_s さんの tweet から辿って以下のリンクを見つけました。

php.internals: [RFC][result] Define PHP 5.3 end of life

投票の結果、以下のことが決まったようです。

• PHP5.3のEOLはPHP5.5.0をリリースして1年後
• EOLの正確な日付はPHP5.5.0リリース時にアナウンス

当初よりは少し余裕は出来ましたが、PHP5.5はすでにbeta2まで来ているので、5.4への移行を進めておいた方が良いですね。稼働中のものは別としても、新規開発のものは5.4対応で開発しましょう。