PHP x AWS でスケーラブルなシステムをつくろう

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増やしてみよう
追加

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

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

それっぽい構成（中期）

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

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

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

RDBで頑張る場合
テーブル分割 or
パーティショニング
DB分割
ユーザーDB 記事DB
user_id user_name
1001 佐藤
1011 山田
user_id user_name
1002 田中
1012 鈴木
users_01
users_02

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

Amazon DynamoDB
RDBからNo SQLへ
他のアプローチ

DynamoDBとは
AWSのフルマネージド型 NoSQL データベース
• 高いスケーラビリティ
• 高い信頼性
• 高速なデータ・アクセス

PHP SDKを使ってテーブルにレコードを保存する例

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

それっぽい構成（後期）

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

誰かがまごころ込めて作ったAMIをもとに
EC2立ち上げて、git からソースをcloneしてきてELBにアタッチす
る
刺し身たんぽぽ的作業を経てサーバー1台追加
Bashの脆弱性来た！SSL祭り来た！既存のサーバーを直接
アップデート
↓
AMIの更新忘れていつの間にかデグレード
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にアップされ、自動的に
デプロイ処理が開始する。

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

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 ホスト数
トリガーベース
時間ベース

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互換
• モノリシックなアーキテクチャをクラウドベースで
再構築
• 高い信頼性
• 高い可用性
• 現在プレビューリリース

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

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

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

PHP x AWS でスケーラブルなシステムをつくろう

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to PHP x AWS でスケーラブルなシステムをつくろう (20)

Recently uploaded (9)

PHP x AWS でスケーラブルなシステムをつくろう