Overview
The goal of this migration project was to move an advertising delivery system to AWS, primarily involving managing customers within a container cluster. This included the ad engine, algorithm strategies, operations backend, billing platform, ad library, ad delivery platform API access services, and other complete system migrations to the new AWS Singapore region. Elite Cloud assisted Archaeologist in understanding AWS services, designing the cloud architecture, and aiding in project testing, service migration, and deployment optimization. The project was planned to begin in January 2024 and complete the migration work within 2 months, followed by continued support for business stability and incremental growth.
Project Objectives
-
GCP Managed Service Migration: Due to Archaeologist’s deep utilization of GCP managed services, migrating to AWS required assistance from a professional technology service provider to match corresponding AWS services. This work included GCP to AWS service adaptation, migration feasibility research, migration method validation, and more. The differences in vendor products, system architectures, and deployment methods led to a substantial migration and rebuilding workload.
-
Tight Project Migration and Redeployment Timeline: Seeking a service provider with rapid deployment and migration capabilities, Archaeologist aimed to complete the migration and deployment testing within 2 months. Considering Archaeologist’s limited human resources and the potentially lengthy database upgrade testing cycle, the AWS RDS MySQL EOS timeline might have an impact, requiring the partner to provide appropriate solutions.
-
Desire for Professional Guidance when Engaging with AWS: To reduce unnecessary risks and trial-and-error, Archaeologist sought assistance in rapidly completing the architecture design, migration, and deployment of their advertising delivery platform on AWS.
Expected Project Deliverables
Archaeologist will consider the project successful if the following main criteria are met:
| No. | Description Test | Result |
|---|---|---|
| 1 | Successful file and database migration, with data integrity verified | Passed |
| 2 | All customer application services functioning normally | Passed |
| 3 | EKS cluster elastic scaling completed within ≤ 10 minutes | Passed |
| 4 | Singapore latency test: API server connection to third-party ad delivery system with average latency below 150ms | Passed |
| 5 | AWS cloud resource and application-related monitoring metrics email alerting | Passed |
| 6 | Cost control, with clear billing | Passed |
Proposed Architecture Diagram
To meet Archaeologist’s requirements, the overall business system was deployed with the following architecture, focusing on implementing the following aspects:
- AWS Architecture Design Considerations: Operations, security, high availability, performance, cost, and sustainability.
- Landing Zone Planning: Assisted Archaeologist in reasonably partitioning network layers, making it easier to distinguish and manage various business operations. A separate testing availability zone subnet was reserved outside the architecture diagram, isolated from the production environment.
- Recommended that Archaeologist use a configured domain name resolution method, utilizing Ingress in EKS in conjunction with the ALB load balancer to place machines across multiple availability zones, improving business security, increasing scaling limits, and reducing single points of failure.
- Utilized AWS services such as IAM and CloudTrail to assist in managing Archaeologist’s permissions, operation records, account threat detection, and more.
Monitoring and Alerting Design
- Assisted in configuring CloudWatch to monitor and alert on events such as EC2 state changes, Health events, memory usage, CPU utilization, and more.
- Used managed Prometheus to collect monitoring metrics for the EKS cluster, compute resources, and more, integrating with CloudWatch for alerting and triggering SNS email alerts.
Core Business EKS Cluster Design
- Worker Nodes deployed across multiple availability zones to ensure business availability. Considering Archaeologist’s business scenario during app promotion periods with potentially high burst traffic, there were high demands for elastic scaling and shrinking. Designed to use Karpenter as the Kubernetes auto-scaling tool for faster and more flexible fulfillment of Archaeologist’s needs, significantly reducing operational workload.
- Customer’s core business deployed within the EKS cluster.
- Designed the cluster to expose Services via ALB Controller Ingress.
- Single EKS container cluster, with a minimum capacity of 8 nodes and a maximum of 30 nodes to meet peak cluster scaling demands.
- Each EC2 instance initially configured with a GP3 disk, with the ability to scale storage as needed.
- Nodes deployed in Private Subnets, preventing node exposure to the public internet for security and control. Node group security groups only allow access from the EKS cluster and ELBs.
Migration Success Delivery Criteria
- Solution meets requirements.
- Migration documentation is complete and meets requirements.
- Application and data migration fully completed.
- Functionality meets requirements after migration.
- Completion of agreed-upon migration design and implementation scope, with stable business operation for 15 working days after cutover.