Aurabaseの Rust コア: 統合されたサービスとしてのバックエンド

オープン ソースの Postgres BaaS のほとんどは、サービスを複数の言語でパッケージ化しています。これは価値判断ではありません。これは具体的な結果をもたらすアーキテクチャ上の事実です。つまり、使用されている言語と同数のコンパイル チェーン、エラー規約、認証ロジックが同期を保つ必要があります。

Aurabase では、私たちが自分たちで作成および保守する製品レイヤー (ゲートウェイ、認証、データベース、リアルタイム、ストレージ、通知、AI、プロビジョニング、アカウント管理) は、単一の Cargo ワークスペース、単一言語、単一のビルド チェーンです。これは、このファイルに記載されている選択です。

ルート Cargo.toml は、リゾルバー v2 の Cargo ワークスペース を 18 メンバー (11 のビジネス サービス、aura-cliCLI、5 つの共有ライブラリ、および aurabase-rsSDK) で宣言します。リポジトリに表示される実際のリストは次のとおりです。

[workspace]
resolver = "2"

members = [
    # サービス (11)
    "services/aura-gateway", "services/aura-auth", "services/aura-db",
    "services/aura-provisioner", "services/aura-realtime", "services/aura-storage",
    "services/aura-functions", "services/aura-notifications", "services/aura-ai",
    "services/aura-migrator", "services/aura-control",
    # ツール
    "aura-cli",
    # リブ (5)
    "libs/aura-core", "libs/aura-crypto", "libs/aura-db-adapters",
    "libs/aura-migrations", "libs/aura-telemetry",
    "aurabase-rs",
]

共有依存関係は [workspace.dependencies]に存在します: Axum 0.8 (WebSocket、マルチパート、マクロを使用)、Tokio、Tower/Tower-HTTP、SQLx 0.8 (セカンダリ NoSQL エンジンの mongodb 経由の Postgres + MongoDB)、async-nats 0.47、sqlparser 0.53 (NL2SQL の SQL 検証)、 oauth2 5、jsonwebtoken 10、およびほぼすべてのサービスにある 2 つのパフォーマンス ライブラリ (グローバル アロケーターとしての mimalloc と、メモリ内キャッシュ用の moka/dashmap)。

リリース プロファイルには、 "abort"ではなく panic = "unwind" という想定される選択が記載されています。ファイルのコメントは一目瞭然です。Axum/Tokio ハンドラーのパニックは、プロセス全体をダウンさせて競合するリクエストを遮断するのではなく、ランタイムによって分離されます (影響を受けるリクエストは 500 を返します)。この同じメモによれば、abort のパフォーマンスの向上 (RPS の約 1 ～ 2%) は、絶縁の損失に見合うものではありません。これは、コードに記載されている信頼性と速度のトレードオフであり、マーケティング上の主張ではありません。

単一の cargo build --workspace で全体がコンパイルされます。単一の cargo test --workspace がテスト スイート全体を実行します。単一の cargo clippy --workspace --all-targets -- -D warnings は、同じルールで製品全体をリントします。この構造の詳細 - 依存関係の継承、ライブラリとサービス間の内部グラフ、成長中に遭遇した落とし穴 - は、専用の記事の主題です: Cargo ワークスペース アーキテクチャ、マルチサービス Rust バックエンドを構造化する方法。

サービス別の Rust 行 (find services -name '*.rs' | xargs wc -l、2026 年 8 月 23 日):

オーラコントロール

36 024

オーラデータベース

30 255

オーラ認証

28 431

オーラプロビジョナー

28 271

オーラ通知

18 498

持つだろう

18 305

オーラゲートウェイ

16 938

オーラリアルタイム

16 799

オーラストレージ

13 747

オーラ機能

11 619

オーラマイグレーター

538

共有ライブラリ (aura-db-adapters: 24,725 行、aura-core: 7,259、aura-migrations: 3,641、aura-crypto: 2,718、aura-telemetry: 201)、CLI (aura-cli: 9,845)、および Rust SDK (aurabase-rs: 6,363) を除きます。 aura-migrator は、一度だけ使用する移行ジョブであり、長期間存続する HTTP サーバーではなく、ワークスペース内で意図的に最小のサービスのままです。

各サービスは、独自の構成とポートを備えた独立した Axum/Tokio バイナリです。 11 個のうち 10 個は /health と /metrics を公開し、 mimalloc をグローバル アロケーターとして宣言します。唯一の例外である aura-migratorは、継続的に実行されるサーバーではなく、単一目的のジョブです。

aura CLI (約 9,800 行) は SDK と同じ API と通信します。これには特権パスがありません。各サービスの完全なリファレンスは、アーキテクチャ ドキュメント および CLI リファレンスにあります。

多言語スタックでは、セキュリティ ルール (エラー形式、SSRF 保護、レート制限) を言語ごとに再実装する必要があり、ほとんどの場合、数か月にわたって変動します。 Aurabase はこれをワークスペース ライブラリに一度コーディングし、関連するすべてのサービスによって使用されます。

