Penanganan Kesalahan Sementara (Membangun Real-World Cloud Apps dengan Azure)

  • Artikel
  • 6 menit untuk membaca

oleh Rick Anderson, Tom Dykstra

Unduh Fix It Project atau Unduh E-book

E-book Building Real World Cloud Apps dengan Azure didasarkan pada presentasi yang dikembangkan oleh Scott Guthrie. Ini menjelaskan 13 pola dan praktik yang dapat membantu Anda berhasil mengembangkan aplikasi web untuk cloud. Untuk informasi tentang e-book, lihat bab pertama.

Saat Anda merancang aplikasi cloud dunia nyata, salah satu hal yang harus Anda pikirkan adalah cara menangani gangguan layanan sementara. Masalah ini sangat penting dalam aplikasi cloud karena Anda sangat bergantung pada koneksi jaringan dan layanan eksternal. Anda bisa sering mendapatkan sedikit gangguan yang biasanya menyembuhkan diri sendiri, dan jika Anda tidak siap untuk menanganinya dengan cerdas, mereka akan menghasilkan pengalaman buruk bagi pelanggan Anda.

Penyebab kegagalan sementara

Di lingkungan cloud, Anda akan menemukan bahwa koneksi database yang gagal dan terputus terjadi secara berkala. Itu sebagian karena Anda akan melalui lebih banyak penyeimbang beban dibandingkan dengan lingkungan lokal di mana server web dan server database Anda memiliki koneksi fisik langsung. Juga, kadang-kadang ketika Anda bergantung pada layanan multi-penyewa, Anda akan melihat panggilan ke layanan menjadi lebih lambat atau waktu habis karena orang lain yang menggunakan layanan sangat mencapainya. Dalam kasus lain Anda mungkin pengguna yang terlalu sering mencapai layanan, dan layanan sengaja membatasi Anda - menolak koneksi - untuk mencegah Anda memengaruhi penyewa layanan lain.

Gunakan logika coba lagi/mundur cerdas untuk mengurangi efek kegagalan sementara

Alih-alih melempar pengecualian dan menampilkan halaman yang tidak tersedia atau kesalahan kepada pelanggan Anda, Anda dapat mengenali kesalahan yang biasanya sementara, dan secara otomatis mencoba kembali operasi yang mengakibatkan kesalahan, dengan harapan bahwa sebelum lama Anda akan berhasil. Sebagian besar waktu operasi akan berhasil pada percobaan kedua, dan Anda akan pulih dari kesalahan tanpa pelanggan mengetahui bahwa ada masalah.

Ada beberapa cara untuk menerapkan logika coba lagi cerdas.

  • Grup Praktik Pola & Microsoft memiliki Blok Aplikasi Penanganan Kesalahan Sementara yang melakukan semuanya untuk Anda jika Anda menggunakan ADO.NET untuk akses SQL Database (bukan melalui Kerangka Kerja Entitas). Anda hanya menetapkan kebijakan untuk percobaan ulang - berapa kali untuk mencoba kembali kueri atau perintah dan berapa lama menunggu antara percobaan - dan membungkus kode SQL Anda dalam blok penggunaan .

    public void HandleTransients()
{
    var connStr = "some database";
    var _policy = RetryPolicy.Create < SqlAzureTransientErrorDetectionStrategy(
        retryCount: 3,
        retryInterval: TimeSpan.FromSeconds(5));

    using (var conn = new ReliableSqlConnection(connStr, _policy))
    {
        // Do SQL stuff here.
    }
}

    TFH juga mendukung Azure In-Role Cache dan Service Bus.

  • Saat Anda menggunakan Kerangka Kerja Entitas, Anda biasanya tidak bekerja langsung dengan koneksi SQL, sehingga Anda tidak dapat menggunakan paket Pola dan Praktik ini, tetapi Entity Framework 6 membangun logika coba lagi semacam ini langsung ke dalam kerangka kerja. Dengan cara yang sama Anda menentukan strategi coba lagi, lalu EF menggunakan strategi tersebut setiap kali mengakses database.

    Untuk menggunakan fitur ini di aplikasi Fix It, yang harus kita lakukan adalah menambahkan kelas yang berasal dari DbConfiguration dan mengaktifkan logika coba lagi.

    // EF follows a Code based Configuration model and will look for a class that
