こんにちは、コンテナソリューショングループの松崎です。
AzureでServie Mesh関係のソリューションを調べていてDaprとOpen Service Meshについて「機能が似ているように見える」「差分は何だろうか?」という疑問を持ちました。本記事はそのまとめになります。
サマリ
- Daprは「Microservices自体の開発を容易にすること」を意図した製品であり、Service Meshを目的としていない
- しかしながら、DaprはDisrtibuted TracingなどService Meshと同等の機能を一部持っている
- 上記の理由のため、Dapr単独では実現不可能なユースケースがある。具体的にはA/BテストなどのためにTraffic Splitting機能が欲しい場合は、Service Mesh製品との併用が必要
Introduction
AKS上でのMicroserviceの構築をサポートするソリューションを調べていると、DaprとOpen Service Meshのキーワードを目にすることが多いです。両者ともに サイドカーパターン を採用しており、技術的に似た領域にアプローチをしようとしているように見えます。
DaprとOpen Service Meshの製品コンセプトはどのように異なるのでしょうか?
DaprはServie Mesh Productではないよという話
Dapr 公式の FAQ : How does Dapr compare to service meshes such as Istio, Linkerd or OSM を見ますと、Service Mesh製品で扱われるようなNetworking領域の問題については主目標においていない事が明言されています。Daprの開発者達は、 「開発者が」Microservicesを構築する際のビルディングブロック *1を作りたいというモチベーションでDaprを開発したようです。
Dapr is not a service mesh. While service meshes focus on fine-grained network control, Dapr is focused on helping developers build distributed applications. Both Dapr and service meshes use the sidecar pattern and run alongside the application. They do have some overlapping features, but also offer unique benefits. For more information please read the Dapr & service meshes concept page
Daprがコンセプトに掲げる「Microservicesのためのビルディングブロック」とService Meshesが扱う問題領域は、具体的にどのように異なるのでしょうか? 以下のページで詳細に解説されています。
Dapr Docs : How Dapr and service meshes compare
要点は以下となります。「Service Meshがインフラ領域/Networkingを意識するのに対し、Daprは開発者体験を重視している」という点を理解することが重要そうです。
- Service Meshはインフラエンジニアリング、その中でも特にNetworkレイヤの通信の管理/操作を主な関心においている
- Daprはよりソフトウェアエンジニアリングな関心を解決するために作られている。そのため、DaprのAPIもSystem Operatorの手を介さずApplication Codeから直接操作できるようAPI設計している
While Dapr and service meshes do offer some overlapping capabilities, Dapr is not a service mesh, where a service mesh is defined as a networking service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric.
.
In most cases, developers do not need to be aware that the application they are building will be deployed in an environment which includes a service mesh, since a service mesh intercepts network traffic. Service meshes are mostly managed and deployed by system operators, whereas Dapr building block APIs are intended to be used by developers explicitly in their code.
具体的な機能の差分
上記を踏まえると製品の特性は以下のように整理できそうです。
- Open Service MeshはService Meshを意識した製品であり。そのため、 インフラ観点で Networkを操作することを主な関心としている。
- Daprは開発者がMicroserviceをできるだけ簡単に構築することを目指しており、その実現のために ソフトウェア開発の観点から 必要な機能のみをスコープに入れている。
具体的なDaprとOpen Service Meshの機能の差分は前述のページにて図示されています。 Traffic routingとTraffic splitting機能についてはDaprのスコープ外となっていることがわかります。
どのように使い分けるのか
そうなりますと、次に出てくる疑問は「どのような基準でDaprとOpen Service Meshを使い分ければいいんだろう?」ですが、こちらについても FAQ : When to choose using Dapr, a service mesh, or both というページが用意されています。
- Daprが提供するビルディングブロックを使ってMicroservicesを開発したい場合は、Daprのみの利用を推奨する。 Dsitriburted TracingについてもDapr単独で対応が可能
- 「Microservice間の通信を暗号化したい」というユースケースについては、全てのMicroserviceがDapr sidecarを保持しているケースにおいてはDaprのみで対応可能。しかしながら、Dapr sidecarを保持していないMicroserviceあるいは他のコンポーネントについても暗号化したい場合、Service Mesh製品を合わせて利用する必要がある。
- また、A/Bテストなどの目的でTraffic Splittingを行いたい場合もService mesh製品とのIntegrationが必要
If, for example, you are looking to use Dapr for one or more building blocks such as state management or pub/sub, and you are considering using a service mesh just for network security or observability, you may find that Dapr is a good fit and that a service mesh is not required.
.
Typically you would use a service mesh with Dapr where there is a corporate policy that traffic on the network must be encrypted for all applications. For example, you may be using Dapr in only part of your application, and other services and processes that are not using Dapr in your application also need their traffic encrypted. In this scenario a service mesh is the better option, and most likely you should use mTLS and distributed tracing on the service mesh and disable this on Dapr.
.
If you need traffic splitting for A/B testing scenarios you would benefit from using a service mesh, since Dapr does not provide these capabilities.
FAQ : When to choose using Dapr, a service mesh, or both
まとめ
駆け足ではありますが、Daprの開発陣がDaprとService Meshとの製品コンセプトの違いをどのように考えているか公式マニュアルを概観してみました。少しでも参考になれば幸いです。
また、本稿の解説ではスコープ外としていますがDaprの真骨頂は、 インフラストラクチャレイヤを抽象化し、ソースコードとインフラの関係を疎結合/Pluggableにすることにより、Microservicesの初期開発時のベロシティと後々のインフラストラクチャの変更容易性を両立させたアプリケーション開発を可能にした点にあると筆者は考えています。*2 *3
Daprは提供する機能が多く筆者は未だその全貌が把握しきれていない状況ではありますが、 ポテンシャルを感じる製品ですので、今後公式ドキュメントを眺めつつ理解を深めていく予定です。
2022/3/10 追記
Daprのその後ですが、リトライ/タイムアウト/サーキットブレーカーなどの実装を共通化/強化する方向で機能の追加が進んでいるようです。そのため、Service Mesh製品との差分は縮まっていく方向にあるように見えます。
*1: ビルディングブロックという言葉が何を指すのかイメージしづらいかもしれませんが、「レゴブロックのように既成の部品を組み合わせるだけでシステムが容易に構築可能になる」というイメージだと理解しています。
*2:参考 : BOSHのAKS + Dapr導入事例 / Technical Story , BOSCH
*3:参考 :Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料) P51-P56