序文 - .NET 開発者向け Dapr
ヒント
このコンテンツは、.NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、 .NET 開発者向け Dapr の電子ブックからの抜粋です。
クラウドの導入が進むのに伴い、"クラウド ネイティブ" 開発への大きなシフトが起きており、その多くはマイクロサービス アーキテクチャを使用して構築されています。 これらのマイクロサービスはステートレスとステートフルの両方であり、クラウドとエッジ上で実行され、現在利用可能なさまざまな言語とフレームワークが採用されています。 このエンタープライズ シフトは、市場投入までの時間短縮に対する市場の圧力と、クラウド用サービス構築のスケールと効率性の両方によって推進されています。 COVID-19 より前の時点で既に、企業によるクラウド導入は加速し、開発者はこれらの分散システム アプリケーションの構築についてさらに多くのことを行うように求められていました。 これが COVID-19 以降に加速しただけのことです。 企業の開発者は、ビジネス ロジックに焦点を当てる一方で、クラウドネイティブ アーキテクチャのスケール、回復性、保守容易性、弾力性、その他の属性をアプリケーションに組み込むことは、プラットフォームに依存しています。そのため、基になるインフラストラクチャを隠ぺいするサーバーレス プラットフォームへのシフトも発生しています。 開発者に、分散システムの専門家になることを期待してはいけません。 Kubernetes などのインフラストラクチャまたはサーバーレス プラットフォームのどちらを基にして構築している場合でも、これは Dapr が役に立つ部分です。
Dapr は、"任意の言語、任意のフレームワーク、任意の場所で実行する" という信念に従い、開発者中心のマイクロサービス プログラミング モデル プラットフォームとして設計されています。 それを使用すると、分散アプリケーションの構築が容易になり、パブリック クラウドから、階層エッジ、さらには単一ノードの IoT デバイスまで、あらゆるインフラストラクチャに移植できます。 それは、Azure でのサービスの構築に関する経験と、Azure Kubernetes Service や Azure Service Fabric でアプリケーションを構築するためにお客様との作業に費やされた時間の両方から生まれました。 繰り返し、対処する必要がある一般的な問題を目にしました。 そのことから、新しい新分野のアプリケーションだけでなく、既存のアプリケーションの最新化を支援するためにも、開発者が使用できる一般的なマイクロサービスのベスト プラクティスの "ライブラリ" を提供する必要があることが明らかになりました。 クライアントとサーバーの時代には DLL が推奨されたのと同じように、コンテナー化され、分散され、ネットワーク化されたクラウド ネイティブ環境では、サイドカー モデルが推奨される方法として出現しています。 Dapr のサイドカーと API を使用すると、開発者は、簡単な単一の HTTP または gRPC のローカル呼び出しを使用して、分散システムの機能をすべて活用できます。
開発者が直面する幅広いシナリオに対応するため、Dapr には、状態管理、サービス間の呼び出し、pub/sub、そして Azure Functions のトリガーとバインドに基づく I/O バインドによる外部システムとの統合などの機能が用意されています。 これらによって利用されている Dapr のコンポーネント モデルを使用することで、コードを変更することなく、基になる状態ストアを異なるものに "入れ替える" ことができます。 このコンポーネント モデルによってコードの移植性と柔軟性が向上し、ニーズに最も適したものを実験できるようになります。 開発者は、サービス SDK を学習してコードに組み込んだり、認証、シークレット管理、再試行、または特定のデプロイ環境を対象とする条件付きコードについて心配したりする必要はありません。
この記事では、標準の .NET 参照アプリケーションである eShop を段階的に "Dapr 化" することによって、開発時間とコード全体の保守を軽減する方法について説明します。 たとえば、元の eShop の実装では、サービス間のイベント発行のために、Azure Service Bus と RabbitMQ の間を抽象化するため、膨大な量のコードが記述されていました。 このすべてのコードを破棄し、Dapr の pub/sub API とコンポーネント モデルに単に置き換えることができます。これにより、2 つだけでなく、より広い範囲の pub/sub ブローカーが提供されるようになりました。 作り直された eShop アプリケーションで使用されている Dapr のアクター モデルにより、実行時間が長く、ステートフルなイベント ドリブン型のワークフロー アプリケーションを簡単に構築でき、コンカレンシーとマルチスレッド処理のすべての問題が解消されることが示されています。 この記事を最後まで読むと、Dapr によってアプリケーションの開発が劇的に簡素化されることがわかります。私は、クラウド ネイティブ アプリの構築に着手するすべての開発者は、Dapr を使用する必要があるものと確信しています。
2019 年 10 月に Dapr v0.1 のリリースが発表されましたが、それから 1 年半経ち、運用環境で使用できる状態の Dapr v1.0 をリリースできることを嬉しく思います。 Dapr が v1.0 になったのは、ひとえにコミュニティの作業のおかげです。 Dapr に関するオープンソース コミュニティの連帯は驚くべきもので、共同作成者は最初に発表された 2019 年 10 月の 114 人から、2021 年初めには 700 人へと、16 か月の間に 6 倍に増加しています。 プロジェクトへの貢献はすべての Dapr リポジトリに及んでおり、問題の提起、機能の提案へのコメント、サンプルの提供、そしてもちろんコードの投稿などの広範囲のものです。 コミュニティのメンバーによる貢献が最も多かったプロジェクトの部分は、Dapr ランタイム、ドキュメント、CLI、SDK、およびコンポーネントの豊富なエコシステムの作成などです。 このオープン性を維持することは、Dapr の未来にとって重要です。
ただし、Dapr はまだ始まったばかりであり、Dapr の機能がさらに増え、Azure サービスで Dapr がさらにサポートされるようになることを、皆さんも期待しているはずです。 私も、皆さんが Dapr を利用することで、中核となるビジネス ロジックに集中し、マイクロサービス開発を促進できることを望んでいます。 https://github.com/dapr/ と Discord https://aka.ms/dapr-discord で、皆さんが Dapr コミュニティによるこの体験に参加することを期待しています。
最新の分散システムは複雑です。 最初は、小規模で疎結合の独立してデプロイ可能なサービスから始めます。 これらのサービスは、プロセスとサーバーの境界を越えるものです。 その後、さまざまな種類のインフラストラクチャ バッキング サービス (データベース、メッセージ ブローカー、キー コンテナー) を使用します。 最後に、これらのばらばらの部分をまとめてアプリケーションを形成します。
Mark RussinovichAzure CTO 兼テクニカル フェローMicrosoft