Home > cloud

cloud Archive

CentOS 5, 6 / Amazon Linux で PHP をパッケージインストールする方法まとめ

この記事の所要時間: 1251

Shin x blog Advent Calendar 2013 の 15 日目です。

php-logo

Cent OS 5, 6 / Amazon Linux にて、PHP の各バージョンを yum でインストールする方法をまとめてみました。

CentOS 6

PHP 5.3

CentOS 6 では、公式パッケージが PHP 5.3.3 なので、公式のリポジトリからインストールできます。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57)

パッケージバージョンは 5.3.3–27 となっています。これは主にセキュリティ上の問題が発生した場合にパッチが提供されているためで、最新のビルドは、2013/12/10 になっています。

$ sudo rpm -qi php
Name        : php                          Relocations: (not relocatable)
  Version     : 5.3.3                             Vendor: CentOS
  Release     : 27.el6_5                      Build Date: Tue Dec 10 22:38:18 2013
  Install Date: Sat Dec 14 22:01:49 2013         Build Host: c6b10.bsys.dev.centos.org
  Group       : Development/Languages         Source RPM: php-5.3.3-27.el6_5.src.rpm
  Size        : 3702221                          License: PHP
  Signature   : RSA/SHA1, Wed Dec 11 04:24:11 2013, Key ID 0946fca2c105b9de
  Packager    : CentOS BuildSystem 
  URL         : http://www.php.net/
  Summary     : PHP scripting language for creating dynamic web sites

PHP 5.4

CentOS のリポジトリでは PHP 5.4 は提供されていないので、外部のリポジトリからインストールします。

ここでは、PHP 5.4 を提供しているリポジトリのうち、remi / IUS を利用します。

remi

remi リポジトリは、Fedora プロジェクトのコントリビュータでもある Remi Collet 氏が運営しているリポジトリです。

PHP の新バージョンがリリースされるごとに該当バージョンの RPM を作成し、配布しています。旧 php.net サイトから、外部リポジトリとしてリンクされていたので、PHP ユーザにはお馴染みですね。

まず、remi リポジトリを有効にするために RPM をインストールします。remi リポジトリには epel リポジトリが必要なので、こちらもインストールしておきます。

$ sudo rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

PHP 5.4 を remi リポジトリからインストールします。パッケージ名は php です。remi リポジトリはデフォルトでは有効にならないので、–enablerepo オプションで指定します。

リリースされたばかりの PHP 5.4.23 がインストールされました。ビルド日時は、2013/12/11 となっています。

$ sudo yum -y install php --enablerepo=remi
(snip)

$ php -v
PHP 5.4.23 (cli) (built: Dec 11 2013 06:48:07)

IUS

IUS は、Rackspace が運営しているリポジトリです。

「Rackspace RPM の Fedora」と書かれているとおり、新しいパッケージは、まず IUS で公開し、プロダクション環境での利用が検証できた後に、Rackspace 顧客用のエンタープライズパッケージとして提供しているようです。

IUS リポジトリを利用するために ius-releaseepel-release パッケージをインストールします。

$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/epel-release-6-5.noarch.rpm
$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/ius-release-1.0-11.ius.centos6.noarch.rpm

PHP 5.4 を IUS リポジトリからインストールします。パッケージ名は php54 です。IUS リポジトリはデフォルトでは有効にならないので、–enablerepo オプションで指定します。

最新版の 5.4.23 ではなく、5.4.22 がインストールされました。ビルド日時は、2013/11/15 となっています。

$ yum -y install php54 --enablerepo=ius
(snip)

$ php -v
PHP 5.4.22 (cli) (built: Nov 15 2013 10:13:25)

IUS では、新しいパッケージは、まず ius-testing リポジトリで検証を行い、その後 ius リポジトリへ展開される流れになっているので、isu-testing リポジトリを見てみると、最新の 5.4.23 が公開されていました。検証環境などで、すぐに新しいバージョンを使いたい場合は、ius-testing を利用すると良いでしょう。

$ sudo yum info php54 --enablerepo=ius-testing
(snip)
Available Packages
Name        : php54
Arch        : x86_64
Version     : 5.4.23
Release     : 3.ius.centos6
Size        : 2.7 M
Repo        : ius-testing
(snip)

PHP 5.5

PHP 5.5 も公式リポジトリでは提供されていないので、remi / IUS からインストールします。

remi

remi の PHP 5.5 は、remi-php55 というリポジトリにて提供されていますので、–enablerepo では、remi-php55 を指定します。パッケージ名は php になります。

最新版の 5.5.7 がインストールされました。ビルド日時は、2013/12/11 です。

$ sudo yum -y install php --enablerepo=remi-php55
(snip)

$ php -v
PHP 5.5.7 (cli) (built: Dec 11 2013 07:13:20)

IUS

IUS では、ius リポジトリにて PHP 5.5 が提供されているので、パッケージ名を php55u に変更します。

最新版から一つ前の 5.5.6 がインストールされました。ビルド日時は、2013/12/04 です。

$ sudo yum -y isntall php55u --enablerepo=ius
(snip)

$ php -v
PHP 5.5.6 (cli) (built: Dec  4 2013 17:19:08)

