Praktik terbaik

Panduan ini membahas pola, prinsip, dan strategi yang terbukti dalam ribuan penerapan.

Prinsip perancangan

1. Mulai sederhana dan tumbuh bertahap

Jangan merancang terlalu rumit sejak awal. Mulailah dengan rancangan paling sederhana yang memenuhi kebutuhan saat ini, lalu kembangkan.

Baik: satu basis data, satu server aplikasi, dan penyeimbang beban. Buruk: layanan mikro di 5 wilayah dengan penyimpanan berbasis peristiwa sejak hari pertama.

2. Rancang untuk menghadapi kegagalan

Anggap komponen dapat gagal. Siapkan redundansi dan penurunan fungsi yang terkendali.

Baik: basis data Multi-AZ, replika alih gagal, dan pemutus sirkuit. Buruk: titik kegagalan tunggal di bagian mana pun.

3. Ukur sebelum mengoptimalkan

Jangan mengoptimalkan tanpa data. Gunakan analisis dan pemantauan.

Baik: jalankan analisis skalabilitas untuk menemukan hambatan nyata. Buruk: “Basis data mungkin lambat, tambahkan cache saja.”

4. Pahami kelebihan dan kekurangan

Setiap keputusan memiliki konsekuensi. Dokumentasikan.

Baik: “Kami memilih monolit agar cepat diluncurkan, lalu beralih ke layanan mikro pada 100k pengguna.” Buruk: “Tambahkan layanan mikro agar dapat diskalakan,” tanpa memahami kerumitannya.

5. Otomatiskan semuanya

Proses manual tidak mampu mengikuti pertumbuhan. Otomatiskan penerapan, pemantauan, dan penskalaan.

Baik: infrastruktur sebagai kode dengan Terraform, grup penskalaan otomatis, dan pipeline CI/CD. Buruk: penyediaan server dan keputusan kapasitas secara manual.

Pola arsitektur umum

Pola: aplikasi web monolitik

Kapan digunakan: MVP, satu tim, dan <100k pengguna.

Topologi:

Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

Kelebihan:

• Pengembangan dan penelusuran kesalahan sederhana.
• Penerapan dan penskalaan horizontal mudah.
• Beban operasional rendah.

Kekurangan:

• Basis kode besar sulit dipelihara.
• Basis data bersama membatasi kapasitas.
• Terikat pada bahasa dan kerangka kerja.

Kapan dikembangkan: ketika basis data menjadi hambatan pada 50k+ pengguna.

Pola: arsitektur layanan mikro

Kapan digunakan: tim besar, >100k pengguna, dan beberapa layanan.

Topologi:

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

Kelebihan:

• Kapasitas setiap layanan disesuaikan mandiri.
• Tim dapat bekerja otonom.
• Pilihan teknologi dan bahasa fleksibel.
• Penerapan tiap layanan mudah.

Kekurangan:

• Operasional lebih rumit.
• Tantangan terdistribusi: konsistensi eventual dan penelusuran kesalahan.
• Latensi jaringan antarlayanan.
• Membutuhkan praktik DevOps matang.

Kapan digunakan: saat monolit menjadi hambatan DAN susunan tim mampu mendukungnya.

Pola: tanpa server, FaaS

Kapan digunakan: beban berbasis peristiwa, permintaan berubah, dan perhatian pada biaya.

Topologi:

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

Kelebihan:

• Bayar hanya waktu komputasi yang dipakai.
• Kapasitas otomatis menjadi nol ketika tidak aktif.
• Pengembangan dan penerapan sederhana.
• Tanpa pengelolaan infrastruktur.

Kekurangan:

• Latensi awal saat kondisi dingin.
• Penyesuaian lingkungan terbatas.
• Ketergantungan penyedia seperti AWS Lambda dan GCP Functions.
• Penelusuran kesalahan lebih sulit daripada server biasa.

Kapan digunakan: lonjakan mendadak, pekerjaan jarang, serta startup dengan sumber daya operasi terbatas.

Pola: danau data dan analitik

Kapan digunakan: data besar, pembelajaran mesin, dan beban analitik.

Topologi:

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

Pertimbangan:

• Kualitas dan tata kelola data.
• Skema saat membaca atau menulis.
• Penanganan data pribadi dan kepatuhan privasi.
• Optimasi kinerja kueri.

Strategi optimasi

Optimasi biaya

1. Kapasitas yang sesuai

• Pantau penggunaan nyata, bukan kapasitas maksimum.
• Temukan pola dengan CloudWatch atau alat serupa.
• Perkecil instans berkapasitas berlebih.

2. Instans yang dipesan

• Perkirakan beban tetap.
• Pesan untuk 1-3 tahun dengan diskon 20-40%.
• Padukan dengan kapasitas otomatis untuk beban berubah.

3. Instans Spot

• Gunakan untuk beban toleran kegagalan dan tidak kritis.
• 70% lebih murah daripada sesuai permintaan.
• Perkirakan tingkat gangguan 2-5%.

4. Strategi cache

• Simpan data yang sering diakses dalam memori Redis.
• Kurangi beban basis data 50-80%.
• Gunakan CDN untuk aset statis: pengurangan biaya 80%+.

5. Transfer data

• Komponen mahal ini sering terabaikan.
• Gunakan endpoint VPC untuk menghindari biaya transfer.
• Kompres data dalam perjalanan.
• Gunakan CloudFront untuk distribusi global.

Optimasi skalabilitas

1. Penskalaan horizontal

• Tambah server di belakang penyeimbang beban.
• Basis data: replika baca dengan utama dan sekunder.
• Cache: tambah simpul cache.

2. Pembagian basis data

• Bagi berdasarkan pengguna, wilayah, atau tanggal.
• Tiap bagian diskalakan secara mandiri.
• Konsekuensi: koordinasi lebih rumit.

3. Pool koneksi

• Gunakan kembali koneksi basis data.
• Tingkatkan throughput 2-3x.
• Kurangi overhead koneksi.

4. Strategi cache

• Simpan data sering diakses pada lapisan aplikasi.
• Cache respons API dengan strategi invalidasi.
• Cache kueri pada ORM.

Praktik keamanan terbaik

1. Enkripsi

• Dalam perjalanan: TLS 1.3 di semua endpoint.
• Tersimpan: AES-256 dengan kunci KMS.
• Basis data: volume terenkripsi dan enkripsi data pribadi pada aplikasi.

2. Autentikasi dan otorisasi

• MFA untuk semua akun.
• OAuth 2.0 untuk integrasi pihak ketiga.
• IAM dengan hak minimum.
• RBAC bagi pengguna aplikasi.

3. Jaringan

• Isolasi VPC dan subnet privat untuk basis data.
• Grup keamanan dengan port minimum.
• NACL sebagai lapisan tambahan.
• WAF untuk aplikasi web pada penyeimbang beban.

4. Perlindungan data

• Tokenisasi dan penyamaran data pribadi.
• Enkripsi per kolom untuk data sensitif.
• Kebijakan retensi dan penghapusan data lama.
• Uji pemulihan cadangan.

5. Pemantauan dan audit

• CloudTrail atau log audit untuk semua panggilan API.
• Alarm CloudWatch untuk anomali.
• Audit keamanan berkala.
• Panduan respons insiden.

Praktik kinerja terbaik

1. Latensi

• CDN untuk aset statis.
• Indeks untuk kueri umum.
• Optimalkan kueri dan hindari N+1.
• Kelompokkan permintaan API.

2. Throughput

• Seimbangkan beban antarserver.
• Pool koneksi basis data.
• Proses tugas panjang secara asinkron.
• Skalakan beban yang dibatasi CPU secara vertikal.

3. Keandalan

• Pemeriksaan kesehatan dan pemulihan otomatis.
• Pemutus sirkuit untuk dependensi.
• Percobaan ulang dengan jeda eksponensial.
• Penurunan fungsi terkendali.

Praktik penerapan terbaik

1. Infrastruktur sebagai kode

• Semua dalam Terraform atau CloudFormation.
• Kontrol versi.
• Tinjauan rekan sebelum diterapkan.
• Uji di staging terlebih dahulu.

2. Penerapan berkelanjutan

• Uji unit, integrasi, dan e2e otomatis.
• Penerapan canary bertahap.
• Penerapan biru-hijau tanpa waktu henti.
• Strategi pemulihan versi.

3. Pemantauan dan observabilitas

• Log terstruktur JSON.
• Pelacakan terdistribusi X-Ray atau Jaeger.
• Metrik Prometheus atau CloudWatch.
• Peringatan pada SLO, bukan hanya kesalahan.

Antipola yang harus dihindari

❌ Titik kegagalan tunggal tanpa redundansi. ❌ Rekayasa berlebihan sebelum pertumbuhan memerlukannya. ❌ Mengabaikan biaya untuk fungsi yang tidak diperlukan. ❌ Penskalaan manual yang seharusnya otomatis. ❌ Tanpa pemantauan, sehingga tidak memahami kondisi. ❌ Tanpa rencana pemulihan bencana: berharap bukan strategi. ❌ Semua dalam satu zona, rentan terhadap gangguan pusat data.

Langkah berikutnya

• Jelajahi pola → Pustaka pola
• Pelajari analisis → Modul analisis
• Praktik tata kelola → Tata kelola