次の方法で共有


Microsoft Orleans

Orleans:

  • 堅牢でスケーラブルな分散アプリを構築するためのクロスプラットフォーム フレームワークです。 分散アプリは、1 つ以上のプロセスにまたがるアプリとして定義されます。多くの場合、ピアツーピア通信を使用してハードウェアの境界を超えています。
  • 単一のオンプレミス サーバーから、クラウド内の数千もの分散型の高可用性アプリにスケーリングします。
  • 使い慣れた概念と C# のイディオムをマルチサーバー環境に拡張します。
  • 弾力的にスケーリングするように設計されています。 ホストがクラスターに参加すると、新しいアクティブ化を受け入れます。 ホストがクラスターを離れると、そのホストでの以前のアクティブ化は、必要に応じて残りのホストで再アクティブ化されます。 ホストは、スケール ダウンまたはマシンの障害が原因でクラスターから離れる可能性があります。 Orleans クラスターは、1 つのホストにスケールダウンできます。 エラスティック スケーラビリティを有効にするのと同じプロパティにより、フォールト トレランスが有効になります。 クラスターは自動的に検出し、障害から迅速に復旧します。
  • 共通のパターンと API のセットを提供することで、分散アプリ開発の複雑さを簡素化します。
  • シングルサーバー アプリの開発に慣れている開発者は、回復力のあるスケーラブルなクラウドネイティブ サービスと分散アプリの構築に移行できます。
  • "Distributed .NET" と呼ばれることもあります。
  • クラウドネイティブ アプリを構築する際に選択するフレームワークです。
  • .NET がサポートされている任意の場所で実行されます。 これには、Linux、Windows、macOS でのホスティングが含まれます。
  • アプリは、Kubernetes、仮想マシン、PaaS サービス (Azure App Service や Azure Container Apps など) にデプロイできます。

「アクターモデル」

Orleans は、"アクター モデル" に基づいています。 アクター モデルは 1970 年代初頭に生まれ、現在は Orleansの中核となるコンポーネントです。 アクター モデルは、各 アクター が、状態と対応する動作の一部をカプセル化する軽量で同時に不変のオブジェクトであるプログラミング モデルです。 アクターは、非同期メッセージを使用して互いに排他的に通信します。 Orleans 特に、アクターが永続的に存在する Virtual Actor 抽象化を発明しました。

手記

アクターは、仮想的に常に存在する、純粋な論理エンティティです。 アクターを明示的に作成したり破棄したりすることはできません。また、その仮想の存在は、アクターを実行するサーバーの障害の影響を受けません。 アクターは常に存在するため、常にアドレス指定可能です。

これは、クラウド時代の新しい世代の分散アプリを構築するための新しいアプローチです。 Orleans プログラミング モデルは、機能を制限したり、開発者に制約を課したりすることなく、高度に並列分散されたアプリ に固有の複雑さを軽減します。

詳細については、「Orleans: Microsoft Research を使用した仮想アクターの」を参照してください。 仮想アクターは、Orleans グレインとして表されます。

グレインとは

粒度は、いくつかの Orleans プリミティブの 1 つです。 アクター モデルに関しては、グレインは仮想アクターです。 任意の Orleans アプリケーションにおける基本的な構成要素は グレインです。 グレインは、ユーザー定義の ID、動作、および状態で構成されるエンティティです。 グレインの次の視覚的表現について考えてみましょう。

粒度は、安定した ID、動作、状態で構成されます。

グレイン ID は、グレインを常に呼び出しに使用できるようにするユーザー定義キーです。 グレインは、他のグレインまたは任意の数の外部クライアントによって呼び出すことができます。 各グレインは、次のインターフェイスの 1 つ以上を実装するクラスのインスタンスです。

グレインには、任意のストレージ システムに格納できる揮発性または永続的な状態データを含めることができます。 そのため、グレインはアプリケーションの状態を暗黙的にパーティション分割し、自動スケーラビリティを実現し、障害からの復旧を簡略化します。 グレインの状態は、グレインがアクティブな間はメモリに保持され、待機時間が短くなり、データ ストアの負荷が軽減されます。

