▲

FreeBSD 개발에 대한 1년 간의 후원

 (daemonology.net)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Amazon의 후원을 받아 1년 동안 FreeBSD 릴리스 엔지니어링과 FreeBSD/EC2 개발을 진행함
  • 릴리스 관리와 EC2 관련 개선을 병행하며 월 평균 50시간의 작업 시간을 투입함
  • Graviton 인스턴스 전원 관리, 핫플러그 지원, 부팅 성능 개선 등 주요 기능 문제와 품질 향상을 달성함
  • AMI 종류 확장 및 빌드 자동화로 FreeBSD AMI 배포의 다양성과 효율성을 높임
  • 후원 종료 후에는 개발 속도 둔화와 일부 기능 개발 정체 현상이 예상됨

FreeBSD 개발 후원 1년 회고

# 시작 배경 및 후원 과정

  • FreeBSD/EC2 플랫폼을 2010년부터 관리해왔으며, 2023년 11월부터 FreeBSD 릴리스 엔지니어링 리드 역할도 수행함
  • Antithesis, Patreon 등에서 소액 후원 중이었으나, 릴리스 엔지니어링 업무가 FreeBSD/EC2 개발 시간을 크게 잠식하는 상황에 직면함
  • Amazon 측과 수년 간 EC2 작업에 대한 스폰서 논의를 이어왔으며, 2024년 4월에 예산 확보 담당자와 연결되어 1년간 후원을 받게 됨
  • 후원은 GitHub Sponsors 경로로 집행됐으며, Amazon 의도한 기간과 실제 입금 시점은 다를 수 있음

# 후원과 작업 시간 분배

  • Amazon의 요청으로 매월 40시간의 FreeBSD 릴리스 엔지니어링 및 EC2 개발 시간을 제공하기로 약속함
  • 실제로는 월별로 50시간 정도를 투입했으며, EC2 이슈에 20시간, 릴리스 작업에 20시간, 기타 엔지니어링에 10시간을 분배함
  • 월별로 작업 시간이 크게 변동함

# FreeBSD 릴리스 관리

  • FreeBSD 분기 릴리스 일정을 도입·관리하면서 1년간 4차례 릴리스를 수행함: FreeBSD 13.4(2024.9), 14.2(2024.12), 13.5(2025.3), 14.3(2025.6 예상)
  • 각 릴리스에는 개발자 코드 마감 독려, 머지 요청 승인 및 조율, 이미지 빌드·테스트, 안내문 작성, 각종 릴리스 빌드 오류 수정이 포함됨
  • 릴리스 엔지니어링 소요 시간은 분기마다 33.5~79시간 수준이며, 후반부로 갈수록 안정화로 작업량이 감소하는 패턴임

# 주요 EC2 기능 개선 및 품질 향상

Graviton 인스턴스 전원 드라이버, 핫플러그 지원

  • Graviton 인스턴스에서 EC2 API의 정상 종료 신호를 FreeBSD가 인지하지 못하던 문제를 해결

    • ACPI _AEI 오브젝트를 활용, GPIO 기반 "power button" 신호와 드라이버 로직을 연결
    • EC2 제공 ACPI 테이블의 Pull Up 플래그 설정 불일치로 인한 장치 비활성화 문제는 FreeBSD/EC2 AMI에 ACPI_Q_AEI_NOPULL 설정 추가로 대응

  • EC2 Graviton 및 x86 인스턴스의 장치 핫플러그(특히 핫 언플러그) 문제들을 복합적으로 진단 및 수정

    • IRQ 누수, PCI 전원 상태와 OS 신호 불일치, "유령" PCI 장치 등 다양한 유형의 버그에 대응
    • 임시 방편으로 ACPI 퀴르크(예: ACPI_Q_CLEAR_PME_ON_DETACH, ACPI_Q_DELAY_BEFORE_EJECT_RESCAN) 적용, EC2 쪽 버그는 수정 예정

