Elasticity vs Scalability #

Dalam merancang dan mengelola infrastruktur di era modern, kita sering kali mendengar istilah scalability dan elasticity digunakan secara bergantian. Seolah-olah kedua kata ini adalah sinonim yang merujuk pada hal yang sama: kemampuan sistem untuk menangani beban aplikasi yang besar. Padahal, secara arsitektur dan operasional, kedua konsep ini memiliki perbedaan yang sangat mendasar. Mengacaukan pemahaman keduanya bukan sekadar kesalahan semantik di atas kertas, melainkan sebuah risiko besar yang dapat menyebabkan salah desain arsitektur, pemborosan anggaran yang signifikan, atau bahkan kegagalan sistem total saat menghadapi lonjakan trafik di dunia nyata. Artikel ini akan membahas secara mendalam perbedaan antara scalability dan elasticity, prasyarat arsitektur untuk masing-masing pendekatan, mekanisme kerjanya di cloud, serta analisis biaya riil dari penerapan keduanya.

Definisi dan Filosofi Dasar #

Untuk memahami perbedaan secara presisi, kita harus melihat akar filosofi dan definisi teknis dari masing-masing konsep terlebih dahulu.

Scalability adalah kemampuan bawaan dari suatu sistem (baik hardware, software, maupun database) untuk menangani peningkatan beban kerja (workload) yang semakin besar dengan cara menambahkan sumber daya (resource). Fokus utama dari scalability adalah kapasitas maksimum. Sistem yang scalable berarti sistem yang tidak akan “pecah” atau mengalami degradasi performa yang fatal ketika beban kerjanya dilipatgandakan, asalkan kita menambahkan resource yang sesuai. Namun, penambahan resource pada sistem yang scalable umumnya bersifat manual, direncanakan terlebih dahulu, dan sering kali berjalan satu arah (meningkat ke atas).

Elasticity adalah kemampuan suatu sistem untuk secara dinamis dan otomatis menyesuaikan alokasi resource-nya agar sesuai dengan kebutuhan beban kerja aktual secara real-time. Fokus utama dari elasticity adalah adaptasi otomatis dua arah (elastic scaling). Sistem yang elastic akan menambah kapasitasnya secara instan ketika trafik melonjak, dan segera mengurangi kapasitasnya kembali ketika trafik mereda. Proses ini berjalan secara otomatis tanpa campur tangan manusia (zero-touch operations), memastikan bahwa resource yang aktif selalu selaras dengan kurva permintaan pengguna.

Analogi Jalan Tol dan Jalur Darurat:

  Scalability = Kapasitas Total Jalan Tol
      Jika jalan tol dengan 2 jalur sudah tidak mampu menampung volume kendaraan harian, 
      kita me-scale jalan tersebut menjadi 4 jalur. Ini membutuhkan perencanaan, 
      pembangunan fisik yang lama, dan kapasitas baru ini akan permanen ada di sana.

  Elasticity = Sistem Kontraflow atau Jalur Darurat Dinamis
      Ketika terjadi kemacetan parah di jam pulang kerja, sistem secara otomatis mengaktifkan 
      jalur kontraflow atau membuka jalur darurat untuk mempercepat arus kendaraan. Setelah 
      jam sibuk lewat dan jalan kembali sepi, jalur tambahan tersebut langsung ditutup kembali.

Tabel berikut menyajikan perbandingan parameter kunci antara scalability dan elasticity:

Diagram di bawah ini menggambarkan bagaimana kedua konsep tersebut merespons fluktuasi beban trafik secara konseptual:

flowchart TD
    subgraph Scalability["Scalability (Kapasitas Maksimal Jangka Panjang)"]
        direction TB
        S1["Trafik Meningkat Lambat"] --> S2["Administrator Menambah Server Baru (Manual/Scheduled)"]
        S2 --> S3["Kapasitas Sistem Bertambah Terencana"]
        S3 --> S4["Sistem Stabil pada Level Kapasitas Baru"]
    end
    
    subgraph Elasticity["Elasticity (Adaptasi Otomatis Real-Time)"]
        direction TB
        E1["Trafik Melonjak Tiba-tiba"] --> E2["Sistem Auto-Scaling Mendeteksi Spike CPU > 70%"]
        E2 --> E3["Instans Baru Dideploy Otomatis dalam Hitungan Detik"]
        E3 --> E4["Trafik Mereda"] --> E5["Instans Dikurangi Otomatis (Scale-In)"]
    end

