- "Up: Portable Microservices Ready for the Cloud"
- Uberでは4,500人のエンジニアと多数の自動化システムが、毎週4,000回以上にわたり4,500のステートレスなマイクロサービスをデプロイしている
- これらのサービスは、世界中で独立して働く数百の個別チームによって開発・デプロイ・運用されている
- サービスは規模・形態・機能が多様で、一部は小規模で内部作業に使われ、一部は大規模でリアルタイムの大量計算に使われている
Uberのステートレスサービスの歴史
- 2014年、UberはPythonで書かれたモノリスを運用し、データは1台のPostgreSQL DBに保存していた
- 成長に伴ってエンジニアを増員し、マイクロサービスアーキテクチャへ移行した
- サービス数が増えるにつれ、UberはµDeployというツールを作り、コードを中央から大規模にデプロイした
- すべてのステートレスサービスをコンテナ化し、ホスト管理と配置を抽象化した
- インフラグループが、ビジネス単位のマイクロサービスとは独立してホストフリートを管理できるようにした
- ただし、サービス管理と配置は依然として手作業だった
- Uberのインフラは、複数のゾーンのグループがリージョンを構成するモデルに従っている
- リージョン内のゾーン間レイテンシは十分に小さいため、同一リージョン内のサービス間では同期通信が効率的だった
- 各ゾーンはUber所有マシンのクラスター、またはパブリッククラウド事業者のものになり得るが、特定のゾーン自体は常に単一事業者のみで構成される
- 一般に、すべてのマイクロサービスは同一リージョン内にある限り、レイテンシの問題なく他サービスを呼び出せる必要がある
- µDeployでは、エンジニアが依然として可用性ゾーン単位で物理配置を管理しなければならなかったため、ワークロードの地理的配置はシステム上で中央集約されていなかった
- つまりサービスエンジニアは、オンプレミスのゾーンでサービスを動かすかどうかだけでなく、どの特定ゾーンで動かすかも決める必要があった
- オンプレミスデータセンターを運用する中で、半導体不足とサプライチェーン問題によりリードタイムが長期化していた
- 2023年2月13日、Uberはサプライチェーン問題への露出を減らして分散させるため、OracleおよびGoogleと提携した
- ビジネスを支える数百の多様なサービスを開発する数千人のUberエンジニアにとって、「基盤インフラを抽象化できるシステム」なしにこの戦略を実行するのは不可能だった
Uberをクラウドへ移すための準備
- 事業を継続しながら4,500のステートレスサービスをクラウドへ移行するには、膨大な調整と労力が必要だった
- この作業はミスが起こりやすく、手動で調整された取り組みで管理するのはほぼ不可能だと当初から明らかだった
- ステートレスマイクロサービスを大規模に維持・管理するには、人手を介さず中央集約型デプロイシステムで自動管理できるよう、サービスを進化させる必要があった
- Statelessを超えてPortabilityへ
- リージョンとゾーンのモデルをもとに、「移植性（Portability）」という概念を考案した
- 移植性とは、リージョン内のあらゆるゾーンで実行でき、人手を介さずインフラプラットフォームによって自動的に新しいゾーンへ移動できるサービスを指す
- パブリッククラウド事業者間の移動だけでなく、オンプレミスゾーンの内外への移動も含まれる
- 一部のサービスはゾーン構成やゾーンリソースの選好に依存していたため、通常は移植性を持っていなかった
- クラウドへの自動移行を行うには、すべてのサービスが移植性を備えている必要があった
UberをPortableにする
- 2021年から2022年にかけて、すべてのサービスに移植性があることを確認するため、全社横断のプログラムを実施した
- 多くの場合、コード検査で文字列定数やファイル名の使用を見るだけでも、移植性違反を検出できた
- 単純なケースでは、特定の物理ロケーションで動くようハードコードされているように見えるコードを強調表示するlintルールを作成した
- サービスが本当に移植可能かを試すため、実際に人手を介さず複数ゾーン間でサービスを移動させる必要があった
- サービスオーナーがサービスの最初の移動を開始できるテストツール群を構築した
- 既存の安全で段階的なコードロールアウト用ツールを基盤にしていたため、サービスオーナーはいつでも元のゾーンへデプロイを戻し、問題が見つかれば対処できた
- 移動が成功すると、そのサービスは以後自動的に移動可能としてマークされた
- その後数年にわたり、Uberの全サービスに対してこのプロセスを繰り返し、最終的にすべてのサービスで完了した
- 作業完了後は、サービスエンジニアの介入なしにゾーントポロジーを変更できるようになった
- 時間が経ってもサービスが移植性を維持できるよう、数週間ごとにすべてのサービスをゾーン間で継続的に移行し、移動機能を定期的にテストしている
- これによりサービスのリグレッションを容易に発見でき、時間の経過とともにエンジニアは特定ゾーンへの配置を前提にしないことに慣れていった
Up: マルチクラウド・マルチテナント Federation Control Plane
- 次のような初期システム目標を設定した
- エンジニアがインフラシステムとやり取りするための単一の入口（Single Point of Entry）を提供する
- システムに直接デプロイされるサービスに対してベストプラクティスを管理・適用し、コードロールアウト時に高い安全性を提供する
- 可用性ゾーンへのサービス配置を自動化する。新しい可用性ゾーンが利用可能になると、新ゾーンへ配置を変更し、通常はUberの高可用性を支えるために配置を中央で調整することも含む
- 面倒なインフラレベルのマイグレーションを自動化し、サービスエンジニアがマイグレーションに関与しなくて済むようにする
- ハイレベルアーキテクチャ
- Experience Layer:
- エンジニアがシステムとやり取りする多様な方法を実装する
- UI、Continuous Delivery、システムを健全に保つロボットなど
- 利用率の低いクラスターやゾーンへワークロードを継続的に移動するBalancer
- 各ワークロードの容量割り当てを継続的に最適化するAuto Scaler
- Platform Layer:
- Experienceレイヤーがサービスとやり取りする際に使う抽象化を実装する
- サービス運用の概念モデルを形作るサービスおよびサービス環境の抽象化と、サービスレベルAPIそのものを含む
- プラットフォームレイヤーでは、サービス制約は実際のサービス配置に望まれる特性を記述する高レベルな目標状態として表現される
- 実行するマシン性能や、リージョン別サービスの総計算容量に関する制約を含められる
- Federation Layer:
- 計算クラスターへの統合を実装する
- 上位レイヤーで使うリージョンおよびゾーン抽象化を実現するため、すべてのクラスターを機能と物理配置に応じて構成する
- プラットフォーム上の高レベルなサービス目標状態を受け取り、ゾーンおよびクラスター配置へ変換する。この変換は、目標状態の制約とクラスターの実際の状態（現在利用可能な容量や、クラスターおよび補助制約を満たせるクラスターを含む）に基づく
- この変換結果は時間とともに変化し、その後で別のゾーンやクラスター配置のほうが望ましくなる場合がある
- Balancerからのあらゆる呼び出しや、Experienceレイヤーから開始される他の作業によっても、この配置は再計算・変更され得る
- システムの安全性を保ち、サービスを良好な状態に維持するため、変更管理コンポーネントは、サービス状態を監視する全システムとの統合を通じて、グローバル状態を少しずつ段階的に変更するロールアウトフローを実装する
- ロールアウトプロセスには、システム全体でのカナリアリリースと状態シグナルの監視が含まれ、問題が見つかれば、システムは変更開始前の構成と配置へサービスを迅速にロールバックする
- Regions
- リージョンには実際のクラスターインスタンスが含まれる
- PelotonおよびKubernetes®クラスターを含む
- これらはUp自体の外部にあるが、実際の容量配置の対象であり、物理ホスト上のコンテナ配置を管理する
効果
- 2018年にUpの取り組みを開始し、2019年初頭に動作するプロトタイプを提供、2020年半ばにプラットフォームを正式リリースした
- それ以降、Uberの全事業ラインにわたって4,000以上のサービスを既存デプロイプラットフォームからUpへ移行した
- この移行の大半は自動化されていたため、チームは最も高度なユースケースに集中でき、他チームの移行支援も可能だった
- この期間、プラットフォームの安定性を最優先事項とし、毎日数百万人がUberのシステムを利用する状況でも事業を安定して運営できた
- 約2,000,000個のコンピューティングコアを新プラットフォームへ移行する全体マイグレーションは約2年にわたって実施され、2022年に成功裏に完了した
- このマイグレーションにより、自動スケーリングと効率化の取り組みを通じて数千万ドル分の追加容量を事業へ還元した
- 手動サービス更新、新しいゾーンの設定と立ち上げ、Uberの複雑なインフラ環境を学びながら横断するのに費やされていた数万時間のエンジニアリング時間を削減し、大幅な金銭的コスト削減につながった
今後の取り組み
- µDeployからUpへの移行を完了した後、チームは現在、中央集約かつ自動化された方法で全サービスへ適用できるソリューションと、これらの機能を中心としたユーザー体験の構築に集中できるようになった
- クラウドマイグレーション
- Uberはフリートのかなりの部分をクラウドへ移行中
- 大規模自動化とUpが提供する抽象化レイヤーにより、サービスチームはこの移行に必要なインフラ詳細から大きく切り離される
- 自動化されたContinuous Delivery
- 自動化されたパイプラインを使い、コードが本番環境にデプロイされる前にさまざまな検査とテストを実行し、本番までのコードデプロイを完全に自動化することを目指している
- 2023年にチームが注力する特別な部分は、サービスを「最新状態」に保ち、本番で動作するすべてのコードが最新のセキュリティ更新とライブラリアップデートを反映するようにすること
- デプロイ安全性（Safety）
- 既存データによれば、観測されたインシデントのかなりの数がコード変更および設定変更に関連していることが分かっている
- 本番前テストの実行や段階的ロールアウトポリシーの設定など、サービスライフサイクルの手動側面を自動化し、実際に本番へ到達する不具合の割合を大きく下げることを目標としている
- プラットフォーム
- Uberのすべてのステートレスサービスフリートを1つのアンブレラプラットフォーム配下に構成することで、インフラプラットフォーム製品間の依存関係と相互作用をより明確にモデル化できるようになる
- これにより、コード上で統一モデルを提供できるだけでなく、他のエンジニアリング組織にも完全に統合されたユーザー体験を提供できる
- すべてのインフラを1か所から観測・運用できることがチームの次の大きな目標だ
結論
- Upプラットフォーム構築の取り組みは、現在ではすべてのステートレスサービスが同じベストプラクティスと自動化を使って段階的にデプロイされているという点で、大きな文化的変化を意味している
- ロールアウトポリシーの変更や大規模ライブラリロールアウト向け自動化の構築で、以前は数か月かかっていた作業が、いまや中央集約型の方法で可能になった
- Uberエンジニアがインフラを気にせずコードにだけ集中できるようにするというビジョンを実現するため、Upのステークホルダーおよびサービスオーナーと継続的に協力していけることを期待している
まだコメントはありません。