Mengukur SLO

Last reviewed 2024-03-29 UTC

Dokumen dalam Framework Arsitektur Google Cloud ini dibuat berdasarkan diskusi sebelumnya tentang tujuan tingkat layanan (SLO) dengan mempelajari apa dan bagaimana pengukuran sehubungan dengan beban kerja layanan umum. Dokumen ini didasarkan pada konsep yang ditentukan dalam Komponen tujuan tingkat layanan.

Menentukan apa yang akan diukur

Terlepas dari domain Anda, banyak layanan memiliki fitur yang sama dan dapat menggunakan SLO umum. Bagian ini membahas SLO umum untuk berbagai jenis layanan dan memberikan penjelasan mendetail tentang SLI yang berlaku untuk setiap SLO.

Setiap subbagian berikut mengidentifikasi jenis layanan tertentu dan memberikan deskripsi singkat tentang layanan tersebut. Kemudian, yang tercantum di bawah setiap jenis layanan adalah kemungkinan SLI, definisi indikator, dan informasi lainnya yang terkait dengan SLI.

Layanan berdasarkan permintaan

Jenis layanan ini menerima permintaan dari klien (pengguna atau layanan lain), melakukan beberapa komputasi, mungkin mengirimkan permintaan jaringan ke backend, lalu menampilkan respons ke klien.

Ketersediaan sebagai SLI

Ketersediaan adalah proporsi permintaan valid yang berhasil ditayangkan. Daftar berikut mencakup informasi yang perlu dipertimbangkan saat menggunakan ketersediaan sebagai SLI:

  • Sebagai pemilik layanan, Anda memutuskan permintaan yang valid. Definisi umum mencakup tidak panjang nol atau mematuhi protokol klien-server. Salah satu metode untuk mengukur validitas adalah meninjau kode respons HTTP (atau RPC). Misalnya, kode HTTP 5xx adalah error terkait server yang dihitung terhadap SLO, sedangkan kode 4xx adalah error klien yang tidak dihitung.
  • Setiap kode respons yang ditampilkan oleh layanan Anda harus diperiksa untuk memastikan bahwa aplikasi menggunakan kode tersebut dengan benar dan konsisten. Apakah kode tersebut merupakan indikator akurat dari pengalaman pengguna terhadap layanan Anda? Misalnya, bagaimana respons situs e-commerce saat pengguna mencoba memesan item yang stoknya habis? Apakah permintaan gagal dan menampilkan pesan error? Apakah situs menyarankan produk serupa? Kode error harus dikaitkan dengan ekspektasi pengguna.
  • Developer dapat secara tidak sengaja menyalahgunakan error. Dengan menggunakan skenario stok habis dari poin sebelumnya, developer mungkin secara keliru menampilkan error. Namun, sistem tersebut berfungsi dengan benar dan bukan error. Kode harus ditampilkan sebagai berhasil, meskipun pengguna tidak dapat membeli item. Meskipun pemilik layanan harus diberi tahu tentang inventaris yang rendah, ketidakmampuan untuk melakukan penjualan bukanlah kesalahan dari sudut pandang pelanggan dan tidak diperhitungkan terhadap SLO.
  • Contoh layanan yang lebih kompleks adalah layanan yang menangani permintaan asinkron atau menyediakan proses yang berjalan lama untuk pelanggan. Meskipun Anda dapat mengekspos ketersediaan dengan cara lain, sebaiknya tampilkan ketersediaan sebagai proporsi permintaan valid yang berhasil. Ketersediaan juga dapat didefinisikan sebagai jumlah menit saat workload pelanggan berjalan (terkadang disebut sebagai pendekatan menit yang baik).
  • Pertimbangkan layanan yang menawarkan virtual machine (VM). Anda dapat mengukur ketersediaan dalam hal jumlah menit setelah permintaan awal yang VM-nya tersedia untuk pengguna.

Latensi sebagai SLI

Latensi (atau kecepatan) adalah proporsi permintaan valid yang ditayangkan lebih cepat daripada nilai minimum. Dengan demikian, latensi menunjukkan kecepatan layanan, dan dapat diukur dengan menghitung perbedaan antara waktu mulai dan berhenti untuk jenis permintaan tertentu. Ingat, ini adalah persepsi pengguna terhadap latensi, dan pemilik layanan biasanya mengukur nilai ini terlalu akurat. Pada kenyataannya, pengguna tidak dapat membedakan antara refresh 100 milidetik (md) dan 300 md, dan bahkan mungkin menerima respons antara 300 md dan 1000 md seperti biasa. Untuk mengetahui informasi selengkapnya, lihat Model Rail.

