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

クラウドネイティブなシステムの理想形の一つは、オンプレミスのプラットフォームであったとしてもAWSやMicrosoft Azure、GCPのように柔軟でスケールアウト可能なインフラストラクチャーの上に分散型のアプリケーションが稼働することだ。

しかし実際には仮想マシンからコンテナベースのインフラストラクチャーに移行し、アプリケーションの実行単位がコンテナになったとしても、アプリケーション自体が分散型になることはそれほど進んでいない。これはモノリシックなアプリケーションを分散型にリアーキテクチャーすることの難しさの現れであろう。また新規のアプリケーションにおいても、デジタルトランスフォーメーション（DX）を促すベンダーサイドの掛け声の割には導入が進んでいないというのが現実だろう。

このような状況の一因として、クラウドネイティブなシステムの主要なプラットフォームであるKubernetesがアプリケーションデベロッパーにとっては未知のプラットフォームであることが挙げられる。そのために、クラウドネイティブなシステム上にアプリケーションを実装するための知見が不足しているのだ。

日本国内でKubernetesの先進的な導入を行っているユーザーでも、アプリケーション開発と本番環境であるKubernetesへの実装は分離されてはいるものの、デベロッパーがKubernetesを理解してワークロードの分解から開発までを行い、運用管理はインフラストラクチャー側に任せるというパターンではデベロッパー側の負担が大きいというのが実際だろう。

企業によってはデベロッパーへの負担を下げるために、素のままのKubernetesを提供するのではなく、使い方に制限があったとしてもテンプレートに従った運用が可能なように「Kubernetes as a Service」的なサービスを提供する場合も見受けられる。

また分散型アプリケーションでは、モノリシックなシステムに比べてサービスディスカバリーやリトライの仕組みからモニタリングまで、デベロッパーが注意を払う必要があるパーツが多過ぎるのも難点だ。

この「Kubernetesはデベロッパーの負担が大きい」という状態を打破するために、Microsoftが新たなオープンソースソフトウェアを提案した。今回は2019年11月5日に行われたMicrosoftの開発者向けカンファレンスであるIgnite 2019で行われたセッション、「Future of Cloud Native Applications with OAM and dapr」を紹介したい。これはAzureのCTOであるMark Russinovich氏が行ったもので、Open Application Model（OAM）とそのKubernetes上の実装例であるRudr、そして分散型アプリケーションのランタイムであるDaprが詳細に解説された。

セッションを行うMark Russinovich氏

動画：Mark Russinovich Presents the Future of Cloud Native Applications with OAM and dapr

整理をするとOpen Application Modelはスペック、Daprは分散型アプリケーションのためのランタイムということになる。Open Application Modelのポイントは、Kubernetesの反省点から多くの発想を得ていると思われるところが興味深い。そのためにRussinovich氏が使ったスライドでは「Kubernetesはコンテナインフラストラクチャーであり、アプリケーションのためのものではない」「アプリケーションデベロッパーはKubernetesのAPIの専門家になる必要がある」などのコメントを紹介し、Kubernetesがインフラストラクチャーの視点に立っていることを強調した。

Kubernetesは運用側のツールであるという見方を紹介

その上で、Open Application Modelはプラットフォームに依存しない仕様であることを解説した。このプラットフォームに依存しないというのは、その対象がパブリッククラウドからRaspberry Piのようなエッジ環境まで含むことを意味している。そのためには「エッジ側でKubernetesが動かないようなハードウェアにおいても実装可能である」というのがポイントだろう。つまりOAMはKubernetesがデフォルトではないし、モノリシックなアプリケーションであっても組み込むことができると解説した。

Open Application Modelの概要

このスライドの最初のポイントには、Open Application Modelがアプリケーションに特化したスペックであることに合わせて、デベロッパーとアプリケーションのためのものでコンテナインフラストラクチャー、つまりKubernetesのためのものではないことが明記されている。

そしてアプリケーションデベロッパーはあくまでもサービスの開発に集中するべきで、「それが実際のコンテナインフラストラクチャーにどのように実装されるか？」に関する責任からは分離しようというのがOpen Application Modelのポイントだ。

特にこれまでのアプリケーションデベロッパー、インフラストラクチャーオペレーターという役割の他にアプリケーションオペレーターという役割を設定したことに注目したい。これはKubernetesの上でのアプリケーション開発が、デベロッパーに不要な苦労を強いているという冒頭のコメントを受けた解決策ということになる。つまりデベロッパーはビジネスロジックに集中すべきで、ロードバランサーやスケールアウトの実装方法などの作業は切り分けて、別の担当者、つまりアプリケーションオペレーターに担当させるという内容だ。

各役割とその担当すべき仕事の内容

ここではアプリケーションオペレーターが受け持つ領域として、トラフィックマネージメント、デプロイメントの方法（カナリア、A/Bテスト、ブルー／グリーン）、オートスケーリングの要否、認証などが挙げられている。これまでは、これらの項目はアプリケーションのマイクロサービス化の延長線上にあるタスクとして、デベロッパーとインフラストラクチャーオペレーターの中間に存在するグレーゾーンとでも言える領域だった。それを敢えてどちらかの役割として付与するのではなく、新たな役割を作ったことが、Russinovich氏の主張のポイントだ。これにより、デベロッパーはコードに集中し、インフラストラクチャーオペレーターは運用に集中するということが可能になるというわけだ。

しかも単にプラットフォームに依存しないというだけではなくクラウドからエッジデバイスまで視野に入れた内容になっていることに注目したい。

クラウドからIoTデバイスまでをカバーするOAM

