How Flutter UKI optimizes knowledge pipelines with AWS Managed Workflows for Apache Airflow


This publish is co-written with Monica Cujerean and Ionut Hedesiu from Flutter UKI.

On this publish, we share how Flutter UKI transitioned from a monolithic Amazon Elastic Compute Cloud (Amazon EC2)-based Airflow setup to a scalable and optimized Amazon Managed Workflows for Apache Airflow (Amazon MWAA) structure utilizing options like Kubernetes Pod Operator, steady integration and supply (CI/CD) integration, and efficiency optimization methods.

About Flutter UKI

As a division of Flutter Leisure, Flutter UKI stands on the forefront of the sports activities betting and gaming business. Flutter UKI presents a various portfolio of leisure choices, encompassing sports activities wagering, on line casino video games, bingo, and poker experiences. Flutter UKI’s digital presence is strong, working by an array of famend on-line manufacturers. These embrace the enduring Paddy Energy, Sky Betting and Gaming, and Tombola. Whereas Flutter UKI has established a powerful on-line foothold, it maintains a major bodily presence with a community of 576 Paddy Energy betting outlets strategically positioned throughout the UK and Eire.

The Knowledge crew at Flutter UKI is integral to the corporate’s mission of utilizing knowledge to drive enterprise success and innovation. Specializing in knowledge, their groups are devoted to making sure the seamless integration, administration, and accessibility of information throughout a number of sides of the group. By growing sturdy knowledge pipelines and sustaining excessive knowledge high quality requirements, Flutter UKI empowers stakeholders with dependable insights, optimizes operational efficiencies, and enhances the person expertise. Its dedication to knowledge excellence underpins its efforts to stay on the forefront of the web gaming and leisure business, delivering worth and strategic benefit to the enterprise.

The journey from self managing Airflow on Amazon EC2 to working Airflow workloads at scale utilizing Amazon MWAA

Flutter UKI’s knowledge orchestration story started in 2017 with a modest Apache Airflow deployment on EC2 situations. As the corporate’s digital footprint expanded, so did their knowledge pipeline necessities, resulting in an more and more advanced monolithic cluster that demanded fixed consideration and useful resource scaling. The operational overhead of managing these EC2 situations grew to become a major problem for his or her engineering groups. In 2022, Flutter UKI reached a crossroads. They wanted to decide on between re-architecting their service on Amazon Elastic Kubernetes Service (Amazon EKS) or embracing Amazon Managed Workflows for Apache Airflow (MWAA).

Flutter UKI was trying to rework their knowledge orchestration service from a resource-intensive, self-managed system to a extra environment friendly, managed service that will enable them to deal with their core enterprise aims quite than infrastructure administration. By in depth proof-of-concept (POC) testing and shut collaboration with AWS Enterprise Help, Flutter UKI gained confidence within the potential of Amazon MWAA to deal with their subtle workloads at scale. Their selection of MWAA over a self-managed resolution on Amazon EKS mirrored Flutter UKI’s strategic deal with utilizing managed companies to scale back operational complexity and speed up innovation.

The migration to Amazon MWAA adopted a methodical method. There was in depth testing of a number of POCs. In the course of the POCs, the engineering crew discovered MWAA to have a great ease of use, which helped them cut back the training curve leading to quicker. Studying from every POC, they iterated on the ultimate structure by making data-driven choices. Beginning with a small subset of directed acyclic graphs (DAG), the Flutter UKI crew expanded their deployment over time, step by step transferring tons of and ultimately 1000’s of workflows to the managed service. This cautious, phased transition allowed them to validate the efficiency and reliability of MWAA whereas minimizing operational threat.

Excessive-level structure design