Kembangkan metrik yang berfokus pada aktivitas yang berfokus pada pengguna. Berikut adalah beberapa contoh metrik tersebut:

  • Interaktif: Pengguna menunggu 1.000 md untuk mendapatkan hasil setelah mengklik elemen.
  • Menulis: Perubahan pada sistem terdistribusi yang mendasarinya memerlukan waktu 1.500 md. Meskipun durasi waktu ini dianggap lambat, pengguna cenderung menerimanya. Sebaiknya Anda membedakan antara operasi tulis dan baca secara eksplisit dalam metrik Anda.
  • Latar belakang: Tindakan yang tidak terlihat oleh pengguna,seperti pemuatan ulang data secara berkala atau permintaan asinkron lainnya, memerlukan waktu tidak lebih dari 5.000 md untuk diselesaikan.

Latensi biasanya diukur sebagai distribusi dan seperti yang disebutkan dalam Memilih SLI. Dengan mempertimbangkan distribusi, Anda dapat mengukur berbagai persentil. Misalnya, Anda mungkin mengukur jumlah permintaan yang lebih lambat daripada persentil ke-99 historis. Peristiwa yang lebih cepat dari nilai minimum ini dianggap baik; permintaan yang lebih lambat dianggap tidak begitu baik. Anda menetapkan nilai minimum ini berdasarkan persyaratan produk. Anda bahkan dapat menetapkan beberapa SLO latensi, misalnya latensi standar versus latensi tail.

Jangan hanya menggunakan latensi rata-rata (atau median) sebagai SLI Anda. Jika latensi median terlalu lambat, setengah dari pengguna sudah tidak puas. Selain itu, layanan Anda dapat mengalami latensi buruk selama berhari-hari sebelum Anda menemukan masalahnya. Oleh karena itu, tentukan SLO untuk latensi tail (persentil ke-95) dan untuk latensi median (persentil ke-50).

Dalam artikel ACM Metrics That Matter, Benjamin Treynor Sloss menulis hal berikut:

  • "Aturan praktis yang baik ... adalah bahwa latensi persentil ke-99 tidak boleh lebih dari tiga hingga lima kali latensi median."
  • "Kami mendapati bahwa ukuran latensi persentil ke-50, ke-95, dan ke-99 untuk setiap layanan masing-masing berharga secara individual, dan idealnya kami akan menetapkan SLO untuk setiap layanan tersebut."

Tentukan batas latensi berdasarkan persentil historis, lalu ukur jumlah permintaan yang masuk ke setiap bucket. Pendekatan ini adalah model yang baik untuk diikuti.

Kualitas sebagai bagian SLI

Kualitas adalah proporsi permintaan valid yang ditayangkan tanpa menurunnya kualitas layanan. Sebagai contoh, kualitas adalah SLI yang berguna untuk layanan kompleks yang dirancang untuk gagal secara wajar. Untuk mengilustrasikannya, pertimbangkan halaman web yang memuat konten utamanya dari satu datastore dan memuat aset opsional dari 100 layanan dan datastore lainnya. Jika salah satu elemen opsional tidak aktif atau terlalu lambat, halaman masih dirender tanpa elemen opsional. Dalam skenario ini, Anda dapat menggunakan SLI untuk melakukan hal berikut:

  • Dengan mengukur jumlah permintaan yang menerima respons yang buruk (respons yang tidak memiliki balasan dari setidaknya satu layanan backend), Anda dapat melaporkan rasio permintaan yang buruk.
  • Anda dapat melacak jumlah respons yang tidak memiliki balasan dari satu backend, atau dari beberapa backend.

Layanan pemrosesan data

Layanan ini menggunakan data dari input, memproses data tersebut, dan menghasilkan output. Performa layanan pada langkah menengah tidak sepenting hasil akhir. SLI terkuat adalah keaktualan, cakupan, ketepatan, dan throughput. Latensi dan ketersediaan kurang berguna.

Keaktualan sebagai bagian SLI

