Healthchecks.io 現已改用自管型物件儲存

背景

Healthchecks.io 是一個監控服務，其功能包含接收並儲存 HTTP 請求的內容。隨著數據量增長，作者從最初將資料存放在 PostgreSQL 資料庫，轉向使用 S3 相容的物件儲存服務。在經歷了 OVHcloud 與 UpCloud 等託管服務的效能波動與延遲問題後，作者決定在 2026 年轉向自建方案，採用 Versity S3 Gateway 搭配 Btrfs 檔案系統，將本地硬碟轉化為 S3 相容介面，以追求更高的效能與自主權。

社群觀點

在 Hacker News 的討論中，社群對於「自建物件儲存」與「選擇 Btrfs 檔案系統」展現了兩極化的反應。首先，針對底層檔案系統的選擇，不少資深工程師對 Btrfs 表達了強烈的不信任感，甚至有人形容看到這個詞會引發創傷後壓力症候群（PTSD）。反對者指出，Btrfs 在過去幾年曾出現嚴重的資料損壞臭蟲，特別是在處理大量小檔案與頻繁寫入的場景下，效能與穩定性堪憂。部分留言者建議改用 ext4 或 ZFS，認為後者在資料完整性與可靠性上更具優勢。然而，也有觀點認為 Btrfs 的可靠性已有進步，且若應用程式層級沒有頻繁呼叫 fsync，效能瓶頸可能不如預期嚴重。

另一個討論核心在於「為何在本地儲存仍需使用 S3 API」。有評論質疑，既然資料量僅約 120GB 且運行在單機環境，直接使用檔案系統 IO 會比透過 S3 API 封裝更有效率。對此，作者親自現身解釋，使用 S3 API 的主因是為了支援多台網頁伺服器的共享存取，且 S3 擁有成熟的生態系，方便未來遷移或整合其他工具。社群對此觀點產生分歧，有人認為 S3 API 已經成為一種事實上的標準，能有效避免供應商鎖定；但也有人反駁，認為 S3 API 本身就是 AWS 建立的技術護城河，雖然開放但仍具備某種程度的鎖定效應。

此外，針對小檔案儲存的架構設計，社群也提供了不同的優化思路。有留言者建議，考慮到平均物件大小僅約 8.5kB，或許將其作為 Blob 存放在雲端資料庫中，並在前端加上快取，會是比維護一套物件儲存系統更簡單的方案。不過，支持自建方案的觀點則強調，雖然租用專屬伺服器的成本高於託管儲存，但獲得的低延遲與對資料掌控的透明度，對於追求極致效能的服務來說是值得的投資。整體而言，社群認同在小規模階段，簡單的單機自建方案確實能解決託管服務常見的不可控延遲問題，但對長期維護的複雜度仍持保留態度。

延伸閱讀

在討論中，社群成員提到了多個可作為替代方案的開源物件儲存工具，包含 Garage、MinIO、SeaweedFS、Ceph (RGW)、Zenko CloudServer 以及 JuiceFS。此外，針對檔案系統的討論，亦有提及 GlusterFS 在處理海量小檔案時的歷史侷限性。