피드로 돌아가기
GeekNewsInfrastructure
원문 읽기
포지의 연합이 필요하다
ATproto 기반 데이터-뷰 분리 구조를 통한 Forge Federation 구현
AI 요약
Context
ActivityPub 기반의 Federated 시스템은 서버 간 메시지 교환 구조로 인해 호스팅과 앱이 강하게 결합된 소규모 중앙집중 서비스들의 집합체라는 한계를 가짐. 이로 인해 신규 서버의 Cold Start 문제와 낮은 Discoverability, 호스트 변경 시의 데이터 단절 문제가 발생함.
Technical Solution
- ATproto의 데이터 모델을 채택하여 데이터 저장소(PDS)와 렌더링 계층(AppView)을 완전히 분리한 아키텍처 설계
- PDS(Personal Data Server)에 사용자 데이터를 호스팅하여 데이터 소유권을 보장하고 호스트 변경 시에도 지속성을 유지하는 구조 구축
- 다수의 PDS 데이터를 수집하여 단일 뷰로 제공하는 AppView 도입을 통해 중앙집중형 서비스와 유사한 일관된 사용자 경험 제공
- Shared Relay 의존 방식을 통해 명시적 Federation의 복잡도를 낮추고 전역적인 프로젝트 발견성(Discoverability) 확보
- Git 서버(Knot)와 빌드 시스템(Spindles)을 분리하고, 이슈 및 PR 대화를 공용 소셜 레이어에서 처리하여 저장소 이동성을 극대화한 설계
- Go modules 기반의 느슨한 결합과 Nix를 통한 오케스트레이션으로 최소 리소스 기반의 Self-hosting 가능 구조 구현
실천 포인트
- 데이터 저장소와 서비스 뷰 계층을 분리하여 벤더 락인을 방지하고 마이그레이션 비용을 최소화했는가 - Federation 도입 시 단순 메시지 교환 방식(ActivityPub)과 데이터 호스팅 방식(ATproto) 중 서비스 성격에 맞는 Topology를 선택했는가 - 시스템의 Discoverability 문제를 해결하기 위해 전역 인덱싱 레이어(AppView/Relay)를 설계에 반영했는가 - 인프라 의존성을 낮추기 위해 재현 가능한 빌드 시스템(Nix 등)과 최소 사양의 런타임을 고려했는가