Virtual Actors
j5ik2oVirutal Actorsはアクターの物理的に位置を固定化しないで、アクターの存在を仮想的に扱う考え方であり、Orleansというツールで考案されたらしい。Orleansプログラミングモデルの一つとなっている。
High-scale interactive services demand high throughput with low latency and high availability, difficult goals to meet with the traditional stateless 3-tier architecture. The actor model makes it natural to build a stateful middle tier and achieve the required performance. However, the popular actor model platforms still pass many distributed systems problems to the developers. The Orleans programming model introduces the novel abstraction of virtual actors that solves a number of the complex distributed systems problems, such as reliability and distributed resource management, liberating the developers from dealing with those concerns. At the same time, the Orleans runtime enables applications to attain high performance, reliability and scalability. This paper presents the design principles behind Orleans and demonstrates how Orleans achieves a simple programming model that meets these goals. We describe how Orleans simplified the development of several scalable production applications on Windows Azure, and report on the performance of those production systems.
大規模なインタラクティブ・サービスでは、高スループット、低レイテンシー、高可用性が求められますが、従来のステートレスな3層アーキテクチャではこれらの要求を満たすことは困難でした。
アクターモデルでは、ステートフルな中間層を構築し、要求されるパフォーマンスを実現することが自然にできます。しかし、一般的なアクターモデルのプラットフォームは、未だに多くの分散システムの問題を開発者に渡しています。
Orleansプログラミングモデルは、信頼性や分散リソース管理などの複雑な分散システムの問題の多くを解決する仮想アクターの新しい抽象化を導入し、開発者をこれらの問題への対処から解放します。同時に、Orleansランタイムは、アプリケーションの高性能、信頼性、スケーラビリティを実現します。
本論文では、Orleansの背後にある設計原理を提示し、Orleansがどのようにしてこれらの目標を満たすシンプルなプログラミングモデルを実現するかを示す。また、Windows Azure上のいくつかのスケーラブルな本番アプリケーションの開発をOrleansによってどのように簡略化したかを説明し、それらの本番システムのパフォーマンスについて報告します。
論文
Virtual Actorsの実装
.NET
Java
Go
Proto.Actor’s clustering mechanism borrows the idea of “virtual actor” from Microsoft Orleans, where developers are not obligated to handle an actor’s lifecycle.
Proto.Actor のクラスタリング機構は、Microsoft Orleans の「仮想アクタ」のアイデアを採用しており、開発者はアクタのライフサイクルを処理する義務はありません。
If the destination actor is not yet spawned when the first message is sent, proto.actor spawns one and lets this newborn actor handle the message; if the actor is already present, the existing actor simply receives the incoming message.
最初のメッセージ送信時に送信先のアクタがまだ生成されていない場合、proto.actor はアクタを生成し、この新生アクタにメッセージを処理させます。アクタがすでに存在する場合、既存のアクタは単に受信メッセージを受け取ります。
From message sender’s point of view, the destination actor is always guaranteed to “exist” This is highly practical and works well with the clustering mechanism.
メッセージ送信者の視点から見ると、送信先のアクターは常に「存在する」ことが保証されています。これは非常に実用的で、クラスタリング・メカニズムとうまく機能します。
An actor’s hosting member may crash at any moment, and the messages to that actor may be redirected to a new hosting member. If a developer must be aware of the actor’s lifecycle, a developer is obligated to be aware of such topology change to re-spawn the failing actor. The concept of virtual actor hides such complexity and eases the interaction.
あるアクタのホスティング・メンバーがいつクラッシュするかわからないので、そのアクタへのメッセージは新しいホスティング・メンバーにリダイレクトされるかもしれません。開発者がアクターのライフサイクルを意識しなければならない場合、開発者はそのようなトポロジーの変更を意識して、故障したアクターを再起動させる義務があります。バーチャルアクターという概念は、そのような複雑さを隠し、相互作用を容易にします。