Dapr 1.0で知るMicrosoftのガバナンス意識の高さとは？

Microsoftが開発をリードする分散システムのためのランタイムDaprが、1.0としてリリースを行った。今回は2021年2月23日に行われたCommunity Callを参考に、1.0のリリースに対してMicrosoftそしてコミュニティがどのような準備を行ったのか？ その意識の高さを紹介したい。

Dapr 1.0に到達

Daprは大きなマイルストーンである1.0に到達

1.0のリリースを発表したブログ：Announcing Dapr v1.0

Daprについては2020年7月に以下の記事で紹介しているので、その概念や目的などはこちらで確認して欲しい。簡単に言えば、クラウドネイティブなシステムを開発しようとした時に、現在のデファクトスタンダードであるKubernetesがデベロッパーに大きな負担になっていることを解消しようとするものだ。単に「宣言的にインフラストラクチャーを構築、分散＆冗長化させるだけではなく、プログラミングモデルまで踏み込んでシステムを構築できるランタイム」と言えば大枠として理解できるだろう。

ポイントは、Daprのプロジェクトを開始したMicrosoftにとって「Kubernetesがインフラストラクチャー寄り過ぎてデベロッパーの負担が大き過ぎる」という反省から産まれたソフトウェアであることだろう。

参考：分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？

ここではDaprそのものの解説よりも「1.0」という安定したリリースを出したコミュニティがどういうクライテリアでソフトウェアを評価しているのか？ その枠組みを解説することで、オープンソースソフトウェアにおいて「1.0」というマイルストーンを通過する際に何が重要視されているのかを明らかにしていきたい。

ひとくちにオープンソースソフトウェアと言っても、それぞれの発端や歴史があるわけだが、少なくともエンタープライズ企業が信頼するに足りるソフトウェアであるためには、Microsoftが何を必要最低限だと考えているのかを知る物差しになると筆者は考えているからだ。

Community Callのアジェンダ

最初に紹介されたスライドでは今回のオンラインミーティングのアジェンダが説明されている。ここでは1.0の振り返りとして発表後の影響の解説、バージョン番号の考え方、コンポーネント認定について、セキュリティオーディットに関する評価、パフォーマンスに関する考察などが含まれている。

Daprコミュニティに対する貢献の方法を解説

最初にコミュニティへの貢献の仕方を、ドキュメントサイトを使って解説した。真っ先にコミュニティに参加する方法を解説するというのが、コミュニティのサイズと質を気にしていることの現れのように感じられた。貢献の概要、ドキュメントへの貢献の方法、さらにPython SDKへの貢献という順番になっているのも、ドキュメントの重要性を示している。Daprのドキュメントサイトは非常に良く構成されており、「コンセプト」「始め方」「アプリケーション開発の方法」「運用方法」「リファレンス」「貢献の方法」という順番の章立てになっている。これは、「アプリケーション開発」の方が「運用方法」よりも優先順位が高いということを暗に示しているのであろう。

参考：Dapr Docs

ドキュメントのブランチも独特の扱い

Daprのリポジトリーもよくあるマスターやメインという名称ではなく、明示的にメジャーバージョン、マイナーバージョンの数値で採番されているのが特徴だと解説した。

Dapr 1.0の概要

ここから1.0のリリースにおける全体的な説明に入った。

Dapr1.0発表時の反響などを解説

このスライドでは、ブログでDapr 1.0のリリースを発表した2021年2月17日から21日までにどのような反響があったのかを示している。メディアでの掲載、GitHubのスターの数、Twitterでの反響やサイトへのビジター数などオープンソースプロジェクトには珍しくマーケティング的な視点で評価していることがわかる。

ちなみに2020年10月に公開された動画で紹介されていた数値がソフトウェアそのものに注目していることからすれば、プロジェクトがマーケティングに意欲的であることが見て取れる。

2020年10月1日のプレゼンテーションからの数字

メディアへの掲載例を紹介するスライドでも幅広くリサーチを行っていることがわかる。

Dapr 1.0リリースに関するメディア掲載例

またプロジェクトに対する認知から評価、利用そして実際にプロジェクトへの貢献をファンネル（ろうと）として定義し、このリリースがいかに新規ユーザーを取り込んだのかを評価するスライドを使って解説した。リリースを公開したツイートのインプレッション数（18万回）からWebサイトの閲覧数、ドキュメントサイトへのユニークユーザー数、Discordチャネルの新規ユーザー数、新規コントリビュータ数などマーケティング的発想で評価しているのがわかる。ベースラインとして比較の対象になっているのは、1.0リリースの1週間前のそれぞれの数値である。