핫플러그 테스트 자동화 및 품질 개선

  • EC2 환경에서 반복적으로 EBS 볼륨을 연결·해제하는 스크립트를 개발, 300회 연속 테스트를 통한 안정성 검증
  • PCIe 핫플러그의 불필요한 5초 지연(물리 시스템에서만 의미 있음)을 EC2에서는 0초로 설정하여 품질 향상

부팅 성능 개선

  • FreeBSD/EC2 부팅 속도 이슈를 데이터 수집 및 분석으로 체계적으로 개선
  • 2024년 초 루트 디스크 용량 증설로 부팅 3배 지연, Graviton2 인스턴스의 커널 엔트로피 시딩 지연, ZFS 부팅 시간 증가, IMDSv2 관련 IPv6 지원 문제 등을 순차적으로 해결
  • 파일시스템별 부팅 성능 격차, 엔트로피 수급 비효율, 네트워크 초기화 지연 등 다방면에서 최적화 이루어짐

# FreeBSD AMI 다양성 확대 및 빌드/배포 자동화

  • 기존 base, cloud-init AMI 외에 small AMI(불필요한 디버깅·테스트 코드/툴 제거, 1GB 크기) , builder AMI(사용자 커스텀용 빌더) 를 추가
  • 4종류 AMI * 2파일시스템(UFS/ZFS) * 2아키텍처(amd64/arm64) * 3버전(13, 14, 15)으로 이미지 조합이 확대되면서 오래된 이미지 자동 삭제 및 스크립트화 진행, 336TB EBS 스냅샷 정리

# 엔지니어링 일반 개선

  • FreeBSD AMI/릴리스 빌드의 병렬화로 전체 빌드 시간을 약 22시간→13시간으로 단축, 더 많은 AMI 종류 추가에 여유 확보
  • EC2 인스턴스 기반 자동화 테스트 및 diffoscope 비교로 빌드 재현성(리프로듀서블 빌드) 문제 진단 및 해결 진행
  • ENA 드라이버 패치 리뷰, OCI 컨테이너 빌드 및 레지스트리 업로드, AWS 관련 툴 개선, 보안 이슈 리포트 등 다양한 소규모 업무 병행

# 앞으로의 전망 및 한계

  • FreeBSD 릴리스 엔지니어링 및 EC2 플랫폼 유지 역할은 유지하나, 이전보다 투입 가능한 시간이 줄어들 전망
  • FreeBSD 15.0(2024년 12월), 14.4/15.1/14.5/15.2(2026년) 릴리스는 예정대로 진행, 단 기능 추가/버그 수정 속도는 저하될 것으로 보임
  • 자동 파일시스템 확장, 다중 NIC 및 핫플러그 자동화, 미리 패치된 AMI 배포, EC2 사용자 웹툴, FreeBSD/Firecracker 지원 등 미완 과제는 장기적으로 정체 예상

