Distribusi data global dengan Azure Cosmos DB - di balik layar

  • Artikel

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Azure Cosmos DB adalah layanan dasar di Azure, sehingga digunakan di semua wilayah Azure di seluruh dunia termasuk awan publik, kedaulatan, Departemen Pertahanan (DoD) dan pemerintah.

Pada tingkat tinggi, data kontainer Azure Cosmos DB container dipartisi secara horizontal ke banyak replica-set, yang mereplikasi tulis, di setiap wilayah. Replica-set menerapkan tulis menggunakan sebagian kuorum secara lama.

Setiap wilayah berisi semua partisi data kontainer Azure Cosmos DB dan dapat melayani bacaan serta melayani penulisan saat penulisan multi-wilayah diaktifkan. Jika akun Azure Cosmos DB Anda didistribusikan di seluruh wilayah N Azure, setidaknya akan ada salinan N x 4 dari semua data Anda.

Dalam pusat data, kami menyebarkan dan mengelola Azure Cosmos DB pada mesin besar, masing-masing dengan penyimpanan lokal khusus. Dalam pusat data, Azure Cosmos DB disebarkan di banyak kluster, masing-masing berpotensi menjalankan beberapa generasi perangkat keras. Mesin dalam kluster biasanya tersebar di 10-20 domain kesalahan untuk ketersediaan tinggi dalam suatu wilayah. Gambar berikut menunjukkan topologi sistem distribusi global Azure Cosmos DB:

Topologi Sistem

Distribusi global di Azure Cosmos DB adalah turnkey: Kapan saja, dengan beberapa klik atau secara terprogram dengan satu panggilan API, Anda dapat menambahkan atau menghapus wilayah geografis yang terkait dengan database Azure Cosmos DB Anda. Database Azure Cosmos DB, pada gilirannya, terdiri dari satu set kontainer Azure Cosmos DB. Di Azure Cosmos DB, kontainer berfungsi sebagai unit distribusi dan skalabilitas logis. Koleksi, tabel, dan grafik yang Anda buat adalah (secara internal) hanya kontainer Azure Cosmos DB. Kontainer benar-benar bersifat skema-agnostik dan menyediakan ruang lingkup untuk kueri. Data dalam kontainer Azure Cosmos DB secara otomatis diindeks setelah penyerapan. Pengindeksan otomatis memungkinkan pengguna untuk mengueri data tanpa kerepotan manajemen skema atau indeks, terutama dalam persiapan distribusi global.

  • Di wilayah tertentu, data dalam kontainer didistribusikan dengan menggunakan kunci partisi, yang Anda sediakan dan dikelola secara transparan oleh partisi fisik yang mendasarinya (distribusi lokal).

  • Setiap partisi fisik juga direplikasi di seluruh wilayah geografis (distribusi global).

Saat aplikasi yang menggunakan Azure Cosmos DB secara elastis menskalakan throughput pada kontainer Azure Cosmos DB atau menggunakan lebih banyak penyimpanan, Azure Cosmos DB secara transparan menangani operasi manajemen partisi (memisahkan, mengkloning, menghapus) di semua wilayah. Terlepas dari skala, distribusi, atau kegagalan, Azure Cosmos DB terus memberikan gambar sistem tunggal dari data dalam kontainer, yang didistribusikan secara global di sejumlah wilayah.

Seperti yang ditunjukkan pada gambar berikut, data dalam kontainer didistribusikan sepanjang dua dimensi - dalam wilayah dan lintas wilayah, di seluruh dunia:

partisi fisik

Partisi fisik diimplementasikan oleh grup replika, yang disebut replica-set. Setiap mesin menge-host ratusan replika yang sesuai dengan berbagai partisi fisik dalam serangkaian proses tetap seperti yang ditunjukkan pada gambar di atas. Replika yang sesuai dengan partisi fisik ditempatkan secara dinamis dan muatannya load-balanced di seluruh mesin dalam kluster dan pusat data dalam suatu wilayah.

