Migrasi dari DigitalOcean ke Hetzner

 (isayeter.com)
15 poin oleh GN⁺ 3 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Memindahkan infrastruktur produksi senilai $1.432 per bulan ke server dedicated $233 per bulan, bahkan sambil mengganti sistem operasi, dan tetap menjaga kontinuitas layanan tanpa downtime
  • Menyiapkan ulang 30 database MySQL dan 34 virtual host Nginx, GitLab EE, Neo4J, Supervisor, dan Gearman secara identik di server baru, lalu menyelesaikan migrasi dengan replikasi real-time dan sinkronisasi incremental terakhir
  • Kunci migrasi database adalah kombinasi pemrosesan paralel mydumper·myloader dan MySQL replication, sekaligus memperbaiki masalah skema sys dan hak akses yang muncul saat upgrade dari MySQL 5.7 ke 8.0
  • Cutover dilakukan dengan urutan menurunkan DNS TTL, mengubah Nginx di server lama menjadi reverse proxy, lalu mengganti semua A record, sehingga selama propagasi DNS permintaan ke IP lama tetap diteruskan ke server baru
  • Hasil akhirnya adalah penghematan $1.199 per bulan, $14.388 per tahun, peningkatan CPU·memori·storage, dan 0 menit downtime

Latar belakang migrasi

  • Dalam konteks menjalankan perusahaan software di Turki, inflasi yang sangat tinggi dan melemahnya lira Turki membuat beban biaya infrastruktur berbasis dolar meningkat tajam
  • Biaya server DigitalOcean sebelumnya mencapai $1.432 per bulan, dengan konfigurasi 192GB RAM, 32 vCPU, 600GB SSD, 2 volume blok 1TB, plus backup
  • Target baru adalah server dedicated Hetzner AX162-R, dengan AMD EPYC 9454P 48-core 96-thread, 256GB DDR5, dan 1.92TB NVMe Gen4 RAID1
  • Biaya bulanan turun menjadi $233, dengan penghematan $1.199 per bulan dan $14.388 per tahun
  • Tidak ada keluhan terhadap keandalan server lama atau developer experience, tetapi untuk workload steady-state rasio harga terhadap performanya sudah tidak lagi masuk akal

Lingkungan operasional lama

  • Stack yang dijalankan bukan lingkungan uji sederhana, melainkan lingkungan produksi nyata
    • 30 database MySQL, total 248GB data
    • 34 virtual host Nginx yang melayani banyak domain
    • GitLab EE termasuk backup 42GB
    • Neo4J Graph DB berukuran 30GB
    • Supervisor mengelola puluhan background worker
    • Menggunakan antrean tugas Gearman
    • Menjalankan aplikasi mobile live untuk ratusan ribu pengguna
  • Sistem operasi server lama adalah CentOS 7 dan sudah berstatus end-of-life
  • Sistem operasi server baru adalah AlmaLinux 9.7, distro kompatibel RHEL 9 dan pilihan penerus yang natural untuk CentOS
  • Migrasi ini bukan hanya soal penghematan biaya, tetapi juga kesempatan keluar dari sistem operasi yang sudah bertahun-tahun tidak menerima update keamanan