Scalability: Meningkatkan Kapasitas Sistem #

Di dalam arsitektur sistem, ketika kita memutuskan untuk meningkatkan kapasitas, kita memiliki dua pilihan jalan utama: Vertical Scaling (Scale Up) atau Horizontal Scaling (Scale Out). Pemilihan metode ini sangat menentukan apakah sistem kita nantinya bisa diintegrasikan dengan fitur elastisitas otomatis atau tidak.

Vertical Scaling (Scale Up / Scale Down) #

Vertical scaling adalah metode meningkatkan kapasitas sistem dengan cara menambah daya komputasi pada satu node atau server yang sama. Kita mengganti server yang ada dengan server yang memiliki spesifikasi lebih tinggi, misalnya meningkatkan jumlah vCPU dari 4 menjadi 16, RAM dari 8 GB menjadi 64 GB, atau meningkatkan performa storage (IOPS).

flowchart LR
    subgraph VU["Vertical Scaling (Scale Up)"]
        direction LR
        NodeSmall["Node Kecil<br>2 vCPU, 4GB RAM"] -->|"Upgrade Hardware"| NodeLarge["Node Besar<br>16 vCPU, 32GB RAM"]
    end

Keuntungan Vertical Scaling: #

1. Tidak Ada Perubahan Kode (Zero Code Changes): Aplikasi monolitik tradisional dapat langsung merasakan peningkatan performa tanpa perlu ditulis ulang. Aplikasi tetap berjalan di satu lingkungan runtime yang sama.
2. Kemudahan Manajemen: Kita hanya mengelola satu sistem operasi, satu alamat IP, dan satu database engine, sehingga overhead administrasi sangat minimal.

Kelemahan Vertical Scaling: #

1. Batas Maksimum Fisik (Hardware Ceiling): Ada batas mutlak di mana kita tidak bisa membeli server yang lebih besar lagi karena keterbatasan teknologi manufaktur chip.
2. Kebutuhan Downtime: Pada sebagian besar platform cloud, mengubah ukuran virtual machine (misal, dari tipe t3.medium ke m5.xlarge) memerlukan proses restart server, yang berarti terjadi downtime layanan selama beberapa menit.
3. Single Point of Failure (SPOF): Meskipun server kita sangat besar dan mahal, jika sistem operasi mengalami kernel panic atau terjadi kerusakan hardware pada hypervisor, seluruh aplikasi kita akan mati total.
4. Biaya Eksponensial: Harga server kelas atas di cloud sering kali naik secara eksponensial, bukan linear. Server dengan spesifikasi dua kali lipat sering kali berbiaya tiga hingga empat kali lipat lebih mahal.

Horizontal Scaling (Scale Out / Scale In) #

Horizontal scaling adalah metode meningkatkan kapasitas sistem dengan cara menambah jumlah node atau server yang bekerja secara paralel di bawah satu kesatuan sistem. Alih-alih membuat satu server menjadi raksasa, kita menambahkan server-server berukuran sedang yang identik untuk membagi beban kerja.

flowchart TD
    subgraph HU["Horizontal Scaling (Scale Out)"]
        direction TB
        LB["Load Balancer"] --> Node1["Node 1 (Web App)"]
        LB --> Node2["Node 2 (Web App)"]
        LB --> Node3["Node 3 (Web App)"]
    end

Keuntungan Horizontal Scaling: #

1. Tidak Ada Batasan Kapasitas (Infinite Ceiling): Secara teoritis, kita bisa menambahkan server tanpa batas (puluhan, ratusan, bahkan ribuan instans) untuk menangani trafik skala global.
2. High Availability Terintegrasi: Jika salah satu node mengalami kegagalan, node lainnya tetap aktif melayani trafik. Load balancer akan secara otomatis mendeteksi node yang rusak dan mengalihkan trafik ke node yang sehat.
3. Biaya Linear: Menambahkan 10 server kecil jauh lebih murah dan fleksibel dibandingkan menyewa satu server raksasa yang setara dengan total spesifikasi 10 server tersebut.
4. Pintu Masuk Menuju Elasticity: Horizontal scaling adalah prasyarat mutlak jika kita ingin menerapkan auto-scaling dinamis di cloud.

