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 に任せ

て、　開発者はアプリケーション開発に集中しよ

う！



3. まとめ

最小構成で頑張る期

１．最小限構成で頑張る期

WEB/App/DBサーバ

オール・インワン！


WEB/App/DBサーバ

起きうる課題

アクセス増加で、徐々にサーバー負荷上昇サイトが重くなる

まずはスペック上げてみる

AWS ならサーバー停止は必要なものの簡単にスペックを上げられる

DB サーバ

WEB/Appサーバ

セッションアップロードファイル

リクエストはどうやって分散する？

ファイルで持ってたセッションどうしよう

ユーザーがアップロードした画像どうしよう

とりあえず、サーバー分けたけ

ど…


WEB/Appサーバ

S3 memcached

画像など

セッション

ロードバランサ (ELB) を導入しよう

セッションはmemcached に持たせよ

う

アップロードされたファイルの共有には S3

を使おうDB サーバ



PHP にはセッションハンドラという機構があり、保存先のストレージを設定で変更できるようになっている。また独自のハンドラを実装することで、新しい保存先を自分で追加することも可能。

session.save_handler = memcachesession.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

2 ．それっぽい構成（初期）さて、 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-2ver1

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 group

Elastic Beanstalk

スケールできそうな気

がしてきた！

AZ - a AZ - c

ELB

　 APP サーバーと WEB サーバの分離　 CDN （ CloudFront ）の活用　 CI との連携　ログの外出し（ fluentd などの活用）　非同期処理（ SQS 、ワーカー）　監視（リソース／サービス）　役割によるサービス分割

(Microservices)　 Lambda によるイベント処理　 2 tier アーキテクチャ

大規模な環境に向けて

いままでの話で出てこなかったけどやっておいた方が良いと思われること

おまけ：　 RDB への新たな光

Amazon RDS for Aurora

• MySQL互換• モノリシックなアーキテクチャをクラウドベースで再構築

• 高い信頼性• 高い可用性• 現在プレビューリリース



3. まとめ

三種の神器 (Beanstalk / DynamoDB / S3 ) で作っておくと 1回作ったアプリケーションは改修なしでスケールする。

とはいえ、最初から完璧なものを開発する必要はない。　→ サービスの規模に応じてその都度対応。

AWS にはサービスの成長を助けてくれるいろんなパーツが用意されているのでうまく活用しよう。

PHP から AWS リソースを使い倒そう。

まとめ

AWS と PHP があれば、いくらでもスケールするサービスが作れます。

世界を変えるサービスを作るチャンスをみんなが持っています！！

まとめ

Make the World a better place with our hands.

ご清聴ありがとうございました。

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

Technology