Bagikan melalui

Merancang aplikasi tangguh dengan SDK Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: NoSQL

Saat membuat aplikasi klien yang berinteraksi dengan Azure Cosmos DB melalui salah satu SDK, penting untuk memahami beberapa dasar-dasar utama. Artikel ini adalah panduan desain untuk membantu Anda memahami dasar-dasar ini dan merancang aplikasi yang tangguh.

Gambaran Umum

Untuk gambaran umum video tentang konsep yang dibahas dalam artikel ini, lihat:

Mode konektivitas

SDK Azure Cosmos DB dapat terhubung ke layanan dalam dua mode konektivitas. SDK .NET dan Java dapat terhubung ke layanan dalam mode Gateway dan Direct, sementara yang lain hanya dapat terhubung dalam mode Gateway. Mode gateway menggunakan protokol HTTP dan mode Langsung biasanya menggunakan protokol TCP.

Mode gateway selalu digunakan untuk mengambil metadata seperti akun, kontainer, dan informasi perutean terlepas dari mode mana yang dikonfigurasikan SDK untuk digunakan. Informasi ini disimpan dalam cache di memori dan digunakan untuk terhubung ke replika layanan.

Singkatnya, untuk SDK dalam mode Gateway, Anda dapat mengharapkan lalu lintas HTTP, sedangkan untuk SDK dalam mode Langsung, Anda dapat mengharapkan kombinasi lalu lintas HTTP dan TCP dalam keadaan yang berbeda (seperti inisialisasi, atau pengambilan metadata, atau informasi perutean).

Instans dan koneksi klien

Terlepas dari mode konektivitas, sangat penting untuk mempertahankan instans Singleton dari klien SDK per akun per aplikasi. Koneksi, baik HTTP dan TCP, dicakupkan ke instans klien. Sebagian besar lingkungan komputasi memiliki batasan dalam hal jumlah koneksi yang dapat dibuka pada saat yang sama dan ketika batas ini tercapai, konektivitas akan terpengaruh.

Aplikasi terdistribusi dan jaringan

Saat Anda mendesain aplikasi terdistribusi, ada tiga komponen utama:

  • Aplikasi Anda dan lingkungan tempat aplikasi itu berjalan.
  • Jaringan, yang mencakup komponen apa pun antara aplikasi Anda dan titik akhir layanan Azure Cosmos DB.
  • Titik akhir layanan Azure Cosmos DB.

Ketika terjadi kegagalan, mereka sering jatuh ke dalam salah satu dari tiga area ini, dan penting untuk dipahami bahwa karena sifat sistem yang terdistribusi, tidak praktis untuk mengharapkan ketersediaan 100% untuk salah satu komponen ini.

Azure Cosmos DB memiliki set SLA ketersediaan yang komprehensif, tetapi tidak ada yang 100%. Komponen jaringan yang menghubungkan aplikasi Anda ke titik akhir layanan dapat mengalami masalah perangkat keras sementara dan kehilangan paket. Bahkan lingkungan komputasi tempat aplikasi Anda berjalan dapat memiliki lonjakan CPU yang memengaruhi operasi. Kondisi kegagalan ini dapat memengaruhi pengoperasian SDK dan biasanya muncul sebagai kesalahan dengan kode tertentu.

Aplikasi Anda harus tahan terhadap tingkat tertentu potensi kegagalan di seluruh komponen ini dengan menerapkan kebijakan coba lagi atas tanggapan yang diberikan oleh SDK.

Haruskah aplikasi saya mencoba lagi jika ada kesalahan?

Jawaban singkatnya adalah ya. Namun tidak semua kesalahan masuk akal untuk dicoba lagi, beberapa kesalahan atau kode status tidak bersifat sementara. Tabel di bawah ini menjelaskannya secara rinci:

Kode status Harus menambahkan coba lagi SDK coba lagi Deskripsi
400 Tidak Tidak Permintaan buruk
401 Tidak Tidak Tidak berwenang
403 Opsional No Terlarang
404 Tidak Tidak Sumber daya tidak ditemukan
408 Ya Ya Waktu permintaan berakhir
409 Tidak Tidak Kegagalan konflik adalah ketika identitas (ID dan kunci partisi) yang disediakan untuk sumber daya pada operasi tulis telah diambil oleh sumber daya yang ada atau ketika batasan kunci unik telah dilanggar.
410 Ya Ya Pengecualian yang hilang (kegagalan sementara yang seharusnya tidak melanggar SLA)
412 Tidak Tidak Kegagalan prakondisi adalah tempat operasi menentukan eTag yang berbeda dari versi yang tersedia di server. Ini adalah kesalahan konkurensi optimis. Coba lagi permintaan setelah membaca versi terbaru sumber daya dan memperbarui eTag pada permintaan.
413 Tidak Tidak Entitas Permintaan Terlalu Besar
429 Ya Ya Aman untuk mencoba lagi pada 429. Tinjau panduan untuk memecahkan masalah HTTP 429.
449 Ya Ya Kesalahan sementara yang hanya terjadi pada operasi tulis, dan aman untuk mencoba kembali. Ini dapat menunjuk ke masalah desain di mana terlalu banyak operasi bersamaan mencoba memperbarui objek yang sama di Azure Cosmos DB.
500 Tidak Tidak Operasi gagal karena kesalahan layanan yang tak terduga. Hubungi dukungan dengan mengisi Masalah dukungan Azure.
503 Ya Ya Layanan tidak tersedia

Pada tabel di atas, semua kode status yang ditandai dengan Ya pada kolom kedua harus memiliki cakupan percobaan ulang di aplikasi Anda.

HTTP 403

Azure Cosmos DB SDK tidak mencoba lagi pada kegagalan HTTP 403 secara umum, tetapi ada kesalahan tertentu yang terkait dengan HTTP 403 yang mungkin akan ditanggapi oleh aplikasi Anda. Misalnya, jika Anda menerima kesalahan yang menunjukkan bahwa Kunci Partisi penuh, Anda mungkin memutuskan untuk mengubah kunci partisi dokumen yang Anda coba tulis berdasarkan beberapa aturan bisnis.

HTTP 429

SDK Azure Cosmos DB akan mencoba lagi kesalahan HTTP 429 secara default mengikuti konfigurasi klien dan menghormati header x-ms-retry-after-ms respons layanan, dengan menunggu waktu yang ditentukan dan mencoba lagi setelahnya.

Ketika percobaan ulang SDK terlampaui, kesalahan dikembalikan ke aplikasi Anda. Idealnya, memeriksa header x-ms-retry-after-ms dalam respons dapat digunakan sebagai petunjuk untuk memutuskan berapa lama waktu tunggu sebelum mencoba mengajukan permintaan kembali. Alternatif lain adalah algoritme back-off eksponensial atau mengonfigurasi klien untuk memperpanjang percobaan ulang pada HTTP 429.

HTTP 449

SDK Azure Cosmos DB akan mencoba lagi pada HTTP 449 dengan back-off tambahan selama periode waktu tertentu untuk mengakomodasi sebagian besar skenario.

Ketika percobaan ulang SDK otomatis terlampaui, kesalahan dikembalikan ke aplikasi Anda. Kesalahan HTTP 449 dapat dicoba kembali dengan aman. Karena sifat operasi tulis yang sangat konkuren, lebih baik memiliki algoritme back-off acak untuk menghindari pengulangan tingkat konkurensi yang sama setelah interval tetap.

Batas waktu jaringan dan kegagalan konektivitas adalah salah satu kesalahan yang paling umum. SDK Azure Cosmos DB sendiri tangguh dan akan mencoba kembali batas waktu dan masalah konektivitas di seluruh protokol HTTP dan TCP jika percobaan ulang dimungkinkan:

  • Untuk operasi baca, SDK akan mencoba kembali setiap batas waktu atau kesalahan terkait konektivitas.
  • Untuk operasi tulis, SDK tidak akan mencoba lagi karena operasi ini tidak idempoten. Ketika ada batas waktu menunggu respons, tidak mungkin untuk mengetahui apakah permintaan mencapai layanan.

Jika akun memiliki beberapa wilayah yang tersedia, SDK juga akan mencoba coba lagi lintas wilayah.

Karena sifat batas waktu dan kegagalan konektivitas, ini mungkin tidak muncul dalam metrik akun Anda, karena hanya mencakup kegagalan yang terjadi di sisi layanan.

Sebaiknya aplikasi memiliki kebijakan percobaan kembali untuk skenario ini dan mempertimbangkan cara mengatasi waktu tunggu penulisan. Misalnya, percobaan membuat batas waktu dapat menghasilkan HTTP 409 (Konflik) jika permintaan sebelumnya mencapai layanan, tetapi akan berhasil jika tidak mencapainya.

Detail implementasi khusus bahasa

Untuk detail implementasi lebih lanjut mengenai bahasa, lihat:

Apakah percobaan ulang memengaruhi latensi saya?

Dari perspektif klien, percobaan ulang apa pun akan memengaruhi latensi operasi ujung ke ujung. Ketika latensi P99 aplikasi Anda terpengaruh, penting untuk memahami percobaan ulang yang terjadi dan cara mengatasinya.

SDK Azure Cosmos DB memberikan informasi mendetail dalam log dan diagnostiknya yang dapat membantu mengidentifikasi percobaan ulang mana yang sedang berlangsung. Untuk informasi selengkapnya, lihat cara mengumpulkan diagnostik SDK .NET dan cara mengumpulkan diagnostik SDK Java.

Bagaimana cara mengurangi latensi coba lagi?

Tergantung pada keadaannya, dalam kebanyakan kasus SDK akan merutekan permintaan ke wilayah lokal, wilayah tulis (dalam skenario penulisan satu wilayah) atau wilayah pertama di daftar wilayah pilihan. Prioritas ini meminimalkan latensi dalam skenario yang sehat dengan terutama menyambungkan ke pusat data terdekat atau paling optimal.

Namun, prioritas ini juga berarti bahwa permintaan yang akan mengakibatkan kegagalan akan selalu dicoba di satu wilayah tertentu terlebih dahulu untuk skenario kesalahan tertentu. Jika failover ke wilayah lain lebih disukai dalam skenario tersebut, ini biasanya ditangani pada lapisan infrastruktur (traffic manager) daripada di tingkat SDK. Penyiapan dan konfigurasi infrastruktur yang tepat dapat memastikan bahwa lalu lintas dialihkan secara efisien selama pemadaman regional, sehingga mengurangi latensi yang dapat disertakan dengan percobaan kembali lintas wilayah dalam skenario pemadaman. Untuk informasi lebih rinci tentang menyiapkan failover tingkat infrastruktur, Anda dapat merujuk ke dokumentasi Azure Traffic Manager. Beberapa SDK mendukung penerapan strategi failover serupa langsung di tingkat SDK. Misalnya, lihat ketersediaan tinggi untuk Java SDK.

Bagaimana dengan pemadaman regional?

SDK Azure Cosmos DB mencakup ketersediaan regional dan dapat melakukan percobaan ulang di wilayah akun lain. Lihat artikel skenario dan konfigurasi coba lagi lingkungan multiregional untuk memahami skenario mana yang melibatkan wilayah lain.

Kapan harus menghubungi dukungan pelanggan

Sebelum menghubungi dukungan pelanggan, lakukan langkah-langkah berikut:

  • Apa dampak yang diukur dalam volume operasi yang terpengaruh dibandingkan dengan operasi yang berhasil? Apakah itu ada dalam SLA layanan?
  • Apakah latensi P99 terpengaruh?
  • Apakah kegagalan terkait dengan kode kesalahan yang harus dicoba kembali oleh aplikasi saya dan apakah aplikasi mencakup percobaan ulang tersebut?
  • Apakah kegagalan memengaruhi semua instans aplikasi Anda atau hanya sebagian? Ketika masalah direduksi menjadi subset instans, biasanya masalah itu terkait dengan instans tersebut.
  • Sudahkah Anda membaca dokumen pemecahan masalah dalam tabel di atas untuk mengesampingkan masalah pada lingkungan aplikasi?

Jika semua instans aplikasi terpengaruh, atau persentase operasi yang terpengaruh berada di luar SLA layanan, atau memengaruhi SLA dan P99 aplikasi Anda sendiri, hubungi dukungan pelanggan.

Langkah berikutnya