Kelemahan Horizontal Scaling: #

1. Kompleksitas Kode dan Arsitektur: Aplikasi harus dirancang agar bersifat stateless (tidak menyimpan state pengguna di dalam server lokal).
2. Overhead Jaringan dan Sinkronisasi: Menghubungkan banyak node memerlukan infrastruktur load balancer, penanganan latensi jaringan antar node, dan manajemen konsistensi data yang lebih kompleks.

Tantangan Skalabilitas pada Level Database #

Meskipun server aplikasi web sangat mudah di-scale secara horizontal, database relasional (seperti PostgreSQL atau MySQL) adalah komponen yang paling sulit untuk di-scale secara horizontal karena masalah konsistensi data (ACID properties).

Untuk mengatasi hal ini, kita biasanya menerapkan strategi berikut:

1. Read Replicas: Memisahkan operasi baca (read) dan tulis (write). Server primary menangani semua operasi tulis, sedangkan satu atau beberapa server replica melakukan replikasi data secara asinkron dari primary dan menangani operasi baca dari pengguna.
2. Sharding (Database Partitioning): Memecah data tabel besar ke dalam beberapa database server fisik yang berbeda berdasarkan kunci sharding (misalnya, membagi data pengguna berdasarkan ID genap dan ganjil).

Berikut adalah contoh implementasi pola koneksi database di level kode aplikasi Go yang mendukung pemisahan Read/Write untuk skalabilitas (menggunakan DB Pool):

package main

import (
	"database/sql"
	"fmt"
	"log"
	_ "github.com/lib/pq"
)

type DBCluster struct {
	Primary *sql.DB // Untuk operasi WRITE (Insert, Update, Delete)
	Replica *sql.DB // Untuk operasi READ (Select)
}

func NewDBCluster(primaryDSN, replicaDSN string) (*DBCluster, error) {
	primary, err := sql.Open("postgres", primaryDSN)
	if err != nil {
		return nil, fmt.Errorf("gagal membuka koneksi primary: %w", err)
	}

	replica, err := sql.Open("postgres", replicaDSN)
	if err != nil {
		return nil, fmt.Errorf("gagal membuka koneksi replica: %w", err)
	}

	// ✓ BENAR: Selalu atur batas koneksi maksimum (Connection Pool)
	primary.SetMaxOpenConns(25)
	replica.SetMaxOpenConns(100) // Replica biasanya melayani koneksi lebih banyak

	return &DBCluster{Primary: primary, Replica: replica}, nil
}

// GetUserData mengambil data user dari Read Replica (Skalabilitas BACA)
func (cluster *DBCluster) GetUserData(userID int) (string, error) {
	var username string
	query := "SELECT username FROM users WHERE id = $1"
	
	// Query dieksekusi ke REPLICA
	err := cluster.Replica.QueryRow(query, userID).Scan(&username)
	if err != nil {
		return "", err
	}
	return username, nil
}

// CreateUser menyimpan data user ke Primary Database (Skalabilitas TULIS)
func (cluster *DBCluster) CreateUser(username string) (int, error) {
	var lastInsertID int
	query := "INSERT INTO users(username) VALUES($1) RETURNING id"
	
	// Query dieksekusi ke PRIMARY
	err := cluster.Primary.QueryRow(query, username).Scan(&lastInsertID)
	if err != nil {
		return 0, err
	}
	return lastInsertID, nil
}

Elasticity: Otomatisasi Dua Arah di Cloud #

Elasticity adalah otomasi tingkat lanjut yang memanfaatkan horizontal scaling untuk menyesuaikan kapasitas secara dinamis tanpa intervensi manual. Untuk memahami bagaimana elasticity bekerja secara efektif di cloud (seperti AWS Auto Scaling Groups atau Kubernetes Horizontal Pod Autoscaler), kita harus memahami komponen-komponen penyusunnya.