# 맺음말

  • Amazon의 위 후원은 오픈소스 개발자에겐 극히 드문 기회이며 그 동안의 성과에 자부심과 감사를 느낌
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 오늘 ziglang.org 다운로드 페이지에 FreeBSD가 추가된 소식 공유, 이제 FreeBSD 사용자는 CI에서 자동으로 빌드된 마스터 브랜치 빌드를 쉽게 받을 수 있음
    FreeBSD가 이제 공식적으로 크로스 컴파일 타겟으로 완전히 지원됨, zig cc -o hello hello.c -target riscv64-freebsd처럼 리눅스와 비슷하게 FreeBSD를 타겟하여 컴파일 가능
    C/C++ 의존성이 있다면 zig 빌드 시스템으로 쉽게 가져오고 빌드 가능, 덕분에 꽤 복잡한 프로젝트도 손쉽게 FreeBSD 크로스 컴파일 가능
    이로 인해 더 많은 프로젝트가 FreeBSD 지원 및 테스팅을 CI에 추가하기를 바라는 마음

    • Zig의 크로스 컴파일 기능이 정말 멋지다는 이야기, 그리고 FreeBSD가 지원 타겟에 추가된 점이 반가움

  • 읽으면서 재밌는 부분이 많았음
    2024년 첫 주부터 FreeBSD 부팅 프로세스가 갑자기 3배 느려졌다는 사례, 커밋을 계속 추적한 끝에 원인이 5GB에서 6GB로 루트 디스크 크기가 늘어난 거였음
    아마존 친구에게 문의해보니 답변이 무슨 마법이라도 된 듯 “정확히는 알지 못하지만, 그냥 모르는 게 나을듯” 식이었음
    중요하게도 루트 디스크 크기를 8GB로 늘리자 성능이 예전 수준으로 복구됨

    • 이런 얘기를 들으니 이제 정말 무슨 이유인지 알고 싶어지는 마음

    • 이런 문제를 찾기 위해 커밋 바이섹팅하는 데 실제로 시간이 얼마나 들었을지 궁금함
      매번 이미지를 만들어 VM을 재부팅했는지 궁금한 상상

    • S3의 오리지널 오브젝트 크기 제한이 5GB였다는 본인 2006년 블로그 글 언급
      https://aws.amazon.com/blogs/aws/amazon_s3/
      이것이 FreeBSD 성능이 느려진 현상과 직접 관련이 있는지는 모름

  • 노트북 지원 관련으로도 많은 일이 진행 중임
    BSD 재단에서 $750,000를 투자해서 S0ix Sleep State 구현 등 다양한 기능에 집중 중이라는 정보를 읽음
    관련 프로젝트는 https://github.com/FreeBSDFoundation/proj-laptop 에서 확인 가능

    • 정말 많은 작업이 동시에 이루어지는 중이지만, 본인은 자신이 직접 하고 있는 부분만 써서 공유한 것임

  • 아마존이 더 많이 지원하고 기여하길 바랬지만 현실은 FreeBSD의 최소 지원에 그치는 모습
    아마존은 FreeBSD 스폰서 명단에도 없음, 구글은 작년에 고작 $9K만 후원했고, 애플과 메타/페이스북도 없음
    반대로 마이크로소프트는 명단에 올라 있는 부분은 칭찬
    이 대기업들이 FreeBSD와 OpenBSD 덕분에 이득을 많이 보면서 매년 자동적으로 기부하지 않는 게 의외
    스폰서 정보는 https://freebsdfoundation.org/our-donors/donors/?donationYear=2024 에서 확인 가능

    • 아마존이 FreeBSD를 더 많이 지원했으면 좋겠다는 마음은 동의
      하지만 FreeBSD Foundation에 기부자 명단에 없다고 해서 지원이 없는 건 아님
      본인이 받은 개발비도 재단을 통하지 않았고, 실제로 재단이 지원하는 개발은 전체 기업 지원의 10% 정도에 불과
      재단이 지원하는 개발은 FreeBSD 자체를 위한 일에 집중할 수 있어서 중요하지만, 전체로 보면 소수임

    • 이 댓글 내용만으로 전체 상황을 다 볼 수 없다는 지적
      연도별로 재단에 기부된 스냅샷만을 보여줄 뿐이고, 기여한 개발 자체는 각 릴리즈의 릴리즈 노트에 요약돼 있음
      https://www.freebsd.org/releases/

    • 마이크로소프트가 왜 FreeBSD를 지원하는지 궁금증
      Hyper-V 확장도 리눅스보다 완전하지 않고, .NET 공식 포트도 없으며, 마이크로소프트가 FreeBSD 기반 서비스를 운영하는 것 같지도 않음

    • 아마존이 FAANG 중 FOSS에 가장 적게 기여하는 기업이라는 의견

  • cperciva에게 많은 존경을 표함
    Tarsnap과 FreeBSD를 동시에 어떻게 관리하는지 궁금함

    • 어느 시점부터 돈이 시간이 되어준다는 것에 대한 경험 공유
      간단한 수리는 직접 하거나 전문가를 부르거나 선택할 수 있음
      이 FreeBSD 작업에 들인 시간 중 일부만이 Tarsnap에서 가져온 시간이었고, 생각보다 많지 않음

  • 예전에 FreeBSD를 워크스테이션으로 사용해본 경험이 있고, 인상적이었음
    집 게이트웨이/방화벽/DNS/DHCP 서버로 FreeBSD를 쓰고 싶었지만 10GbE NIC 드라이버가 지원되지 않아 결국 Nix를 선택
    FreeBSD가 여전히 잘 유지되고 있다는 것이 보기 좋음

  • FreeBSD/EC2 상위 사용자들이 누구인지 궁금함

    • 본인도 잘 모름
      실제로 자신에게 컨택하는 사용자는 전체 FreeBSD/EC2 유저 중 0.1%도 안 되는 듯
      누가 FreeBSD를 EC2에서 쓰는지 정말 알고 싶음

    • 넷플릭스가 FreeBSD를 엣지 박스에만 사용하는 건지 궁금함

  • FreeBSD가 유닉스 계열에서 어떤 틈새를 메우고 있는지 궁금함
    왜 OpenBSD나 NetBSD보다 복잡한 FreeBSD를 사용하는지, ZFS나 Nvidia, ELF가 필요하면 그냥 Linux가 낫지 않은지 질문
    GNU 문제는 알고 있으나 Musl Void같은 대안도 있는데, FreeBSD만의 뚜렷한 “정체성”이 궁금하다는 genuine curiosity

    • 금융권에서 FreeBSD를 EC2와 자체 데이터센터 금속 서버 모두에서 사용한 경험
      zfs와 jails를 많이 활용
      모든 서비스를 각 jail에서 독립적으로 돌려 매우 비용 효율적
      클라우드로 일부 이전하여 하이브리드로 Linux(k8s)+FreeBSD를 운용했을 때는 비용이 급증
      데이터센터 직접 관리는 디스크 교체나 화재 대응 등 번거로운 점 있지만, AWS는 멀티리전 등 다양한 기능을 제공함(비용 부담 있음)
      zfs는 한 번 프로덕션 DB 테이블이 실수로 삭제됐을 때 스냅샷 덕분에 즉시 롤백하여 큰 도움이 되었음, 백업용으로도 zfs 활용
      프로덕션에서 dtrace로 트러블슈팅도 한 경험
      서버에 FreeBSD만 운용할 때는 OS 군단이 하나라 관리가 쉽고, 리눅스 도입 시에는 각 팀이 제각각 배포판을 써서 혼란이 있었음
      FreeBSD를 커널+OS가 통합된 구조로써 좋아하는 마음

    • 본인 입장에서, FreeBSD는 OpenBSD와 NetBSD의 장점을 적절히 혼합한 느낌
      과거 FreeBSD는 Intel CPU 최적화와 탄탄한 보안을 자랑했고, 특히 ZFS 지원이 결정적인 차별점
      nvidia 드라이버도 최근에야 네이티브 FreeBSD 지원이 생겼음
      결국 FreeBSD는 다른 BSD의 장점과 하드웨어 안정성을 잘 결합하고 있음

    • FreeBSD는 OpenBSD나 NetBSD보다 훨씬 더 큰 유저 베이스를 가진다는 점
      소프트웨어 카탈로그 자체가 더 방대해서 데스크탑 일상 사용도 충분히 가능
      왜 리눅스를 안 쓰냐면, 리눅스는 기업의 이익에 너무 얽매여 있다는 점

    • FreeBSD가 ZFS 지원에서 리눅스보다 한수 위라는 의견
      라이선스 이슈 덕분에 FreeBSD가 더 나은 환경 제공

    • FreeBSD는 OpenBSD보다 네트워킹 처리량 측면에서 더 뛰어남
      일반적으로 BSD들은 변화 속도가 적어서 통합 플랫폼으로 쓰기에 좋음

  • 이 글을 보면 FreeBSD 개발 환경이 썩 좋게 그려지지 않는다는 의견
    복잡성이 큰 OS임을 감안하면 최소한 누군가는 풀타임으로 릴리즈 매니저를 맡아야 할 텐데, 1년간 파트타임이 전부인 현실이 아쉽다는 생각
    그래도 리눅스만이 유일한 대안이 아니란 점에서 FreeBSD의 존재는 중요함

답변달기