ablog

不器用で落着きのない技術者のメモ

サービスメッシュの歴史

TL;TR(まとめ)

  • サービスメッシュのロードバランシング、サーキット・ブレイキング、リトライといった機能自体は新しいものではなく以前はライブラリで提供されていた機能をリパッケージングしたもの。
  • サービスメッシュの起源は Web 3層モデルのアプリレイヤーで使われていたキャッシング、ロードバランシング、ルーティング、フローコントロールなどのハンドリングなどを行っていたライブラリ。
  • ハイトラフィックなワークロードを捌く GoogleFacebookNetflixTwitter などのWebスケールの企業はモノリシックなアプリケーションを独立したパーツに分解してマイクロサービス化していった。
  • 初期のサービメッシュはプロキシではなくライブラリとして提供されていた。Google の Stubby、Netflix の Hysterix、Twitter の Finagle など。
  • コンテナやオーケストレーターの登場によってデプロイの複雑さが劇的に低下したことで、ライブラリよりプロキシのほうが便利になった。例えば、ライブラリをコンパイルすると全てのアプリをデプロイし直さないといけないが、プロキシであれば全てのアプリをリコンパイルしてデプロイする必要はない。また、プロキシだとアプリケーションと異なる言語で開発することもできる。

"The History of the Service Mesh" より

So where did the service mesh come from? By doing some software archeology, we find that the core features the service mesh provides — things like request-level load balancing, circuit-breaking, retries, instrumentation — are not fundamentally new features. Instead, the service mesh is ultimately a repackaging of functionality; a shift in where, not what.

The History of the Service Mesh - The New Stack

サービスメッシュのコア機能である「ロードバランシング」、「サーキット・ブレイキング」、「リトライ」などは基本的に新しい機能ではなく、機能のリパッケージングである。新しい機能ではなく使われる場所が変わっただけである。

The origins of the service mesh start with the rise of the three-tiered model of application architecture circa 2010 — a simple architecture that, for a time, powered the vast majority of applications on the web. In this model, request traffic plays a role (there are two hops!), but it is very specialized in nature. Application traffic is first handled by a “web tier,” which in turn talks to an “app tier,” which in turn talks to a “database tier.” The web servers in the web tier are designed to handle high volumes of incoming requests very rapidly, handing them off carefully to relatively slow app servers. (Apache, NGINX and other popular web servers all have very sophisticated logic for handling this situation.) Likewise, the app layer uses database libraries to communicate with the backing stores. These libraries typically handle caching, load balancing, routing, flow control, etc., in a way that’s optimized for this use case.

The History of the Service Mesh - The New Stack

サービスメッシュの起源は2010年頃のWeb三層モデル(Web層-AP層-DB層)のアプリケーション・アーキテクチャに遡る。アプリケーションレイヤーはデータベースライブラリを使い、そのようなライブラリは一般的にキャッシング、ロードバランシング、ルーティング、フローコントロールなどのハンドリングなどを行っていた。

So far so good, but this model starts to break down under heavy load — especially at the app layer, which can become quite large over time. Early web-scale companies — Google, Facebook, Netflix, Twitter — learned to break the monolith apart into lots of independently-running pieces, spawning the rise of microservices. The moment microservices were introduced, east-west traffic was also introduced. In this world, communication was no longer specialized, it was between every service. And when it went wrong, the site went down.

The History of the Service Mesh - The New Stack

当時は良かったWeb 3層モデルも、ハイトラフィックなワークロードを捌くには厳しくなっていった。Webスケールの企業、Google, Facebook, Netflix, Twitter などはモノリシックなアプリケーションを独立したパーツに分解し、マイクロサービス化していった。

These companies all responded in a similar way — they wrote “fat client” libraries to handle request traffic. These libraries — Stubby at Google, Hysterix at Netflix, Finagle at Twitter — provided a uniform way of runtime operations across all services. Developers or service owners would use these libraries to make requests to other services, and under the hood, the libraries would do load balancing, routing, circuit breaking, telemetry. By providing uniform behavior, visibility, and points of control across every service in the application, these libraries formed what was ostensibly the very first service meshes — without the fancy name.

The History of the Service Mesh - The New Stack

各社はリクエストをハンドリングするためにファット・クライアント ライブラリを作った。Google の Stubby、Netflix の Hysterix、Twitter の Finagle など。全てのサービスの開発者やサービスオーナーはこのライブラリを使えば、ロードバランシング、ルーティング、サーキット・ブレイキング、モニタリングなどを共通の方式で行えるようになった。当時は名前はなかったが、これが「サービメッシュ」の始まりである。

Fast forward to the modern, cloud-native world. These libraries still exist, of course. But libraries are significantly less appealing in light of the operational convenience provided by out-of-process proxies — especially when combined with the dramatic drop in deployment complexity made possible by the advent of containers and orchestrators.

The History of the Service Mesh - The New Stack

現在のクラウドネイティブでも、これらのライブラリはまだ存在する。しかし、コンテナやオーケストレーターの登場によってデプロイの複雑さが劇的に低下したことで、アウトプロセスプロキシが提供する運用上の利便性を考慮すると、ライブラリは魅力的ではなくなった。

Proxies sidestep many of the downsides of libraries. For example, when a library changes, these changes must be deployed across every service, a process which often entails a complex organizational dance. Proxies, by contrast, can be upgraded without recompiling and redeploying every application. Likewise, proxies allow for polyglot systems, in which applications are comprised of services are written in different languages — an approach that is prohibitively expensive for libraries.

The History of the Service Mesh - The New Stack

プロキシは多くの点でライブラリより優れている。例えば、ライブラリを返納すると全てのサービスに変更をデプロイしないといけないが、プロキシであれば全てのアプリケーションをリコンパイルしてデプロイする必要はない。また、プロキシだとアプリケーションと異なる言語で開発することもできる。