Jenis-Jenis Kebijakan Scaling (Scaling Policies) #

Di platform cloud, kita tidak hanya memiliki satu cara untuk melakukan auto-scaling. Ada beberapa opsi kebijakan yang bisa kita pilih sesuai dengan karakteristik workload aplikasi kita:

1. Target Tracking Scaling: Kebijakan ini bekerja seperti termostat ruangan. Kita menentukan target metrik tertentu (misalnya, rata-rata utilitas CPU di angka 70%). Jika utilitas CPU naik menjadi 80%, sistem auto-scaling akan menambahkan instans baru agar utilitas turun kembali ke 70%. Jika CPU turun ke 40%, instans akan dikurangi untuk menaikkan kembali utilitas ke angka target.
2. Step Scaling / Simple Scaling: Kebijakan ini merespons alarm metrik secara bertahap. Contoh:
   • Jika CPU > 70%, tambahkan 2 instans.
   • Jika CPU > 85%, tambahkan 4 instans.
   • Jika CPU < 35%, kurangi 2 instans.
3. Scheduled Scaling: Digunakan untuk fluktuasi beban yang sangat mudah diprediksi polanya. Misalnya, sebuah aplikasi absensi online karyawan kantor pasti akan mengalami lonjakan trafik setiap hari Senin pagi pukul 07.30 - 08.30. Kita bisa menjadwalkan penambahan server pada pukul 07.00 dan menguranginya kembali pada pukul 09.00.
4. Predictive Scaling: Fitur modern yang menggunakan algoritma Machine Learning untuk menganalisis data historis trafik aplikasi selama beberapa minggu ke belakang. Sistem akan memprediksi kapan lonjakan trafik berikutnya terjadi dan melakukan scaling lebih awal (proaktif), bukan setelah lonjakan terjadi (reaktif).

Siklus Hidup Auto-Scaling dan Konsep Cooldown Period #

Salah satu parameter paling kritis namun sering diabaikan dalam konfigurasi auto-scaling adalah Cooldown Period (Waktu Tenang).

Ketika sistem mendeteksi lonjakan CPU dan memutuskan untuk melakukan scale out dengan menambah satu instans baru, instans tersebut membutuhkan waktu untuk booting, mengunduh kode terbaru, menjalankan inisialisasi aplikasi, dan akhirnya siap melayani trafik. Selama proses inisialisasi ini berjalan, utilitas CPU pada server lama mungkin masih tetap tinggi karena trafik belum terbagi.

Tanpa adanya Cooldown Period, sistem auto-scaling akan mendeteksi bahwa CPU masih tinggi pada detik berikutnya dan akan terus-menerus memicu penambahan server baru secara berlebihan (flapping/oscillation).

Cooldown Period adalah durasi waktu tunggu setelah aktivitas scaling terjadi, 
di mana sistem auto-scaling membekukan sementara kalkulasi alarm metrik 
untuk memberikan waktu bagi instans baru agar benar-benar aktif dan stabil.

Berikut adalah diagram alir siklus hidup proses auto-scaling yang aman dengan menerapkan Cooldown Period dan Connection Draining:

flowchart TD
    Start["Monitor Metrik (CloudWatch/Prometheus)"] --> Check{"Apakah Metrik Melewati Batas?"}
    Check -- "CPU > 75% (3 Periode)" --> ScaleOut["Trigger Scale Out"]
    Check -- "CPU < 30% (5 Periode)" --> ScaleIn["Trigger Scale In"]
    Check -- Normal --> Start
    
    ScaleOut --> AddInstance["Tambah Instans Baru"]
    AddInstance --> RegisterLB["Daftarkan ke Load Balancer"]
    RegisterLB --> CooldownOut["Terapkan Cooldown Period (misal: 300 detik)"]
    CooldownOut --> Start
    
    ScaleIn --> DeregisterLB["Hapus dari Load Balancer (Connection Draining)"]
    DeregisterLB --> TerminateInstance["Matikan Instans"]
    TerminateInstance --> CooldownIn["Terapkan Cooldown Period (misal: 600 detik)"]
    CooldownIn --> Start