Replika unik milik penyewa Azure Cosmos DB. Setiap replika menghosting instans mesin database Azure Cosmos DB, yang mengelola sumber daya serta indeks terkait. Mesin database Azure Cosmos DB beroperasi pada sistem jenis berbasis atom-record-sequence (ARS). Mesinnya agnostik terhadap konsep skema, mengaburkan batas antara struktur dan nilai instans rekaman. Azure Cosmos DB mencapai agnostikisme skema penuh dengan secara otomatis mengindeks semuanya setelah penyerapan dengan cara yang efisien, yang memungkinkan pengguna untuk mengkueri data mereka yang didistribusikan secara global tanpa harus berurusan dengan skema atau manajemen indeks.

Mesin database Azure Cosmos DB terdiri dari komponen termasuk implementasi beberapa primitif koordinasi, runtime bahasa, prosesor kueri, dan subsistem penyimpanan dan pengindeksan yang bertanggung jawab untuk penyimpanan transaksional dan pengindeksan data, masing-masing. Untuk memberikan daya tahan dan ketersediaan tinggi, mesin database mempertahankan data dan indeksnya pada SSD dan mereplikasinya di antara instans mesin database dalam replica-set. Penyewa yang lebih besar sesuai dengan skala throughput dan penyimpanan yang lebih tinggi dan memiliki replika yang lebih besar atau lebih banyak atau keduanya. Setiap komponen sistem sepenuhnya asinkron – tidak ada blokir utas, dan setiap utas melakukan pekerjaan berumur pendek tanpa menimbulkan peralihan yang tidak perlu. Pembatasan tarif dan tekanan balik dialirkan di seluruh tumpukan dari kontrol penerimaan ke semua jalur I/O. Mesin database Azure Cosmos DB dirancang untuk mengeksploitasi konkurensi terperinci dan untuk memberikan throughput tinggi saat beroperasi dalam jumlah sumber daya sistem yang hemat.

Distribusi global Azure Cosmos DB bergantung pada dua abstraksi utama - set replika dan set partisi. Replica-set adalah blok Lego modular untuk koordinasi, dan partition-set adalah overlay dinamis dari satu atau lebih partisi fisik yang didistribusikan secara geografis. Untuk memahami cara kerja distribusi global, kita perlu memahami dua abstraksi utama ini.

Replica-set

Partisi fisik terwujud sebagai kelompok replika yang dikelola sendiri dan load-balanced secara dinamis yang tersebar di beberapa domain kesalahan, yang disebut replica-set. Set ini secara kolektif mengimplementasikan protokol mesin status yang direplikasi untuk membuat data dalam partisi fisik sangat tersedia, tahan lama, dan konsisten. Keanggotaan replica-set N bersifat dinamis – tetap berfluktuasi antara NMin dan NMax berdasarkan kegagalan, operasi administratif, dan waktu untuk replika yang gagal untuk regenerasi/pemulihan. Berdasarkan perubahan keanggotaan, protokol replikasi juga mengonfigurasi ulang ukuran kuorum baca dan tulis. Untuk mendistribusikan throughput secara seragam yang ditetapkan ke partisi fisik tertentu, kami menggunakan dua ide:

  • Pertama, biaya pemrosesan permintaan tulis pada pemimpin lebih tinggi daripada biaya penerapan pembaruan pada pengikut. Oleh karena itu, pemimpin dianggarkan lebih banyak sumber daya sistem daripada pengikut.

  • Kedua, sejauh mungkin, kuorum baca untuk tingkat konsistensi tertentu disusun hanya dari replika pengikut. Kami menghindari menghubungi pemimpin untuk melayani baca kecuali diperlukan. Kami menggunakan sejumlah ide dari penelitian yang dilakukan pada hubungan beban dan kapasitas dalam sistem berbasis kuorum untuk lima model konsistensi yang didukung Azure Cosmos DB.

Partition-set

