Apa Itu Service Mesh?

Pengenalan Service Mesh

Service mesh adalah infrastruktur yang dapat dikonfigurasi yang digunakan untuk mengelola komunikasi antar-layanan dalam sistem mikroservis. Tujuannya adalah untuk memproses traffic antara mikroservis, yang juga disebut sebagai east-west traffic.

Dalam aplikasi cloud-native, sebuah aplikasi mungkin terdiri dari ratusan layanan. Setiap layanan dapat memiliki beberapa instance, dan setiap instance tersebut mungkin terus berubah. Dalam lingkungan operasional yang rumit seperti ini, bagaimana memberikan akses yang andal kepada pengguna dan menjaga layanan tetap berjalan dengan stabil telah menjadi tantangan besar. Oleh karena itu, solusi yang disebut service mesh muncul.

Service mesh seperti TCP/IP antara mikroservis, yang menangani fungsi antar-layanan seperti panggilan jaringan, pembatasan laju, pemantauan, dll. Kami terutama menerapkan service mesh pada platform Kubernetes. Selain itu, pola yang paling klasik disebut sidecar, yang mengabstraksikan beberapa fungsi umum ke dalam kontainer sidecar dan memasangnya bersama dengan kontainer layanan ke dalam pod yang sama. Gambar di bawah ini menunjukkan mengapa disebut sebagai service mesh.

Sidecar bukan satu-satunya pola yang menerapkan service mesh; selain itu, kami memiliki pola DaemonSet dan pola Ambient mesh:

• Perbedaan antara pola DaemonSet dan pola sidecar adalah bahwa pola DaemonSet hanya mengizinkan setiap node dalam kluster Kubernetes untuk menjalankan satu pod, dan pod ini berfungsi sebagai proxy sidecar. Dibandingkan dengan pola sidecar, pola DaemonSet menggunakan lebih sedikit sumber daya mesin, tetapi memiliki kekurangan seperti isolasi yang buruk, sulit memprediksi panggilan sumber daya, dll. Anda dapat menemukan lebih banyak perbedaan dalam artikel ini: Sidecars and DaemonSets: Battle of containerization patterns.

• Ambient mesh adalah mode data plane baru yang diperkenalkan oleh Istio pada 7 September 2022. Untuk menyelesaikan masalah kopling infrastruktur dan deployment mesh, Ambient mesh memisahkan proxy data plane dari pod aplikasi sehingga dapat di-deploy secara terpisah.

Ambient mesh membagi data plane menjadi lapisan overlay yang aman dan lapisan pemrosesan L7: Lapisan overlay yang aman menangani fungsi seperti routing TCP, metrik pemantauan, logging akses, tunneling mTLS; selain semua fungsi lapisan overlay yang aman, lapisan pemrosesan L7 memiliki lebih banyak fungsi seperti kontrol traffic melalui routing HTTP, observabilitas, dan mencapai kebijakan otorisasi L7 yang kaya.

Selain itu, Ambient mesh menggunakan agen bersama yang disebut ztunnel (zero-trust tunnel), yang berjalan di setiap node dalam kluster Kubernetes dan menghubungkan serta mengautentikasi workload di dalam mesh dengan aman. Anda dapat membaca artikel ini jika ingin mengetahui detail tentang mode Ambient mesh: Introducing Ambient Mesh

Mengapa kita membutuhkan service mesh?

Sebelum service mesh menjadi populer, banyak arsitektur mikroservis mengelola layanan melalui kerangka kerja mikroservis yang bekerja sama dengan platform kontrol. Namun, metode ini memiliki masalah berikut:

1. Keterikatan yang erat antara kerangka kerja dan layanan, sehingga kesulitan dan kompleksitas pemeliharaan secara keseluruhan menjadi sangat tinggi. Selain itu, pengembang perlu memahami pustaka umum, yang membuat mereka tidak dapat fokus pada implementasi layanan.
2. Perlu mempertahankan kerangka kerja multi-bahasa, yang meningkatkan biaya pemeliharaan.
3. Mikroservis memiliki biaya upgrade yang tinggi, dan biasanya perlu me-reboot layanan selama upgrade.
4. Ada kerangka kerja dengan banyak versi online yang berbeda, memaksa orang untuk mempertimbangkan kompatibilitas yang kompleks.

