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.
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. 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
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. 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. 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?
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. 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. SCALABILITY PATH
3. Scaling database – Sharding in SaaS
db
tenant2
db
tenant1
App
Multiple databases
Data partitioned by tenants
db core
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. 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