# Komputasi awan dijelaskan: 11 konsep arsitektur yang wajib Anda ketahui (Masterclass 4K).

Published: 2026-09-15

Sebagian besar insinyur perangkat lunak mencoba mempelajari arsitektur cloud dengan menghafal ratusan akronim produk vendor di AWS, GCP, dan Azure. Namun, rekayasa cloud di dunia nyata dibangun di atas sebelas primitif arsitektur fundamental. Dalam masterclass remaster 4K ini, Niko menguraikan cetak biru perusahaan lengkap: dari penskalaan vertikal versus horizontal dan penyeimbangan beban Layer 7 hingga penskalaan otomatis dinamis, eksekusi microVM tanpa server, dekupling berbasis peristiwa asinkron, orkestrasi kontainer, hierarki penyimpanan empat pilar, perbedaan krusial antara ketersediaan tinggi dan durabilitas 11 nines, Infrastructure as Code deklaratif, dan jaringan Virtual Private Cloud. Kuasai sebelas konsep ini, dan Anda dapat merancang backend apa pun dalam produksi. Putusan: SHIP IT.

Canonical: https://thedailydiff.dev/id/video/2026-09-14-cloud-computing-explained-4k/

## Isi video ini

- - Dinding Arsitektur & Cetak Biru Utama
- - 01. Penskalaan Vertikal vs. Horizontal
- - 02. Arsitektur Penyeimbangan Beban (L4 vs. L7 & Pemeriksaan Kesehatan)
- - 03. Penskalaan Otomatis & Elastisitas
- - 04. Tanpa Server (FaaS & MicroVM Firecracker)

## Bab

- 0:00 - Dinding Arsitektur & Cetak Biru Utama
- 0:57 - 01. Penskalaan Vertikal vs. Horizontal
- 2:17 - 02. Arsitektur Penyeimbangan Beban (L4 vs. L7 & Pemeriksaan Kesehatan)
- 3:45 - 03. Penskalaan Otomatis & Elastisitas
- 4:50 - 04. Tanpa Server (FaaS & MicroVM Firecracker)
- 6:05 - 05. Arsitektur Berbasis Peristiwa (EDA & Dekupling)
- 7:13 - 06. Orkestrasi Kontainer (Docker & Kubernetes)
- 8:16 - 07. 4 Pilar Penyimpanan Cloud (S3, EBS, DB & Redis)
- 9:44 - 08. Ketersediaan Tinggi & Nines (Failover Multi-AZ)
- 10:53 - 09. Durabilitas vs. Ketersediaan (Mengapa 11 Nines Bukan Uptime)
- 12:14 - 10. Infrastruktur sebagai Kode (Terraform vs. Console Drift)
- 13:20 - 11. Jaringan Cloud (VPC, Subnet, NAT & Grup Keamanan)
- 14:26 - 12. Cetak Biru Perusahaan Lengkap & Putusan

## Transkrip terjemahan

Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.

### - Dinding Arsitektur & Cetak Biru Utama

0:00 Setiap insinyur perangkat lunak pada akhirnya menghadapi dinding arsitektur cloud. Anda membangun aplikasi di laptop Anda, mendorongnya ke produksi, dan saat pengguna nyata tiba, server crash, koneksi database habis, dan tagihan AWS Anda terlihat seperti nomor telepon. Sebagian besar pengembang mencoba memecahkan masalah rekayasa cloud dengan menghafal tiga ratus akronim produk AWS yang berbeda. Tetapi komputasi cloud yang sebenarnya bukan tentang menghafal katalog vendor: itu dibangun di atas sebelas primitif arsitektur fundamental.

0:34 Dalam masterclass ini, kami akan membahas seluruh cetak biru perusahaan: dari penskalaan dan penyeimbangan beban hingga tanpa server, dekupling berbasis peristiwa, hierarki penyimpanan, dan jaringan cloud. Kuasai sebelas konsep ini, dan Anda dapat mendesain backend apa pun di AWS, GCP, atau Azure. Ini adalah The Daily Diff, di balik layar.

### - 01. Penskalaan Vertikal vs. Horizontal

