Healthchecks.io가 자체 호스팅 object storage를 사용하기 시작했다

Healthchecks.io는 ping request body의 처음 100kB를 저장하며, 작은 본문은 PostgreSQL에 넣고 큰 본문은 S3-compatible object storage로 오프로드한다.

기존에는 AWS S3, OVHcloud, UpCloud를 순서대로 사용했지만, 비용과 운영 조건은 괜찮아도 시간이 지나며 성능 저하, 서버 에러, timeout, 특히 DeleteObjects 지연이 반복됐다.

운영 규모는 다음과 같다.

• 14 million objects, 119GB
• 객체 크기: 100 bytes ~ 100,000 bytes, 평균 8KB
• 평균 30 uploads/sec, 피크 150 uploads/sec
• 지속적인 upload/delete churn

self-hosted 대안으로 Minio, SeaweedFS, Garage를 검토했지만, 1인 운영 체계에서는 클러스터 자동화, 업그레이드 절차, 장애 노드 교체, 모니터링까지 떠안아야 해서 운영 복잡도가 부담이었다.

최종적으로 선택한 것은 Versity S3 Gateway였다. 이 도구는 로컬 filesystem을 S3 서버처럼 동작하게 만들며, 별도 metadata DB가 없고 파일 생성/읽기/삭제가 곧 S3의 Put/Get/Delete에 대응한다. 업그레이드는 binary 교체 + systemd 재시작 수준으로 단순했다.

현재 구성은 다음과 같다.

• S3 API는 전용 서버에서 동작
• 애플리케이션 서버는 Wireguard 터널로 접근
• 저장소는 NVMe 2개 RAID 1과 Btrfs filesystem
• 2시간마다 rsync로 변경분을 백업 서버에 동기화
• 백업 서버는 매일 전체 백업을 암호화해 외부 보관
• 전체 백업은 최근 30일 유지

이 방식의 가장 큰 tradeoff는 durability다. object storage 서버와 두 디스크가 동시에 문제가 생기면, 최대 2시간 분량의 ping body를 잃을 수 있다. 다만 primary data store인 PostgreSQL이 멈추는 것보다는 영향이 작다고 판단했다.

전환 후에는 S3 latency가 낮아졌고, 대기 중이던 ping body queue도 줄었다. 아직은 몇 주밖에 되지 않아 장기 안정성은 더 지켜봐야 하지만, 현재까지 availability 문제는 없었다.

결론적으로:

• managed object storage보다 비용은 증가했다
• 대신 성능과 제어 가능성은 개선됐다
• 1인 팀이 감당 가능한 단순함을 유지하면서, 운영상 더 나은 절충안을 찾은 셈이다
• 더 나은 tradeoff를 가진 시스템이 나오면 다시 migration할 의향도 열어두고 있다