Memecahkan masalah peningkatan latensi di aplikasi App Engine

Dalam banyak kasus, peningkatan latensi dalam aplikasi Anda pada akhirnya akan menyebabkan error server 5xx. Karena penyebab utama lonjakan error dan latensi mungkin sama, terapkan strategi berikut untuk memecahkan masalah latensi:

  1. Menentukan cakupan masalah latensi
  2. Mengidentifikasi penyebabnya
  3. Memecahkan masalah

Menentukan cakupan masalah latensi

Tentukan cakupan masalah dengan mengajukan pertanyaan berikut:

  • Aplikasi, layanan, dan versi mana yang terpengaruh oleh masalah ini?
  • Endpoint spesifik mana pada layanan yang terpengaruh oleh masalah ini?
  • Apakah hal ini berdampak terhadap semua klien secara global, atau sebagian klien tertentu?
  • Kapan waktu mulai dan waktu berakhir insiden tersebut? Pertimbangkan untuk menentukan zona waktu.
  • Apa error spesifiknya?
  • Apa yang dimaksud dengan delta latensi yang diamati, yang biasanya ditentukan sebagai peningkatan pada persentil tertentu? Misalnya, latensi meningkat sebesar 2 detik pada persentil ke-90.
  • Bagaimana Anda mengukur latensi? Secara khusus, apakah Anda mengukurnya di klien, atau terlihat di data latensi Cloud Logging atau Cloud Monitoring yang disediakan oleh infrastruktur penayangan App Engine?
  • Apa dependensi layanan Anda, dan apakah ada yang mengalami insiden?
  • Apakah Anda baru-baru ini membuat perubahan kode, konfigurasi, atau workload yang memicu masalah ini?

Layanan mungkin memiliki pemantauan dan logging kustom sendiri yang dapat Anda gunakan untuk lebih mempersempit cakupan masalah. Dengan menentukan cakupan masalah, Anda dapat mencari kemungkinan penyebab utama dan menentukan langkah pemecahan masalah selanjutnya.

Mengidentifikasi penyebabnya

Tentukan komponen mana di jalur permintaan yang paling mungkin menyebabkan latensi atau error. Komponen utama dalam jalur permintaan adalah sebagai berikut:

Klien --> Internet --> Google Front End (GFE) --> App Engine yang menyediakan infrastruktur --> Instance layanan

Jika informasi sebelumnya tidak menunjukkan sumber kegagalan, terapkan strategi berikut saat meninjau kondisi dan performa instance layanan Anda:

  1. Memantau log permintaan App Engine. Jika Anda melihat error kode status HTTP atau latensi yang meningkat di log tersebut, masalahnya mungkin terletak pada instance yang menjalankan layanan Anda.

  2. Jika jumlah instance layanan belum diskalakan untuk mencocokkan tingkat traffic, instance Anda mungkin kelebihan beban, sehingga menyebabkan error dan latensi yang meningkat.

  3. Jika Anda melihat peningkatan error atau latensi di Cloud Monitoring, masalahnya mungkin berasal dari upstream load balancer, yang mencatat metrik App Engine. Pada umumnya, hal ini mengarah ke masalah dalam instance layanan.

  4. Jika Anda melihat peningkatan latensi atau error dalam metrik pemantauan, tetapi tidak dalam log permintaan, hal ini menunjukkan kegagalan load balancing, atau kegagalan instance yang parah yang mencegah load balancer merutekan permintaan. Untuk membedakan kasus-kasus ini, lihat log permintaan sebelum insiden dimulai. Jika log permintaan menunjukkan peningkatan latensi sebelum kegagalan, instance aplikasi mulai gagal sebelum load balancer berhenti merutekan permintaan ke sana.

Memecahkan masalah

Bagian ini menjelaskan strategi pemecahan masalah untuk masalah latensi yang tinggi dari komponen berikut di jalur permintaan:

  1. Internet
  2. Google Front End (GFE)
  3. Infrastruktur penayangan App Engine
  4. Instance aplikasi
  5. Dependensi aplikasi

