Koordinasi layanan dan pengelolaan state

Mengembangkan Aplikasi di AWS

Ricardo Sueiras

Principal Technologist

Koordinasi Layanan

 

• Banyak layanan harus bekerja bersama menyelesaikan suatu alur kerja.
• Mereka membutuhkan strategi koordinasi.
• Dua pendekatan: orchestration dan choreography.

Orchestration

 

• Orchestrator pusat mengoordinasikan alur kerja.
• Orchestrator mengendalikan urutan dan menentukan layanan berikutnya.
• Berguna untuk retry, logika kondisional, dan penanganan error.
• Di AWS: diimplementasikan dengan Step Functions lintas Lambda, ECS, DynamoDB.

Orchestration

 

• Logika alur kerja tersentral, sehingga debugging dan pemantauan lebih mudah.
• Konsekuensi: menambah ketergantungan pusat.

Choreography

• Tidak ada pengendali pusat.
• Layanan bereaksi terhadap event secara mandiri.
• Tiap layanan mendengarkan event relevan dan menjalankan tugasnya.
• Tak ada layanan yang perlu tahu seluruh alur kerja.
• Meningkatkan loose coupling dan skalabilitas.

 

Choreography

• Di AWS: EventBridge, SNS, SQS.
• Sangat skalabel.
• Konsekuensi: makin sulit dipahami dan di-debug saat alur kerja membesar.

 

Arsitektur berbasis event

• Layanan berkomunikasi dengan memproduksi dan mengonsumsi event.
• Mendorong loose coupling antarlayanan.
• Mendorong skalabilitas tinggi.
• Memungkinkan pemrosesan event paralel.
• Layanan baru dapat berlangganan tanpa mengubah yang ada.

 

Arsitektur berbasis event

 

• Trade-off saat menerapkan EDA:
• Rancang untuk eventual consistency.
• Terapkan idempotency.
• Penanganan kegagalan lebih kompleks.

Idempotency

 

• Operasi yang sama dijalankan berulang menghasilkan hasil yang sama.
• Prinsip desain krusial pada sistem asinkron dan berbasis event.
• Sistem terdistribusi bisa mengirim event duplikat (retry, kegagalan jaringan, reprocessing).
• Menjaga kebenaran dan keandalan sistem.

Dead letter queues

 

• Mengelola kegagalan dalam komunikasi asinkron.
• Mengisolasi pesan bermasalah "poison".
• Setelah berkali-kali retry gagal, pesan dipindah ke DLQ.
• Alur pemrosesan utama tetap berjalan.

Dead letter queues

• Gunakan saat urutan pesan tidak kritis.
• Lewati untuk sistem tidak kritis yang menerima kehilangan data sesekali.
• Hindari saat urutan pesan harus dipertahankan.

 

Mengelola state

• Mengelola state adalah dasar aplikasi cloud native.
• State adalah data yang disimpan antarinteraksi.
• Menyimpan state lokal di server membatasi skalabilitas dan ketahanan.

 

Mengelola state

• Pengelolaan state punya trade-off tergantung yang Anda bangun.
• State eksternal meningkatkan skalabilitas dan ketahanan.
• Biaya: latensi dan kompleksitas tambahan.
• Pertimbangkan: konsistensi, caching, dan pola akses data.

 

Stateful

 

• Data sesi disimpan di server.
• Permintaan harus diarahkan ke instance yang sama (sticky session).
• Membatasi fleksibilitas skala.
• Jika instance gagal, sesi hilang.

Stateless

 

• Setiap permintaan diproses independen.
• Tidak ada state disimpan di server.
• State berada di sistem eksternal.
• Pendekatan yang disukai untuk aplikasi cloud native.
• Instansi mana pun dapat menangani permintaan apa pun, sehingga skala horizontal mudah.

Ayo berlatih!

Mengembangkan Aplikasi di AWS