많은 서버를 Linux에서 BSDs로 이전하는 이유와 방법
(it-notes.dragas.net)- Stefano Marinelli는 고객 문제 해결을 기준으로, 관리 중인 서버를 가능한 범위에서 Linux 중심 구성에서 FreeBSD·OpenBSD·NetBSD 등 BSD 기반 구성으로 되돌리고 있음
- 전환의 목표는 유행하는 배포 방식보다 안정성·업그레이드 용이성·구성 일관성·보안성을 높이는 데 있으며, 각 BSD를 역할에 맞게 나눠 사용함
- Proxmox 기반 하이퍼바이저 일부를 FreeBSD와 bhyve로 옮기고 VM 일부를 FreeBSD jails로 대체하면서, 호스트 리소스 사용과 I/O 병목이 줄어듦
- 한 고객 환경에서는 약 10개 VM을 가진 호스트 2대를 주말에 이전한 뒤 성능 향상을 고객이 먼저 알아챘고, 이후 20개 Proxmox 호스트를 단계적으로 옮겨 최종 호스트 수가 20대에서 11대로 줄어듦
- 현재 관리 중인 하이퍼바이저의 78%가 FreeBSD, 워크로드의 66%가 BSD 계열에서 실행되며, 성능·신뢰성에 대한 고객 반응도 긍정적임
문제 해결을 우선하는 운영 원칙
- Stefano Marinelli는 BSD Cafe의 창립자이자 Prodottoinrete에서 일하는 기술자로, 자신을 “문제를 해결하는 사람”으로 정의함
- 1996년부터 Linux를 사용했고, 2002년부터 FreeBSD를 본격적으로 탐색했으며, 2003년 졸업 논문에서는 오픈소스 시스템의 가상화를 다루며 NetBSD/Xen을 효율적인 해결책 중 하나로 테스트함
- 초기 직장 경험 이후 운영 원칙을 세움
- 특정 벤더에 묶이지 않음
- 고객에게 가장 적합한 솔루션을 권함
- 박스를 파는 것이 아니라 문제를 해결함
- 가능하면 오픈소스를 사용하고 장려함
- 적합한 곳에는 BSD를, 그렇지 않은 곳에는 Linux를 사용함
- 고객이 직접 접근하지 않는 영역에는 BSD를 적용하고, 고객이 명시적으로 요구하는 곳에는 Linux를 쓰는 방식으로 출발함
- NetBSD/Xen: 가상화 기반
- OpenBSD: 네트워크와 방화벽 진입점
- FreeBSD: ZFS 도입 이후 백업 서버 등 여러 서비스
Linux 비중이 커진 배경과 한계
- 한때 관리 환경은 약 65% BSD, 35% Linux였지만, Linux 인기가 높아지면서 고객 요구도 함께 늘어남
- Linux 가상화 솔루션이 성숙하면서 여러 호스트가 NetBSD/Xen에서 OpenNebula와 MooseFS, 이후 Proxmox와 Ceph 구성으로 이동함
- 이 이동의 배경에는 고객이 VM 생명주기, 설정 변경, 호스트 마이그레이션 등을 직접 관리해야 한다는 요구가 있었음
- Proxmox는 신뢰성과 안정성이 우수했고, 고객이 직접 관리해야 하는 VM은 Linux가 많았으며 일부는 FreeBSD였음
- 자체 인프라는 계속 주로 BSD 기반으로 유지됨
파일시스템과 데이터 손실 경험
- BSD 시스템에서는 백업에서 복구해야 할 정도로 데이터를 잃은 적이 없었음
- Linux에서는 ext4, XFS, btrfs에서 데이터 손실을 경험함
- XFS 사례는 몇 개 파일 손실에 그쳤고 백업으로 복구했지만, 요구 수준이 높은 고객에게는 좋지 않은 경험이었음
- btrfs 사례는 재부팅 후 미러 구성의 50TB 파일시스템이 더 이상 마운트되지 않는 장애였고, 별도 백업 덕분에 복구 가능했음
- btrfs 장애 이후 해당 서버는 FreeBSD와 ZFS 기반으로 처음부터 재구축됐고, 그 뒤로 단일 비트도 잃지 않았다고 함
컨테이너와 유행 기술에 대한 거리두기
- 2018년부터 특정 요구가 있는 개발자들에게 Docker와 Podman을 도입했으며, 주된 목적은 개발 지원이었음
- 일부 개발자는 기존 설정의 제한을 우회하기 위해 Docker를 요구했고, 그 제한 중 일부는 오래된 소프트웨어와 라이브러리를 계속 쓰려는 나쁜 관행에 가까웠음
- Docker와 Podman은 빠른 배포와 보안 강화에 유용하지만, 항상 최선도 아니고 유일한 선택지도 아님
- Linux 생태계는 최근 몇 년간 크게 발전했지만, 일부 배포판과 커뮤니티는 실질적 이익보다 새것으로 바꾸는 흐름에 더 집중하는 듯 보였음
- Docker Compose 파일만으로 배포되는 소프트웨어가 흔해졌고, 특정 패치 파일이나 의존성 버전에 기대는 불안정한 조합도 존재함
- 빠른 배포와 단순화를 위해 구조적 문제를 덮어두면, 오래 안정적으로 운영해야 하는 워크로드에서는 문제가 더 커질 수 있음
BSD 비중을 다시 높인 이유
- 몇 년 전부터 가능한 모든 워크로드에 BSD를 우선 적용하는 방향으로 비중을 뒤집기로 결정함
- 목표는 안정적이고 일관되며 업그레이드하기 쉽고 안전한 시스템을 만드는 데 있었음
- 각 BSD는 서로 다른 역할을 맡음
- OpenBSD: 추가 패키지 없이 필요한 구성을 끝내는 경우가 많고, 업그레이드가 단순하고 안전함
- NetBSD: 새 버전을 서두르지 않으며, 필요한 패키지 업데이트와 보안 패치만으로 수년간 운영 가능한 시스템으로 사용함
- FreeBSD: ZFS, bhyve, 성숙한 네이티브 jail 시스템을 기본 구성 요소로 제공함
- FreeBSD에서는 ZFS와 boot environments 덕분에 업그레이드 시 심리적 안정감이 커짐
- BSD들은 순간적 유행을 좇기보다, 초기 Linux처럼 일관성과 안정성을 중시하는 시스템으로 받아들여짐
실제 마이그레이션 방식
- 초기 대상은 곧 업데이트가 필요하거나, 이전 예정이거나, 문제를 일으켜 깊이 살펴볼 가치가 있는 시스템이었음
- 고객이 직접 접근하지 않는 하이퍼바이저, 특히 임대 서버를 먼저 FreeBSD로 옮김
- 마이그레이션은 비교 가능한 쌍둥이 머신을 만들고 FreeBSD를 설치한 뒤, 프로덕션 서버와 브리지로 연결하고 vm-bhyve를 설치하는 방식으로 진행함
- Proxmox의 VM은 주요 설정을 재구성하면서 복사함
- Proxmox에서 이미 ZFS를 쓰는 경우에는 zfs send/receive가 첫 단계였음
- Ceph를 쓰는 경우에는 스토리지를 ZFS로 라이브 마이그레이션한 뒤 같은 절차를 적용함
- 첫 번째 가시적 효과는 VM 트래픽 처리를 위한 호스트 리소스 사용 감소였음
- I/O 성능도 크게 좋아졌고, 가상 디스크 드라이버를 virtio에서 NVMe로 바꾸면서 추가 개선이 있었음
- 부하가 큰 I/O 상황에서 FreeBSD는 Linux VM보다 덜 막히는 모습을 보였고, 로드도 크게 낮았음
고객 환경에서 확인한 결과
- 한 고객 환경에서 각각 약 10개 VM을 가진 호스트 2대를 주말 동안 이전함
- 고객은 화요일에 성능이 크게 좋아진 것을 알아채고, 승인 없이 하드웨어를 업그레이드한 것인지 걱정해 연락함
- 설명을 들은 뒤 고객은 추가 테스트와 전체 이전을 요청했고, 총 20개 Proxmox 호스트가 단계적으로 이전됨
- 많은 VM은 PHP 웹사이트, Tomcat 기반 Java 관리 시스템, 산업 장비 모니터링 소프트웨어 같은 단순 워크로드였음
- 환경과 의존성 분리가 목적이던 VM은 FreeBSD jails에 잘 맞았음
- 일부는 Linuxulator를 사용해 Linux jails 안에서 실행함
- 불가능한 경우에는 개별 jail 안에 구성을 다시 만듦
- VM과 OS의 이중 버퍼링을 피하면서 RAM을 ZFS 캐시와 다른 서비스에 활용할 수 있었고, 작업 속도도 빨라짐
- 일부 VM, 예를 들어 Zimbra는 VM으로 남김
- 최종적으로 VM 수가 크게 줄고 jails로 대체되면서 호스트 수도 20대에서 11대로 감소했고, 월 비용이 크게 절감됨
- 다른 사례에서는 약 18분 걸리던 작업이 평균 6분 정도로 줄었다고 추정했으며, 주요 요인 중 하나로 bhyve의 NVMe 드라이버를 의심함
기술보다 어려운 이념과 판매 논리
- 주요 도전은 기술 자체보다 특정 솔루션만 정답이라고 믿는 이념적 고정관념인 경우가 많음
- 과거에는 VMware가 필수라고 여겨져 Proxmox를 설득해야 했지만, 지금은 Proxmox가 널리 회자되며 또 다른 유행이 됨
- 어떤 경우에는 5년에 한 번 업데이트될 법률사무소 웹사이트에도 Kubernetes 기반 클라우드 클러스터가 제안됨
- “누가 관리할 것인지”, “데이터가 실제로 어디에 있고 누가 지킬 것인지”를 물으면 충분히 고려하지 않은 경우가 많았음
- 단순한 솔루션은 장기 유지와 관리가 쉽고, 1년·5년·10년 뒤 다시 돌아와 업데이트하고 안정화하기도 수월함
- Kubernetes 클러스터는 훌륭하지만 유지보수가 필요하며, 외부화하면 데이터 통제권을 잃을 수 있음
- 상업적으로는 Linux와 “Cloud”가 잘 팔리지만, NetBSD 기반 솔루션은 현재 판매 매력이 낮음
- 의사결정자에게 기술 지식이 거의 없을 때는 대안의 장점보다 판매하기 쉬운 항목이 우선될 수 있음
운영 중 드러난 차이
- BSD 시스템은 업데이트나 단순 재부팅에서 예기치 않은 놀라움을 준 적이 없다고 함
- Linux에서는 네트워크 인터페이스 이름이 바뀌어 서버에서 사실상 잠기는 상황을 예로 듦
- 예:
enx3e3300c9e14e에서enp10s0f0np0로 변경 - OpenBSD/FreeBSD 계열에서
ix0는 계속ix0로 남는다는 점과 대비됨
- 예:
- FreeBSD에서는 ZFS를 다시 컴파일한 뒤 모듈이 로드되지 않아 재부팅 후 파일시스템 마운트가 막히는 상황을 겪지 않았음
- 협업하는 개발자 다수는 새로운 운영 방식을 긍정적으로 받아들임
- 실험 후 거의 모두가 긍정적이었고, Docker 호스트 대신 jails를 명시적으로 요청하기 시작함
- BastilleBSD로 템플릿 jail을 복제하고 배포함
- ZFS 자동 스냅샷에 접근해 잃어버린 파일을 복구하는 방법을 익힘
- 문제마다 더 많은 자원을 요구하기보다 실제로 무슨 일이 일어나는지 이해하려는 방식으로 돌아감
- 일부는 어려움을 겪었지만 긍정적인 태도를 유지했으며, 모든 사람에게 같은 해결책을 강요할 수는 없음
컴플라이언스와 체크리스트의 충돌
- Linux는 많은 컴플라이언스 요구의 기본 대상으로 취급되며, OpenSSH 버전을 묻는 경우가 많음
- OpenBSD의 최신 OpenSSH를 쓰고 있어도 절차상
OpenSSH_9.2p1 Debian-2+deb12u3같은 형식과 맞지 않으면 “안전하지 않다”고 불평하는 사례가 있음 Debian부분이 릴리스가 아니라 Linux 배포판을 가리킨다고 설명해도 이해하지 못하는 경우가 있음- 이런 문서를 준비하는 사람은 자신이 무엇을 요구하는지 모른 채 체크리스트만 따르는 경우가 많음
현재 진행 상황
- 전환은 계속 진행 중이며, 기회가 보이면 Linux에서 BSD로 가능한 범위에서 이전하고 있음
- 현재 관리 중인 하이퍼바이저의 78%가 FreeBSD에서 실행됨
- VPS, jails, hosts 등을 포함한 워크로드의 66%가 BSD 계열에서 실행되며, OPNsense 같은 솔루션도 포함됨
- 고객들은 주요 문제를 겪지 않았고, 성능이나 신뢰성에 대해 불평하지 않았으며, 피드백은 모두 긍정적이었음
- 최근 심각한 SSH 취약점 이후 일부 고객은 걱정해 연락했지만, 노출된 SSH 서비스가 OpenBSD 버전이라 영향을 받지 않는 경우가 있었고 이를 긍정적으로 받아들임
- 일부 고객은 OpenBSD 기반 구성을 더 원하게 됨
댓글과 토론
Hacker News 의견들
-
Linux, FreeBSD, NetBSD, OpenBSD를 재미와 학습, 그리고 수익 목적으로 모두 사용하고 있음
적어도 BSD 하나쯤 익혀두면 Linux에 대한 지식도 예상 못 한 방향으로 넓어질 가능성이 큼
예를 들어 FreeBSD 덕분에 커널 개발, 전체 시스템 디버깅, 네트워크 스택 개발, 드라이버 개발, 시스템 전체가 어떻게 맞물리는지까지 배우게 됐고, 그 기술은 Linux로도 꽤 잘 오갔음
개인 인프라에는 FreeBSD를 주로 쓰는데, 시간이 지나도 단순하고 덜 놀라움.ifconfig는 여전히ifconfig이고 잘 동작하며,rc.d면 개인 용도에는 충분함
tunables와sysctl같은 방식으로 하드웨어와 커널 설정을 체계적으로 관리하는 점도 좋고, 매뉴얼 페이지는 신규 사용자와 오래된 사용자 모두에게 계속 유용함
물론 흠도 있고 커뮤니티 마찰도 있음. 데스크톱과 일부 개발자 경험은 기여자·사용자 규모 때문에 Linux보다 계속 뒤처질 가능성이 크고, BSD 일자리 시장도 Linux에 비해 매우 작음
그래도 전부 아니면 전무의 문제가 아니며, 중요한 운영 환경에서는 가용성과 제로데이 완화를 위해 이중 스택을 두는 게 이상적이라고 봄- FreeBSD가 시간이 지나도 단순하고 덜 놀라우며
ifconfig와rc.d만으로 충분하다는 점이 매우 끌림
소수의 서버를 계속 돌려야 하지만 주업은 아니라서 가능한 한 시간을 덜 쓰고 싶음
서버에는 가볍고 단순해서 Alpine Linux를 쓰기 시작했는데, 다음 단계가 BSD일 수도 있겠음 - Linux가 내부에서 어떻게 동작하는지 깊이 이해하고 싶다면 Linux From Scratch를 강력히 추천함
20년 전 처음 살펴봤을 때 시스템에 대한 귀중한 통찰을 줬고, 미리 패키징된 배포판이나 libc에 의존하지 않고 바닥부터 만드는 경험이 큰 전환점이었음
https://www.linuxfromscratch.org/ - FreeBSD를 정말 즐겁게 썼음. 배포판이 아니라 완전한 운영체제이고, 소스에서 전체를 쉽게 다시 빌드할 수 있음
사람들도 좋고 기술도 괜찮음
행사는 곧 열림: https://freebsdfoundation.org/news-and-events/event-calendar...
Fall 2024 FreeBSD Summit, 2024년 11월 7–8일, San Jose, CA - FreeBSD가 좋은 이유로 설계 선택에 놀랄 일이 적고 대체로 말이 된다는 얘기는 많이 하지만, 업데이트에 놀라지 않는 즐거움은 충분히 말하지 않는 듯함
이번 주말에 13.2에서 14.1로 올릴 예정인데, 새 오디오 하위 시스템을 설정해야 하거나, 시작 스크립트를 새 서비스 관리자 패러다임에 맞게 바꿔야 하거나, 프로그램 절반이 새 유사 컨테이너 패키지 형식 때문에 갑자기 느려질 걱정은 안 해도 된다고 꽤 확신함 - BSD에서 네트워크 스택과 드라이버 개발에 입문할 때 어떤 프로젝트를 했는지 궁금함
- FreeBSD가 시간이 지나도 단순하고 덜 놀라우며
-
btrfs를 많이 관리하는 입장에서는 50TB 파일시스템이 정말 복구 불가능했다는 얘기가 꽤 믿기 어려움
btrfs는 무서운 상황에 빠지기도 하지만, 약간의 노력으로 다시 빠져나오는 경우도 많음
여기서 “문제를 해결한다”는 결국 “문제를 날리고 새로 시작한다”였던 셈이고, 언제나 그게 더 쉬움. 고객이 이해해줘서 다행임- 4년 동안 업무에서 매일 btrfs를 쓴 입장에서는 그 얘기가 100% 믿김
틀렸다는 뜻은 아니고, 경험은 크게 다르며 사용 패턴이 보편적이지 않을 수 있다는 뜻임
21세기에 써본 파일시스템 중 가장 신뢰하기 어렵고 불안정했음 - 항상 그런 건 아니었음. BTRFS 신뢰성은 10~15년 전만 해도 지금과 꽤 달랐던 것으로 기억함
글도 그 옛날 시기를 다루고 있으니 크게 무리한 얘기는 아님
그 무렵 SLES가 btrfs를 기본 파일시스템으로 삼았는데, 사용자 문제가 너무 많아서 거의 즉시 결정을 되돌렸음 - 홈랩에서 btrfs는 만족스러웠음. 12TB raid1을 썼고, 백플레인에 연결된 PSU 레일이 부하 중 가끔 내려갔음
무서운 오류는 많았지만 아무것도 잃지 않았고, 원인을 찾아 PSU를 교체하는 데 두 달 걸림 - btrfs가 데이터가 온전하다는 걸 알고 있다면, 자동 복구해야 하는 것 아닌가?
- 왜 btrfs나 비슷한 파일시스템을 운영 환경에 쓰는지 모르겠음
완전히 쓰레기통 수준은 아니지만, 인터넷에는 “X가 일어났고, 그다음 Y를 깨달았으며 데이터를 되찾을 수 없었다”는 이야기가 널려 있음
- 4년 동안 업무에서 매일 btrfs를 쓴 입장에서는 그 얘기가 100% 믿김
-
아이디어는 좋고 더 배우고 싶지만, “미리 테스트하지 않고 옮겼더니 어쩐지 더 빨라졌다”처럼 보임
원인이 메모리 할당인지, 디스크 지연인지, 하이퍼바이저인지, 다른 방법으로도 재현 가능한지 알 수 없음
읽기는 재미있었지만 근거와 이해가 빠져 있었고, 이런 변경을 하기 전에 더 깊이 조사했으면 함
Linux와 BSD에서 데이터베이스를 비교한 벤치마크를 찾아보면 실제로는 훨씬 미묘하고, 설정과 테스트 대상에 따라 양쪽 결과가 모두 나옴- 비슷한 구성을 20년 동안 쓰고 비교 테스트한 뒤의 결과임
솔직히 벤치마크는 매우 특정한 조건에 묶인다고 봐서 항상 큰 비중을 두지 않았고, 관심은 현실의 사용 사례에 있음
발표와 글의 목적은 모든 구성을 이전하라고 권하는 게 아니라, 경험과 얻은 결과를 공유하고 BSD를 각자 목적에 맞게 써보도록 장려하는 것임
BSD가 최고의 해법이라는 뜻은 아니며, 모든 문제에 맞는 보편 해법은 없지만 선택지가 넓은 건 긍정적임
- 비슷한 구성을 20년 동안 쓰고 비교 테스트한 뒤의 결과임
-
“아무것도 안 돌아가면 내가 왜 돈을 주지? 모든 게 돌아가면 내가 왜 돈을 주지?”라는 말은 케인스 경제학을 모르는 사람의 말임
https://www.youtube.com/watch?v=9OhIdDNtSv0
https://www.youtube.com/watch?v=NO_tTnpof_o
사람에게 필요한 건 배를 채울 음식과 하루 끝에 쉴 곳뿐이고, 나머지는 허영임
전 세계 GDP 중 기본적인 물질적 필요를 충족하는 데 쓰이는 비중은 얼마나 될까?
대부분은 불필요함. 1970년대 이후 생산성은 크게 올랐지만, 현재 미국 젊은 세대는 같은 나이의 부모·조부모 세대보다 더 가난함
그렇다면 IT 최적화가 가져오는 건 무엇인가? 소유자에게 더 많은 부를 주고, 직원들에게는 정리해고를 줄 뿐임
IT 종사자들은 장기적으로 자신들의 활동이 부를 늘려주지 않는다는 걸 이해해야 함. 이들은 자신이 최적화하는 생산수단을 소유하지 않는 한, 자기 일자리를 없애는 몇 안 되는 직업군임
그 생산수단은 고용주가 소유함- IT 업계 사람들의 문제는 자신이 최적화 곡선보다 앞서 있다고 생각한다는 점이고, 모두가 그렇게 생각하니 아무도 앞서 있지 않음
- 그 점은 잘 이해하지만 갇혀 있음. 40대보다 50대에 더 가까워졌고, 가족을 책임져야 함
다른 직업에 관심이 있을 수는 있지만, 새 직업을 배우려고 일을 그만두면 일상과 저축이 무너짐
현실적으로 배울 수 있으면서 매달 비슷한 돈을 가져다줄 다른 직업도 없음. 혼자 살면 생활수준을 낮출 수 있겠지만, 가족이 있으면 어떻게 그렇게 하겠나?
게다가 “돈 많이 주는 영혼 없는 소프트웨어 일”과 “돈은 적지만 영감을 주는 소프트웨어 일” 사이의 전환 같은 건 없음. 영혼 없는 일만 있고 돈의 액수만 다름
일은 어디서나 힘들고, 변수는 보상뿐임. 최선이라야 “덜 끔찍한” 일을 찾는 정도임
십대였을 때 프로그래밍이 이렇게 잔혹한 일상 노동으로 변할 거라고는 상상도 못 했음
중년의 위기는 사물을 보는 방식을 바꿔놓음. 일에서 더 많은 의미를 원하지만, 사회는 생계와 의미를 극단적으로 분리해놨고 빠져나갈 길이 없음
실제든 상상이든 책임이 우리를 붙잡고 있음. 직업 인생을 재시작하고 싶지만 위험이 너무 큼
그래도 흥미로운 업무는 여전히 고맙게 여기며, 세부에 파고들면 적어도 잠시나마 모든 게 얼마나 무의미한지 잊을 수 있음 - 현재 미국 세대는 음식과 주거만 얻기에는 충분히 부유함
힘들어하는 사람들은 대개 음식과 주거를 넘어선 개선된 삶이 있는 인기 도시에서 살고 싶어하기 때문임
1950년대 집들은 품질이 형편없었고 미국 전역에 퍼져 있었음. 지금도 사람들이 살고 싶어하지 않는 98% 지역에서는 그런 집을 싸게 살 수 있음 - “나만의 철학을 따르며 나 자신을 위해 일하겠다”는 말이면 충분히 이해한 것 같음
그는 생산수단을 소유하고 있음
-
FreeBSD에서 Linux로 옮겼는데, 주된 이유는 Java 지원이 좋지 않았고 Linux가 훨씬 더 인기 있어지면서 소프트웨어 가용성 차이가 커졌기 때문임
- FreeBSD도 Java 지원이 꽤 괜찮지 않나?
새 LTS 릴리스가 나오면 FreeBSD로 이식되기까지 몇 달 걸리는 정도가 전부 아닌가 싶음
- FreeBSD도 Java 지원이 꽤 괜찮지 않나?
-
최근 systemd-nspawn을 알게 됐는데, LXC의 대안이고 systemd에 내장·통합되어 있음
전체 가상 머신보다 훨씬 가볍고 Solaris Zones나 FreeBSD jails와 꽤 비슷함
한 가지 사용법은 OCI(Docker) 이미지를 경로에 풀어놓는 것으로, 그러면 Docker, Podman 등이 제공하는 컨테이너 도구를 재사용할 수 있음
BSD는 거의 만져보지 않았고 Solaris도 마지막으로 쓴 지 몇 년 됐기 때문에 사용자 입장에서 제대로 비교하기는 어려움 -
최근 3~4년 사이 꽤 충성도 높은 OpenBSD 사용자가 됐음
기본 OpenBSD 설치에는 상당한 네트워크 기능이 포함되어 있고, 구현도 깔끔함
너무 깔끔해서 설치 후 패키지를 잔뜩 추가해 어지럽히기 시작하면 약간 죄책감이 들 정도임
저장소 요구사항이 더 복잡했다면 FreeBSD ZFS를 썼겠지만, 내 modest한 필요에는 UFS로 충분함
데스크톱, 웹, 메일 서비스에 OpenBSD를 사용함. 한계는 있지만 다른 BSD나 Linux 배포판을 굴릴 만큼 심각한 건 없음 -
SOHO 용도라면 docker compose도 충분히 실용적이고, 백업·마이그레이션·새 서버 이전을 단순하게 해주는 경우가 많다고 봄
많은 앱은 좋은 백업 전략이 있는 단일 인스턴스만 있으면 되고, 핫 페일오버 인스턴스까지 필요하지 않음
1~2년에 한 번 필요할 때 한 시간 정도 중단은 감당할 수 있고, 실제로 그런 일도 드뭄
글에서 말한 것처럼, 서비스와 의존성의 실제 Dockerfile들이 널리 제공된다는 전제라면 괜찮은 지침 묶음 역할도 함
PostgreSQL compose 인스턴스를 전용 서버의 새 계정·데이터베이스로 바꾸는 것도 비교적 쉬움
redis, rabbitmq 같은 앱 중심이 아닌 서비스도 비슷함. 전부 도입할 수도, 일부만 도입할 수도 있고, 어느 쪽이든 상당 부분 자체 문서화가 됨 -
XFS 장애에 대해 조금 더 써줬으면 함
아주 오랫동안 XFS를 쓰고 있는데 아무 문제도 없었음- 나도 궁금함. 개인 장비에서도 회사 고객 컴퓨터의 모든 데이터에도 XFS만 수년째 쓰고 있음
예전에 광범위한 테스트를 했고, 막대한 데이터를 쓰고 읽을 때 선형적이고 지속적으로 매우 높은 성능을 내며, 파일 수가 엄청나게 많아져도 성능이 떨어지지 않았던 유일한 파일시스템이 당시 XFS였음
실시간 데이터라 성능 하락은 절대 안 됐는데, 고객이 XFS 문제로 데이터를 잃은 적은 한 번도 없음
다만 SGI 장비에서는 XFS 손실이 일상적이었음. 한 페이지짜리 텍스트 파일에 몇 초마다 계속 쓰다가 전원을 껐다 켜면 파일이 비어 있는 유명한 상황이 있었음
Linux에서는 이런 일이 일어나지 않음. 몇 년 전 누군가와 이 얘기를 했던 것 같은데, SGI가 XFS를 Linux로 옮길 때나 그 직후 무언가 바뀐 것 같음 - 데이터 손실 시점을 알기는 어렵지만 오래전 일이라고 봄
XFS는 원래 SGI IRIX에서 왔고 고급 하드웨어에서 돌도록 설계됐음. SGI가 1999년에 Linux에 기증했고, 많은 가정을 그대로 가져왔음
예를 들어 SGI 장비에는 캐시가 달린 하드웨어 RAID가 있었고, 이는 자체 메모리를 가진 내장 컴퓨터에 가까웠음
그 캐시는 배터리 백업이 있어서 시스템 충돌이나 갑작스러운 전원 손실이 있어도 쓰기를 마칠 만큼 살아 있었음. SGI는 사용할 수 있는 하드웨어 종류를 강하게 통제했고 보통 품질도 좋았음
범용 PC 기반 서버 환경은 흔히 그렇지 않았음. 보통 IDE나 SATA 하드디스크뿐이었고, 그 디스크들은 거짓말을 했음
싼 하드웨어의 펌웨어는 실제로 쓰기를 마치지 않았는데도 완료됐다고 보고했고, 벤치마크에서 더 빨라 보이게 만들었음
Linux로 비용을 아끼려는 소비자와 기업은 대체로 벤치마크상 가장 싸고 빨라 보이는 것을 샀음
그래서 하드웨어 장애나 갑작스러운 전원 손실이 있으면 파일시스템은 안전하게 디스크에 쓰였다고 생각했지만 실제로는 아직 진행 중인 쓰기가 몇 MB 남아 있을 수 있었음
초기 Linux XFS에서는 그래서 데이터 손실 가능성이 분명히 있었고, 2000년대 초반 Linux XFS에서 그런 문제를 겪었음
Ext4를 계속 쓰는 큰 장점은 강력한 복구 도구가 많았다는 점임. Ext4가 데이터베이스 호스팅에서 빠른 건 어느 정도 운이지만, 진짜 이유는 가장 싸고 형편없는 개인용 PC 하드웨어를 쓴다는 가정으로 처음부터 설계됐기 때문임
하지만 현대 XFS는 완전히 다른 물건임. SGI에서 이식된 원본에 비해 광범위하게 다시 쓰이고 크게 개선됐음
그래서 2005년이나 2010년의 경험은 지금 별 의미가 없음
파일시스템에 대한 깊은 기술 지식은 없지만, FreeBSD의 UFS는 쓰기 전에 기록할 내용을 남기는 쓰기 전 로그를 쓰는 것으로 이해함. XFS나 Ext4의 저널링보다 단순하지만 더 견고한 해법일 수 있고, 대신 성능을 내주는 구조라고 봄
ZFS와 Btrfs라면 Btrfs는 되도록 피하고 싶음. OpenSUSE, Fedora 같은 배포판이 기본으로 쓰지만, 개인 장비에서는 그냥 단일 파티션을 Ext4나 XFS로 포맷함
개인 파일 서버에서는 UPS와 함께 아주 단순한 구성으로 쓰긴 함. ZFS는 쓰지 않지만, btrfs는 ZFS 수준에 도달하지 못했다고 강하게 의심함
Linux가 ZFS 수준의 무언가 없이도 계속 쓰이는 이유 중 하나는, 대형 기업 고객에게는 ZFS 기능 대부분이 중복되기 때문임
이들은 보통 ZFS가 나오기 전부터 ZFS 비슷한 기능을 제공하던 비싼 SAN이나 더 고급 NAS의 독점 저장소 솔루션을 씀
그 위에 ZFS처럼 복잡한 것을 얹어도 이득이 거의 없음
또는 Linux 클러스터 파일시스템 솔루션 중 하나를 쓰는데, 선택지는 넓음 - 몇 년 전 CentOS 7의 Jenkins 장비에서 inode가 바닥나 시스템이 죽고 파일시스템을 다시 마운트하지 못한 적이 있음
파일이 엄청나게 많은 4TB 볼륨이라 백업 복구에 시간이 많이 걸렸음 - 90년대 후반부터 IRIX에서 XFS를 썼고, 초기에 endian 변환 관련 문제가 몇 개 있었던 것 같지만 지난 20년 가까이는 별문제가 없었음
- 나도 궁금함. 개인 장비에서도 회사 고객 컴퓨터의 모든 데이터에도 XFS만 수년째 쓰고 있음
-
여기서 주요 BSD들이 모두 쓰이는 걸 보니 반가움
의미가 맞을 때마다 OpenBSD를 사용함- 실제로 공개 서비스 대부분은 OpenBSD에서 호스팅하고, 라우터와 방화벽은 전부 OpenBSD로 돌림
배포 대상의 호스트 운영체제를 최대한 신경 쓰지 않기 위해 모든 것을 Ansible로 관리하기 시작했고, 실험적으로 OpenBSD나 NetBSD로 옮길 때도, BSD 대 GNU 문제인지 특정 배포판 문제인지 확인하려고 여러 Linux 배포판에 테스트를 세울 때도 잘 동작했음
다른 도구 대신 Ansible을 고른 첫 번째 이유는 BSD 지원이었음
- 실제로 공개 서비스 대부분은 OpenBSD에서 호스팅하고, 라우터와 방화벽은 전부 OpenBSD로 돌림