Internet

Aplikasi Anda mungkin mengalami masalah latensi karena konektivitas yang buruk atau bandwidth yang lebih rendah.

Koneksi internet yang buruk

Untuk menentukan apakah masalahnya adalah koneksi internet yang buruk, jalankan perintah berikut pada klien Anda:

$ curl -s -o /dev/null -w '%{time_connect}\n' <hostname>

Nilai untuk time_connect menunjukkan latensi koneksi klien ke Google Front End terdekat. Untuk koneksi lambat, pecahkan masalah lebih lanjut menggunakan traceroute untuk menentukan hop mana di jaringan yang menyebabkan penundaan.

Menjalankan pengujian dari klien di lokasi geografis yang berbeda. App Engine otomatis merutekan permintaan ke pusat data Google terdekat, yang bervariasi berdasarkan lokasi klien.

Bandwidth rendah

Aplikasi mungkin merespons dengan cepat; namun, bottleneck jaringan menunda infrastruktur penayangan App Engine agar tidak mengirim paket melalui jaringan dengan cepat, sehingga memperlambat respons.

Google Front End (“GFE”)

Aplikasi Anda mungkin mengalami masalah latensi karena pemilihan rute yang salah, permintaan paralel yang dikirim dari klien HTTP/2, atau penghentian koneksi SSL.

Memetakan IP klien ke region geografis

Google akan me-resolve nama host aplikasi App Engine ke GFE terdekat dengan klien, berdasarkan alamat IP klien yang digunakan dalam pencarian DNS. Jika DNS resolver klien tidak menggunakan protokol EDNS0, Google mungkin tidak merutekan permintaan klien ke GFE terdekat.

Pemblokiran head-of-line HTTP/2

Klien HTTP/2 yang mengirim beberapa permintaan secara paralel mungkin mengalami peningkatan latensi karena pemblokiran head-of-line di GFE. Untuk mengatasi masalah ini, klien harus menggunakan protokol QUIC.

Penghentian SSL untuk domain kustom

GFE mungkin menghentikan koneksi SSL. Jika Anda menggunakan domain kustom, bukan domain appspot.com, penghentian SSL memerlukan hop tambahan. Tindakan ini mungkin meningkatkan latensi untuk aplikasi yang berjalan di beberapa wilayah. Untuk mengetahui informasi selengkapnya, lihat Memetakan domain kustom.

Infrastruktur penyajian App Engine

Anda mungkin melihat peningkatan latensi di aplikasi karena insiden layanan secara keseluruhan atau penskalaan otomatis.

Insiden di tingkat layanan

Google memposting detail masalah layanan yang parah di dasbor Kondisi Layanan. Namun, Google melakukan peluncuran secara bertahap, sehingga insiden di tingkat layanan cenderung tidak memengaruhi semua instance Anda sekaligus.

Penskalaan otomatis