なお、5.4 と同じく ius-testing リポジトリを見ると、最新版の 5.5.7 が提供されていました。

$ sudo yum info php55u --enablerepo=ius-testing
(snip)
Name        : php55u
Arch        : x86_64
Version     : 5.5.7
Release     : 1.ius.centos6
Size        : 2.6 M
Repo        : ius-testing
(snip)

CentOS 5

PHP 5.1

CentOS 5 では、ベンダー提供の標準 RPM が、PHP 5.1.6 なので、公式 yum リポジトリから yum install でインストールできます。

5.1.6 はかなり古いバージョンですが、現在もパッチの提供が続けられています。最新ビルドは、2013/12/10 となっていました。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.1.6 (cli) (built: Dec 10 2013 22:08:48)

PHP 5.3

公式リポジトリにて PHP 5.3 パッケージも配布されています。パッケージ名は php53 となっています。

CentOS 6 と同じく、PHP 5.3.3 がインストールされます。ビルド日時は、2013/12/10 です。

$ sudo yum -y install php53
(snip)

$ php -v
PHP 5.3.3 (cli) (built: Dec 10 2013 22:12:52)

PHP 5.4, 5.5

CentOS 6 と同じく、外部リポジトリを利用してインストールします。

remi / IUS 共に、CentOS 5 用の release パッケージが提供されていますので、こちらをインストールします。各 PHP のインストールは、CentOS 6 と同じです。

remi

epel-releaseremi-release パッケージをインストールします。

$ sudo rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

IUS

epel-releaseius-release パッケージをインストールします。なお IUS では、PHP 5.4 は提供されていますが、PHP 5.5 は提供されていませんでした。

$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/5/x86_64/epel-release-5-4.noarch.rpm
$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/5/x86_64/ius-release-1.0-11.ius.centos5.noarch.rpm

Amazon Linux

Amazon Linux では、公式リポジトリにて、PHP 5.3, 5.4, 5.5 が提供されています。

同じリポジトリで提供されているので、パッケージ名にてインストールするバージョンを指定します。

PHP 5.3

パッケージ名を php でインストールします。最新版一つ前の 5.3.27 が提供されています。ビルド日時は、2013/07/12 です。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.3.27 (cli) (built: Jul 12 2013 22:04:28)

PHP 5.4

パッケージ名を php54 でインストールします。最新版一つ前の 5.4.22 が提供されています。ビルド日時は、2013/12/09 です。

$ sudo yum -y install php54
(snip)

$ php -v
PHP 5.4.22 (cli) (built: Dec  9 2013 18:19:32)

PHP 5.5

パッケージ名を php55 でインストールします。最新版一つ前の 5.5.6 が提供されています。ビルド日時は、2013/12/09 です。

$ sudo yum -y install php55
(snip)

$ php -v
PHP 5.5.6 (cli) (built: Dec  9 2013 18:09:49)

さいごに

CentOS / Amazon Linux にて PHP を yum でインストールする方法を見てきました。現在は、PHP 5.3, 5.4, 5.5 どのバージョンにおいても yum でインストールすることが可能です。

検証は、CentOS 6 は Vagrant + VirtualBox + Docker 、CentOS 5 は Vagrant + VirtualBox で、Amazon Linux は AWS で行いました。こういった類の検証では、Docker コンテナの起動の速さは便利ですね。Vagrant ですら昨年の今頃はまだ触った程度だったのに、ここ一年の進化は早いものです。

参考

  • コメント (Close): 0
  • トラックバック (Close): 0

とある CMS を使ったサイトに Varnish を導入した話

この記事の所要時間: 741

Shin x blog Advent Calendar 2013 の 6 日目です。

varnishcache-logo

とあるサイトに、Varnish をリバースプロキシとして導入して、半年が経過しました。

導入した経緯やその効果など書いてみたいと思います。

Varnish とは

Varnish は、HTTP アクセラレータです。Web サーバのリバースプロキシとして動作し、キャッシュを生かして高いパフォーマンスを発揮するのが特徴です。また、VCL という独自の設定言語を持ち、これにより状況に応じた設定を柔軟に行うことができます。

導入の経緯

このサイトでは LAMP 構成の CMS を利用しており、インフラには AWS を利用しています。基本、閲覧が中心なのですが、イベント時に多数のアクセスがあります。S3 や CloudFront も検討したのですが、コンテンツを数分おきに更新する必要があるので今回は採用しませんでした。

下記が構成のイメージです。なお図はかなり簡略化しており、実際の構成とは異なります。

before

こちらでパフォーマンスの問題が発生したので、CMS が生成したページ全体をキャッシュとして高速に返すよう Varnish Cache を導入しました。

after

当初、nginx の proxy_cache を試したのですが、同一 URL へ多数のリクエストが来ている状況でキャッシュのライフタイムが切れると、バックエンドへ同じ URL に対して複数のリクエストが飛んでしまい、PHP アプリケーション側に負荷がかかるという現象があったので、今回は取りやめました。

Varnish では、同一 URL に対して複数のリクエストがあっても、バックエンドへは 1 リクエストしか飛ばないようになっています。

導入

