Praktik terbaik penanganan error dan latensi permintaan

Halaman ini menjelaskan praktik terbaik untuk mengoptimalkan latensi permintaan dan menangani error di Cloud Healthcare API. Terapkan praktik ini saat Anda merencanakan dan mendesain arsitektur sistem.

Google menyediakan perjanjian tingkat layanan (SLA) yang menentukan waktu beroperasi yang diharapkan dari layanan Cloud Healthcare API dan cara klien menangani error. Untuk mengetahui informasi selengkapnya, lihat Perjanjian Tingkat Layanan (SLA) Cloud Healthcare.

Menerapkan logika percobaan ulang dan waktu tunggu

Untuk menangani penundaan dan error yang disebabkan oleh permintaan yang gagal, terapkan logika percobaan ulang dan waktu tunggu yang sesuai. Saat menyetel durasi waktu tunggu, berikan waktu yang cukup untuk melakukan hal berikut:

• Biarkan Cloud Healthcare API memproses permintaan.
• Tentukan apakah error berasal dari layanan atau klien.

Anda dapat mencoba kembali beberapa error, tetapi error lainnya tidak dapat dicoba kembali dan tetap ada di beberapa percobaan ulang. Misalnya, jika data permintaan diformat dengan tidak benar, server akan merespons dengan kode status 400 Bad Request. Permintaan tidak akan berhasil hingga Anda memperbaiki data.

Untuk menangani situasi ini, Anda perlu merencanakan status error akhir.

Untuk mengetahui informasi selengkapnya tentang logika percobaan ulang dan waktu tunggu, lihat Mencoba lagi permintaan yang gagal.

Menangani error di beberapa lapisan

Saat middleware berinteraksi dengan Cloud Healthcare API, terapkan logika percobaan ulang dan waktu tunggu di klien dan middleware. Jika klien mengalami error setelah batas percobaan ulang, Anda harus dapat mengidentifikasi apakah error terjadi di klien, middleware, atau layanan Cloud Healthcare API yang mendasarinya. Hal ini sangat penting saat merencanakan status error akhir.

Pertimbangkan skenario berikut:

1. Middleware menerima error 500 Internal Server Error dari Cloud Healthcare API saat mengirim permintaan.
2. Lapisan middleware mencoba ulang permintaan lima kali lagi, mencapai batasnya, lalu berhenti mencoba ulang.
3. Klien menerima error 500 Internal Server Error akhir.

Penting untuk dipahami bahwa error tersebut berasal dari Cloud Healthcare API, bukan middleware. Untuk menyederhanakan proses penelusuran bug, berikan informasi ini dalam error yang ditampilkan kepada klien.

Diagram berikut menunjukkan skenario saat proxy middleware menerima error 500 Internal Server Error saat meneruskan permintaan dari klien ke Cloud Healthcare API. Klien dan proxy menerapkan penanganan error dan percobaan ulang.

Gambar 1. Lapisan tempat Anda perlu menerapkan logika percobaan ulang dan waktu tunggu adalah Client dan Proxy.

Gambar 1 menunjukkan langkah-langkah berikut:

1. Klien mengirimkan permintaan yang valid ke Cloud Healthcare API melalui proxy middleware.
2. Proxy meneruskan permintaan ke Cloud Healthcare API.
3. Cloud Healthcare API menampilkan error 500 Internal Server Error ke proxy. Proxy mencoba ulang permintaan lima kali lagi hingga batas percobaan ulangnya tercapai.

4. Proxy menampilkan status error akhir, 500 Internal Server Error, kepada klien.

   Dengan menggunakan rekomendasi yang ditampilkan sebelumnya, Anda dapat men-debug status error akhir dengan membuat proxy menampilkan error berikut kepada klien:

   Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

   Tambahkan informasi lainnya tentang error yang ditampilkan dari Cloud Healthcare API.

Terkadang, klien atau proxy menerima error 500 Internal Server Error yang melampaui batas percobaan ulang dan tidak dapat mencoba lagi. Dalam hal ini, intervensi manusia mungkin diperlukan untuk mendiagnosis apakah error berasal dari proxy atau Cloud Healthcare API.

Memilih error yang akan dicoba ulang

Bergantung pada arsitektur sistem, Anda dapat mencoba lagi kesalahan tertentu dan mengabaikan kesalahan lainnya. Berikut adalah daftar kode error Cloud Healthcare API yang dapat dicoba lagi:

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Error ini biasanya tidak terjadi dengan frekuensi yang sama, dan beberapa error mungkin tidak pernah terjadi.

Efek arsitektur sistem

Arsitektur sistem Anda memengaruhi cara dan waktu Anda mencoba ulang error.

Misalnya, dalam arsitektur klien-ke-server langsung, klien yang menerima error 401 UNAUTHENTICATED dari Cloud Healthcare API dapat melakukan autentikasi ulang dan mencoba lagi permintaannya.

Misalkan sistem memiliki lapisan middleware antara klien dan Cloud Healthcare API. Jika klien diautentikasi dengan benar dan token autentikasi yang sudah habis masa berlakunya menyebabkan masalah, maka middleware harus memperbarui token dan mencoba lagi permintaan.

Setelah menganalisis status error akhir, Anda dapat menyesuaikan error yang dicoba ulang oleh klien berdasarkan temuan Anda.

Merencanakan status error akhir

Bahkan setelah menerapkan logika percobaan ulang dan waktu tunggu, klien atau middleware mungkin menerima error hingga percobaan ulangnya habis. Error terakhir yang ditampilkan sebelum percobaan ulang dan waktu tunggu habis adalah status error akhir. Anda mungkin mengalami status error akhir untuk error konsistensi data.

Terkadang, status error akhir memerlukan intervensi manual. Coba terapkan solusi untuk mengatasi status error akhir permintaan. Jika tidak, catat status error akhir sehingga manusia dapat meninjaunya.

Pertimbangkan hal berikut saat merencanakan cara menangani status error akhir:

• Apakah ada dependensi pemrosesan yang perlu dihentikan jika transaksi atau kumpulan FHIR tidak dapat diselesaikan dengan berhasil.
• Jika banyak instance virtual machine (VM) mulai gagal secara permanen, klien harus melaporkan permintaan yang gagal. Setelah masalah diperbaiki, klien harus mencoba lagi permintaan.
• Sistem pemantauan, sistem pemberitahuan, dan tujuan tingkat layanan (SLO) diperlukan untuk memastikan stabilitas sistem Anda. Lihat Menguji dan memantau untuk mengetahui informasi selengkapnya.

Merencanakan peningkatan latensi

Cloud Healthcare API adalah layanan yang skalabel dan berperforma tinggi, tetapi latensi permintaan masih dapat bervariasi karena alasan berikut:

• Perbedaan kecil antara permintaan, meskipun tampaknya tidak signifikan, dapat menyebabkan waktu pemrosesan tambahan.
• Permintaan serupa mungkin memiliki latensi yang berbeda. Misalnya, dua permintaan serupa yang menambahkan rekaman ke penyimpanan data mungkin memiliki latensi yang berbeda jika salah satunya melampaui nilai minimum yang memicu tugas tambahan, seperti mengalokasikan lebih banyak penyimpanan.
• Cloud Healthcare API menangani banyak permintaan secara serentak. Waktu saat klien mengirim permintaan, yang diukur dalam fraksi detik, mungkin bertepatan dengan waktu saat Cloud Healthcare API mengalami beban yang lebih berat dari biasanya.
• Jika resource fisik Cloud Healthcare API, seperti disk, menangani banyak permintaan, resource tersebut harus menyelesaikan tugas yang diantrekan sebelum menangani permintaan lain.
• Terkadang, Cloud Healthcare API mencoba kembali error di sisi server, yang dapat meningkatkan latensi untuk klien.
• Mungkin ada beberapa salinan data di pusat data yang berbeda di lokasi regional atau multi-regional. Jika permintaan Anda dirutekan di beberapa pusat data, baik pada permintaan asli maupun pada percobaan ulang, latensi mungkin meningkat.

Merencanakan menggunakan latensi persentil

Anda dapat merencanakan peningkatan latensi dengan menganalisis latensi persentil permintaan Anda. Contoh berikut menjelaskan latensi persentil ke-50 dan latensi persentil ke-99:

• Latensi persentil ke-50 adalah latensi maksimum, dalam detik, untuk 50% permintaan tercepat. Misalnya, jika latensi persentil ke-50 adalah 0,5 detik, maka Cloud Healthcare API memproses 50% permintaan dalam waktu 0,5 detik. Latensi persentil ke-50 juga disebut "latensi median".
• Latensi persentil ke-99 adalah latensi maksimum, dalam detik, untuk 99% permintaan tercepat. Misalnya, jika latensi persentil ke-99 adalah dua detik, maka Cloud Healthcare API memproses 99% permintaan dalam waktu dua detik.

Jika Anda menganalisis latensi persentil selama interval saat Cloud Healthcare API hanya memproses beberapa permintaan, latensi persentil mungkin tidak berguna atau menunjukkan performa keseluruhan karena permintaan pencilan dapat memiliki pengaruh yang besar.

Misalnya, proses di Cloud Healthcare API memproses 100 permintaan dalam 100 menit. Latensi persentil ke-99 untuk 100 menit akan didasarkan pada satu permintaan paling lambat. Pengukuran latensi menggunakan satu permintaan tidak cukup untuk memahami apakah ada masalah performa.

Mengumpulkan sampel permintaan yang lebih besar selama jangka waktu yang lebih lama, seperti 24 jam, dapat memberikan lebih banyak insight tentang perilaku keseluruhan sistem Anda. Anda dapat menggunakan contoh ini untuk menentukan cara sistem Anda merespons traffic berat.