Dokumen ini menunjukkan arsitektur yang menggunakan mesh layanan Istio untuk bermigrasi dari lingkungan lama, seperti pusat data lokal yang menjalankan aplikasi di virtual machine, ke Google Kubernetes Engine (GKE). Menggunakan mesh layanan dapat mengurangi kompleksitas migrasi dan pemfaktoran ulang karena mesh layanan memisahkan fungsi jaringan dari fungsi layanan.
Dokumen ini menjelaskan alasan migrasi dan menjelaskan fase tingkat tingginya. Anda dapat menggunakan arsitektur ini untuk melakukan migrasi dalam satu operasi (terkadang disebut migrasi big-bang), atau untuk melakukan migrasi fitur demi fitur secara bertahap. Dokumen deployment yang menyertainya akan memandu Anda dalam melakukan contoh migrasi.
Panduan deployment dan arsitektur ini ditujukan bagi para profesional IT yang mengelola infrastruktur kompleks yang ingin mereka migrasikan dan modernisasi secara bertahap, sekaligus meminimalkan hal-hal berikut:
- Periode nonaktif
- Upaya pemfaktoran ulang
- Kompleksitas operasional jaringan Anda
Konsep yang dijelaskan di atas berlaku untuk semua cloud, sehingga dokumen ini mengasumsikan bahwa Anda telah memahami teknologi, container, dan microservice cloud.
Seperti dijelaskan dalam artikel Bermigrasi ke Google Cloud: Memulai, ada beberapa pola untuk bermigrasi ke cloud. Arsitektur dalam dokumen ini menggunakan pola pemfaktoran ulang (terkadang disebut move andimprove), dengan pola 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.
Arsitektur
Diagram berikut menunjukkan cara menggunakan mesh layanan untuk mengarahkan traffic ke microservice yang berjalan di lingkungan sumber atau ke Google Cloud:
Arsitektur ini mencakup komponen berikut:
Lingkungan sumber, dalam hal ini instance Compute Engine yang menghosting contoh beban kerja untuk dimigrasikan. Lingkungan sumber juga dapat berada di infrastruktur lokal atau dihosting di platform cloud lainnya.
Mesh layanan, dalam hal ini Istio Gateway, yang menautkan berbagai layanan secara bersamaan. Mesh layanan menyediakan fitur jaringan bernilai tinggi seperti penemuan layanan, komunikasi yang aman, load balancing, pengelolaan traffic, dan kemampuan observasi.
Implementasi standar mesh layanan menyambungkan setiap layanan dengan proxy yang menyediakan fitur tersebut. Proxy layanan paling sering disebut sebagai file bantuan. Peran file bantuan adalah untuk menambah dan meningkatkan aplikasi yang melekat padanya, sering kali tanpa menyadari aplikasi tersebut. Dalam panduan deployment yang menyertai, Anda menggunakan Envoy sebagai proxy file bantuan.
Beban kerja yang berisi aplikasi yang terdiri dari microservice. Microservice adalah komponen mandiri yang dibuat untuk mengakomodasi fitur aplikasi. Dalam arsitektur ini, aplikasi terdiri dari berbagai microservice yang tidak dapat dibedakan oleh pengguna. Misalnya, komponen yang menangani ulasan buku adalah 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. Class ini dapat ditulis dalam berbagai bahasa dan framework (seperti dalam aplikasi Polyglot), dan dapat memiliki siklus proses yang berbeda.
Container yang berfungsi untuk menentukan lebih lanjut batas setiap microservice. Karena lingkungan target dalam arsitektur ini dirancang dengan Kubernetes, sebaiknya simpan microservice dalam container menggunakan alat berikut:
- Docker adalah alat untuk mengisolasi program tingkat ruang pengguna di tingkat sistem operasi. Kode ini menjalankan paket yang disebut containers.
- Kubernetes adalah solusi orkestrasi terkemuka untuk workload dalam container. Library ini menyediakan fitur seperti penemuan layanan, load balancing, pod dan node pemulihan mandiri, serta pengelolaan secret dan konfigurasi.
- GKE adalah lingkungan Kubernetes terkelola dan siap produksi, yang merupakan bagian dari Google Cloud.
Untuk mengetahui saran tentang cara mem-build microservice ini dalam container, baca Praktik terbaik untuk membuat container dan Praktik terbaik untuk mengoperasikan container.
Untuk melakukan migrasi menggunakan mesh layanan, selesaikan fase berikut:
- Menilai lingkungan lama: Kumpulkan informasi dan tetapkan serangkaian persyaratan untuk lingkungan target serta dasar pengukuran untuk pengujian dan validasi.
- Bangun fondasi di lingkungan target: Sediakan lingkungan target Anda dan terapkan metodologi infrastruktur sebagai kode agar infrastruktur Anda dapat diaudit, dapat diulang, dan otomatis disediakan.
- Men-deploy layanan dan mulai mengarahkan traffic ke lingkungan target: Selesaikan satu operasi untuk men-deploy semua instance microservice secara bersamaan, atau selesaikan deployment bertahap untuk men-deploy satu microservice dalam satu waktu.
- Berhenti mengarahkan traffic ke lingkungan lama: Siapkan aturan perutean untuk mengarahkan traffic ke layanan yang berjalan di lingkungan target saja.
- Hentikan lingkungan lama: Perbarui data DNS agar mengarah ke load balancer yang Anda siapkan selama fase penyediaan lingkungan target.
Dokumen ini menjelaskan beberapa pertimbangan desain untuk jenis migrasi ini, dan panduan deployment yang menyertainya memberikan langkah-langkah mendetail untuk menyelesaikan migrasi.
Pertimbangan desain
Bagian ini berisi panduan untuk membantu Anda mengembangkan arsitektur yang memenuhi persyaratan spesifik Anda dalam hal keandalan, efisiensi operasional, biaya, dan pengoptimalan performa.
Keandalan
Bagian berikut menjelaskan pertimbangan untuk keandalan migrasi.
Gunakan strategi migrasi bertahap
Meskipun arsitektur ini dapat digunakan untuk migrasi operasi tunggal, sebaiknya gunakan strategi migrasi bertahap. Menyelesaikan migrasi dalam satu operasi sulit dilakukan karena tantangan dan risiko yang diperlukan dalam memigrasikan satu atau beberapa aplikasi sekaligus. Saat Anda memiliki keterbatasan pada waktu dan anggaran, berfokus pada migrasi operasi tunggal 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 memungkinkan Anda mendistribusikan risiko pada peristiwa migrasi yang lebih kecil, bukan satu latihan dengan risiko tinggi. Migrasi bertahap juga memungkinkan tim migrasi merencanakan, mendesain, dan mengembangkan beberapa strategi migrasi untuk mengakomodasi berbagai jenis fitur.
Untuk mendapatkan panduan cara memilih fitur mana yang akan dimigrasikan terlebih dahulu dan cara memigrasikan fitur stateful, lihat Memilih aplikasi yang akan dimigrasikan terlebih dahulu di bagian "Migrate to Google Cloud: Menilai dan menemukan workload Anda".
Menggunakan rangkaian pengujian kepatuhan
Untuk membantu memfasilitasi migrasi, sebaiknya gunakan rangkaian pengujian kepatuhan. Paket pengujian kepatuhan adalah serangkaian pengujian yang dapat Anda jalankan terhadap suatu 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 pemantauan, pelacakan, dan visualisasi mesh layanan untuk validasi manual. Kemudian, Anda dapat menerapkan rangkaian pengujian dan mengembangkannya dari waktu ke waktu dengan cara berikut:
- Uji beban: Anda dapat mengembangkan paket pengujian dengan otomatis mengirimkan traffic pengujian ke lingkungan dan mengevaluasi hasilnya.
- Alat pengujian kepatuhan: Anda dapat mendesain dan mengembangkan rangkaian pengujian menggunakan alat khusus.
Jalankan rangkaian pengujian kepatuhan terhadap lingkungan lama sebagai dasar pengukuran dan juga terhadap lingkungan target selama dan setelah migrasi.
Rangkaian pengujian Anda harus berfokus pada aspek berikut untuk divalidasi selama migrasi:
- Penyediaan: Sediakan resource yang Anda perlukan di lingkungan sebelum mengonfigurasinya.
- Konfigurasi: Setelah 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.
Chef InSpec, RSpec, dan Serverspec adalah alat untuk mengembangkan rangkaian pengujian kepatuhan otomatis. Alat ini berfungsi pada platform apa pun, dan dapat diperluas sehingga Anda dapat menerapkan kontrol Anda sendiri, mulai dari kontrol bawaan.
Saat menyediakan lingkungan target, Anda dapat menggunakan rangkaian pengujian kepatuhan untuk memvalidasinya. Anda mungkin harus mengupdate rangkaian pengujian untuk memperhitungkan perbedaan pada akhirnya antara lingkungan lama dan target, seperti topologi jaringan dan hardware. Perlu diingat bahwa Anda berpindah dari lingkungan lokal, yang memiliki kontrol penuh, ke lingkungan cloud publik, yang biasanya Anda tidak memiliki akses penuh ke seluruh stack.
Sebelum mengarahkan traffic dari lapisan load balancing lingkungan lama ke lingkungan target, sebaiknya jalankan rangkaian pengujian kepatuhan logika bisnis terhadap microservice yang diekspos oleh lingkungan target. Paket pengujian dapat membantu memastikan bahwa microservice berfungsi seperti yang diharapkan. Misalnya, Anda dapat memvalidasi respons yang ditampilkan oleh layanan yang diekspos oleh mesh layanan. Anda dapat menyimpan rute asli sebagai opsi cadangan jika Anda perlu melakukan roll back perubahan dan kembali ke lingkungan lama. Dengan mengarahkan sebagian kecil traffic production ke instance microservice yang berjalan di lingkungan target, Anda dapat membangun keyakinan terhadap lingkungan target dan meningkatkan total traffic seiring waktu.
Melarang permintaan lintas-lingkungan
Selama fase uji kepatuhan, sebaiknya Anda menyaring aturan perutean untuk melarang permintaan lintas-lingkungan, sehingga saat permintaan klien mencapai lingkungan, baik yang lama maupun target, permintaan tersebut akan tetap berada dalam lingkungan tersebut. Melarang permintaan lintas lingkungan akan membantu memastikan bahwa pengujian memvalidasi lingkungan target dengan benar. Jika Anda tidak melarang permintaan ini, pengujian dapat melaporkan keberhasilan di lingkungan sumber, bukan di lingkungan target tanpa sepengetahuan Anda.
Menghentikan lingkungan lama
Sebelum menghentikan lingkungan lama, pastikan semua hal berikut sudah benar:
- 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. Jangan menghentikan lingkungan lama kecuali jika Anda yakin bahwa lingkungan target telah divalidasi. Selain itu, jangan membatasi validasi hanya untuk logika bisnis, tetapi pertimbangkan persyaratan nonfungsional lainnya seperti performa dan skalabilitas.
Efisiensi operasional
Bagian berikut menjelaskan pertimbangan untuk efisiensi operasional dari migrasi Anda.
Menilai lingkungan lama
Sebelum mendesain atau mengimplementasikan rencana migrasi, Anda harus menilai lingkungan lama untuk mengumpulkan informasi dan menetapkan serangkaian persyaratan bagi lingkungan target serta dasar pengukuran untuk pengujian dan validasi. Anda memulai dengan membuat katalog yang berisi semua fitur aplikasi yang akan dimigrasikan. Untuk setiap fitur, Anda harus dapat menjawab serangkaian pertanyaan yang 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?
Untuk informasi selengkapnya, lihat Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda.
Resource stateless versus stateful
Arsitektur ini menggunakan mesh layanan karena memisahkan fungsi layanan (cara logika bisnis diterapkan) dari fungsi jaringan (cara dan waktu mengarahkan traffic ke fungsi layanan). Dalam deployment yang menyertainya, Anda menggunakan Istio sebagai mesh layanan.
Di lingkungan lama, sebagian besar panggilan layanan tidak melibatkan jaringan karena terjadi di platform monolitik. Dalam arsitektur microservice, komunikasi antarlayanan terjadi melalui jaringan, dan layanan harus menangani model yang berbeda ini. Mesh layanan memisahkan fungsi untuk menangani komunikasi jaringan, jadi Anda tidak perlu menerapkannya di setiap aplikasi. Mesh layanan juga mengurangi kompleksitas operasional jaringan karena menyediakan saluran komunikasi yang aman, load balancing, pengelolaan traffic, dan fitur kemampuan observasi yang tidak memerlukan konfigurasi apa pun.
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 untuk meminimalkan periode nonaktif dan mengurangi masalah sinkronisasi dan integritas selama migrasi. Anda dapat membaca strategi migrasi data lebih lanjut di bagian Mengevaluasi pendekatan migrasi data dalam artikel "Migrasi ke Google Cloud: Mentransfer set data besar".
- 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 dapat mengambil data data atau lapisan cache biasanya digunakan untuk mengurangi sensitivitas ini.
- Terkait dengan fitur lainnya: Jika dua fitur atau lebih saling terkait, Anda mungkin harus memigrasikannya secara bersamaan. Meskipun lebih mudah daripada memigrasikan seluruh aplikasi, pendekatan ini mungkin lebih sulit dilakukan daripada memigrasikan satu fitur.
Mendaftarkan layanan dengan mesh layanan
Karena lingkungan lama Anda tidak terintegrasi langsung dengan mesh layanan, saat mengonfigurasi migrasi, Anda harus mendaftarkan semua layanan yang berjalan di lingkungan lama secara manual dengan mesh layanan. Jika lingkungan Anda sudah berjalan di Kubernetes, Anda dapat mengotomatiskan pendaftaran menggunakan integrasi bawaan dengan API mesh layanan.
Setelah mendaftarkan lingkungan lama, gunakan mesh layanan untuk mengekspos microservice yang berjalan di lingkungan lama. Kemudian, Anda dapat merutekan traffic secara bertahap ke microservice dari antarmuka lingkungan lama ke antarmuka lingkungan target.
Klien tidak akan melihat gangguan layanan apa pun, karena mereka mengakses antarmuka kedua lingkungan melalui lapisan load balancing. Pemilihan rute traffic di dalam mesh layanan bersifat transparan bagi klien, sehingga klien tidak akan tahu bahwa konfigurasi pemilihan rute telah diubah.
Pengoptimalan biaya
Arsitektur ini menggunakan komponen Google Cloud yang dapat ditagih berikut:
Saat men-deploy arsitektur, Anda dapat menggunakan kalkulator harga untuk membuat perkiraan biaya berdasarkan penggunaan yang Anda proyeksikan.
Pengoptimalan performa
Dalam arsitektur ini, traffic hampir sama terbagi antara layanan yang berjalan di Compute Engine dan layanan yang berjalan di GKE. Mesh layanan menyeimbangkan traffic di antara instance layanan yang dipilih, baik saat dijalankan di cluster GKE maupun di instance Compute Engine. Jika Anda ingin semua traffic melewati mesh layanan, Anda harus mengonfigurasi ulang beban kerja yang berjalan di Compute Engine agar mengarah ke layanan di mesh layanan, bukan terhubung ke layanan tersebut secara langsung. Anda dapat mengonfigurasi kebijakan load balancing untuk revisi setiap layanan dengan resource DestinationRule.
Deployment
Untuk men-deploy arsitektur ini, lihat Men-deploy migrasi dengan perluasan mesh Istio.
Langkah selanjutnya
- Baca tentang GKE.
- Baca tentang Istio.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.