Pola arsitektur aplikasi di AWS

Mendeploy Aplikasi di AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Kenali instruktur Anda

Instruktur kursus Dunieski Otano, seorang AWS Solutions Architect, dengan pengalaman cloud sekitar sepuluh tahun

Mengapa arsitektur yang tepat penting

Diagram keputusan tema terang dengan satu simpul pilihan arsitektur bercabang ke tiga faktor: coupling, state, dan komunikasi, di atas ikon timbangan kecil untuk trade-off

Arsitektur adalah serangkaian trade-off, bukan satu jawaban benar
- Tiga pertanyaan membentuk tiap pilihan:
  - Seberapa erat komponen terkait (coupled)?
  - Di mana state berada?
  - Komunikasi sinkron atau asinkron?
- Cocokkan pola dengan workload, bukan tren

Rantai kegagalan di malam Jumat

API pembayaran lambat membekukan seluruh checkout
Semua layanan menunggu sinkron padanya
Solusinya arsitektur, bukan API yang lebih cepat

Perbandingan berdampingan layanan yang saling terkait erat sehingga macet vs layanan yang dipisahkan oleh message queue

Mengapa pilihan arsitektur menentukan deployment

Diagram yang membandingkan arsitektur rapuh dengan keterkaitan erat di mana satu layanan gagal memicu kegagalan berantai ke semua layanan vs desain tangguh di mana buffer antrian mengisolasi kegagalan sehingga layanan lain tetap melayani

Pola yang Anda pilih membentuk cara aplikasi menskalakan dan gagal
- Desain yang erat putus saat beban naik
Pola yang tepat membuat deployment terprediksi
- Kode sama, perilaku produksi sangat berbeda

Pola arsitektur inti

Monolithic: satu unit deploy, mudah memulai
Microservices: layanan independen, dideploy terpisah
Event-driven: komponen bereaksi pada event, bukan panggilan langsung
- Fanout adalah subpola event-driven: satu event ke banyak konsumen

Tiga pola arsitektur aplikasi berdampingan: monolithic sebagai satu blok bertumpuk, microservices sebagai layanan yang dapat dideploy mandiri, dan event-driven dengan event bus, dengan fanout ditunjukkan sebagai subpola berlabel di panel event-driven yang memublikasikan satu event ke banyak konsumen

Stateful vs stateless

Stateless: tidak menyimpan data klien antar-permintaan
- Instans mana pun bisa menangani permintaan mana pun
Stateful: instans mengingat interaksi sebelumnya
Stateless memungkinkan Anda menskalakan horizontal
- Pindahkan state bersama ke DynamoDB atau ElastiCache

Instans fungsi stateless di kiri yang dapat menerima permintaan apa pun vs instans stateful di kanan yang terikat ke satu sesi klien

Tight vs loose coupling

Keterkaitan erat dengan pemanggil terblokir menunggu pemanggil yang lambat vs keterkaitan longgar dengan antrian SQS yang mem-buffer pesan sehingga produsen tetap bekerja

Tight coupling: pemanggil menunggu respons dari yang dipanggil
Satu layanan lambat menghentikan seluruh rantai
Loose coupling: antrian Amazon SQS di antara layanan
Produsen tetap bekerja meski konsumen sedang down

Sinkron vs asinkron

Synchronous: pemanggil memblokir dan menunggu hasil
Gunakan saat pemanggil butuh jawaban sekarang
Asynchronous: pemanggil menyerahkan kerja lalu kembali
Gunakan untuk pekerjaan lambat, memuncak, atau tidak mendesak

Panggilan sinkron dengan pemanggil terblokir hingga respons tiba di kiri vs penyerahan asinkron yang langsung kembali dengan pemrosesan latar belakang di kanan

Pola ketangguhan untuk panggilan pihak ketiga

Retry dengan exponential backoff: jeda makin lama antar upaya
Circuit breaker: hentikan panggilan ke layanan yang gagal sementara waktu
Dead-letter queue: tampung pesan yang terus gagal
Kombinasikan; retry membabi buta memperparah gangguan

Tiga pola ketangguhan: kurva retry dengan exponential backoff, circuit breaker menghentikan panggilan ke layanan gagal, dan dead-letter queue menangkap pesan yang menghabiskan retry

Ayo berlatih!

Mendeploy Aplikasi di AWS