Aurabase의 Rust 코어: 통합 서비스형 백엔드

대부분의 오픈 소스 Postgres BaaS는 서비스를 여러 언어로 패키지합니다. 이는 가치 판단이 아닙니다. 구체적인 결과를 가져오는 아키텍처적 사실입니다. 즉, 사용 중인 언어만큼 동기화를 유지해야 하는 컴파일 체인, 오류 규칙 및 인증 논리가 많습니다.

Aurabase에서 게이트웨이, 인증, 데이터베이스, 실시간, 스토리지, 알림, AI, 프로비저닝, 계정 관리 등 우리가 직접 작성하고 유지 관리하는 제품 계층은 단일 Cargo 작업 공간, 단일 언어, 단일 빌드 체인입니다. 이는 이 파일이 문서화하는 선택입니다.

루트 Cargo.toml는 18개 멤버(11개 비즈니스 서비스, aura-cliCLI, 5개 공유 라이브러리 및 aurabase-rsSDK)가 있는 해석기 v2에서 Cargo 작업 공간을 선언합니다. 저장소에 표시되는 실제 목록은 다음과 같습니다.

[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 및 거의 모든 서비스에서 발견되는 두 개의 성능 라이브러리: 전역 할당자로서 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는 동일한 규칙으로 전체 제품을 린트합니다. 이 구조의 세부 사항(종속성 상속, libs와 서비스 간의 내부 그래프, 성장하는 동안 우리가 직면한 함정)은 전용 기사의 주제입니다: Cargo 작업 공간 아키텍처, 다중 서비스 Rust 백엔드를 구성하는 방법.

서비스별 Rust 라인(services -name '*.rs' | xargs wc -l 찾기, 2026년 8월 23일):

오라 제어

36 024

아우라-db

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)는 제외됩니다. 수명이 긴 HTTP 서버가 아닌 일회용 마이그레이션 작업인 aura-migrator는 의도적으로 작업 공간에서 가장 작은 서비스로 남아 있습니다.

각 서비스는 자체 구성과 포트를 갖춘 독립적인 Axum/Tokio 바이너리입니다. 11개 중 10개는 /health 및 /metrics을 노출하고 mimalloc를 전역 할당자로 선언합니다. 유일한 예외인 aura-migrator는 지속적으로 실행되는 서버가 아닌 단일 목적 작업입니다.

aura CLI(약 9,800줄)는 SDK와 동일한 API와 통신하며 권한 있는 경로가 없습니다. 각 서비스에 대한 전체 참조는 아키텍처 문서 및 CLI 참조에 있습니다.

다중 언어 스택에서는 오류 형식, SSRF 보호, 속도 제한과 같은 보안 규칙을 각 언어로 다시 구현해야 하며 거의 항상 몇 달에 걸쳐 표류합니다. Aurabase는 관련된 모든 서비스에서 사용되는 작업 공간 lib에서 이를 한 번 코딩합니다.

직접적인 결과: aura-core의 보안 패치(예: SSRF 보호)는 5개 언어로 된 5개의 개별 패치를 통하지 않고 다음 cargo build의 각 소비자 서비스에 전파됩니다.

aura-gateway는 동일한 클라이언트나 동일한 인증 모델이 없는 두 표면을 분리합니다. 데이터 플레인(포트 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))

각 플레인은 동일한 방식으로 서로 신뢰해서는 안되는 두 표면 간에 실수로 공유된 단일 체인이 아닌 별도의 모듈(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)이며, 전용 프로젝트당 2개의 복제본(deploy/cnpg/tenant-postgrest.yaml)에 배포되고 테넌트의 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 = ? 필터에 의존하지 않습니다. 각 요청은 요청을 실행하기 전에 SET LOCAL ROLE tenant_<uuid> 트랜잭션 범위를 실행하는 aura_authenticator역할을 통과합니다. 이는 정확히 PostgREST 자체가 기대하는 모델입니다. 행 수준 보안은 비즈니스 코드 수준이 아닌 엔진 수준에서 나머지 작업을 수행합니다.