0:57 Konsep nomor satu: Penskalaan. Ketika aplikasi Anda mengalami pertumbuhan lalu lintas, Anda memiliki dua cara yang sangat berbeda untuk menangani beban: penskalaan vertikal, atau penskalaan horizontal. Penskalaan vertikal, atau scaling up, berarti mengambil mesin Anda yang ada dan menambahkan lebih banyak sumber daya: meningkatkan dari empat inti CPU menjadi tiga puluh dua, atau menukar tiga puluh dua gigabyte RAM dengan seratus dua puluh delapan. Penskalaan vertikal tidak memerlukan perubahan arsitektur: kode

1:28 dan database Anda tetap persis sama. Tetapi itu mencapai batas perangkat keras yang brutal. Tidak ada satu mesin pun di dunia yang memiliki sepuluh ribu inti CPU, dan instans tingkat atas membawa premi harga eksponensial. Penskalaan horizontal, atau scaling out, berarti menjaga server Anda tetap kecil dan harga komoditas, tetapi menjalankan beberapa instans secara paralel di belakang router. Jika satu instans crash, node yang tersisa menyerap lalu lintas dengan tanpa waktu henti. Aturan emas penskalaan horizontal adalah

2:01 statelessness: server aplikasi Anda tidak dapat menyimpan sesi pengguna, file yang diunggah, atau status di disk lokalnya. Status harus berada di database eksternal atau cache, memungkinkan node mana pun untuk menangani permintaan pengguna mana pun.

### - 02. Arsitektur Penyeimbangan Beban (L4 vs. L7 & Pemeriksaan Kesehatan)

2:17 Konsep nomor dua: Penyeimbangan Beban. Penskalaan horizontal terdengar hebat di atas kertas, tetapi memperkenalkan masalah langsung: ketika sepuluh ribu pengguna mengunjungi nama domain Anda, server spesifik mana yang menerima lalu lintas mereka? Penyeimbang beban bertindak sebagai reverse proxy yang berada di antara internet publik dan kluster backend pribadi Anda. Ini menerima koneksi TCP atau HTTP yang masuk dan mendistribusikan permintaan di seluruh instans sehat Anda.

2:47 Penyeimbang beban beroperasi di dua lapisan jaringan utama. Penyeimbang Beban Jaringan Lapisan 4 beroperasi di lapisan transport, merutekan paket TCP dan UDP mentah berdasarkan alamat IP dan port dengan latensi mikrodetik dan jutaan permintaan per detik. Penyeimbang Beban Aplikasi Lapisan 7 memeriksa protokol HTTP itu sendiri: membaca jalur URL, header permintaan, cookie, dan metode HTTP. Ini memungkinkan perutean berbasis jalur: mengirim permintaan slash-api ke kluster backend Anda dan permintaan slash-static ke

3:25 penyimpanan objek. Yang penting, penyeimbang beban melakukan pemeriksaan kesehatan aktif. Setiap beberapa detik, penyeimbang melakukan ping ke titik akhir kesehatan di setiap instans. Jika sebuah instans melempar tiga kesalahan lima ratus berturut-turut atau gagal merespons, itu secara otomatis dikeluarkan dari pool dengan tanpa permintaan yang terbuang.

### - 03. Penskalaan Otomatis & Elastisitas

3:45 Konsep nomor tiga: Penskalaan Otomatis. Jika aplikasi web Anda membutuhkan dua server pada jam tiga pagi, tetapi dua puluh server selama peluncuran tengah hari, mengklik tombol secara manual di konsol cloud adalah jalur yang dijamin menuju waktu henti dan kebangkrutan. Penskalaan otomatis menghadirkan elastisitas dinamis ke pool server horizontal. Grup Penskalaan Otomatis memantau metrik kinerja seperti rata-rata pemanfaatan CPU, I-O jaringan, atau kedalaman backlog antrean. Ketika rata-rata CPU melewati ambang batas yang ditentukan — katakanlah,

4:19 tujuh puluh persen selama tiga menit berturut-turut — penskala otomatis secara otomatis meluncurkan mesin virtual baru, mendaftarkannya dengan penyeimbang beban Anda, dan mulai merutekan lalu lintas. Sama pentingnya adalah scaling in: ketika gelombang lalu lintas surut, penskala otomatis menghentikan instans yang berlebihan sehingga Anda berhenti membayar untuk komputasi idle. Untuk mencegah flapping — di mana server dengan cepat dibuat dan dihancurkan dalam lingkaran thrashing tanpa akhir — arsitek cloud mengonfigurasi periode pendinginan. Konsep nomor empat: Tanpa Server.

### - 04. Tanpa Server (FaaS & MicroVM Firecracker)

