OpenX uses AmpereOne-powered C3A instances on Google Cloud to drive sustainability and performance at scale

Snapshot

Organization: OpenX is the world’s leading independent supply-side platform for audience, data, and identity targeting.

Challenge: OpenX must ensure consistent, effective delivery of real-time dynamic services at the scale of hundreds of billions of ad requests per day, requiring substantial compute resources, while also maintaining their Net Zero and CarbonNeutral® certification and status.

Solution: OpenX migrated a portion of their cloud compute to leverage AmpereOne-powered C3A instances available via Google Cloud Platform.

Results: OpenX achieved performance parity out of the box with Ampere instances, when compared with x86 instances, as well as some of the faster chips from several established industry leaders.

Case Study

OpenX uses AmpereOne®-powered C3A instances on Google Cloud to drive sustainability and performance at scale.

OpenX is a programmatic advertising platform that helps digital publishers monetize their properties through dynamic advertising that is bought and sold in real time and helps advertisers effectively target their audiences through data-driven curation. Ampere® spoke with Mark Chodos and Kenneth Kharma from OpenX to get a deeper understanding of how cloud compute from Google Cloud C3A instances built on AmpereOne help their platform team achieve positive outcomes across both sustainability and performance.

100% Cloud Based, CarbonNeutral Certified, Net-Zero Verified

OpenX is an independent omni-channel supply-side platform (SSP) and a global leader in supply-side curation, transparency, and sustainability. Through its 100% cloud-based tech stack, OpenX powers advertising across CTV, app, mobile web, and desktop, enabling publishers to deliver marketers with improved performance and dynamic future-proofed solutions. With a 17-year track record of programmatic innovation, OpenX is a direct and trusted partner of the world’s largest publishers, working with more than 130,000 premium publisher domains and over 100,000 advertisers. As the market leader in sustainability, OpenX was the first adtech company to be certified as CarbonNeutral® and third-party verified for achieving its SBTi Net-Zero targets.

OpenX is the only 100% cloud-based SSP boasting the most efficient tech stack in the industry. Since shifting to wholly operate on the Google Cloud Platform (GCP), the product and platform teams have effectively improved performance, scalability, speed, and global reach. This includes outcomes such as coverage across global regions and markets; significantly reduced time to market for new products and features with full CI/CD pipelines and automated infrastructure; and drove some cost reduction and the ability to build advanced AI capabilities powered by Google Cloud AI (Cloud TPU, Kubeflow, AutoML).

Sustainable performance across billions of transactions

Ampere connected with Mark Chodos, Staff Site Reliability Engineer, and Kenneth Kharma, Distinguished Engineer for Privacy and Sustainability from the OpenX platform team, which owns validating new products and features that are delivered via GCP. Part of the team’s charter encompasses a focus on sustainability initiatives within OpenX, which includes constant optimization of their usage of GCP and finding cost-effective ways to reduce or offset carbon emissions generated by compute intensive resources. According to Mark, “Google provides a lot of good data on the emissions impact we have within our platform,” which then equips OpenX with some of the insights they need to effectively allocate and scale compute resources.

As an SSP, OpenX facilitates a fair value exchange between advertisers, and publisher-owned websites, domains, apps, brokering the placement of ads on publishers’ digital real estate. These channels send requests through OpenX, which, in real time finds advertisers or potential buyers for those ad spots, while also returning the best bid back along with the ad creative associated with it, which then gets displayed on available publisher properties. Because of the volume of requests and the timing required to meet the demands of this exchange between ad pricing, availability, and serving, some of the most constant, business-critical optimizations for OpenX are around scale and latency.

There’s a considerable amount of backend infrastructure and technology that enables a host of capabilities to run seamlessly, and in parallel. According to OpenX, this includes components like their user interface, a management API, and ad delivery and data systems. Their delivery and data systems are the highest throughput and the largest consumers of their GCP resources. The delivery systems are notably compute heavy because “We’re running transactions on hundreds of billions of ad requests per day – and again, we need to do that with low latency, within milliseconds,” Chodos shared.

On the data side, “we are handling petabytes of data per day, which we need to process, aggregate, and then deliver reports on in a timely fashion.” To quickly generate and render that data in usable outputs like internal dashboards and customer-facing reports, OpenX shifted away from using microservices, in favor of the Google Kubernetes Engine (GKE) and Google’s BigQuery service, which aligns with their fully deployed in Google Cloud strategy. It also enables OpenX to maximize its use of regional data centers to fulfill requests as close as possible to the source.

Seamless access to Ampere’s industry-leading compute performance

OpenX has been 100% cloud-based since 2019 and was the first SSP to shift fully to the cloud. Mark Chodos was introduced to the Ampere team in 2023 at Google Cloud Next, and the two companies connected over the mutual opportunity to deliver powerful, sustainable cloud compute and services at scale. With AmpereOne powering GCP’s C3A instances, OpenX’s integration of Ampere into their compute optimization initiative was seamless, with performance proving to be on par or better than other cloud-based instance providers.

When OpenX enacted its cloud migration in 2019, the platform team that their applications were containerized and run in Kubernetes, which helped once Chodos started exploring the use of Ampere and Arm-based architecture for three applications. The apps each used different programming languages, part of the core OpenX ad delivery system. The first application is the OpenX front end application, referred to as “Frontier”, written in Golang – it directly receives requests from the load balancer and kickstarts each ad transaction.

