Moodle on AWS: A Cloud-Native Approach — Part 1
The education sector continues to change dramatically and with e-learning through digital platforms becoming commonplace, education leaders have to rethink ways to deliver quality education in a scalable and cost-effective way. Moodle is a free and open-source Learning Management System (LMS) written in PHP and distributed under the GNU General Public License.
Part 1 of this two-part blog series provides you guidance in deploying Moodle on AWS using containers in a highly-available, scalable, and cost-effective way using higher-order managed services like AWS Fargate, Amazon Elastic File System (EFS), Amazon ElastiCache and Amazon RDS, etc... In part 2, I would be going into details around how to dockerize Moodle for this deployment on Amazon Elastic Container Service (ECS) and would also be providing AWS CloudFormation templates for the deployment.
About Moodle LMS
Moodle enables educators to create their own private website containing dynamic courses that extend learning through multiple platforms like web, mobile apps, etc. A typical Moodle installation comprises the Moodle code executing in a PHP-compatible web server, a relational database (MySQL, PostgreSQL, MariaDB, etc.), and a file store for uploaded and generated files.
The moodledata folder typically located at /var/www/moodledata is where Moodle stores uploaded and generated files, and so needs to be writable by the webserver. Additionally, the code, which typically resides in a folder like /var/www/moodle or ~/htdocs/moodle should not be writeable by the webserver.
Redis cache store is a great option to handle session and application cache as it supports data guarantee, key awareness, and locking. Default Moodle distribution does not come shipped with a Redis PHP driver and needs to be installed to enable communication with a Redis Server.
A Cloud-Native architecture for Moodle
Moodle has several requirements that need to be addressed when deployed as a highly available and scalable solution. I plan to show you how a mix of higher-order managed AWS services can help address these requirements. The following architecture diagram depicts a container-based deployment of Moodle on AWS Fargate. Let's look at the components in detail.
AWS Fargate for Compute
Amazon ECS on AWS Fargate is an excellent option that can be used to run Docker containers without having to manage servers or clusters of Amazon EC2 instances. Because Amazon ECS is a regionally distributed container orchestrator fully managed by AWS, you get resiliency and scale out of the box.
To run Moodle tasks and services with the Fargate launch type, the Moodle application needs to be packaged in containers. Further, we specify the CPU and memory requirements, networking, and IAM policies and launch the application. To distribute the incoming HTTP/HTTPS (or layer 7) traffic to different tasks running in the service, an Application Load Balancer can be used.
Elastic File System for moodledata
In a Highly Available deployment of Moodle, all servers need to access the shared file storage moodledata. Amazon EFS is a fully managed shared elastic file system designed to be consumed by other AWS services such as ECS. Amazon EFS scales transparently replicates your data and makes it available across Availability Zones and supports multiple storage tiers to meet the demands of the majority of workloads. Native integration between Amazon ECS and Amazon EFS was recently introduced and this integration has been enabled for Fargate via platform version 1.4.
When you create an EFS file system, it gets created on an infrastructure that spans several Availability Zones (at least 3) for durability. This file system can be concurrently mounted and accessed from all the Availability Zones in the Region through EFS mount targets.
Session Management using ElastiCache
Moodle needs to store user session data to maintain the application state as they work, this means users can be connected to any of your servers without losing their progress. When planning an ElastiCache implementation, planning for failures is very important so that there is a minimal impact upon the running compute environments.
To make our Moodle application fault-tolerant, I rely on Redis Replication Groups (RG). A Redis RG is comprised of a single primary node to where our Moodle compute environments can both read and write to and up to 5 read-only replica nodes. Whenever data is written to the primary node, it is also asynchronously replicated to the read replica nodes. To mitigate the impact of an Availability Zone (AZ) failure, I place the nodes in multiple AZs.
Amazon RDS MySQL as Moodle database
The Moodle database typically has around 200 tables. Moodle’s database is typically MySQL or Postgres, but can also be Microsoft SQL Server or Oracle. MySQL is the world’s most popular open-source relational database and is chosen for this reference architecture. Amazon RDS is used for deploying scalable MySQL servers.
Amazon RDS provides high availability and failover support for DB instances using multi-AZ deployments. In our multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different AZ. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups. In the event of a planned or unplanned outage of your DB instance, Amazon RDS automatically switches to a standby replica in another Availability Zone if you have enabled multi-AZ.
Amazon ECR as a docker repository
For organizations that wish to have a fully-managed private Docker container registry, Amazon Elastic Container Registry (ECR) is a very compelling option. Since ECR is integrated with ECS, the development of production workflow is simplified significantly.
AWS Secrets Manager for storing credentials
The Moodle compute environment running on AWS Fargate needs to connect to Amazon RDS as well as Amazon ElastiCache. AWS secrets manager is a good fit for storing database and Redis credentials and transparently injecting into the containers running on ECS.
Auto Scaling
To maintain cost efficiency we want to build a service that runs on low spec servers, the system will deploy additional servers to handle the load when needed but at other times, such as school holidays, it will scale back to the minimum needed to keep the system working.
Automatic scaling is the ability to increase or decrease the desired count of tasks in your Amazon ECS service automatically. Amazon ECS leverages the Application Auto Scaling service to provide this functionality.
Conclusion
Part 1 of this two-part blog series provides architectural guidance on hosting Moodle in a Cloud-Native way. In part 2, I would be going into details around how to dockerize Moodle for deployment on ECS and would also be providing CloudFormation templates for the deployment.
Let me know if you have questions. Happy to provide more details in part 2 of this blog.
