Web App
フロントエンドにアクセスできて、サイロ01、サイロ02にアクセスできなければデプロイ成功です。
| フロントエンド | パブリックアクセス可 |  |
| サイロ01 | パブリックアクセス不可 |  |
| サイロ02 | パブリックアクセス不可 | |
Azure Table
サイロ01、サイロ02のインスタンスのステータスが Active になっていればデプロイ成功です。
ARM版 Visual Studio 2022 Preview でついに MAUI がサポート
ARM版 Visual Studio 2022 Preview 17.6.0 Preview 1.0 でついに MAUI がサポートされました！
詳細は後日レポート予定です。
Orleans の概要と基本構成のデプロイまで（目次）
目次
- 目次
- Orleans は何を解決するために生まれ、どのようなフレームワークなのか
- Orleans の 構成と重要なプリミティブ（構成要素）
- Orleans の構成要素：フロントエンド
- Orleans の構成要素：グレイン
- Orleans の構成要素：サイロ
- Orleans の基本的な構成を App Service にデプロイする（1）構成の確認
- Orleans の基本的な構成を App Service にデプロイする（2）VNet の設定
- Orleans の基本的な構成を App Service にデプロイする（3）App Service の プライベートポート
- Orleans の基本的な構成を App Service にデプロイする（4）動作確認
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 のメリット
古典的なWebアプリの問題点
- 読み取り要求のたびにデータベースにアクセスするため、 データベースの負荷が大きい
- アプリのインスタンスの状態をお互いが把握できず、データベースへの書き込み競合が発生する
- 各々のアプリのインスタンスが状態を個別に持ちリソースの効率が悪い。
対策としてキャッシュ、キューなどを追加するも新たな問題が
- 読み取り要求のデータベース負荷対策としてキャッシュを追加。代わりに、キャッシュの一貫性の問題が発生
- データベースへの書き込み競合対策としてキューを追加。代わりに、非同期書き込みの待ちが発生
問題は軽減しているが、インフラを追加して厄介ごとをオフロードしているだけなので根本的な解決ではない…
スケーラビリティも確保できていない
根本解決のためのアプローチ（Orleans のコンセプト）
- アプリインスタンスがお互いに会話し互いに連携することで分散アプリの問題を解決する
- データベースを唯一の「真実のソース」とし、キャッシュやキューなどの余計なインフラ自体をなくす
これによって
- 高スループット
- 低レイテンシー
- 高スケーラビリティ
が確保できることをねらって開発されました。
結局 Orleans とは
Orleans は、アプリケーションのフロントエンド と永続化ストレージ（DBなど）の間のステートフルでスマートな中間層を提供するフレームワークです。
Orleans のメリット
- DB への書き込み競合の考慮が不要
- キャッシュ不要
- Appインスタンス間の一貫性考慮が不要
- Appインスタンスを追加すれば自動でクラスターが構成される
分散アプリケーションを開発するときに発生するいろいろな面倒なことについて、
いい感じで面倒を見てくれるので、メリットだけを享受することができます。
Teams など超大規模サービスでの実績もある安定したフレームワークです
次の記事はこちらです。
hiro128.hatenablog.jp
Orleans の基本的な構成を App Service にデプロイする（1）構成の確認
方針
Orleans の基本的な構成のデプロイを App Service にデプロイしてみましょう。
基本的な方針を以下の通りとします
- フロントエンドのみパブリックアクセス可能
- 2つのサイロとストレージはプライベートアクセスのみ可能とする
- プライベートアクセスはリージョン VNet 統合とプライベートエンドポイントで実現する
実際の構成は以下のようになります。
それぞれのリソースが Orleans のどの構成要素に相当するか分かりやすくするため概念図との対比にしました。
構成
| 役割 | リソース | パブリック アクセスの受信 |
プライベート アクセスの受信 |
プライベート エンドポイント |
リージョン VNet 統合 |
WebSocket |
| フロントエンド | App Service | ○ | X | X | ○ | ○（ポート数：2） |
| サイロ01 | App Service | X | ○ | ○ | ○ | ○（ポート数：2） |
| サイロ02 | App Service | X | ○ | ○ | ○ | ○（ポート数：2） |
| 永続化ストレージ | Table Storage | X | ○ | ○ | ーーー | ーーー |
次の記事はこちらです。
hiro128.hatenablog.jp