Keaktualan adalah proporsi data valid yang diperbarui lebih baru daripada nilai minimum. Daftar berikut memberikan beberapa contoh penggunaan keaktualan sebagai SLI:

  • Dalam sistem batch, keaktualan diukur sebagai waktu yang berlalu selama pemrosesan berhasil diselesaikan untuk output tertentu.
  • Dalam pemrosesan real-time atau sistem yang lebih kompleks, keaktualan melacak usia data terbaru yang diproses dalam pipeline.
  • Dalam game online yang membuat ubin peta secara real time, pengguna mungkin tidak melihat seberapa cepat ubin peta dibuat, tetapi mereka mungkin menyadari saat data peta tidak ada atau tidak baru. Dalam hal ini, keaktualan melacak data yang hilang atau usang.
  • Dalam layanan yang membaca data dari sistem pelacakan untuk menghasilkan pesan "Item X tersedia" untuk situs e-commerce, SLI keaktualan dapat ditentukan sebagai persentase permintaan yang menggunakan informasi stok yang baru saja diperbarui (dalam menit terakhir).
  • Anda juga dapat menggunakan metrik untuk menayangkan data non-baru guna memperbarui SLI untuk mengetahui kualitas.

Cakupan sebagai SLI

Cakupan adalah proporsi data valid yang berhasil diproses.

Untuk menentukan cakupan, ikuti langkah-langkah berikut:

  1. Tentukan apakah akan menerima input sebagai valid atau melewatinya. Misalnya, jika catatan input rusak atau panjangnya nol dan tidak dapat diproses, Anda dapat menganggap catatan tersebut tidak valid sebagai metrik.
  2. Hitung jumlah data yang valid. Jumlah ini dapat dilakukan dengan metode *count() *sederhana dan mewakili total jumlah data Anda.
  3. Terakhir, hitung jumlah data yang berhasil diproses dan bandingkan jumlah tersebut dengan total jumlah data yang valid. Nilai ini adalah SLI untuk cakupan.

Ketepatan sebagai bagian SLI

Koreksi adalah proporsi data valid yang menghasilkan output yang benar. Pertimbangkan poin-poin berikut saat menggunakan akurasi sebagai SLI:

  • Dalam beberapa kasus, metode untuk menentukan ketepatan output digunakan untuk memvalidasi pemrosesan output. Misalnya, sistem yang memutar atau mewarnai gambar tidak boleh menghasilkan gambar zero-byte, atau gambar dengan panjang atau lebar nol. Penting untuk memisahkan logika validasi ini dari logika pemrosesan itu sendiri.
  • Salah satu metode untuk mengukur SLI kebenaran adalah dengan menggunakan data input pengujian yang diketahui bagus. Jenis data ini adalah data yang menghasilkan output yang diketahui benar. Ingat, data input harus mewakili data pengguna.
  • Dalam kasus lain, Anda dapat menggunakan pemeriksaan matematis atau logika terhadap output, seperti dalam contoh sebelumnya tentang memutar gambar.
  • Terakhir, pertimbangkan sistem penagihan yang menentukan validitas transaksi dengan memeriksa perbedaan antara saldo sebelum dan setelah transaksi. Jika cocok dengan nilai transaksi itu sendiri, transaksi tersebut adalah transaksi yang valid.

Throughput sebagai bagian SLI

Throughput adalah proporsi waktu ketika kecepatan pemrosesan data lebih cepat dari batas. Berikut beberapa poin yang perlu dipertimbangkan saat menggunakan throughput sebagai SLI:

  • Throughput dalam sistem pemrosesan data sering kali lebih mewakili kepuasan pengguna daripada pengukuran latensi tunggal untuk operasi tertentu. Jika ukuran setiap input sangat bervariasi, mungkin tidak masuk akal untuk membandingkan waktu yang diperlukan untuk menyelesaikan setiap elemen (jika semua tugas berlangsung pada kecepatan yang dapat diterima).
  • Byte per detik adalah cara umum untuk mengukur jumlah pekerjaan yang diperlukan untuk memproses data, terlepas dari ukuran set data. Namun, metrik apa pun yang kira-kira diskalakan secara linear sehubungan dengan biaya pemrosesan akan berfungsi.
  • Mungkin akan bermanfaat untuk mempartisi sistem pemrosesan data Anda berdasarkan tingkat throughput yang diharapkan. Atau terapkan sistem kualitas layanan yang memastikan input prioritas tinggi ditangani, dan input prioritas rendah dimasukkan ke dalam antrean. Apa pun itu, mengukur throughput seperti yang ditentukan di bagian ini membantu menentukan apakah sistem Anda berfungsi sesuai dengan SLO.

Layanan eksekusi terjadwal

Untuk layanan yang perlu melakukan tindakan pada interval yang teratur (seperti cron job Kubernetes), ukur skew dan durasi eksekusi. Berikut adalah contoh cron job Kubernetes terjadwal:

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"

Skew sebagai bagian SLI