In the course of the service re-architecture, the information crew strategically managed over 3,500 dynamically generated DAGs by implementing a classy distribution method throughout a number of Amazon MWAA environments to create a workload remoted surroundings. Another excuse for having a number of environments was to ensure that nobody MWAA surroundings doesn’t get overloaded by a number of DAGs. By putting DAG information throughout numerous Amazon Easy Storage Service (Amazon S3) places and configuring distinctive DAG_FOLDER paths for every surroundings, the information crew created an clever load balancing mechanism that allocates workflows primarily based on advanced standards together with surroundings sort, process quantity, and environment-specific DAG affinity. A round-robin distribution technique was designed to attenuate single surroundings load, making certain scalable infrastructure with zero efficiency degradation. This method allowed the crew to optimize workflow orchestration, sustaining excessive efficiency whereas effectively managing an intensive assortment of dynamically generated DAGs throughout a number of MWAA environments. To supply extra compute to particular person duties and to maintain the MWAA environment friendly, Flutter UKI delegated the DAG execution to an exterior compute surroundings utilizing Amazon Elastic Kubernetes Service (Amazon EKS). The ensuing high-level structure is proven within the following determine.

  1. Kubernetes Pod Operator (KPO) for duties: Flutter UKI transitioned from utilizing customized operators and lots of native Airflow operators to solely using the Kubernetes Pod Operator (KPO). This choice simplified their structure by eliminating pointless complexity, lowering upkeep overhead, and mitigating potential bugs. Moreover, this method enabled them to allocate compute sources on a per-task foundation, optimizing general service efficiency. It additionally enabled the usage of completely different container pictures for various duties, thereby avoiding library dependency conflicts.
  2. Kubernetes Pod Operator wrapper (KPOw): As a substitute of utilizing KPO straight, they developed a wrapper (KPOw) round it. This wrapper abstracts the underlying complexity and minimizes the affect of signature adjustments in Airflow, Amazon MWAA, Amazon EKS, or operator variations. By centralizing these adjustments, they solely have to replace the wrapper quite than 1000’s of particular person DAGs. The wrapper additionally simplifies DAGs by hiding repetitive parameters, corresponding to node affinity, pod sources, and EKS cluster configurations. Moreover, it enforces company-specific naming conventions and permits for parameter validation at process execution time quite than throughout DagBag refresh. In addition they launched profiles and picture information, the place profile information comprise needed KPO parameters, and the corresponding picture information hyperlink to the repository for the duty’s container picture. This setup ensures consistency throughout duties utilizing the identical profile and facilitates simultaneous updates throughout duties.
  3. Month-to-month picture updates in Kubernetes: Imposing a coverage of month-to-month picture updates made certain that their code remained present, stopping safety vulnerabilities and avoiding in depth code adjustments on account of deprecated libraries.
  4. Steady Airflow updates: Flutter UKI maintains a cutting-edge infrastructure by implementing new Airflow variations shortly after launch, whereas following a rigorously orchestrated deployment technique. Their method makes use of normal Amazon MWAA configurations and employs a scientific testing protocol. New variations are first deployed to growth and take a look at environments for thorough validation earlier than reaching manufacturing techniques. This methodical development considerably reduces the chance of disruptions to business-critical workflows.

To realize operational excellence, Flutter UKI has carried out a complete monitoring framework centered on Amazon CloudWatch metrics. Their monitoring resolution contains strategically configured alarms that present early warning alerts for potential points. This proactive monitoring method permits their groups to rapidly establish and examine anomalies in manufacturing workload executions, making certain excessive availability and efficiency of their knowledge pipelines. The mix of cautious model administration and sturdy monitoring exemplifies Flutter UKI’s dedication to operational excellence of their cloud infrastructure.

  1. CI/CD integration: By managing their code in GitLab, with obligatory code evaluations and utilizing Argo Occasions and Argo Workflows for picture updates in AWS ECR, they streamlined their growth processes.
  2. Efficiency Optimization: A good portion of the DAGs are dynamically generated primarily based on database metadata. This technology course of runs exterior Amazon MWAA, with its personal CI/CD pipeline, and the ensuing DAG information are saved within the S3 DAG. Putting code exterior of duties was prevented, together with parameter analysis. Parameters and secrets and techniques are saved in AWS Secrets and techniques Supervisor and retrieved at process runtime. Engineers goal to attenuate or get rid of inter-service dependencies inside MWAA.

