IF Notes

Implementasi, Operasional, dan Tools of the Trade

5 min read

Back to IF4031 Arsitektur Aplikasi Terdistribusi

Implementasi, Operasional, dan Tools of the Trade

Questions/Cues

  • Apa tantangan operasional utama?

  • Apa itu Service Discovery?

  • Bagaimana mengatasi Fan Out?

  • Apa itu Client-Side Load Balancing?

  • Apa itu Observability?

  • Apa peran Netflix OSS?

  • Apa itu SideCar Pattern?

  • Apa gunanya Prana?

  • Bagaimana mengelola deployment?

  • Apa itu Red/Black push?

Reference Points

  • 07-IF4031-Microservices.pdf (hampir seluruh dokumen)

Tantangan Operasional

Mengelola puluhan atau ratusan layanan memperkenalkan kompleksitas operasional yang signifikan. DevOps menjadi model yang mutlak diperlukan.

1. Service Discovery

Di lingkungan cloud yang dinamis, instance layanan bisa muncul dan menghilang (karena auto-scaling, deployment, atau kegagalan). Alamat IP mereka tidak tetap.

  • Masalah: Bagaimana layanan A bisa menemukan alamat IP layanan B yang sedang berjalan?

  • Solusi: Sebuah Service Registry (seperti Netflix Eureka). Saat sebuah instance layanan dimulai, ia mendaftarkan dirinya (alamat IP dan port) ke Registry. Ketika layanan lain ingin memanggilnya, ia akan bertanya ke Registry untuk mendapatkan daftar alamat yang tersedia.

2. Chattiness dan Fan Out

Satu permintaan masuk dari pengguna (misalnya, ke API Gateway) dapat “menyebar” (fan out) menjadi puluhan atau ratusan permintaan ke layanan-layanan internal. Ini meningkatkan lalu lintas jaringan secara eksponensial dan bisa menciptakan bottleneck.

  • Solusi:

    • Caching Agresif: Simpan hasil dari panggilan layanan yang sering diakses.

    • Passing Data via Headers: Daripada setiap layanan harus memanggil layanan User Account untuk mendapatkan detail pengguna, informasi tersebut dapat dilewatkan di HTTP Header dari satu layanan ke layanan berikutnya.

Praktik Terbaik dan Pola Implementasi

1. Client-Side Smart Load Balancers

  • Load Balancer Tradisional (Proxy): Klien memanggil satu alamat load balancer, yang kemudian mendistribusikan lalu lintas ke beberapa instance di belakangnya.

  • Client-Side Load Balancer (Contoh: Netflix Ribbon): Klien (pemanggil layanan) mendapatkan daftar semua instance yang tersedia dari Service Registry. Klien itu sendiri yang kemudian memilih instance mana yang akan dipanggil berdasarkan algoritma tertentu (misalnya, round-robin). Ini menghilangkan satu hop jaringan dan memberikan lebih banyak kecerdasan pada klien.

2. Isolasi dan Keamanan

Setiap layanan harus diisolasi. Di AWS, ini dapat dicapai dengan menggunakan Security Groups untuk secara ketat mengontrol port dan alamat IP mana yang diizinkan untuk berkomunikasi dengan layanan tersebut.

3. SideCar Pattern untuk Ekosistem Polyglot

Ketika Anda memiliki layanan yang ditulis dalam berbagai bahasa (Java, Python, Node.js - sebuah ekosistem polyglot), sulit untuk menyediakan fungsionalitas umum seperti service discovery, monitoring, atau circuit breaking secara konsisten.

  • Solusi: SideCar Pattern. Sebuah proses kecil (“sidecar”) di-deploy di samping setiap instance aplikasi utama. Aplikasi utama berkomunikasi dengan dunia luar melalui sidecar ini. Sidecar menangani semua interaksi jaringan dan fungsionalitas infrastruktur. Contoh dari Netflix adalah Prana, sebuah sidecar yang memungkinkan aplikasi non-JVM untuk terintegrasi dengan ekosistem infrastruktur Netflix (Eureka, Archaius, dll.).

Observability: Memahami Sistem yang Kompleks

Observability adalah kemampuan untuk memahami keadaan internal sistem hanya dengan melihat output eksternalnya. Ini lebih dari sekadar monitoring biasa dan terdiri dari tiga pilar:

  1. Logging: Mengumpulkan log terpusat dari semua layanan (misalnya, menggunakan ELK Stack).

  2. Metrics: Mengumpulkan metrik numerik (misalnya, jumlah permintaan per detik, latensi, penggunaan CPU) dari setiap layanan. Netflix Servo adalah library untuk ini.

  3. Distributed Tracing: Melacak alur sebuah permintaan saat melewati beberapa layanan. Setiap permintaan diberi ID unik yang dibawa ke setiap layanan, memungkinkan visualisasi dependensi dan identifikasi bottleneck.

Deployment dan Tools of the Trade

Deployment Strategy: Red/Black (Blue/Green) Pushes

Ini adalah strategi deployment tanpa downtime.

  1. Versi baru dari layanan (“Black”) di-deploy di samping versi lama yang sedang berjalan (“Red”).

  2. Lalu lintas masih sepenuhnya diarahkan ke versi Red.

  3. Setelah versi Black lolos semua tes, load balancer dialihkan untuk mengirim semua lalu lintas baru ke versi Black.

  4. Versi Red tetap siaga untuk rollback cepat jika terjadi masalah, sebelum akhirnya dimatikan.

    Netflix Asgard adalah tool yang digunakan untuk mengelola deployment semacam ini.

Netflix OSS (Open Source Software)

Netflix telah membuka banyak sekali tools infrastruktur mereka yang menjadi standar de-facto dalam membangun microservices, terutama di ekosistem JVM:

  • Eureka: Service Discovery.

  • Ribbon: Client-Side Load Balancing.

  • Hystrix: Fault Tolerance (Circuit Breaker).

  • Archaius: Konfigurasi dinamis.

  • Zuul: API Gateway (versi lebih lama).

Summary

Implementasi microservice pada skala besar memerlukan penanganan tantangan operasional yang kompleks seperti Service Discovery menggunakan Service Registry (Eureka), dan mitigasi Fan Out melalui caching dan penyebaran data via header. Praktik terbaik meliputi penggunaan Client-Side Load Balancer (Ribbon) dan SideCar Pattern (Prana) untuk ekosistem polyglot, didukung oleh Observability yang kuat (logging, metrics, tracing) dan strategi deployment canggih seperti Red/Black. Ekosistem Netflix OSS menyediakan serangkaian tools yang teruji untuk mengatasi sebagian besar tantangan ini.

Graph View

Backlinks