Back to IF3130 Sistem Paralel dan Terdistribusi
Arsitektur, Prinsip Desain, dan Skalabilitas ST
Questions/Cues
Mengapa kita butuh ST?
Apa itu Inherent Distribution?
Apa itu Distribusi sebagai Artifak?
Apa tantangan utama (kesulitan) ST?
Apa itu Middleware?
Apa 4 goals utama desain ST?
Apa itu Distribution Transparency?
Sebutkan jenis-jenis transparansi!
Apa itu Openness?
Apa itu Scalability (Skalabilitas)?
Apa 3 dimensi Skalabilitas?
Apa saja teknik skalabilitas?
Teknik: Hiding Latency?
Teknik: Distribution?
Teknik: Replication/Caching?
Reference Points
- Slides 23-33
Mengapa Membangun Sistem Terdistribusi?
Ada dua alasan utama:
Inherent Distribution (Distribusi Alami): Aplikasinya secara alami memang membutuhkan penyebaran informasi atau pembagian sumber daya antar entitas yang tersebar secara geografis.
- Contoh: ATM (bank di lokasi beda-beda), sistem reservasi tiket, World Wide Web (WWW), game online.
Distribusi sebagai Artifak (Alat): Distribusi digunakan sebagai “alat” untuk solusi masalah tertentu, meskipun masalahnya sendiri awalnya tidak terdistribusi.
Contoh: Replicated servers (server yang digandakan) digunakan untuk mencapai fault tolerance (jika satu server mati, yang lain mengambil alih) atau untuk meningkatkan performance/cost ratio dan QoS (Quality of Service).
Tantangan Utama (Mengapa Sulit?)
Tiga hal utama yang membuat sistem terdistribusi sulit dirancang:
Konkurensi: Banyak hal terjadi bersamaan. Perlu penanganan khusus untuk akses bersama ke sumber daya (data, file) agar tetap konsisten.
Sinkronisasi: Karena tidak ada global clock, mengoordinasikan waktu dan urutan kejadian antar komputer yang berbeda itu sangat sulit.
Failures: Komponen (komputer, jaringan) bisa gagal kapan saja secara independen. Sistem harus bisa mendeteksi dan pulih dari kegagalan ini.
Arsitektur: Middleware
Banyak sistem terdistribusi modern menggunakan lapisan (layer) perangkat lunak yang disebut Middleware.
Posisinya berada di antara Local OS (Sistem Operasi lokal di tiap komputer) dan Aplikasi.
Tujuannya adalah untuk menyembunyikan kompleksitas dan heterogenitas (perbedaan) dari sistem terdistribusi. Middleware menyediakan tampilan yang seragam dan konsisten bagi aplikasi, seolah-olah semuanya berjalan di satu mesin.
Contoh arsitektur modern adalah Kubernetes Cluster, yang mengabstraksi Control Plane (manajemen) dan Compute Machines (tempat aplikasi/container berjalan).
Goals (Tujuan) Desain Sistem Terdistribusi
Ada empat tujuan utama saat mendesain ST:
Making resources available (Membuat sumber daya tersedia/dapat diakses)
Distribution Transparency (Transparansi Distribusi)
Openness (Keterbukaan)
Scalability (Skalabilitas)
Desain Goal: Distribution Transparency
Tujuan: Menyembunyikan fakta bahwa proses dan sumber daya sebenarnya tersebar di banyak komputer. Sistem harus terlihat satu dan utuh bagi pengguna.
Jenis-jenis Transparansi Detail Access Menyembunyikan perbedaan representasi data dan cara pemanggilan (misal: beda OS, beda bahasa) Location Menyembunyikan di mana sebuah objek (data/layanan) berada Migration Menyembunyikan fakta bahwa sistem bisa memindahkan objek ke lokasi lain saat sedang digunakan Relocation Mirip migration, tapi menyembunyikan dari client bahwa lokasi objek telah berubah Replication Menyembunyikan fakta bahwa sebuah data/layanan digandakan (direplikasi) di banyak lokasi Concurrency Menyembunyikan fakta bahwa banyak pengguna lain mungkin sedang mengakses objek yang sama secara bersamaan Failure Menyembunyikan kegagalan dan proses pemulihan (recovery) dari sebuah objek Peringatan: Transparansi penuh itu berlebihan dan seringkali tidak mungkin (misal: menyembunyikan kegagalan total) dan bisa mengorbankan kinerja.
Desain Goal: Openness (Keterbukaan)
Tujuan: Sistem harus conform (patuh) pada interface (antarmuka) yang terdefinisi dengan baik.
Ini memungkinkan sistem untuk:
Portability: Mudah dipindahkan.
Interoperability: Mudah dihubungkan/berinteraksi dengan sistem lain.
Intinya adalah membuat sistem independen terhadap heterogenitas (perbedaan) hardware, platform (OS), dan bahasa pemrograman.
Desain Goal: Scalability (Skalabilitas)
Tujuan: Sistem harus tetap efisien dan berkinerja baik meskipun terjadi peningkatan beban yang signifikan.
Tiga Dimensi Skalabilitas:
Size Scalability: Kemampuan menangani penambahan jumlah pengguna atau proses.
Geographical Scalability: Kemampuan untuk tetap berfungsi baik meskipun jarak maksimal antar node sangat jauh (misalnya, antar benua).
Administrative Scalability: Kemampuan untuk tetap mudah dikelola meskipun berada di bawah banyak domain administratif yang berbeda (misal: beda perusahaan, beda departemen).
Teknik-Teknik Skalabilitas
Hide Communication Latency (Menyembunyikan Latensi):
Gunakan komunikasi asinkron. Pengirim tidak perlu menunggu balasan dan bisa lanjut bekerja.
Gunakan handler terpisah untuk memproses balasan yang datang nanti.
Distribution (Distribusi):
Partisi data dan komputasi: Pecah data dan pekerjaan ke banyak mesin.
Pindahkan komputasi ke client (misal: JavaScript di browser, applet).
Contoh data terdesentralisasi: DNS (Domain Name System).
Replication / Caching (Replikasi / Caching):
Gandakan data/layanan di banyak lokasi (replicated file servers).
Gunakan cache untuk menyimpan salinan data yang sering diakses lebih dekat ke pengguna (web cache, file cache).
Sistem terdistribusi dibangun karena kebutuhan alami (inherent) atau sebagai alat (artifact) untuk mencapai fault tolerance dan kinerja, namun memiliki tantangan konkurensi, sinkronisasi, dan failure. Arsitektur modern seperti middleware bertujuan untuk mencapai Openness (keterbukaan/interoperabilitas) dan Distribution Transparency (menyembunyikan kompleksitas). Tujuan utamanya adalah Scalability, yang dicapai melalui tiga teknik utama: hiding latency (komunikasi asinkron), distribution (partisi data), dan replication/caching (menggandakan data).
Additional Information
Pendalaman: Masalah Konsistensi Replikasi
Teknik Replication/Caching adalah kunci skalabilitas, namun ia memunculkan masalah baru: Bagaimana menjaga agar semua salinan (replika) tetap konsisten?
Ini melahirkan konsep Consistency Models (Model Konsistensi):
Strong Consistency (Konsistensi Kuat):
Juga dikenal sebagai Linearizability.
Menjamin bahwa setiap operasi (baca/tulis) terlihat terjadi seketika (instan). Begitu sebuah data ditulis, semua pembaca di mana pun akan melihat data baru tersebut.
Kelebihan: Sangat mudah dipahami oleh programmer (seperti bekerja di satu mesin).
Kekurangan: Sangat lambat dan mahal. Membutuhkan banyak komunikasi antar node untuk berkoordinasi (sering menggunakan algoritma konsensus seperti Paxos/Raft).
Eventual Consistency (Konsistensi Pada Akhirnya):
Asumsi yang lemah. Sistem menjamin bahwa jika tidak ada update baru, semua replika pada akhirnya (eventually) akan memiliki nilai yang sama.
Ini memperbolehkan adanya periode di mana replika berbeda-beda (stale read).
Kelebihan: Sangat cepat (operasi tulis bisa langsung dibalas) dan sangat available (bisa tetap beroperasi saat jaringan terpartisi).
Kekurangan: Sulit dipahami oleh programmer. Aplikasi harus bisa menangani data yang mungkin kedaluwarsa atau konflik (misal: dua orang mengedit data yang sama di dua replika berbeda conflict resolution).
Contoh: DNS, Amazon DynamoDB, Cassandra.
Pendalaman: Pola Partisi Data (Sharding)
Teknik Distribution (partisi data) sering disebut Sharding. Ini adalah teknik memecah database besar menjadi potongan-potongan kecil (shard) yang disimpan di server berbeda.
Tujuan: Horizontal Scaling untuk database.
Strategi Sharding:
Range-Based Sharding: Data dipartisi berdasarkan range dari shard key.
Contoh: Shard A (User ID 1-1000), Shard B (User ID 1001-2000).
Kelebihan: Mudah melakukan range query (ambil semua user dari 100-200).
Kekurangan: Risiko Hotspot. Jika User ID baru selalu berurutan (1001, 1002, 1003…), semua operasi tulis akan menghantam Shard B, membuat server itu kelebihan beban.
Hash-Based Sharding: Data dipartisi berdasarkan hash dari shard key.
Contoh:
shard_id = hash(user_id) % jumlah_shard.Kelebihan: Distribusi data jauh lebih merata. Tidak ada hotspot.
Kekurangan: Range query menjadi mustahil (User ID 100 dan 101 bisa berada di shard yang berbeda).
Sumber & Referensi Lanjutan:
Paper Dynamo: “Dynamo: Amazon’s Highly Available Key-value Store” (Paper klasik tentang eventual consistency dan desain sistem AP).
Artikel: “Database Sharding” (Banyak artikel online yang menjelaskan strategi sharding secara mendalam).