13_SOA Performance, Scalability & Availability

Definisi

• Performance mencakup berbagai concern: throughput, utilization, latency.
• Availability dan scalability sering dibundel dengan performance, karena solusi untuk satu masalah sering membantu menyelesaikan masalah lain juga.

Mitos: “Tambah Hardware = Otomatis Lebih Cepat/Available”

Banyak orang merasa performance, availability, dan scalability mudah ditingkatkan dengan sekadar menambah hardware — kenyataannya sering tidak demikian. Butuh teknologi/pendekatan pengembangan baru; memanfaatkan hardware tambahan, mengimplementasikan load balancing, dan memastikan performa aplikasi tetap baik saat terjadi kegagalan adalah masalah yang sangat sulit dipecahkan.

Availability

Availability (ITIL): kemampuan sebuah configuration item/IT service menjalankan fungsi yang disepakati ketika dibutuhkan (bukan berarti harus selalu up 24 jam — jika saat tidak dibutuhkan service down, itu sah-sah saja).

$\text{Availability \%}=\frac{\text{Agreed Service Time}-\text{Downtime}}{\text{Agreed Service Time}}$

Availability %	Downtime/tahun	Downtime/bulan	Downtime/minggu
90% (“one nine”)	36.5 hari	72 jam	16.8 jam
99% (“two nines”)	3.65 hari	7.2 jam	1.68 jam
99.9% (“three nines”)	8.76 jam	43.8 menit	10.1 menit
99.99% (“four nines”)	52.56 menit	4.32 menit	1.01 menit
99.999% (“five nines”)	5.26 menit	25.9 detik	6.05 detik

Mean-Time To Recover (MTTR) dan Mean-Time Between Error (MTBE) — Time Between Failures dihitung dari downtime - uptime antara satu kegagalan dengan kegagalan berikutnya.

Scalability

Scalability: atribut yang diinginkan dari jaringan/sistem/proses — kemampuan mengakomodasi jumlah elemen yang bertambah, memproses volume kerja yang tumbuh/menyusut dengan baik, dan/atau amenable terhadap pengurangan/penambahan ukuran (Andre Bondi). Intinya: seberapa baik sistem merespons perubahan dengan menambah/mengurangi resource.

• Scaling Out (Horizontal) vs Scaling Up (Vertical).

Best Practices

Teknikal

• Code for Performance — perhatikan serialisasi, keamanan (safety).
• Pilih protokol komunikasi yang tepat.
• Gunakan (Distributed) Caching.
• Manfaatkan Enterprise Service Bus.

Desain

• Pecah sistem menjadi beberapa codebase yang dapat di-deploy independen.
• Jadikan interface sebagai first-class citizen — memudahkan pencarian service yang tepat, dukungan berbagai bahasa, serta pengembangan/testing/deployment yang efisien.
• Resilience dan Autonomous.

SOA Design Pattern for Performance & Scalability (Arnon Rotem-Gal-Oz)

Decouple Invocation Pattern

• Masalah: bagaimana service menangani beban normal, beban puncak, dan periode beban tinggi berkelanjutan tanpa gagal?
• Solusi: pisahkan reply dari request — acknowledge penerimaan di edge service, taruh request pada queue yang reliable, lalu load-balance & prioritaskan komponen handler yang membaca dari queue.

Parallel Pipeline Pattern

• Masalah: bagaimana membangun service yang mempertahankan state namun tetap memberi throughput tinggi?
• Solusi: pecah proses menjadi beberapa subtask, tambahkan queue di antaranya, jadikan tiap subtask komponen independen. Catatan: semakin banyak subtask, semakin tinggi latensi.

Gridable Service Pattern

• Masalah: bagaimana membangun service untuk menangani task komputasi intensif secara scalable?
• Solusi: perkenalkan teknologi grid untuk menangani task komputasi intensif (Load balance, Manage queue, Schedule, Monitor and manage di grid root node, lalu tersebar ke banyak grid node yang tiap punya grid agent untuk Execute & Monitor).

Service Instance Pattern

• Masalah: bagaimana membangun service yang scalable secara sederhana & hemat biaya?
• Solusi: melakukan deployment banyak instance dari business logic service (Distribute lewat Dispatcher di edge).

Virtual Endpoint Pattern

• Masalah: bagaimana memberi layanan transparansi lokasi & pemulihan kegagalan yang graceful tanpa memengaruhi consumer?
• Solusi: membungkus beberapa instance edge component untuk membentuk virtual endpoint yang memberikan transparansi lokasi.

Service Watchdog Pattern

• Masalah: bagaimana meningkatkan availability dengan mengidentifikasi & menyelesaikan masalah/kegagalan spesifik service?
• Solusi: service memonitor kondisi internalnya sendiri, bertindak atas potensi masalah, mencoba self-heal, dan terus-menerus mempublikasikan statusnya ke watchdog agent.

Circuit Breaker Pattern

• Masalah: bagaimana mencegah kegagalan (jaringan/service) merambat ke service lain?
• Solusi: client memanggil remote service lewat proxy (circuit breaker).

sequenceDiagram
  participant Client
  participant CB as Circuit Breaker
  participant Supplier
  Client->>CB: request
  CB->>Supplier: request
  Note over CB,Supplier: connection problem (timeout berulang)
  Client->>CB: request
  CB-->>Client: timeout!
  Note over CB: trip → circuit open
  Client->>CB: request
  CB-->>Client: circuit open! (langsung gagal, tanpa hubungi Supplier)

• Saat jumlah kegagalan beruntun melewati threshold, circuit breaker trip — selama periode timeout, semua permintaan ke service tersebut langsung digagalkan tanpa mencoba menghubungi service asli.
• Setelah timeout berakhir, circuit breaker mengizinkan sejumlah test request lewat. Jika sukses → kembali beroperasi normal; jika gagal → periode penggagalan diulang.

Layered Architecture (N-layer)

• Masalah: menghadapi kompleksitas sistem microservice.
• Solusi: pecah sistem menjadi 3-4 layer dengan peran spesifik, mis. presentation, business, persistence, database.

Command Query Request Separation (CQRS) Pattern

• Masalah: model gabungan untuk command dan query membuat model makin kompleks.
• Solusi: buat object model berbeda untuk masing-masing tujuan (Query Model & Command Model), mungkin berjalan di proses logis berbeda, bahkan hardware terpisah.

Message Broker

• Masalah: bagaimana men-decouple tujuan pesan dari pengirim sambil menjaga kontrol sentral atas alur pesan?
• Solusi: pakai central Message Broker yang menerima pesan dari banyak sumber, menentukan tujuan yang tepat, dan me-routing pesan ke channel yang benar (mengubah topologi mesh penuh menjadi topologi hub-and-spoke).

Message Bus

• Masalah: bagaimana service berinteraksi secara decoupled lewat protokol berbeda, konfigurasi dinamis, dan routing?
• Solusi: pakai infrastruktur messaging terpadu untuk transformasi, mediasi, routing, invocation pesan:
  • Message bus — menghubungkan berbagai service.
  • Message router — menentukan pesan dikirim ke mana.
  • Channel adaptor — mengonversi format & protokol.

Event-driven Architecture (bukan pattern, tapi architecture style)

• Pub/sub: infrastruktur messaging melacak subscription. Saat event dipublikasi, langsung dikirim ke tiap subscriber. Setelah diterima, event tidak dapat di-replay dan subscriber baru tidak melihat event lama.
• Event streaming: event ditulis ke log, terurut ketat (dalam partition) dan durable. Client tidak subscribe, melainkan membaca dari titik manapun di stream, bertanggung jawab atas posisinya sendiri — bisa join kapan saja dan replay event (lihat juga Kafka di 9_Integration Patterns).

Event-Sourcing

• Masalah: bagaimana melakukan update database & mengirim message/event secara reliable/atomik?
• Solusi: state entitas bisnis dinyatakan sebagai sequence of state-changing events. Setiap kali state berubah, event baru di-append ke daftar event. Karena menyimpan event adalah operasi tunggal, sifatnya inheren atomik. Aplikasi merekonstruksi state terkini entitas dengan replay semua event-nya (dibanding menyimpan current state langsung di tabel).

Enterprise Integration Pattern (Peta Besar)

Kumpulan pattern klasik untuk integrasi lewat pesan, terdiri dari kategori: Message Construction (Command, Document, Event Message, dst.), Message Routing (Content-Based Router, Aggregator, Splitter, Scatter-Gather, dst.), Message Transformation (Message Translator, Envelope Wrapper, Canonical Data Model, dst.), Messaging Endpoints, Messaging Channels, dan Systems Management (Control Bus, Wire Tap, Message History, dst.) — lihat enterpriseintegrationpatterns.com.

Ringkasan Pattern & Beware

Pattern	Fungsi utama
Decoupled Invocation	Queue request untuk hadapi beban puncak & tingkatkan reliabilitas
Parallel Pipelines	Pecah proses jadi steps untuk tingkatkan throughput
Gridable Service	Pakai teknologi grid untuk task intensif komputasi
Service Instance	Deploy banyak instance service untuk bantu skalabilitas
Virtual Endpoint	Transparansi lokasi untuk bantu availability
Service Watchdog	Monitor & self-heal service

Hal yang perlu diwaspadai:

• Split Brain Problem — lebih dari satu server mengklaim diri sebagai master; data antar server jadi tidak sinkron, hasilnya bisa berupa response parsial/salah.
• Communication overhead — penambahan komponen untuk skalabilitas justru bisa meningkatkan latensi.

Flashcard

flashcards Apa rumus Availability menurut ITIL? :: Availability % = (Agreed Service Time - Downtime) / Agreed Service Time. Apa perbedaan Scaling Out (Horizontal) dan Scaling Up (Vertical)? :: Scaling Out menambah jumlah server/instance; Scaling Up menambah kapasitas pada satu server (mis. CPU/memori) — dua opsi utama strategi scalability. Jelaskan Decouple Invocation Pattern: masalah dan solusinya :: Masalah: service perlu menangani beban normal-puncak-tinggi berkelanjutan tanpa gagal. Solusi: pisahkan reply dari request, acknowledge di edge, taruh request di queue reliable, lalu load-balance & prioritaskan handler yang membacanya. Jelaskan cara kerja Circuit Breaker Pattern :: Client memanggil service lewat proxy (circuit breaker); jika kegagalan beruntun melewati threshold, circuit breaker trip dan menggagalkan semua request langsung selama periode timeout; setelah timeout, sejumlah test request diizinkan — sukses maka normal lagi, gagal maka periode penggagalan diulang. Apa perbedaan Pub/Sub dan Event Streaming pada Event-driven Architecture? :: Pub/Sub: event dikirim langsung ke subscriber saat dipublikasi, tidak bisa di-replay, subscriber baru tidak lihat event lama. Event Streaming: event ditulis ke log terurut & durable, client membaca dari titik manapun, bertanggung jawab atas posisinya, bisa join kapan saja & replay event. Jelaskan pattern Event-Sourcing dan mengapa ia atomik :: State entitas bisnis dinyatakan sebagai sequence of state-changing events; tiap perubahan menambah event baru (append). Atomik karena menyimpan event adalah operasi tunggal; state terkini direkonstruksi dengan replay semua event. Apa perbedaan Message Broker dan Message Bus pattern? :: Message Broker: satu broker sentral menentukan tujuan & routing pesan (topologi hub-and-spoke). Message Bus: infrastruktur messaging terpadu dengan 3 komponen — message bus (hubungkan service), message router (tentukan tujuan), channel adaptor (konversi format/protokol). Apa itu Split Brain Problem sebagai risiko dalam desain scalability? :: Kondisi di mana lebih dari satu server mengklaim diri sebagai master, menyebabkan data antar server tidak sinkron dan bisa menghasilkan response parsial/tidak akurat. Sebutkan mitos umum tentang performance/availability/scalability yang dibantah materi ini :: Bahwa menambah hardware otomatis meningkatkan performa/availability — kenyataannya butuh teknologi/pendekatan baru (load balancing, desain toleran kegagalan) karena masalah ini sangat sulit dipecahkan hanya dengan hardware tambahan.