Clubhouse telah menciptakan gelombang di komunitas observabilitas dengan meninggalkan kerangka kerja standar industri OpenTelemetry (OTel) demi solusi logging kustom. Langkah ini membantu mereka mencapai target ambisius memproses data observabilitas hanya dengan biaya 500 dolar AS per petabyte sambil menangani lebih dari 100 petabyte data terkompresi setiap hari.
Keputusan tersebut telah memicu perdebatan sengit di kalangan developer tentang apakah pengumpulan data dalam skala masif seperti ini diperlukan atau justru pemborosan. Perusahaan kini memproses 100 miliar event per hari, menimbulkan pertanyaan tentang nilai penyimpanan data log dalam jumlah yang sangat besar.
Milestone Skala Observabilitas Clubhouse
Metrik | Skala | Tanggal Pencapaian |
---|---|---|
Event per hari | 100 Miliar | Oktober 2023 |
Data yang diproses per hari (terkompresi) | 100+ Petabyte | November 2023 |
Target efisiensi biaya | $500 USD per Petabyte | Tujuan saat ini |
Biaya operasional harian | Di bawah $50,000 USD | Target saat ini |
Perdebatan Besar Logging: Simpan Semua atau Selektif
Komunitas terpecah dalam menyikapi pendekatan Clubhouse terhadap pengumpulan data. Kritikus berargumen bahwa menyimpan 100 petabyte log menunjukkan penilaian teknis yang buruk ketimbang pencapaian teknologi. Mereka menyarankan bahwa sebagian besar data ini terdiri dari informasi debug yang jarang diperiksa kecuali sistem produksi mengalami masalah kritis.
menyimpan 100PB log hanya berarti kita belum mengetahui apa yang benar-benar layak di-log. metrics + structured events biasanya dapat menceritakan 90% dari keseluruhan cerita.
Namun, pendukung membantah bahwa memiliki data komprehensif yang tersedia sangat penting untuk debugging masalah yang tidak terduga. Mereka menunjukkan bahwa memfilter log terlalu agresif dapat membuat engineer tidak memiliki informasi yang mereka butuhkan saat menyelidiki masalah kompleks yang tidak diantisipasi selama desain logging awal.
Perdebatan ini mencerminkan ketegangan fundamental dalam pengembangan perangkat lunak modern antara optimasi biaya dan visibilitas operasional. Beberapa organisasi lebih memilih logging yang ramping dengan kurasi yang hati-hati, sementara yang lain mengadopsi pendekatan kumpulkan semua dan filter kemudian.
Arsitektur Teknis: Menyederhanakan Pipeline Data
Solusi teknis Clubhouse melibatkan penghapusan lapisan collector OpenTelemetry, yang mereka anggap menambah kompleksitas dan overhead yang tidak perlu. Sebaliknya, mereka mengimplementasikan pipeline langsung menggunakan FluentBit untuk streaming log aplikasi langsung ke ClickHouse, fondasi database kolumnar mereka.
Perubahan arsitektur ini mengurangi kebutuhan pemrosesan mereka secara dramatis. Perusahaan melaporkan membutuhkan 8.000 core CPU untuk menangani pemrosesan log JSON dalam setup sebelumnya, dibandingkan dengan hanya 90 core dengan pendekatan baru mereka. Pipeline yang disederhanakan menghilangkan beberapa langkah serialisasi dan deserialisasi yang mengonsumsi sumber daya komputasi yang signifikan.
Sistem baru menggunakan skema tabel lebar di ClickHouse, memungkinkan engineer menyimpan data event yang beragam dalam struktur tabel tunggal. Pendekatan ini memungkinkan query yang lebih cepat dan korelasi event terkait yang lebih baik selama sesi troubleshooting.
Perbandingan Arsitektur Teknis
Pengaturan Sebelumnya (dengan OpenTelemetry):
- Container stdout → CRI-O/dockerd
- FluentBit menangkap dan memperkaya dengan metadata Kubernetes
- Kolektor OTel memproses data di memori
- OTel mendorong data yang telah ditransformasi ke backend streaming
- ClickHouse menerima dan menyimpan data
- Dibutuhkan: 8.000 core CPU untuk pemrosesan JSON
Pengaturan Baru (Pipeline Kustom):
- Streaming langsung FluentBit ke ClickHouse
- Routing event berbasis Lua dalam FluentBit
- Skema tabel lebar untuk analisis khusus
- Dibutuhkan: 90 core CPU (pengurangan 99%)
Trade-off Biaya vs. Waktu Engineering
Implikasi finansial platform observabilitas telah menjadi perhatian utama bagi tim engineering. Beberapa anggota komunitas berbagi pengalaman dengan vendor seperti Datadog dan Splunk, di mana perpanjangan kontrak sering memicu langkah-langkah pemotongan biaya yang agresif yang dapat mengompromikan visibilitas sistem.
Organisasi semakin dipaksa untuk menyeimbangkan perilaku sistem yang dapat diamati dengan kendala anggaran. Beberapa perusahaan mendedikasikan 5-10% dari total anggaran mereka untuk logging dan observabilitas, memandangnya sebagai investasi infrastruktur yang esensial. Yang lain kesulitan membenarkan biaya ini, terutama ketika nilainya sulit dikuantifikasi dalam metrik bisnis tradisional.
Tantangan menjadi lebih kompleks ketika mempertimbangkan biaya tersembunyi dari observabilitas yang tidak memadai. Engineer mungkin menghabiskan berjam-jam atau berhari-hari menyelidiki masalah yang dapat diselesaikan dalam hitungan menit dengan data tracing dan logging yang tepat. Namun, mengkuantifikasi dampak produktivitas ini tetap sulit bagi sebagian besar organisasi.
Performa Database dalam Skala Besar
Peran ClickHouse sebagai fondasi penyimpanan telah menarik perhatian signifikan dari komunitas. Pengguna melaporkan peningkatan performa yang dramatis dibandingkan dengan database tradisional, dengan beberapa mengalami percepatan 50x untuk beban kerja analitik yang melibatkan dataset besar.
Namun, ClickHouse hadir dengan serangkaian tantangannya sendiri. Database ini bekerja paling baik dengan pola data yang immutable dan append-only, membuatnya kurang cocok untuk aplikasi yang memerlukan update yang sering. Ketergantungannya pada sistem koordinasi seperti Zookeeper juga memperkenalkan kompleksitas operasional yang dianggap memberatkan oleh beberapa tim.
Model penyimpanan kolumnar database ini unggul dalam menangani skema event lebar yang digunakan Clubhouse, memungkinkan query yang efisien dari kolom data spesifik tanpa memindai seluruh dataset. Kemampuan ini menjadi krusial saat memproses volume informasi skala petabyte.
Pertimbangan Regulasi dan Privasi
Diskusi ini juga menyoroti kekhawatiran regulasi yang penting, terutama seputar retensi data dan kepatuhan privasi. Regulasi GDPR Eropa membatasi berapa lama organisasi dapat menyimpan log yang mungkin berisi informasi pribadi, biasanya membatasi log analisis error umum hingga sekitar satu bulan.
Kerangka regulasi ini memaksa perusahaan untuk lebih sengaja tentang data apa yang mereka kumpulkan dan simpan dalam jangka panjang. Beberapa organisasi menemukan bahwa kepatuhan GDPR sebenarnya meningkatkan praktik logging mereka dengan mendorong strategi pengumpulan data yang lebih bijaksana.
Tantangannya menjadi menyeimbangkan visibilitas sistem yang komprehensif dengan persyaratan privasi dan biaya penyimpanan. Platform observabilitas modern mulai menawarkan solusi penyimpanan bertingkat yang dapat mengarsipkan log detail sambil menjaga data yang sering diakses dalam tingkat penyimpanan yang lebih cepat dan lebih mahal.
Kesimpulan
Keputusan Clubhouse untuk mengganti OpenTelemetry dengan solusi kustom mencerminkan ketegangan industri yang lebih luas seputar biaya observabilitas, kebijakan retensi data, dan produktivitas engineering. Meskipun pencapaian teknis mereka mengesankan, komunitas tetap terpecah tentang apakah pengumpulan data yang komprehensif seperti ini merepresentasikan praktik engineering yang baik atau over-engineering yang mahal.
Perdebatan pada akhirnya berpusat pada manajemen risiko: risiko kehilangan informasi debugging kritis versus risiko biaya infrastruktur yang berlebihan dan masalah kepatuhan regulasi. Seiring alat observabilitas terus berkembang, organisasi perlu menemukan keseimbangan mereka sendiri antara visibilitas yang komprehensif dan kendala praktis.
Referensi: Scaling our Observability platform beyond 100 Petabytes by embracing wide events and replacing OTel