PHP x AWS でスケーラブルなシ
ステムをつくろう
2015-06-27 PHPカンファレンス福岡
ハンズラボ株式会社
井上泰治

自己紹介
• 井上 泰治 （いのうえ たいじ）
• ハンズラボ株式会社
• Twitter: inufs
• Github: inouet
ECサイトのバックエンド開発などをやっています。
PHPはPHP3の頃から、かれこれ 10年くらい使って
います。

もくじ
１. スケーラブルなシステムとは
2. サービスの成長に伴う課題と解決方法
3. まとめ
１. スケーラブルなシステムとは

スケーラビリティとは
Wikipediaより抜粋
負荷の高低に合わせてリソース・
プールを拡大・縮小できること
短時間に 自動的に

スケーラビリティとは
サーバ
本などに書いてあるスケーラビリティ

スケーラビリティとは
サーバ
スケールアップ

スケーラビリティとは
スケールアウト
こうなるようにすればよい
わかっとるわ！

実際には … 増え続ける構成要素
Database httpd Proxy / Cache
Cache Storage
Search
Deploy
Job QueueDevelop
Storage

スケーラビリティとは
実際にはシステムは複数の構成要素から構成され
る。WEBサーバ、アプリケーションサーバ、DBサー
バ、ロードバランサ、キャッシュ、ストレージなど。
それぞれの構成要素がスケールできるようになっ
ていなければならない。
ボトルネックとなりがちな所をAWSに任せて、
開発者はアプリケーション開発に集中しよう！

１. スケーラブルなシステムとは
2. サービスの成長に伴う課題と解決方法
3. まとめ

最小構成で頑張る期

１． 最小限構成で頑張る期
WEB/App/DB
サーバ
オール・イ
ンワン！

１． 最小限構成で頑張る期
WEB/App/DB
サーバ
起きうる課題
アクセス増加で、徐々にサーバー
負荷上昇
サイトが重くなる
まずはスペック上げてみる
AWSならサーバー停止は必要なものの
簡単にスペックを上げられる

DBサーバ
WEB/App
サーバ
セッション
アップロードファイル
リクエストはどうやって分散
する？
ファイルで持ってたセッショ
ンどうしよう
ユーザーがアップロードした
画像どうしよう
とりあえず、
サーバー分けたけ
ど…
１． 最小限構成で頑張る期

WEB/App
サーバ
S3 memcached
画像など セッション
ロードバランサ(ELB)を導
入しよう
セッションはmemcached
に持たせよう
アップロードされたファイ
ルの共有にはS3を使おう
DBサーバ
１． 最小限構成で頑張る期

１． 最小限構成で頑張る期
PHPにはセッションハンドラという機構があり、
保存先のストレージを設定で変更できるようになっている。
また独自のハンドラを実装することで、新しい保存先を自分で
追加することも可能。
session.save_handler = memcache
session.save_path = 'tcp://10.1.1.1:11211’
/etc/php.ini
最近のフレームワークはその機能を元から同梱していることがほとんどなので、
たいていはフレームワークの設定で済む。
例) http://laravel3.kore1server.com/docs/cache/config#memchached
セッションハンドラについて

１． 最小限構成で頑張る期
主にPHPのSDKからアップする方法と、コマンドラインからアップロードする
2通りの方法がある。 下記はSDKを使った例
S3へのアップロードについて

それっぽい構成（初期）

2．それっぽい構成（初期）
DBサーバ
WEB/App
サーバ
S3 memcached
画像など セッション
徐々にDBが重くなってきた。
起きうる課題
せっかくmemcachedあるんだし、
ガンガンキャッシュしちゃえ
→ memcachedも悲鳴を上げだ
した。
ELB

node1 node2
下記のように、増やしたサーバを
その都度追加しても良いのですが…
Memcachedサーバを追加するたびに、
アプリケーションコードもしくは設定ファイルの修正が必
要になる。
Appサーバ
まずはmemcached増やしてみよう
追加
2．それっぽい構成（初期）