Prasyarat Arsitektur untuk Sistem yang Elastis #

Kita tidak bisa begitu saja menyalakan fitur auto-scaling di cloud dan berharap sistem kita langsung menjadi elastis secara ajaib. Ada harga teknis yang harus dibayar di level kode aplikasi dan desain arsitektur agar sistem siap menjadi elastis.

1. Stateless Architecture (Ketiadaan State) #

Ini adalah syarat paling mendasar. Server aplikasi tidak boleh menyimpan data sesi (session state), file unggahan pengguna, atau state penting lainnya di dalam penyimpanan lokal (RAM atau harddisk lokal server).

Jika server bersifat stateful, maka ketika user melakukan login di Server A, data login disimpan di RAM Server A. Saat auto-scaling menambahkan Server B dan load balancer mengarahkan request berikutnya dari user yang sama ke Server B, user tersebut akan secara otomatis ter-logout karena Server B tidak memiliki data sesinya.

// ANTI-PATTERN: Menyimpan sesi user di memori lokal server (Stateful)
// ✗ Jika server di-scale out atau di-terminate, sesi user akan hilang.
var sessions = make(map[string]*UserSession)

func LoginHandler(w http.ResponseWriter, r *http.Request) {
    sessionID := generateSessionID()
    sessions[sessionID] = &UserSession{UserID: 123} // Tersimpan di RAM lokal server
    setSessionCookie(w, sessionID)
}

// BENAR: Menyimpan sesi user di Redis cluster eksternal (Stateless)
// ✓ Setiap node server dapat mengambil sesi dari database terpusat yang sama.
func LoginHandler(w http.ResponseWriter, r *http.Request) {
    sessionID := generateSessionID()
    err := redisClient.Set(ctx, sessionID, "123", time.Hour).Err() // Tersimpan di Redis
    if err != nil {
        http.Error(w, "Gagal menyimpan sesi", http.StatusInternalServerError)
        return
    }
    setSessionCookie(w, sessionID)
}

2. Kecepatan Bootstrapping & Startup Time #

Elastisitas sangat bergantung pada kecepatan sistem merespons lonjakan trafik. Jika VM kita membutuhkan waktu 10 menit dari proses pembuatan hingga siap melayani trafik (akibat skrip inisialisasi yang terlalu panjang, mengunduh paket dependensi saat booting, atau ukuran image OS yang terlalu besar), maka auto-scaling kita akan gagal mengantisipasi lonjakan trafik. Pengguna akan mengalami error timeout sebelum server baru siap melayani mereka.

Untuk mengoptimalkan hal ini, kita harus:

• Menggunakan teknologi kontainerisasi (seperti Docker di Kubernetes) karena kontainer dapat aktif dalam hitungan detik, jauh lebih cepat dibanding Virtual Machine tradisional yang butuh hitungan menit.
• Membuat Golden Image (misalnya Amazon Machine Image/AMI khusus) yang sudah berisi seluruh dependensi terinstal, sehingga server tidak perlu mengunduh apa pun saat menyala pertama kali.
• Menghindari cold start pada serverless dengan meminimalkan ukuran paket aplikasi.

3. Graceful Shutdown & Connection Draining #

Dalam proses penyusutan kapasitas (scale in), sistem auto-scaling akan mematikan instans yang dianggap berlebih. Jika server dimatikan secara mendadak saat sedang memproses request transaksi pembayaran pengguna, maka transaksi tersebut akan gagal di tengah jalan dan merusak integritas data database.

Aplikasi kita harus mampu menangani sinyal sistem seperti SIGTERM dengan cara menghentikan penerimaan request baru dari Load Balancer, menyelesaikan seluruh proses request yang sedang berjalan (in-flight requests), menutup koneksi ke database dengan aman, dan baru kemudian mengizinkan server dimatikan. Di sisi Load Balancer, fitur ini dikenal dengan istilah Connection Draining atau Deregistration Delay.

4. Health Checks yang Akurat #