// derives from DbConfiguration for executing any Connection Resiliency strategies
public class EFConfiguration : DbConfiguration
{
    public EFConfiguration()
    {
        AddExecutionStrategy(() => new SqlAzureExecutionStrategy());
    }
}

    Untuk pengecualian SQL Database yang diidentifikasi kerangka kerja sebagai kesalahan sementara, kode yang ditampilkan menginstruksikan EF untuk mencoba kembali operasi hingga 3 kali, dengan penundaan back-off eksponensial antara percobaan ulang, dan penundaan maksimum 5 detik. Back-off eksponensial berarti bahwa setelah setiap kali gagal, percobaan ulang akan menunggu untuk jangka waktu yang lebih lama sebelum mencoba lagi. Jika tiga percobaan berturut-turut gagal, itu akan melemparkan pengecualian. Bagian berikut tentang pemutus sirkuit menjelaskan mengapa Anda ingin back-off eksponensial dan sejumlah percobaan ulang yang terbatas.

    Anda dapat mengalami masalah serupa saat menggunakan layanan Azure Storage, seperti yang dilakukan aplikasi Fix It untuk Blob, dan API klien penyimpanan .NET sudah menerapkan jenis logika yang sama. Anda cukup menentukan kebijakan coba lagi, atau Anda bahkan tidak perlu melakukannya jika Anda puas dengan pengaturan default.

Pemutus

Ada beberapa alasan mengapa Anda tidak ingin mencoba kembali terlalu banyak kali selama periode yang terlalu lama:

  • Terlalu banyak pengguna yang terus-menerus mencoba kembali permintaan yang gagal dapat menurunkan pengalaman pengguna lain. Jika jutaan orang semuanya membuat permintaan coba lagi berulang, Anda dapat mengikat antrean pengiriman IIS dan mencegah aplikasi Anda melayani permintaan yang sebaliknya dapat ditangani dengan sukses.
  • Jika semua orang mencoba kembali karena kegagalan layanan, mungkin ada begitu banyak permintaan yang diantrekan sehingga layanan terendam banjir ketika mulai pulih.
  • Jika kesalahan disebabkan oleh pembatasan dan ada jendela waktu yang digunakan layanan untuk pembatasan, percobaan ulang yang berkelanjutan dapat memindahkan jendela tersebut keluar dan menyebabkan pembatasan berlanjut.
  • Anda mungkin meminta pengguna yang menunggu halaman web untuk dirender. Membuat orang menunggu terlalu lama mungkin lebih mengganggu yang relatif cepat menyarankan mereka untuk mencoba lagi nanti.

Back-off eksponensial mengatasi beberapa masalah ini dengan membatasi frekuensi percobaan ulang yang dapat didapatkan layanan dari aplikasi Anda. Tetapi Anda juga harus memiliki pemutus sirkuit: ini berarti bahwa pada ambang coba lagi tertentu aplikasi Anda berhenti mencoba kembali dan mengambil beberapa tindakan lain, seperti salah satu hal berikut:

  • Fallback kustom. Jika Anda tidak bisa mendapatkan harga saham dari Reuters, mungkin Anda bisa mendapatkannya dari Bloomberg; atau jika Anda tidak bisa mendapatkan data dari database, mungkin Anda bisa mendapatkannya dari cache.
  • Gagal diam. Jika apa yang Anda butuhkan dari layanan tidak semuanya atau tidak sama sekali untuk aplikasi Anda, kembalikan saja null saat Anda tidak bisa mendapatkan data. Jika Anda menampilkan tugas Fix It dan blob service tidak merespons, Anda dapat menampilkan detail tugas tanpa gambar.
  • Gagal dengan cepat. Kesalahan pengguna untuk menghindari membanjiri layanan dengan permintaan coba lagi yang dapat menyebabkan gangguan layanan bagi pengguna lain atau memperluas jendela pembatasan. Anda dapat menampilkan pesan "coba lagi nanti" yang ramah.

Tidak ada kebijakan coba lagi satu ukuran untuk semua. Anda dapat mencoba kembali lebih banyak kali dan menunggu lebih lama dalam proses pekerja latar belakang asinkron daripada yang Anda lakukan di aplikasi web sinkron di mana pengguna menunggu respons. Anda dapat menunggu lebih lama di antara percobaan ulang untuk layanan database relasional daripada yang Anda lakukan untuk layanan cache. Berikut adalah beberapa contoh kebijakan coba lagi yang direkomendasikan untuk memberi Anda gambaran tentang bagaimana angkanya mungkin bervariasi. ("Fast First" berarti tidak ada penundaan sebelum percobaan ulang pertama.

Sampel kebijakan coba lagi

Untuk panduan kebijakan coba lagi SQL Database, lihat Memecahkan masalah kesalahan sementara dan kesalahan koneksi ke SQL Database.

Ringkasan

Strategi coba lagi/back-off dapat membantu membuat kesalahan sementara tidak terlihat oleh pelanggan sebagian besar waktu, dan Microsoft menyediakan kerangka kerja yang dapat Anda gunakan untuk meminimalkan pekerjaan Anda menerapkan strategi apakah Anda menggunakan ADO.NET, Kerangka Kerja Entitas, atau layanan Azure Storage.

Di bab berikutnya, kita akan melihat cara meningkatkan performa dan keandalan dengan menggunakan penembolokan terdistribusi.

Sumber

Untuk informasi lebih lanjut, lihat sumber daya berikut ini:

Dokumentasi

Video

Sampel kode

SebelumnyaBerikutnya