Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Scaling Symfony - From single to multi-node cluster

5 287 vues

Publié le

Presentation shows process of scaling Symfony based application. Starting from single server, we show steps until the Service Oriented Architecture (SOA). To solve scalability issues we will use popular Symfony bundles.

Presentation from the 5th Wrocław's Symfony Group meetup which took place on 1.03.2016.

Publié dans : Technologie
  • Login to see the comments

Scaling Symfony - From single to multi-node cluster

  1. 1. Scaling Symfony From single to multi-node cluster Antoni Orfin antoniorfin@gmail.com
  2. 2. THEORY Scaling types 1. Vertical Scaling 2. Horizontal Scaling
  3. 3. THEORY Scaling types Real life: Vertical ! horizontal
  4. 4. SCALABILITY PATH 0. Caching HTTP Cache 1. Browser cache (private) 2. Proxy cache (shared) 0 1st Tier Cache – Reverse Proxy Caches HTTP responses. Most performant, close to the user. E.g. Varnish 1 $response = new Response; $response->setMaxAge(600); // For user’s browser $response->setSharedMaxAge(600); // For reverse proxy $response->setVary([’User-Agent’]); // Reverse proxy should cache // different responses for UA @Cache(smaxage=”15”, // Configure using annotations vary={”User-Agent”}) 2nd Tier Cache – in-application Caches database query results, long-term operations. E.g. Redis, Memcache (mostly in-memory) 2
  5. 5. App DB App Db Single server with Application (PHP, Symfony) and Database (MySQL) Separated servers servers separated by their roles Beware of ping between app and DB " SCALABILITY PATH 1. Separating servers
  6. 6. $ htop F4 (filter): mysql collectd SCALABILITY PATH 1. Separating servers When?
  7. 7. # parameters.yml parameters: database_host: localhost … # parameters.yml parameters: database_host: db.pixers … SCALABILITY PATH 1. Separating servers How? Ask your *ops to set-up new db server1 Change database host in configuration2
  8. 8. App1App1 AppN… Load Balancers Distribute requests to backend servers, e.g. HAProxy, Varnish Application servers Each has the same application (clones) SCALABILITY PATH 2. Adding application servers lb1 lb2 DNS DNS Server Distributes requests to Load Balancers
  9. 9. DNS Load Balancing1 Load Balancing software e.g. HAProxy, Varnish, nginx 2 $ dig a microsoft.com ... ;; ANSWER SECTION: microsoft.com. 924 IN A 104.40.211.35 microsoft.com. 924 IN A 104.43.195.251 microsoft.com. 924 IN A 191.239.213.197 microsoft.com. 924 IN A 23.96.52.53 microsoft.com. 924 IN A 23.100.122.175 SCALABILITY PATH 2. Adding application servers How?
  10. 10. Session handling Losing users’ session? Sticky sessions? 3 Saving files Using distributed filesystem (Amazon S3, CEPH or just NFS) 4 $ composer require knplabs/knp-gaufrette-bundle ~0.3 $ composer require oneup/flysystem-bundle @stable $ composer require snc/redis-bundle 2.x-dev SymfonyComponentHttpFoundationSessionStorage HandlerMemcachedSessionHandler SCALABILITY PATH 2. Adding application servers How?
  11. 11. db2 master db1 master Master-Master replication Writes to db1 or db2 Reads from db1 or db2 + High-availability + Better performance in writes and reads - Generating IDs (auto_increment_offset) - Failover mechanism? Master-Slave replication Writes to db1 Reads from db1 or db2 + High-availability + Better performance in reads + Easier than master/master - Failover mechanism? SCALABILITY PATH 3. Scaling database - Replication db2 slave db1 master
  12. 12. Multiple databases Data partitioned by type + More space for data + Better performance in reads - Not transparent for application (99% cases) - Beware of JOINs (app-side) SCALABILITY PATH 3. Scaling database - Sharding db products db orders App
  13. 13. SCALABILITY PATH 3. Scaling database – Sharding in SaaS db tenant2 db tenant1 App Multiple databases Data partitioned by tenants db core
  14. 14. SCALABILITY PATH 3. Scaling database How? Sharding + Dynamic connections (SaaS/Multitenant) + Multiple entity managers 1 Replication - Doctrine2 # app/config/config.yml doctrine: dbal: connections: default: slaves: slave1: # ... slave2:
  15. 15. SCALABILITY PATH Final architecture?
  16. 16. SCALABILITY PATH 4. Going SOA Core Application PrintAPI PhotoAPI
  17. 17. SCALABILITY PATH 4. Going SOA When? Pros: + New business opportunities + Better scalability as services are stateless + Exposing API by SOAP or REST + Easier development (dev-team per service) + Technology independent (Symfony app can use Node.js service) Cons: - Platform complexity – harded to maintain - Communication overhead - Security? 1 2
  18. 18. SCALABILITY PATH 4. Going SOA How? Service-side (e.g. Search application)1 Client-side (e.g. Core application)2 $ composer require guzzlehttp/guzzle $ composer require eightpoints/guzzle-bundle (we don’t use it) $ composer require friendsofsymfony/rest-bundle (we don’t use it in every project) $ composer require jms/serializer-bundle $ composer require nelmio/api-doc-bundle
  19. 19. Contact me at: antoniorfin@gmail.com linkedin.com/in/antoniorfin twitter.com/antoniorfin www.pixersize.com Thank you! Questions & Answers

×