Varnish Cache は、m1.large インスタンスの Amazon Linux サーバに yum からインストールしました。

$ sudo rpm --nosignature -ivh http://repo.varnish-cache.org/redhat/varnish-3.0/el6/noarch/varnish-release/varnish-release-3.0-1.el6.noarch.rpm
$ sudo yum -y install varnish

もし varnish のプロセスが落ちた場合に自動で再起動するように monit も入れています。varnish は、monit から起動しています。

$ sudo yum install monit
$ sudo chkconfig monit on

$ sudo vim /etc/monit.d/varnish
check process varnish with pidfile /var/run/varnishd.pid
start program = "/etc/init.d/varnish start"
stop program = "/etc/init.d/varnish stop"

$ sudo service monit start

監視

死活、性能監視として Zabbix を採用していたので、Varnish サーバも Zabbix で監視しています。

Zabbix のテンプレートは下記を利用しています。

rdvn / zabbix-templates

効果

Varnish 導入の効果はてきめんでした。

ELB 経由で来たリクエストは全て Varnish を経由しており、キャッシュが有効な期間(3分で設定しています)は、キャッシュを返すだけなので非常に高速です。

またキャッシュが切れた場合も、バックエンドへは 1 URL に対して 1 リクエストしか来ないため、バックエンドへの大きな負荷にはなりません。(ある特定の数ページのみが際立ってアクセスされるサイトなので)

導入前は、ピーク時にはバックエンドの Web サーバが応答を返せない場合があったのですが、それも一切無くなりました。

はっきりいって、下手に CMS を細々チューニングするよりも遥かに効果があります。導入後も安定して動いており、Varnish 起因の問題も発生していません。

参考の数値として、270,000 req/m のリクエストが来た時(Varnish 上位にある ELB の RequestCount)、Varnishサーバ(m1.large)の CPU 利用率は 56% 程度でした。その際の Client requests received(client_req)は 5,000 弱でした。外部からの閲覧に関して遅延など異常はありませんでした。

VCL

Varnish の特徴として挙げられるのが VCL = Varnish configuation Language による設定です。

VCL は小さな DSL となっており、プログラミングのように設定を書くことができます。イメージとしては nginx の設定をよりコードっぽくした感じですね。

例えば、下記は UserAgent を見て、iPhone が含まれていたら、http://sp.example.com/ へリダイレクトさせる VCL です。

if (req.url == "/") {
  if (req.http.user-agent ~ "(?i)iPhone") {
    error 750 "Moved Temporarily";
  }
}

sub vcl_error {
  if (obj.status == 750) {
    set obj.http.location = "http://sp.example.com/";
    set obj.status = 302;
    return (deliver);
  }
}

参考

構築にあたって参考にしたサイトです。柔軟に設定できるので、色々と調べながらの調整になりました。

さいごに

Varnish は、手軽に導入できるわりに簡単にパフォーマンスを向上させることができます。とくに CMS のような閲覧が中心となるアプリケーションには大きな効果を発揮します。

CMS 自体にもキャッシュ機構などは付いていますが、それよりの上位でキャッシュできるので、バックエンドが負荷に耐えられない構成でもうまく吸収することができます。

個人的には VCL がプログラムっぽく書けるのが設定しやすくて好きです。

アクセス過多でパフォーマンスに問題が出た際に使える切り札として覚えておくと、いつか役立つ日が来るやもしれません。