The second application, referred to as “Broker”, is a Java application that acts as the hub of the OpenX ad delivery system, receiving the ad requests, processing them through other backend services, and out to a third application – their server-side real-time bidding service (SSRTB), written in Erlang. That service intakes ad requests, sends them out to demand side platforms (DSPs) at upwards of a trillion or more requests per day, receives return responses, and routes them back through the other applications. For OpenX, it’s business critical that all requests processed as quickly as possible, with minimal latency and high throughput.

All three applications and the numerous tasks they perform, including sending and receiving requests and real-time data processing and streaming, are compute-intensive and run effortlessly on Ampere’s C3A instances. Due to Ampere’s single-threaded core design, C3A instances offer much more reliable latency under load and provide considerable benefits compared to other instance types.

When it comes to measuring latency, the OpenX platform team is constantly evaluating the timing metrics of various operations that their applications perform. When the team introduced Ampere into their infrastructure, they were able to pull up internal dashboards and do side-by-side comparisons of latency on Ampere compared to other processors that they’re also using via GCP. According to Chodos, “Frontier and SSRTB applications pretty much achieved parity out of the box-without any specific tuning needed compared to faster Intel and AMD chips that we were using in GCP.” He acknowledged that with the second of the three OpenX applications, the team faced some challenges across all platforms. “We got reengaged with the Ampere team, and we also engaged some internal engineering teams to take a deep dive into this application.” With some suggestions and work between the teams, OpenX was able to narrow it down to some issues around garbage collection. Through changing settings on things like resource allocations, making sure that there was sufficient memory and CPU allocation to that application, as well as tweaking some of the JVM settings, the team was able to achieve performance parity with x86 instances.

Chodos also noted that “we run a substantial amount on spot instances of GCP as another cost-saving measure, because there’s significant savings over the on-demand instances, so there’s a kind of built-in cycling of the application because of that.” Chodos shared, “we do core pinning on some parts of our applications (where context switching across cores is a performance constraint), and GCP did add features that allowed us to enable core pinning for some threads, and that made a huge difference with some parts of our SSRTB application, which was particularly sensitive to context switching.”

The OpenX approach to application lifecycle management and multi-architecture containers

The platform team uses Google’s Cloud Build CI/CD platform for its continuous integration. When it came to adding another architecture to their existing GKE deployment, OpenX experienced some challenges with executing their initial goal of trying to build multi-architecture containers for each application using “docker buildx” to simplify deployment. Chodos shared, “When we tried to build these multi-arch containers, things slowed down to a crawl in some cases. There were some cross compilation issues, some running and queueing without hardware acceleration. I know that we were able to get the multi-arch container builds to work within a reasonable timeframe for our Java application. But there were also some issues with the libraries of the different architectures and getting all that to line up with our Golang and Erlang applications.”

Evaluating sustainability and emissions objectives

OpenX was recertified and reverified CarbonNeutral® and Net-Zero in 2023. The process to get there started several years prior with an evaluation of the emissions from their five global data centers at the time, which included their own infrastructure and servers. The team brought in climate consultants and worked with reputable, well-respected entities to help with doing everything by the book, across their journey to carbon neutrality and zero emissions. According to Chodos, “That allowed us to achieve carbon neutral certification. We also established Net-Zero goals, which shortly after getting those approved by the Science Based Targets initiative (SBTi), we announced that we could achieve those goals all through the migration to GCP.”

Kharma added, “We’re continuously looking at ways within GCP to help reduce our emissions even further, because we do end up having to offset certain things in terms of emissions. Ideally, we would want to minimize the amount that we need to offset, so we look at things like operating in GCP regions that are more climate friendly.” He also noted that the power efficiency of Ampere processors was one of the factors in OpenX choosing to deploy these applications to C3A instances. They also leverage the ability to leverage clean energy powered data centers where possible. “The power usage of the compute instances we’re using is our biggest source of emissions, so anything we can do to optimize the performance of our platform, including making our apps more efficient to reduce the compute usage or using more energy efficient CPUs, allows us to operate more efficiently and reduce emissions. A lot of these things have the dual benefit of helping us drive down costs, as well.”

What’s ahead for OpenX using Ampere-powered processors

The OpenX platform team leadership is exploring running other services on Ampere. For now, the three applications they’ve been running on C3A instances for the past six months are running in three GCP regions – a cluster in the US, one in Europe, and one in Asia. According to Chodos, “Once the Google team can share when there will be more regions, we’re ready and willing to consume more Ampere compute.”

Getting started with AmpereOne-powered C3A instances

Contact the Ampere sales team to learn how to get access to C3A instances. Contact Sales

Learn more about Ampere’s C3A instances currently in private preview on GCP, here. Google Blog

Sign up for our developer newsletter to receive updates on Ampere-powered C3A instances, and stay informed on developer topics and events. Newsletter

Learn more about OpenX: OpenX

About Ampere

Built for sustainable cloud computing, Ampere Computing’s Cloud Native Processors feature a single-threaded, multiple core design that’s scalable, powerful, and efficient.

Learn more:

Disclaimer: All data and information contained in or disclosed by this document are for informational purposes only and are subject to change.

To find more information about optimizing your code on Ampere CPUs, checkout our tuning guides in the Ampere Developer Center. You can also get updates and links to more great content like this by signing up to our monthly developer newsletter.

If you have questions or comments about this case study, there is an entire community of Ampere users and fans ready to answer at the Ampere Developer community. And be sure to subscribe to our YouTube channel for more developer-focused content.