Sekelompok partisi fisik, satu dari masing-masing yang dikonfigurasi dengan wilayah database Azure Cosmos DB, disusun untuk mengelola kumpulan kunci yang sama yang direplikasi di semua wilayah yang dikonfigurasi. Primitif koordinasi yang lebih tinggi ini disebut partition-set - overlay partisi fisik dinamis yang didistribusikan secara geografis yang mengelola seperangkat kunci. Meski partisi fisik yang diberikan (replica-set) tercakup dalam kluster, partition-set dapat mencakup kluster, pusat data, dan wilayah geografis seperti yang ditunjukkan pada gambar di bawah ini:

Set Partisi

Anda dapat menganggap partition-set sebagai “super replica-set” yang tersebar secara geografis, terdiri dari beberapa replica-set yang memiliki sekumpulan kunci sama. Mirip dengan replica-set, keanggotaan partition-set juga dinamis - ini berfluktuasi berdasarkan operasi manajemen partisi fisik implisit untuk menambahkan/menghapus partisi baru ke/dari partition-set tertentu (misalnya, ketika Anda menskalakan throughput pada kontainer, menambahkan/menghapus wilayah ke database Azure Cosmos DB Anda, atau ketika kegagalan terjadi). Karena masing-masing partisi (dari partition-set) mengelola keanggotaan partition-set dalam replica-set sendiri, keanggotaan sepenuhnya terdesentralisasi dan sangat tersedia. Selama konfigurasi ulang partition-set, topologi overlay antara partisi fisik juga didirikan. Topologi dipilih secara dinamis berdasarkan tingkat konsistensi, jarak geografis, dan bandwidth jaringan yang tersedia antara sumber dan partisi fisik target.

Layanan ini memungkinkan Anda mengonfigurasi database Azure Cosmos DB dengan satu wilayah tulis atau beberapa wilayah tulis, dan tergantung pada pilihannya, set partisi dikonfigurasi untuk menerima penulisan di satu atau semua wilayah. Sistem ini menggunakan protokol konsensus bersarang dua tingkat – satu tingkat beroperasi dalam replika replica-set dari partisi fisik yang menerima tulisan, dan yang lain beroperasi pada tingkat partition-set untuk memberikan jaminan pengurutan lengkap untuk semua penerapan tulisan dalam partition-set. Konsensus berlapis berlapis ini sangat penting untuk implementasi SLA kami yang ketat untuk ketersediaan tinggi, serta implementasi model konsistensi, yang ditawarkan Azure Cosmos DB kepada pelanggannya.

Resolusi konflik

Desain kami untuk propagasi pembaruan, resolusi konflik, dan pelacakan kausalitas terinspirasi dari pekerjaan sebelumnya pada algoritma epidemi dan sistem Bayou. Meskipun kernel ide-ide telah bertahan dan memberikan bingkai referensi yang nyaman untuk mengomunikasikan desain sistem Azure Cosmos DB, mereka juga telah mengalami transformasi signifikan saat kami menerapkannya ke sistem Azure Cosmos DB. Ini diperlukan, karena sistem sebelumnya dirancang tidak dengan tata kelola sumber daya atau dengan skala di mana Azure Cosmos DB perlu beroperasi, atau untuk memberikan kemampuan (misalnya, konsistensi keusangan terikat) dan SLA yang ketat dan komprehensif yang diberikan Azure Cosmos DB kepada pelanggannya.

