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 dapat menangani error. Untuk mengetahui informasi selengkapnya, lihat Perjanjian Tingkat Layanan (SLA) Cloud Healthcare.

Mengimplementasikan 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 menetapkan durasi waktu tunggu, berikan waktu yang cukup untuk melakukan hal berikut:

• Izinkan 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 ulang dan tetap ada di seluruh beberapa percobaan ulang. Misalnya, jika data permintaan salah diformat, 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 debug, berikan informasi ini dalam error yang ditampilkan ke 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 Klien 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 akan mencoba ulang permintaan lima kali lagi hingga batas percobaan ulang tercapai.

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

   Dengan menggunakan rekomendasi yang ditampilkan sebelumnya, Anda dapat men-debug status error akhir dengan meminta proxy menampilkan error berikut ke 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 setelah batas percobaan ulang dan tidak dapat mencoba lagi. Dalam hal ini, manusia mungkin perlu melakukan intervensi untuk mendiagnosis apakah error berasal dari proxy atau Cloud Healthcare API.

Memilih error yang akan dicoba ulang

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

• 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 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 mengautentikasi 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 tidak berlaku menyebabkan masalah, maka middleware harus memuat ulang token dan mencoba lagi permintaan.

Setelah menganalisis status error akhir, Anda dapat menyesuaikan error yang dicoba ulang 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 manusia. Coba terapkan solusi untuk menyelesaikan status error akhir untuk permintaan. Jika tidak, catat status error akhir ke dalam log agar dapat ditinjau oleh manusia.

Pertimbangkan hal berikut saat merencanakan cara menangani status error akhir:

• Apakah ada dependensi pemrosesan yang perlu dihentikan jika transaksi atau paket FHIR tidak dapat diselesaikan dengan sukses.
• Jika banyak instance virtual machine (VM) mulai gagal secara permanen, klien harus melaporkan permintaan yang gagal. Setelah masalah diperbaiki, klien harus mencoba lagi permintaan.
• 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 data 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 pecahan 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 lainnya.
• Terkadang, Cloud Healthcare API mencoba ulang error di sisi server, yang dapat meningkatkan latensi untuk klien.
• Mungkin ada beberapa salinan data di berbagai pusat data di lokasi regional atau multi-regional. Jika permintaan Anda dirutekan ke beberapa pusat data, baik pada permintaan asli maupun pada percobaan ulang, mungkin akan terjadi peningkatan latensi.

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, Cloud Healthcare API memproses 50% permintaan dalam 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, Cloud Healthcare API memproses 99% permintaan dalam 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 secara keseluruhan karena permintaan outlier dapat memiliki pengaruh besar.

Misalnya, proses di Cloud Healthcare API memproses 100 permintaan dalam 100 menit. Latensi persentil ke-99 selama 100 menit akan berdasarkan satu permintaan terlama. 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 sistem Anda secara keseluruhan. Anda dapat menggunakan contoh ini untuk menentukan respons sistem Anda terhadap traffic yang berat.