← 미리디 아카이브

Eregion 데이터 흐름 2026-08-26

Eregion 데이터 인프라 흐름

어떤 데이터가 어느 인프라로 오가나. 팀이 공유하는 프로덕션, 각자 격리된 로컬, 읽기만 하는 전사 Databricks — 세 영역을 구분하고 그 사이의 이동 경로 일곱 개에 번호를 붙였다.

Databricks read-only EC2 · Supabase SSoT S3 · ap-northeast-2
§1

세 영역

EC2 위의 Supabase가 팀 전체가 공유하는 프로덕션 원본(SSoT)이다. Databricks는 전사 Lakehouse로 읽기만 하고, S3는 산출물 보관소다.

Databricks · 전사 Lakehouse
silver…template_info_mart
정본 추출대상 (active · 원본 · presentation)
bronze…designcontent components
미리캔버스 원본 (수량 정합 대조)
AWS EC2 · Eregion 서버
Next.js 앱 + 워커 (PM2) · :3000
agentic-rlsc · extract-DO · thumbnail · linter
Production Eregion Supabase
Postgres 17 · Private ALB :54321 · public + rlsc_ml (30 tbl)
layouts · design_objects · rlsc_results
linter_results · labelled_rlscs · components
AWS S3 · ap-northeast-2
miricanvas-ai-stg
썸네일 src · DB덤프 mordor-dump/ · embedding parquet
miricanvas-ai / -dev
썸네일 dest (prod/dev)
component-generation-*
컴포넌트 데이터
EC2 서버는 내부망 10.122.9.74 (VPN)에 있고, production 머지 시 GitHub Actions로 자동배포된다.
§2

데이터 이동 ①–⑦

영역과 영역 사이에서 실제로 무엇이 어느 방향으로 움직이는지.

  1. Databricks → EC2 — 정본 추출대상 → layouts 적재 (databricks CLI)
  2. Databricks ↔ EC2 — 컴포넌트 수량 정합 대조 (read-only)
  3. EC2 Supabase → S3 — 매일 cron pg_dump → mordor-dump/
  4. EC2 워커 → S3 — 썸네일 · parquet · 컴포넌트 업로드
  5. S3/LFS → 로컬 — 덤프 받기 (SSO/LFS)
  6. 로컬 — pg_restore (public · data-only)
  7. EC2 Supabase → 미캔 API — 유효 컴포넌트 / RLSC 전달
§3

내 로컬은 격리되어 있다

로컬 Supabase는 프로덕션을 특정 시점에 떠 온 복사본이다. 복사는 한 방향으로만 흐른다.

Next.js dev :3000 + 워커
supabase start · pnpm dev · 검색은 미캔 API(staging) 프록시
Local Supabase · :54322
복원된 프로덕션 스냅샷 (data-only · public) · 특정 시점 복사본

🔒 단방향 복사

프로덕션 → 덤프 → 내 로컬. 역방향 쓰기는 없다. 내 로컬에서 무엇을 하든 production과 전사 데이터에는 영향이 가지 않는다.

§4

미리캔버스 BE — 별개 DB

운식이 관리하는 완전히 별개의 DB다. Eregion에서 직접 접근하지 않고 ⑦번 경로로 API를 통해 넘긴다.

Miricanvas API
api-staging / api.miricanvas
Miricanvas PG
서빙 DB (별개)
Recall Search V2
hybrid · embedding
실서비스
Staging6 / Production