Artikel ini adalah bagian pertama dari seri yang membahas tentang penggunaan mesh layanan untuk memigrasikan setiap fitur di lingkungan lama, seperti pusat data lokal yang menjalankan aplikasi di mesin virtual, ke Google Kubernetes Engine (GKE).
Seri ini terdiri dari artikel konseptual dan tutorial pendamping. Artikel ini menjelaskan alasan migrasi dan menjelaskan langkah-langkah dasarnya. Tutorial ini akan memandu Anda menggunakan contoh migrasi.
Pengantar
Artikel ini ditujukan untuk profesional IT yang menangani infrastruktur kompleks yang ingin Anda migrasikan dan modernisasikan secara bertahap sekaligus meminimalkan hal berikut:
- Periode nonaktif
- Upaya pemfaktoran ulang
- Kompleksitas operasional jaringan Anda
Konsep yang dijelaskan berikut dapat diterapkan ke cloud apa pun, jadi artikel ini menganggap Anda telah memahami teknologi, container, dan microservice cloud.
Sebagaimana dijelaskan dalam Pola dan praktik hybrid dan multi-cloud, terdapat tiga pola utama untuk bermigrasi ke cloud: lift-and-shift, improve-and-move, dan rip-and-replace. Artikel ini menjelaskan pola improve-and-move, dengan pola tersebut diterapkan ke setiap fitur aplikasi, bukan ke aplikasi secara keseluruhan.
Selama migrasi, aplikasi memiliki arsitektur hybrid dengan beberapa fitur ada di Google Cloud, sementara fitur lain masih ada di lingkungan lama. Setelah migrasi selesai, aplikasi lengkap akan dihosting di Google Cloud.
Terminologi
- aplikasi
- Dalam artikel ini, aplikasi adalah sistem software lengkap yang memiliki banyak fitur. Pengguna melihat aplikasi sebagai unit tunggal. Sebagai contoh, situs yang menjual buku merupakan sebuah aplikasi.
- fitur
Fitur merupakan unit fungsi dari aplikasi, seperti fitur ulasan buku pada aplikasi toko buku. Fitur terdiri dari microservice.
Fitur dapat bersifat stateless yang tidak bergantung pada jenis data apa pun, atau stateful yang memiliki dependensi pada data.
- layanan mikro
Microservice adalah komponen mandiri yang dibuat untuk mengakomodasi fitur aplikasi. Dalam artikel ini, aplikasi terdiri dari berbagai microservice yang tidak dapat dibedakan oleh pengguna. Misalnya, komponen yang menangani ulasan buku merupakan microservice.
Dalam pola microservice, aplikasi adalah gabungan dari beberapa microservice yang masing-masing memiliki tujuan khusus. Misalnya, Anda mungkin memiliki satu microservice yang menangani rating buku dan microservice lain yang menangani ulasan buku. Microservice tersebut harus dikaitkan secara longgar dan saling berantarmuka melalui API yang jelas. Microservice ini dapat ditulis dalam berbagai bahasa dan framework (seperti dalam aplikasi polyglot), dan memiliki siklus proses yang berbeda.
Untuk menentukan lebih lanjut batasan setiap microservice, Anda dapat menyimpannya dalam container menggunakan alat berikut:
- Docker adalah alat untuk mengisolasi program tingkat ruang pengguna pada tingkat sistem operasi. Docker menjalankan paket yang disebut container.
- Kubernetes adalah solusi orkestrasi terkemuka untuk workload dalam container. Kubernetes menyediakan fitur seperti penemuan layanan, load balancing, pod dan node pemulihan mandiri, serta secret dan manajemen konfigurasi.
- Google Kubernetes Engine (GKE) adalah lingkungan Kubernetes terkelola dan siap produksi dari Google Cloud.
- mesh layanan
Mesh layanan adalah software yang menghubungkan berbagai layanan, dan memberikan fitur jaringan bernilai tinggi seperti penemuan layanan, komunikasi yang aman, load balancing, pengelolaan traffic, pemantauan, dan kemampuan observasi.
Penerapan mesh layanan pada umumnya adalah dengan menyambungkan setiap layanan dengan proxy yang menyediakan fitur tersebut. Proxy layanan seringnya disebut sebagai sidecar. Peran sidecar adalah untuk menambah dan meningkatkan aplikasi tempat sidecar terpasang, yang seringnya tanpa sepengetahuan aplikasi.
- migrasi
Migrasi adalah proses untuk memindahkan fitur dari satu atau beberapa aplikasi yang berjalan di lingkungan lama ke lingkungan tujuan, seperti Google Cloud. Dalam artikel ini, migrasi dapat berupa salah satu dari jenis berikut:
- Migrasi big-bang: saat Anda memigrasikan semua fitur aplikasi sekaligus.
- Migrasi fitur demi fitur secara bertahap: saat Anda memigrasikan satu fitur pada satu waktu.
- rangkaian pengujian kepatuhan
Rangkaian pengujian kepatuhan adalah serangkaian pengujian yang dapat Anda jalankan terhadap lingkungan untuk memeriksa apakah lingkungan tersebut memenuhi serangkaian persyaratan tertentu. Jika lingkungannya valid, berarti lingkungan tersebut memenuhi persyaratan. Misalnya, Anda dapat memvalidasi respons terhadap permintaan pengujian, atau memeriksa apakah dependensi aplikasi sudah diinstal.
Anda dapat memulai dengan alat visualisasi, mesh layanan, pemantauan, dan pelacakan untuk melakukan validasi secara manual. Kemudian Anda dapat menerapkan rangkaian pengujian dan mengembangkannya seiring waktu:
- Uji beban. Anda dapat mengembangkan rangkaian pengujian dengan mengirimkan traffic pengujian secara otomatis ke lingkungan dan mengevaluasi hasilnya.
- Alat pengujian kepatuhan. Anda dapat mendesain dan mengembangkan rangkaian pengujian menggunakan alat khusus.
Mengapa memilih strategi migrasi bertahap?
Migrasi big-bang sulit dilakukan karena tantangan dan risiko yang muncul saat memigrasikan satu atau beberapa aplikasi dalam satu praktik. Ketika Anda memiliki keterbatasan dalam hal waktu dan anggaran, fokus pada migrasi big-bang tidak menyisakan banyak kapasitas untuk mengerjakan fitur aplikasi baru.
Sebaliknya, migrasi fitur demi fitur secara bertahap memiliki keseluruhan kompleksitas yang lebih rendah karena ukuran workload yang dimigrasikan lebih kecil: satu fitur memiliki jejak yang lebih kecil dibandingkan dengan keseluruhan aplikasi. Migrasi bertahap membuat Anda dapat melakukan penyebaran risiko ke seluruh peristiwa migrasi yang lebih kecil, dibandingkan saat melakukan satu praktik berisiko tinggi. Migrasi bertahap juga memungkinkan tim migrasi merencanakan, mendesain, dan mengembangkan beberapa strategi migrasi untuk mengakomodasi berbagai jenis fitur.
Anda dapat menemukan panduan tentang cara memilih fitur yang akan dimigrasikan terlebih dahulu dan cara memigrasikan fitur stateful dalam Memigrasikan aplikasi monolitik ke microservice di Google Kubernetes Engine.
Mengapa menggunakan mesh layanan?
Mesh layanan memisahkan fungsi layanan (cara logika bisnis diterapkan) dari fungsi jaringan (cara dan waktu untuk merutekan traffic ke fungsi layanan).
Di lingkungan lama, sebagian besar panggilan layanan tidak melibatkan jaringan, karena panggilan tersebut terjadi di platform monolitik. Dalam arsitektur microservice, komunikasi antarlayanan yang terjadi di jaringan dan layanan harus menangani model yang berbeda ini. Mesh layanan memisahkan fungsi untuk menangani komunikasi jaringan, sehingga Anda tidak perlu menerapkannya di setiap aplikasi. Mesh layanan juga mengurangi kompleksitas operasional jaringan karena menyediakan fitur saluran komunikasi yang aman, load balancing, pengelolaan traffic, pemantauan, dan kemampuan observasi yang siap pakai.
Di tutorial berikut, Anda menggunakan Istio sebagai mesh layanan. Fitur Istio meliputi:
- Pengelolaan traffic, kontrol traffic yang mendetail dengan aturan pemilihan rute yang lengkap untuk traffic HTTP, gRPC, WebSocket, dan TCP.
- Permintaan untuk fitur ketahanan: percobaan ulang, failover, pemutus arus listrik, dan injeksi fault.
- Lapisan kebijakan yang dapat di-plug dan API konfigurasi yang mendukung kontrol akses dan pembatasan kapasitas.
- Metrik, log, dan trace otomatis untuk semua traffic dalam cluster, termasuk cluster masuk dan keluar.
- Komunikasi antarlayanan yang aman dengan autentikasi dan otorisasi berbasis akun layanan.
- Fasilitasi tugas deployment dan pengujian, seperti pengujian A/B, peluncuran canary, injeksi fault, dan pembatasan kapasitas.
Anda juga dapat memvisualisasikan mesh layanan. Alat seperti Kiali terintegrasi dengan Istio untuk menunjukkan layanan mana yang merupakan bagian dari mesh layanan dan cara layanan tersebut terhubung.
Screenshot berikut menunjukkan contoh service graph Kiali yang merepresentasikan mesh Istio.
Dengan men-deploy dan mengonfigurasi mesh layanan, Anda dapat merutekan traffic secara dinamis ke lingkungan lama dan lingkungan target. Anda tidak perlu mengubah konfigurasi aplikasi untuk mendukung migrasi Anda karena pengelolaan traffic bersifat transparan terhadap layanan di mesh.
Meskipun pendekatan ini berfungsi dengan baik untuk fitur stateless, Anda perlu melakukan perencanaan dan pemfaktoran ulang tambahan untuk memigrasikan fitur yang bersifat stateful, sensitif terhadap latensi, atau sangat terkait dengan fitur lain:
- Stateful. Saat memigrasikan fitur stateful, Anda juga harus memigrasikan data, meminimalkan periode nonaktif, serta menangani masalah sinkronisasi dan integritas selama migrasi. Anda dapat membaca selengkapnya tentang strategi migrasi data dalam Memigrasikan aplikasi monolitik ke microservice di Google Kubernetes Engine.
- Sensitif terhadap latensi. Jika fitur sensitif terhadap latensi saat berkomunikasi dengan fitur lain, Anda mungkin perlu men-deploy komponen tambahan selama proses migrasi. Proxy yang mampu mengambil data atau lapisan cache biasanya digunakan untuk memitigasi sensitivitas ini.
- Sangat terkait dengan fitur lainnya. Jika dua atau beberapa fitur sangat terkait, Anda mungkin harus memigrasikannya secara bersamaan. Meskipun lebih mudah daripada memigrasikan seluruh aplikasi, pendekatan ini mungkin lebih sulit dilakukan daripada memigrasikan satu fitur.
Rencana migrasi
Bagian ini menunjukkan rencana untuk melakukan migrasi fitur demi fitur secara bertahap menggunakan mesh layanan. Rencana ini terdiri dari fase-fase berikut:
- Menilai lingkungan lama.
- Membangun dasar dalam lingkungan target.
- Men-deploy layanan di lingkungan target dan memulai pemilihan rute traffic ke lingkungan target.
- Menghentikan pemilihan rute traffic ke lingkungan lama.
- Menghentikan lingkungan lama.
Menilai lingkungan lama
Sebelum aktivitas desain atau penerapan migrasi apa pun, Anda menilai lingkungan lama untuk mengumpulkan informasi dan menetapkan serangkaian persyaratan untuk lingkungan target serta dasar pengukuran untuk pengujian dan validasi. Anda memulai dengan membuat katalog yang berisi semua fitur aplikasi yang akan dimigrasikan. Untuk masing-masing fitur, Anda harus bisa menjawab serangkaian pertanyaan (tidak lengkap) berikut:
- Apa saja persyaratan performa dan lingkungan runtime?
- Apakah ada dependensi pada fitur lainnya?
- Apakah fitur ini penting bagi bisnis?
- Apakah fitur ini stateless atau stateful?
- Berapa banyak pemfaktoran ulang yang diharapkan untuk memigrasikannya?
- Apakah fitur ini dapat memiliki jendela migrasi sistem?
Anda dapat membaca selengkapnya tentang proses penilaian dan fitur yang perlu dimigrasikan. Kemudian, jalankan rangkaian pengujian kepatuhan terhadap lingkungan lama sebagai dasar pengukuran dan juga lingkungan target selama dan setelah migrasi.
Rangkaian pengujian Anda harus berfokus pada aspek berikut untuk divalidasi selama migrasi:
- Penyediaan. Menyediakan resource yang diperlukan di lingkungan sebelum Anda mengonfigurasinya.
- Konfigurasi. Setelah Anda menyediakan resource di lingkungan, konfigurasikan resource tersebut sesuai kebutuhan aplikasi Anda. Memiliki rangkaian pengujian konfigurasi memastikan bahwa lingkungan siap untuk menghosting aplikasi Anda.
- Logika bisnis. Setelah memvalidasi penyediaan dan konfigurasi lingkungan, validasi logika bisnis aplikasi Anda. Misalnya, Anda dapat memvalidasi respons terhadap permintaan.
InSpec, RSpec, dan Serverspec adalah alat untuk mengembangkan rangkaian pengujian kepatuhan otomatis. Alat ini tidak bergantung pada platform dan dapat diperluas sehingga Anda dapat menerapkan kontrol sendiri, mulai dari kontrol bawaan.
Diagram berikut menunjukkan contoh lingkungan lama:
Menyediakan lingkungan target
Setelah memiliki cukup informasi tentang lingkungan dan aplikasi yang akan dimigrasikan, Anda dapat menyediakan lingkungan target sesuai dengan persyaratan yang Anda tetapkan selama penilaian.
Selama fase ini, Anda dapat menggunakan rangkaian pengujian kepatuhan untuk memvalidasi lingkungan target. Anda mungkin harus mengupdate rangkaian pengujian untuk memperhitungkan perbedaan tertunda antara lingkungan lama dan target, seperti hardware dan topologi jaringan. Perlu diingat bahwa Anda berpindah dari lingkungan lokal, yang Anda memiliki kontrol penuh, ke lingkungan cloud publik, yang biasanya Anda tidak memiliki akses penuh terhadap keseluruhan stack.
Karena Anda menyediakan lingkungan baru, sebaiknya terapkan metodologi infrastruktur sebagai code agar infrastruktur anda dapat diaudit, diulang, dan disediakan secara otomatis.
Diagram berikut menunjukkan lingkungan lama dan lingkungan target yang baru disediakan dan saat ini masih kosong.
Mengonfigurasi mesh layanan
Langkah Anda berikutnya adalah menyiapkan mesh layanan yang mencakup lingkungan lama dan lingkungan target. Mesh layanan menangani koneksi berbagai microservice yang berjalan di lingkungan lama yang akan dimigrasikan ke lingkungan target. Pada fase ini, mesh layanan masih kosong, dan menunggu layanan didaftarkan. Mesh layanan belum menerima traffic produksi apa pun.
Diagram berikut menunjukkan lingkungan lama dan mesh layanan kosong di lingkungan target.
Menambahkan layanan di lingkungan lama ke mesh
Dalam contoh ini, lingkungan lama tidak terintegrasi secara langsung dengan mesh layanan. Integrasi tersebut mengharuskan Anda mendaftarkan semua layanan yang berjalan di lingkungan lama secara manual dengan mesh layanan. Jika lingkungan Anda telah berjalan di Kubernetes, Anda dapat mengotomatiskan pendaftaran berkat integrasi native dengan API mesh layanan.
Di tahap ini, klien masih menggunakan antarmuka lingkungan lama untuk mengakses microservice yang Anda migrasikan. Mesh layanan belum menerima traffic produksi apa pun.
Diagram berikut menunjukkan layanan yang berjalan di lingkungan lama ditambahkan ke mesh layanan.
Mengekspos layanan melalui mesh layanan
Setelah lingkungan lama terdaftar, Anda menggunakan mesh layanan untuk mengekspos microservice yang berjalan di lingkungan lama. Di tahap ini Anda juga secara bertahap merutekan traffic ke microservice melalui antarmuka lingkungan lama ke antarmuka lingkungan target.
Klien tidak mengalami gangguan layanan, karena mereka mengakses antarmuka kedua lingkungan melalui lapisan load balancing. Selain itu, pemilihan rute traffic di dalam mesh layanan bersifat transparan pada klien. Klien tidak akan tahu bahwa perubahan konfigurasi pemilihan rute telah terjadi.
Diagram berikut menunjukkan layanan yang berjalan di lingkungan lama diekspos melalui mesh layanan.
Men-deploy layanan di lingkungan target
Di fase ini, Anda akan men-deploy microservice di lingkungan target. Di sini diasumsikan bahwa Anda telah memasukkan microservice ini ke dalam container. Setelah proses tersebut selesai, Anda dapat memilih strategi deployment untuk menginisialisasi workload yang akan dimigrasikan di lingkungan target:
- Deployment massal: Anda men-deploy seluruh instance microservice secara bersamaan.
- Deployment bertahap: Anda men-deploy satu microservice dalam satu waktu.
Instance microservice di lingkungan target belum menerima traffic produksi apa pun.
Saat memigrasikan microservice stateful, Anda juga harus memigrasikan data terkait, meminimalkan periode nonaktif dan menangani masalah sinkronisasi dan integritas. Baca selengkapnya tentang strategi migrasi data.
Microservice yang berjalan di lingkungan target secara otomatis terdaftar di mesh layanan, berkat integrasi native dengan Kubernetes dan Istio. Pada tahap ini, klien masih menggunakan microservice yang berjalan di lingkungan lama yang diekspos melalui mesh layanan. Microservice yang berjalan di lingkungan target masih belum menerima traffic produksi apa pun.
Diagram berikut menunjukkan layanan yang diperluas yang tidak menerima traffic produksi apa pun, dan layanan di lingkungan lama yang diekspos menggunakan mesh layanan.
Menyiapkan aturan pemilihan rute untuk memisahkan traffic
Sekarang Anda menyiapkan aturan pemilihan rute untuk memisahkan traffic produksi antara layanan yang berjalan di lingkungan lama dan layanan yang berjalan di lingkungan target menggunakan mesh layanan. Anda dapat memulai dengan merutekan sebagian kecil traffic produksi ke instance microservice yang berjalan di lingkungan target. Setelah Anda membangun keyakinan di lingkungan target melalui rangkaian pengujian dan pemantauan yang ketat, Anda dapat meningkatkan porsi total traffic seiring waktu.
Karena permintaan klien dirutekan di kedua lingkungan, Anda memerlukan perencanaan dan koordinasi tambahan untuk microservice stateful karena data terkait juga harus dimigrasikan dan ada kemungkinan fase sementara dengan berbagai sumber terpercaya akan muncul selama migrasi.
Diagram berikut menunjukkan pemisahan traffic antara microservice yang berjalan di lingkungan target dan yang berjalan di lingkungan lama.
Anda sebaiknya juga mempertajam aturan pemilihan rute untuk tidak mengizinkan permintaan lintas lingkungan, sehingga saat permintaan klien mencapai lingkungan, baik lama maupun target, permintaan tetap berada di lingkungan tersebut.
Menyiapkan aturan untuk merutekan traffic ke lingkungan target
Di fase ini, Anda akan mengupdate aturan pemilihan rute untuk merutekan traffic secara bertahap ke layanan yang berjalan di lingkungan target saja.
Diagram berikut menunjukkan traffic sekarang dirutekan ke lingkungan target saja, sedangkan lingkungan lama disimpan sebagai cadangan.
Menghentikan lingkungan lama
Di fase ini, Anda akan menghentikan lingkungan lama.
Sebelum menghentikan lingkungan lama, pastikan hal berikut:
- Tidak ada traffic yang dirutekan ke instance microservice yang berjalan di lingkungan lama.
- Tidak ada traffic yang masuk melalui antarmuka lingkungan lama.
- Lingkungan target telah sepenuhnya divalidasi.
Saat kondisi ini terpenuhi, Anda dapat mengupdate data DNS untuk mengarah ke load balancer yang Anda siapkan selama fase penyediaan lingkungan target.
Diagram berikut hanya menunjukkan lingkungan target saja, karena lingkungan lama telah dihentikan.
Langkah berikutnya
- Baca tentang Google Kubernetes Engine.
- Baca tentang Istio.
- Baca tutorial terkait.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.