Strategi tanpa downtime

  • Tidak menggunakan pendekatan sekadar mengganti DNS dan me-restart layanan, melainkan migrasi tanpa downtime dengan prosedur 6 tahap

  • Tahap 1: memasang seluruh stack di server baru

    • Memasang Nginx dengan kompilasi source memakai flag yang sama seperti sebelumnya
    • PHP dipasang melalui Remi repo dan memakai file konfigurasi .ini yang sama dari server lama
    • Memasang MySQL 8.0, Neo4J Graph DB, GitLab EE, Node.js, Supervisor, dan Gearman, lalu mengonfigurasinya agar perilakunya sama seperti sebelumnya
    • Sebelum menyentuh record DNS, semua layanan sudah disiapkan agar berjalan identik dengan server lama
    • Sertifikat SSL ditangani dengan menyalin seluruh direktori /etc/letsencrypt/ dari server lama via rsync
    • Setelah seluruh traffic berpindah ke server baru, dilakukan force renew massal sertifikat dengan certbot renew --force-renewal

  • Tahap 2: replikasi file web dengan rsync

    • Seluruh direktori /var/www/html sekitar 65GB dan 1,5 juta file direplikasi lewat rsync berbasis SSH
    • Verifikasi integritas dilakukan dengan opsi --checksum
    • Tepat sebelum cutover dilakukan sinkronisasi incremental terakhir untuk memasukkan file yang berubah

  • Tahap 3: replikasi master-slave MySQL

    • Alih-alih men-dump lalu me-restore sambil mematikan database, dipakai konfigurasi replikasi real-time
    • Server lama dijadikan master, server baru dijadikan slave read-only
    • Muatan awal berukuran besar dimasukkan dengan mydumper, lalu replikasi dimulai dari posisi binlog yang tepat sebagaimana tercatat di metadata dump
    • Hingga saat cutover, kedua sisi dipertahankan dalam kondisi sinkron real-time

  • Tahap 4: menurunkan DNS TTL

    • Memanggil DigitalOcean DNS API lewat script untuk menurunkan TTL record A/AAAA dari 3600 detik menjadi 300 detik
    • Record MX dan TXT tidak diubah
    • Perubahan TTL record email dikecualikan karena bisa memicu masalah deliverability
    • Setelah menunggu 1 jam agar TTL lama kedaluwarsa secara global, cutover siap dilakukan dalam waktu 5 menit

  • Tahap 5: mengubah Nginx server lama menjadi reverse proxy

    • Script Python mem-parse blok server {} di 34 konfigurasi situs Nginx
    • Konfigurasi lama dibackup, lalu diganti dengan konfigurasi proxy yang mengarah ke server baru
    • Selama propagasi DNS, request yang masuk ke IP lama tetap diam-diam diteruskan ke server baru
    • Dari sudut pandang pengguna, tidak ada gangguan yang terlihat

  • Tahap 6: cutover DNS dan mematikan server lama

    • Script Python memanggil DigitalOcean API untuk mengganti semua A record ke IP server baru dalam hitungan detik
    • Server lama dipertahankan sebagai cold standby selama 1 minggu lalu dimatikan
    • Selama seluruh proses, layanan tetap merespons baik secara langsung maupun lewat proxy, sehingga tidak ada celah availability

Migrasi MySQL

  • Bagian paling kompleks dari seluruh pekerjaan adalah proses migrasi MySQL

  • Dump data

    • Menggunakan mydumper alih-alih mysqldump standar
    • Dengan memanfaatkan 48 core CPU di server baru untuk export/import paralel, pekerjaan yang butuh berhari-hari dengan mysqldump single-thread dipangkas menjadi beberapa jam
    • Opsi utama yang dipakai mencakup --threads 32, --compress, --trx-consistency-only, --skip-definer, --chunk-filesize 256
    • File metadata dari dump utama mencatat posisi binlog saat snapshot diambil
      • File: mysql-bin.000004
      • Position: 21834307
    • Nilai tersebut kemudian dipakai sebagai titik awal replikasi

  • Transfer dump

    • Setelah dump selesai, hasilnya ditransfer ke server baru lewat rsync berbasis SSH
    • Total data yang ditransfer mencapai 248GB chunk terkompresi
    • Opsi --compress dari mydumper membantu meningkatkan kecepatan transfer jaringan

  • Load data

    • Menggunakan myloader
    • Opsi utama yang dipakai adalah --threads 32, --overwrite-tables, --ignore-errors 1062, --skip-definer

  • Masalah transisi dari MySQL 5.7 ke 8.0

    • Karena lingkungan CentOS 7, server lama masih tertahan di MySQL 5.7
    • Sebelum migrasi, dilakukan pengecekan kompatibilitas data dengan MySQL 8.0 memakai mysqlcheck --check-upgrade, dan hasilnya tidak menunjukkan masalah
    • Server baru dipasangi MySQL 8.0 Community terbaru
    • Di seluruh proyek, waktu eksekusi query menurun secara signifikan; teks asli menyebut optimizer yang lebih baik dan peningkatan InnoDB di MySQL 8.0 sebagai alasan
    • Namun lompatan versi ini juga menimbulkan masalah
      • Setelah import, struktur kolom tabel mysql.user ternyata berjumlah 45, bukan 51 seperti yang diharapkan
      • Akibatnya mysql.infoschema hilang dan autentikasi user terganggu
    • Percobaan perbaikan pertama memakai perintah berikut
      • systemctl stop mysqld
      • mysqld --upgrade=FORCE --user=mysql &
    • Percobaan pertama gagal dengan error ERROR: 'sys.innodb_buffer_stats_by_schema' is not VIEW
    • Penyebabnya adalah skema sys ter-import sebagai tabel biasa, bukan view
    • Solusinya adalah menjalankan DROP DATABASE sys; lalu mengulangi upgrade
    • Setelah itu proses selesai dengan normal

