Beberapa pembaca mungkin sudah tau kalau di tahun ini gue lagi tertarik memperdalam tentang “distributed system” dan “network engineering”. In general gue tertarik dengan bagaimana internet—literally—bekerja. Dari beberapa hal yang sudah gue pelajari, hal pertama yang ingin gue bagikan adalah tentang Content Delivery Network atau yang biasa disebut dengan CDN.
Siapa yang menggunakan CDN?
Sebelum kita masuk ke pembahasan apa itu CDN, mari kita lihat layanan (populer) apa saja yang menggunakan CDN.
Kasus Fastly’s outage pada 8 Juni 2021 kemarin setidaknya menjelaskan bahwa Reddit dan StackOverflow menggunakan layanan CDN dari mereka. Selain layanan populer yang menggunakan Fastly sebagai solusi CDN mereka, ada Shopify yang menggunakan Cloudflare dan Streamble yang menggunakan Bunny.
Setiap CDN memiliki fitur uniknya masing-masing, dan fitur umum yang ditawarkan oleh CDN adalah satu: membuat layanan (terasa) dekat dengan pengguna, dimanapun pengguna berada.
Apa itu CDN?
Pada dasarnya CDN hanyalah kumpulan komputer yang berada diberbagai lokasi dan saling terhubung. Komputer-komputer tersebut biasa disebut dengan Point of Presence atau PoP.
Penyedia layanan CDN biasanya memiliki 1/lebih PoP yang tersebar di berbagai kota-kota besar. Tugas dari PoP tersebut pada dasarnya hanya satu: mengatur pertukaran paket yang ada.
Mengapa ada CDN?
Komputer dapat berkomunikasi dengan komputer lain melalui sesuatu yang disebut alamat IP. Dalam jaringan internet, alamat IP yang umum digunakan bersifat publik, dan bila alamat IP tersebut publik, berarti si pengelola alamat IP tersebut “menyewa” dari sebuah organisasi yang disebut Regional Internet Registry atau RIR yang terdiri dari RIPE NCC, APNIC, ARIN, LACNIC, NRO dan AFRINIC.
Ambil salah satu contoh misalnya alamat IP 27.112.79.80, yang mana memiliki subnet 27.112.79.0/24 di jaringan 27.112.78.0/23 yang terdaftar di IDNIC, yang mana bagian dari APNIC untuk wilayah Indonesia.
Karena setiap alamat IP pasti terdaftar—berikut dengan wilayahnya—siapapun dapat mengetahui dari wilayah mana sebuah koneksi tersebut berasal. Internet adalah jaringan yang kompleks, yang saling terhubung dari level antar kota; negara, sampai benua.
Jika gue mengakses server yang mengatur permintaan ke github.com dari jaringan gue sekarang, high-level view nya adalah seperti ini:
Dengan catatan bila server github.com berada di San Francisco
Sebenarnya gambarannya tidak sesederhana itu, di lower-level view, kira-kira seperti ini:
sorry buat pemilihan warna yang kurang aksesibel
Dengan catatan bila kita menggunakan peta dunia versi bumi datar dan kondisi diatas tergantung ISP yang digunakan serta server yang ingin dituju.
Oke, ilustrasi diatas sumbernya gue ambil dari hasil traceroute(8) ke server github.com. Masalah dari kasus diatas adalah latensi dan sayangnya, latensi adalah sesuatu yang tidak bisa dihindari.
Mengapa latensi ini penting karena berdasarkan “riset” ternyata angka latensi ini berpengaruh terhadap bisnis, silahkan cari sendiri referensinya karena gue males ngomongin bisnis.
Masalah diatas mungkin dapat diselesaikan dengan cara menjalankan banyak server di berbagai kota besar. Namun tentu saja ada biaya yang harus dibayar, dan melihat ada peluang bahwa masalah tersebut dapat menjadi bisnis, maka lahirlah perusahaan-perusahaan yang bergerak di industri CDN yang *exactly *melakukan apa yang seharusnya dilakukan: menjalankan banyak server di berbagai kota besar.
Cara kerja CDN
Server-server atau PoPs yang tersebar diberbagai daerah tersebut secara teknis bertindak sebagai penghubung alias *proxy. *Dan penghubung tersebut bekerja sebagai penerus paket yang datang dari pengguna dan mengembalikannya.
Agar gue gak terlalu capek ngedit gambar, gue akan ambil contoh PoPs nya Fastly yang diambil dari halaman ini.
Fastly PoPs. Sumber
Ketika kita (user) mengakses github.com dari Jakarta, koneksi yang ada adalah seperti ini:
Mengakses github.com via PoP nya Fastly di Singapore
Lalu bukankah berarti Fastly harus mengakses server github.com yang ada di San Francisco juga? Benar, namun, bukan dari PoP yang ada di Singapore, melainkan dari PoP yang terdekat dengan server github.com yakni di San Francisco juga.
Bagaimana itu bisa terjadi? Magic!
Oke oke, rahasianya ada di BGP Routing yang nanti akan gue bahas detailnya.
Dengan menggunakan CDN, dari sisi pengguna kita tidak akan mendapatkan latensi yang besar karena permintaan kita menuju ke wilayah yang paling dekat dengan wilayah kita. Dari sisi pemilik layanan, salah satunya mereka tidak perlu menjalankan server di banyak tempat, karena itu pada dasarnya tugasnya si CDN hahaha.
That Cache thing
Biasanya bagian yang paling banyak dijual oleh CDN adalah Cache Hit Ratio, yang bahkan itu dijadikan metriks akan kehandalan layanan CDN mereka. Dan itu *make sense *mengingat halaman website hanyalah sebuah dokumen dan kebanyakan website adalah dokumen statis.
Seperti, ketika kamu mengakses halaman ini, pada dasarnya yang membedakan kamu dengan pembaca lainnya hanyalah:
- User Agent (sistem operasi, browser, berikut dengan propertinya)
- Bahasa yang digunakan (via alamat IP misalnya)
Jika situs kita tidak bergantung dengan 2 hal diatas, pada dasarnya tidak ada yang membedakan kamu dengan pembaca/pengunjung lainnya.
Beda cerita kalau misalnya halaman ini sangat bergantung dengan wilayah negara pengunjung berasal (misal untuk mengarahkan pengunjung ke situs khusus negara tersebut), kapabilitas peramban yang ada (misal halaman ini hanya bisa berjalan di Google Chrome for some random reason) dan lain sebagainya.
Nah, misal, karena tidak ada bagian yang membedakan tersebut, CDN bisa membantu untuk mengurangi beban server kita dengan memberikan response yang sudah disimpan oleh si CDN. Misal, jika ada 1000 orang yang mengakses halaman ini dalam waktu yang sama, berarti ada 1000 permintaan yang masuk ke server gue dalam waktu tersebut.
Dengan bantuan CDN, permintaan yang masuk ke server gue mungkin cuma 1, karena yang 999 nya berasal dari response yang sudah disimpan oleh CDN dengan catatan gue tidak membedakan 2 poin yang sudah disebutkan diatas.
Jika permintaan tersebut response nya langsung diberikan oleh CDN, berarti cache tersebut biasanya disebut HIT. Yang berarti, jika cache HIT ratio nya adalah 99%, kasarnya dari 1000 request, 999 request yang ada tidak menyentuh origin server (server kita) sama sekali.
That DDoS thing
Distributed Denial of Service atau yang biasa disebut dengan DDoS adalah teknik penyerangan yang paling mudah dilakukan. Tidak perlu ribet mengakses server target untuk mematikan layanan, cukup kirim yang misalnya paket berukuran 500M dari 100 komputer, maka besar kemungkinan server tersebut akan tumbang karena tidak kuat menangani paket masuk sebanyak 50GB/s.
CDN biasanya menawarkan layanan untuk menyelesaikan masalah tersebut yang biasa disebut dengan DDoS Protection.
Cara kerjanya relatif sederhana, pertama, PoPs ataupun router di CDN misalnya dapat menangani paket sebanyak 1TB/s dan kedua, CDN mengetahui mana paket yang normal dan kurang normal berdasarkan, ehm, machine learning.
Hahaha tentu saja berdasarkan pola.
Dan jika paket tersebut dianggap kurang normal, maka PoPs ataupun router di CDN akan “drop” paket tersebut bahkan sebelum menyentuh server kita.
That GeoDNS thing
Ketika user mengakses github.com, berarti user mengakses komputer yang memiliki alamat IP 13.229.188.59 (per 12 Juni 2021). Domain Name System atau DNS adalah sistem yang digunakan di jaringan internet untuk mempermudah pengguna dengan mengingat alamat domain daripada alamat IP nya.
Di DNS, terdapat 3 komponen utama:
- DNS Authotritative Server yang bertugas menjawab alamat alamat IP dari permintaan DNS recursor
- DNS Recusor yang bertugas menerjemahkan alamat domain menjadi alamat IP dari permintaan DNS resolver
- DNS Resolver yang bertugas untuk menanyakan alamat IP dari alamat domain ke DNS recursor
DNS yang digunakan oleh pengguna ada di poin terakhir, resolver tersebut bisa Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) ataupun yang sudah disediakan oleh ISP.
Jika github.com menggunakan strategi Geo DNS, maka Authoritative Name Server akan menjawab dengan alamat IP yang berbeda-beda tergantung wilayah geografi pengguna.
Mari kita ke contoh nyata: facebook.com. Ketika user ingin mengakses facebook.com, DNS authoritative server Facebook akan menjawab dengan alamat IP yang berbeda-beda tergantung dengan lokasi si user tersebut. Untuk mencoba, gue akan menggunakan fitur EDNS Client Subnet atau ECS sehingga gue tidak perlu menggunakan VPN untuk proses percobaannya.
9.9.9.11 adalah DNS resolver dari Quad9 yang mendukung ECS
Disitu terlihat bahwa DNS Resolver mendapatkan alamat IP berbeda-beda untuk alamat domain yang sama berdasarkan letak geografis penggunanya (yang diasumsikan dengan Client subnet).
Banyak alasan mengapa menggunakan Geo DNS namun yang pasti adalah sebagai “traffic director” dan jika kita menggunakan CDN, kemungkinan besar itu sudah tugas CDN. Geo DNS termasuk teknologi yang relatif sudah lama dan yang mana kemungkinan besar akan tergantikan oleh adopsi Anycast yang akan kita bahas setelah ini.
That anycast thing
Anycast ini bukanlah teknologi yang unik digunakan oleh CDN, namun kebanyakan CDN pasti menggunakan teknologi ini.
Dengan bahasa yang paling sederhana, anycast intinya adalah ketika 1 alamat IP (publik) digunakan di banyak komputer.
Kita ambil contoh stackoverflow.com yang mana menggunakan layanan CDN dari Fastly. Berapapun alamat IP yang digunakan oleh pengunjungnya ketika mengakses stackoverflow.com, alamat IP yang diberikan oleh authoritative servernya StackOverflow akan selalu sama (per 12 Juni 2021):
- 151.101.1.69
- 151.101.65.69
- 151.101.129.69
- 151.101.193.69
Yang urutannya berbeda-beda. Untuk mengujinya, kita bisa membuat permintaan melalui HTTP(S) Proxy dan melihat bagian Header nya (X-Served-By) yang merepresentasikan lokasi PoP yang digunakan:
Contoh alamat IP anycast untuk stackoverflow.com
Yang mana tangkapan layar diatas menjelaskan bahwa:
- Permintaan pertama dengan proxy London response nya dari New York (LGA)
- Permintaan kedua dengan proxy Paris response nya dari Amsterdam (AMS)
- Permintaan ketiga dan terakhir dengan proxy Bangladesh dan tanpa proxy response nya dari Singapore (QPG)
Yang intinya, response diberikan oleh PoP terdekat dengan pengguna dan hanya melalui 1 alamat IP (terlepas .1.69, .129.169, .65.69, ataupun .193.69).
Gue sebenarnya ingin bercerita lebih banyak tentang Anycast IP ini terlebih gue sudah bereksperimen dengan BGP juga, tapi karena terlalu keluar dari konteks pembahasan, please give me another shot later!
Apakah saya butuh CDN?
Akhirnya kita ke pembahasan inti.
Jawaban singkat untuk pertanyaan tersebut adalah: most likely no.
Menggunakan CDN menurut gue seperti kita berlangganan asuransi: kita tidak bisa memprediksi masa depan dan somehow kita tidak ingin shit happens tapi ketika itu terjadi, setidaknya kita sudah memikirkan & memitigasinya.
Jadi, untuk jawaban yang lebih panjang, mari kita jawab berdasarkan threat model yang sudah kita pikirkan.
Bandwidth
Biaya bandwidth relatif murah dan juga biasanya hanya menagih egress traffic (trafik dari server ke internet). Egress traffic di salah satu server gue di DigitalOcean Singapore untuk Mei 2021 sekitar 24.45GiB berdasarkan vnstat(1).
Jika gue menggunakan Google Cloud, mungkin seharga 0.05/GB untuk egress wilayah Asia, untuk hanya biaya egress bandwidth aja.
Dan itu relatif murah, terlebih gue tidak menjalankan layanan yang banyak memakan bandwidth juga.
Jika lo memiliki layanan yang banyak memakan bandwidth (ada nampilin video, gambar HD, dsb) mungkin bisa pertimbangkan menggunakan CDN untuk menghemat biaya tersebut dan in case media tersebut bersifat statis.
Selainnya, dan terlebih bila tidak menjadikan harga bandwidth sebagai masalah, sekali lagi, most likely kita tidak membutuhkan CDN.
DDoS
Ini bagian yang paling gampang dijual oleh CDN.
Namun biasanya layanan penyedia infrastruktur yang kita gunakan sudah menyediakan DDoS Protection di level router mereka.
Jika DDoS menjadi salah satu yang dikhawatirkan, dan terlebih bila penyedia infrastruktur (ataupun karena menggunakan in-house data center) tidak menyediakan DDoS Protection, mungkin bisa mempertimbangkan untuk menggunakan CDN.
Selainnya, sekali lagi, most likely kita tidak membutuhkan CDN.
Latency
Ini menurut gue hanya cocok untuk yang target pasarnya sudah bukan lokal lagi.
Jika target pasar masih lokal, pengunjung dari Bandung yang mengakses server lo yang berada di Jakarta tersebut hanya memiliki perbedaan beberapa milidetik dengan pengunjung yang dari Pandeglang.
Tapi jika perbedaan 2ms bisa merugikan bisnis lo sebesar 4jt/ms, mungkin bisa pertimbangkan untuk cari bisnis lain?
Hahaha.
Anyway, di bagian ini menurut gue yang paling penting dalam menentukan apakah butuh menggunakan CDN atau tidak. Sebagai kesimpulan, jika latency adalah masalah yang saat ini lo alami, coba pertimbangkan dulu untuk melacak dimana latensi yang ada.
Dan bila sudah sangat yakin bahwa latensi yang paling menimbulkan masalah adalah ada di waktu ketika pengguna ingin menghubungi server lo, mungkin bisa pertimbangkan untuk menggunakan CDN.
Selainnya, sekali lagi, most likely kita tidak membutuhkan CDN.
FUD
Siapa yang tidak khawatir dengan ketidakpastian?
Dan ini menurut gue yang paling laku dijual.
Biasanya, diiming-imingi dengan pertanyaan sebagai pemilihan copy: gimana kalau tiba-tiba situs lo viral? Gimana kalau tiba-tiba server lo kena DDoS? Gimana kalau tiba-tiba cinta datang kepadaku saat kumulai mencari cinta?
I’m sorry for the last one.
Ketakutan, ketidakpastian, dan keraguan atau FUD adalah bagian yang paling laku dijual terlebih bila kita menganggap CDN adalah seperti asuransi.
Terlebih, “Network is reliable” menjadi salah satukekeliruan yang paling populer di dunia distributed computing.
Dan ini sangat sulit untuk ditolak.
Namun untuk orang-orang yang memiliki prinsip YOLO ataupun filosofi “Let it crash” nya Erlang (yang gue cherrypick), yes, sekali lagi, most likely kita tidak membutuhkan CDN.
Bagaimana kalau tiba-tiba situs viral? Cool. Jika menggunakan infrastruktur yang mendukung autoscaling & scale to zero, gue rasa pertanyaan “gimana kalau tiba-tiba situs viral?” sudah tidak lagi seseram pertanyaan “itu di kerah ada lipstik siapa?”
Penutup
CDN memang berguna, namun perlu diketahui juga apakah kita sudah membutuhkannya atau belum.
Alternatif dari CDN adalah Application Delivery Network atau ADN, yang menjadi lawan dari CDN itu sendiri. Jika CDN menjembatani pengguna dengan layanan kita ke lokasi yang paling dekat melalui PoP nya, ADN pada dasarnya menjadi jembatan itu sendiri, thanks to anycast network.
Yang berarti, kalau lo ingin membangun bisnis CDN sendiri tanpa harus memakan biaya & administrasi yang lebih panjang, menjalankan aplikasi di layanan yang menawarkan ADN mungkin bisa menjadi solusi.
Jenis ADN yang bisa dijalankan pun beragam. Ada yang berjenis “Serverless” alias sebuah function yang hanya dieksekusi ketika ada request aja seperti Cloudflare Worker; AWS Lambda, dan dsb, ada yang berjenis “Micro VM” ataupun container seperti Google Cloud Run, AWS Fargate, Heroku, dan Fly.io, dsb.
Kekurangan di industri Infrastructure As a Service alias IaaS sejauh yang gue tau adalah satu: Anycast VPS, dan alasan gue sederhana: tidak semua layanan membutuhkan CDN & tidak semua aplikasi harus berjalan secara on-demand.
Fly.io gue rasa solusi yang paling mendekati dari terkait Anycast VPS ini, technically gue bisa aja depoy Ubuntu container; menjalankan beberapa script untuk menjalankan beberapa program, membuat beberapa port mapping, dsb.
Namun sayangnya ada satu kekurangan dari fly.io: TLS certificate.
Sejauh ini fly.io hanya bisa untuk 1 domain = 1 aplikasi, gue tidak bisa deploy s.edgy.network, dns.edgy.network, yt.edgy.network di 1 “micro VM” dengan benefit Anycast IP yang ditawarkan oleh fly.io.
Benefit anycast IP bukan hanya untuk pengguna akhir, melainkan dari sisi operator pun tidak perlu repot-repot misalnya seperti menerapkan “load balancing” untuk menentukan “backend” mana yang bisa diakses, karena technically, semua “backend” tersebut memiliki 1 alamat IP.
Sebagai penutup, ya, most likely kita tidak membutuhkan CDN.
Jika cache hit ratio menjadi satu-satu nya alasan menggunakan CDN, mungkin bisa mempertimbangkan membaca MDN? Karena bukankah pada dasarnya bagian pembedanya hanya 1: Ketika menggunakan layanan CDN, “end user” tersebut adalah PoP.
Dan tugas PoP pada dasarnya adalah meneruskan permintaan dari pengguna akhir ke origin server jika tidak ada cache, ataupun karena tidak ada kebijakan terhadap PoP untuk “meng-cache” permintaan tersebut dari origin server.
Benar?