2．それっぽい構成（初期）
node1 node2
Cluster Client が サーバーの増減を検知して適切なサーバーに
割り振ってくれる
→ 増減のたびに設定ファイルとかを変更しなくて良い。
エンドポイント
node3
Appサーバ
そこで ElastiCache Cluster Client for PHP
増減を自動
検出
pecl ライブラリが提供されている
・・・・
http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/AutoDiscovery.html

2．それっぽい構成（初期）
さて、DBサーバーどうしよう
HAProxy / Keepalived
Write Read
アプリケーションコードの改修が必要。
Write はこっち、Read はこっちみたいな。
できれば、マスタスレーブ構成に対応し
やすいフレームワークを採用しておくとこ
の時に困らない。
http://recipes.laravel.jp/recipe/463
まずレプリケーション組んでみる

それっぽい構成（中期）

2．それっぽい構成（中期）
DBサーバ
WEB/App
サーバ
S3
キャッシュサーバ
画像、動
画など セッション、キャッシュ
ELB

起きうる課題
DBのマスタだけ負荷が高い。
2．それっぽい構成（中期）
数1000万レコードとかあるテーブルが出て
きて検索も徐々に遅くなってきた。
→ 書き込みがボトルネックに
→ JOINすると死ぬ。
レプリケーション遅延

2．それっぽい構成（中期）
このままRDBを使って頑張るか、他のアー
キテクチャに乗り換えるか。
どちらを選んでもそれなりのアプリケー
ション改修コストはかかる。
ここが転換期

2．それっぽい構成（中期）
RDBで頑張る場合
テーブル分割 or
パーティショニング
DB分割
ユーザーDB 記事DB
user_id user_name
1001 佐藤
1011 山田
user_id user_name
1002 田中
1012 鈴木
users_01
users_02

2．それっぽい構成（中期）
 いままでのアーキテクチャが使えるので新しい学習コストはかからない。
 トランザクションが使える（ただしDBまたぐと厳しい）
 柔軟なクエリ
デメリット
メリット
 とはいえJOINできなくなってくる。
 テーブル分割すると横断した検索ができない。
 それなりの作り込み（改修）が必要で、分割する対象が増えるたびに必要。
 アプリケーションコードの複雑化。
 自動的にはスケールできない。
RDBで頑張る場合

2．それっぽい構成（中期）
Amazon DynamoDB
RDBからNo SQLへ
他のアプローチ

2．それっぽい構成（中期）
DynamoDBとは
AWSのフルマネージド型 NoSQL データベース
• 高いスケーラビリティ
• 高い信頼性
• 高速なデータ・アクセス

PHP SDKを使ってテーブルにレコードを保存する例
2．それっぽい構成（中期）

2．それっぽい構成（中期）
• スケーラビリティ
 指定したスループットまで自動的にスケール
 一度プログラムを書けばそれがスケールするシステムに。
 容量の心配も不要
• DB保守からの開放
DynamoDBの場合
デメリット
• トランザクションはあきらめる
• 学習コスト
• アプリケーションによって向き不向きがある
• 検索の自由度が低いので、他のシステムとの併用が必要
 連携部分の作り込みはそれなりに必要
メリット

それっぽい構成（後期）

2．それっぽい構成（後期）
WEB/App
サーバ
S3
キャッシュサーバ
画像、動
画など セッション、キャッシュ
DynamoDB
検索
CloudSearch
ELB

誰かがまごころ込めて作ったAMIをもとに
EC2立ち上げて、git からソースをcloneしてきてELBにアタッチす
る
刺し身たんぽぽ的作業を経てサーバー1台追加
Bashの脆弱性来た！SSL祭り来た！ 既存のサーバーを直接
アップデート
↓
AMIの更新忘れていつの間にかデグレード
2．それっぽい構成（後期）
APPサーバも増えて、構成管理とかデプロイとか
ちゃんとしないとそろそろ辛い。
再現性の
低いデプ
ロイ
人力ス
ケール