Untuk menyelesaikan masalah di atas, Willian Morgan, mantan insinyur Twitter dan salah satu pendiri Linkerd, mengusulkan konsep "Service Mesh". Service mesh menggunakan pola sidecar untuk memisahkan infrastruktur dengan logika layanan tanpa memengaruhi aplikasi, yang mencapai upgrade dan O&M yang seragam dalam bahasa.

Service mesh memindahkan fungsi seperti kontrol traffic, observabilitas, dan komunikasi aman ke komponen dasar; dengan demikian, pengembang tidak perlu khawatir tentang implementasi konkret dari lapisan komunikasi dan manajemen layanan. Pengembang dapat menyerahkan semua pekerjaan kotor terkait komunikasi kepada service mesh dan fokus pada pengembangan layanan. Berdasarkan fitur-fitur ini, service mesh dapat membantu kita menyelesaikan masalah yang disebutkan sebelumnya.

Bagaimana service mesh bekerja?

Service mesh tidak akan menambahkan fungsi baru ke lingkungan operasional aplikasi, sehingga semua aplikasi dalam kerangka kerja masih memerlukan aturan yang sesuai untuk menentukan bagaimana mengirim permintaan dari A ke B. Perbedaannya adalah service mesh akan mengekstrak komunikasi antar-layanan dari manajemen logika dan kemudian mengabstraksikannya ke dalam lapisan infrastruktur.

Saat ini, sebagian besar service mesh menggunakan arsitektur data plane + control plane, yang ditunjukkan di bawah ini:

Control plane

Control plane mengelola dan mengonfigurasi data plane serta melaksanakan strategi saat menjalankan layanan. Semua instance di dalam control plane dengan service mesh tunggal akan berbagi sumber daya konfigurasi yang sama.

Control plane lebih fokus pada pengiriman dan strategi seperti keamanan, observabilitas, dan kontrol traffic. Ini juga akan mengumpulkan dan mengumpulkan data telemetri dari data plane sehingga DevOps dapat menggunakannya.

Data plane

Data plane biasanya berfungsi sebagai proxy dan terdiri dari banyak proxy sidecar. Sidecar akan berjalan bersama instance layanan secara paralel dan mengontrol traffic aplikasi layanan dengan mencegat aliran data layanan.

Seperti yang telah disebutkan sebelumnya, service mesh dicapai dengan menerapkan pola sidecar ke Kubernetes dan membungkusnya sebagai kontainer. Sidecar menyarankan penggunaan kontainer tambahan untuk memperluas dan memperkuat kontainer utama, dan kontainer tambahan ini disebut kontainer sidecar, yang dialokasikan dalam pod yang sama dengan kontainer layanan. Di sisi lain, service mesh adalah jaringan mesh yang terdiri dari proxy sidecar tersebut.

Aplikasi service mesh

Dalam arsitektur mikroservis, insinyur biasanya mengenkripsi layanan publik yang terpapar atau membatasi akses untuk melindungi layanan, tetapi mereka mengabaikan keamanan komunikasi di dalam kluster. Sampai sekarang, banyak aplikasi mikroservis masih kekurangan enkripsi komunikasi antar-layanan, dan traffic internal kluster bahkan ditransfer dalam format data mentah. Akibatnya, traffic internal sangat rentan terhadap serangan penyadapan dan MITM (Man-in-the-middle attack).

Untuk menghindari serangan terhadap traffic internal kluster, kami menggunakan mTLS untuk mengenkripsi data traffic. mTLS dapat mengamankan keamanan komunikasi antara mikroservis dalam service mesh. Ini menggunakan teknologi enkripsi untuk mengautentikasi setiap mikroservis dan mengenkripsi traffic antar-layanan secara mutual.