Latensi atau error yang meningkat dapat terjadi karena skenario penskalaan otomatis berikut:

  • Meningkatkan skala traffic terlalu cepat: Penskalaan otomatis App Engine mungkin tidak menskalakan instance Anda secepat peningkatan traffic, sehingga menyebabkan overload sementara. Biasanya, kelebihan beban terjadi saat traffic dihasilkan oleh program komputer, bukan pengguna akhir. Untuk mengatasi masalah ini, batasi sistem yang menghasilkan traffic.

  • Lonjakan traffic: lonjakan traffic dapat menyebabkan peningkatan latensi jika layanan yang diskalakan otomatis perlu ditingkatkan skalanya lebih cepat daripada yang memungkinkan, tanpa memengaruhi latensi. Traffic pengguna akhir biasanya tidak menyebabkan lonjakan traffic yang sering. Jika melihat lonjakan traffic, Anda harus menyelidiki penyebabnya. Jika sistem batch berjalan pada interval, Anda mungkin dapat memperlancar traffic atau menggunakan setelan penskalaan yang berbeda.

  • Setelan autoscaler: autoscaler dapat dikonfigurasi berdasarkan karakteristik penskalaan layanan Anda. Parameter penskalaan mungkin menjadi tidak optimal selama skenario berikut:

    • Setelan penskalaan lingkungan standar App Engine dapat menyebabkan latensi jika disetel terlalu agresif. Jika Anda melihat respons server dengan kode status 500 dan pesan "Permintaan dibatalkan setelah menunggu terlalu lama untuk mencoba melayani permintaan Anda" di log, berarti waktu permintaan habis saat antrean tertunda menunggu instance tanpa aktivitas.

    • Anda mungkin melihat peningkatan waktu tunda dengan penskalaan manual meskipun telah menyediakan instance yang memadai. Sebaiknya Anda tidak menggunakan penskalaan manual jika aplikasi Anda menyalurkan traffic pengguna akhir. Penskalaan manual lebih baik untuk workload seperti task queue.

    • Penskalaan dasar meminimalkan biaya dengan mengorbankan latensi. Sebaiknya Anda tidak menggunakan penskalaan dasar untuk layanan yang sensitif terhadap latensi.

    • Setelan penskalaan default App Engine memberikan latensi yang optimal untuk sebagian besar layanan. Jika masih menemukan adanya permintaan dengan waktu tunda yang tinggi, tentukan jumlah minimum instance. Jika menyesuaikan setelan penskalaan untuk mengurangi biaya dengan meminimalkan instance tanpa aktivitas, Anda berisiko mengalami lonjakan latensi jika beban meningkat secara tiba-tiba.

Sebaiknya lakukan benchmark performa dengan setelan penskalaan default, lalu jalankan benchmark baru setelah setiap perubahan pada setelan ini.

Deployment

Peningkatan latensi sesaat setelah deployment menunjukkan bahwa skala Anda tidak memadai sebelum memigrasikan traffic. Instance baru mungkin belum mempersiapkan cache lokal, dan ditayangkan lebih lambat dibandingkan instance lama.

Untuk menghindari lonjakan latensi, jangan men-deploy layanan App Engine menggunakan nama versi yang sama dengan versi layanan yang sudah ada. Jika menggunakan kembali nama versi yang sudah ada, Anda tidak akan dapat memigrasikan traffic ke versi baru secara perlahan. Permintaan mungkin menjadi lebih lambat karena App Engine memulai ulang setiap instance dalam jangka waktu yang singkat. Anda juga harus melakukan deployment ulang jika ingin kembali ke versi sebelumnya.

Instance aplikasi

Bagian ini menjelaskan strategi umum yang dapat Anda terapkan ke instance aplikasi, dan kode sumber untuk mengoptimalkan performa dan mengurangi latensi.

Kode aplikasi

Masalah dalam kode aplikasi dapat sulit untuk di-debug, terutama jika sifatnya intermiten atau tidak dapat direproduksi.

Untuk mengatasi masalah, lakukan tindakan berikut:

  • Untuk mendiagnosis masalah, sebaiknya instrumentasikan aplikasi Anda menggunakan logging, monitoring, dan tracing. Anda juga dapat menggunakan Cloud Profiler.

  • Coba ulangi masalah di lingkungan pengembangan lokal yang dapat memungkinkan Anda menjalankan alat proses debug bahasa tertentu yang mungkin tidak dapat dijalankan dalam App Engine.

  • Untuk lebih memahami bagaimana aplikasi Anda gagal dan bottleneck apa yang terjadi, jalankan uji beban pada aplikasi Anda hingga terjadi kegagalan. Tetapkan jumlah maksimum instance, lalu tingkatkan beban secara bertahap hingga aplikasi gagal.

  • Jika masalah latensi berkaitan dengan deployment kode aplikasi versi baru, rollback untuk menentukan apakah versi baru tersebut yang menyebabkan insiden. Namun, jika Anda men-deploy kode terus-menerus, deployment yang sering terjadi akan mempersulit penentuan apakah deployment tersebut yang menyebabkan insiden atau tidak berdasarkan waktu onset.

  • Aplikasi Anda dapat menyimpan setelan konfigurasi dalam Datastore atau di tempat lain. Buat linimasa perubahan konfigurasi untuk menentukan apakah ada perubahan yang sesuai dengan dimulainya peningkatan latensi.