Orleans 粒度の管理されたライフサイクル。

粒度のインスタンス化は、 Orleans ランタイムによって必要に応じて自動的に実行されます。 しばらく使用されていないグレインは、リソースを解放するためにメモリから自動的に削除されます。 これは、安定した ID が原因で可能です。これにより、既にメモリに読み込まれているかどうかにかかわらず、グレインを呼び出すことができます。 これにより、呼び出し元は、どの時点でグレインがインスタンス化されているかをサーバーで認識する必要がないため、障害からの透過的な復旧も可能になります。 グレインにはマネージド ライフサイクルがあり、Orleans ランタイムは、必要に応じてグレインのアクティブ化/非アクティブ化と配置/配置を行います。 これにより、開発者はすべてのグレインが常にメモリ内にあるかのようにコードを記述できます。

サイロとは

サイロは、Orleans プリミティブのもう 1 つの例です。 サイロは、1 つ以上のグレインをホストします。 Orleans ランタイムは、アプリケーションのプログラミング モデルを実装します。

通常、複数のサイロは、スケーラビリティと耐障害性のためにクラスターとして実行されます。 クラスターとして実行すると、サイロは互いに連携して作業を分散し、障害を検出して復旧します。 ランタイムを使用すると、クラスターでホストされているグレインは、単一のプロセス内にあるかのように相互に通信できます。 クラスター、サイロ、およびグレイン間の関係を視覚化するには、次の図を検討してください。

クラスターには 1 つ以上のサイロがあり、サイロには 1 つ以上のグレインがあります。

上の図は、クラスター、サイロ、およびグレイン間の関係を示しています。 任意の数のクラスターを使用でき、各クラスターには 1 つ以上のサイロがあり、各サイロには 1 つ以上のグレインがあります。

サイロは、コア プログラミング モデルに加えて、タイマー、アラーム (永続的タイマー)、永続化、トランザクション、ストリームなどの一連のランタイム サービスをグレインに提供します。 詳細については、「Orleansでできること」を参照してください。.

Web アプリやその他の外部クライアントは、ネットワーク通信を自動的に管理するクライアント ライブラリを使用して、クラスター内のグレインを呼び出します。 クライアントは、シンプルにするためにサイロを使用して同じプロセスで共同ホストすることもできます。

Orleansでできること

Orleans はクラウドネイティブ アプリを構築するためのフレームワークであり、最終的にスケーリングが必要になる .NET アプリをビルドするときは常に考慮する必要があります。 Orleansを使用するには、一見無限の方法がありますが、最も一般的な方法は次のとおりです。ゲーム、銀行、チャット アプリ、GPS 追跡、株式取引、ショッピング カート、投票アプリなど。 Orleans は、Azure、Xbox、Skype、Halo、PlayFab、Gears of War、およびその他の多くの内部サービスで Microsoft によって使用されます。 Orleans には、さまざまなアプリケーションに簡単に使用できる多くの機能があります。

固執

Orleans は、要求を処理する前に状態が使用可能であり、一貫性が維持されるようにする単純な永続化モデルを提供します。 グレインには、複数の名前付き永続データ オブジェクトを含めることができます。 たとえば、ユーザーのプロファイルには "profile" と呼ばれ、インベントリには "inventory" と呼ばれるものがあります。 この状態は、任意のストレージ システムに格納できます。

グレインの実行中、状態はメモリ内に保持されるため、ストレージにアクセスせずに読み取り要求を処理できます。 グレインが状態を更新すると、IStorage.WriteStateAsync を呼び出すと、持続性と一貫性のためにバッキング ストアが確実に更新されます。

詳細については、「グレイン永続化 」を参照してください。

タイマーとアラーム

アラームは、グレインの永続的なスケジューリング メカニズムです。 これらは、その時点でグレインが現在アクティブ化されていない場合でも、将来の時点で何らかのアクションが完了するようにするために使用できます。 タイマーは、アラームに対応する非永続的なイベントであり、信頼性を必要としない頻度の高いイベントに使用できます。