公式サイトのドキュメントが英語なので、日本語でのまとまった情報があればと思うのですが、詳しい方(チラチラッ、Kindle とかでどうでしょうか 😀

おまけ Vagrantfile

簡単に Varnish を試せるように Vagrantfile を作りました。

vagrant up して、http://192.168.33.50/sample.php にアクセスすると現在日時が表示されます。こちらがバックエンドアプリケーションの想定ですので、リロードする度に表示される日時は変わっていきます。

Varnish は 6081 port で待ち受けているので、http://192.168.33.50:6081/sample.php にアクセスするとその時点でのページがキャッシュされます。リロードするとキャッシュが返され、日時が変更されていないことが分かるでしょう。

shin1x1/vagrant-varnish

$ git clone https://github.com/shin1x1/vagrant-varnish
$ vagrant up
  • コメント (Close): 0
  • トラックバック (Close): 0

関西PHP勉強会で「いまどきのPHP」を発表してきました( in JAWS FESTA Kansai 2013 )

この記事の所要時間: 325

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

Untitled
Photo by omoon.

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

いまどきのPHP

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

いまどきのPHP from Masashi Shinbara

いつもの勉強会とは違い、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への参加を予定しています。

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

  • コメント (Close): 0
  • トラックバック (Close): 0

Amazon S3 stream wrapper で S3 を操作する

この記事の所要時間: 038

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 の設定を行う

Aws\S3\S3Client の registerStreamWrapper メソッドを実行すると「s3」というプロトコルが有効となります。
あとは通常のファイル操作と同じように mkdir() や file_get_contents() 関数にて操作対象の S3 オブジェクトを操作します。

パス名は以下の形式で指定します。

s3://バケット名/キー(パス)

たとえば bucket1 というバケットの /folder/foo.txt であれば下記のようになります。

s3://bucket1/folder/foo.txt

以下のサンプルでは、東京リージョンに存在するバケットに対して、dir1/dir2 というフォルダを作成して、file1, file2, file3 というファイルをアップロードしています。さらに dir1/dir2 の内容を読み込んで echo しています。

これを実行すると以下のように出力されます。

$ 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

Management Console でも S3 にオブジェクトが作成されていることが分かります。

s3_stream_wrapper

Amazon S3 stream wrapper を使う利点

stream wrapper で S3 を操作する利点ですが、まず普段ファイルを操作するのと同じ方法で操作できるのが便利です。

また、スキーマを変更するだけで別のプロトコルで処理ができるので、ユニットテストが書きやすくなります。

具体的には、「s3://」といったパスを引数で渡して処理を実行するように実装しておきます。すると、テスト時は vfsStream を使って「vfs://」からはじまるパス名に渡すように変更すれば、S3 へ通信させることなくテストを実行することができます。

SDK の API を実行するよりも簡単にS3 を操作できるのでおすすめです。

参考

  • コメント (Close): 0
  • トラックバック (Close): 0

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

この記事の所要時間: 1053

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 "http://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 を止めておく。
    • コメント (Close): 0
    • トラックバック (Close): 0

    AWS ELB に SSL 証明書を Management Console で設定する

    この記事の所要時間: 27

    Management Console で AWS ELB に SSL 証明書を 設定する方法です。

    ここではすでに作成されている ELB(HTTP のみを Listen)に HTTPS します。新規で ELB を作成して、そのまま HTTPS を設定する場合も似た手順で設定できます。

    対象の ELB の Listeners に HTTPS を追加

    対象の ELB の Listeners に HTTPS を追加します。ここでは SSL Terminaion を利用するので、Instance 側は HTTP としています。
    Load Balancer Protocol を選択すると SSL Certificate に「Select」というリンクができるのでこれをクリックします。

    aws_elb_https_1

    SSL 証明書を登録

    SSL 証明書を登録する画面がポップアップで表示されるので、ここに発行された証明書を登録します。
    中間証明書が複数ある場合、Certificate Chain に繋げて記載します。

    aws_elb_https_2

    「Save」ボタンをクリックすると証明書が登録されて、証明書を選択している状態になります。もう一度「Save」ボタンをクリックします。

    aws_elb_https_3

    追加した Listeners を登録

    最後に追加した Listeners を登録するために「Save」ボタンをクリックします。これで HTTPS の Listeners と SSL 証明書が登録されたので、ブラウザ等から HTTPS でアクセスして登録した証明書を確認します。

    aws_elb_https_4

    証明書の変更、更新

    証明書の更新などで Listeners に登録した証明書を変更する場合は、Listeners の SSL Certificate にて「Change」をクリックします。

    aws_elb_https_5

    ポップアップが表示され、証明書を選択する画面になります。ここでは一度登録した証明書を変更することができないので、Upload a new SSL Certificate を選択して、証明書の登録を行ない、新しい証明書を選択します。

    aws_elb_https_6

    ブラウザで完結するので楽

    SSL証明書の登録や更新は、Webを運用をしていくと地味に続くタスクなので Management Console 上で誰でもできるのは楽です。さらに証明書の削除も Management Console でできるようになるとより良いですね。

    • コメント (Close): 0
    • トラックバック (Close): 0

    SeleniumでAWS課金情報を取得する – JAWS-UG Osaka勉強会 第3回

    この記事の所要時間: 147

    Japan AWS User Group (JAWS-UG) – Osaka勉強会 第3回に参加してきました。

    すっかり恒例になってきたJAWS-UG Osaka勉強会に参加してきました。今回も濃いセッション満載で楽しかったです。会場提供頂いたテレビ大阪さんありがとうございました。

    せっかく参加するならということで、今回は Selenium を使って AWS の課金情報を取得して、Twitter で投稿するという内容でLTをやってきました。

    SeleniumでAWSへの愛を叫ぶ

    当日は真面目なものとそうでないものの2つ発表ネタを持って行っていたのですが、発表前にこちらにしました。

    スライドを用意していましたが、このタイトルの解説を延々と書いているだけなので表紙だけアップしておきます:D

    20110618_jaws_osaka_lt

    SeleniumでAWS課金情報を取得する

    やっていることは単純で、Selenium で AWSサイトにログインして、Account Actibityページで今月の課金(=愛)を取得、そしてそれをTwitterで投稿するだけです。

    デモで使った Selenium テストケースのソースは以下です。(AWS アカウントのメールアドレスとパスワードは仮の値に変えています。)

    ポイントは、課金情報をstoreTextで取得している点と、課金情報に含まれる単位($)をJavaScriptで削除している点ですね。

    Seleniumを使えば、単純なスクレイピングならこれだけでできます。

    テストケースをxUnitのソースに変換して、Selenium RCと組み合わせると、cronやJenkinsなんかで定期的に課金情報を取得することも可能です。

    みなさんも愛を確認して、叫んでみて下さい:D

    雑感

    • Beanstalk の PHP 対応が来るらしい!
    • Hadoop / EMR 分かりやすかったです。
    • Hadoop のデモは地味:D
    • 決戦に参加できて勝てて良かった!
    • 今回のLTは(自分以外)レベル高かったー。
    • おっぱいぷるぷる。

    さあ、AWSをはじめよう! for PHPer

    この記事の所要時間: 1116

    春ということで、Amazon Web Services(AWS)をはじめてみませんか。

    AWS盛り上がっていますね。2011年3月に東京リージョンができたことで、そろそろ触ってみようかなというPHPユーザの方も多いかと思います。

    そんなあなたへ、AWSをはじめる際に役立つ情報をご紹介です。

    1. AWSアカウントを新規作成して、EC2の利用申し込みを行う

    まずAWSのアカウントを作成して、EC2の利用申し込みを行います。

    手順については、AWSエバンジェリストの @KenTamagawa さんが書かれた以下の資料が参考になります。このとおりに進めていけば、おおよそ問題無いと思います。

    進める中で自分が詰まった点は以下。

    郵便番号、電話番号にはハイフンを

    郵便番号、電話番号はハイフンが必要なので入力するようにして下さい。

    書式は日本国内のもの、郵便番号8ケタ(ハイフン入り)、電話番号は12〜13ケタ(ハイフン入り)で大丈夫です。

    電話にびびらない

    EC2の利用申し込みでAmazonから電話がかかってくる場面があります。

    実は、はじめてアカウントを作成して利用しようとした時は申込画面も英語版しか無かったので、英語な人から電話がかかってくるのかと思って、それはそれはびびっていました。気持ちの整理を付けるために2,3日かかった記憶があります:D

    まあ冷静に考えてみれば分かりますが、人がかけてくるわけではなく、機械がかけてきます。電話を取るとアナウンスが流れるので、あとは画面に表示された暗証番号をプッシュで入力すればokです。(人がかけてくる場面を想像すると面白いですが:-p)

    暗証番号を入力するとすぐに次の画面に遷移するので、これはこれで近未来な感じがして感動しました。

    クレジットカードが必要

    アカウント作成、EC2の利用申し込みは無料ですし、サービスを利用(EC2インスタンスを起動など)しない限りは費用は発生しませんが、クレジットカードの登録は必須となります。ご注意を。

    2. EC2を触ってみる

    では実際にブラウザでAWS Management ConsoleへアクセスしてEC2インスタンスを起動してみましょう。

    この手順についても、@KenTamagawa さんが書かれた資料が参考になります。

    補足としては以下の点あります。

    SSHログインユーザ

    このスライドのようにAmazon Linuxを利用する場合は「ec2-user」ユーザでSSHログインして下さい。他のOSで起動した際は、rootユーザでログインする場合もあるので間違えないようにご注意を。

    SSHコマンドでログイン

    SSHでログインするツールは、sshコマンドでも何でも良いです。その際はダウンロードした秘密鍵を -i で指定して下さい。

    $ ssh -i /path/to/demo-key.pem ec2-user@PUBLIC_DNS_HOST
    

    なお手元のMacではPublic DNSにあるFQDNを指定すると「ControlPath too long」というエラーが発生します。こういった場合は、Public DNSからIPを引いて、IP直で指定すればログインできます。(ただしIP変更が起こる場合があるので、可能ならFQDNでログインした方が良いです。)

    $ dig ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
    
    xxx.xxx.xxx.xxx
    $ ssh -i /path/to/demo-key.pem ec2-user@xxx.xxx.xxx.xxx
    

    PHPのインストール

    Amazon LinuxでPHPを利用するには、yumでインストールするだけです。

    $ sudo yum -y install php
    

    Amazon LinuxでインストールされるPHPのバージョンは、5.3.6です。(2011/04/12現在)

    $ php -v
    PHP 5.3.6 (cli) (built: Mar 29 2011 19:13:32)
    Copyright (c) 1997-2011 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    

    あとは必要に応じて、yumコマンドやpear、peclコマンドで追加していきましょう。

    3. AWS SDK for PHP

    まずAWSを利用する準備が整いました。

    これからEC2インスタンス(サーバ)のセットアップをして、S3やEBS、RDSなどなどを活用していくと思うのですが、PHPerなら是非おさえておきたいのが「AWS SDK for PHP」です。

    AWSはクラウド環境として多種多様なサービスを展開しているのですが、そういったサービスをAPIで操作することができます。例えばEC2インスタンスの起動、停止といった作業がどこからでもAPIで操作できるわけです。このAPIが揃っているのがAWSの特徴で、なかにはR53のようにAPIでのみ操作可能(AWS Management Consoleでは操作できない)なサービスがあるくらいです。

    このAPIを活用すれば、独自の管理コンソールを構築することも可能で、実際そういったサービスも外部ベンダーから提供されています。

    そんな便利なAPIなのですが、このAPIをPHPから簡単に操作できるようにSDKが提供されています。それが「AWS SDK for PHP」です。

    3-1. 要件

    AWS SDK for PHPは以下の環境で動作します。

    PHPのバージョンさえクリアしておけば、あと必要なのはcURLくらいでしょうか。

    ちなみに2.で構築したAmazon Linux環境のPHPでは、下記条件は全て満たされていました。

    • PHP5.2以上(5.2.14 or 5.3.x推奨)
    • SimpleXML / JSON / PCRE / SPL
    • cURL PHPエクステンション(HTTPSサポート)
    • file_get_contents() / file_put_contents() でファイルシステムを読み書きできる環境

    3-2. インストール

    AWS SDK for PHPはPHPソースで書かれたライブラリです。ダウンロードするだけで利用できますので、お好みの方法でインストールして下さい。

    • http://aws.amazon.com/sdkforphp からダウンロード
    • git
    • subversion
    • pear

    ここではgitでインストールしています。

    $ sudo yum -y install git  //git のインストール(git環境があれば不要)
    $ git clone git://github.com/amazonwebservices/aws-sdk-for-php.git AWSSDKforPHP
    $ ls
    AWSSDKforPHP
    

    要件やインストール方法はドキュメントがあるのでこちらを参考にして下さい。
    => Getting Started with the AWS SDK for PHP

    3-3. 認証情報の取得

    AWS SDK for PHPを実際に利用する際はAWSアカウントの認証情報が必要となります。

    認証情報はAWSのWebサイトで取得できます。

    まずグローバルナビの「アカウント」をクリックします。クリックするとアカウントのメニューが表示されるので下図のように「セキュリティ証明書」をクリックします。

    セキュリティ証明書ページが表示されたら(もしログイン画面が表示されたらログインして下さい)、下図の「アクセス証明書」を表示します。ここにある「アクセスキーID」「シークレットアクセスキー」が認証情報となります。

    3-4. サンプル

    では実際にAWS SDK for PHP(以下、SDK)を使ってサンプルを作ってみます。

    ここでは全リージョンのEC2インスタンスを取得して表示してみましょう。

    サンプルファイルはSDKが入っているAWSSDKforPHPディレクトリと同じ階層に設置します。

    $ ls
    AWSSDKforPHP sample.php
    

    サンプルソースは以下です。

    まず require_once() でSDKを読み込みます(1)。これはどのサービスに対する処理を書く時も同じです。

    次は、処理対象のリージョンを連想配列に格納しています(2)。SDKで処理を行う際は対象のリージョンをセットする必要があります。今回のサンプルでは全リージョンに対して処理を行うので、連想配列に格納しておきます。

    次に、EC2へ処理を行うAmazonEC2クラスをインスタンス化します(3)。コンストラクタにて3-3で確認した認証情報をセットしています。第1引数が「アクセスキーID」、第2引数が「シークレットアクセスキー」となっています。

    書籍のサンプルなどを見ると認証情報はSDK用の設定ファイルである「config.inc.php」に記載する例が多いのですが、個人的には認証情報は自分で管理したいのでコンストラクタで渡す方法がやりやすいです。

    ここからAmazonEC2インスタンスに対して処理を行います。

    まずset_region()で処理対象のリージョンを設定します(4)。そしてdescribe_instances()で対象リージョンのEC2インスタンス情報を取得して(5)、リージョン名とインスタンスIDをprintf()で出力しています。

    この処理を各リージョン毎に行います。

    3-5. 実行

    ではサンプルソースを実行してみましょう。

    下記結果から、us-westリージョンで1つ、ap-northeast(東京)リージョンで2つのEC2インスタンスが存在していることが分かります。

    $ php sample.php
    [us-west-1] i-xxxxxxxx
    [ap-northeast-1] i-yyyyyyyy
    [ap-northeast-1] i-zzzzzzzz
    

    このようにAWS SDK for PHPを利用すると簡単な記述でAPIを実行して、AWSを操作することができます。

    4. 参考書籍

    Webに様々な情報があるとはいえ、これからはじめるなら、やはり書籍などまとまった情報をじっくり学びたいところです。

    そこでAWSをこれからはじめるPHPerにおすすめな本をあげてみました。

    G-CLOUD Magazine 2011

    クラウド関連の情報が掲載されているムックです。AWSの特集があり、その中にAWS SDK for PHPの記事が掲載されています。

    他にもAWSの記事も多く掲載されており、特にgumiさんの「Amazon EC2 API Tools」を活用したサーバ構築を自動化する記事が参考になりました。

    Amazon Web Servicesガイドブック

    AWSを活用するPHPerにはおすすめの定番本です。

    この本ではAPIを利用してAWSを活用する実例が多数掲載されているのですが、それらのサンプルソースが全て「AWS SDK for PHP」を利用したものになっています。個人的にはタイトルを「AWS SDK for PHPガイドブック」にしても良いんじゃないかと思うくらいPHP満載のAWS本です。

    内容も単に機能紹介を並べているのではなく、実際のWebサイトなどの構築を通じてAWSの各サービスを活用するアイデアが書かれています。

    AWS SDK for PHP(aws.amazon.com)

    書籍では無いですが、AWSサイトでは「AWS SDK for PHP」のドキュメントが公開されています。

    導入方法にTips、そしてリファレンスが揃っており、SDKを活用していくには必須の内容となっています。

    => AWS SDK for PHP

    AWSを触ってみましょう

    いよいよクラウドの本格利用がはじまる今だからこそ、多種多様なクラウドサービスを個人で利用できるAWSを通じてクラウド利用の勘所を掴んでおくというのが大切だと思います。

    さらに「AWS SDK for PHP」の存在により、PHPコードで手軽にそういったサービスをプログラムで操作することができます。

    無料利用枠も提供されていますので、まだの人はぜひ一度AWSを使って、「プログラマブルデータセンター」と呼ばれるクラウド環境を体感してみてください。

    AWSで気になること4つを聞いてきた – 第1回 JAWS Osaka勉強会

    この記事の所要時間: 727

    第1回 JAWS(Japan AWS User Group) Osaka勉強会に行ってきました。

    大阪では貴重なクラウド系の勉強会、しかもAWSの方が来られる、さらにちょうどAWSを使える案件が出てきたタイミング(というか提案したのですが:D)ということで、参加してきました。

    おそらく他の参加される方は「はじめまして」の人ばかりですし、せっかくの機会なので LT もやってきました。

    ちなみに人見知りしたり、自己紹介が苦手だったりする人は発表してしまうのが良いですよ。発表の上手下手は関係無く、発表した人は印象に残りやすいです。数分でも自分の話を参加者全員が聞いて貰えるってなかなか無いですからね。
    @see 勉強会を楽しむなら発表しよう!

    AWSで聞きたいあれこれ

    「AWSで聞きたいあれこれ」というタイトルでLTしてきました。

    せっかくAWSエバンジェリスト、さらに識者の方達が集まる場なわけですから、日頃AWSを使っていてふと気になる疑問、「自分はこうしているんだけど、他の人はどうやっているのかなー」という質問を逆に聞いてしまおうと思い、通常の発表とは逆にみなさんに質問を投げかけるという内容にしました。

    本当は山ほど聞きたいことがあったのですが、とりあえずという事で基本的な 4 つについて聞いてきました。

    1. Region

    質問

    AWSアカウントを作って、さあ AWS Management Console で EC2 インスタンスを起動してみようと思った時にまず迷うのが region の選択です。(勉強会時点は)4 つの Region(US East / US West / EU West / Asia Pacific)があるのですが、日本向け Web システムを構築するならどの Region を選びますか?

    参考までに、各regionにmicroインスタンスを立てて、国内からpingを打ってみました。RTTを見るとUS WestかAsia Pacificかなーと思うのですが、日本向けWebシステムを作るとしたらどのregionを選びますか?もしくは選んでますか?

    会場からの回答

    • US West と Asia Pacific が半々くらい。US Eastもちらほら。EU Westはナシ。
    • Asia Pacificでも経路によっては、国内からでも80msくらい出る。
      => たしかにさくらVPSからだと70msくらい出ますね。
    • US Eastをあえて選ぶ理由は価格。
      => 速度を気にしなくて良い or 工夫できるなら、価格も大事な要素です。
    • RTTだけが重要なわけでは無い。
    • Asia Pacificを選んで困ったとこは特に無し。

    感想

    pingの結果を見ると、やっぱりUS Westを選ぶ人が多いように思っていたのですが、Asia Pacificの人も結構多かったです。ちょうどAsia Pacificのサーバを作っていたところだったので安心しました。

    より近いregionができれば悩む必要の無くなるので、今後に期待したいですね。

    2. AMI

    質問

    EC2インスタンスを起動するときに選ぶAMIですが、Amazon AMIやPublic AMIなどの公開されているAMIを利用しますか?それとも自分でイチからOSを入れて構築したAMIを使いますか?なお、前者の場合は起動したインスタンスをカスタムして別のAMIを生成することも含みます。

    会場からの回答

    • 全員公開されているAMIを利用で、OSをイチから入れるという人はいませんでした。
    • 公開されているAMIを利用しつづけて困ったことは特に無い。
    • やはりAmazonとしては、Amazon Linuxがおすすめ?
      => 必ずしもそうではない。利用者の自由。
    • Amazon Linuxを利用すれば、AWS Premium Supportで有利?
      => 有利というわけではないが、Amazonで仕様を把握しているので回答は得られやすい。
    • 会場でも何名かの人が実際にAmazon Linuxを利用しました。

    感想

    ここもEC2を使う上で悩むポイントでした。

    Googleで「EC2 AMI」で検索すると、AMIをOSイメージから作成する情報が多くひっかかり、逆に公開されているこのAMIを使うと良いといった情報があまり無かったので、実はOSイメージからAMIを作成してそれをラウンチするのが一般的なのかと思っていました。

    個人的にはrightscaleのAMIを利用していて、それで困ったことは無いのですが、やはり同じような使い方をしている人が多いということで安心しました。また、Amazon Linux を本稼働で利用しているという意見も聞けたので今後は利用してみようと思います。

    3. Root Device

    質問

    AMIを選ぶ時にも絡むのですが、Root Deviceの選択です。instance storeとEBSの2種類が選択でき、それぞれ特徴があります。どちらを利用していますか?利用しますか?

    これはあくまでRoot Deviceだけの話で、instance storeがRoot Deviceでもデータ領域にEBSをマウントする方法は、前者になります。

    会場からの回答

    • ほとんどの人がEBS。
    • サーバ用途にもよる。
    • 従来はinstance storeだったものをEBSへ移行している。
    • Root Deviceをinstance storeにしているのは、以前はRoot DeviceにEBSが利用選択出来なかったからでは。
    • EBSは速度的に不利という話があるが?
      => とくにそれで困ったという意見はありませんでした。

    感想

    EBSは数多くのメリット(インスタンス停止時にデータが消えない、スナップショット(バックアップ)が容易、AMIが簡単に作成できる、別サーバにattachできるなど)があるのでDevice Rootとして利用したいと思っていました。

    速度的に不利という情報もあったので、実際のところどうなのかと思っていたのですが、とくに支障は感じないということだったので良かったです。

    何か明確な理由が無いかぎりはEBSをRoot Deviceに選んで良さそうですね。

    4. EBS Snapshot

    質問

    EBSの特徴でもあるスナップショットですが、簡単にボリューム全体のバックアップが取れるという優れものです。日々のバックアップとして利用しているのですが、実際のところ困ったこととかありませんか?

    例えばスナップショットでバックアップを取っていたが、いざリストアしようとしたらデータが不完全で困った、など。

    会場からの回答

    • 困ったという意見はナシ。
    • スナップショットはS3に保存される。S3の耐久性はイレブンナイン(99.999999999%)なので、まず大丈夫。
      => 自前でバックアップストレージ用意するよりはるかに安全ですね。。。
    • ただファイルシステムの整合性は担保されていないので、これは自分でフォローする。
      => 書き込みロックする、DBはダンプする、など。
      => 書き込みが頻繁で無いなら、世代数を多めに取るという考えもあり。
    • 念のため他のバックアップ方法と組み合わせている人は?
      => いませんでした。

    感想

    EBSのスナップショットは簡単にバックアップが取れるのでかなり便利なのですが、あまりに簡単過ぎて、根拠はないのですが若干不安があったりもしました。

    そういった心配は不要でしたので、安心して利用できますね。

    やってみて

    逆質問という形式でやってみたのですが、多く方々から様々な意見を頂いて、とても勉強になりました。まだまだ聞きたい内容はあるので、また次回以降でやってみたいと思います。

    回答頂いたみなさんありがとうございました!

    雑感

    こんなにAWSについて聞いたり話したりしたのは初めてでした:D

    他の方の発表ももちろんですし、懇親会でも(ここでは書けない)色々なお話を聞くことができて楽しかったです。やはり「生の声」が聞けるのは勉強会の醍醐味ですね。進化が速いAWSだけに最新情報を共有できるこういった場は貴重です。

    懇親会でJAWSの方々から「コアメンバーになる?」と声をかけて頂いたので、コアメンバーとしてお手伝いさせて頂くことになりました。具体的に何をやるのかはまだ分かっていませんが、コミュニティ活動に関わって行ければと思います。

    会場提供頂いた富士ソフトさん、AWSのお二方、JAWSのみなさん、ありがとうございました!

    GoogleAppEngine に関する議論について思うこと

    この記事の所要時間: 210

    appengine関連でTogetterから議論が巻き起こってますね。最近すっかりappengineをご無沙汰だった自分としては、一連のtweetやblogを読んだおかげですっかり熱が戻ってきました。

    議論の発端になったのは以下のTogetter。

    Togetter – 「Google AppEngineについて思うところ」

    議論を見ていて感じるところがあったので、ざざっと。

    • @makotokuwata さんの主張自体は自分はそれほど違和感無かった。ただ表現がキツイ箇所があったのが琴線に触れてしまったのかな。
    • 議論から有用なtweetやblogエントリが生まれてきた。これはとても参考になった。
    • 意識的にそうしていたわけではないだろうけど、寄ってたかって反論していくのは見ていて @makotokuwata さんが気の毒に感じた。
    • @makotokuwata さんがこれまでされてきた活動(Python4PHPer)は素晴らしいと思う(自分もイベントは気になってた)し、これからも続けられると良いのでは。(
      大きなお世話かもしれませんが)
    • ちなみに反論していた人には「appengine ja night」な方も多かったけど、自分がイベントに参加した時はアットホームな雰囲気でとても楽しかったです。技術的な内容ゼロの自分のLTも笑顔で聞いてくれたし。別にこわいひとたちでは無い(と思う)。
    • ようは、表現が少し過激だったり、ちょっとした言葉の行き違いが原因かと。自分も感情的になるとついつい余計なことを書いてしまうから気をつけないと。
    • 多分、飲み屋で同じ話すれば「おまえなにいうてんねん」というノリで軽い議論になるだけで、こんなややこしい話にはならなかったでしょうね。オンラインのコミュニケーションは難しい。。。
    • どちらかがどちらかのイベントに参加して懇親会とかで話せば、わだかりも解けると思うんだけどなー。

    今回のことでこれまで頑張ってこられた @makotokuwata さんが辛い思いをされているのは、とても悲しいことなので、気にせずに頑張って下さい。

    そういえば appengineを追いかけてる時に作ろうと思って放置していたものとかあるから、またやりだそうかな。

    appengine について参考になったエントリ

    ホーム > cloud

    検索
    フィード
    メタ情報

    Return to page top