자체 호스팅 Rails 애플리케이션 구축: 설계 결정 및 그 이유

Building Self-Hosting Rails Applications: Design Decisions and Why

작성자
HackerNews
발행일
2025년 11월 25일

핵심 요약

  • 1 Broadcast는 Docker 이미지로 배포되며, SolidQueue 등 PostgreSQL 기반 서비스를 활용하여 단일 데이터베이스로 모든 종속성을 통합하고 설치 및 유지보수를 간소화합니다.
  • 2 Rails 앱과 호스트 시스템 간의 통신을 위해 '트리거 파일' 패턴을 도입하여 UI에서 업그레이드, 백업, 도메인 변경 등 시스템 작업을 제어할 수 있도록 구현했습니다.
  • 3 Thruster를 통해 SSL/HTTP/2를 자동 처리하고, 단일 행 설치 모델 및 파일 기반 모니터링을 적용하여 사용자 편의성과 운영 효율성을 극대화한 자체 호스팅 아키텍처를 제시합니다.

도입

2024년에 출시된 자체 호스팅 이메일 마케팅 플랫폼인 Broadcast의 개발자는 애플리케이션 구축 과정에서 얻은 기술적 교훈을 공유합니다. 이 글은 최종 사용자가 Rails 및 배포에 익숙하지 않다는 전제 하에, 애플리케이션의 쉬운 설치와 유지보수에 중점을 둔 설계 결정과 그 이유를 상세히 설명합니다. Kamal과 같은 도구의 발전에도 불구하고, Broadcast는 사용자 편의성을 최우선으로 고려한 자체 호스팅 아키텍처를 목표로 했습니다.

Docker 이미지 기반 배포 및 단일 DB 아키텍처

Broadcast는 소스 코드 대신 Docker 이미지로 배포되어 설치 및 업데이트를 간소화합니다. 약 500MB 이미지는 모든 종속성을 포함하며 docker compose up으로 전체 스택을 시작합니다. Rails 8의 SolidQueue, SolidCable, SolidCache 등 PostgreSQL 기반 서비스를 활용, Redis 없이 단일 PostgreSQL 인스턴스로 모든 데이터를 관리하여 외부 서비스 종속성 및 유지보수 복잡성을 최소화했습니다.

트리거 파일 패턴과 파일 기반 모니터링으로 시스템 제어 및 가시성 확보

컨테이너 내부 Rails 앱이 호스트 시스템을 직접 제어할 수 없는 제약을 극복하고자 ‘트리거 파일’ 패턴을 도입했습니다. Rails 앱이 파일에 의도를 기록하면, 호스트 cron 작업이 이를 감지하여 업그레이드, 백업, 도메인 변경 등 시스템 작업을 수행합니다. 역으로, 호스트 시스템 메트릭(CPU, 메모리, 디스크)은 호스트 cron 스크립트가 생성한 JSON 파일을 Rails 앱이 읽는 방식으로 제공되어, 파일 시스템을 통한 양방향 정보 교환을 구현합니다.

단일 행 설치 모델 및 Thruster를 통한 자동 SSL/HTTP/2

installations 테이블의 단일 행에 라이선스 키, 도메인 등 설치 설정을 저장하여 환경 변수를 대체하고 UI를 통한 동적 변경을 지원합니다. SSL/HTTP/2 구현을 위해 Basecamp의 Thruster를 활용, 제로 구성 자동화를 달성했습니다. Thruster는 Let’s Encrypt 인증서 프로비저닝, 갱신, SSL 종료, HTTP/2 서비스를 자동으로 처리하며, TLS_DOMAIN 변수를 통해 다중 도메인까지 지원하여 사용자들은 복잡한 SSL 설정 없이 즉시 안전한 서비스를 이용할 수 있습니다.

결론

Broadcast의 아키텍처는 지난 12개월간 다양한 설치 환경에서 수백만 건의 이메일을 성공적으로 처리하며 견고함을 입증했습니다. 초기 설치 외에 인프라 관련 지원 요청이 적다는 점은 설계의 성공을 보여줍니다. 단일 Rails 앱, 단일 PostgreSQL 데이터베이스, 소수의 셸 스크립트로 구성된 단순한 디버깅 표면은 문제가 발생했을 때 문제 해결 지점을 최소화하여 자체 호스팅 애플리케이션의 운영 및 유지보수 부담을 크게 줄여줍니다.

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!