詳細については、「タイマーとリマインダー」を参照してください。

柔軟なグレイン配置

Orleansでグレインがアクティブ化されると、ランタイムは、そのグレインをアクティブ化するサーバー (サイロ) を決定します。 これは粒子配置と呼ばれます。

Orleans の配置プロセスは完全に構成可能です。 開発者は、ランダム、ローカル優先、負荷ベースなどの一連のすぐに使用できる配置ポリシーから選択するか、カスタムロジックを構成できます。 これにより、グレインを作成する場所を柔軟に決定できます。 たとえば、グレインは、運用する必要があるリソースや通信に使用するその他のグレインに近いサーバーに配置できます。

詳細については、「グレイン配置」を参照してください。

グレイン バージョン管理と異種クラスター

変更を安全に考慮する方法で運用システムをアップグレードすることは、特にステートフル システムでは困難な場合があります。 これを考慮するために、Orleans のグレイン インターフェイスをバージョン管理できます。

クラスターでは、クラスター内のどのサイロに対して使用可能なグレイン実装と、それらの実装のバージョンのマッピングが維持されます。 このバージョンの情報は、グレインへの呼び出しをルーティングするときに配置の決定を行うために、配置戦略と組み合わせてランタイムによって使用されます。 さらに、バージョン管理されたグレインを安全に更新するために、異なるサイロで使用できるグレイン実装のセットが異なる異種クラスターも可能になります。

詳細については、「グレインのバージョン管理」を参照してください。

ステートレス ワーカー

ステートレス ワーカーは、状態が関連付けられていない特別にマークされたグレインであり、複数のサイロで同時にアクティブ化できます。 これにより、ステートレス関数の並列処理が向上します。

詳細については、「ステートレス ワーカー グレイン」を参照してください。

グレイン呼び出しフィルター

グレイン呼び出しフィルター は、多くのグレインに共通するロジックです。 Orleans では、着信呼び出しと発信呼び出しの両方のフィルターがサポートされます。 承認、ログ記録、テレメトリ、エラー処理のフィルターはすべて一般的と見なされます。

要求コンテキスト

メタデータやその他の情報は、要求コンテキストを使用して、一連の要求と共に渡すことができます。 要求コンテキストは、分散トレース情報またはその他のユーザー定義値を保持するために使用できます。

分散 ACID トランザクション

前述の単純な永続化モデルに加えて、グレインは トランザクション状態を持つことができます。 複数のグレインは、状態が最終的に格納される場所に関係なく、ACID トランザクションに一緒に参加できます。 Orleans 内のトランザクションは分散化されており (中央トランザクションマネージャーまたはトランザクションコーディネーターはありません)、シリアル化可能な分離

トランザクションに関する詳細については、「トランザクション」を参照してください。

ストリーム

ストリームは、開発者が一連のデータ項目をほぼリアルタイムで処理するのに役立ちます。 Orleans ストリームは マネージドで、粒度またはクライアントがストリームを発行またはサブスクライブする前に、ストリームを作成または登録する必要はありません。 これにより、ストリーム プロデューサーとコンシューマーを互いに分離し、インフラストラクチャを切り離すことができます。

ストリーム処理は信頼性が高いです。グレインは、チェックポイント (カーソル) を格納し、アクティブ化中またはその後の任意の時点で、保存されたチェックポイントにリセットできます。 ストリームでは、効率と回復のパフォーマンスを向上させるために、コンシューマーへのメッセージのバッチ配信がサポートされます。

ストリームは、Azure Event Hubs、Amazon Kinesis などのキューサービスによってサポートされます。

任意の数のストリームを少数のキューに多重化でき、これらのキューを処理する責任はクラスター全体で均等に分散されます。

Orleans ビデオの概要

Orleansのビデオの概要に興味がある場合は、次のビデオをご覧ください。

次の手順