10년 된 블로그 마이그레이션: Ubuntu 16.04에서 FreeBSD Jails로
많은 개발자에게 개인 블로그나 소규모 프로젝트 사이트는 "set it and forget it" (한 번 설정하면 잊어버리는) 작업입니다. 한 개발자에게 이는 10년 넘게 Ubuntu 16.04 LTS에서 블로그를 운영한다는 것을 의미했습니다. 시스템은 거의 1,500일에 달하는 가동 시간(uptime)을 자랑하며 놀라울 정도로 안정적이었지만, 5년 넘게 보안 업데이트가 제공되지 않으면서 결국 마이그레이션이 불가피해졌습니다.
이 마이그레이션은 단순히 OS를 업데이트하는 것만이 아니었습니다. 이는 시스템 관리의 다른 철학을 실험해 볼 수 있는 기회였습니다. DigitalOcean VPS에서 Hetzner 인스턴스로 이동하고 Linux에서 FreeBSD로 전환함으로써, 저자는 비대해진 구식 서버를 FreeBSD Jails를 사용하는 효율적이고 컨테이너화된 아키텍처로 변모시켰습니다.
변화의 동기
Ubuntu 16.04와 같은 지원 종료(EOL) 배포판을 실행하는 것은 심각한 보안 위험을 초래합니다. 릴리스가 지원 종료되면 apt 저장소는 이동되며, 시스템은 새로운 취약점에 노출됩니다. 저자의 사이트가 악의적인 공격자에게 피해를 입지는 않았지만, "SEO 스팸" (봇이 게시물에 도박 링크를 삽입하는 행위)은 방치된 레거시 서버가 겪는 흔한 운명입니다.
보안 외에도, 이번 이동은 더 나은 하드웨어 가치를 얻고자 하는 욕구에 의해 추진되었습니다. Hetzner로의 전환을 통해 이전 DigitalOcean droplet보다 절반도 안 되는 월 비용으로 두 배의 CPU와 RAM을 확보할 수 있었습니다.
FreeBSD 철학 수용하기
FreeBSD는 단순히 안정성 때문만이 아니라, 표준 Linux 배포판보다 더 강력한 서버 경험을 제공하는 통합된 설계와 특정 기능들 때문에 선택되었습니다.
FreeBSD Jails vs. Docker
FreeBSD의 눈에 띄는 특징 중 하나는 Jails입니다. 이는 Docker보다 수십 년 앞선 OS 수준의 가상화 형태입니다. Docker가 주로 애플리케이션의 일시적이고 불변하는 "패키징"에 사용되는 반면, Jails는 동일한 커널을 공유하는 미니 가상 머신처럼 작동합니다. Jails는 높은 수준의 격리성을 제공하여 각 사이트가 자체 샌드박스에서 실행될 수 있도록 합니다. 만약 하나의 jail이 침해되면, 피해 범위는 제한적이며, 호스트나 다른 사이트에 영향을 주지 않고 jail을 파괴하고 다시 생성할 수 있습니다.
ZFS: 파일 시스템의 골드 스탠다드
또 다른 주요 동기는 ZFS였습니다. Btrfs와 같은 Linux 대안과 비교했을 때, ZFS는 훨씬 더 성숙한 것으로 널리 알려져 있습니다. 데이터 무결성을 처리하고 거의 즉각적인 스냅샷을 제공하는 능력 덕분에 VPS 제공업체의 유료 스냅샷 서비스에 의존하지 않는 백업 전략을 세울 수 있습니다.
아키텍처 및 구현
새로운 스택은 보안과 관리의 용이성을 보장하기 위해 리버스 프록시 아키텍처를 중심으로 설계되었습니다.
네트워킹 레이어
Jails가 격리된 상태를 유지하면서도 서로 통신할 수 있도록, 클론된 루프백 인터페이스를 사용하여 가상 네트워크 인터페이스 (bastille0)가 생성되었습니다. 트래픽은 FreeBSD의 강력한 방화벽인 **PF (Packet Filter)**를 통해 관리됩니다. 설정은 모든 들어오는 HTTP (80) 및 HTTPS (443) 트래픽을 기본 웹 서버가 위치한 특정 내부 IP (10.0.0.5)로 리다이렉트합니다.
Bastille를 이용한 Jails 관리
수동으로 jail을 생성하는 복잡함을 피하기 위해, 저자는 jail의 생명주기를 단순화하는 관리 프레임워크인 Bastille를 활용했습니다. Bastille를 사용하면 새로운 환경을 만드는 것이 다음과 같이 간단합니다:
bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
웹 스택: Caddy와 Nginx
- Caddy: 주요 진입점으로 사용됩니다. 에지 서버로서 Nginx 대신 Caddy를 선택한 이유는 SSL 인증서 발급 및 갱신을 자동으로 처리하여 manual
certbot설정의 필요성을 없애주기 때문입니다. - Nginx: 각 개별 사이트 (예: 블로그 또는 시위 페이지)는 자체 Nginx 인스턴스를 가진 자체 jail에 실행됩니다. 그러면 Caddy 서버가 트래픽을 이들 내부 jail IP로 리버스 프록시합니다.
성능 벤치마크
이동을 검증하기 위해, 저자는 Vultr VPS 인스턴스를 통해 여러 글로벌 위치 (London, São Paulo, Silicon Valley, and Tokyo)에서 wrk와 hey를 사용하여 광범위한한 load testing을 load testing을 수행했습니다.
결과
성능 차이는 극명했습니다. 과부하 상태 (100만 건의 요청과 10k의 동시 접속자)에서, 이전 Ubuntu 서버는 심각하게 고전하며 요청의 약 7%만 완료했습니다. 반면, FreeBSD 서버는 요청의 94%를 성공적으로 처리했습니다.
| Metric | Ubuntu 16.04 (Old) | FreeBSD 14.3 (New) |
|---|---|---|
| Success Rate | ~7% | ~94% |
| Requests/Sec | Lower | 3x to 11x Higher |
| Latency (p90) | Unpredictable | < 3.5s (Global) |
기술적 참고 사항: 저자는 FreeBSD 서버가 초기에는 기본 kern.ipc.somaxconn 제한인 128로 인해 10k 동시 접속 상황에서 실패했다는 점을 언급했습니다. sysctl을 통해 이를 16,384로 늘려 병목 현상을 해결했습니다.
비판적 관점 및 시사점
저자는 경험을 높게 평가했지만, Hacker News의 커뮤니티 토론은 중요한 반론을 제공했습니다:
- 벤치마크 타당성: 일부 사용자는 새 서버가 이전 서버의 1개 CPU 코어에 비해 4개의 CPU 코어를 가졌기 때문에 벤치마크가 왜곡되었으며, 현대적인, 적절하게 설정된 Ubuntu 설치본이 FreeBSD와 유사한 성능을 낼 것이라고 주장했습니다.
- "Uptime Trap" (가동 시간의 함정): 한 댓글 작성자는 극단적인 가동 시간의 위험성을 경고하며, 10년 동안 사이트를 운영했지만 하드웨어가 결국 교체될 때 설정을 어떻게 했는지 전혀 몰랐던 경험을 언급했습니다.
- 대안적 호스팅: 일부는 Hugo로 생성된 정적 사이트의 경우, GitHub Pages나 S3+CloudFront와 같은 무료 대안에 비해 VPS를 사용하는 것이 과도하다고 지적했습니다.
최종 생각
벤치마크에 대한 논쟁은 있었지만, 이번 마이그레이션은 강력한 학습 과정이었습니다. 이번 전환은 인프라를 코드로 관리하는 것의 가치와 "좀비" 서버에서 벗어나는 것의 이점을 강조했습니다. 한 사용자가 말했듯이, FreeBSD로의 마이그레이션은 "Linux가 무엇이었는지, 무엇인지, 그리고 FreeBSD의 놀라움에 대한 새로운 시각을 제공합니다."