Saatnya Menyinkronkan Konsistensi dalam Sistem IIoT
Topik penting (dan diperdebatkan dengan hangat) dalam desain sistem terdistribusi adalah model konsistensi mana yang akan digunakan. Model konsistensi mempengaruhi banyak bagian dari desain sistem, dan memilih salah satu dari yang lain berdampak pada hal-hal seperti ketersediaan sistem dan ketahanan terhadap kegagalan jaringan. Blog ini ditujukan untuk arsitek sistem yang ingin memahami dengan lebih baik apa artinya menjadi konsisten atau tidak.
Pertama, mari kita klarifikasi bahwa blog ini bukan tentang "C" di ACID (https://en.wikipedia.org/wiki/ACID). Konsistensi ACID memastikan bahwa pembaruan ke penyimpanan data valid sesuai dengan serangkaian batasan. Blog ini berfokus pada jenis konsistensi yang menjelaskan apa yang terjadi ketika data direplikasi antar toko terdistribusi. Ternyata, ACID tidak mengatakan sesuatu tentang itu, tetapi itu adalah "Aku" (Isolasi), bukan "C." Membingungkan? Sedikit, tapi bersabarlah.
Isolasi juga disebut sebagai konsistensi yang kuat . Ketika sistem sangat konsisten, semua penulisan dan pembacaan antara penyimpanan terdistribusi dijalankan dalam urutan yang sama untuk setiap aplikasi dalam sistem itu. Itu adalah cara yang rumit untuk mengatakan, ketika satu aplikasi menulis sesuatu, semua aplikasi membaca setelah menulis, dijamin untuk melihat data baru.
Ini ternyata menjadi properti yang sangat berguna di banyak sistem. Ini memastikan bahwa tidak ada dua orang yang dapat memesan lemari es yang sama dari situs belanja, bahkan ketika mereka membeli pada waktu yang sama. Konsistensi yang kuat memberlakukan urutan operasi yang sama secara global , jadi dua pembelian selalu diproses oleh semua orang dalam urutan yang sama. Dalam praktiknya, ini berarti bahwa upaya pembelian kedua dijamin untuk memastikan bahwa lemari es sudah habis.
Konsistensi yang kuat terdengar seperti hal yang cukup rapi untuk dimiliki, jadi mengapa tidak semua sistem menggunakannya? Itu karena sesuatu yang disebut teorema CAP (https://en.wikipedia.org/wiki/CAP_theorem). Pertama, catatan singkat:CAP telah dikritik oleh banyak orang karena terlalu sederhana untuk menggambarkan perilaku sistem terdistribusi yang kompleks – jadi berhati-hatilah saat menggunakannya – tetapi CAP menyediakan kerangka kerja yang berguna untuk membahas model konsistensi. Saya tidak akan membahas detail CAP karena internet memiliki banyak sumber daya yang melakukan pekerjaan yang jauh lebih baik daripada yang saya harapkan di sini.
Singkatnya, CAP memberi tahu kita apa yang terjadi dalam sistem terdistribusi ketika aplikasi kehilangan kemampuan untuk "berbicara" untuk sementara waktu, atau dengan kata lain:ketika jaringan mati. Ternyata tidak mungkin sebuah sistem menjadi sangat konsisten dan selalu menjamin uptime, terlepas dari hilangnya konektivitas. Menyedihkan.
Kedengarannya rumit, tetapi sebenarnya cukup intuitif. Ingat bagaimana konsistensi yang kuat membutuhkan tatanan global untuk semua operasi dalam suatu sistem? Itu artinya bacaan harus lihat semua tulisan sebelumnya, dari semua orang. Jika tidak semua aplikasi terhubung, maka ini menjadi tidak mungkin untuk dijamin. Satu aplikasi mungkin telah memesan lemari es, tetapi jika belum semua aplikasi menerima pesanan ini, mereka tidak dapat melakukan pemesanan baru. Itu mengakibatkan downtime untuk situs belanja!
Waktu henti dapat dikurangi dengan membuang lebih banyak sumber daya pada masalah, seperti melakukan replikasi basis data (lebih banyak penyimpanan) atau menggunakan server web yang berlebihan (lebih banyak komputasi). Saat ini hal ini hampir sepele untuk dilakukan di infrastruktur cloud publik, meskipun menjadi cukup mahal dan kompleks ketika suatu sistem memiliki banyak bagian yang bergerak, seperti dengan arsitektur layanan mikro. Saat sistem tidak berjalan di cloud, menambahkan lebih banyak sumber daya bukanlah hal yang sepele karena penyimpanan, komputasi, dan bandwidth jauh lebih terbatas di lingkungan non-cloud.
Jadi, meskipun konsistensi yang kuat nyaman untuk aplikasi, ini membebani infrastruktur (dan dompet Anda!). Untuk mengatasi masalah ini, orang pintar telah menemukan solusi yang tidak terlalu rumit dalam hal konsistensi, tetapi masih bisa diterapkan dari perspektif aplikasi. Apa yang kita bicarakan adalah "konsistensi akhirnya." Saatnya untuk definisi lain.
Suatu sistem akhirnya konsisten ketika, jika tidak ada pembaruan untuk item tertentu, semua aplikasi akhirnya melihat nilai yang sama. Atau dalam istilah awam:semua orang akhirnya melihat data yang sama jika mereka menunggu cukup lama. Ini berarti bahwa aplikasi dapat membaca dan menulis pada saat yang sama, dan dapat melakukannya bahkan saat jaringan sedang tidak aktif! Akhirnya, infrastruktur sistem mengirimkan semua pembaruan ke aplikasi.
Karena aplikasi tidak harus menunggu satu sama lain, waktu kerja sistem yang pada akhirnya konsisten secara teoritis tidak terbatas – asalkan aplikasi Anda tidak mogok atau terjadi pemadaman listrik. Namun tak terbatas tidak praktis; setelah beberapa waktu Anda mengharapkan aplikasi Anda terhubung kembali. Oleh karena itu, pada akhirnya sistem yang konsisten biasanya membatasi waktu yang diperlukan untuk menjadi konsisten. Ketika batas tersebut kedaluwarsa, dan aplikasi tidak memiliki kesempatan untuk menyinkronkan, pemulihan kegagalan terjadi.
Ketersediaan bukan satu-satunya keuntungan dari sistem yang pada akhirnya konsisten. Karena membaca dan menulis tidak memerlukan sinkronisasi, seperti halnya dengan sistem yang sangat konsisten, mereka jauh lebih cepat. Kurangnya sinkronisasi juga memungkinkan komunikasi peer-to-peer langsung, yang selanjutnya meningkatkan kinerja sekaligus juga meningkatkan ketahanan, karena menghilangkan kebutuhan akan perantara pesan terpusat, yang memperkenalkan satu titik kegagalan.
Meskipun konsistensi akhirnya tidak berfungsi untuk situs web belanja, ketika mempertimbangkan keunggulannya (ketersediaan, kinerja, ketahanan, efisiensi sumber daya), tidak mengherankan jika konsistensi sering digunakan dalam sistem yang sangat penting.
RTI Connext Product Suite adalah implementasi terdepan dari standar OMG DDS, yang digunakan secara luas sebagai protokol dalam sistem IoT Industri yang sangat penting. Perbedaan besar antara OMG DDS dan protokol konektivitas lainnya, adalah bahwa DDS berperilaku seperti database terdistribusi yang terus-menerus disinkronkan antar aplikasi, sedangkan protokol lain biasanya menyediakan antarmuka untuk mengirim pesan dan menyerahkan pengelolaan status ke aplikasi.
Jika Anda berpikir bahwa database terdistribusi terdengar seperti sesuatu yang harus berurusan dengan konsistensi, Anda benar. RTI Connext DDS harus terus-menerus menyeimbangkan ketersediaan dan kinerja versus konsistensi untuk dapat bekerja di lingkungan misi-kritis yang paling menuntut. Secara default, RTI Connext DDS menggunakan konsistensi akhirnya yang menjamin bahwa aplikasi yang dibangun dengannya tidak berhenti bekerja ketika jaringan gagal, sambil memastikan bahwa semua aplikasi pada akhirnya berbagi pandangan yang sama tentang "dunia".
Sekarang Anda melihat bagaimana sesuatu yang terdengar abstrak seperti "konsistensi" memiliki konsekuensi yang luas dan harus diperlakukan sebagai topik penting dalam desain sistem awal. Sayangnya, tidak pernah sesederhana menjadi "sangat konsisten" atau "pada akhirnya konsisten". Arsitektur lambda (https://en.wikipedia.org/wiki/Lambda_architecture) hanyalah salah satu contoh yang menggunakan konsistensi yang kuat dan akhirnya untuk mendapatkan yang terbaik dari kedua dunia. Dengan begitu banyak nuansa konsistensi, arsitek sistem harus membuat keputusan yang rumit tentang seberapa banyak konsistensi yang dapat diberikan sistem mereka.
Di RTI, tim layanan profesional kami membantu Anda membuat keputusan tersebut, mempertimbangkan konsekuensinya, dan mengonfigurasi produk kami untuk menciptakan solusi konsistensi yang sesuai untuk Anda.
Pelajari lebih lanjut tentang layanan RTI di sini:https://www.rti.com/services