AWSの中でのPaas (Herokuみたいなやつ）
構成管理、デプロイ、オートスケールまで面倒見てくれ
る
 流行ってないのがとても残念
もちろん PHPもサポート
インスタンス内にsshで入れるなど自由度はわりと高め
そこで Elastic Beanstalk
Elastic Beanstalkとは

Elastic Beanstalkのサポートする環境
• Java (Tomcat)
• PHP (Apache)
• Python (Apache)
• Node.js
• Ruby (Passenger/Puma)
• .NET (IIS 7.5/8)
• Docker

Elastic Beanstalkによる構成管理
Beanstalkでは .ebextensions というフォルダの内の設定
ファイルで構成管理を行う。
パッケージのインストール
コマンドの実行
ユーザー/グループの作成
AWSリソースの設定
実行タイミング 実行内容例
下記が詳しい
http://www.slideshare.net/AmazonWebServicesJapan/aws-aws-elastic-beanstalk
デプロイ実行前
デプロイ中
デプロイ後

Elastic Beanstalkによる構成管理
設定ファイルの例
packages:
yum:
php55-opcache: []
commands:
01-command:
command: pecl install redis
02-command:
command: pecl install uri_template
パッケージのイ
ンストール
コマンドの実
行

Elastic Beanstalkによるデプロイメント
ZIPファイルにまとめてアップロードする方法と、
ebコマンドでデプロイする方法がある。
ebコマンドの方が便利。
$ eb deploy –profile=production
--version=v1.5
※ eb コマンドには v2とv3があり、v2の古い情報が多いので注意
これを実行すると git レポジトリの v1.5のタグが付けられた
ソースが zipファイルとしてS3にアップされ、自動的に
デプロイ処理が開始する。

Elastic Beanstalkによるデプロイメント
example.com
FQDN-1
Deploy (Ver2)
ver1
ver2
CNAME
FQDN-2
Environmentを作成すると1つFQDNが払い出される
例) example-1.elasticbeanstalk.com
Env: A
Env: B
Blue-Green デプロイメント

Elastic Beanstalkによるデプロイメント
example.com
FQDN-2
ver1
ver2
FQDN-1
SWAP
Env: A
Env: B
Blue-Green デプロイメント
コマンド1発で完了

Elastic Beanstalkによるオートスケール
<５分間>の<CPU使用率>が <５０%> になったら、イン
スタンスを <１台><増やす>といった設定
CRONのように、 <○○ 時>になったら <○○台>に増や
す
といった設定。 繰り返しも可能
• CPU使用率
• ネットワークIN/OUT
• ディスクRead/Write OPS
• リクエストカウント
• Healty/UnHealty ホスト数
トリガーベース
時間ベース

2．それっぽい構成（後期）
WEB/App
サーバ
S3 キャッシュサーバ
画像など セッション、キャッシュ
DynamoDB
検索
CloudSearch
Auto Scaling groupElastic Beanstalk
スケールでき
そうな気がし
てきた！
AZ - a AZ - c
ELB

 APPサーバーと WEBサーバの分離
 CDN（CloudFront）の活用
 CIとの連携
 ログの外出し（fluentdなどの活用）
 非同期処理（SQS、ワーカー）
 監視（リソース／サービス）
 役割によるサービス分割 (Microservices)
 Lambdaによるイベント処理
 2 tier アーキテクチャ
大規模な環境に向けて
いままでの話で出てこなかったけど
やっておいた方が良いと思われること

おまけ： RDBへの新たな光
Amazon RDS for Aurora
• MySQL互換
• モノリシックなアーキテクチャをクラウドベースで
再構築
• 高い信頼性
• 高い可用性
• 現在プレビューリリース

１. スケーラブルなシステムとは
2. サービスの成長に伴う課題と解決方法
3. まとめ

三種の神器 (Beanstalk / DynamoDB / S3 ) で作っておく
と1回作ったアプリケーションは改修なしでスケールす
る。
とはいえ、最初から完璧なものを開発する必要はない。
→ サービスの規模に応じてその都度対応。
AWSにはサービスの成長を助けてくれるいろんなパー
ツが用意されているのでうまく活用しよう。
PHPからAWSリソースを使い倒そう。
まとめ

AWS と PHP があれば、
いくらでもスケールするサービス
が作れます。
世界を変えるサービスを作るチャ
ンスをみんなが持っています！！
まとめ

Make the World a better
place with our hands.
ご清聴ありがとう
ございました。