Meskipun kita dapat langsung mendefinisikan strategi keamanan komunikasi di dalam mikroservis dan mengimplementasikan autentikasi identitas dan enkripsi, tetap sangat tidak efisien untuk mengimplementasikan fungsi yang sama secara individual di setiap mikroservis. Menambahkan fungsi baru harus memodifikasi kode layanan dan menginvasi logika layanan. Selain itu, bahkan jika kita dapat mengimplementasikan fungsi baru, iterasi, upgrade, dan pengujian selanjutnya masih memerlukan pengembang untuk menghabiskan lebih banyak waktu untuk pemeliharaan. Dengan demikian, pengembang tidak dapat fokus pada pengembangan fungsi layanan.

Sebaliknya, jika kita menggunakan service mesh, kita dapat menyediakan komunikasi mTLS tanpa layanan asli perlu menyadarinya. Oleh karena itu, dalam service mesh, kami memindahkan semua fungsi terkait komunikasi ke proxy sidecar.

Ketika dua mikroservis perlu berkomunikasi, proxy sidecar akan terlebih dahulu membangun koneksi mTLS, dan akan mengirim traffic terenkripsi melalui koneksi mTLS ini. Sidecar akan bertukar sertifikat dan saling mengautentikasi melalui otoritas sertifikat. Sebelum terhubung, sidecar akan memeriksa strategi autentikasi yang dikirim oleh control plane untuk menentukan apakah itu mengizinkan mikroservis untuk berkomunikasi. Jika komunikasi diizinkan, sidecar akan menggunakan kunci komunikasi yang dihasilkan untuk membangun koneksi aman dan mengenkripsi data komunikasi antar mikroservis. Selama seluruh proses, aplikasi layanan tidak akan terpengaruh, sehingga mengurangi gangguan bagi pengembang.

Dari skenario ini, semua orang dapat memahami mengapa service mesh dapat memperluas fungsi saat ini tanpa memengaruhi layanan saat ini. Tentu saja, selain mencapai fungsi konfigurasi keamanan traffic internal yang mirip dengan mTLS, service mesh juga dapat dengan cepat memperluas fungsi seperti kontrol traffic, observabilitas, dan protokol codec dengan memodifikasi konfigurasi control plane.

Kesimpulan

Artikel ini secara singkat memperkenalkan konsep dasar service mesh, prinsip kerjanya, dan manfaat yang dibawanya. Service mesh merevolusi arsitektur mikroservis dan membantu pengembang melepaskan diri dari lingkungan operasional mikroservis yang kompleks untuk fokus pada pengembangan fungsi layanan.

Meskipun service mesh menyelesaikan banyak titik sakit dalam arsitektur mikroservis, ia masih memiliki keterbatasan. Kompleksitas pengembangan perangkat lunak adalah abadi, dan itu hanya dipindahkan dari satu bagian ke bagian lain. Ketika kita mengabstraksikan manajemen layanan ke dalam lapisan terpisah, kita harus menghadapi kesulitan O&M tambahan dan peningkatan dalam tautan traffic. Selain itu, service mesh perlu digunakan di lingkungan cloud-native, yang menetapkan standar yang lebih tinggi untuk kemampuan profesional dan pengalaman kerja teknik DevOps. Itulah mengapa kami mengatakan teknologi hanyalah alat untuk menyelesaikan masalah, tetapi kita perlu menimbang manfaat yang dibawa oleh service mesh sesuai dengan aplikasi praktisnya.

Dengan perkembangan eksplosif cloud-native dan optimasi service mesh, service mesh kemungkinan akan sepenuhnya menggantikan arsitektur mikroservis di masa depan dan menjadi pilihan pertama setiap perusahaan untuk arsitektur ulang mikroservis dan cloud-native.

Jika Anda ingin tahu lebih banyak tentang manajemen API, hubungi kami kapan saja: https://api7.ai/contact.