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 untuk layanan Cloud Healthcare API dan cara klien 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, implementasikan logika percobaan ulang dan waktu tunggu yang sesuai. Saat menetapkan durasi waktu tunggu, berikan waktu yang cukup untuk melakukan hal berikut:

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

Anda dapat mencoba lagi beberapa error, tetapi error lainnya tidak dapat dicoba ulang dan akan terus berlanjut setiap kali mencoba lagi. Misalnya, jika data permintaan tidak diformat dengan benar, server akan merespons dengan kode status 400 Bad Request. Permintaan tidak akan berhasil sampai Anda memperbaiki data.

Untuk menangani situasi ini, Anda perlu membuat rencana untuk status error akhir.

Untuk mengetahui informasi selengkapnya tentang logika percobaan ulang dan waktu tunggu, lihat Mencoba ulang 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 melebihi batas percobaan ulangnya, 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 lagi.
  3. Klien akan menerima error 500 Internal Server Error terakhir.

Penting untuk dipahami bahwa error tersebut berasal di Cloud Healthcare API, bukan middleware. Untuk menyederhanakan proses debug, berikan informasi ini dalam error yang ditampilkan ke klien.

Diagram berikut menunjukkan skenario ketika 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.

Diagram tempat menangani error dalam stack klien/middleware/server.
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 sebanyak lima kali lagi hingga batas percobaan ulangnya tercapai.

  4. Proxy akan 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 selengkapnya tentang error yang ditampilkan dari Cloud Healthcare API.

Terkadang, klien atau proxy menerima error 500 Internal Server Error melewati batas percobaan ulangnya 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 lagi

Bergantung pada arsitektur sistem, Anda dapat mencoba lagi error tertentu dan mengabaikan error lainnya. Berikut adalah daftar tidak lengkap 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 pada frekuensi yang sama, dan beberapa mungkin tidak pernah terjadi.

Efek arsitektur sistem

Arsitektur sistem Anda memengaruhi cara dan waktu Anda mencoba kembali 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 suatu sistem memiliki lapisan middleware antara klien dan Cloud Healthcare API. Jika klien mengautentikasi dengan benar dan token autentikasi yang sudah tidak berlaku menyebabkan masalah, middleware harus memperbarui token dan mencoba lagi permintaan tersebut.

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

Rencana untuk status error akhir

Meskipun telah menerapkan logika percobaan ulang dan waktu tunggu habis, klien atau middleware mungkin akan menerima error hingga percobaan ulangnya habis. Error terakhir yang ditampilkan sebelum percobaan ulang dan waktu tunggu habis adalah status error akhir. Anda mungkin mendapati status {i>error <i}final untuk kesalahan konsistensi data.

Terkadang, status error terakhir memerlukan intervensi manual. Coba terapkan solusi untuk menyelesaikan status error akhir untuk permintaan. Jika tidak, catat status error akhir agar orang dapat meninjaunya.

Pertimbangkan hal berikut saat merencanakan cara menangani status error akhir:

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

Membuat rencana untuk meningkatkan latensi

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

  • Perbedaan kecil antar-permintaan, meskipun tampak tidak signifikan, dapat menyebabkan waktu pemrosesan yang lebih lama.
  • Permintaan serupa mungkin memiliki latensi yang berbeda. Misalnya, dua permintaan serupa yang menambahkan data ke penyimpanan data mungkin memiliki latensi yang berbeda jika salah satu permintaan melampaui batas yang memicu tugas tambahan, seperti mengalokasikan lebih banyak penyimpanan.
  • Cloud Healthcare API menangani banyak permintaan secara serentak. Waktu ketika klien mengirim permintaan, yang diukur dalam sepersekian detik, mungkin bertepatan dengan waktu saat Cloud Healthcare API menerima beban yang lebih berat dari biasanya.
  • Jika resource fisik Cloud Healthcare API, seperti disk, menangani banyak permintaan, resource tersebut harus menyelesaikan tugas dalam antrean sebelum menangani permintaan lain.
  • Terkadang, Cloud Healthcare API mencoba ulang error di sisi server, sehingga dapat meningkatkan latensi untuk klien.
  • Mungkin ada beberapa salinan data di pusat data yang berbeda pada lokasi regional atau multi-regional. Jika permintaan Anda dirutekan ke beberapa pusat data, baik pada permintaan asli maupun saat percobaan ulang, mungkin akan terjadi peningkatan latensi.

Membuat rencana 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 hitungan detik, untuk 50% permintaan tercepat. Misalnya, jika latensi persentil ke-50 adalah 0,5 detik, berarti Cloud Healthcare API akan memproses 50% permintaan dalam 0,5 detik. Latensi persentil ke-50 juga disebut dengan "latensi median".
  • Latensi persentil ke-99 adalah latensi maksimum, dalam hitungan detik, untuk 99% permintaan tercepat. Misalnya, jika latensi persentil ke-99 adalah dua detik, berarti Cloud Healthcare API memproses 99% permintaan dalam waktu dua detik.

Jika Anda menganalisis latensi persentil selama suatu interval ketika 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, anggaplah suatu proses di Cloud Healthcare API memproses 100 permintaan dalam 100 menit. Latensi persentil ke-99 selama 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 dalam jangka waktu yang lebih lama, seperti 24 jam, dapat memberikan lebih banyak data tentang perilaku sistem Anda secara keseluruhan. Anda dapat menggunakan contoh ini untuk menentukan cara sistem merespons traffic yang padat.