4:53 Selama bertahun-tahun, tim pemasaran mengiklankan tanpa server sebagai kode ajaib yang berjalan di langit. Pada kenyataannya, tanpa server masih menggunakan server — tetapi Anda tidak memiliki, menambal, atau membayarnya ketika tidak ada kode yang berjalan. Dengan Function-as-a-Service seperti AWS Lambda atau Google Cloud Functions, Anda menulis fungsi handler yang berdiri sendiri. Ketika permintaan HTTP, pengunggahan file S3, atau perubahan database terjadi, runtime cloud mem-boot mesin virtual-mikro

5:23 ephemeral seperti Firecracker dalam waktu kurang dari lima milidetik. Kode Anda dieksekusi, mengembalikan respons, dan mati. Jika tidak ada yang mengunjungi situs web Anda selama tiga bulan, tagihan komputasi Anda persis nol dolar dan nol sen. Jika satu juta pengguna mengunjunginya secara bersamaan, penyedia memutar satu juta microVM bersamaan. Trade-off rekayasa itu nyata: latensi cold start saat memutar runtime baru, batas eksekusi lima belas menit yang keras pada Lambda, dan statelessness yang ketat.

5:55 Tanpa server tidak terkalahkan untuk pipeline peristiwa dan API sporadis, tetapi buruk untuk WebSockets persisten atau pelatihan multi-jam.

### - 05. Arsitektur Berbasis Peristiwa (EDA & Dekupling)

6:05 Konsep nomor lima: Arsitektur Berbasis Peristiwa, atau EDA. Dalam arsitektur tradisional, layanan berkomunikasi secara sinkron. Layanan checkout Anda memanggil pembayaran, pembayaran memanggil inventaris, inventaris memanggil penipuan, dan penipuan memanggil email. Ini menciptakan kaskade malapetaka sinkron. Jika penyedia email pihak ketiga mengalami gangguan jaringan dan membutuhkan sepuluh detik untuk merespons, seluruh permintaan checkout pelanggan Anda kehabisan waktu dengan kesalahan. Dalam arsitektur berbasis peristiwa, layanan sepenuhnya terpisah.

6:37 Ketika pelanggan mengklik beli, layanan checkout tidak memanggil layanan downstream. Itu hanya menerbitkan peristiwa yang disebut OrderPlaced ke Bus Peristiwa pusat seperti Amazon EventBridge atau topik SNS. Checkout selesai dalam lima puluh milidetik. Pekerja downstream untuk pembayaran, pengurangan inventaris, dan tanda terima email menarik pesan secara independen dari antrean SQS khusus mereka sendiri. Jika layanan email mati selama satu jam, pesan menunggu dengan aman di-buffer dalam antrean tanpa satu pun pesanan yang hilang.

### - 06. Orkestrasi Kontainer (Docker & Kubernetes)

7:13 Konsep nomor enam: Orkestrasi Kontainer. Docker memecahkan pengemasan: itu membungkus kode aplikasi Anda, perpustakaan sistem, konfigurasi, dan runtime ke dalam gambar yang tidak dapat diubah yang berjalan secara identik di MacBook Anda dan di cloud. Tetapi mengemas kontainer itu mudah. Menjalankan lima ratus kontainer di lima puluh mesin virtual fisik adalah di mana rekayasa terhenti. Itulah mengapa orkestrator kontainer seperti Kubernetes dan AWS ECS

7:41 ada. Orkestrator menyediakan bidang kontrol: server API, penyimpanan status etcd, dan penjadwal cerdas. Anda mendeklarasikan status yang Anda inginkan: Saya ingin sepuluh replika layanan autentikasi saya dengan masing-masing dua gigabyte RAM. Penjadwal memeriksa kluster, menempatkan pod pada node dengan memori kosong, mengonfigurasi jaringan internal, dan terus-menerus menyelaraskan realitas. Jika sebuah node mengalami kegagalan perangkat keras, Kubernetes mendeteksi kehilangan tersebut dan segera menjadwalkan ulang semua pod yang dipindahkan ke node

### - 07. 4 Pilar Penyimpanan Cloud (S3, EBS, DB & Redis)