DAGs are scheduled to distribute execution instances as evenly as attainable. Job code and customary modules are hosted on Amazon S3 and retrieved at runtime. For bigger codebases, Amazon Elastic File System (Amazon EFS) volumes are mounted to process pods are used.

Outcomes

At present, Flutter UKI’s infrastructure includes 4 Amazon MWAA clusters, every executing duties on devoted Amazon EKS node teams. They handle roughly 5,500 DAGs encompassing over 30,000 duties, dealing with greater than 60,000 DAG runs day by day with a concurrency exceeding 450 duties operating concurrently throughout clusters. They anticipate a ten% month-to-month enhance on this workload within the quick to medium time period. Throughout main occasions like Cheltenham and Grand Nationwide, the place knowledge load will increase by 30%, their MWAA service has demonstrated stability and scalability, reaching a 100% success price for crucial processes in 2025, a major enchancment over earlier years.

Conclusion

Flutter UKI’s journey with AWS Managed Workflows for Apache Airflow (Amazon MWAA) has resulted in a secure, scalable, and resilient manufacturing surroundings. The cautious re-architecting of Flutter UKI’s service, mixed with strategic choices round process execution and infrastructure administration, has not solely simplified their operations, but in addition enhanced efficiency and reliability. Safety and compliance advantages have been additionally seen, as a result of MWAA gives managed safety updates, built-in encryption, and integration with AWS safety companies. Maybe most significantly, the shift to MWAA has allowed Flutter UKI’s engineering groups to redirect their efforts from infrastructure upkeep to business-critical duties, specializing in DAG growth and enhancing knowledge pipeline effectivity, finally accelerating innovation of their core enterprise operations.

For those who’re trying to cut back operational overhead and migrate to a completely managed Airflow resolution on AWS, think about using Amazon MWAA. Get in contact together with your Technical Account Supervisor or your Options Architect to debate an answer particular to your use-case. You may also attain out to AWS Help by making a case in case you’re dealing with an points organising the service.

Able to see what Amazon MWAA is like? Go to the AWS Administration Console for Amazon MWAA. For extra info, see What Is Amazon Managed Workflows for Apache Airflow. Moreover, Utilizing Amazon MWAA with Amazon EKS reveals you how one can combine Amazon MWAA with Amazon EKS.


Concerning the authors

Monica Cujerean is a Principal Knowledge Engineer at Flutter UKI, specializing in service associated initiatives that cowl efficiency optimization, value effectiveness, and new characteristic adoption on most AWS service in our stack: Amazon MWAA, Amazon Redshift, Amazon Aurora, and Amazon SageMaker.

Ionut Hedesiu is a Senior Knowledge Architect at Flutter UKI, chargeable for designing strategic options to cowl advanced and diversified enterprise wants. His fundamental experience is on Amazon MWAA, Kubernetes, Amazon Sagemaker, and ETL options.

Nidhi Agrawal is a Technical Account Supervisor at AWS and works with giant enterprise prospects to offer the technical steering, greatest practices, and strategic help to prospects, serving to them optimize their environments within the AWS Cloud.

John Kellett is a Senior Buyer Options Supervisor with 25 years of expertise throughout non-public and public sectors. John helps drive end-to-end buyer engagement by program administration excellence. By understanding and representing prospects’ strategic visions, John aligns to develop the folks, organizational readiness, and expertise competencies to fulfill the specified outcomes.

Sidhanth Muralidhar is a Principal Technical Account Supervisor at AWS. He works with giant enterprise prospects who run their workloads on AWS. He’s obsessed with working with prospects and serving to them architect workloads for value, reliability, efficiency, and operational excellence at scale of their cloud journey. He has a eager curiosity in knowledge analytics as effectively.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles