Platform data untuk beban kerja misi penting di Azure

  • Artikel

Dalam arsitektur misi penting, status apa pun harus disimpan di luar komputasi sebanyak mungkin. Pilihan teknologi didasarkan pada karakteristik arsitektur utama ini:

Karakteristik Pertimbangan
Performa Berapa banyak komputasi yang diperlukan?
Latensi Apa dampak jarak antara pengguna dan penyimpanan data terhadap latensi? Apa tingkat konsistensi yang diinginkan dengan tradeoff pada latensi?
Daya respon Apakah penyimpanan data harus selalu tersedia?
Skalabilitas Apa skema partisinya?
Daya tahan Apakah data diperkirakan akan bertahan lama? Apa kebijakan penyimpanannya?
Ketahanan Jika terjadi kegagalan, apakah penyimpanan data dapat gagal secara otomatis? Langkah-langkah apa yang berlaku untuk mengurangi waktu failover?
Keamanan Apakah data dienkripsi? Dapatkah datastore dijangkau melalui jaringan publik?

Dalam arsitektur ini, ada dua penyimpanan data:

  • Database

    Menyimpan yang terkait dengan beban kerja. Disarankan agar semua status disimpan secara global dalam database yang dipisahkan dari stempel regional. Bangun redundansi dengan menyebarkan database di seluruh wilayah. Untuk beban kerja misi penting, menyinkronkan data di seluruh wilayah harus menjadi perhatian utama. Selain itu, jika terjadi kegagalan, permintaan tulis ke database harus tetap berfungsi.

    Replikasi data dalam konfigurasi aktif-aktif sangat disarankan. Aplikasi harus dapat langsung terhubung dengan wilayah lain. Semua instans harus dapat menangani permintaan baca dan tulis.

  • Broker pesan

    Satu-satunya layanan stateful di stempel regional adalah broker pesan, yang menyimpan permintaan untuk waktu yang singkat. Broker melayani kebutuhan akan penyanggaan dan olahpesan yang andal. Permintaan yang diproses dipertahankan dalam database global.

Untuk pertimbangan data lainnya, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Pertimbangan platform data.

Database

Arsitektur ini menggunakan Azure Cosmos DB untuk NoSQL. Opsi ini dipilih karena menyediakan fitur terbanyak yang diperlukan dalam desain ini:

  • Penulisan multi-wilayah

    Penulisan multi-wilayah diaktifkan dengan replika yang disebarkan ke setiap wilayah tempat stempel disebarkan. Setiap stempel dapat menulis secara lokal dan Azure Cosmos DB menangani replikasi dan sinkronisasi data antara stempel. Kemampuan ini secara signifikan menurunkan latensi untuk pengguna akhir aplikasi yang didistribusikan secara geografis. Implementasi referensi Azure Mission-Critical menggunakan teknologi multi-master untuk memberikan ketahanan dan ketersediaan maksimum.

    Redundansi zona juga diaktifkan dalam setiap wilayah yang direplikasi.

    Untuk detail tentang penulisan multi-wilayah, lihat Mengonfigurasi penulisan multi-wilayah di aplikasi Anda yang menggunakan Azure Cosmos DB.

  • Manajemen konflik

    Dengan kemampuan untuk melakukan penulisan di beberapa wilayah, kebutuhan untuk mengadopsi model manajemen konflik karena penulisan simultan dapat memperkenalkan konflik rekaman. Last Writer Wins adalah model default dan digunakan untuk desain Misi Kritis. Penulis terakhir, seperti yang didefinisikan oleh tanda waktu terkait dari rekaman memenangkan konflik. Azure Cosmos DB for NoSQL juga memungkinkan properti kustom ditentukan.

  • Pengoptimalan kueri

    Rekomendasi efisiensi kueri umum untuk kontainer baca-berat dengan jumlah partisi yang tinggi adalah menambahkan filter kesetaraan dengan itemID yang diidentifikasi. Tinjauan mendalam rekomendasi pengoptimalan kueri dapat ditemukan di Memecahkan masalah kueri saat menggunakan Azure Cosmos DB.

  • Fitur pencadangan

    Disarankan agar Anda menggunakan fitur cadangan asli Azure Cosmos DB untuk perlindungan data. Fitur pencadangan Azure Cosmos DB mendukung pencadangan online dan pemulihan data sesuai permintaan.

Catatan

Sebagian besar beban kerja bukan murni OLTP. Ada peningkatan permintaan untuk pelaporan real-time, seperti menjalankan laporan terhadap sistem operasional. Ini juga disebut sebagai HTAP (Hybrid Transactional and Analytical Processing). Azure Cosmos DB mendukung kemampuan ini melalui Azure Synapse Link untuk Azure Cosmos DB.

Model data untuk beban kerja

Model data harus dirancang singgah sehingga fitur yang ditawarkan oleh database relasional tradisional tidak diperlukan. Misalnya, kunci asing, skema baris/kolom yang ketat, tampilan, dan lainnya.

Beban kerja memiliki karakteristik akses data ini:

  • Pola baca:
    • Point reads - Mengambil satu rekaman. ID item dan kunci partisi langsung digunakan untuk pengoptimalan maksimum (1 RU per permintaan).
    • Baca daftar - Mendapatkan item katalog untuk ditampilkan dalam daftar. FeedIterator dengan batas jumlah hasil yang digunakan.
  • Pola tulis:
    • Penulisan kecil - Permintaan biasanya menyisipkan satu atau sejumlah kecil rekaman dalam transaksi.
  • Dirancang untuk menangani lalu lintas tinggi dari pengguna akhir dengan kemampuan untuk menskalakan untuk menangani permintaan lalu lintas dalam urutan jutaan pengguna.
  • Payload kecil atau ukuran himpunan data - biasanya dalam urutan KB.
  • Waktu respons rendah (dalam urutan milidetik).
  • Latensi rendah (dalam urutan milidetik).

Konfigurasi

Azure Cosmos DB dikonfigurasi sebagai berikut:

  • Tingkat konsistensi diatur ke konsistensi Sesi default karena merupakan tingkat yang paling banyak digunakan untuk satu wilayah dan aplikasi yang didistribusikan secara global. Konsistensi yang lebih lemah dengan throughput yang lebih tinggi tidak diperlukan karena sifat pemrosesan tulis yang asinkron dan tidak memerlukan latensi rendah pada penulisan database.

    Catatan

    Tingkat konsistensi Sesi menawarkan tradeoff yang wajar untuk latensi, ketersediaan, dan jaminan konsistensi untuk aplikasi khusus ini. Penting untuk dipahami bahwa Tingkat konsistensi yang kuat tidak tersedia untuk database tulis multi-master.

  • Kunci partisi diatur ke /id untuk semua koleksi. Keputusan ini didasarkan pada pola penggunaan, yang sebagian besar "menulis dokumen baru dengan GUID sebagai ID" dan "membaca berbagai dokumen menurut ID". Menyediakan kode aplikasi mempertahankan keunikan ID-nya, data baru didistribusikan secara merata ke dalam partisi oleh Azure Cosmos DB, memungkinkan skala tak terbatas.

  • Kebijakan pengindeksan dikonfigurasi pada koleksi untuk mengoptimalkan kueri. Untuk mengoptimalkan biaya dan performa RU, kebijakan pengindeksan kustom digunakan. Kebijakan ini hanya mengindeks properti yang digunakan dalam predikat kueri. Misalnya, aplikasi tidak menggunakan bidang teks komentar sebagai filter dalam kueri. Itu dikecualikan dari kebijakan pengindeksan kustom.

Berikut adalah contoh dari implementasi yang menunjukkan pengaturan kebijakan pengindeksan menggunakan Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Untuk informasi tentang koneksi dari aplikasi ke Azure Cosmos DB dalam arsitektur ini, lihat Pertimbangan platform aplikasi untuk beban kerja misi penting

Layanan Pesan

Sistem penting misi sering menggunakan layanan olahpesan untuk pemrosesan pesan atau peristiwa. Layanan ini mempromosikan konektor longgar dan bertindak sebagai buffer yang mengisolasi sistem terhadap lonjakan permintaan yang tidak terduga.

  • Azure Bus Layanan direkomendasikan untuk beban kerja berbasis pesan saat menangani pesan bernilai tinggi.
  • Azure Event Hubs direkomendasikan untuk sistem berbasis peristiwa yang memproses peristiwa atau telemetri dalam volume tinggi.

Berikut ini adalah pertimbangan desain dan rekomendasi untuk Azure Bus Layanan premium dan Azure Event Hubs dalam arsitektur misi penting.

Menangani beban

Sistem olahpesan harus dapat menangani throughput yang diperlukan (seperti dalam MB per detik). Pertimbangkan hal berikut:

  • Persyaratan non-fungsi (NFR) sistem harus menentukan ukuran pesan rata-rata dan jumlah puncak pesan/detik yang harus didukung setiap stempel. Informasi ini dapat digunakan untuk menghitung puncak MB/detik yang diperlukan per stempel.
  • Dampak failover harus dipertimbangkan saat menghitung puncak MB/detik yang diperlukan per stempel.
  • Untuk Azure Bus Layanan, NFR harus menentukan fitur Bus Layanan tingkat lanjut seperti sesi dan membatalkan duping pesan. Fitur-fitur ini akan memengaruhi throughput Bus Layanan.
  • Throughput Bus Layanan dengan fitur yang diperlukan harus dihitung melalui pengujian sebagai MB/detik per Unit Olahpesan (MU). Untuk informasi selengkapnya tentang topik ini, lihat Bus Layanan tingkat olahpesan premium dan standar.
  • Throughput Azure Event Hubs harus dihitung melalui pengujian sebagai MB/detik per unit throughput (TU) untuk tingkat standar atau unit pemrosesan (PU) untuk tingkat premium. Untuk informasi selengkapnya tentang topik ini, lihat Penskalaan dengan Azure Event Hubs.
  • Perhitungan di atas dapat digunakan untuk memvalidasi bahwa layanan olahpesan dapat menangani beban yang diperlukan per stempel, dan jumlah unit skala yang diperlukan untuk memenuhi beban tersebut.
  • Bagian operasi akan membahas penskalakan otomatis.

Setiap pesan harus diproses

Tingkat premium Azure Bus Layanan adalah solusi yang direkomendasikan untuk pesan bernilai tinggi yang pemrosesannya harus dijamin. Berikut ini adalah detail mengenai persyaratan ini saat menggunakan Azure Bus Layanan premium:

  • Untuk memastikan bahwa pesan ditransfer dengan benar dan diterima oleh broker, produsen pesan harus menggunakan salah satu klien API Bus Layanan yang didukung. API yang didukung hanya akan berhasil dikembalikan dari operasi pengiriman jika pesan disimpan pada antrean/topik.

  • Untuk memastikan pesan di bus diproses, Anda harus menggunakan mode terima PeekLock. Mode ini memungkinkan pemrosesan setidaknya sekali. Berikut ini menguraikan prosesnya:

    • Konsumen pesan menerima pesan untuk diproses.
    • Konsumen diberi kunci eksklusif pada pesan selama durasi waktu tertentu.
    • Jika konsumen berhasil memproses pesan, konsumen akan mengirimkan pengakuan kembali ke broker, dan pesan dihapus dari antrean.
    • Jika pengakuan tidak diterima oleh broker dalam periode waktu yang dialokasikan, atau handler secara eksplisit meninggalkan pesan, kunci eksklusif akan dilepaskan. Pesan kemudian tersedia bagi konsumen lain untuk memproses pesan.
    • Jika pesan tidak berhasil memproses beberapa kali yang dapat dikonfigurasi, atau handler meneruskan pesan ke antrean dead-letter.

  • Karena pesan berpotensi dapat diproses lebih dari satu kali, penangan pesan harus dibuat idempogen.

Pemrosesan pesan idempotensi

Dalam RFC 7231, Protokol Transfer Hypertext menyatakan, "A ... metode dianggap idempogen jika efek yang dimaksudkan pada server beberapa permintaan identik dengan metode tersebut sama dengan efek untuk satu permintaan tersebut."

Salah satu teknik umum membuat penanganan pesan idempoten adalah memeriksa penyimpanan persisten, seperti database, jika pesan telah diproses. Jika telah diproses, Anda tidak akan menjalankan logika untuk memprosesnya lagi.

  • Mungkin ada situasi di mana pemrosesan pesan mencakup operasi database, khususnya penyisipan rekaman baru dengan pengidentifikasi yang dihasilkan database. Pesan baru dapat dipancarkan ke broker, yang berisi pengidentifikasi tersebut. Karena tidak ada transaksi terdistribusi yang mencakup database dan broker pesan, mungkin ada sejumlah komplikasi yang dapat terjadi jika proses yang menjalankan kode terjadi gagal. Lihat contoh situasi berikut:
    • Kode yang memancarkan pesan mungkin berjalan sebelum transaksi database diterapkan, yaitu berapa banyak pengembang yang bekerja menggunakan pola Unit Kerja. Pesan tersebut dapat lolos, jika kegagalan terjadi antara memanggil broker dan meminta agar transaksi database dilakukan. Saat transaksi bergulir kembali, ID yang dihasilkan database tersebut juga dibatalkan, yang membuatnya tersedia untuk kode lain yang mungkin berjalan pada saat yang sama. Ini dapat menyebabkan penerima pesan yang lolos memproses entri database yang salah, yang merusak konsistensi dan kebenaran sistem Anda secara keseluruhan.
    • Jika pengembang menempatkan kode yang memancarkan pesan setelah transaksi database selesai, proses masih dapat gagal antara operasi ini (transaksi yang dilakukan - pesan dikirim). Ketika itu terjadi, pesan akan melalui pemrosesan lagi, tetapi kali ini klausul penjaga idempotensi akan melihat bahwa pesan telah diproses (berdasarkan data yang disimpan dalam database). Klausa akan melewati kode pemancaran pesan, percaya bahwa semuanya berhasil dilakukan terakhir kali. Sistem hilir, yang mengharapkan untuk menerima pemberitahuan tentang proses yang selesai, tidak menerima apa pun. Situasi ini kembali menghasilkan keadaan inkonsistensi secara keseluruhan.
  • Solusi untuk masalah di atas melibatkan penggunaan pola Kotak Keluar Transaksional, di mana pesan keluar disimpan ke samping, di penyimpanan transaksional yang sama dengan data bisnis. Pesan kemudian dikirimkan ke broker pesan, ketika pesan awal telah berhasil diproses.
  • Karena banyak pengembang tidak terbiasa dengan masalah ini atau solusinya, untuk menjamin bahwa teknik ini diterapkan secara konsisten dalam sistem misi penting, kami sarankan Anda memiliki fungsionalitas kotak keluar dan interaksi dengan broker pesan yang dibungkus dalam beberapa jenis pustaka. Semua pemrosesan kode dan pengiriman pesan yang signifikan secara transaksional harus menggunakan pustaka tersebut, daripada berinteraksi dengan broker pesan secara langsung.

Ketersediaan tinggi dan pemulihan bencana

Broker pesan harus tersedia bagi produsen untuk mengirim pesan dan konsumen untuk menerimanya. Berikut ini adalah detail mengenai persyaratan ini:

  • Untuk memastikan ketersediaan tertinggi dengan Bus Layanan, gunakan tingkat premium, yang memiliki dukungan untuk zona ketersediaan di wilayah pendukung. Dengan zona ketersediaan, pesan dan metadata direplikasi di tiga pusat data yang berbeda di wilayah yang sama.
  • Gunakan SDK Bus Layanan atau Azure Event Hubs yang didukung untuk mencoba kembali kegagalan baca atau tulis secara otomatis.
  • Pertimbangkan replikasi aktif-aktif atau pola replikasi pasif aktif untuk mengisolasi terhadap bencana regional.