Load balancer harus mengetahui secara pasti apakah suatu instans siap menerima trafik (readiness) dan apakah instans tersebut masih sehat untuk terus melayani trafik (liveness). Jika konfigurasi health check kita terlalu longgar, trafik akan tetap diarahkan ke instans yang sedang hang atau mengalami kegagalan internal, menyebabkan error 502/504 Bad Gateway pada sisi pengguna akhir.

Analisis Perhitungan Matematis Dampak Biaya #

Mari kita lakukan simulasi perhitungan biaya secara riil untuk membandingkan tiga pendekatan manajemen kapasitas: Over-provisioning (Kapasitas Tetap Puncak), Under-provisioning (Kapasitas Rata-Rata Tetap dengan Risiko Down), dan Elastic Scaling (Adaptasi Dinamis).

Skenario Workload Perusahaan E-Commerce: #

• Trafik Puncak (Peak Hours): 08.00 - 12.00 dan 18.00 - 22.00 (Total 8 jam sehari) -> Membutuhkan 20 instans untuk menjaga performa.
• Trafik Normal (Off-Peak Hours): Sisa 16 jam lainnya -> Hanya membutuhkan 5 instans untuk melayani trafik.
• Tipe Instans Cloud: AWS c5.large (Biaya sewa: $0.085 per jam).
• Durasi Simulasi: 1 Bulan (30 Hari).

Pendekatan 1: Over-Provisioning (Kapasitas Tetap Puncak) #

Perusahaan memilih untuk tidak mengambil risiko performa sama sekali. Mereka menyewa 20 instans secara konstan selama 24 jam sehari, 7 hari seminggu, untuk menjamin sistem selalu siap menghadapi trafik puncak kapan saja.

$$\text{Total Jam Instans per Hari} = 20 \text{ instans} \times 24 \text{ jam} = 480 \text{ instans-jam}$$ $$\text{Total Jam Instans per Bulan} = 480 \text{ instans-jam} \times 30 \text{ hari} = 14.400 \text{ instans-jam}$$ $$\text{Total Biaya Bulanan} = 14.400 \text{ instans-jam} \times $0.085 = \mathbf{$1.224}$$

Analisis: Sistem sangat aman dari risiko crash akibat trafik. Namun, selama 16 jam per hari ketika trafik sepi, ada 15 server yang menganggur tapi tetap harus dibayar. Efisiensi penggunaan resource sangat buruk.

Pendekatan 2: Under-Provisioning (Kapasitas Rata-Rata Tetap) #

Perusahaan ingin menghemat biaya dengan menetapkan kapasitas server secara konstan di angka rata-rata kebutuhan, yaitu 10 instans sepanjang waktu.

$$\text{Total Jam Instans per Hari} = 10 \text{ instans} \times 24 \text{ jam} = 240 \text{ instans-jam}$$ $$\text{Total Jam Instans per Bulan} = 240 \text{ instans-jam} \times 30 \text{ hari} = 7.200 \text{ instans-jam}$$ $$\text{Total Biaya Bulanan} = 7.200 \text{ instans-jam} \times $0.085 = \mathbf{$612}$$

Analisis: Biaya berhasil ditekan hingga 50%. Namun, selama 8 jam trafik puncak harian, 10 server tersebut tidak mampu menangani beban kerja yang membutuhkan 20 server. Aplikasi mengalami degradasi performa parah, server crash, transaksi pembayaran gagal, dan perusahaan kehilangan potensi pendapatan puluhan ribu dolar akibat kekecewaan pelanggan.

Pendekatan 3: Elastic Scaling (Adaptasi Dinamis) #

Perusahaan mengonfigurasi fitur auto-scaling secara elastis. Selama 8 jam trafik puncak, kapasitas otomatis naik menjadi 20 instans. Selama 16 jam trafik sepi, kapasitas otomatis menyusut kembali menjadi 5 instans.