そしてアプリケーションデベロッパー、アプリケーションオペレーター、インフラストラクチャーオペレーターの3つの役割を、アーキテクチャー図にマップしたのが次のスライドだ。

アプリケーションオペレーターという役割の登場

ここでアプリケーションデベロッパーはコードを書くこととコンテナ化に集中し、トラフィック管理などはアプリケーションオペレーターに任せていることがわかる。アプリケーションの構成を設定した上で、実装の特性を設定したアプリケーションオペレーターは、「具体的に何を使って実装するのか？」はインフラストラクチャーオペレーターに任せるという流れだ。

例えば、ECサイトなどのWebサイトのフロントエンドとデータベースのバックエンドが接続されたアプリケーションの場合、大量のトラフィックを捌くロードバランサーが必要という判断はアプリケーションオペレーターが下し、その意向を受けてどのロードバランサーを使うのか？　はインフラストラクチャーオペレーターが選択するという形になるわけだ。

そしてこれら3つの役割が実際にどうやってコードとして設定をするのか？　について解説した。

アプリケーションオペレーターが設定する例

Open Application Modelが単に仕事を分割しただけで終わらないのは、ここからプログラミングモデルの解説に移ったことからもわかる。特に分散型システムへの適用を推奨することを象徴するように、ファンクションモデル、つまりサーバーレスとゲーム開発などで利用されるアクターモデルへの適用を解説した。

ここではファンクションを記述することが実際にはプログラミング言語にロックインされてしまうというリスクを解説。つまりプログラミングの段階でファンクションを定義できたとしても、それが記述されるプログラミング言語に限定されてしまうという問題、そして別のプログラミング言語とそのSDKがお互いに呼び出すことが難しいという問題を解決するために開発したのがDaprであるとして、ここからDaprの解説に移った。

注目したいのは「ここにRustを使っている人はいる？　Rustはメモリーセーフなシステムプログラミング言語だけど、Rustだけで分散型のアクターモデルを作ることは今のところできないよね。でもそれを可能にするのがDaprだ」とコメントしたことだ。AzureのCTOがRustに注目していることを垣間見せながら、Daprの紹介に移った。

Daprの概要

ここでDaprは分散型でファンクションモデル、アクターモデル双方のプログラミングモデルの実装を行うランタイムであることが紹介された。

さまざまな言語と接続できるのがDaprのポイント

特に重要なのは、ビルディングブロックとしてこれから多くのサービスがプラグインできるというアーキテクチャーであること、そしてクラウドからエッジまでカバーすることだろう。サービス間通信のPub/Subや分散型のトレーシング、読み込みや書き込みのリソースを定義するリソースバインディングなど、マイクロサービスを構成する際に必要となる機能がすでに盛り込まれていることがわかる。

マイクロサービスに求められる機能を実装

そしてここからは、Daprのステート管理、リソースバインディングを見せるデモを行った。これはPythonで書かれた300桁の円周率を求めるコードをDaprでマイクロサービス化したものだ。元のプログラムは300桁の円周率を求めるだけのコードだが、それをDapr化することにより、途中で処理を中断しても、次回の実行時に継続するようにRedisにステータスの書き込みを行うこと、最終的に求められた値をCosmos DBに書き込むという変更をVisual Studio Codeで実際に行ってみせた。

Pythonコードを修正してデモを実行

そして他にもデモとしてサービスの起動や発見、メッセージのルーティングなどマイクロサービスとして構成される際にデベロッパーがこれまでは面倒を見なければいけなかったパーツを、Daprが受け持ってくれるということを実証してみせた。

さらに最後に行ったデモでは、Daprが拡張できるということを示すために、自動搬送ロボットを制御するシステムにDaprを組み込んで、画像認識のマイクロサービスをその場で追加するところをみせた。

このセッションではOpen Application Modelとそれを実現するDaprだけを紹介したが、別のセッションではOpen Application ModelのKubernetes版の実装であるRudrが紹介された。

動画：The Future of Cloud Native Applications with Open Application Model and Dapr

Russinovich氏の個人アカウントのYouTubeチャネルに公開されたこの動画では、Open Application ModelをKubernetesのCRDを使って実装したのが、Rudrであるとして紹介された。

OAMのKubernetesでの実装がRudr

またOpen Application Modelはスペックで実装とは別であることを強調するために例として、Alibaba Cloudでの実装、EDAS（Enterprise Distributed Application Service）が紹介された。

Alibaba Cloudが既にOpen Application Modelを実装している

ここまでの内容を見ると、デベロッパーが分散型のアプリケーションを実装する際の困難であるKubernetesの難しさを排除するために、MicrosoftはOpen Application ModelとDaprを開発して公開し、それを推進したいという狙いが見える。

単にマイクロサービスとしてアプリケーションを実装できるだけではなく、サーバーレスやアクターモデルまでもパターンとして実現できるという部分は、インフラストラクチャー側にシフトしたKubernetesでは難しい部分だ。

しかしKubernetesも無視するわけにはいかないということで、Open Application Modelの実装例としてRudrを作ったということだろう。実際には「DaprがあればKubernetesは要らない」と言いたいが、まだそう言い切るにはタイミングが早いというのが本音ではないだろうか。

GitHub上での多くのスターを獲得して急速に認知を拡げているOpen Application ModelとDaprだが、実質的にKubernetesをリプレースするためにはAWSやKubernetesのベースを作ったGoogleからの賛同が必要だろう。中国最大のクラウドプロバイダーであるAlibaba Cloudからの賛同は力強い後押しになるだろうが、すでに拡大しているKubernetesのエコシステムの中でどのようなポジションを取れるのか、DaprとOpen Application Modelのこれからに注目していきたい。