Home > database >  How to separate different parts of laravel application?
How to separate different parts of laravel application?

Time:01-24

I have a huge Laravel application, it contitutes of a dashboard where users have many different complex cruds that are all saved in a database with more than 100 tables, it also have an api for mobile app that can reach a peack of 300 thousand requests per minute. As the app scales I'm having issues with performance, as all is in one single aws hosted ec2 server, by all I mean all app images, company logos etc, all the resources for the dashboard and all the api for mobile app. I need a solution for this problem, should I separate all in different machines? If so, how?

All the app is currently running PHP 7.2 and Laravel 5.5 on a aws ec2 12xlarge instance.

CodePudding user response:

You are asking us some basic concept of scalability in the Cloud.

I will try to give one direction you could follow.

The current design is very bad for couple of reasons:

  1. As you said, it cannot scale because everything hold in one server;
  2. Because everything hold in one server, I hope you have automated backup in case your instance fails
  3. The only thing you can do in this configuration is to scale vertically, instead of horizontally (using more instances instead of a big one)
  4. Files are on the same disk, so you cannot scale

In term of application (Laravel), you are running with a monolith: everything in one app. I don't need to tell you that it doesn't scale well but it can.

Lets dive into to main topic: How to scale this big fat instance?

First of all, you should use a shared space for your images. There are NFS (expensive), S3 (cheap) and shared EBS (cheaper than NFS, but can only be used by a limited number of instances at a time). I would use S3.

We can skip the part where you need to refactor your monolith application to a micro-service architecture, with smaller parts. It can be done if you have time and money, but I would say it is not the priority to your scaling issue.

I don't know if the database is also on the same EBS or not. If it is, use RDS: it is an almost no management managed database. You can have multi-AZ for very high availability, or Multi-AZ DB Cluster (new) which will spread the load for reads into 2 shadow instances.

To go further with your application, you can also run mobile and web on separated instances, to avoid one impacting the other.

And...That's all! Laravel has a transparent configuration mechanism for the storage to easily switch from one to another.

When I say "That's all", I mean in term of way to improve the scaling. You will have to migrate the data from the EC2 database to RDS, perform the transfer of your images from the EBS to S3, create an autoscaling group, create an IAM Instance role for your EC2 Autoscaling group to access S3, know when the application has peaks so you can do a predictive scaling, etc.

I would recommand using IaC for this, like CloudFormation or Terraform.

This is the tip of the iceberg, but I hope you can start building a more robust system with these tips.

  • Related