Catatan

Pemulihan bencana geografis Azure Bus Layanan hanya mereplikasi metadata di seluruh wilayah. Fitur ini tidak mereplikasi pesan.

Pemantauan

Sistem olahpesan bertindak sebagai buffer antara produsen pesan dan konsumen. Ada jenis indikator utama yang harus Anda pantau dalam sistem misi penting yang memberikan wawasan berharga yang dijelaskan di bawah ini:

  • Pembatasan - Pembatasan menunjukkan bahwa sistem tidak memiliki sumber daya yang diperlukan untuk memproses permintaan. Baik Bus Layanan maupun Event Hubs mendukung pemantauan permintaan yang dibatasi. Anda harus memperingatkan indikator ini.
  • Kedalaman antrean - Kedalaman antrean yang berkembang dapat menunjukkan bahwa prosesor pesan tidak berfungsi atau tidak ada cukup prosesor untuk menangani beban saat ini. Kedalaman antrean dapat digunakan untuk menginformasikan logika penskalaan otomatis handler.
    • Untuk Bus Layanan, kedalaman antrean diekspos sebagai jumlah pesan
    • Untuk Azure Event Hubs, konsumen harus menghitung kedalaman antrean per partisi dan mendorong metrik ke perangkat lunak pemantauan Anda. Untuk setiap bacaan, konsumen mendapatkan nomor urut peristiwa saat ini, dan properti peristiwa dari peristiwa antrean terakhir. Konsumen dapat menghitung offset.
  • Antrean surat mati - Pesan dalam antrean surat mati mewakili pesan yang tidak dapat diproses. Pesan-pesan ini biasanya memerlukan intervensi manual. Pemberitahuan harus diatur pada antrean surat mati.
    • Bus Layanan memiliki antrean surat mati dan metrik DeadLetteredMessages.
    • Untuk Azure Event Hubs, fungsi ini harus berupa logika kustom yang dibangun ke dalam konsumen.
  • Penggunaan CPU/Memori - CPU dan memori harus dipantau untuk memastikan sistem olahpesan memiliki sumber daya yang cukup untuk memproses beban saat ini. Baik Bus Layanan premium dan Azure Event Hubs premium mengekspos CPU dan Penggunaan memori.
    • Unit olahpesan (MUs) digunakan dalam Bus Layanan untuk mengisolasi sumber daya seperti CPU dan memori untuk namespace. CPU dan memori yang naik di atas ambang batas dapat menunjukkan bahwa tidak ada cukup MUs yang dikonfigurasi, sementara berada di bawah ambang batas lain dapat menunjukkan bahwa ada terlalu banyak MUs yang dikonfigurasi. Indikator ini dapat digunakan untuk menskalakan MUs secara otomatis.
    • Tingkat premium Azure Event Hubs menggunakan unit pemrosesan (PUs) untuk mengisolasi sumber daya, sementara tingkat standar menggunakan unit throughput (TU). Tingkatan tersebut tidak memerlukan interaksi dengan CPU/Memori untuk melambungkan PUs atau TU secara otomatis.

Pemeriksaan kondisi

Kesehatan sistem olahpesan harus dipertimbangkan dalam pemeriksaan kesehatan untuk aplikasi misi penting. Pertimbangkan faktor berikut:

  • Sistem olahpesan bertindak sebagai buffer antara produsen pesan dan konsumen. Stempel dapat dilihat sehat jika produsen berhasil mengirim pesan ke broker dan jika konsumen berhasil memproses pesan dari broker.
  • Pemeriksaan kesehatan harus memastikan bahwa pesan dapat dikirim ke sistem pesan.

Langkah berikutnya

Sebarkan implementasi referensi untuk mendapatkan pemahaman penuh tentang sumber daya dan konfigurasinya yang digunakan dalam arsitektur ini.

Implementasi: Mission-Critical Online