UberにおけるモノリシックなAPIのマイクロサービスへの分解
- 共有
-
- |
後で読む
マイリーディングリスト
UberのエンジニアであるEmily Reinhold氏は、モノリシックなAPIをモジュール化された柔軟なマイクロサービスアーキテクチャに分割した方法を記事にした。彼女はUberが移行するにあたり鍵となったいくつかの設計事項とアーキテクチャ上の選択について焦点を当てた。
マイクロサービスに移行するにあたり、Reinhold氏は目標をより3つの点でよりスケーラビリティを獲得することであると述べた。増大するトラフィックに対処すること、簡単に機能追加を行うこと、そして組織の成長に迅速に適応することができるアーキテクチャを選択することである。
Uberのエンジニアはマイクロサービス間の結合度を低減するためにいくつかの総合的な設計上の判断を行った。
- MVCSの採用。これはよく知られたModel-View-Controllerアプローチの拡張で 、明示的にアプリケーションロジックを担当するサービス層を含んだものである。この構造により永続化層とビジネスロジックを疎結合にすることを可能とし、後の変更を容易にする。
- PostgreSQLのUDRへの置き換え。このことにより世界中に複製されたデータストアが複数のデータセンタからのアクセスに応答することを可能にした。
同時に、Uberのエンジニアは多くのサービスを扱うために重要なアーキテクチャ上の決断を行った。
- 非同期ネットワーク処理。これは増加する多数のサービス要求を処理するためであり、同時に万単位のコネクションを扱うことができるとされる、Pythonで書かれたイベントループベースの非同期ネットワークライブラリであるTornadoを採用した。Tornadoを用いる利点の一つは、非同期パラダイムをもとに構成された、Uberの既存のネットワーク実装とうまく統合できる能力を持っているためである。
- サービス探索と回復性。増加する多数のサービスを取り扱う際、鍵となる機能はサービスを探索することと障害点を特定することである。これは失敗率やSLA違反のような指標の取集を含み、不健全なホストを検知し、失敗が連鎖することを防止するためにサーキットブレーカを発動させる。Uberはこれらの検討事項をHyperbahn上でTChannelを用いることで対処している。これらは彼らが開発したオープンソース化されているRPCのためのネットワーク多重化とフレーム化のプロトコルである。
- 厳密なインターフェイス定義。UberはIDLを用いたインターフェイス定義及び多様なプログラミング言語向けのクライアント側とソースコードの生成のためにThriftを選択している。Thriftはインターフェイス定義に準拠していない呼び出しをクライアントが行おうとしていることを検知することが可能である。
最後に、Reinhold氏はUberが次の3原則を適用することによりプロダクション環境の健全性を保っていると説明した。
- ボトルネックと故障点を特定するために負荷テストを実行すること
- ハードウェアをより有効に活用するためにコンテナを用いること
- システムが復旧可能であること、及び脆弱性を特定するためにシステムの崩壊を模擬することができること
Emily Reinhold氏はこれらの話題を先にニューヨークで開催されたQConでも議論した。
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
この記事に星をつける
コミュニティコメント