Hacker News 의견들

• 나는 self-hosting을 책임의 문제로 봄
  SaaS 제품 몇 개를 직접 호스팅 중인데, AWS보다 훨씬 저렴하면서도 성능이 훨씬 좋음
  다만 클라이언트 프로젝트에서는 AWS 비용을 지불하도록 설득함. 하드웨어 가용성 책임을 다른 쪽으로 넘길 수 있기 때문임
  예산이 제한된 경우엔 RDS 비용이 부담스러움. Hetzner의 3노드 Galera 클러스터를 몇 달러로 운영하는 게 훨씬 경제적임
  하지만 Cloudflare나 SQS 같은 관리형 서비스도 종종 장애가 발생함. 결국 완벽한 안정성은 어디에도 없음

  • “왜 NoNameCMS에서 Salesforce로 바꾸나요?”라고 물었더니, “Salesforce가 다운되면 WSJ에 기사 나니까”라는 답을 들음. 책임 전가의 현실적인 이유임
  • 클라이언트의 고객 입장에서는 “Ikea랑 Disney도 다운됐다”는 말이 통하지 않음. 결국 자기 서비스가 멈췄다는 게 전부임
  • AWS Serverless PG가 있는데 굳이 직접 관리할 이유가 없음. 저트래픽 환경에서는 거의 무료 수준이고, 보안·백업·통합성 면에서 훨씬 우수함
    AWS Aurora Serverless
  • VM 수준까지만 외주화하고 나머지는 직접 관리하는 절충도 가능함. 기술 스택의 운영 오버헤드에 따라 달라짐
  • 20년간 수많은 클라이언트의 self-hosted SQL을 운영했는데, SQL 서버가 다운된 적은 한 번도 없음
    클라우드 SQL은 오히려 비용 구조가 복잡하고, 백업 설정만 한 번 해두면 끝임

• 나는 self-hosting이 대부분에게 맞는 선택이라는 주장에 동의하지 않음
  오히려 예산이 빠듯하거나, 혹은 전담 엔지니어를 둘 만큼 큰 규모일 때만 직접 호스팅이 합리적이라 생각함
  소규모 기업은 클라우드에 맡기는 게 현실적임. 셋업 후 월 30~120분 관리면 충분하다는 계산이 나옴

  • 대부분의 회사는 클라우드를 써도 여전히 인프라 엔지니어를 고용함. “클라우드가 인건비를 줄인다”는 건 거짓임
    Heroku나 Render 같은 PaaS는 일반 개발자도 다룰 수 있지만 훨씬 비쌈
    결국 애플리케이션 복구 자동화가 안 되어 있으면 새벽 3시에 깨는 건 똑같음
  • 대부분의 서비스는 고가용성이 필요하지 않음. 토요일에 다운돼도 월요일에 고치면 됨
    내부 툴이라면 Docker에 Postgres 하나 추가하는 데 5분이면 충분함
  • 클라우드도 월 1~2시간 정도는 관리 시간이 들어감. self-hosting과 큰 차이 없음
  • RDS를 쓰면 오히려 가시성과 제어권이 떨어져서 디버깅이 더 어려움
  • 논점은 효율이 아니라 문제가 생겼을 때 누가 욕을 먹느냐임. 클라우드면 책임을 돌리기 쉬움

• ‘관리형 데이터베이스’의 정의가 혼란스러움
  나에게 기본 요건은 자동 백업, 인덱스 최적화, 멀티데이터센터 장애조치, 포인트인타임 복구, 슬로우쿼리 분석, 스토리지 예측임
  이런 걸 월 요금으로 제공한다면 self-hosting 논쟁은 의미가 없어짐

  • 문제는 전문 인력을 고용해야 한다는 점임. Postgres 담당자가 휴가 가면 버스 팩터 문제가 생김
    결국 두 명을 두게 되고, 일이 심심하니 불필요한 개선을 시도하다가 6개월을 날리는 경우도 있음
  • self-hosting의 이유는 결국 지연시간(latency) 임. 백업이나 분석은 기본이고, 직접 구축해야 가장 빠름
  • 셋업만 잘 하면 백업이나 멀티리전 장애조치도 자동화 가능함
  • 새벽 3시에 전화 안 올 서비스만 self-hosting함. 로그나 내부 분석용은 괜찮지만, DB는 절대 아님
  • Yugabyte 오픈소스가 이런 기능 대부분을 커버함