Konfigurasi replikasi MySQL

  • Setelah dump selesai dimuat di kedua server, server baru dikonfigurasikan sebagai replica dari server lama
  • Pada perintah CHANGE MASTER TO, ditentukan IP server lama, user replikasi, port 3306, MASTER_LOG_FILE='mysql-bin.000004', dan MASTER_LOG_POS=21834307
  • Lalu dijalankan START SLAVE;
  • Hampir seketika replikasi berhenti karena error 1062 Duplicate Key
  • Penyebabnya adalah dump dilakukan dalam dua bagian, dan di sela-selanya ada write ke beberapa tabel, sehingga replay binlog mencoba memasukkan ulang baris yang sudah ada di dump
  • Untuk mengatasinya diterapkan pengaturan berikut
    • SET GLOBAL slave_exec_mode = 'IDEMPOTENT';
    • START SLAVE;
  • Mode IDEMPOTENT akan melewati error duplicate key dan missing row secara diam-diam
  • Semua database inti akhirnya sinkron tanpa error, dan dalam beberapa menit nilai Seconds_Behind_Master turun menjadi 0

Verifikasi sebelum cutover

  • Sebelum menyentuh record DNS, perlu dipastikan semua layanan di server baru bekerja dengan benar
  • Metode verifikasinya adalah memodifikasi file /etc/hosts di mesin lokal secara sementara agar domain diarahkan ke IP server baru
  • Browser dan Postman lalu mengirim request ke server baru, sementara pengguna eksternal tetap mengakses server lama
  • Endpoint API, panel admin, dan status respons tiap layanan diperiksa
  • Setelah semua lolos, barulah cutover aktual dilakukan

Masalah hak akses SUPER

  • Setelah replikasi master-slave sepenuhnya sinkron, ditemukan bahwa di server baru read_only = 1 tetapi statement INSERT tetap berhasil
  • Penyebabnya adalah semua user aplikasi PHP ternyata memiliki hak akses SUPER
  • Di MySQL, hak akses SUPER dapat melewati read_only
  • Dari hasil SHOW GRANTS FOR 'some_db_user'@'localhost'; terlihat bahwa hak akses SUPER memang ada
  • Dilakukan REVOKE SUPER ON *.* FROM 'some_db_user'@'localhost'; berulang pada total 24 user aplikasi
  • Setelah itu dijalankan FLUSH PRIVILEGES;
  • Sejak saat itu read_only = 1 benar-benar memblokir write dari user aplikasi sambil tetap mengizinkan replikasi

Persiapan DNS

  • Semua domain dikelola lewat DigitalOcean DNS, sementara nameserver terhubung dari GoDaddy
  • Penurunan TTL diotomatisasi dengan script yang menargetkan DigitalOcean API
  • Yang diubah hanya record A dan AAAA
  • Record MX dan TXT tidak disentuh
    • TTL record terkait email dikecualikan karena potensi isu deliverability Google Workspace
  • Setelah menunggu 1 jam agar TTL lama habis, cutover siap dilakukan

Mengubah Nginx server lama menjadi reverse proxy

  • Alih-alih mengedit 34 file konfigurasi secara manual, konversi otomatis dilakukan dengan script Python
  • Script tersebut mem-parse blok server {} di semua file konfigurasi dan mengidentifikasi content block utama, lalu menggantinya dengan konfigurasi proxy
  • Konfigurasi asli dibackup sebagai file .backup
  • Pada contoh konfigurasi dipakai proxy_pass https://NEW_SERVER_IP;, proxy_set_header Host $host;, proxy_set_header X-Real-IP $remote_addr;, proxy_read_timeout 150;
  • Opsi pentingnya adalah proxy_ssl_verify off
    • Karena sertifikat SSL di server baru valid untuk domain, tetapi tidak valid untuk alamat IP
    • Karena kedua ujung koneksi dikelola sendiri, penonaktifan verifikasi dianggap dapat diterima di sini

