Microsoft Orleans

  • [アーティクル]

Orleans は、堅牢でスケーラブルな分散アプリケーションを構築するためのクロスプラットフォーム フレームワークです。 分散アプリケーションとは、複数のプロセスにまたがるアプリケーションとして定義され、多くの場合、ピアツーピア通信を使ってハードウェアの境界を越えるものです。 Orleans では、単一のオンプレミス サーバーから、クラウド内の数百から数千の分散された高可用性アプリケーションにスケーリングします。 Orleans は、使い慣れた概念と C# のイディオムをマルチサーバー環境に拡張します。 Orleans は、弾力的にスケーリングするように設計されています。 ホストがクラスターに参加すると、新しいアクティブ化を受け入れられます。 スケールダウンするかマシンの故障が原因でホストがクラスターから離れると、そのホストの以前のアクティブ化は、必要に応じて残りのホストで再アクティブ化されます。 Orleans クラスターは、1 つのホストにスケールダウンすることができます。 弾力性のあるスケーラビリティを有効にするのと同じプロパティを使用すると、フォールト トレランスも有効になります。 クラスターは自動的に検出され、失敗から迅速に回復します。

Orleans の主要な設計目標の 1 つは、共通のパターンと API のセットを提供することで、複雑な分散アプリケーションの開発を簡素化することです。 シングルサーバー アプリケーションの開発に慣れている開発者は、Orleans を使うと、回復性とスケーラビリティを備えたクラウドネイティブ サービスやその他の分散アプリケーションの構築に容易に移行できます。 このため、Orleans はよく "分散 .NET" と呼ばれ、クラウドネイティブ アプリをビルドするときに選ばれるフレームワークとなっています。 Orleans は .NET がサポートされている場所ならどこでも実行できます。 これには、Linux、Windows、macOS でのホスティングが含まれます。 Orleans アプリは、Kubernetes、仮想マシン、Azure App Service や Azure Container Apps などの PaaS サービスにデプロイできます。

"アクター モデル"

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

注意

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

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

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

グレインとは

グレインは、いくつかある Orleans プリミティブの 1 つです。 アクター モデルの観点から見れば、グレインは仮想的なアクターです。 Orleans アプリケーションの基本的な構成要素が "グレイン" です。 グレインは、ユーザー定義の ID、動作、および状態で構成されるエンティティです。 次のようなグレインの視覚化された表現を考えてみます。

グレインは、安定した ID、動作、状態で構成されます。

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

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

Orleans グレインのマネージド ライフサイクル。

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

サイロとは

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

通常、サイロのグループは、スケーラビリティとフォールト トレランスのためにクラスターとして実行されます。 クラスターとして実行する場合、サイロは互いに連携して作業を分散し、失敗を検出して復旧します。 ランタイムにより、クラスターでホストされているグレインは、1 つのプロセス内にあるかのように相互に通信できます。 クラスター、サイロ、グレインの関係を視覚化するために、次の図を考えてみます。

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

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

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

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

Orleans でできること

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

永続化

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

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

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

タイマーとアラーム

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

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

柔軟なグレイン配置

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

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

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

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

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

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

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

ステートレス ワーカー

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

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

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

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

要求コンテキスト

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

分散 ACID トランザクション

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

トランザクションの詳細情報については、トランザクションに関するページを参照してください。

ストリーム

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

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

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

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

Orleans ビデオの概要

Orleans の概要のビデオに関心をお持ちの場合は、次のビデオをご覧ください。

次の手順

チュートリアル: 最低限の Orleans アプリケーションを作成する