Belajar Cloud Computing - Content Delivery Network (CDN) & Cloud DNS

#Pendahuluan

Di episode 12 kita men-deploy aplikasi dengan container dan Kubernetes. Namun deployment yang baik tidak berarti pengalaman pengguna yang baik: jika seluruh server kalian berada di Singapura, pengguna di London harus menempuh perjalanan jaringan ribuan kilometer untuk setiap gambar, file, dan script. Di sinilah dua layanan jaringan yang saling melengkapi berperan: CDN untuk memperpendek perjalanan konten, dan cloud DNS untuk menuntun nama domain ke tujuan yang tepat.

Episode 13 ini membahas mengapa latensi itu soal fisika jarak, bagaimana CDN menyimpan konten di edge location di seluruh dunia — termasuk konten dinamis — dan bagaimana cloud DNS melakukan traffic management dengan routing berbasis latensi, geolokasi, serta failover otomatis berdasarkan health check.

#Mengapa Latensi: Fisika Jarak

Latensi adalah waktu yang dibutuhkan data melakukan perjalanan. Cahaya di dalam serat optik menempuh sekitar dua pertiga kecepatan cahaya di ruang hampa — setiap 1000 kilometer menambah sekitar 5 milidetik per arah, belum lagi peralatan jaringan di setiap hop.

Seorang pengguna di London akan merasa aplikasi "lemot" bukan karena servernya lemah, melainkan karena setiap byte harus menempuh puluhan ribu kilometer. Solusinya bukan memperkuat server — melainkan mendekatkan data ke pengguna.

#CDN: Konten yang Menunggu di Pinggir Dunia

CDN (Content Delivery Network) adalah jaringan server cache yang tersebar di edge locations di seluruh dunia. Ketika pengguna di Jakarta meminta sebuah file, CDN mengarahkan request ke edge terdekat, bukan ke origin server di London.

Cara kerjanya sederhana:

1. Permintaan pertama mencapai edge — edge belum punya file (cache miss) — edge mengambil dari origin, menyimpannya, lalu mengembalikannya ke pengguna.
2. Permintaan berikutnya dari pengguna mana pun di wilayah itu mencapai edge — file sudah tersedia (cache hit) — dikirim langsung tanpa menyentuh origin.
3. Setiap file diberi TTL: selama belum kedaluwarsa, edge melayani dari cache; setelah kedaluwarsa, edge mengecek origin lagi.

#Konten Dinamis: Lebih dari Sekadar Cache

CDN bukan hanya untuk file statis. Untuk konten dinamis — HTML yang berbeda per pengguna, hasil autentikasi, atau API — CDN tetap berguna lewat dua mekanisme:

• Smart routing: traffic dioptimalkan melewati jalur terbaik ke origin, termasuk koneksi keep-alive yang dipakai ulang, sehingga mengurangi latensi jaringan.
• Dynamic content acceleration: koneksi antara edge dan origin dioptimalkan sehingga respons API terasa lebih cepat meski tidak bisa di-cache.

Selain itu, CDN menjadi lapisan perlindungan pertama terhadap DDoS: ribuan edge menyerap volume serangan sebelum mencapai origin. Ini juga alasan mengapa di episode 14 nanti, CDN disebut sebagai bagian dari pertahanan berlapis.

#Praktik: Invalidasi Cache di CloudFront

Salah satu operasi paling umum adalah invalidasi cache: ketika konten baru di-deploy, file lama di edge harus dihapus agar pengguna tidak mendapat versi basi. Di AWS dilakukan dengan aws cloudfront create-invalidation:

aws cloudfront create-invalidation \
  --distribution-id E1XYZEXAMPLE \
  --paths "/index.html" "/assets/*"

Perintah ini memberi tahu CloudFront bahwa index.html dan semua file di folder assets harus dianggap kedaluwarsa di seluruh edge. Di GCP, operasi yang sama dilakukan lewat Cloud CDN dengan invalidate cache pada backend service; di Azure, lewat Azure Front Door dengan purge content. Konsepnya sama — hanya nama dan sintaks yang berbeda.

#Cloud DNS dan Traffic Management

Setelah konten dekat dengan pengguna, pertanyaan berikutnya: bagaimana nama domain toko-kalian.id menemukan server yang benar? DNS (Domain Name System) adalah direktori internet yang menerjemahkan nama domain menjadi alamat IP.

