Penyetelan kinerja aplikasi terdistribusi

  • Artikel

Dalam seri ini, kami berjalan melalui beberapa skenario aplikasi cloud, menunjukkan bagaimana tim pengembangan menggunakan tes beban dan metrik untuk mendiagnosis masalah kinerja. Artikel-artikel ini didasarkan pada pengujian beban aktual yang kami lakukan saat mengembangkan aplikasi contoh. Kode untuk setiap skenario tersedia di GitHub.

Skenario:

Apa itu kinerja?

Kinerja sering diukur dalam hal produksi, waktu respons, dan ketersediaan. Target kinerja harus didasarkan pada operasi bisnis. Tugas yang dihadapi pelanggan mungkin memiliki persyaratan yang lebih ketat daripada tugas operasional seperti menghasilkan laporan.

Tentukan tujuan tingkat layanan (SLO) yang mendefinisikan target kinerja untuk setiap beban kerja. Anda biasanya mencapai tujuan ini dengan memecah target performa menjadi satu set Indikator Performa Utama (KPI), seperti:

  • Latensi atau waktu respons permintaan tertentu
  • Jumlah permintaan yang dilakukan per detik
  • Tingkat di mana sistem menghasilkan pengecualian.

Target kinerja harus secara eksplisit menyertakan beban target. Selain itu, tidak semua pengguna menerima tingkat performa yang sama persis, bahkan ketika mengakses sistem secara bersamaan dan melakukan pekerjaan yang sama. Jadi SLO harus dibingkai dalam hal persentil.

Contoh SLO untuk mungkin: "Permintaan klien memiliki respons dalam waktu 500 md @ P90, pada beban hingga 25 K permintaan/detik."

Tantangan penyetelan kinerja sistem terdistribusi

Hal ini dapat sangat menantang untuk mendiagnosis masalah kinerja dalam aplikasi terdistribusi. Beberapa tantangannya adalah:

  • Transaksi atau operasi bisnis tunggal biasanya melibatkan beberapa komponen sistem. Mungkin sulit untuk mendapatkan pandangan end-to-end holistik dari satu operasi.

  • Konsumsi sumber daya didistribusikan di beberapa simpul. Untuk mendapatkan tampilan yang konsisten, Anda perlu mengumpulkan log dan metrik di satu tempat.

  • Cloud menawarkan skala elastis. Autoscaling adalah teknik penting untuk menangani lonjakan beban, tetapi juga dapat menutupi masalah mendasar. Juga, mungkin sulit untuk mengetahui komponen mana yang perlu diskalakan dan kapan.

  • Beban kerja sering kali tidak menskalakan di seluruh inti atau utas. Penting untuk memahami persyaratan beban kerja Anda dan melihat ukuran yang dioptimalkan dengan lebih baik. Beberapa ukuran menawarkan inti yang dibatasi dan hyperthreading yang dinonaktifkan untuk meningkatkan beban kerja berorientasi inti tunggal dan per beban kerja berlisensi inti.

  • Kegagalan cascading dapat menyebabkan kegagalan hulu masalah akar. Akibatnya, sinyal pertama dari masalah dapat muncul dalam komponen yang berbeda dari akar penyebab.

Praktik terbaik umum

Penyesuaian kinerja adalah seni dan sains, tetapi dapat dibuat lebih dekat dengan sains dengan mengambil pendekatan sistematis. Berikut beberapa praktik terbaik:

  • Aktifkan telemetri untuk mengumpulkan metrik. Instrumen kode Anda Ikuti praktik terbaik untuk pemantauan. Gunakan pelacakan berkorelasi sehingga Anda dapat melihat semua langkah dalam transaksi.

  • Pantau persentil 90/95/99, bukan hanya rata-rata. Rata-rata dapat menutupi outlier. Tingkat sampling untuk metrik juga penting. Jika tingkat sampling terlalu rendah, dapat menyembunyikan paku atau outlier yang mungkin menunjukkan masalah.

  • Serang satu kemacetan pada satu waktu. Bentuk hipotesis dan uji dengan mengubah satu variabel pada satu waktu. Menghapus satu kemacetan akan sering mengungkap kemacetan lain lebih jauh di hulu atau hilir.

  • Kesalahan dan percobaan ulang dapat berdampak besar pada kinerja. Jika Anda melihat bahwa layanan backend membatasi sistem Anda, peluasan skala atau coba optimalkan penggunaan (misalnya dengan menyetel kueri database).

  • Carilah anti-pola kinerja umum.

  • Carilah kesempatan untuk mepararlelkan. Dua sumber kemacetan yang umum adalah antrian pesan dan database. Dalam kedua kasus tersebut, sharding dapat membantu. Untuk informasi selengkapnya, lihat Pemisahan data horizontal, vertikal, dan fungsional. Cari partisi yang mungkin menunjukkan beban baca atau tulis yang tidak seimbang.

Langkah berikutnya

Baca skenario penyetelan performa