マーケティングのファンネルを使ってリリースを評価

厳密なバージョン管理

そしてここからDaprのバージョン番号の考え方、コンポーネントの認定に関する解説を行った。

Daprバージョン番号、コンポーネントの認定を解説

次のスライドでは1.0という初期のリリースにも関わらず、リリースごとの互換性、特に下位互換性を重要視していることが解説された。大きな変更がある場合には、その変更の2つ前のリリースから告知を行うこと、また機能を廃止する場合も2つ前のリリースから告知を行うという厳密なルールを課していることが説明された。

バージョン番号と互換性に関する解説

ここでバージョンを付与される対象として定義されているのが、バイナリーだけではなくAPI、コンポーネントそしてリポジトリーであることにも注目したい。つまりコアなバイナリーだけではなく他のコンポーネント（SDKなど）やAPI、リポジトリー、ドキュメント、クイックスタートなどについても、リリース番号を付けて厳密に監視する方針が解説された。なおドキュメントサイトもバージョンごとに構築されていることは注目すべきだ。

バージョン管理はバイナリーだけではなく包括的

バージョン番号は「メジャーリリース.マイナーリリース.パッチ」というフォーマットで管理され、パッケージごとに独立して管理されると解説したのが次のスライドだ。

バージョン番号の考え方

そしてメジャーリリース、マイナーリリース、パッチとは何かを解説したのがこのスライドだ。またAPIのバージョンについても明確に定義されていることも注目したい。

メジャー、マイナー、パッチとは何か？

APIのバージョンについても解説

またコンポーネントライフサイクルについても明確に定義されており、アルファ、ベータ、GA（General Availability）の定義や適合性テストなどについても明記されている。このことからもわかるように、Daprが非常に厳格なルールの中で開発されていることがわかる。

コンポーネントの認定を解説

サポートについても言及しており、オープンソースプロジェクトというよりも商用ソフトのサポートクライテリアを提示しており、エンタープライズ企業向けのソフトウェアで鍛えられたMicrosoftの姿勢が垣間見える内容となった。

サポートの範囲は2リリース（最新版と1つ前）

サポートされるリリースの具体例

Daprのセキュリティについて

Daprはセキュリティについても重要視しているとして解説されたのが、次のスライドから始まる内容だ。分散型システムであるDaprは、デフォルトでMutual TLSを利用しており、Sentryと命名された認証システムが認証キーを発行して暗号化する仕組みとなっている。Kubernetes環境下での実装やマイクロサービスとしてネットワーク化される場合、セキュリティとしてどこが攻撃のターゲットになるのか？ についてもモデルを使って解説された。

Daprが想定する攻撃モデル

セキュリティの最後のトピックとしてセキュリティオーディットが2020年6月と2021年2月に実行されたことを解説した。これはCNCFのプロジェクトとしてKubernetes、CoreDNS、Envoy、Prometheusなども行った検証テストで、Daprもそれらに倣ったというものだろう。

Kubernetesのセキュリティオーディット：https://www.cncf.io/blog/2019/08/06/open-sourcing-the-kubernetes-security-audit/

Daprのセキュリティオーディットの結果については以下を参照されたい。

Daprのセキュリティオーディット（PDF）：Pentest- & Retest-Report Dapr 02.2021

Kubernetesとは実施しているベンダーは違うものの、1.0のリリースに際して8ヶ月というインターバルを経てソフトウェアそのものの安全性を外部ベンダーに託して評価させたという事実はエンタープライズ企業にとっては好評価であろう。

セキュリティオーディットの解説

Daprの性能について

最後に解説されたのは、Daprの性能面での評価だ。これは分散システムとしてのPodやSentryの起動性能、そしてスケーラビリティに関する評価、データプレーンとして実際にトラフィックを発生させて計測したもので、素のPodとDaprのmTLS、Sentryを利用した場合の差などについて計測されている。またDaprの特徴であるアクターモデルについても簡単ではあるが、起動時間などが測定されており、ここでも厳密であろうとするMicrosoftの姿勢が現れている。

Daprのパフォーマンスについても解説

全体として1.0という安定版のソフトウェアリリースに際して、機能強化を訴求するのではなく、ドキュメントサイトの充実ぶりやセキュリティ、パフォーマンスに対する意識の高さを訴求したオンラインミーティングとなった。

バージョン番号やリリースの考え方、サポートなどオープンソースプロジェクトとしては異例に厳密な枠組みを持っていることを示した形になったDaprであるが、プロジェクトをリードするMicrosoftにとっては当たり前のことなのだろう。今後、これらの枠組みがその他のオープンソースプロジェクトのテンプレートとして使われることを希望したい。