8:16 yang sehat. Konsep nomor tujuh: Hierarki Penyimpanan Cloud. Pemula sering memperlakukan penyimpanan cloud sebagai satu bucket tempat Anda membuang file. Dalam arsitektur produksi, penyimpanan dibagi menjadi empat pilar yang berbeda berdasarkan pola akses dan latensi. Pertama adalah Object Storage, seperti Amazon S3 atau Google Cloud Storage. Anda mengakses file melalui API HTTP REST menggunakan panggilan PUT dan GET sederhana. Ini menawarkan kapasitas horizontal tak terbatas dengan dua sen per gigabyte per bulan,

8:49 menjadikannya ideal untuk video, unggahan pengguna, log, dan cadangan. Kedua adalah Block Storage, seperti Amazon EBS. Ini adalah hard drive virtual yang dipasang langsung ke mesin virtual tertentu melalui interkoneksi berkecepatan tinggi. Mereka memformat menjadi sistem file standar seperti ext4, mendukung akses baca dan tulis acak cepat yang dibutuhkan oleh mesin database. Ketiga adalah Managed Databases: mesin relasional seperti PostgreSQL di RDS yang menyediakan transaksi ACID dan join kompleks,

9:21 dan mesin NoSQL seperti DynamoDB yang memberikan latensi milidetik satu digit pada skala besar. Dan keempat adalah In-Memory Caches seperti Redis. Membaca data dari RAM membutuhkan mikrodetik daripada milidetik. Cache berada di depan database Anda, melindunginya dari lalu lintas baca berulang dan mengelola token sesi pengguna yang volatil.

### - 08. Ketersediaan Tinggi & Nines (Failover Multi-AZ)

9:44 Konsep nomor delapan: Ketersediaan Tinggi, atau HA. Ketersediaan menjawab satu pertanyaan: berapa persen waktu aplikasi Anda beroperasi dan dapat dijangkau oleh pengguna? Dalam kontrak perusahaan, ketersediaan diukur dalam nines. Dua nines, atau ketersediaan sembilan puluh sembilan persen, memungkinkan lebih dari tiga setengah hari waktu henti setiap tahun. Empat nines menurunkan waktu henti yang diizinkan menjadi lima puluh dua menit, dan lima nines hanya mengizinkan lima menit total waktu henti per

10:15 tahun. Untuk mencapai ketersediaan tinggi, Anda harus menghilangkan satu titik kegagalan di seluruh domain kesalahan. Di cloud, itu berarti menyebarkan di beberapa Zona Ketersediaan. Zona Ketersediaan bukanlah satu rak: itu adalah satu atau lebih pusat data fisik yang berbeda terpisah beberapa mil dengan daya dan pendingin independen. Dengan menjalankan instans aktif di Zona A dan Zona B dengan replikasi database sinkron, sambaran petir atau putusnya serat optik yang menyebabkan seluruh fasilitas fisik mati mengakibatkan failover otomatis.

10:50 dalam tiga puluh detik tanpa intervensi manusia.

### - 09. Durabilitas vs. Ketersediaan (Mengapa 11 Nines Bukan Uptime)

10:53 Konsep nomor sembilan: Ketahanan versus Ketersediaan. Ini adalah jebakan konseptual paling umum dalam wawancara arsitektur cloud . Teknisi sering menggunakan kata-kata ini secara bergantian, tetapi keduanya mengukur properti yang sama sekali berbeda. Ketersediaan mengukur waktu aktif: dapatkah saya melakukan panggilan API untuk membaca atau menulis data saya saat ini juga? Ketahanan mengukur pelestarian: apakah data saya akan bertahan tanpa kerusakan bit, korupsi, atau penghancuran permanen selama sepuluh tahun? kerusakan bit, korupsi, atau penghancuran permanen selama sepuluh tahun?

11:24 Lihat Amazon S3 Standard. Perjanjian Tingkat Layanannya menawarkan ketersediaan sembilan puluh sembilan koma sembilan persen, yang memungkinkan sekitar empat puluh tiga menit waktu henti setiap bulan di mana permintaan API mungkin mengembalikan kesalahan lima ratus. Tetapi S3 menjanjikan sebelas sembilan ketahanan: sembilan puluh sembilan koma sembilan sembilan sembilan sembilan sembilan sembilan sembilan sembilan sembilan persen. Jika Anda menyimpan sepuluh juta file di S3, Anda secara statistik dapat berharap kehilangan rata-rata satu file setiap sepuluh ribu tahun.

11:56 rata-rata satu file setiap sepuluh ribu tahun. S3 mencapai ini dengan mengkodekan objek dan mereplikasi potongan di setidaknya tiga fasilitas data yang terpisah secara geografis. setidaknya tiga fasilitas data yang terpisah secara geografis. Selama pemadaman jaringan regional yang besar, S3 mungkin untuk sementara tidak tersedia, tetapi data Anda tidak pernah dihancurkan.

