Uber社は2023年2月、オンプレミスのデータセンターからOracle Cloud Infrastructure （OCI）とGoogle Cloud Platformへの戦略的移行に着手した。この移行の重要な要素はコスト削減、価格性能の向上、サプライチェーンの不確実性に対するハードウェアの柔軟性を確保するために、主にx86で構成されていた既存コンピューター群にARMベースのコンピューターを統合することだった。
x86アーキテクチャとARMアーキテクチャはプロセッサ設計における根本的に異なる哲学を表しており、その違いは数十年にわたってコンピューティングの状況を形成してきた。x86（インテルとAMDが開発）が後方互換性と複雑な命令をマイクロコードで実行することを重視する複合命令セットコンピューティング (CISC)アプローチを採用しているのに対し、ARMはより単純で固定長の命令を1サイクルで実行する縮小命令セットコンピューティング (RISC)の原則を採用している。
このアーキテクチャの違いは実用面にも現れる：x86プロセッサは通常、計算集約型タスクにおいてより高いピーク性能を発揮するが消費電力も大きいため、電源が容易に利用できるデスクトップやサーバーで主に使用されている；一方、ARMプロセッサはエネルギー効率に優れ、ワット当たりの性能比が高いため、モバイルデバイス、組み込みシステム、そして最近では省電力を重視するデータセンターでも選択されるアーキテクチャとなっている。
マルチアーキテクチャの統合は新しいハードウェアを導入するだけではない。Uber社のインフラチームにとってそれは長年x86ベースだけだった基本システムを見直すことを意味した。この移行により、アーキテクチャの前提がテクノロジースタックの各レイヤーにいかに深く浸透しているかが明らかになった。
この移行の基礎となったのは、Oracle Cloud InfrastructureがAmpere ComputingのARMプロセッサを戦略的に採用したことだった。これらのチップは驚くべきエネルギー効率を実現する － ARMがモバイル分野で完成させたこの特長は、今やデータセンター環境にまで拡大されている。クラウドプロバイダーにとってこれは大幅な省電力と計算密度の向上につながり、エネルギーコストと物理的な設置面積の両方を削減する。
Uber社にとってこれらの利点は持続可能性の目標と完全に一致する。ゼロエミッションを目指す同社にとって、エネルギー効率の高いコンピューティングインフラを採用することは、環境への影響を削減すると同時にコスト構造を改善するための重要なステップとなる。
移行はホストレベルの準備から始まった－オペレーティングシステム、カーネル、および重要なインフラストラクチャコンポーネントを含むARM互換イメージを作成する。ホストが起動できるようになると、チームは複雑な依存関係が明らかになったビルドパイプラインに取り組んだ。Uber社のコンテナシステムはx86用に最適化されたMakisuというツールに依存していたが、これはARMのクロスコンパイルができなかった。
/filters:no_upscale()/news/2025/02/uber-arm-cloud/en/resources/1distributedbuildpipeline-17394210469874-1740141998746.jpg)
コンテナイメージのビルドパイプライン
チームは5,000以上のサービスのビルドプロセスを書き直すのではなく、巧妙なブートストラップアプローチを採用した。Google Bazelを活用してARM版Makisuをビルドし、それを使って他のサービスをネイティブにビルドできるようにしたのだ。この一見簡単そうに見える作業によって循環的な依存関係が明らかになった：MakisuはBuildkite上で動作し、BuildkiteはUberのOdinプラットフォーム上で動作し、ホストエージェントに依存していた － そのすべてがMakisuでビルドされていたのである。
この循環依存関係を解消するにはBazelのマルチアーキテクチャ機能を利用して各レイヤーを計画的に再構築する必要があった。チームはホストエージェントから始め、次にOdinのコンポーネントを再構築し、続いてBuildkite、最後にMakisuを再構築した。この基盤により、統一されたマルチアーキテクチャのコンテナイメージを生成できる分散ビルドパイプラインが実現した。
このアプローチはビルドコストを倍増させたが（毎週40万以上のコンテナビルドを実施）、それでも経済的にはARMの採用に有利だった。分散ビルドシステムは重要な利点も提供した：オールオアナッシングのアプローチではなく、段階的で制御された移行を可能にした。
デプロイシステムにも同様の機能強化が必要だった。Uber社はアーキテクチャ固有の配置制約と、互換性の問題が発生した場合にx86に戻す自動フォールバック機構を実装した。これらのセーフガードにより、チームは本番の信頼性を維持しながら、サービスを段階的に移行することができた。
最初のARMベースのサービスの成功裡なデプロイメントは技術的マイルストーンとなり、マルチアーキテクチャインフラストラクチャがUber社の規模で機能することを証明した。しかし、この初期の成功から何千ものサービスを移行するまでの道のりには、さらなる戦略とツールが必要である。
クラウドプロバイダーがプロセッサアーキテクチャオプションを広げる中、Uber社やBitmovin社のような組織は、大規模なインフラシステムに多様なコンピューティングアーキテクチャを組み込むことの課題と潜在的なメリットの両方を示している。Bitmovin社のARMプロセッサへの完全なエンコーディングサービスの移行は、Uberの経験と並んで、企業が大規模なアーキテクチャの多様性をどのようにナビゲートできるかについての貴重な洞察を提供している。