Perubahan workload

Perubahan workload dapat menyebabkan peningkatan latensi. Beberapa metrik pemantauan yang menunjukkan perubahan beban kerja mencakup qps, penggunaan API, dan latensi. Periksa juga perubahan ukuran permintaan dan respons.

Tekanan memori

Jika pemantauan menunjukkan pola gigi gergaji dalam penggunaan memori, atau penurunan penggunaan memori yang berkaitan dengan deployment, kebocoran memori mungkin menjadi penyebab masalah performa. Kebocoran memori juga dapat menyebabkan pembersihan sampah memori yang sering, sehingga mengakibatkan latensi lebih tinggi. Jika Anda tidak dapat melacak masalah ini ke masalah dalam kode, coba sediakan instance yang lebih besar dengan memori lebih besar.

Kebocoran resource

Jika instance aplikasi Anda menunjukkan peningkatan latensi yang berhubungan dengan usia instance, mungkin terjadi kebocoran resource yang menyebabkan masalah performa. Latensi menurun setelah deployment selesai. Misalnya, struktur data yang menjadi lebih lambat seiring waktu karena penggunaan CPU yang lebih tinggi dapat menyebabkan workload yang terikat ke CPU menjadi lebih lambat.

Pengoptimalan kode

Untuk mengurangi latensi di App Engine, optimalkan kode menggunakan metode berikut:

  • Tugas offline: gunakan Cloud Tasks untuk mencegah permintaan pengguna memblokir aplikasi yang menunggu penyelesaian tugas, seperti mengirim email.

  • Panggilan API asinkron: pastikan kode Anda tidak diblokir saat menunggu panggilan API selesai.

  • Panggilan API batch: panggilan API versi batch biasanya lebih cepat daripada mengirim panggilan satu per satu.

  • Denormalisasi model data: mengurangi latensi panggilan yang dilakukan ke lapisan persistensi data dengan melakukan denormalisasi model data.

Dependensi aplikasi

Pantau dependensi aplikasi Anda untuk mendeteksi apakah lonjakan latensi berkorelasi dengan kegagalan dependensi.

Perubahan workload dan peningkatan traffic dapat menyebabkan latensi dependensi meningkat.

Dependensi non-penskalaan

Jika dependensi aplikasi Anda tidak bertambah seiring peningkatan jumlah instance App Engine, dependensi tersebut mungkin akan mengalami overload saat traffic meningkat. Contoh dependensi yang mungkin tidak dapat diskalakan adalah database SQL. Jumlah instance aplikasi yang lebih tinggi akan menghasilkan jumlah koneksi database yang lebih tinggi, yang dapat menyebabkan kegagalan beruntun karena database tidak dapat dimulai. Untuk menyelesaikan masalah ini, lakukan tindakan berikut:

  1. Men-deploy versi default baru yang tidak terhubung ke database.
  2. Menonaktifkan versi default sebelumnya.
  3. Men-deploy versi non-default baru yang terhubung ke database.
  4. Memigrasikan traffic ke versi baru secara perlahan.

Sebagai tindakan pencegahan, desain aplikasi Anda untuk melepaskan permintaan ke dependensi menggunakan throttling adaptif.

Kegagalan lapisan cache

Untuk mempercepat permintaan, gunakan beberapa lapisan cache, seperti cache edge, Memcache, dan memori dalam instance. Kegagalan di salah satu lapisan cache ini dapat menyebabkan peningkatan latensi mendadak. Misalnya, flush Memcache dapat menyebabkan lebih banyak permintaan menuju ke Datastore yang lebih lambat.