Prosedur cutover

  • Tepat sebelum cutover, syaratnya adalah lag replikasi berada di Seconds_Behind_Master: 0 dan reverse proxy sudah siap
  • Urutan eksekusinya sebagai berikut
    • Di server baru jalankan STOP SLAVE;
    • Di server baru jalankan SET GLOBAL read_only = 0;
    • Di server baru jalankan RESET SLAVE ALL;
    • Di server baru jalankan supervisorctl start all
    • Di server lama jalankan nginx -t && systemctl reload nginx untuk mengaktifkan proxy
    • Di server lama jalankan supervisorctl stop all
    • Dari Mac lokal jalankan python3 do_cutover.py untuk mengganti semua A record DNS ke IP server baru
    • Tunggu propagasi sekitar 5 menit
    • Di server lama beri komentar pada semua entri crontab
  • Script cutover DNS memanggil DigitalOcean API untuk mengganti semua A record dalam sekitar 10 detik

Pekerjaan tambahan setelah cutover

  • Setelah migrasi selesai, ditemukan banyak webhook proyek GitLab masih mengarah ke IP server lama
  • Dibuat dan diterapkan script untuk memindai semua proyek melalui GitLab API dan memperbarui webhook secara massal

Hasil akhir

  • Biaya bulanan turun dari $1.432 menjadi $233
  • Penghematan tahunan mencapai $14.388
  • Dari sisi performa juga diperoleh server yang lebih kuat
    • CPU naik dari 32 vCPU menjadi 96 logical CPU
    • RAM naik dari 192GB menjadi 256GB DDR5
    • Storage berubah dari konfigurasi campuran sekitar 2,6TB menjadi 2TB NVMe RAID1
    • Downtime adalah 0 menit
  • Total waktu migrasi sekitar 24 jam
  • Tidak ada dampak ke pengguna

Pelajaran utama

  • MySQL replication adalah sarana kunci untuk migrasi tanpa downtime
    • Disiapkan sejak awal, dibiarkan mengejar ketertinggalan, lalu dilakukan cutover
  • Hak akses user MySQL wajib diperiksa sebelum migrasi
    • Jika ada hak akses SUPER, maka read_only bisa dilewati sehingga lingkungan slave sebenarnya tidak benar-benar read-only
  • Update DNS, perubahan konfigurasi Nginx, dan perbaikan webhook penting untuk diotomatisasi dengan script
    • Menangani lebih dari 34 situs secara manual akan memakan waktu lama dan meningkatkan risiko error
  • Kombinasi mydumper + myloader jauh lebih cepat daripada mysqldump untuk dataset besar
    • Dump dan restore paralel 32 thread memangkas pekerjaan berhari-hari menjadi beberapa jam
  • Untuk workload steady-state, cloud provider bisa menjadi mahal, dan server dedicated dapat memberi performa lebih tinggi dengan biaya lebih rendah

Script GitHub

  • Semua script Python yang dipakai untuk migrasi dipublikasikan di GitHub
  • Daftar script yang disertakan
    • do_list_domains_ttl.py
      • Menampilkan semua A record, IP, dan TTL untuk domain DigitalOcean
    • do_ttl_update.py
      • Menurunkan TTL semua A/AAAA record menjadi 300 detik secara massal
    • do_to_hetzner_bulk_dns_records_import.py
      • Memindahkan semua DNS zone dari DigitalOcean ke Hetzner DNS
    • do_cutover_to_new_ip.py
      • Mengalihkan semua A record dari IP server lama ke IP server baru
    • nginx_reverse_proxy_update.py
      • Mengubah semua konfigurasi situs nginx menjadi konfigurasi reverse proxy
    • mysql_compare.py
      • Membandingkan row count semua tabel di dua server MySQL
    • final_gitlab_webhook_update.py
      • Memperbarui semua webhook proyek GitLab ke IP server baru
    • mydumper
      • Library mydumper
  • Semua script mendukung mode DRY_RUN = True untuk preview aman sebelum penerapan nyata

Bacaan terkait