모든 프로젝트가 동일한 Postgres 토폴로지를 공유하는 것은 아닙니다. aura-provisioner 코드는 FullyDedicated(전적으로 프로젝트 전용 CNPG 인스턴스) 및 SharedClusterDedicated(공유 CNPG 클러스터에서 RLS에 의해 격리된 스키마)라는 두 가지 이상의 실제 변형이 있는 ProjectInstanceKind 유형을 노출합니다. 가입한 계획에 따라 토폴로지가 결정됩니다. 이는 "모든 사람을 위한 전용 기반"에 대한 통일된 약속이 아닙니다.

11개의 비즈니스 서비스 중 10개는 async-nats을 Cargo.toml의 직접 종속성으로 선언합니다. aura-migrator만이 이를 선언하지 않습니다. 이 크레이트 이름이 말하지 않는 것: 거의 모든 곳에서 이러한 서비스는 [JetStream이 아닌 NATS의코어 게시/구독 API (Client::publish / publish_with_headers, 지속성 또는 재생 없이 최대 1회 전달)을 사용합니다.](https://docs.nats.io/nats-concepts/jetstream). 이는 가장 중요한 세 가지 용도에 대한 코드에서 확인된 사례입니다. aura-realtime에 대한 PostgreSQL CDC 배포, aura-functions의 Edge Functions 작업 알림(DLQ 자체는 NATS가 아닌 Postgres에 있음), aura-provisioner과 나머지 플릿 간의 이벤트 프로비저닝입니다.

JetStream — NATS의 지속성 및 명명된 스트림 모드 —은 모노레포에서 확인된 하나의 위치인 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(Edge-runtime을 통해 V8 격리)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // aura-edge-runtime에 대한 프록시 — V8 Isolates(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로 격리합니다.

두 배포 경로 모두에 대한 방법 문서는 Edge Functions를 참조하세요. Supabase의 Deno 마이그레이션 플레이북은 이 파일 이전에 이미 이러한 차이점을 문서화한 Supabase 프로젝트를 Aurabase로 마이그레이션을 참조하세요.

SDK를 통해 API를 호출하면 이 아키텍처가 보이지 않습니다. 이것이 목표입니다. 이는 주로 세 가지 대상, 즉 프로덕션 데이터를 마이그레이션하기 전에 다중 테넌트 백엔드의 운영 안정성을 평가하는 대상, 저장소(MIT, 단일 단일 저장소)에 기여하려는 대상, Aurabase 측의 보안 패치가 느리게 확산되는 이유를 이해하려는 대상 등 세 가지 대상에게 중요합니다.

구체적으로 말하면 단일 IC(cargo build --workspace, cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings)가 제품 표면의 90% 이상을 덮습니다. aura-core에 대한 코드 검토는 잠재적으로 한 번에 10개의 서비스에 영향을 미칠 수 있습니다. 더 나은 경우(수정 사항이 도중에 손실되지 않음) 또는 더 나쁜 경우(잘못 분리된 변경 사항이 빠르게 확산됨)입니다. 이는 마법의 솔루션이 아닌 절충안입니다. 이것이 바로 우리가 마케팅 요약이 아닌 실제 아키텍처를 문서화하는 이유입니다.

이 기둥 페이지는 게시된 클러스터의 기술 분석에 대한 링크입니다. 이 페이지 게시 당시의 실제 상태 — 해당 기사가 온라인에 올라오자마자 링크가 활성화됩니다.

클러스터 A — 프레임워크 및 아키텍처

Axum 대 Actix-web: 프로덕션 환경의 Rust 백엔드를 위한 프레임워크는 무엇입니까?게시됨

화물 작업 공간 아키텍처: 다중 서비스 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로 마이그레이션게시됨

Sovereign 자체 호스팅: Rust 기반 BaaS에 맞서 Aurabase 포지셔닝곧 출시 예정