Cloud DNS berarti nama domain dikelola oleh provider — AWS Route 53, GCP Cloud DNS, Azure Azure DNS — dengan jangkauan global dan SLA tinggi. Nilai lebihnya bukan sekadar resolusi nama, melainkan traffic management: keputusan cerdas tentang IP mana yang dijawab, berdasarkan kondisi real-time.

• Routing berbasis latency: tanyakan DNS dari Singapura, dijawab IP Singapura; dari London, dijawab IP London. Setiap pengguna diarahkan ke region terdekat.
• Routing berbasis geolokasi: jawab berbeda berdasarkan negara atau benua — misalnya wajibkan pengguna Indonesia ke server Indonesia untuk kepatuhan data.
• Failover berbasis health check: DNS memeriksa kesehatan endpoint secara berkala; jika primary mati, jawaban otomatis berpindah ke secondary. Inilah ketahanan alamat tanpa perlu menambah server.

#Praktik: Menelusuri Resolusi DNS dengan dig

Untuk memverifikasi jawaban DNS, kalian bisa menggunakan dig atau nslookup langsung dari terminal. Contoh menelusuri alamat yang dijawab untuk sebuah domain:

dig +short toko-kalian.id
54.230.200.10

Hasilnya adalah alamat IP yang dijawab oleh DNS. Jika kalian menjalankan dig +short dari dua lokasi berbeda pada konfigurasi routing berbasis latency, hasilnya bisa berbeda — itulah bukti DNS melakukan traffic management. Untuk melihat detail lengkap termasuk TTL dan authoritative nameserver, jalankan dig toko-kalian.id ANY atau nslookup toko-kalian.id — keduanya menampilkan laporan yang sama, hanya formatnya berbeda.

Untuk menambah record baru di Route 53, AWS menyediakan aws route53 change-resource-record-sets — perintah yang mengirim perubahan DNS dalam format JSON:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1ABC2DEF3G4H \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.toko-kalian.id.",
          "Type": "A",
          "TTL": 300,
          "ResourceRecords": [
            { "Value": "203.0.113.10" }
          ]
        }
      }
    ]
  }'

Perhatikan perbedaan TTL yang mencolok antara praktik CDN dan DNS: TTL DNS menentukan berapa lama resolver boleh menyimpan jawaban. TTL pendek (misalnya 300 detik) berarti perubahan DNS — seperti pemindahan IP karena failover — tersebar cepat, sedangkan TTL panjang menghemat query DNS.

#Komparasi Layanan CDN dan DNS Big 3

Ketiga cloud menawarkan pasangan CDN dan DNS yang sama lengkapnya. Sering kali keduanya dipakai bersama-sama: CDN membutuhkan DNS untuk mengarahkan pengguna ke edge yang tepat, dan DNS cerdas membutuhkan data tentang lokasi pengguna — keduanya saling melengkapi untuk satu tujuan: membuat aplikasi terasa lokal bagi setiap pengguna di dunia.

#Penutup

Pada episode 13 ini kalian telah memahami dua lapisan yang membuat aplikasi terasa cepat dan andal secara global: CDN yang mendekatkan konten statis dan dinamis ke edge locations sehingga pengguna di mana pun dilayani oleh server terdekat, dan cloud DNS dengan traffic management — routing berbasis latensi, geolokasi, dan failover health check — yang menuntun nama domain ke tujuan terbaik. Kalian juga berlatih invalidasi cache lewat aws cloudfront create-invalidation, membaca hasil dig, dan menambah record dengan aws route53 change-resource-record-sets.

Kunci yang harus dibawa pulang:

• CDN mendekatkan konten ke pengguna — latensi adalah soal jarak, dan edge adalah jawabannya.
• DNS adalah direktori sekaligus pengatur traffic — health check menjadikannya lapisan failover otomatis.
• Kombinasi CDN dan DNS membuat aplikasi global — cepat untuk semua, di mana pun mereka berada.

Aplikasi kalian kini cepat dan mudah dijangkau — dan karena itu, makin layak untuk diserang. Semakin populer sebuah layanan, semakin menarik ia bagi penyerang. Episode 14 akan membangun pertahanan di atas fondasi jaringan yang sudah kalian kuasai: Cloud Security, Firewall & Web Application Firewall (WAF) — pertahanan berlapis yang melindungi aplikasi yang sudah kalian bangun sejauh ini.