こんにちは Dapr Advent Calendar 25日目です。ついにファイナルを迎えました。私たちの挑戦を応援し続けてくれた世界中のファンの皆さん、そして、Dapr Advent Calendarに集まってくださった皆さん、本当にありがとうございます！
Daprを使うべきかどうか
一部のオタクにしか分からない挨拶から始めて申し訳ありません、いよいよDapr Advent Calendarも最終回です。最後は「Daprを使うべきかどうか」について論じたいと思います。
なぜDaprを使うのか
まずはDaprのメリットや、Daprが解決する課題について説明します。
この3つを順に説明します。
1. アプリとインフラを疎結合にする
Daprの主目的であり、このAdvent Calendarでも何度となく触れてきたことですが、Daprを使うことでアプリケーションとインフラ層を分離することができます。そのおかげで開発時にインフラ関連のツールは必要ありませんし、インフラのことを気にせずビジネスロジック（とWeb API）の開発に注力することができます。
その辺りはこの記事に書いていました。
また、Spring Cloudのようにアプリケーションとインフラ層の結合がより密接しているフレームワークでは、新旧バージョンの混在が難しいことがありましたが、アプリケーションとインフラ層が分離されているDaprでは、アプリケーションだけのバージョンアップ、Daprやk8sだけのバージョンアップが行いやすいというメリットがあります。
その辺りについては、この記事にも書いた通りです。
このアプリケーションとインフラ層を分離できるというのが、Daprの1つ目のメリットとなります。
2. 言語やフレームワークを選ばない
2つ目のメリットが、Daprがサイドカーという方式を採っているため、言語やフレームワークを選ばないことです。
僕はJava + Spring Bootで開発していますが、僕が大好きだったSpring CloudはJVM言語でしか開発ができません。Daprであればその縛りはなく、HTTP通信さえできれば好きな言語や好きなフレームワークでの開発ができます。
仮に組織の中で様々な言語やフレームワークを使う人たちがいたとしても、組織の共通技術基盤としてDaprを採用することができ、皆のノウハウを集めて育てることができます。
その気になれば、一つのシステムを別々の言語やフレームワークを混在させて構築することもできるでしょう。マイクロサービスの一要素としてポリグロット（多言語）が挙げられることがありますが、まさにそれを実現するための基盤としてDaprを利用することができます。
そんな好き放題に言語やフレームワークが使われることはあまりないとは思いますが、システムが非常に大きくてサブシステムごとに開発する組織が分かれる場合や、たとえばフロントエンドに近い部分はNode.jsで作り、コアに近い部分はJVM言語で作る、という程度のポリグロットなら現実にもあり得るでしょう。Daprはそうした状況でも共通的に使えるのです。
3. マルチクラウド
そしてメリットの最後が、マルチクラウドです。
たとえばAWS向けに開発していたシステムを、AWSの障害に備えてAzureやGCPでも運用したい時には、それぞれのマネージドサービスやミドルウェアを抽象化するDaprを利用できます。
そんな案件ほとんどないでしょ、せいぜいマルチリージョンまででしょ、と思っていたのですが、意外とそういうリクエストが "なくはない" という感じで、実際にマルチクラウドを目指している案件で、Daprを採用するかべきかどうかを一緒に検討して欲しいと言われています。
もちろんDaprなど使わなくても、各クラウド固有のマネージドサービスではなくPostgreSQLやMySQL、Redis、またたKafkaやRabbitMQなどを使うようにすれば十分だという面もあるでしょう。しかしDaprを使えばマネージドサービスのメリットを引き出しながら、共通のAPIで利用できるというメリットがあるというのも確かです。
ネットワーク関連の設定などはDaprの範疇外ですし、マルチクラウドは簡単でもありませんが、せめてアプリケーションとその周辺のインフラ層においてはDaprを使うことで複雑さを排除できる可能性があります。
この辺りは実際に取り組む機会などあれば、また改めてお伝えしたいと思います。
Daprを使う上での課題
もちろん、Daprを使えば順風満帆というわけでも、全幅の信頼が置けるというわけでもありません。Daprのデメリットや課題についても目を向けてみましょう。
- 導入事例が極めて少ない
- 機能が少ない
- メンテナンス期間の短さ
この3つです。ほぼ説明不要な気もしますが、順に説明します。
1. 導入事例が極めて少ない
まず一つ目、Daprは導入事例がほとんどありません。人によっては「cero-tさんがやってるやつ」みたいな印象があると耳にしたことすらあります。それくらい日本でも、おそらく世界でも、導入事例は多くありません。
全く枯れていない技術ですから、大きな問題があったり、情報が少なかったりするかも知れません。あるいは全く流行らなくてメンテナンスされなくなってフェードアウトしてしまうリスクだってあります。
新しいプロダクトを使うというのは、そういうリスクと戦うことになります。
2. 機能が少ない
Daprは世にアナウンスされから約2年、バージョン1.0がリリースされてから約1年くらいの新しいプロダクトですから、そこまで機能が多くありません。このDapr Advent Caledndarだけであらかたの機能を網羅できてしまう程度です。
Spring Cloudなどと比較すると、提供する機能も、対応するコンポーネント（マネージドサービス、ミドルウェア）も少ないですし、いくつかのコンポーネントはまだAlpha版やBeta版だったりします。Alpha版やBeta版の機能でも十分に使えるので僕は使っていますが、いつかAPIの仕様が変わるかも知れないというリスクを受け入れざるを得ません。
機能が少ない部分は自分でカバーしたり、クラウドの機能を直接使ったりする必要があるため、すべてがDaprだけで完結するわけでもありません。足りないところは自分で補う必要があるのです。
3. メンテナンス期間の短さ
DaprはMicrosoft社が中心に開発しているプロダクトですが、まだビジネス的に十分回っているわけではありませんから、サポートなどのエコシステムもそんなに整ってはいません。バージョン1.0からは「Production Ready」な品質として、少し古いバージョンでもパッチが提供されるようになりました。ただ、そのパッチの提供期間も長くはありません。
Daprはおおむね2ヶ月に1度程度、マイナーバージョンアップ（1.4→1.5、1.5→1.6など）が行われます。またバグフィックスや軽微な機能追加のためのパッチ（1.4.1→1.4.2、1.5.0→1.5.1など）が提供されます。このパッチの提供は「現行バージョンと、その一つ前のバージョン」のみが対象となっています。
2021-12-25現在の最新バージョンは 1.5.1 で、その前バージョンである 1.4 はパッチ提供の範囲内なので 1.4.4 までリリースされていますが、バージョン 1.3 以前にはパッチは提供されません。
おおむね2ヶ月に一度バージョンが上がることを踏まえると、特定バージョンのメンテナンス期間は4ヶ月程度しかありません。もちろん最新バージョン（1.x.0）がリリースされてすぐには使わず、パッチが1つ2つリリースされてから使うことも多いでしょうから、実質的には長くとも2ヶ月に一度くらいにはDaprのバージョンを上げる必要があります。
次のドキュメントにあるように1コマンドでバージョンアップできるとは言え、その頻度には抵抗がある組織だってあるかも知れません。
このサポートの短さは課題の一つと言えます。
Daprの課題を覆す
僕は上に書いたようなリスクを受け入れてDaprを使っているのですが、もちろん僕の「Daprを使いましょう」という提案を受け入れてくれたお客様も相当な勇気（あるいは無謀さ）があったように思います。*1
ただ、Daprに問題があった時に心中するつもりで使っているわけでもありません。Daprにどうしても受け入れられない問題があると分かったときには「Daprを捨てて自分で作る」つもりでいます。
DaprはHTTP通信で使うサイドカーですから、同様の機能を自分で作り込み、URLの向き先を自分で作った機能にすれば、Daprを使わずに同様の機能を提供できます。Daprを使っている以上はアプリケーションとインフラ層が疎結合になっているので、別のものに差し替えることだって不可能ではないのです。
もちろん口で言うほど容易なことではないですし、そんな状況が訪れることは願ってないですが、「Daprを使って開発すれば、最悪、自分で作り直すことだってできる」という感覚ではいるのです。そのため、リスクを受け入れることができました。
サイドカーコンテナ
ところで、Daprのようなサイドカーを、単独プロセスではなくコンテナとして提供するパターンもあります。
ここで記載されているサイドカーパターンやアンバサダーパターンを使えば、アプリケーション開発はビジネスロジックに注力し、サイドカーやアンバサダーがインフラとの連携に注力するという責任分解もやりやすくなるでしょう。Daprで提供されているような主要機能を、自分で好きなように実装して提供することもできるはずです。
ではなぜサイドカーコンテナパターンにしなかったのかと言うと、単純に、自分で実装するのが面倒だったためです。そこにDaprがあるんだから、Daprを使おう、ダメだった時には自分で作ろう、というくらいの感覚です。
そうやってダメな場合の撤退パターンも考えたうえで、僕はDaprを使うことに決めたのです。
まとめ
- なぜDaprを使うのか
- Daprを使う上での課題
- 導入事例が極めて少ない
- 機能が少ない
- メンテナンス期間の短さ
- 最悪、自分で作り直すという覚悟を持って使い始めた
最後になりますが、僕はDaprというプロダクトに魅力を感じているのもそうですが、それ以上にDaprという「アプリケーション寄りのサイドカーサービス」というアーキテクチャそのものに魅力を感じて使っているとも言えます。そのアーキテクチャに利があるという確信があるため、最悪は自分で作れば良いという覚悟ができましたし、他にもっと良いものが出てきたら乗り換えれば良い、きっと乗り換えやすいはずだと考えています。
それがいまの僕の考え方なんだ、ということをお伝えして、Dapr Advent Calendarを締めくくりたいと思います。
それでは、またの機会に！
See you!
*1:ちなみにこのお客様は5〜6年くらい前に「マイクロサービスで作ってみましょう」という提案も受け入れてくれました
