Mengenal Service Discovery: Teknologi yang Membuat Microservices Lebih Fleksibel
Dalam aplikasi modern, terutama yang menggunakan microservices, sebuah aplikasi biasanya tidak hanya terdiri dari satu server atau satu komponen. Sebaliknya, aplikasi dapat dibangun dari banyak service yang saling berkomunikasi untuk menjalankan fungsi tertentu.
Masalahnya, lokasi setiap service tidak selalu tetap. Sebuah service dapat berpindah server, memiliki beberapa instance, menggunakan alamat IP yang berbeda, atau mengalami perubahan jumlah instance karena proses scaling.
Service Discovery membantu aplikasi menemukan lokasi service lain secara otomatis tanpa harus menyimpan alamat IP dan port setiap service secara manual. Dengan mekanisme ini, komunikasi antarservice dapat menjadi lebih fleksibel, terutama pada lingkungan cloud, container, dan microservices.
Lalu, apa itu Service Discovery, bagaimana cara kerjanya, dan mengapa teknologi ini penting dalam arsitektur aplikasi modern?
Apa Itu Service Discovery?
Service Discovery adalah mekanisme yang memungkinkan aplikasi menemukan lokasi service lain secara otomatis dalam sebuah jaringan. Informasi yang ditemukan dapat berupa alamat IP, hostname, port, nama service, dan status instance.
Pada aplikasi sederhana, alamat service biasanya ditentukan secara langsung melalui konfigurasi. Namun, cara ini menjadi kurang praktis pada arsitektur microservices karena satu service dapat memiliki banyak instance dengan alamat yang berbeda dan dapat berubah sewaktu-waktu.
Service Discovery membantu mengatasi masalah tersebut dengan menyediakan informasi mengenai endpoint yang tersedia. Dengan begitu, service dapat saling berkomunikasi tanpa harus bergantung pada alamat IP tertentu dan tanpa melakukan konfigurasi secara manual setiap kali terjadi perubahan infrastruktur.
Mengapa Service Discovery Dibutuhkan?
Dalam sistem tradisional, aplikasi biasanya berkomunikasi dengan server yang memiliki alamat relatif tetap.
Misalnya: Aplikasi → 192.168.1.10:8080
Masalah mulai muncul ketika aplikasi berkembang dan menggunakan banyak service. Contohnya:
Frontend
↓
API Service
↓
User Service
↓
Payment Service
↓
Notification Service
Masing-masing service dapat berjalan pada server atau container yang berbeda. Jika setiap service harus mengetahui alamat IP service lainnya secara manual, pengelolaan sistem akan menjadi semakin sulit.
Service Discovery memberikan pendekatan yang lebih dinamis. Alih-alih aplikasi mengetahui alamat IP secara langsung, aplikasi cukup mengetahui nama service: payment-service, Kemudian Service Discovery membantu menemukan endpoint yang tersedia untuk service tersebut.
Bagaimana Cara Kerja Service Discovery?
Secara sederhana, Service Discovery bekerja dengan menyimpan informasi mengenai service yang tersedia dan lokasi instance-nya. Alur dasarnya dapat digambarkan seperti berikut:
Service A
│
│ mencari "Service B"
▼
Service Discovery
│
│ memberikan endpoint
▼
Service B
Prosesnya biasanya melibatkan beberapa tahap.
1. Service Mendaftarkan Diri
Ketika sebuah service dijalankan, service tersebut mendaftarkan informasi dirinya ke sistem Service Discovery. Misalnya:
Nama: payment-service
IP: 10.0.0.15
Port: 8080
Status: healthy
Informasi ini kemudian disimpan dalam registry.
2. Service Discovery Menyimpan Informasi
Service Discovery menyimpan daftar service beserta endpoint yang tersedia. Contohnya:
user-service → 10.0.0.10:8080
payment-service → 10.0.0.15:8080
notification-service → 10.0.0.20:8080
Jika sebuah service memiliki beberapa instance, semuanya dapat dicatat.
payment-service
├── 10.0.0.15:8080
├── 10.0.0.16:8080
└── 10.0.0.17:8080
3. Service Lain Mencari Service yang Dibutuhkan
Ketika order-service ingin berkomunikasi dengan payment-service, order-service tidak perlu mengetahui IP address setiap instance. Service tersebut cukup mencari: payment-service, Service Discovery kemudian memberikan informasi mengenai instance yang tersedia.
4. Request Dikirim ke Instance yang Tersedia
Setelah mendapatkan endpoint, request dapat dikirim ke instance yang sesuai. Jika terdapat beberapa instance, sistem dapat memilih salah satu berdasarkan mekanisme tertentu, misalnya load balancing.
5. Instance yang Tidak Sehat Dapat Dikeluarkan
Service Discovery biasanya dapat dikombinasikan dengan mekanisme health check. Jika sebuah instance tidak lagi sehat atau tidak dapat diakses, endpoint tersebut dapat ditandai tidak tersedia sehingga request berikutnya tidak diarahkan ke instance tersebut.
Apa Itu Service Registry?
Service Registry adalah tempat penyimpanan informasi mengenai service dan endpoint yang tersedia dalam sebuah sistem. Service Registry menjadi salah satu komponen penting dalam Service Discovery. Contohnya:
| Service | Endpoint | Status |
|---|---|---|
| User Service | 10.0.0.10:8080 | Healthy |
| Payment Service | 10.0.0.11:8080 | Healthy |
| Payment Service | 10.0.0.12:8080 | Healthy |
| Notification Service | 10.0.0.13:8080 | Unhealthy |
Registry memungkinkan sistem mengetahui service apa saja yang tersedia dan ke mana request dapat diarahkan. Informasi tersebut dapat berubah secara dinamis ketika instance ditambahkan, dihapus, atau mengalami gangguan.
Apa Itu Service Registration?
Service Registration adalah proses ketika sebuah service mendaftarkan dirinya ke Service Registry. Misalnya ketika container baru menjalankan payment-service, service tersebut dapat melakukan registrasi:
Nama Service: payment-service
Endpoint: 10.0.0.15:8080
Setelah terdaftar, service lain dapat menemukan endpoint tersebut melalui Service Discovery. Registrasi dapat dilakukan secara otomatis ketika service mulai berjalan.
Apa Itu Service Deregistration?
Selain mendaftarkan service, sistem juga perlu mengetahui ketika sebuah instance sudah tidak tersedia. Proses menghapus atau menandai instance dari registry disebut service deregistration. Misalnya:
payment-service
├── 10.0.0.15:8080
├── 10.0.0.16:8080
└── 10.0.0.17:8080
Kemudian instance 10.0.0.16 dihentikan. Registry perlu memperbarui informasi menjadi:
payment-service
├── 10.0.0.15:8080
└── 10.0.0.17:8080
Dengan demikian, request tidak lagi diarahkan ke instance yang sudah tidak tersedia.
Apa Itu Health Check dalam Service Discovery?
Health check adalah mekanisme untuk memeriksa apakah sebuah service atau instance masih dapat menerima request dengan baik. Health check sangat penting karena service yang masih tercatat di registry belum tentu benar-benar dapat digunakan. Contohnya:
payment-service
10.0.0.15:8080 → Healthy
10.0.0.16:8080 → Unhealthy
10.0.0.17:8080 → Healthy
Ketika request datang, sistem dapat menghindari instance yang berstatus Unhealthy. Health check dapat dilakukan melalui beberapa metode, tergantung platform dan arsitektur yang digunakan.
Jenis Service Discovery
Secara umum, Service Discovery sering dibagi menjadi dua pendekatan utama, yaitu client-side discovery dan server-side discovery.
1. Client-Side Service Discovery
Pada client-side discovery, client bertanggung jawab mencari service yang ingin digunakan. Alurnya:
Client
↓
Service Registry
↓
Mendapatkan endpoint
↓
Service
Misalnya order-service ingin mengakses payment-service. order-service terlebih dahulu meminta informasi endpoint kepada Service Registry. Setelah mendapatkan endpoint, order-service mengirimkan request langsung ke instance yang dipilih.
Kelebihan pendekatan ini adalah client memiliki kontrol lebih besar terhadap proses pemilihan instance. Namun, client membutuhkan mekanisme atau library untuk berinteraksi dengan Service Registry dan melakukan pemilihan endpoint.
2. Server-Side Service Discovery
Pada server-side discovery, client tidak perlu mencari endpoint secara langsung. Request dikirim terlebih dahulu ke komponen yang bertanggung jawab menemukan service. Alurnya:
Client
↓
Load Balancer / Proxy
↓
Service Discovery
↓
Service Instance
Komponen seperti load balancer, proxy, atau gateway dapat membantu menentukan instance yang akan menerima request. Pendekatan ini membuat client lebih sederhana karena logika discovery tidak perlu diimplementasikan pada setiap service. Namun, infrastruktur tambahan perlu dikelola untuk menangani proses tersebut.
Perbedaan Client-Side dan Server-Side Discovery
| Aspek | Client-Side | Server-Side |
|---|---|---|
| Pencarian service | Dilakukan client | Dilakukan komponen server/proxy |
| Client | Lebih kompleks | Relatif lebih sederhana |
| Registry | Diakses client | Dapat diakses proxy atau komponen infrastruktur |
| Pemilihan instance | Client | Load balancer/proxy |
| Fleksibilitas | Tinggi | Bergantung pada infrastruktur |
| Pengelolaan | Logika discovery berada di aplikasi | Lebih banyak ditangani infrastruktur |
Tidak ada pendekatan yang selalu paling baik. Pemilihannya bergantung pada arsitektur, platform, kebutuhan operasional, dan teknologi yang digunakan.
Service Discovery dalam Arsitektur Microservices
Service Discovery sangat erat kaitannya dengan microservices. Dalam arsitektur microservices, aplikasi besar dipecah menjadi beberapa service yang memiliki tanggung jawab berbeda. Contohnya:
┌─ User Service
│
API Gateway ─────────┼─ Order Service
│
├─ Payment Service
│
└─ Notification Service
Setiap service dapat berjalan secara independen dan memiliki instance yang berbeda. Misalnya ketika traffic meningkat, order-service dapat diperbanyak:
order-service
├── Instance 1
├── Instance 2
├── Instance 3
└── Instance 4
Service Discovery membantu service lain mengetahui instance mana yang tersedia. Tanpa mekanisme discovery, pengelolaan alamat endpoint dalam lingkungan yang dinamis dapat menjadi lebih sulit.
Service Discovery pada Cloud dan Container
Service Discovery semakin penting ketika aplikasi dijalankan pada lingkungan cloud dan container. Pada lingkungan tersebut, instance dapat dibuat dan dihentikan secara dinamis. Contohnya:
Traffic meningkat
↓
Instance baru dibuat
↓
Service mendaftarkan endpoint
↓
Service Discovery memperbarui registry
↓
Request dapat diarahkan ke instance baru
Ketika traffic menurun, beberapa instance dapat dihentikan kembali. Service Discovery membantu mengikuti perubahan tersebut tanpa mengharuskan developer memperbarui alamat IP secara manual.
Service Discovery dan Docker
Dalam lingkungan container, alamat IP container dapat berubah ketika container dibuat ulang. Karena itu, menggunakan alamat IP container secara langsung bukan pendekatan yang ideal untuk komunikasi antarservice dalam sistem yang dinamis.
Service discovery berbasis nama service dapat membuat komunikasi lebih sederhana. Misalnya: order-service → payment-servicedibandingkan:
order-service → 172.18.0.5:8080
Dengan menggunakan nama service, aplikasi tidak terlalu bergantung pada alamat IP instance tertentu. Platform container modern juga menyediakan mekanisme discovery atau DNS service yang dapat digunakan sesuai kebutuhan arsitektur.
Service Discovery pada Kubernetes
Kubernetes memiliki mekanisme Service yang memungkinkan workload berkomunikasi menggunakan nama service daripada bergantung pada alamat IP Pod secara langsung. Misalnya terdapat: payment-service
Service lain dapat menggunakan nama tersebut untuk menemukan endpoint yang tersedia. Kubernetes kemudian membantu mengarahkan traffic ke Pod yang sesuai berdasarkan konfigurasi Service. Hal ini membuat komunikasi antarworkload lebih dinamis karena Pod dapat dibuat ulang atau berpindah tanpa membuat aplikasi harus mengetahui alamat IP Pod secara manual.
Dalam konteks Kubernetes, istilah Service Discovery dapat berkaitan dengan DNS internal, Kubernetes Service, endpoint, dan mekanisme jaringan lain yang digunakan untuk menemukan workload.
Service Discovery dan DNS
DNS juga dapat digunakan sebagai bagian dari mekanisme Service Discovery. Daripada aplikasi menyimpan alamat IP secara langsung, aplikasi dapat menggunakan nama host tertentu.
Contohnya: payment-service.example.internal
Nama tersebut kemudian dapat dipetakan ke endpoint yang sesuai. Pendekatan berbasis DNS cukup populer karena banyak aplikasi sudah mendukung resolusi nama host tanpa memerlukan implementasi discovery khusus di dalam kode aplikasi.
Namun, kemampuan dan perilaku discovery tetap bergantung pada bagaimana DNS dan infrastruktur di belakangnya dikonfigurasi.
Service Discovery vs Load Balancing
Service Discovery dan load balancing memiliki fungsi yang berbeda meskipun keduanya sering digunakan bersama. Service Discovery bertugas membantu menemukan service atau instance yang tersedia. Sementara itu, load balancing bertugas mendistribusikan traffic ke beberapa instance yang tersedia. Contohnya:
Service Discovery
↓
Menemukan instance
↓
┌────────────┼────────────┐
↓ ↓ ↓
Instance 1 Instance 2 Instance 3
↑ ↑ ↑
└──── Load Balancer ──────┘
Dalam implementasi tertentu, komponen yang sama atau platform yang sama dapat menangani sebagian fungsi tersebut. Namun secara konsep, discovery dan load balancing merupakan tanggung jawab yang berbeda.
| Service Discovery | Load Balancing |
|---|---|
| Menemukan service | Mendistribusikan traffic |
| Mengetahui endpoint | Memilih atau mengarahkan traffic |
| Memantau keberadaan instance | Membagi beban antarinstance |
| Membantu service saling menemukan | Membantu mencegah satu instance menerima seluruh beban |
Service Discovery vs API Gateway
Service Discovery juga berbeda dengan API Gateway. API Gateway biasanya menjadi pintu masuk bagi client menuju beberapa backend service. Contohnya:
Client
↓
API Gateway
├── User Service
├── Order Service
└── Payment Service
Sementara Service Discovery membantu gateway atau service lain menemukan lokasi backend service tersebut. Dengan demikian, API Gateway dan Service Discovery dapat digunakan secara bersamaan.
Manfaat Service Discovery
Service Discovery memberikan beberapa manfaat bagi aplikasi modern.
1. Mengurangi Ketergantungan pada IP Address
Aplikasi tidak perlu menyimpan alamat IP setiap instance secara permanen. Hal ini membuat sistem lebih fleksibel ketika infrastruktur berubah.
2. Mendukung Scaling
Ketika instance baru ditambahkan, endpoint tersebut dapat didaftarkan ke registry sehingga dapat ditemukan oleh service lain. Hal ini sangat berguna pada sistem yang menggunakan horizontal scaling.
3. Mempermudah Arsitektur Microservices
Dalam microservices, jumlah service dapat cukup banyak. Service Discovery membantu masing-masing service menemukan dependency yang dibutuhkan tanpa konfigurasi alamat secara manual.
4. Mendukung Infrastruktur Dinamis
Server, container, dan instance cloud dapat dibuat atau dihentikan sesuai kebutuhan. Service Discovery membantu aplikasi mengikuti perubahan tersebut.
5. Membantu Menangani Instance yang Bermasalah
Dengan health check, instance yang tidak sehat dapat dikeluarkan dari daftar endpoint yang digunakan.
6. Mengurangi Konfigurasi Manual
Developer tidak perlu memperbarui alamat IP setiap kali lokasi service berubah. Hal ini dapat mengurangi pekerjaan operasional dan risiko kesalahan konfigurasi.
7. Mendukung High Availability
Ketika sebuah service memiliki beberapa instance, Service Discovery dapat membantu menyediakan daftar endpoint yang tersedia. Jika satu instance mengalami masalah, sistem dapat menggunakan instance lainnya sesuai mekanisme yang diterapkan.
Apa Kekurangan Service Discovery?
Meskipun memiliki banyak manfaat, Service Discovery juga menambah komponen dan kompleksitas dalam sistem.
1. Menambah Kompleksitas Infrastruktur
Sistem perlu mengelola registry atau mekanisme discovery. Semakin banyak komponen yang digunakan, semakin besar pula kebutuhan monitoring dan maintenance.
2. Registry Menjadi Komponen Penting
Jika mekanisme Service Discovery mengalami masalah, proses menemukan service dapat terganggu. Karena itu, komponen discovery biasanya perlu dirancang dengan tingkat ketersediaan yang baik.
3. Membutuhkan Monitoring
Perubahan status service, health check, registration, dan deregistration perlu dipantau agar masalah dapat diketahui lebih cepat.
4. Masalah Konsistensi Data
Pada sistem terdistribusi, informasi mengenai instance dapat mengalami keterlambatan pembaruan. Karena itu, desain Service Discovery perlu mempertimbangkan bagaimana registry menangani perubahan data dan kegagalan jaringan.
Contoh Sederhana Service Discovery
Bayangkan sebuah aplikasi toko online memiliki tiga service:
User Service
Order Service
Payment Service
Order Service membutuhkan Payment Service.
Tanpa Service Discovery, konfigurasi mungkin seperti:
PAYMENT_SERVICE_HOST=10.0.0.15
PAYMENT_SERVICE_PORT=8080
Jika server payment berpindah ke alamat lain, konfigurasi perlu diperbarui. Dengan Service Discovery, Order Service dapat mencari: payment-service
Registry kemudian memberikan endpoint yang tersedia:
10.0.0.15:8080
10.0.0.16:8080
Jika 10.0.0.15 mengalami gangguan dan statusnya menjadi tidak sehat, sistem dapat menghindari endpoint tersebut. Dengan demikian, komunikasi antarservice menjadi lebih dinamis.
Contoh Alur Service Discovery pada Microservices
Secara keseluruhan, prosesnya dapat digambarkan seperti berikut:
Service Registry
▲
│
Registration
│
Payment Service
│
│
Order Service ──────┘
│
│ Discovery
▼
Service Registry
│
│ Endpoint
▼
Payment Service Instance
Jika terdapat beberapa instance, registry dapat menyimpan semuanya:
Payment Service
│
├── Instance A → Healthy
├── Instance B → Healthy
└── Instance C → Unhealthy
Instance yang tidak sehat dapat dikeluarkan dari endpoint yang dipilih untuk request.
Teknologi yang Dapat Digunakan untuk Service Discovery
Terdapat berbagai teknologi dan platform yang menyediakan mekanisme Service Discovery atau fitur yang mendukungnya. Beberapa contoh yang umum ditemui dalam ekosistem cloud dan distributed systems antara lain:
- Consul
- etcd
- Apache ZooKeeper
- Kubernetes Service dan DNS
- Mekanisme discovery berbasis DNS
- Service discovery yang disediakan oleh platform cloud tertentu
Masing-masing memiliki pendekatan, fitur, dan lingkungan penggunaan yang berbeda. Pemilihannya sebaiknya disesuaikan dengan arsitektur aplikasi dan infrastruktur yang digunakan.
Kapan Service Discovery Dibutuhkan?
Service Discovery semakin bermanfaat ketika sistem memiliki karakteristik seperti:
- Menggunakan microservices
- Memiliki banyak service
- Menjalankan banyak instance
- Menggunakan container
- Menggunakan Kubernetes
- Berjalan pada cloud
- Membutuhkan auto scaling
- Memiliki infrastruktur yang dinamis
- Membutuhkan high availability
Sebaliknya, website sederhana dengan satu server dan satu aplikasi mungkin belum membutuhkan Service Discovery khusus. Misalnya:
Website
↓
1 Server
↓
1 Application
Dalam kondisi seperti itu, konfigurasi endpoint sederhana biasanya sudah cukup.
Praktik yang Baik dalam Menggunakan Service Discovery
Agar Service Discovery dapat berjalan dengan baik, ada beberapa hal yang perlu diperhatikan.
1. Gunakan Nama Service
Sebisa mungkin aplikasi menggunakan nama service daripada alamat IP instance secara langsung.
2. Terapkan Health Check
Pastikan endpoint yang tidak sehat tidak terus digunakan untuk menerima traffic.
3. Siapkan Redundansi
Service Registry sebaiknya tidak menjadi single point of failure.
4. Pantau Perubahan Instance
Monitoring diperlukan untuk mengetahui service yang sering gagal melakukan registration atau mengalami perubahan status.
5. Perhatikan TTL dan Deregistration
Jika menggunakan mekanisme lease atau TTL, pastikan service melakukan pembaruan status sesuai kebutuhan.
6. Jangan Mengandalkan Discovery untuk Semua Hal
Service Discovery membantu menemukan service, tetapi tidak menggantikan mekanisme keamanan, autentikasi, authorization, observability, maupun load balancing.
Kesimpulan
Service Discovery adalah mekanisme yang memungkinkan service dalam sebuah sistem menemukan lokasi service lain secara otomatis tanpa harus mengetahui alamat IP dan port setiap instance secara manual.
Teknologi ini sangat berguna dalam arsitektur microservices, cloud, container, dan sistem terdistribusi yang memiliki infrastruktur dinamis. Ketika sebuah service memiliki banyak instance, Service Discovery dapat membantu mengetahui endpoint yang tersedia dan menghindari instance yang tidak sehat melalui mekanisme seperti health check.
Service Discovery dapat diterapkan menggunakan pendekatan client-side maupun server-side discovery. Dalam implementasinya, teknologi seperti DNS, Kubernetes Service, Consul, etcd, dan berbagai platform lainnya dapat digunakan sesuai kebutuhan.
Pada sistem sederhana, Service Discovery mungkin belum diperlukan. Namun, ketika aplikasi berkembang menjadi lebih kompleks, memiliki banyak service, menggunakan auto scaling, atau berjalan pada lingkungan cloud dan container, mekanisme ini dapat membantu membuat komunikasi antarservice menjadi lebih fleksibel, dinamis, dan mudah dikelola.
Untuk mendapatkan informasi lainnya mengenai teknologi, cloud computing, hosting, website, dan perkembangan digital, Blog Hosteko dapat menjadi sumber referensi yang informatif. Untuk kebutuhan domain dan hosting, Hosteko Hosting Indonesia juga menyediakan layanan yang dapat mendukung kebutuhan website dan infrastruktur digital.