1 komentar

 
GN⁺ 3 hari lalu
Komentar Hacker News

  • Beberapa bulan lalu aku memindahkan dua server dari Linode dan DO ke Hetzner, dan berhasil memangkas biaya cukup besar. Yang lebih mengesankan, stack-nya benar-benar berantakan, dengan puluhan situs, bahasa yang berbeda-beda, library lama, plus MySQL dan Redis yang kusut jadi satu. Tapi Claude Code memindahkan semuanya, dan untuk library yang tidak ada, ia bahkan menulis ulang sebagian kode untuk menanganinya. Migrasi serumit ini sekarang jadi jauh lebih mudah, jadi ke depannya sepertinya portabilitas antar penyedia akan makin besar

    • Menurutku, yang dibayar orang selama ini bukan komputasi ajaib, melainkan supaya tidak perlu menyentuh glue code yang ditempel-tempel selama 10 tahun. Kalau agent mulai melahap glue itu, moat penyedia lama bakal cepat menipis
    • Jujur saja, ini terasa seperti iklan Claude yang di dalamnya masih ada iklan Hetzner lagi. Jadi penasaran sebenarnya ini nested sampai level mana
    • Rasanya tidak semua cerita harus selalu dibawa jadi cerita AI
    • Aku juga akan meninggalkan Linode dalam beberapa bulan ke depan. Sudah kupakai lebih dari 10 tahun dan aku juga banyak mereferensikan pelanggan ke sana, tapi mereka terus menaikkan harga, dan sekarang di tempat seperti Hetzner aku bisa dapat memori 8x, NVMe dedicated, dan CPU dedicated dengan harga lebih murah. Memang ada sedikit kehilangan kelebihan seperti portabilitas mudah pada server virtual, tapi bahkan saat ada gangguan, support Hetzner selalu cepat dan kompeten
    • Aku juga makin sering memakai Claude untuk DevOps. Aku menjalankan VM di atas Proxmox pada bare metal milikku, dan Claude mengoptimalkan serta mengonfigurasi jaringan baru lintas beberapa mesin dengan sangat cepat, sampai rasanya seperti rekan kerja atau sysadmin yang dibayar mahal

  • Aku sedang menyusun rencana untuk pindah dari AWS ke Hetzner. Amazon kadang memasang harga 20 kali lebih mahal daripada pesaing, memaksa komitmen jangka panjang kalau ingin harga yang lumayan, dan juga membuat perpindahan data sangat mahal, jadi terasa sangat anti-pelanggan. Mereka mungkin mengira orang akan terkunci oleh biaya egress, tapi nyatanya begitu satu bagian dipindahkan ke pesaing, itu justru mendorong untuk memindahkan semuanya. Untungnya aku tidak membangun platform di atas layanan khusus Amazon, jadi migrasinya agak lebih mudah

    • Bagian itu dulu benar, tapi suasananya berubah sejak GCP merilis kebijakan pembebasan biaya egress pada Januari 2024, lalu AWS beberapa bulan kemudian menyamai dengan kebijakan serupa. Bukan mau membujuk supaya tetap bertahan, hanya ingin bilang bahwa secara teknis permintaan waiver itu dimungkinkan. Aku sendiri tidak yakin sampai sejauh mana cakupannya, dan dari wording AWS kelihatannya juga dipengaruhi oleh EU Data Act

  • Setiap kali melihat tulisan seperti ini, aku heran karena orang jarang membahas hal-hal seperti redundansi atau load balancer. Kalau satu server mati, beberapa layanan bisa ikut turun sekaligus, jadi aku penasaran apakah orang benar-benar menganggap ini baik-baik saja. Mungkin memang hemat uang, tapi bisa jadi malah membayar lebih mahal dalam waktu maintenance dan masalah masa depan

    • Menurutku itu tergantung jenis layanan dan seberapa penting layanan tersebut. Kalau satu server bisa berjalan 10 tahun dan total downtime selama periode itu hanya sekitar 1 minggu sampai 1 bulan, banyak kasus di mana itu masih sangat bisa diterima. Bisnis kecil, situs hobi, forum, atau blog, tempat situs web bukan inti operasional, mungkin tidak terlalu terdampak oleh downtime singkat. Bahkan bisa jadi ekor panjang situs bertrafik rendah seperti ini justru mencakup mayoritas web. Tidak semua hal perlu high availability, dan kalau mau, penyedia seperti ini juga tetap menyediakan fitur seperti load balancer
    • Menurutku tulisan seperti ini populer karena sering menampakkan ketidakcocokan antara kebutuhan dan solusi. Kalau proyek hobi atau bisnis kecil diberi arsitektur kelas enterprise sampai jadi overengineered, padahal downtime sehari sesekali pun masih tidak masalah, maka full setup ala cloud mungkin memang tidak perlu. Tapi tulisan kali ini terasa agak aneh karena menekankan migrasi tanpa downtime, sementara arsitektur akhirnya sendiri tampak tidak terlalu toleran terhadap kegagalan. Dengan sedikit tambahan struktur di sisi Hetzner, sepertinya itu sudah bisa jauh lebih baik
    • Banyak workload memang tidak butuh tingkat kesiapan seperti itu. Dan keandalan dari kesederhanaan juga jangan diremehkan. Aku sudah lama bekerja sebagai Linux sysadmin, dan downtime pada sistem kompleks jauh lebih sering kulihat daripada pada sistem yang sederhana. Di suatu titik di antara teori dan kenyataan, kesanku justru sistem sederhana lebih tahan banting dalam kebanyakan kasus
    • Kalau mau adil, sejak awal mereka juga memakai VM tunggal di DigitalOcean, jadi sebenarnya mereka tidak terlalu menikmati keunggulan khas penyedia cloud. Biasanya tulisan seperti ini terbagi antara kasus yang memang sejak awal salah masuk cloud lalu lebih cocok pindah ke fisik, dan kasus yang justru akan jadi bencana kalau dipindahkan begitu saja. Yang ini kelihatannya lebih dekat ke kategori pertama. Kalau setup-nya berjalan baik di DO, mestinya di Hetzner pun masih cukup aman asalkan ada kebijakan DR yang layak
    • Bisa jadi keputusan ini lahir dari pengalaman yang sebenarnya belum terlalu lama mengalami neraka maintenance atau masalah besar di masa depan

  • Di lithus.eu kami sudah sering memindahkan pelanggan dari berbagai cloud ke Hetzner. Biasanya kami menyusun multi-server, kadang multi-AZ, lalu menyebarkan workload dengan Kubernetes untuk memberi HA. Untuk single node, Kubernetes mungkin berlebihan, tapi kalau nodenya beberapa, itu jauh lebih masuk akal. Backup kami gabungkan antara Velero dan backup level aplikasi, misalnya untuk Postgres kami sampai memakai backup WAL untuk PITR. Data stateful ditempatkan minimal di dua node agar HA terjamin. Dari sisi performa, bare metal umumnya juga lebih baik, dan dibanding AWS, waktu respons sering turun hingga setengahnya. Menurutku penyebabnya bukan virtualisasi itu sendiri, melainkan faktor sekitar seperti NVMe, latensi jaringan yang rendah, dan cache contention yang lebih kecil. Ada juga lebih banyak detail di posting HN yang pernah kutulis dulu

    • Aku juga pernah mengukurnya sendiri beberapa tahun lalu, dan sejak itu aku jadi tidak tertarik lagi pada server virtual. Waktu CPU tidak dicadangkan seperti RAM, jadi performanya memang buruk sekali dibanding hardware asli. Tulisan pengukuran ini juga layak dibaca
    • Deployment k8s menurutku memang enak sekali untuk dipindah-pindahkan. Vendor lock-in-nya lebih kecil dibanding managed service dari berbagai cloud. Stack-ku juga cuma k8s, hosted Postgres, dan storage mirip s3, jadi Postgres sebenarnya bisa saja ku-host sendiri kapan saja, dan akhirnya yang benar-benar tersisa inti pentingnya cuma k8s dan s3. Sepertinya Hetzner juga punya sesuatu yang mirip s3, tapi aku belum melihatnya, dan memindahkan 100TB sepertinya pekerjaan besar juga
    • Sebagai catatan, HA berarti high availability
    • Tulisan itu masuk akal, tapi email di bagian akhir agak terasa seperti kalimat promosi sehingga sedikit mengganggu

  • Tulisan ini cukup sulit dibaca. Rasanya seperti Claude yang melakukan migrasi, lalu aku membaca laporan yang juga ditulis Claude. Kalau memang penghematan ini terjadi berkat LLM, itu keren, tapi kalau mau dipublikasikan setidaknya seharusnya diedit agar repetisi dan gaya narasi ala LLM dibersihkan

    • Aku tahu banyak orang tidak membaca sumber aslinya, tapi kali ini memang benar-benar menyakitkan untuk dibaca

  • Menurutku Hetzner perlu diwaspadai. Dulu aku sangat suka, tapi belakangan aku pindah keluar. Mereka mematikan sekitar 30 VM yang kami pakai untuk pipeline CI/CD hanya karena satu sengketa tagihan 36 dolar. Padahal kami sudah mengirim bukti pembayaran penuh sampai catatan bank, tapi mereka bahkan tidak mau melihatnya, dan saat kami berusaha menghubungi secara darurat, akses tetap diputus semuanya. Sekarang kami pindah ke Scaleway

    • Customer service mereka terasa cukup bermusuhan. Meski begitu, aku masih memakainya untuk hal-hal yang tidak kritis
    • Penanganan billing Hetzner memang cukup terotomatisasi, tapi biasanya bahkan kalau pembayaran kartu gagal mereka masih memberi tenggang sekitar sebulan untuk melunasi

  • Beberapa bulan lalu aku mencari alternatif AWS untuk proyek sampingan SaaS kecil, dan awalnya cukup serius mempertimbangkan Hetzner demi penghematan biaya sekaligus mendukung cloud EU. Aku rela melakukan lebih banyak sendiri, tapi akhirnya reputasi IP jadi penghalang utama. Salah satu aturan managed AWS firewall di perusahaan tempatku bekerja memblokir banyak, mungkin bahkan semua, IP Hetzner, dan di laptop kerja pun situs yang di-host di IP Hetzner tidak bisa dibuka karena kebijakan IT. Mungkin dengan Cloudflare dampaknya berkurang, tapi aku juga pernah melihat komentar bahwa perlindungan DDoS mereka lemah. Akhirnya aku memilih DO App Platform di region EU, dan opsi managed DB juga jadi nilai tambah besar

    • Kalau pesaing diblokir dengan cara seperti ini, dari sudut pandang Amazon jelas itu metode yang sangat praktis
    • Aku tidak tahu aturan firewall yang dimaksud, tapi kalau DO dianggap lebih tepercaya daripada Hetzner itu cukup mengejutkan. Saat melihat scraper atau hacker, aku juga sering melihat ASN DO, jadi menurutku mereka pun suatu saat bisa ikut diblokir
    • Dalam pengalamanku, IP DO justru lebih parah. Aku juga pindah dari DO tepat karena alasan itu
    • Aku pernah menulis soal isu ini di thread terkait Tor. Dugaanku saat itu, Hetzner cukup ramah terhadap Tor sehingga bisa memengaruhi reputasi IP, walau waktu itu juga ada balasan yang mengatakan tidak ada masalah reputasi. Tapi setelah melihat materi Tor Project, tampaknya Hetzner mencakup sekitar 7% jaringan Tor, jadi ceritanya memang tidak sesederhana itu
    • Ironisnya, aku menyelesaikan 99% masalah bot hanya dengan memblokir AWS dan Azure. Tidak ada dampak ke pengguna nyata, jadi aku malah sempat berpikir untuk menjual fitur blokir ini sebagai layanan tersendiri

  • Cukup bermanfaat dan patut diapresiasi bahwa pengalaman migrasi seperti ini dibagikan. Buatku, perbandingan DO dan Hetzner itu seperti trade-off antara membuka DoorDash atau UberEats versus memasak makan malam sendiri. Rasio biayanya juga terasa mirip. Aku bekerja dengan tiga cloud besar dan on-prem, tapi untuk tugas kecil atau tes PoC, aku masih tetap kembali ke konsol DigitalOcean. Kenyamanan berupa server atau bucket yang siap dengan beberapa klik, sane default, dan backup yang tinggal centang satu kotak jelas punya nilai kalau menghitung harga waktu

    • Aku tidak sepenuhnya yakin menangkap maksudnya, tapi menurutku Console Hetzner juga mirip seperti itu
    • Ada dua hal yang menarik dari tulisan ini. Yang pertama adalah prosedur migrasi tanpa downtime itu sendiri, dan itu bisa dijadikan referensi secara umum. Yang kedua adalah keputusan mengganti instance cloud dengan bare metal, yang berarti penghematan biaya itu juga datang bersama hilangnya failover cepat dan backup tertentu sebagai bagian dari harga yang dibayar. Kalau aku yang melakukannya, mungkin aku akan menambah sekitar 200 dolar untuk satu hot spare, lalu setiap beberapa hari menukar peran primary/secondary untuk memastikan keduanya sama-sama berfungsi normal. Dengan biaya yang relatif kecil, risiko kegagalan fatal bisa berkurang besar
    • Yang baru dijelaskan itu sebenarnya hampir sama dengan pengalaman yang sudah disediakan Hetzner Cloud selama beberapa tahun. Bahkan ada Hetzner Cloud API, jadi semua bisa diatur lewat IaC tanpa perlu klik tombol sama sekali
    • Dalam kasusku, aku memasang Coolify di atas server Hetzner sehingga pengalamannya hampir seperti layanan one-click
    • Melihat situasi ini, yang langsung teringat olehku cuma xkcd ini

  • Aku penasaran bagaimana mereka melakukan backup DB. Apakah ada replica atau standby, atau cuma backup per jam saja. Dalam setup server tunggal seperti ini, kalau ada kerusakan hardware seperti SSD, aplikasi bisa langsung berhenti, dan khususnya kalau SSD mati total, downtime bisa berlangsung berjam-jam atau berhari-hari selama semuanya diset ulang

    • Hetzner biasanya mengiklankan server hardware dengan 2x 1TB SSD, dan sangat menyarankan konfigurasi SW RAID1 agar kapasitas bersihnya jadi 1TB. Installer image mereka pun secara default mengarah ke sana. Jadi meskipun SSD pertama mati beberapa tahun kemudian, kalau monitoring menangkapnya, kita masih bisa pindah ke box baru, memakai solusi antara/replica, atau bertahan di disk lain sambil menunggu hot-swap. Tentu saja kalau pindah ke server fisik kita kehilangan sebagian redundansi cloud, jadi itu harus ikut dihitung dalam model risiko bersama penghematan yang didapat. Dan tanpa backup harian ke storage jarak jauh sekalipun, menurutku itu sudah nekat. Hal ini juga berlaku di cloud, hanya saja pengaturannya lebih mudah
    • Bisa juga downtime selama itu ternyata tidak terlalu dipedulikan siapa pun. Misalnya aplikasi mobile HOA-ku mati seminggu pun aku tidak terlalu peduli. Tidak semua hal perlu selalu aktif
    • Aku juga punya kekhawatiran yang sama. Tulisan ini terasa seperti penulisnya belum cukup memikirkan semuanya dan lebih fokus pada pemangkasan biaya agresif. VM DigitalOcean kemungkinan mendukung live migration dan snapshot, sedangkan di Hetzner itu hanya tersedia pada produk cloud. Di bare metal Hetzner, kalau disk atau komponen mati ya memang mati, dan walaupun mereka mengganti disk-nya, pemulihan tetap harus dilakukan pengguna dari awal. Hetzner juga menjelaskan hal ini dengan cukup jelas di berbagai tempat
    • Yang paling mudah pernah kulakukan justru di MongoDB; replication, sharding, dan failover-nya sangat sederhana. Belakangan di PostgreSQL aku juga memakai pg_auto_failover dengan 1 monitor, 1 primary, dan 1 replica, dan setelah memahami setup serta jebakannya, itu juga cukup mudah. Dalam pengalamanku, migrasi tanpa downtime juga memungkinkan
    • Kalau mereka memutuskan trade-off itu memang layak diterima, menurutku kita tidak bisa langsung menyatakan itu salah. Tidak semua aplikasi butuh ketersediaan 24/7, dan mayoritas situs web tidak akan terlalu terpukul oleh downtime beberapa jam. Kalau penghematan biayanya lebih besar daripada risikonya, itu bisa jadi keputusan bisnis yang sepenuhnya rasional. Yang justru membuatku penasaran adalah strategi backup dan recovery mereka, dan apa saja yang berubah setelah pindah ke Hetzner

  • Gambar meme di header itu buatanku. Aku pernah memakainya di tulisan ini, jadi rasanya menyenangkan melihatnya dipakai dua kali