Graham Weldon discusses building highly available and scalable PHP systems. He outlines different system architectures from simple single server setups to load balanced solutions with failover. Key aspects in scaling PHP applications include using Nginx as a web server, PHP-FPM for processing, a clustered database, and caching with Varnish. Session handling requires a common storage like Redis. Weldon also promotes Rakuten's hiring needs for engineers interested in scalable architecture and DevOps.

1. High availability PHP
Building scalable PHP systems
Building scalable PHP systems
Graham Weldon
Platform as a Service Development & Operations Group
Architecture Committee Office
Rakuten, Inc.

2. About me
• PHP Developer (15 years)
• Game Developer
• Dev Ops
• CakePHP Contributor
• Public Speaker for PHP
• Public Speaker for Open
Source
• Used to live in Australia
• Moved to Tokyo, Japan to work
for Rakuten, Inc.
• I love Tokyo (and Sapporo!)

3. (CakeMatsuri) PHP Matsuri

4. (CakeMatsuri) PHP Matsuri
2009

5. (CakeMatsuri) PHP Matsuri
2009 2010

6. (CakeMatsuri) PHP Matsuri
2009 2010 2011

7. (CakeMatsuri) PHP Matsuri
2009 20122010 2011

8. (CakeMatsuri) PHP Matsuri
2009 201320122010 2011

10. What I do at work

11. Rakuten’s PaaS

12. Rakuten’s PaaS
• We build on top of Cloud Foundry
• Build new services
• Build new runtimes
• Support application developers
• Ensure a stable, forward-thinking platform is available
• Internal use only
• Highly available
• Easily scalable

13. By the way ...
• We’re hiring!
• If you’re interested in:
• large systems
• scalable architecture
• solving challenging problems
• Ask me for information!
• @predominant
• graham.weldon@mail.rakuten.com

14. We’re Hiring!
• Rakuten
Platform as a Service
• http://bit.ly/rakutenpaas

15. What does “Highly available” mean?
• No “single point of failure”
• Redundancy
• Failover systems

16. What does “Highly available” mean?
• In the event of a system failure
there are backup / alternative
systems available to take over
• No system failure should result
in applications being “down” or
offline
• The system is designed to
continue operating in the event
of failure

17. What does “scalable” mean?
• Easy to add more servers
• Distribute the load of users
amongst many servers
• Transparently add to the
compute pool to provide faster
response times
+
+
+

18. System design / architecture

19. Simple Web Setup
Internet

20. Simple Web Setup
Internet LimitedLimited
BandwidthBandwidth

21. Simple Web Setup
Internet LimitedLimited
BandwidthBandwidth
SingleSingle
WebserverWebserver

22. Simple Web Setup
Internet LimitedLimited
BandwidthBandwidth
SingleSingle
WebserverWebserver
Single DatabaseSingle Database

23. Simple Web Setup
Internet LimitedLimited
BandwidthBandwidth
SingleSingle
WebserverWebserver
Single DatabaseSingle Database
No FailoverNo Failover
solutionsolution

24. Simple Web Setup
Internet LimitedLimited
BandwidthBandwidth
SingleSingle
WebserverWebserver
Single DatabaseSingle Database
No FailoverNo Failover
solutionsolution
No scalingNo scaling

25. Simple Setup
• We have all done this before
• It works well for very small sites
• You will encounter problems when the number of users grows
• There is no way to recover from system failure
• Any failure will produce extensive downtime

26. A better solution
Internet

27. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
Traffic goes to the primary server

28. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
When a failure occurs on the
primary server...

29. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
Traffic is redirected to the
backup server

30. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
FailoverFailover
availableavailable

31. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
FailoverFailover
availableavailableFailover reliesFailover relies
on DNSon DNS

32. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
FailoverFailover
availableavailableFailover reliesFailover relies
on DNSon DNS
NotNot
scalablescalable

33. A better solution
Internet
PrimaryPrimary
Backup /Backup /
FailoverFailover
FailoverFailover
availableavailableFailover reliesFailover relies
on DNSon DNS
NotNot
scalablescalable
Database SyncDatabase Sync
problems?problems?

34. A better solution
• A backup is now available
• We can switch traffic to the backup server in case of failure
• Highly available?
• A little bit
• Scalable?
• No
• Its a better solution than the previous example
• But its not ideal

35. An even better solution
Internet
Load BalancersLoad Balancers
Load balancers distribute the load

36. An even better solution
Internet
Load BalancersLoad Balancers
WebWeb
ServersServers
A pool of webservers are available
to handle the incoming traffic

37. An even better solution
Internet
Load BalancersLoad Balancers
WebWeb
ServersServers
DBDB
ServersServers
Webservers connect to a database cluster
to distribute load

38. An even better solution
Internet
Load BalancersLoad Balancers
WebWeb
ServersServers
DBDB
ServersServers
LoadLoad
balancedbalanced

39. An even better solution
Internet
Load BalancersLoad Balancers
WebWeb
ServersServers
DBDB
ServersServers
ScalableScalable
LoadLoad
balancedbalanced

40. An even better solution
Internet
Load BalancersLoad Balancers
WebWeb
ServersServers
DBDB
ServersServers
FailoverFailover
availableavailable
ScalableScalable
LoadLoad
balancedbalanced

41. A perfect solution?
• There are good solutions available
• No solution is perfect
• Consider the parts of the system that can fail
• Build it in a highly available way
• Allow additional servers / services to be added through configuration
• Or.. through auto detection

42. Scaling PHP
A Case Study of the Rakuten Platform

43. Web Server
• Nginx
• Why?
• Fast
• Reliable
• Stable
• Low resource usage
• Designed for high speed
• Easy configuration

44. Optimization
• PageSpeed
• Optimization tool from Google
• Open Source
• Easy to install
• Lots of options
• Optimizes your pages
• Image processing
• JS/CSS compression

45. PHP
• PHP-FPM
• “Fast Process Manager”
• Easy to configure
• Fast when configured right
• Process pooling
• Simple to setup

46. Databases
• A range of options
• Redis
• MongoDB
• Clusterix (MySQL Compatible)
• Each in a clustered setup
• Highly available
• Scalable

47. Database considerations
• Optimize queries
• Use fast disks!
• Large memory
• Lots of CPU
• Database is often a bottleneck
• Make sure you have enough
resources

48. Content Delivery
• Use a Content Delivery
Network for static content
• Or.. use a separate server for
delivering static content to
ensure PHP has the
processing power it needs
• Speeds up browser requests
for static files
• Allows concurrent requests
with less work / effort

49. Varnish
• HTTP accelerator
• In-memory caching
• Huge performance increases
• 300-1000x speed increase

50. Special considerations

51. Session Storage
• You need a common place for all servers to access for session storage
• We recommend Redis
• Common storage ensures that sessions will be maintained
• Without common storage, users will lose their session data between
page requests.

52. Session Storage
Web Servers Session Store

53. Session Storage
• php.ini
• session.save_handler = ‘redis’
• session.save_path = ‘tcp://host:port, ...’

54. Opcode Caching
• OpCache (Extension)
• Bundled with PHP 5.5+
• Available as an extension for earlier versions
• Faster than XCache
• Simple to setup
• OpCache will cache per-server
• You might want to pre-warm the cache for all servers
• I don’t have a better solution for this yet

55. Thankyou!
Any questions?

56. • We’re looking for talented engineers!
• Interested in DevOps?
• Interested in highly available systems?
• Contact me!
• @predominant
• Rakuten
Platform as a Servicehttp://bit.ly/rakutenpaas
• Rakuten
Public Cloud Section
http://bit.ly/rakutenpcs