個人的なメモ

Tomohiro Suzuki @hiro128_777 のブログです。Microsoft MVP for Developer Technologies 2017- 本ブログと所属組織の公式見解は関係ございません。

Orleans の概要と基本構成のデプロイまで(目次)

Orleans は何を解決するために生まれ、どのようなフレームワークなのか

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の 構成と重要なプリミティブ(構成要素)

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の構成要素:フロントエンド

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の構成要素:グレイン

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の構成要素:サイロ

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の基本的な構成を App Service にデプロイする(1)構成の確認

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の基本的な構成を App Service にデプロイする(2)VNet の設定

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の基本的な構成を App Service にデプロイする(3)App Service の プライベートポート

記事はこちらです。
hiro128.hatenablog.jp
 

Orleans の基本的な構成を App Service にデプロイする(4)動作確認

記事はこちらです。
hiro128.hatenablog.jp
 
 

Orleans の 構成と重要なプリミティブ(構成要素)

Orleans の構成

Orleans の構成は以下のようになっています。

Orleans のクラスターは1つの巨大なコンピューターのように取り扱われます。
スケールアウトやアップグレードによるインスタンス追加や、障害時のインスタンスの突然停止に対応するため、
サイロは、Container Apps、App Service、マネージド k8s などの SaaS にデプロイする前提となっています。
 
Orleans の基本的な動作は、以下の通りです。

  • REST API が定義されたエンドポイントであるフロントエンドで、HTTP リクエストを受信します
  • リクエストは適切なグレインにルーティングされグレインのメソッドが呼び出され、データがメモリ内にない場合はDBから取得し、レスポンスを返します

 
 

Orleans の重要なプリミティブ(構成要素)

Orleans の全体像を把握するために、重要な構成要素はフロントエンド、グレイン、サイロの3つです。


 

プリミティブ 概要
Frontend Orleans の世界と外部とのゲートウェイ
HTTP Request/Response と Grain Call/Response の変換を行います。
Grain フロントエンドから呼び出す際のID(identity)、業務ロジック実装(behavior)、インメモリの状態(state)で構成されるエンティティ
クラスターでホストされているグレインは、1 つのプロセス内にあるかのように相互に通信できます。
Silo グレインをホストするインスタンス
クラスターとして実行され、サイロ同士は互いに連携して作業を分散し、失敗を検出して復旧できます。

 
 
次の記事はこちらです。
hiro128.hatenablog.jp
 
 

Orleans の基本的な構成を App Service にデプロイする(2)VNet の設定

構成図

構成では、フロントエンドのみパブリックアクセス可能、2つのサイロとストレージはプライベートアクセスのみ可能としますが、プライベートアクセスはリージョン VNet 統合とプライベートエンドポイントで実現します。
そのための VNet の設定は以下のようになります。
 

アドレス空間


 

接続デバイス(プライベートエンドポイント)


 

サブネット


 
 
次の記事はこちらです。
hiro128.hatenablog.jp
 
 

Orleans は何を解決するために生まれ、どのようなフレームワークなのか

古典的なWebアプリの問題点

  • 読み取り要求のたびにデータベースにアクセスするため、 データベースの負荷が大きい
  • アプリのインスタンスの状態をお互いが把握できず、データベースへの書き込み競合が発生する
  • 各々のアプリのインスタンスが状態を個別に持ちリソースの効率が悪い。

 

 
 

対策としてキャッシュ、キューなどを追加するも新たな問題が

  • 読み取り要求のデータベース負荷対策としてキャッシュを追加。代わりに、キャッシュの一貫性の問題が発生
  • データベースへの書き込み競合対策としてキューを追加。代わりに、非同期書き込みの待ちが発生


 
問題は軽減しているが、インフラを追加して厄介ごとをオフロードしているだけなので根本的な解決ではない…
スケーラビリティも確保できていない
 
 

根本解決のためのアプローチ(Orleans のコンセプト)

  • アプリインスタンスがお互いに会話し互いに連携することで分散アプリの問題を解決する
  • データベースを唯一の「真実のソース」とし、キャッシュやキューなどの余計なインフラ自体をなくす


 
これによって

  • 高スループット
  • 低レイテンシー
  • 高スケーラビリティ

が確保できることをねらって開発されました。
 
 

結局 Orleans とは

Orleans は、アプリケーションのフロントエンド と永続化ストレージ(DBなど)の間のステートフルでスマートな中間層を提供するフレームワークです。

 

Orleans のメリット

  • DB への書き込み競合の考慮が不要
  • キャッシュ不要
  • Appインスタンス間の一貫性考慮が不要
  • Appインスタンスを追加すれば自動でクラスターが構成される

 
分散アプリケーションを開発するときに発生するいろいろな面倒なことについて、
いい感じで面倒を見てくれるので、メリットだけを享受することができます。
Teams など超大規模サービスでの実績もある安定したフレームワークです

 
 
次の記事はこちらです。
hiro128.hatenablog.jp