コンピューターのフットプリントの大半をクラウドへ移行する準備として、Uberは、コンテナ化されたマイクロサービスのほとんどをμDeployからUpと名付けられた新しいマルチクラウドプラットフォームに移行した。多くのマイクロサービスをポータブルにすることに2年を費やした。
Uberは2014年にモノリシックアプリケーションとしてスタートしたが、成長とともにマイクロサービスアーキテクチャに移行した。同社は、規模に応じたアプリケーションサービスのデプロイを標準化するためにμDeployを開発。この移行により、ホストの管理と配置の側面は抽象化されたが、サービスの管理と配置は依然として手作業が多く、サービスエンジニアはサービスを特定の地域のどのゾーン(物理データセンター)で実行するかを決定しなければならなかった。
Uber社のシニアスタッフエンジニアであるMathias Schwarz氏とエンジニアリングマネージャーのAndrew Neverov氏は、Uber社がエンジニアリングチームをインフラから完全に切り離す決断をした理由をこのように語っている。
オンプレミスのデータセンターでは、チップ不足やサプライチェーンの問題により、長いリードタイムが発生していました。2023年2月13日にUberはOracleやGoogleと提携し、サプライ チェーンの問題にさらされるリスクを分散し、軽減することを目指しました。この戦略を実行するには、ビジネスを支える何百ものさまざまなサービスに取り組む何千人ものUberのエンジニアから、基盤となるインフラを抽象化する仕組みがなければ不可能です。
2018年、Uberのプラットフォームチームは、サービスの配置とインフラレベルのマイグレーションを自動化する役割を担う、新しいマルチクラウド、マルチテナントのフェデレーションコントロールプレーンに取り組み始めた。Upと名付けられたこの新しいプラットフォームは、サービスエンジニアがインフラシステムとやり取りするための主要なツールになる予定だった。また、安全なコードロールアウトを推進するためのベストプラクティスを管理・実施する。
アップハイレベル・アーキテクチャ(出典:Uber Engineering Blog)
Upプラットフォームはレイヤー化されたアーキテクチャを持ち、エクスペリエンスレイヤーはユーザーとのやり取りや、ワークロード管理、スケーリングを含むシステムのハウスキーピングを担当する。プラットフォームレイヤーは、エクスペリエンス・レイヤーのコンポーネントが使用する共通の抽象化と概念モデルを提供し、ホストマシンの能力と計算能力に基づくサービス配置の制約を表現するために使用される。フェデレーションレイヤーは、コンピュータークラスターとの統合を実装し、利用可能な容量と定義された配置制約に基づいてサービス配置を実行する。変更管理コンポーネントは、ヘルスモニタリングによってサポートされる段階的なロールアウト機能を提供する。一番下のレイヤーは、Peleton( Apache Mesosの上に構築されたUber独自のオープンソースのコンテナオーケストレーションプラットフォーム)とKubernetesを使用して、実際のクラスターインスタンスを含む。
クラウドへの移行の準備として、同社はすべてのステートレスマイクロサービスをポータブルにすることに2年を費やし、ゾーンやリージョンへの配置をサービスエンジニアが関与することなく一元管理できるようにした。チームは、既存のツールを使ってゾーン間でサービスを移動させ、ポータブル性を確保した。まず、ポータビリティの問題を解決するために、サービスを元のゾーンに戻すことを許可したが、解決された後は、ポータビリティを検証し、リグレッションを防ぐために、定期的にサービスを移動させた。
いったんポータブルになったマイクロサービスは徐々に、そしてほとんどが自動的にUpに移行された。自動スケーリングと効率化の 取り組みにより大幅な金銭的節約をもたらし、サービスチームのメンテナンス負担をかなり軽減した。UberのマイクロサービスプラットフォームのほとんどがUpによって管理されるようになったことで、同社はサービスやチームに大きな影響を与えることなく、クラウド移行の取り組みを自由に開始できるようになった。また、自動化された継続的デリバリーとデプロイの安全性にも注力したいという。