Azure Fluid Relay が GA されたとのことですが、個人的によく知らなかったので調べてみました。

はじめに

🤖

現代のアプリケーション開発において、リアルタイムのコラボレーション機能は非常に重要です。Fluid Framework と Azure Fluid Relay は、このニーズを満たすための強力なツールです。

Fluid Framework の概要

🤖

Fluid Framework は、Microsoft が開発したオープンソースのライブラリで、リアルタイムの共同編集とデータ同期を実現するための基盤を提供します。このフレームワークは、複数のユーザーが同時にデータを操作できるようにし、高いパフォーマンスとスケーラビリティを誇ります。Fluid Framework の最大の特徴は、データの分散管理と効率的な同期メカニズムにあります。これにより、ユーザーは一貫したデータ体験を享受できるのです。

動作やコードのサンプルについて

下記のチュートリアルページが分かりやすいと思います。

ざっくり、下記のような処理ロジックでデータ同期を実現しています。

クライアントコードによって、データがローカルにて変更される
Fluid ランタイムから Fluid サービスにその変更が送信される
Fluid サービスにて操作がシーケンス処理され、すべてのクライアントにブロードキャストされる
Fluid ランタイムにより、操作がローカルデータに組み込まれた後 "valueChanged" イベントが発生する
クライアントコード側で "valueChanged" イベントを処理する

Azure Fluid Relay について

Azure Fluid Relay は、Fluid Framework を利用したアプリケーションのためのバックエンド側をサービス (マネージドサービス) として提供するものです。

内部は AKS などの Azure サービス群

下図の通り、Azure Fluid Relay は内部で AKS (Azure Kubernetes Service) や Azure Front Door, Azure Cache for Redis, Azure Cosmos DB などを利用しているとのことです。

主な制約など

データはペアリージョン間で冗長化
リソース作成後はリージョンの変更ができず、リソースの再作成が必要
セッション単位の同時接続数は 100 ユーザーまで。用途によっては結構少ない
クライアント側でネットワーク断などの際はローカルに蓄積して後で再送は可能だが、本記事執筆時点では猶予は 1 分までと結構厳しいので、繋がらない場合にはエラー処理などをする方が無難か
課金の単位は「in / out の処理数」や「クライアント単位のコネクション時間」など。サービスの起動時間ではないところは嬉しいかも

ひと通りのチュートリアル

※上記ページだけではなく「次のステップ」へどんどん進んでいくチュートリアルです。

おわりに

最近、こういうフレームワークを実現するためのサーバー側のコンポーネントもマネージドサービス側で提供されるケースが多くなってきたなーと感じます。AKS や Azure Container Apps での Dapr 統合も近いと言えば近いかと。

まさにコードに集中するための周辺機能はできるだけ手間をかけないで済ます、ですね。

Fluid Framework を使う機会は多いとは言えないかもしれませんが、こういうのがあるんだということは覚えておこうと思います😁