直接的な影響: aura-core のセキュリティ パッチ (SSRF 保護など) は、5 つの言語で 5 つの個別のパッチを介するのではなく、次の cargo buildの各コンシューマ サービスに伝播します。

aura-gateway は、同じクライアントも同じ認証モデルも持たない 2 つのサーフェスを分離します。データ プレーン (ポート 8080、変数 GATEWAY_PORT) は、API キー (apikey、 X-API-Key または ?apikey=) によって認証された SDK/アプリ トラフィックを受信します。管理プレーン (ポート 8090、 MANAGEMENT_PORT) は、JWT コンソール (Authorization: Bearer) によって認証された Studio/管理トラフィックを受信します。

// データプレーン — API キー
.route("/v1/auth/{*path}", any(auth_proxy))
.route("/v1/db/{*path}", any(db_proxy))
.route("/v1/realtime/ws", get(realtime_ws_proxy))
.route("/v1/realtime/sse", get(realtime_sse_proxy))
.route("/v1/storage/{*path}", any(storage_proxy))
.route("/v1/notifications/{*path}", any(notifications_proxy))
.route("/v1/ai/{*path}", any(ai_dispatcher))
.route("/v1/functions/{*path}", any(functions_proxy))

// 管理計画 — JWT コンソール
.route("/v1/control/{*path}", any(control_proxy))

各プレーンには独自のミドルウェア スタック (クエリ識別、アクセス ログ、レート制限、認証 (プレーン固有)、サーキット ブレーカー、プロキシ) が搭載されています。これらは、互いに同じように信頼すべきではない 2 つのサーフェス間で偶然共有された単一のチェーンではなく、別個のモジュール (middleware/rate_limit.rs、 middleware/circuit_breaker.rs、 middleware/auth_data_plane.rs、 middleware/auth_management_plane.rs) に実装されています。方法。

ミドルウェアの正確な順序、ターゲットごとのレート制限、および NATS/HTTP プロキシについては、専用記事 デュアルプレーン ゲートウェイ、Rust でのデータプレーン/管理プレーン API ゲートウェイの設計の主題です。

SDK が使用する自己生成 REST API は、社内の Rust モジュールではありません。これは、実際のアップストリーム バイナリ PostgREST (postgrest/postgrest:v12.2.8) であり、専用プロジェクト (deploy/cnpg/tenant-postgrest.yaml) ごとに 2 つのレプリカにデプロイされ、テナントの CNPG インスタンスと同じ場所に配置されます。 aura-provisioner はこのデプロイメントを作成し、aura-db は各スキーマのリロード後にそのエンドポイント OPTIONS を調査して、PostgREST が DDL の変更を考慮していることを確認します。

これは、近道ではなく、想定されたアーキテクチャ上の選択です。PostgREST は成熟し、広く採用されているプロジェクトであり、その動作を Rust で少しずつ書き換えても何も起こりません。 Aurabase の Rust の作業は、クエリ エンジン自体の内部ではなく、マルチテナント ルーティング、プロビジョニング、NetworkPolicy によるネットワーク分離、ゲートウェイとの共有認証、調整されたスキーマ リロードに重点を置いています。この互換性が実際に何をカバーするのか、またどこで止まるのかについては、別の記事で説明します: PostgREST、実際の互換性、およびの代替案。

GraphQL 側でも同じロジック: Postgres 拡張機能 pg_graphql (プリコンパイルされた .deb パッケージ、v1.6.1) は専用の CNPG イメージにインストールされ、POST /v1/control/projects/{project_id}/graphql/enable エンドポイントを介してプロジェクトごとにオンデマンドでアクティブ化されます。これは書き換えられた GraphQL エンジンでもありません。 Hasura および PostGraphile との詳細および正直な比較: pg_graphql を使用した Postgres 上のネイティブ GraphQL API。

マルチテナント分離は、アプリケーション ORM によって追加された WHERE tenant_id = ? フィルターに依存しません。各リクエストは aura_authenticatorロールを通過し、リクエストを実行する前にトランザクション スコープの SET LOCAL ROLE tenant_<uuid> を実行します。これは、まさに PostgREST 自体が期待するモデルです。行レベルのセキュリティは、残りの部分をビジネス コード レベルではなくエンジン レベルで実行します。

すべてのプロジェクトが同じ Postgres トポロジを共有するわけではありません。 aura-provisioner コードは、少なくとも 2 つの実際のバリアントを持つ ProjectInstanceKind 型を公開します: FullyDedicated (プロジェクト専用の CNPG インスタンス) と SharedClusterDedicated (共有 CNPG クラスター上の RLS によって分離されたスキーマ)。契約したプランによってトポロジが決まります。これは「全員に専用のベースを提供する」という一律の約束ではありません。

11 のビジネス サービスのうち 10 は、Cargo.toml の直接の依存関係として async-nats を宣言しています。宣言なしで宣言しているのは aura-migrator だけです。このクレート名が示していないこと: これらのサービスはほぼどこでも、JetStreamではなく、NATS のコア パブ/サブ API (Client::publish / publish_with_headers、 永続化または再生なしの最大 1 回配信) を使用しています。 。これは、最も重要な 3 つの用途のコードで検証されたケースです。 aura-realtimeへの PostgreSQL CDC の配布、 aura-functions での Edge Functions ジョブの通知 (DLQ 自体は NATS ではなく Postgres に存在します)、 aura-provisioner と残りのフリート間のプロビジョニング イベントです。

