• August 8, 2025

Membuat Alarm Berdasarkan SLO di Amazon Search dengan CloudWatch Application Signals – Bagian 1

Teori: Penerapan Konsep SLO pada Amazon Product Search

Dalam seri blog ini, tim Amazon Product Search akan berbagi bagaimana kami memantau sistem penting menggunakan Service Level Objectives (SLO), serta perjalanan kami bermigrasi dari sistem monitoring internal ke Amazon CloudWatch Application Signals.

Amazon Product Search adalah sistem besar yang terdiri dari lebih dari 40 layanan backend dan melayani puluhan ribu permintaan setiap detik.

Apa yang Akan Dibahas di Bagian 1?

  • Keterbatasan monitoring tradisional

  • Dasar-dasar SLO dan konsep burn rate

  • Kapan sebaiknya menggunakan SLO untuk monitoring

  • Keputusan penting dalam merancang sistem monitoring berbasis SLO

Monitoring Tradisional Tidak Lagi Cukup

Apa Tujuan Monitoring di Amazon Search?

Kami ingin membuat alarm yang:

  • Memberi tahu engineer hanya saat ada kejadian penting

  • Tidak terlalu sering memunculkan alarm yang tidak penting

  • Bisa menangkap insiden yang benar-benar berdampak

Contoh masalah dengan pendekatan lama:

  • Alarm palsu: Kadang terjadi lonjakan error sesaat di tengah malam karena bot, tapi sistem pulih sendiri. Tidak perlu membangunkan engineer untuk hal ini.

  • Degradasi diam-diam: Kadang layanan makin lambat sedikit demi sedikit selama beberapa minggu. Masalah seperti ini tidak langsung terdeteksi oleh alarm biasa.

Itulah sebabnya kami mulai mempertimbangkan pendekatan berbasis SLO.

Mengenal SLO (Service Level Objectives)

Istilah Penting:

  • SLI (Service Level Indicator): Metode untuk mengukur apakah layanan bekerja dengan baik (contoh: waktu respon)

  • SLO (Service Level Objective): Target performa layanan, seperti “99,9% permintaan harus direspons di bawah 1 detik dalam 28 hari”

  • SLA (Service Level Agreement): Janji formal ke pelanggan soal performa layanan

  • Error Budget: Toleransi yang bisa diterima jika performa tidak 100% sempurna (misalnya, 0.1% error masih bisa ditoleransi)

Contoh Konversi SLO:

  • Bahasa manusia: 99,9% permintaan harus selesai di bawah 1000 ms dalam 28 hari

  • Variabel:

    • SLI: Latensi

    • Threshold: 1000 ms

    • Interval: 28 hari

    • Target: 99,9%

Bagaimana Cara Membuat Alarm Berdasarkan SLO?

Konsep Burn Rate

Burn rate bisa diibaratkan seperti “speedometer” untuk error budget. Ia menunjukkan seberapa cepat kita “menghabiskan” jatah error dibanding target SLO.

  • Burn rate = 1 → Penggunaan error budget pas sesuai rencana

  • Burn rate > 1 → Error budget habis lebih cepat dari target

  • Burn rate < 1 → Masih aman, penggunaan error budget lambat

Kapan Burn Rate Lebih Baik dari Threshold?

Kasus 1: Lonjakan sesaat

  • Threshold-based: Langsung munculkan alarm walau cuma 1 spike (tidak perlu diproses jam 3 pagi)

  • Burn rate: Tidak akan munculkan alarm kecuali lonjakan cukup besar untuk menghabiskan error budget secara signifikan

Kasus 2: Spike berkala

  • Threshold-based: Sering terlewat karena spike hanya sesaat dan tidak berturut-turut

  • Burn rate: Bisa menangkap pola berulang karena memperhitungkan total konsumsi error budget

Kasus 3: Gangguan besar

  • Threshold-based: Bisa terlambat karena butuh banyak data poin dulu baru alarm menyala

  • Burn rate: Langsung deteksi dan munculkan alarm saat error budget habis dengan cepat

Pendekatan Burn Rate Multi-Window

Kenapa Multi-Window?

Jika kita hanya pakai 1 jendela waktu (window):

  • Window pendek → terlalu sensitif, banyak false alarm

  • Window panjang → tidak responsif, alarm bisa terlambat kembali ke normal

Solusi: Gunakan Dua Window:

  • Window Panjang (misal 1 jam): Memastikan kita tetap patuh terhadap SLO

  • Window Pendek (misal 5 menit): Membuat alarm bisa cepat kembali ke normal dan mendeteksi masalah baru lebih cepat

Contoh Pengaturan:

  • Alarm jika 2% error budget habis dalam 1 jam

  • Alarm jika 5% error budget habis dalam 6 jam

  • Tiket (bukan alarm) jika 10% error budget habis dalam 3 hari

Perbedaan Perhitungan Error Budget: Period-Based vs Request-Based

Period-Based SLO

  • Error budget hanya berkurang

  • Jika habis, harus berhenti rilis fitur dan fokus perbaikan layanan

Request-Based SLO

  • Error budget bisa naik turun

  • Bisa “mengisi ulang” error budget kalau performa layanan membaik

  • Bisa kehabisan error budget lebih dari satu kali dalam periode yang sama

Manfaat Monitoring Berbasis SLO

Dengan menerapkan monitoring SLO:

  • Lebih fokus pada apa yang penting untuk pelanggan

  • Bisa bedakan antara alarm yang benar-benar penting dan yang bisa ditunda

  • Membantu tim on-call lebih fokus, tidak kewalahan oleh alarm yang tidak relevan

Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman.
Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!