• 관리형 DB가 VPS 대비 너무 비쌈
  편의성 프리미엄을 기대했지만 실제로는 몇 배나 더 비쌈. 그래서 큰 프로젝트 외엔 쓰지 않음

  • 스스로 못한다고 믿게 만들고, 그 사이에 가격을 계속 올림. 옮길 기술이 없으니 종속됨

• 글에서 언급된 고가용성(HA) 부분이 부족함. WAL 설정만으로는 설명이 안 됨. 복제는 비용이 큼

• Postgres가 HN에서 과대평가된 이유를 모르겠음
  MongoDB처럼 자동 장애조치가 되는 HA 클러스터를 쉽게 구성할 방법이 없음. 실서비스에서는 어떻게 해결하는지 궁금함

  • PostgreSQL 커뮤니티도 이 문제를 인식하고 있음. MongoDB의 내장 복제 안정성을 부러워함
    관련 논의: PostgreSQL 메일링리스트
  • Kubernetes를 쓴다면 CloudNativePG가 사실상 표준 HA 솔루션임
  • SQL 진영은 진짜 HA 대신 빠른 복구(Disaster Recovery) 에 익숙함
    실제로는 모든 연결이 끊기고, 캐시가 초기화되며, 업그레이드 시엔 서비스 중단이 필수임
    Oracle RAC만이 예외이고, PostgreSQL은 그런 구조가 아님. YugabyteDB가 그나마 대안임
    대부분의 앱은 몇 시간의 다운타임을 감수함. 대기업만이 복잡한 자동화를 감당할 수 있음
  • 가장 흔한 방법은 Patroni를 쓰는 것임. 간단히 하려면 Autobase 사용
    Kubernetes 환경이라면 CloudNativePG도 좋음.
    pg_auto_failover는 단순하지만 제약이 있음
  • 사실 대부분의 비즈니스는 그런 복잡한 HA가 필요 없음. 비용 대비 효과가 낮음

• Autobase를 보면 self-hosting 시 필요한 작업을 자동으로 처리해줌

  • README를 훑어봤는데 커넥션 풀링은 범위 밖인 듯함
  • 다른 self-hosted PaaS와도 잘 연동되는지 궁금함. Docker 컨테이너 형태로 동작하는 듯함
  • 멋진 프로젝트라 감사함

• 15년 동안 Postgres를 항상 self-hosted로 써왔지만, 문제를 겪은 적은 거의 없음
  유일한 고민은 ORM 업그레이드에 맞춰 PG 버전 마이그레이션을 해야 할 때였음. 신중한 시스템 관리로 해결 가능했음

• Fly.io에서 비관리형 Postgres를 직접 돌렸는데, 정말 고생했음
  노드가 자주 죽어서 수동으로 repmgr로 복구해야 했고, 결국 내부 위키에 절차를 정리함
  클러스터의 목적이 고가용성인데 왜 좀비 프라이머리를 자동으로 처리하지 않는지 이해가 안 됐음
  결국 관리형 Postgres로 옮겼고, 장애 시 다른 사람이 처리해주는 게 정말 편함

  • 지금은 Fly의 Managed Postgres를 쓰고 있음

• 이 스레드의 많은 댓글이 규모, 워크로드, 인력, 시간, 비즈니스 단계, 확장성 요구 같은 현실적 요소를 무시함
  self-hosting이 맞을 수도, 아닐 수도 있는데 논의가 너무 단순함

  • 엔지니어들은 이런 요소를 거의 고려하지 않고, 상사가 승인할 가장 비싼 솔루션을 택하는 경향이 있음