$$\text{Jam Instans saat Puncak (Peak Hours)} = 20 \text{ instans} \times 8 \text{ jam} = 160 \text{ instans-jam/hari}$$ $$\text{Jam Instans saat Sepi (Off-Peak Hours)} = 5 \text{ instans} \times 16 \text{ jam} = 80 \text{ instans-jam/hari}$$ $$\text{Total Jam Instans per Hari} = 160 + 80 = 240 \text{ instans-jam/hari}$$ $$\text{Total Jam Instans per Bulan} = 240 \text{ instans-jam} \times 30 \text{ hari} = 7.200 \text{ instans-jam}$$ $$\text{Total Biaya Bulanan} = 7.200 \text{ instans-jam} \times $0.085 = \mathbf{$612}$$

$$\text{Persentase Penghematan Biaya dibanding Over-Provisioning} = \frac{$1.224 - $612}{$1.224} \times 100% = \mathbf{50%}$$

Analisis: Pendekatan elastis menghasilkan biaya yang sama persis dengan pendekatan Under-Provisioning ($612), namun tanpa risiko downtime layanan sama sekali karena kapasitas server langsung menyesuaikan diri menjadi 20 server secara instan saat trafik puncak tiba. Inilah kekuatan nyata dari konsep elasticity di cloud.

Kapan Memilih Scalability Saja, dan Kapan Butuh Elasticity? #

Meskipun elasticity terdengar sangat menggiurkan karena efisiensi biayanya, tidak semua sistem di dunia nyata harus dibuat menjadi elastis. Memaksakan penerapan elastisitas otomatis pada aplikasi yang tidak siap justru akan menjadi bumerang yang menambah kompleksitas tanpa memberikan manfaat nyata.

Kita dapat menggunakan panduan checklist kondisi berikut untuk menentukan pilihan pendekatan yang paling tepat:

BUTUH ELASTICITY jika:
  ✓ Pola trafik aplikasi kita sangat fluktuatif dan sulit diprediksi (misal: e-commerce, media sosial, portal berita viral).
  ✓ Fluktuasi beban kerja terjadi dalam skala waktu yang singkat (menit ke jam, bukan bulan ke tahun).
  ✓ Aplikasi bersifat stateless atau sangat mudah dipisahkan dari layer datanya.
  ✓ Biaya infrastruktur menjadi prioritas utama efisiensi keuangan tim engineering.

CUKUP SCALABILITY (Tanpa Auto-Scaling Otomatis) jika:
  ✗ Pola beban kerja sistem sangat datar, stabil, dan mudah diprediksi sepanjang waktu (misal: core API ERP internal perusahaan, server database log internal).
  ✗ Waktu startup aplikasi kita sangat lambat (> 10-15 menit) sehingga auto-scaling tidak akan mampu merespons lonjakan trafik secara real-time.
  ✗ Aplikasi bersifat stateful berat yang sangat berisiko rusak jika instans server dimatikan secara acak oleh auto-scaler.
  ✗ Sistem berjalan di atas infrastruktur fisik lokal (On-Premise) yang kapasitas hardware fisiknya terbatas dan tidak memiliki API virtualisasi instan seperti cloud.

Ringkasan #

• Scalability fokus pada batas kapasitas maksimum, sedangkan Elasticity fokus pada adaptasi otomatis dua arah untuk menyesuaikan kapasitas secara dinamis terhadap beban kerja aktual secara real-time.
• Horizontal scaling (scale out/in) adalah prasyarat mutlak untuk elasticity, sedangkan vertical scaling (scale up/down) umumnya membutuhkan restart server fisik/virtual yang memicu downtime.
• Stateless architecture adalah hukum wajib bagi sistem yang elastis agar user session tidak terputus saat trafik berpindah-pindah di antara instans server yang dinamis.
• Cooldown period sangat penting dikonfigurasi secara tepat pada auto-scaling untuk mencegah instabilitas sistem akibat penambahan server baru secara berlebihan (flapping).
• Kecepatan startup aplikasi menentukan efektivitas elastisitas. Gunakan kontainer (Docker) dan optimasikan proses booting agar server siap melayani request dalam hitungan detik.
• Elasticity menghasilkan penghematan biaya operasional yang sangat masif di cloud (mencapai 50% atau lebih) tanpa mengorbankan tingkat ketersediaan (availability) aplikasi saat trafik melonjak.

← Sebelumnya: Shared Responsibility   Berikutnya: Global Infrastructure →