Manfaatkan Semaksimal Mungkin Sistem yang Anda Miliki

• Tulisan ini membahas pengalaman penulis dalam mengelola performa Postgres pada aplikasi SaaS, ketika database mengalami kesulitan menangani beban.
• Tim penulis melakukan penskalaan vertikal dengan mengganti ke instans yang lebih besar setiap kali database menjadi terlalu sibuk. Namun, mereka sudah menggunakan instans terbesar dan hampir mencapai kondisi kelebihan beban.
• Dua solusi yang mungkin diajukan adalah melakukan sharding penulisan ke klaster database yang independen, serta memecah monolit menjadi beberapa layanan yang saling terhubung (microservices).
• Kedua solusi tersebut memang dapat menambah kapasitas dan menawarkan opsi menarik untuk toleransi kegagalan serta ketahanan operasional, tetapi juga akan sangat meningkatkan kompleksitas.
• Penulis berpendapat bahwa biaya nyata dari peningkatan kompleksitas adalah perhatian, yang membuat setiap keputusan teknis berikutnya menjadi lebih rumit.
• Penulis menyarankan bahwa sebelum meningkatkan kompleksitas secara besar-besaran, biasanya ada peluang untuk "memeras" sedikit performa tambahan dari sistem yang sudah ada dengan menyesuaikan beban kerja, melakukan tuning performa, atau melengkapi sistem dengan cara tertentu.
• Dalam kasus mereka, dengan mengoptimalkan kueri berat, melakukan tuning konfigurasi Postgres, dan memindahkan sebagian kueri read-only yang mahal ke database replika, mereka menurunkan penggunaan CPU puncak mingguan database dari 90% menjadi 30%.
• Penulis menyimpulkan bahwa kompleksitas memang diperlukan dan tidak bisa dihindari, tetapi sebaiknya penambahan kompleksitas ditunda selama mungkin dan terlebih dahulu memeras performa sebanyak mungkin dari sistem yang ada.

[GN⁺]

Opini Hacker News

• Artikel ini menekankan pentingnya memaksimalkan potensi sistem yang ada saat ini, sebelum mempertimbangkan penggantian atau peningkatan.
• Disarankan agar tim memanfaatkan apa yang mereka miliki sekarang, meskipun tidak sempurna, dan mencari cara untuk mencapai tujuan dengan sumber daya yang ada.
• Dibahas gagasan merancang aplikasi agar tidak menggunakan join di database, dengan usulan bahwa ruang penyimpanan itu murah dan semuanya didenormalisasi lalu harus diperbarui dalam transaksi.
• Penggunaan UUID disarankan untuk mencegah hot partition, sehingga sistem dapat diskalakan secara horizontal alih-alih bergantung pada integer yang pada akhirnya bisa gagal.
• Dibagikan contoh sukses sebuah tim yang secara signifikan meningkatkan performa sistem dengan mengubah cara menyelesaikan masalah, alih-alih menambah perangkat keras atau kompleksitas.
• Artikel ini menentang pemecahan monolit menjadi banyak layanan yang saling terhubung sekaligus, dan sebagai gantinya menyarankan untuk mengidentifikasi pemecahan yang akan memberi dampak terbesar.
• Ditekankan pentingnya mengoptimalkan query pada aplikasi web yang dibangun di atas ORM, karena sering kali masih ada banyak ruang untuk perbaikan.
• Diperingatkan tentang beban mental dan kompleksitas dalam mengerjakan sistem microservices, yang sering kali menyebabkan downtime dan kekacauan.
• Dibedakan antara efisiensi (meminimalkan kerugian dan menghindari kompleksitas) dan optimisasi (menggunakan algoritma khusus dengan konsekuensi penambahan kompleksitas).
• Dibagikan kekhawatiran tentang migrasi ke infrastruktur yang lebih kompleks, dengan usulan bahwa ini mungkin bukan solusi ajaib yang diharapkan semua orang.
• Kesederhanaan lebih didukung daripada kompleksitas, terutama ketika sumber daya terbatas dan sistem tidak terlalu kritis.
• Terakhir, artikel ini membahas sharding per tenant (pelanggan) sebagai solusi potensial untuk masalah skalabilitas.