PHP x AWS でスケーラブルなシステムをつくろう

10,864 views

Published on

Published in: Technology
0 Comments
43 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,864
On SlideShare
0
From Embeds
0
Number of Embeds
5,538
Actions
Shares
0
Downloads
34
Comments
0
Likes
43
Embeds 0
No embeds

No notes for slide

PHP x AWS でスケーラブルなシステムをつくろう

  1. 1. PHP x AWS でスケーラブルなシ ステムをつくろう 2015-06-27 PHPカンファレンス福岡 ハンズラボ株式会社 井上泰治
  2. 2. 自己紹介 • 井上 泰治 (いのうえ たいじ) • ハンズラボ株式会社 • Twitter: inufs • Github: inouet ECサイトのバックエンド開発などをやっています。 PHPはPHP3の頃から、かれこれ 10年くらい使って います。
  3. 3. もくじ 1. スケーラブルなシステムとは 2. サービスの成長に伴う課題と解決方法 3. まとめ 1. スケーラブルなシステムとは
  4. 4. スケーラビリティとは Wikipediaより抜粋 負荷の高低に合わせてリソース・ プールを拡大・縮小できること 短時間に 自動的に
  5. 5. スケーラビリティとは サーバ 本などに書いてあるスケーラビリティ
  6. 6. スケーラビリティとは サーバ スケールアップ
  7. 7. スケーラビリティとは スケールアウト こうなるようにすればよい わかっとるわ!
  8. 8. 実際には … 増え続ける構成要素 Database httpd Proxy / Cache Cache Storage Search Deploy Job QueueDevelop Storage
  9. 9. スケーラビリティとは 実際にはシステムは複数の構成要素から構成され る。WEBサーバ、アプリケーションサーバ、DBサー バ、ロードバランサ、キャッシュ、ストレージなど。 それぞれの構成要素がスケールできるようになっ ていなければならない。 ボトルネックとなりがちな所をAWSに任せて、 開発者はアプリケーション開発に集中しよう!
  10. 10. 1. スケーラブルなシステムとは 2. サービスの成長に伴う課題と解決方法 3. まとめ
  11. 11. 最小構成で頑張る期
  12. 12. 1. 最小限構成で頑張る期 WEB/App/DB サーバ オール・イ ンワン!
  13. 13. 1. 最小限構成で頑張る期 WEB/App/DB サーバ 起きうる課題 アクセス増加で、徐々にサーバー 負荷上昇 サイトが重くなる まずはスペック上げてみる AWSならサーバー停止は必要なものの 簡単にスペックを上げられる
  14. 14. DBサーバ WEB/App サーバ セッション アップロードファイル リクエストはどうやって分散 する? ファイルで持ってたセッショ ンどうしよう ユーザーがアップロードした 画像どうしよう とりあえず、 サーバー分けたけ ど… 1. 最小限構成で頑張る期
  15. 15. WEB/App サーバ S3 memcached 画像など セッション ロードバランサ(ELB)を導 入しよう セッションはmemcached に持たせよう アップロードされたファイ ルの共有にはS3を使おう DBサーバ 1. 最小限構成で頑張る期
  16. 16. 1. 最小限構成で頑張る期 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 セッションハンドラについて
  17. 17. 1. 最小限構成で頑張る期 主にPHPのSDKからアップする方法と、コマンドラインからアップロードする 2通りの方法がある。 下記はSDKを使った例 S3へのアップロードについて
  18. 18. それっぽい構成(初期)
  19. 19. 2.それっぽい構成(初期) DBサーバ WEB/App サーバ S3 memcached 画像など セッション 徐々にDBが重くなってきた。 起きうる課題 せっかくmemcachedあるんだし、 ガンガンキャッシュしちゃえ → memcachedも悲鳴を上げだ した。 ELB
  20. 20. node1 node2 下記のように、増やしたサーバを その都度追加しても良いのですが… Memcachedサーバを追加するたびに、 アプリケーションコードもしくは設定ファイルの修正が必 要になる。 Appサーバ まずはmemcached増やしてみよう 追加 2.それっぽい構成(初期)
  21. 21. 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
  22. 22. 2.それっぽい構成(初期) さて、DBサーバーどうしよう HAProxy / Keepalived Write Read アプリケーションコードの改修が必要。 Write はこっち、Read はこっちみたいな。 できれば、マスタスレーブ構成に対応し やすいフレームワークを採用しておくとこ の時に困らない。 http://recipes.laravel.jp/recipe/463 まずレプリケーション組んでみる
  23. 23. それっぽい構成(中期)
  24. 24. 2.それっぽい構成(中期) DBサーバ WEB/App サーバ S3 キャッシュサーバ 画像、動 画など セッション、キャッシュ ELB
  25. 25. 起きうる課題 DBのマスタだけ負荷が高い。 2.それっぽい構成(中期) 数1000万レコードとかあるテーブルが出て きて検索も徐々に遅くなってきた。 → 書き込みがボトルネックに → JOINすると死ぬ。 レプリケーション遅延
  26. 26. 2.それっぽい構成(中期) このままRDBを使って頑張るか、他のアー キテクチャに乗り換えるか。 どちらを選んでもそれなりのアプリケー ション改修コストはかかる。 ここが転換期
  27. 27. 2.それっぽい構成(中期) RDBで頑張る場合 テーブル分割 or パーティショニング DB分割 ユーザーDB 記事DB user_id user_name 1001 佐藤 1011 山田 user_id user_name 1002 田中 1012 鈴木 users_01 users_02
  28. 28. 2.それっぽい構成(中期)  いままでのアーキテクチャが使えるので新しい学習コストはかからない。  トランザクションが使える(ただしDBまたぐと厳しい)  柔軟なクエリ デメリット メリット  とはいえJOINできなくなってくる。  テーブル分割すると横断した検索ができない。  それなりの作り込み(改修)が必要で、分割する対象が増えるたびに必要。  アプリケーションコードの複雑化。  自動的にはスケールできない。 RDBで頑張る場合
  29. 29. 2.それっぽい構成(中期) Amazon DynamoDB RDBからNo SQLへ 他のアプローチ
  30. 30. 2.それっぽい構成(中期) DynamoDBとは AWSのフルマネージド型 NoSQL データベース • 高いスケーラビリティ • 高い信頼性 • 高速なデータ・アクセス
  31. 31. PHP SDKを使ってテーブルにレコードを保存する例 2.それっぽい構成(中期)
  32. 32. 2.それっぽい構成(中期) • スケーラビリティ  指定したスループットまで自動的にスケール  一度プログラムを書けばそれがスケールするシステムに。  容量の心配も不要 • DB保守からの開放 DynamoDBの場合 デメリット • トランザクションはあきらめる • 学習コスト • アプリケーションによって向き不向きがある • 検索の自由度が低いので、他のシステムとの併用が必要  連携部分の作り込みはそれなりに必要 メリット
  33. 33. それっぽい構成(後期)
  34. 34. 2.それっぽい構成(後期) WEB/App サーバ S3 キャッシュサーバ 画像、動 画など セッション、キャッシュ DynamoDB 検索 CloudSearch ELB
  35. 35. 誰かがまごころ込めて作ったAMIをもとに EC2立ち上げて、git からソースをcloneしてきてELBにアタッチす る 刺し身たんぽぽ的作業を経てサーバー1台追加 Bashの脆弱性来た!SSL祭り来た! 既存のサーバーを直接 アップデート ↓ AMIの更新忘れていつの間にかデグレード 2.それっぽい構成(後期) APPサーバも増えて、構成管理とかデプロイとか ちゃんとしないとそろそろ辛い。 再現性の 低いデプ ロイ 人力ス ケール
  36. 36. AWSの中でのPaas (Herokuみたいなやつ) 構成管理、デプロイ、オートスケールまで面倒見てくれ る  流行ってないのがとても残念 もちろん PHPもサポート インスタンス内にsshで入れるなど自由度はわりと高め そこで Elastic Beanstalk Elastic Beanstalkとは
  37. 37. Elastic Beanstalkのサポートする環境 • Java (Tomcat) • PHP (Apache) • Python (Apache) • Node.js • Ruby (Passenger/Puma) • .NET (IIS 7.5/8) • Docker
  38. 38. Elastic Beanstalkによる構成管理 Beanstalkでは .ebextensions というフォルダの内の設定 ファイルで構成管理を行う。 パッケージのインストール コマンドの実行 ユーザー/グループの作成 AWSリソースの設定 実行タイミング 実行内容例 下記が詳しい http://www.slideshare.net/AmazonWebServicesJapan/aws-aws-elastic-beanstalk デプロイ実行前 デプロイ中 デプロイ後
  39. 39. Elastic Beanstalkによる構成管理 設定ファイルの例 packages: yum: php55-opcache: [] commands: 01-command: command: pecl install redis 02-command: command: pecl install uri_template パッケージのイ ンストール コマンドの実 行
  40. 40. Elastic Beanstalkによるデプロイメント ZIPファイルにまとめてアップロードする方法と、 ebコマンドでデプロイする方法がある。 ebコマンドの方が便利。 $ eb deploy –profile=production --version=v1.5 ※ eb コマンドには v2とv3があり、v2の古い情報が多いので注意 これを実行すると git レポジトリの v1.5のタグが付けられた ソースが zipファイルとしてS3にアップされ、自動的に デプロイ処理が開始する。
  41. 41. 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 デプロイメント
  42. 42. Elastic Beanstalkによるデプロイメント example.com FQDN-2 ver1 ver2 FQDN-1 SWAP Env: A Env: B Blue-Green デプロイメント コマンド1発で完了
  43. 43. Elastic Beanstalkによるオートスケール <5分間>の<CPU使用率>が <50%> になったら、イン スタンスを <1台><増やす>といった設定 CRONのように、 <○○ 時>になったら <○○台>に増や す といった設定。 繰り返しも可能 • CPU使用率 • ネットワークIN/OUT • ディスクRead/Write OPS • リクエストカウント • Healty/UnHealty ホスト数 トリガーベース 時間ベース
  44. 44. 2.それっぽい構成(後期) WEB/App サーバ S3 キャッシュサーバ 画像など セッション、キャッシュ DynamoDB 検索 CloudSearch Auto Scaling groupElastic Beanstalk スケールでき そうな気がし てきた! AZ - a AZ - c ELB
  45. 45.  APPサーバーと WEBサーバの分離  CDN(CloudFront)の活用  CIとの連携  ログの外出し(fluentdなどの活用)  非同期処理(SQS、ワーカー)  監視(リソース/サービス)  役割によるサービス分割 (Microservices)  Lambdaによるイベント処理  2 tier アーキテクチャ 大規模な環境に向けて いままでの話で出てこなかったけど やっておいた方が良いと思われること
  46. 46. おまけ: RDBへの新たな光 Amazon RDS for Aurora • MySQL互換 • モノリシックなアーキテクチャをクラウドベースで 再構築 • 高い信頼性 • 高い可用性 • 現在プレビューリリース
  47. 47. 1. スケーラブルなシステムとは 2. サービスの成長に伴う課題と解決方法 3. まとめ
  48. 48. 三種の神器 (Beanstalk / DynamoDB / S3 ) で作っておく と1回作ったアプリケーションは改修なしでスケールす る。 とはいえ、最初から完璧なものを開発する必要はない。 → サービスの規模に応じてその都度対応。 AWSにはサービスの成長を助けてくれるいろんなパー ツが用意されているのでうまく活用しよう。 PHPからAWSリソースを使い倒そう。 まとめ
  49. 49. AWS と PHP があれば、 いくらでもスケールするサービス が作れます。 世界を変えるサービスを作るチャ ンスをみんなが持っています!! まとめ
  50. 50. Make the World a better place with our hands. ご清聴ありがとう ございました。

×