Skip to content

How to: Build a Disaster Recovery strategy for a Banking app using AWS Multi-Region architecture

Notifications You must be signed in to change notification settings

djtoler/Deploying-a-Python-App-on-MultiRegion-AWS-Infrastructure-

Repository files navigation

Purpose

The goal of Deployment 6 was to enhance the reliability of our banking application infrastructure. By doing this, we increase the confidence of our users, ensuring they have consistent and uninterrupted access to our services. This growth in user confidence will cause an increase in user loyalty which directly translates into more transactions & revenue.

Our last deployment, 5.1, decoupled our application from our Jenkins server. This partially addressed the single point of failure issue and using Jenkins agents made our system architecture more distributed. However, our infrastructure was still allocated in a single region, leaving our system vulnerabe to a disaster and possible latency issues. We were also using SQLite, leaving our customers data exposed to anything that has access to our server. Our 2nd application server was also just used as a standby instance incase an availability zone went down.

In Deployment 6, we solved several issues that our last deployment left us with.

  • We added an additional 2 application servers in US-West-2 for a multi-region infrastructure that'll fully address the single point of failure issue (minus configuration), ensuring that our application is prepared to still service customers in the event of a disaster

  • We added a single load balancer in each region to equally distribute ingreess traffic amongst our 2 instances that are in seperate AZs, increasing our banking applications availability to facilitate users transactions.

  • We decoupled our database from our application by moving away from SQLite and using AWS RDS and this came at a cost of an increase in latency sinces we're no longer reading and writing data locally. However, we increased the scalability and flexibility of our database conponent. We also took a step ij the direction of making our users data more secure.

  • We intergrated Terraform into our Jenkins pipeline, deploying our infrastructure via a Jenkins agent, which optimized our applications infrastructure depoyment proceess.


Issues

1. Load balancer return 504 error

Using Load balancer URL directly in browser Using CURL with URL in command line
aaaaaa.png aaaaaa.png

We found that we needed to add a rule to our security group that allows egreess traffic to port 8000, our applicatoions port.

Default Outbound Security Group rules Updated Outbound Security Group rules
aaaaaa.png aaaaaa.png

2. Incompatable dependency versions during application install

This error occured during the installation of our setup process on our application instances. I ran the commands line by line once the application didnt deploy automatically. I noticed that because we were not running these commands inside our Python virtual enviornment, we were experiencing configuration drift. To fix this, I simply switched the order of setup commands and we had a successful application launch.


Steps

1. Download banking application source code from GitHub to local machine

  • Create a GitHub token
# Go to GitHub settings
# Go to "Developer Settings" on the left panel
# Click "Personal Access Tokens"
# Click "Generate New Token" then "Generate Classic Token"
# Select repo, admin:org, admin:repo_hook
# Copy the token and paste it somewhere safe for future use
  • Run this script to create a remote GitHub repository using your token (GitHub Repo Creation Script)
# Have you GitHub token ready & think of a name for your new repo
curl -O https://github.com/djtoler/automated_installation_scripts/blob/main/auto-github_repo_create.sh
chmod +x auto-github_repo_create.sh
./auto-github_repo_create.sh <YourGitHubToken> <NameOfYourRepo>
  • Set the remote GitHub repository in your local repository
git remote add origin http://github.com/<YourUserName>/<NameOfYourRepo>.git
  • Clone the source code from GitHub into our local repo and push into the remote repo
git clone https://github.com/djtoler2/Deployment6.git
cd Deployment6
git add .
git commit -m'pushing source code to remote repo'
git push
  • Create our second branch calld dev1 to build our infrastructure
git checkout -b dev1
git push -u origin dev1

2. Use Terraform to deploy our CICD infrastructure using Jenkins controller/agent architecture

  • Create 3 Terraform files called main.tf variables.tf & terraform.tfvars
  • Using Terraform, configure 2 EC2 instances, 1 for our Jenkins controller server and 1 for our Jenkins agent server
  • Create a userdata script to install the dependencides for each instance
curl -O https://raw.githubusercontent.com/djtoler2/Deployment6/main/ud_jenkins_agent_tf.sh
curl -O https://github.com/djtoler2/Deployment6/blob/main/ud_jenkins_controller.sh
Make sure our userdata scripts are in root directory Use them in main.tf like this
aaaaaa.png aaaaaa.png
  • Deploy the 2 Jenkins instances
    • Run ./tf_deploy.sh
  1. Store AWS credentials as enviornment variables in Jenkins

  1. Set up AWS RDS database

  1. Deploy our multi-region banking application infrastructure from our Jenkins agent using Terraform

  • Configure Terraform files to deploy and launch our application on each instance:
    • 2 VPC's (US-East-1, US-West-2)
    • 2 Route Tables
    • 2 Subnets in each region (US-East-1, US-West-2)
    • 2 Availability Zones in each region (US-East-1, US-West-2)
    • 1 Internet Gateway in each region (US-East-1, US-West-2)
    • 2 EC2 instances in each region (US-East-1, US-West-2)
    • 2 Route Tables
cd terraformInit
git add .
git commit -m"pushing infrastructure"
git push
  1. Configure a load balancer for each region our banking application is deployed in

  • Create a target group for each application instance
  • Create a load balancer
  • Attach each task to the load balancer
  • Check our application at the load balancers URL

System Diagram


Optimization

Security: Move our RDS into a private subnet for better security of our users' data

Security: Move our application servers into a private subnet

Reliability: Configure our infrastructure to failover to our alternate region if 1 region fails

Performance: Add a cache in front of our database

Performance: Add read replicas in the specific availability zones our application instances are in

Availability: Add auto-scaling capabilities to our instances

About

How to: Build a Disaster Recovery strategy for a Banking app using AWS Multi-Region architecture

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published