Ingat bahwa set partisi didistribusikan di beberapa wilayah dan mengikuti protokol replikasi Azure Cosmos DB s (tulis multi-wilayah) untuk mereplikasi data di antara partisi fisik yang terdiri dari set partisi tertentu. Setiap partisi fisik (dari partition-set) menerima tulisan dan melayani bacaan biasanya kepada klien yang lokal di wilayah tersebut. Tulisan yang diterima oleh partisi fisik dalam suatu wilayah diterapkan secara lama dan sangat tersedia dalam partisi fisik sebelum diakui kepada klien. Ini adalah tulisan tentatif dan disebarkan ke partisi fisik lainnya dalam partition-set menggunakan saluran anti-entropi. Klien dapat meminta penulisan tentatif atau berkomitmen dengan melewati header permintaan. Propagasi anti-entropi (termasuk frekuensi propagasi) bersifat dinamis, berdasarkan topologi partition-set, kedekatan regional partisi fisik, dan tingkat konsistensi yang dikonfigurasi. Dalam set partisi, Azure Cosmos DB mengikuti skema penerapan utama dengan partisi arbiter yang dipilih secara dinamis. Pemilihan penengah bersifat dinamis dan merupakan bagian integral dari konfigurasi ulang partition-set berdasarkan topologi overlay. Tulisan yang diterapkan (termasuk pembaruan multi-baris/batch) dijamin akan diurutkan.

Kami menggunakan jam vektor berkode (berisi ID wilayah dan jam logis yang sesuai dengan setiap tingkat konsensus pada replica-set dan partition-set) untuk pelacakan kausalitas dan vektor versi untuk mendeteksi dan menyelesaikan konflik pembaruan. Topologi dan algoritma pemilihan rekan dirancang untuk memastikan penyimpanannya tetap dan minimal dan minim overhead jaringan vektor versi. Algoritma menjamin properti konvergensi yang ketat.

Untuk database Azure Cosmos DB yang dikonfigurasi dengan beberapa wilayah tulis, sistem menawarkan sejumlah kebijakan resolusi konflik otomatis yang fleksibel bagi pengembang untuk dipilih, termasuk:

  • Last-Write-Wins (LWW), yang, secara default, menggunakan properti tanda waktu yang ditentukan sistem (berdasarkan protokol jam sinkronisasi waktu). Azure Cosmos DB juga memungkinkan Anda menentukan properti numerik kustom lainnya yang akan digunakan untuk resolusi konflik.
  • Kebijakan penyelesaian konflik yang ditentukan aplikasi (Kustom) (dinyatakan melalui prosedur penggabungan), yang dirancang untuk rekonsiliasi konflik semantik yang ditentukan aplikasi. Prosedur ini dipanggil setelah mendeteksi konflik tulis-tulis di bawah naungan transaksi database sisi server. Sistem menyediakan hanya satu jaminan untuk pelaksanaan prosedur penggabungan sebagai bagian dari protokol komitmen. Ada beberapa sampel resolusi konflik yang tersedia untuk Anda mainkan.

Model Konsistensi

Baik Anda mengonfigurasi database Azure Cosmos DB dengan satu atau beberapa wilayah tulis, Anda dapat memilih dari lima model konsistensi yang ditentukan dengan baik. Dengan banyaknya wilayah tulis, berikut ini adalah beberapa aspek penting dari tingkat konsistensi:

Konsistensi kebasian terikat menjamin bahwa semua bacaan akan berada dalam awalan K atau T detik dari tulisan terbaru di salah satu wilayah. Selain itu, bacaan dengan konsistensi kebasian terikat dijamin monoton dan dengan jaminan awalan yang konsisten. Protokol anti-entropi beroperasi dengan cara yang terbatas pada tarif dan memastikan bahwa awalan tidak menumpuk dan tekanan balik pada tulisan tidak harus diterapkan. Konsistensi sesi menjamin bacaan monoton, penulisan monoton, baca tulisan Anda sendiri, tulis setelah baca, dan jaminan awalan konsisten, di seluruh dunia. Untuk database yang dikonfigurasi dengan konsistensi kuat, manfaat (latensi tulis rendah, ketersediaan tulis tinggi) dari beberapa wilayah tulis tidak berlaku, karena replikasinya sinkron di seluruh wilayah.

Semantik dari lima model konsistensi di Azure Cosmos DB dijelaskan di sini, dan dijelaskan secara matematis menggunakan spesifikasi TLA+ tingkat tinggi di sini.

Langkah berikutnya

Selanjutnya pelajari cara mengonfigurasi distribusi global dengan menggunakan artikel berikut: