マイクロサービスが主流となる中、マイクロサービス向けに開発された「Dapr」が、プラットフォームエンジニアにとって魅力的なものとなっている。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
アプリケーションの構築手法として注目が集まっていたマイクロサービスも、必ずしも全てのアプリケーションやAPIに適切なわけではないことが認められつつある。
マイクロサービスという用語が登場したのは2011年のことだ。マイクロサービスとは、アプリケーションをモジュール形式の小さなサービスごとに分割し、連携させるアーキテクチャを表す。
2016年には、マイクロサービスを早期導入した企業(Netflixなど)がマイクロサービスの概念を取り込んだマイクロサービスオーケストレーションフレームワーク「Conductor」をオープンソース化した。同年には、Pivotal LabsがJavaベースのマイクロサービスフレームワーク「Spring Cloud Stream」のバージョン1.0を公開。2018年後半には、IDCが2022年までには全てのエンタープライズアプリケーションの90%がマイクロサービスを備えるとの予測を発表した。
だが、その後すぐ、コストと複雑さからマイクロサービスは混迷期を迎える。Gartnerが2021年に実施したメディア分析によると、2019年から2020年にかけて、マイクロサービスアーキテクチャを扱った記事は42%減少したという。
RedMonkの創設者でアナリストも兼務するスティーブン・オグレディ氏は「業界ではマイクロサービスに関して2つの大きなトレンドがある。1つは、マイクロサービスがどこに適しているかを判断することだ。これまでは適切でないケースも含めてあらゆるところにマイクロサービスを適用しようとしてきた。もう1つは、マイクロサービスを構築、管理するための広範な機能を備えた統合プラットフォームが求められていることだ」と述べている。
こうした中、マイクロサービス向けに開発された「Dapr」(Distributed Application Runtime)が、プラットフォームエンジニアリング時代に重要な役割を果たすとみられつつある。
Daprとは、2019年にMicrosoftが開発したマイクロサービスフレームワークで、2021年にCNCF(Cloud Native Computing Foundation)に寄贈されたプロジェクトだ。
Daprは分散アプリケーションランタイムであり、複数のプログラミング言語で記述されたマイクロサービスアプリケーションと、そのアプリケーションの実行に必要な各種共有要素を結び付けるAPIの標準セットを提供する。
共有要素はDaprではコンポーネントと呼ばれ、「Redis」やHashiCorpの「HashiCorp Vault」などさまざまなステートストアやシークレットストア、「Apache Kafka」などのメッセージングサービス、暗号化ツールや可観測性ツールを連携できる。
Daprは、サーバレスアプリケーションや仮想マシン(VM)ベースのアプリケーションもサポートしているが、コンテナやKubernetesと併せて利用することで大きなメリットを享受できる。
「2023年には、DaprはCNCFのプロジェクトの中で11番目に大きなプロジェクトとなり、3000人を超える貢献者を擁している」と話すのは、2021年創設のスタートアップ企業でKubernetesとDapr APIのマネージドサービスをホストするDiagridの創設者兼CEOのマーク・フッセル氏だ。
「開発者が自分たちのプラットフォームに統合できるように、誰かがプラットフォームエンジニアリングAPIを構築して、開発者に提供しなければならない。その一環としてDaprのAPIを導入している企業は多い印象だ。Daprを導入することで、断片化を解消し、メッセージングの一貫性を確保して、クラウドとオンプレミスにまたがるアプリケーションを構築できる。クラウドへの移植性を確保するのにも役立つ」(フッセル氏)
DaprのAPIで抽象化レイヤーを形成することで、コードを再構築するたびに連携作業によるメンテナンスをすることなく、プラットフォームサービスを変更できるとフッセル氏は語る。
Gartnerでアナリストとして働くマット・ブレイザー氏は、.NETのエコシステムにおいて、マイクロサービスに該当するかどうかにかかわらず、分散アプリケーションと関連するインフラを管理する企業は、Daprに注目しているという。
「変化のペースが速い現代社会では、単一のモノリスは適切なアーキテクチャではないユースケースは多い。かといって、500も1000もマイクロサービスが必要なわけではなく、モノリスを3つ程度のコンポーネントに分割すれば十分という場合もある。ただ、モノリスを3つのコンポーネントに分解するとしても、300のコンポーネントに分解するとしても、Daprのようなプラットフォームが必要なことは変わらない」(ブレイザー氏)
Daprは2024年後半に「Dapr Workflow」というサービスのβ版を提供開始予定だ。Dapr Workflowは、Temporal Technologiesの「Temporal」やUber Technologiesの「Cadence」といったマイクロサービスオーケストレーションベンダーのツールと競合するが、多言語対応のマルチツールサポートを備えているという。Microsoftのパートナーアーキテクトで、Dapr Workflowの作成者でもあるクリス・ギラム氏は、「KubeCon + CloudNativeCon North America 2023」のプレゼンテーションで「ワークフローの実行を定義するには、開発するのに選択したコードをただ使用するだけでよい。ワークフローの実行にデバッガーをアタッチすると、ワークフローで何が起きているかを確認できる」と述べている。
2022年、クラウドセキュリティベンダーのZscalerは、ソフトウェアプロジェクトにDaprを採用した。Zscalerでプリンシパルソフトウェアエンジニアのジョシュ・カーライル氏は「Daprには独特な学習が必要で、Kubernetesでサイドカーパターンを使用してオープンソースバージョンのDaprをデプロイするのは特に難しい」と指摘する。
「ZScalerのソフトウェアエンジニアは、Dapr APIを使用する開発サイクルに慣れなければならなかった。具体的には、コードを実行する前にDapr CLIを起動して実行しておくことを理解する必要があった。学ぶことはそれほど重労働ではなかったが、エンジニアが新しいワークフローに慣れて開発に取り掛かるのにおそらく2〜3週間はかかった」(カーライル氏)
2023年、カーライル氏はZscalerの開発チームを率いてDaprを使用し、社内でホストするApache Kafkaメッセージングプラットフォームに、リトライやサーキットブレーカーなどのオブザーバビリティと自動修復機能を追加した。同氏が見積もった結果、開発者が初期に学習する必要があったとしても、ゼロから構築するよりもDaprを利用する方がプロジェクト完了までの時間が約4分の1から3分の1に短縮されたという。
「Apache Kafkaは優れたプラットフォームだが、運用や管理が極めて複雑だ。最終的にはApache Kafkaが最善の選択肢ではない可能性があることはおおむね分かっていた。チームはDaprを利用し、コードを抽象化した。そうしておけば、将来、Apache Kafkaを用いたパブリッシュ/サブスクライブ方式のメッセージングを別の製品、サービスに移行したとしても、プラットフォームのコードを変更する必要はない」(カーライル氏)
この開発を終えて以降、カーライル氏は社内5000人以上の従業員が使用する社内開発者プラットフォームの開発に取り組んでいる。同氏は、この取り組みにDaprを含めることを予定している。
プラットフォームチームには、開発者が運用環境への「ゴールデンパス」を構築する際に選択できる幅広いツールがある。サービスメッシュやイベント駆動型の自動化、その他のマイクロサービスオーケストレーションツールなどがその例だ。
「使用する機能の中には『サービスメッシュだけで十分だ』とエンジニアが考える機能も幾つかあった。だが、Daprならば、ネットワークレベルでサービスメッシュを使用できる。ただし、非同期呼び出しを行い、メッセージングのような同じ機能を適用したい場合はあまり適切だとはいえない。既にサービスメッシュが用意されているのなら、アンインストールする必要はない。だが、サービスメッシュのような負荷が高い作業に取り組みたくないなら、同等の機能をDaprで手に入れることができる」(カーライル氏)
カーライル氏は、Dapr Workflowが既存のマイクロサービスオーケストレーションツールの軽量の代替ツールになる可能性があるとも指摘している。
「数年前にMicrosoft Azure Functionsを使ってサーバレス関連の作業をこなしたとき、Azure Functionsには耐久性のあるタスクフレームワークがあった。Dapr Workflowの機能はそれを思い起こさせるものだ」(カーライル氏)
Copyright © ITmedia, Inc. All Rights Reserved.