GN⁺: 귀하의 스타트업에 복잡한 Cloud Infrastructure가 필요합니까?
(hadijaveed.me)복잡한 클라우드 인프라가 정말 필요한가?
- Pieter Levels가 Lex Friedman Podcast에서 이야기한 내용을 들으며 많은 깨달음을 얻음
- Pieter는 단일 서버에서 애플리케이션을 운영하며 성공적인 마이크로 SaaS 비즈니스를 구축함
- 클라우드 인프라의 복잡성을 피하고 제품-시장 적합성에 집중하는 것이 중요함
- 모든 스타트업에 적합하지 않을 수 있지만, 복잡성을 위한 복잡성을 피해야 함
최근 관찰
프로젝트 1: Lambda 과부하
- 20-30개의 Lambda 함수로 다양한 서비스 운영
- SQS와 Lambda를 이용한 백그라운드 작업
- CloudWatch에 분산된 로그
결과: 디버깅이 어렵고 변경이 힘들며 배포가 복잡함. 단일 NodeJS 컨테이너나 Python Flask/FastAPI 앱과 Redis로 단순화할 수 있었음
프로젝트 2: 마이크로서비스 혼란
- Kubernetes (EKS)에서 7개의 작은 마이크로서비스 운영
- CRUD와 비즈니스 로직을 위한 별도의 서비스
결과: 인프라 관리에 더 많은 시간을 소비함. 이 정도의 분리가 필요했는지 의문
단일 서버 설정의 힘
- 현대 서버는 강력함. Hetzner, latitude.sh에서 저렴한 가격에 강력한 VM을 제공
- GCP VM과 EC2 인스턴스도 합리적인 가격
- 40GB RAM과 다중 코어를 가진 강력한 컴퓨팅 파워 제공
- 모든 것이 중앙 집중화되어 관리가 쉬움
- 수백만 QPS로 확장하는 문제는 나중에 해결 가능
단일 VM 설정을 위해 필요한 것:
- 강력한 머신 (EC2, GCP VM, Hetzner 등)
- 안전한 접근 (HTTPS, IP 제한 SSH 또는 SSM)
- 무중단 배포를 위한 CI/CD
- DNS 구성
- 정기적인 데이터베이스 백업
- 대기 VM을 통한 중복성 확보
Docker Compose
- Docker Compose는 로컬 개발에 훌륭함
- 여러 서비스를 단일 명령으로 관리 가능
- 프로덕션 환경에서 덜 사용됨
- 업데이트 중 다운타임 발생 가능성 있음
Docker Compose Anywhere: 주말 프로젝트
- Docker Compose Anywhere를 주말 동안 개발
- 다음 기능 제공:
- GitHub Actions를 통한 원클릭 Linux 서버 설정
- GitHub Container Registry와 Docker Rollout을 이용한 무중단 배포
- 환경 변수와 비밀 관리 (age 또는 sops 사용 고려)
- GitHub Actions를 통한 자동화된 Postgres 백업
- 단일 VM에서 다중 앱 지원
- Traefik과 Let's Encrypt를 통한 자동 SSL
몇 가지 고려사항
보안을 위해:
- 엄격한 방화벽 규칙 설정 (필요한 포트만 열기)
- SSH 키 보안 (AWS에서는 SSM, GCP에서는 CLI 선호)
- 보안 강화를 위한 바스천 호스트 사용
- 비밀 보호 및 WAF 또는 Cloudflare 사용 고려
데이터 보호:
- 암호화된 데이터베이스 백업을 안전한 클라우드 스토리지로 전송 (예: S3)
- 추가 중복성을 위해 디스크 스냅샷 정기적으로 생성
- 백업 및 스냅샷에 대한 보존 정책 구현
GN⁺의 정리
- 이 글은 스타트업이 복잡한 클라우드 인프라를 피하고 단순한 설정으로 제품-시장 적합성에 집중해야 함을 강조함
- 단일 서버 설정의 장점과 Docker Compose를 활용한 간단한 배포 방법을 소개함
- 복잡한 인프라 관리에 시간을 낭비하지 않고 핵심 제품 개발에 집중하는 것이 중요함
- 비슷한 기능을 가진 프로젝트로는 Heroku, DigitalOcean 등이 있음
Hacker News 의견
-
여러 프로젝트에서 최신 기술을 사용하려는 팀들이 품질이 낮은 결과물을 만들어내는 경우가 많음
- Kubernetes를 이해하지 못하면서도 사용하려는 미성숙한 팀들이 있음
- Puppet을 사용해 다양한 VM에서 Docker 서비스를 실행하거나 Python 백엔드를 구동하는 자동화된 프로세스를 구축함
- 스타트업들이 클라우드에서 많은 비용을 지출하면서도 2017년의 DevOps 선구자들보다 나쁜 결과물을 만들어내고 있음
- 관련 블로그 글: The Emperor's New clouds
-
작은 스타트업에서 단일 VM을 사용해 nginx, webapp, postgres, redis 등을 운영함
- 개발자들이 동일한 설정으로 로컬 환경에서 작업할 수 있어 디버깅이 쉬움
- 수직 확장이 가능해 초기 단계에서는 적합함
-
SaaS를 단일 서버에서 시작해 여러 서버로 확장함
- Kubernetes를 사용하지 않고도 분산 데이터베이스를 운영함
- 클라우드 제공업체의 가상 머신보다 강력한 베어메탈 서버를 사용함
- 자동화 도구로 ansible과 terraform을 사용해 서버를 관리함
-
Kubernetes의 핵심 기능인 배포, 파드 서비스, 블루-그린 배포 등이 유용함
- 클라우드 네이티브 환경에서 다양한 오픈 소스 시스템을 사용하면 복잡해질 수 있음
-
많은 사람들이 Kubernetes를 배우기 위해 복잡한 인프라를 구축함
- 대규모 클라이언트로 확장할 때 유용할 수 있음
- 창업자나 CTO에게는 덜 유용할 수 있음
-
마이크로서비스 책에서도 "먼저 모놀리스를 구축하라"고 권장함
- 초기에는 모놀리스를 사용하는 것이 디버깅이 쉬움
- Docker를 사용해 초기 단계를 간소화함
- 비즈니스 필요에 따라 Kubernetes로 전환함
-
복잡한 프레임워크를 처음부터 선택하는 것은 권장하지 않음
- 자체 도구를 사용하는 것이 항상 더 효율적이지 않을 수 있음
- 표준 도구를 사용하는 것이 장기적으로 더 효율적일 수 있음
-
클라우드에서 VM, 블록 및 블롭 스토리지, DNS, IdP, 도메인 등록자만 사용함
- FaaS와 같은 서비스는 복잡하고 디버깅이 어려움
- 단일 VM과 모놀리틱 코드베이스가 이상적임
-
6년 동안 단일 $10/월 VPS에서 프로젝트를 운영함
- VPS 기술이 매우 발전해 신뢰성이 높음
- 클라우드 인프라는 협업과 운영 관리 기능을 위해 사용함
-
클라우드 기반 솔루션을 선호하지만 선택적으로 사용함
- Google Cloud Platform(GCP)을 사용해 비용을 절감함
- Kubernetes를 사용하지 않음
- Docker를 사용해 배포를 간소화함
- GCP의 관리형 서비스가 시간을 절약해줌