Kecenderungan adalah proporsi eksekusi yang dimulai dalam jangka waktu yang dapat diterima dari waktu mulai yang diharapkan. Saat menggunakan kemiringan, pertimbangkan hal berikut:

  • Skew mengukur perbedaan waktu antara kapan tugas dijadwalkan untuk dimulai dan waktu mulai yang sebenarnya. Pertimbangkan contoh cron job Kubernetes sebelumnya. Jika disetel untuk dimulai pada menit nol setiap jam, tetapi dimulai pada tiga menit setelah satu jam, kemiringannya adalah tiga menit. Saat tugas berjalan lebih awal, Anda memiliki bias negatif.
  • Anda dapat mengukur kemiringan sebagai distribusi dari waktu ke waktu, dengan rentang sesuai yang dapat diterima dan menentukan kemiringan yang baik. Untuk menentukan SLI, bandingkan jumlah operasi yang berada dalam rentang yang baik.

Durasi eksekusi sebagai SLI

Durasi eksekusi adalah proporsi eksekusi yang selesai dalam jangka waktu durasi yang dapat diterima. Berikut ini adalah konsep penting yang terkait dengan penggunaan durasi eksekusi:

  • Durasi eksekusi adalah waktu yang diperlukan untuk menyelesaikan tugas. Untuk eksekusi tertentu, mode kegagalan yang umum adalah saat durasi sebenarnya melebihi durasi yang dijadwalkan.
  • Kasus yang menarik adalah menerapkan SLI ini ke tugas yang tidak pernah berakhir. Karena tugas ini tidak selesai, catat waktu yang dihabiskan untuk tugas tertentu, bukan menunggu tugas selesai. Pendekatan ini memberikan distribusi yang akurat tentang waktu yang diperlukan untuk menyelesaikan pekerjaan, bahkan dalam skenario terburuk.
  • Seperti halnya kemiringan, Anda dapat melacak durasi eksekusi sebagai distribusi dan menentukan batas atas dan bawah yang dapat diterima untuk peristiwa yang baik.

Metrik untuk jenis sistem lainnya

Banyak workload lain memiliki metriknya sendiri untuk menghasilkan SLI dan SLO. Perhatikan contoh berikut:

  • Sistem penyimpanan: Ketahanan, throughput, waktu ke byte pertama, ketersediaan blob.
  • Media/video: Kontinuitas pemutaran klien, waktu untuk memulai pemutaran, transcode kelengkapan eksekusi grafik.
  • Game: Waktu untuk mencocokkan pemain aktif, waktu untuk membuat peta.

Menentukan cara pengukuran

Bagian sebelumnya membahas hal yang Anda ukur. Setelah menentukan hal yang akan diukur, Anda dapat memutuskan cara mengukurnya. Anda dapat mengumpulkan metrik SLI dengan beberapa cara. Bagian berikut mengidentifikasi berbagai metode pengukuran, memberikan deskripsi singkat tentang metode, mencantumkan kelebihan dan kekurangan metode, serta mengidentifikasi alat penerapan yang sesuai untuk metode tersebut.

Logging sisi server

Metode logging sisi server melibatkan pemrosesan log sisi server untuk permintaan atau data yang diproses.

Logging sisi server Detail
Kelebihan
  • Proses ulang log yang ada untuk mengisi ulang data SLI historis.
  • Gunakan ID sesi lintas layanan untuk merekonstruksi perjalanan pengguna yang kompleks di beberapa layanan.
Kekurangan
  • Permintaan yang tidak sampai di server tidak akan dicatat.
  • Permintaan yang menyebabkan server error mungkin tidak dicatat.
  • Lamanya waktu untuk memproses log dapat menyebabkan SLI yang tidak berlaku lagi, yang mungkin menjadi data yang tidak memadai untuk respons operasional.
  • Menulis kode untuk memproses log bisa menjadi tugas yang rentan error dan memakan waktu.
Metode & alat penerapan

Metrik server aplikasi

Metode metrik server aplikasi melibatkan ekspor metrik SLI dari kode yang melayani permintaan pengguna atau memproses data mereka.

Metrik server aplikasi Detail
Kelebihan
  • Menambahkan metrik baru ke kode biasanya cepat dan murah.
Kekurangan
  • Permintaan yang tidak menjangkau server aplikasi tidak akan dicatat.
  • Permintaan multi-layanan mungkin sulit dilacak.
Metode & alat penerapan

Metrik infrastruktur frontend

Metode metrik infrastruktur frontend menggunakan metrik dari infrastruktur load balancing (seperti, load balancer Lapisan 7 global di Google Cloud).

