Amadeus Cloud Migration on Ampere Altra Instances

(This article was originally published by Ampere Computing)

You may not be familiar with Amadeus because it is a B2B company…but when you search for flights or hotels on the internet, there is a good chance you are using Amadeus-supported services behind the scenes, says Didier Spezia, cloud architect at Amadeus. .

Amadeus is a world-leading travel IT company that supports many participants in the tourism industry: airlines, hotel chains, travel agencies, airports, etc. One of Amadeus's businesses is to provide flight search and pricing services to travel agencies and companies such as Kayak or Expedia. Amadeus also supports more advanced features such as budget-based queries and calendar-constrained queries that require pre-calculation of multidimensional indexes. Searching for the right flight with available seats among a wide range of airlines is very difficult.

Getting the best solution is considered an NP puzzle, so to provide the best-effort answer, Amadeus uses a combination of brute force methods, graph algorithms and heuristics. It requires large distributed systems and consumes a lot of CPU, and now runs on thousands of machines on Amadeus’ internal facilities. To meet customer needs, Amadeus operates multiple on-premises facilities around the world and runs workloads on multiple cloud service providers.

Project

A few years ago, Amadeus launched a large, multi-year project to migrate most of its internal resources to Azure. For this specific use case, Amadeus worked with Microsoft to verify the Ampere ARM-based virtual machine (VM).

Microsoft's Mo Farhat commented in the discussion:

From our standpoint…[Microsoft] wants to offer our customers choices. We won't boot [they] between one architecture and another... or between one CPU and another. We want to provide a range of options and provide credible advice...

Initially, Amadeus was not necessarily interested in introducing different architectures as part of the transition. Spezia said:

We only introduce different architectures because we expect some benefits…We are very concerned about the performance/price ratio we can get from Ampere…We want to be able to mix machines with traditional x86 CPUs with machines with Ampere CPUs , and run the workload on the CPU that best suits that workload.

They chose a large, distributed, compute-intensive C application as the first to run on Ampere, because they believe this will provide the greatest comparative advantage over x86.

We think ARM-based machines may be a good choice, but of course, we need to verify and confirm our assumptions. We first ran a number of synthetic benchmarks. ...The results are positive, but the synthetic benchmarks are not very relevant. Since introducing new CPU architectures into the ecosystem is not neutral, we need better guarantees and decide to use real application code for benchmarking. …The application is a large C code base. It relies on many underlying open source libraries, plus some Amadeus middleware libraries, and finally the functional code itself. A subset of this code has been isolated for running benchmarks on the testbench.

One of the factors that made the project successful was the Amadeus team's ability to obtain Ampere servers early in the project. Didier said:

First of all, Amadeus has installed several machines with Ampere Altra CPUs internally. They are used for the initial transplant work and are still running our CI/CD to this day. Since we are in the process of moving to the public cloud and are highly mixed with complex ecosystems, we are very grateful to be able to deploy some machines on-premises that have the same CPU architecture as the VMs offered in Azure. We found that using machines running the target architecture for CI/CD and testing instead of cross-compiling is invaluable.

The CI of the application continues to run on the Ampere server in Amadeus Labs.

Challenge

Our code porting began by recompiling everything with an Arm64-compatible toolchain (Aarch64 target), which had an impact on our CI/CD.

The process of porting this code to Ampere was very smooth, although some problems were found. Some platform-specific compiler behaviors, such as whether the "char" data type is signed or unsigned, differ on x86 and Arm64, and the application makes assumptions about the behavior.

To compile their large C code base, Amadeus uses both GCC and Clang C compilers. Among the changes required as part of the porting, some open source dependencies need to be upgraded to take advantage of improved Arm64 support. Some of these upgrades involve API or behavior changes that require further code changes. Additionally, as part of the migration, some potential code issues that did not show itself on x86 (related to undefined or platform-defined behavior) were exposed and fixed.

Deployment

In the cloud, Amadeus applications are deployed on OpenShift clusters (Red Hat Kubernetes-based container platform). To run in a production environment, the application requires a complete middleware ecosystem (enterprise service bus, logging and monitoring facilities, etc.), which is also hosted in OpenShift.

Amadeus does not want to migrate its entire application infrastructure to Arm64. Another trusted partner, Red Hat, has delivered Kubernetes functionality that supports heterogeneous hardware architectures to OpenShift as supported features.

Specifically, this means that a single OpenShift cluster can contain x86 and ARM compute nodes. By defining node sets with x86 and Arm64 nodes and deploying containers with tags and "blues", developers can easily decide which VM type to schedule pods. Therefore, the support components of the Amadeus application infrastructure can run on a traditional x86 VM, and Amadeus decides that the application pods running on Arm64 for cost and performance reasons can run on Azure Dps v5 VM powered by Ampere Altra CPU .

Heterogeneous clustering is critical to support incremental migration and avoid doubling the number of OpenShift clusters.

Result

Obviously, before entering production, Amadeus hopes to verify their hypotheses with some benchmarks. Using cpubench1a synthesis benchmark, using VMs of 32 vCPUs, a single Ampere Altra VM (D32ps_v5) provides 20% higher raw throughput, performance/price ratio is 50% higher than equivalent Intel VMs, and raw throughput is 20% higher than equivalent AMD VMs 13% higher, and 27% higher performance/price throughput.

When benchmarking is done using real shopping application benchmarking, there is a trade-off between throughput and response time. The higher the throughput, the greater the impact of response time. The performance/price ratio of Ampere Altra VM is 47% higher, with an average response time down 11% lower than the Intel VM, a 37% higher performance/price ratio of AMD VM, and a 9% lower average response time down.

Amadeus has now ported enough application components to run real applications (not just benchmarks). The company is currently completing integration testing and verifying the final part of the platform. Once done, Amadeus will start scaling production environments across multiple Azure regions.

Ampere's first cloud-native processor is built for sustainable cloud computing, delivering predictable high performance, platform scalability and power efficiency that the industry has never seen before. We invite you to learn more about our developers’ work, find best practices, insights, and join the conversation: developer.amperecomputing.com and community.amperecomputing.com.

Contact our expert sales team for partnerships or for more information or get trial access to Ampere Systems through our Developer Access Program.

The above is the detailed content of Amadeus Cloud Migration on Ampere Altra Instances. For more information, please follow other related articles on the PHP Chinese website!