CODEWITHSUNDEEP
phpamazon-web-servicesautoscaling
alxndr_k
alxndr_k

Reputation: 79

Transfer multidomain PHP application to AWS Autoscaling

We have a bunch of websites (>15) running on the same codebase. Currently our strategy is to run every website on a separate Lightsail/EC2 instance. Website behavior depends on .env file but it is possible to change this dependency to hostname. We have a lot of git changes every day. We keep instances state in sync via Deployer (Gitlab CI/CD). Due to our strategy (one website - one VPS) it is costly to scale such infrastructure.

There is a single master instance for admin & content editing purposes with write access to RDS database. Other instances are used for website domains and they have read access to RDS DB I mentioned before. We also have S3 for product gallery.

It seems it would be pretty standard to migrate such infrastructure to AWS ASG but there are some bottlenecks:

How could we move this infrastructure to AWS ASG/ALB to reduce costs?

I've checked https://devops.stackexchange.com/questions/2098/where-to-start-scaling-php-applications-on-aws answer but I couldn't figure out how to handle mentioned bottlenecks above.

Upvotes: 0

Views: 51

Answers (1)

symcbean
symcbean

Reputation: 48367

You don't start addressing a problem by choosing a solution. As you're already finding out, your current architecture won't work with auto-scaling.

Currently our strategy is to run every website on a separate Lightsail/EC2 instance

Your currently architecture has ZERO fault tolerance.

If what you are asking is how to build a scalable architecture, then this is the issue you need to address. And doing away a 1:1 relationship between site and server means that you can easily take a node offline to apply updates.

every website has local MySQL DB

You need to decouple the DBMS and redis too. I assume that you are using Redis for session storage. If you already have a central DBMS then use that - but expand to a minum of 2 nodes. I'd suggest master-master replication initially, but its good practice to treat this as a primary + backup rather than a true DBMS cluster. OTOH you can designate one node as the primary for SOME sites and the other as primary for the remainder.

Upvotes: 1

Related Questions