JetStream — NATS の永続性と名前付きストリーム モード — は、モノリポジトリ内の検証済みの 1 つの場所、つまり aura-realtime のクロスインスタンス プレゼンス KV ストア (バケット aura_presence、メモリ ストア、60 秒 max_age) にのみ表示されます。これは、 ws-front の複数のインスタンス間で誰がどのチャネルに接続しているかを同期します。これは、再生するイベントのストリームではなく、インスタンス間の共有状態です。ワークスペース内の他の場所では、永続的な JetStream ストリームは見つかりませんでした。 CDC パイプラインの詳細 (wal2json、Lease Kubernetes による固有の cdc-worker の選択、ws-frontレプリカへのコア NATS ファンアウト、サブスクライバーによる RLS 再検証) は、専用記事の主題です: NATS を使用した PostgreSQL CDC のブロードキャスト。 リアルタイム ドキュメント では、SDK 側での使用法について説明しています。

これは、このファイルの最も重要なニュアンスであり、Aurabase 製品コードにおける純粋な Rust からの唯一の実質的な相違点です。各関数には、 "wasm" または "deno"に相当する runtime フィールドがあります。呼び出しハンドラーはそれに応じて実行パスを選択します。実際のスニペットはコード自体でコメント化されています。

// ランタイムに応じたディスパッチ: WASM (wasmtime) または Deno (エッジランタイム経由の V8 分離)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // aura-edge-runtime へのプロキシ — V8 分離 (supabase/edge-runtime、MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

wasm モードはネイティブです: aura-functions は Wasmtime (バージョン 43、機能 async および cranelift) に直接依存し、燃料カウント、エポックによる割り込み、 StoreLimitsによるメモリ境界を使用して同じ Rust プロセスでモジュールを実行します。 deno モード — 既存の Supabase コードとのほぼ直接的な Deno.serve() 互換性のために Studio エディターでデフォルトで使用されるモード — 実行を aura-edge-runtime、約 550 行の別個の TypeScript サービスに委任します。明示的にモデル化されています — ソース ファイル ヘッダーのコメント自体がそれを引用しています — supabase/edge-runtime (MIT ライセンス)、各呼び出しを独自の V8 Isolate に分離します。

両方のデプロイ パスのハウツー ドキュメントについては、「エッジ関数」を参照してください。 Supabase からの Deno 移行プレイブックについては、「 Migrate a Supabase project to Aurabase」を参照してください。この違いについては、このファイルの前にすでに説明されています。

SDK を通じて API を呼び出すだけの場合、このアーキテクチャは目に見えなくなります。これが目標です。これは主に 3 つの対象者にとって重要です。本番データを移行する前にマルチテナント バックエンドの運用の信頼性を評価する人、リポジトリ (MIT、単一モノリポジトリ) に貢献する予定の人、および Aurabase 側のセキュリティ パッチがなぜゆっくりではなく急速に広がるのかを理解したい人です。

具体的には、1 つの IC (cargo build --workspace、 cargo test --workspace、 cargo clippy --workspace --all-targets -- -D warnings) で製品表面の 90% 以上をカバーします。 aura-core のコード レビューは、良く言えば (修正が途中で失われない)、悪くすれば (分離が不十分な変更が同じくらい早く広がる)、一度に 10 個のサービスに影響を与える可能性があります。これは魔法の解決策ではなく妥協策です。だからこそ、マーケティング概要ではなく実際のアーキテクチャを文書化します。

このピラー ページは、公開されたクラスターの技術分析にリンクしています。このページの公開時の実際のステータス — 対応する記事がオンラインになるとすぐにリンクがアクティブになります。

クラスター A — フレームワークとアーキテクチャ

Axum と Actix-web: 本番環境の Rust バックエンドのフレームワークはどちらですか?公開されました

Cargo ワークスペース アーキテクチャ: マルチサービス Rust バックエンドを構築する方法公開

デュアルプレーン ゲートウェイ: Rust でのデータプレーン/管理プレーン API ゲートウェイの設計公開済み

クラスター B — Postgres 上の自己生成 API

PostgREST: 互換性が実際にカバーするものと、代替手段が存在するもの公開済み

pg_graphql を使用した Postgres 上のネイティブ GraphQL API: Hasura と PostGraphile が同じことをしない点公開

RLS とプロジェクトごとの専用ベース: Aurabase からのマルチテナント絶縁の選択公開済み

クラスター C — リアルタイムとメッセージング

NATS を使用した PostgreSQL CDC の配布: リアルタイム アーキテクチャ公開済み

クラスター D — エッジ関数 WebAssembly

クラスター E — 移行と代替案

RLS ポリシーを書き換えずに Supabase プロジェクトを Aurabase に移行する公開済み

ソブリンセルフホスティング: Rust ネイティブ BaaS に対する Aurabase の位置づけ近日公開予定