### - 10. Infrastruktur sebagai Kode (Terraform vs. Console Drift)

12:14 Konsep nomor sepuluh: Infrastructure as Code, atau IaC. Pada masa-masa awal komputasi awan, para insinyur masuk ke konsol manajemen web AWS dan secara manual mengklik-klik untuk membuat mesin virtual, mengkonfigurasi subnet, dan melampirkan grup keamanan. Industri menyebutnya ClickOps, dan dalam produksi, itu adalah bencana mutlak. Perubahan konsol manual tidak memiliki jejak audit, tidak ada mekanisme rollback, dan mau tidak mau menyebabkan pergeseran konfigurasi antara lingkungan staging dan produksi. Dengan alat Infrastructure as Code seperti Terraform,

12:48 seperti Terraform, OpenTofu, Pulumi, atau AWS CDK, Anda mendefinisikan seluruh arsitektur cloud Anda seluruh arsitektur cloud Anda dalam file konfigurasi deklaratif yang disimpan di Git. Setiap perubahan pada port terbuka atau replika basis data melalui permintaan pull dan tinjauan sejawat. permintaan pull dan tinjauan sejawat. Menjalankan "terraform plan" melihat pratinjau perbedaan API yang tepat sebelum apa pun disentuh, dan membuat replika identik dari tumpukan produksi Anda membutuhkan empat menit, bukan empat minggu. membutuhkan empat menit, bukan empat minggu.

### - 11. Jaringan Cloud (VPC, Subnet, NAT & Grup Keamanan)

13:20 Konsep nomor sebelas: Jaringan Cloud dan Virtual Private Clouds. Ketika Anda menyebarkan server ke cloud, server tersebut tidak terpapar langsung di internet publik. Mereka hidup di dalam batas terisolasi yang didefinisikan oleh perangkat lunak yang disebut VPC. disebut VPC. Di dalam VPC Anda, Anda mengalokasikan ruang alamat IP pribadi seperti sepuluh-titik-nol-titik-nol-titik-nol garis miring enam belas, dan membaginya menjadi subnet publik dan pribadi. Subnet publik memiliki rute langsung ke Internet Gateway.

13:51 Ini menampung aset yang menghadap publik seperti Application Load Balancer dan NAT Gateway Anda. Gateways. Ini adalah satu-satunya bagian dari jaringan Anda yang memiliki alamat IP publik. alamat. Server aplikasi dan basis data produksi Anda hidup murni di subnet pribadi tanpa IP publik dan nol rute masuk dari internet. internet. Ketika server backend Anda perlu mengunduh pembaruan keamanan, lalu lintas keluar mereka merutekan melalui NAT Gateway di subnet publik. subnet. Di sekitar setiap instance terdapat Grup Keamanan: firewall virtual stateful virtual stateful yang menegakkan prinsip hak istimewa terkecil.

### - 12. Cetak Biru Perusahaan Lengkap & Putusan

14:28 Grup keamanan basis data Anda hanya menerima koneksi pada port 5432 hanya dari grup keamanan server aplikasi Anda, membuat penetrasi dari luar secara matematis tidak mungkin. Ketika Anda melihat lebih jauh, kesebelas primitif ini terhubung menjadi satu sistem yang kohesif. DNS Anda merutekan ke Load Balancer di subnet publik, grup penskalaan otomatis menangani lonjakan lalu lintas di beberapa Availability Zone, bus acara memisahkan pekerja backend, dan seluruh tumpukan Anda disebarkan dari Git menggunakan Infrastructure as Code.

15:02 Putusan kelas master hari ini: SHIP IT. Berhenti menghafal ratusan akronim pemasaran cloud. Kuasai sebelas pola arsitektur ini, pisahkan keadaan Anda, dan bangun sistem yang tidak bisa gagal. Beri tahu saya konsep cloud mana yang paling membuat Anda pusing saat pertama kali memulai membangun di kolom komentar. Dan untuk mendapatkan lembar contekan arsitektur lengkap, berlangganan buletin di the daily diff dot dev,

15:28 tautan di bawah. Dan itulah perbedaannya untuk hari ini. Saya Niko dari Axrisi. Gabungkan secara bertanggung jawab.

## Sumber

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io