Metrik infrastruktur frontend Detail
Kelebihan
  • Metrik dan data historis sering kali sudah ada, sehingga mengurangi upaya engineer untuk memulai.
  • Pengukuran diambil pada titik yang paling dekat dengan pelanggan, tetapi masih dalam infrastruktur penayangan.
Kekurangan
  • Tidak valid untuk SLI pemrosesan data.
  • Hanya dapat memperkirakan perjalanan pengguna multi-permintaan.
Metode & alat penerapan

Klien atau data sintetis

Metode klien atau data sintetis melibatkan penggunaan klien yang mengirim permintaan buatan secara berkala dan memvalidasi respons.

Klien atau data sintetis Detail
Kelebihan
  • Mengukur semua langkah perjalanan pengguna multi-permintaan.
  • Mengirim permintaan dari luar infrastruktur Anda akan menangkap lebih banyak jalur permintaan secara keseluruhan di SLI.
Kekurangan
  • Memperkirakan pengalaman pengguna dengan permintaan sintetis mungkin menyesatkan (baik positif palsu maupun negatif palsu).
  • Mencakup semua corner case sulit dan dapat berubah menjadi pengujian integrasi.
  • Target keandalan tinggi memerlukan pemeriksaan yang sering untuk pengukuran yang akurat.
  • Menyelidiki lalu lintas dapat menutupi lalu lintas yang sebenarnya.
Metode & alat penerapan

Instrumentasi klien

Metode instrumentasi klien melibatkan penambahan fitur kemampuan observasi ke klien yang berinteraksi dengan pengguna, dan mencatat kembali peristiwa ke infrastruktur penyaluran Anda yang melacak SLI.

Instrumentasi klien Detail
Kelebihan
  • Memberikan ukuran pengalaman pengguna yang paling akurat.
  • Dapat mengukur keandalan pihak ketiga, misalnya, CDN atau penyedia pembayaran.
Kekurangan
  • Penyerapan log klien dan latensi pemrosesan membuat SLI ini tidak cocok untuk memicu respons operasional.
  • Pengukuran SLI berisi sejumlah faktor yang sangat bervariasi yang kemungkinan berada di luar kontrol langsung.
  • Membangun instrumentasi ke klien dapat melibatkan banyak pekerjaan teknik.
Metode & alat penerapan

Pilih metode pengukuran

Setelah Anda memutuskan apa dan bagaimana mengukur SLO, langkah Anda selanjutnya adalah memilih metode pengukuran yang paling sesuai dengan pengalaman pelanggan terkait layanan Anda, dan menuntut upaya paling sedikit dari pihak Anda. Untuk mencapai ideal ini, Anda mungkin perlu menggunakan kombinasi metode dalam tabel sebelumnya. Berikut adalah pendekatan yang disarankan yang dapat Anda terapkan dari waktu ke waktu, yang dicantumkan dalam urutan peningkatan upaya:

  • Menggunakan ekspor server aplikasi dan metrik infrastruktur. Biasanya, Anda dapat langsung mengakses metrik ini, dan metrik tersebut akan memberikan nilai dengan cepat. Beberapa alat APM menyertakan alat SLO bawaan.
  • Gunakan instrumentasi klien. Karena sistem lama biasanya tidak memiliki instrumentasi klien pengguna akhir bawaan, penyiapan instrumentasi mungkin memerlukan investasi yang signifikan. Namun, jika menggunakan suite APM atau framework frontend yang menyediakan instrumentasi klien, Anda dapat dengan cepat mendapatkan insight tentang kepuasan pelanggan.
  • Menggunakan pemrosesan log. Jika Anda tidak dapat menerapkan ekspor server atau instrumentasi klien (butir sebelumnya), tetapi log masih ada, pemrosesan log mungkin merupakan pendekatan terbaik Anda. Metode lainnya adalah menggabungkan ekspor dan pemrosesan log. Gunakan ekspor sebagai sumber langsung untuk beberapa SLI (seperti ketersediaan langsung) dan pemrosesan log untuk sinyal jangka panjang (seperti pemberitahuan pengeluaran lambat yang dibahas dalam panduan SLO dan Pemberitahuan).
  • Menerapkan pengujian sintetis. Setelah memiliki pemahaman dasar tentang cara pelanggan menggunakan layanan, Anda menguji layanan. Misalnya, Anda dapat melakukan seed akun pengujian dengan data yang diketahui berkualitas dan membuat kueri untuk akun tersebut. Pendekatan ini dapat membantu menandai mode kegagalan yang sulit diamati, seperti untuk layanan dengan traffic rendah.

Apa langkah selanjutnya?