Bermigrasi dari AWS ke Google Cloud: Bermigrasi dari AWS Lambda ke Cloud Run

Google Cloud menyediakan alat, produk, panduan, dan layanan profesional untuk membantu memigrasikan workload serverless dari Amazon Web Services Lambda ke Google Cloud. Meskipun Google Cloud menyediakan beberapa layanan tempat Anda dapat mengembangkan dan men-deploy aplikasi serverless, dokumen ini berfokus pada migrasi ke Cloud Run, lingkungan runtime serverless. AWS Lambda dan Cloud Run memiliki kesamaan dalam hal penyediaan resource otomatis, penskalaan oleh penyedia cloud, dan model harga bayar per penggunaan.

Dokumen ini membantu Anda merancang, menerapkan, dan memvalidasi rencana untuk memigrasikan workload serverless dari AWS Lambda ke Cloud Run. Selain itu, panduan ini menawarkan panduan bagi mereka yang mengevaluasi potensi manfaat dan proses migrasi tersebut.

Dokumen ini adalah bagian dari rangkaian multi-bagian tentang migrasi dari AWS keGoogle Cloud yang mencakup dokumen berikut:

Untuk informasi selengkapnya terkait cara memilih lingkungan runtime serverless yang tepat untuk logika bisnis Anda, lihat Memilih lingkungan runtime container terkelola. Untuk pemetaan komprehensif antara AWS dan Google Cloud layanan, lihat membandingkan layanan AWS dan Azure dengan Google Cloud layanan.

Untuk migrasi ke Google Cloudini, sebaiknya ikuti framework migrasi yang dijelaskan dalam Bermigrasi ke Google Cloud: Mulai.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Anda dapat bermigrasi dari lingkungan sumber ke Google Cloud dalam serangkaian iterasi—misalnya, Anda mungkin memigrasikan beberapa workload terlebih dahulu dan yang lainnya nanti. Untuk setiap iterasi migrasi terpisah, Anda mengikuti fase framework migrasi umum:

  1. Lakukan penilaian dan temukan workload dan data Anda.
  2. Rencanakan dan bangun fondasi pada Google Cloud.
  3. Migrasikan beban kerja dan data Anda ke Google Cloud.
  4. Optimalkan lingkungan Google Cloud Anda.

Untuk mengetahui informasi selengkapnya tentang fase framework ini, lihat Bermigrasi ke Google Cloud: Memulai.

Untuk mendesain rencana migrasi yang efektif, sebaiknya Anda memvalidasi setiap langkah rencana, dan memastikan Anda memiliki strategi rollback. Untuk membantu Anda memvalidasi rencana migrasi, lihat Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

Migrasi workload serverless sering kali lebih dari sekadar memindahkan fungsi dari satu penyedia cloud ke penyedia cloud lainnya. Karena aplikasi berbasis cloud bergantung pada web layanan yang saling terhubung, migrasi dari AWS ke Google Cloud mungkin memerlukan penggantian layanan AWS dependen dengan Google Cloud layanan. Misalnya, perhatikan skenario saat fungsi Lambda Anda berinteraksi dengan Amazon SQS dan Amazon SNS. Untuk memigrasikan fungsi ini, Anda mungkin perlu mengadopsi Pub/Sub dan Cloud Tasks untuk mencapai fungsi serupa.

Migrasi juga menghadirkan peluang berharga bagi Anda untuk meninjau arsitektur aplikasi dan keputusan desain secara menyeluruh. Melalui peninjauan ini, Anda mungkin menemukan peluang untuk melakukan hal berikut:

  • Optimalkan dengan Google Cloud fitur bawaan: Pelajari apakah Google Cloud layanan menawarkan keunggulan unik atau lebih sesuai dengan persyaratan aplikasi Anda.
  • Sederhanakan arsitektur Anda: Nilai apakah penyederhanaan dapat dilakukan dengan menggabungkan fungsi atau menggunakan layanan secara berbeda dalamGoogle Cloud.
  • Meningkatkan efisiensi biaya: Evaluasi potensi perbedaan biaya saat menjalankan aplikasi yang difaktorkan ulang di infrastruktur yang disediakan di Google Cloud.
  • Meningkatkan efisiensi kode: Faktorkan ulang kode Anda bersama dengan proses migrasi.

Rencanakan migrasi Anda secara strategis. Jangan menganggap migrasi Anda sebagai latihan hosting ulang (lift-and-shift). Gunakan migrasi Anda sebagai kesempatan untuk meningkatkan kualitas desain dan kode secara keseluruhan dari aplikasi serverless Anda.

Menilai lingkungan sumber

Pada fase penilaian, Anda menentukan persyaratan dan dependensi untuk memigrasikan lingkungan sumber ke Google Cloud.

Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda perlu mendapatkan pengetahuan mendalam tentang workload yang ingin dimigrasikan, persyaratannya, dependensinya, dan lingkungan Anda saat ini. Anda harus memahami titik awal agar berhasil merencanakan dan menjalankan migrasi Google Cloud.

Fase penilaian terdiri dari tugas-tugas berikut:

  1. Mem-build inventaris workload yang komprehensif.
  2. Membuat katalog workload Anda sesuai dengan properti dan dependensinya.
  3. Latih dan ajari tim Anda tentang Google Cloud.
  4. Buat eksperimen dan bukti konsep di Google Cloud.
  5. Hitung total biaya kepemilikan (TCO) lingkungan target.
  6. Pilih strategi migrasi untuk workload Anda.
  7. Pilih alat migrasi Anda.
  8. Tentukan jadwal dan rencana migrasi.
  9. Validasi rencana migrasi Anda.

Untuk mengetahui informasi selengkapnya tentang fase penilaian dan tugas ini, lihat Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda. Bagian di bawah ini didasarkan pada informasi dalam dokumen tersebut.

Membangun inventaris workload AWS Lambda Anda

Untuk menentukan cakupan migrasi, Anda membuat inventaris dan mengumpulkan informasi tentang workload AWS Lambda.

Untuk mem-build inventaris beban kerja AWS Lambda, sebaiknya terapkan mekanisme pengumpulan data berdasarkan AWS API, alat developer AWS, dan antarmuka command line AWS.

Setelah membangun inventaris, sebaiknya Anda mengumpulkan informasi tentang setiap workload AWS Lambda dalam inventaris. Untuk setiap workload, fokuslah pada aspek yang membantu Anda mengantisipasi potensi friksi. Selain itu, analisis workload tersebut untuk memahami cara memodifikasi workload dan dependensinya sebelum bermigrasi ke Cloud Run. Sebaiknya Anda mulai dengan mengumpulkan data tentang aspek berikut dari setiap workload AWS Lambda:

  • Kasus penggunaan dan desain
  • Repositori kode sumber
  • Artefak deployment
  • Pemanggilan, pemicu, dan output
  • Lingkungan runtime dan eksekusi
  • Konfigurasi workload
  • Kontrol akses dan izin
  • Persyaratan kepatuhan dan peraturan
  • Proses penyebaran dan operasional

Kasus penggunaan dan desain

Mengumpulkan informasi tentang kasus penggunaan dan desain workload akan membantu dalam mengidentifikasi strategi migrasi yang sesuai. Informasi ini juga akan membantu Anda memahami apakah Anda perlu memodifikasi workload dan dependensinya sebelum migrasi. Untuk setiap workload, sebaiknya lakukan hal berikut:

  • Mendapatkan insight tentang kasus penggunaan tertentu yang dilayani workload, dan mengidentifikasi dependensi dengan sistem, resource, atau proses lain.
  • Menganalisis desain dan arsitektur workload.
  • Nilai persyaratan latensi beban kerja.

Repositori kode sumber

Menginventarisasi kode sumber fungsi AWS Lambda akan sangat membantu jika Anda perlu melakukan pemfaktoran ulang workload AWS Lambda agar kompatibel dengan Cloud Run. Pembuatan inventaris ini melibatkan pelacakan codebase, yang biasanya disimpan dalam sistem kontrol versi seperti Git atau di platform pengembangan seperti GitHub atau GitLab. Inventaris kode sumber sangat penting untuk proses DevOps Anda, seperti pipeline continuous integration dan continuous development (CI/CD), karena proses ini juga perlu diperbarui saat Anda bermigrasi ke Cloud Run.

Artefak deployment

Mengetahui artefak deployment apa yang diperlukan oleh workload merupakan komponen lain dalam membantu Anda memahami apakah Anda mungkin perlu memfaktorkan ulang workload AWS Lambda Anda. Untuk mengidentifikasi artefak deployment yang diperlukan workload, kumpulkan informasi berikut:

  • Jenis paket deployment untuk men-deploy workload.
  • Semua lapisan AWS Lambda yang berisi kode tambahan, seperti library dan dependensi lainnya.
  • Semua ekstensi AWS Lambda yang diandalkan oleh workload.
  • Penentu yang Anda konfigurasi untuk menentukan versi dan alias.
  • Versi beban kerja yang di-deploy.

Pemanggilan, pemicu, dan output

AWS Lambda mendukung beberapa mekanisme pemanggilan, seperti pemicu, dan model pemanggilan yang berbeda, seperti pemanggilan sinkron dan pemanggilan asinkron. Untuk setiap workload AWS Lambda, sebaiknya Anda mengumpulkan informasi berikut yang terkait dengan pemicu dan pemanggilan:

  • Pemetaan sumber peristiwa dan pemicu yang memanggil workload.
  • Apakah beban kerja mendukung pemanggilan sinkron dan asinkron.
  • URL beban kerja dan endpoint HTTP(S).

Workload AWS Lambda Anda dapat berinteraksi dengan resource dan sistem lain. Anda perlu mengetahui resource apa yang menggunakan output dari workload AWS Lambda Anda, dan bagaimana resource tersebut memakai output tersebut. Pengetahuan ini membantu Anda menentukan apakah perlu mengubah apa pun yang mungkin bergantung pada output tersebut, seperti sistem atau workload lain. Untuk setiap workload AWS Lambda, sebaiknya Anda mengumpulkan informasi berikut tentang resource dan sistem lainnya:

  • Resource tujuan yang mungkin menjadi tujuan pengiriman peristiwa oleh workload.
  • Tujuan yang menerima catatan informasi untuk pemanggilan asinkron.
  • Format untuk peristiwa yang diproses beban kerja.
  • Cara beban kerja AWS Lambda dan ekstensinya berinteraksi dengan AWS Lambda API, atau API AWS lainnya.

Agar dapat berfungsi, workload AWS Lambda Anda dapat menyimpan data persisten dan berinteraksi dengan layanan AWS lainnya. Untuk setiap workload AWS Lambda, sebaiknya Anda mengumpulkan informasi berikut tentang data dan layanan lainnya:

  • Apakah workload mengakses virtual private cloud (VPC) atau jaringan pribadi lainnya.
  • Cara workload menyimpan data persisten, seperti menggunakan penyimpanan data efemeral dan Amazon Elastic File System (EFS).

Lingkungan runtime dan eksekusi

AWS Lambda mendukung beberapa lingkungan eksekusi untuk workload Anda. Untuk memetakan lingkungan eksekusi AWS Lambda ke lingkungan eksekusi Cloud Run dengan benar, sebaiknya evaluasi hal berikut untuk setiap workload AWS Lambda:

  • Lingkungan eksekusi beban kerja.
  • Arsitektur kumpulan petunjuk prosesor komputer tempat beban kerja berjalan.

Jika workload AWS Lambda Anda berjalan di lingkungan runtime khusus bahasa, pertimbangkan hal berikut untuk setiap workload AWS Lambda:

  • Jenis, versi, dan ID unik lingkungan runtime khusus bahasa.
  • Setiap modifikasi yang Anda terapkan pada lingkungan runtime.

Konfigurasi workload

Untuk mengonfigurasi workload saat Anda memigrasikannya dari AWS Lambda ke Cloud Run, sebaiknya nilai cara Anda mengonfigurasi setiap workload AWS Lambda.

Untuk setiap workload AWS Lambda, kumpulkan informasi tentang setelan konkurensi dan skalabilitas berikut:

  • Kontrol konkurensi.
  • Setelan skalabilitas.
  • Konfigurasi instance beban kerja, dalam hal jumlah memori yang tersedia dan waktu eksekusi maksimum yang diizinkan.
  • Apakah beban kerja menggunakan AWS Lambda SnapStart, konkurensi yang dicadangkan, atau konkurensi yang disediakan untuk mengurangi latensi.
  • Variabel lingkungan yang Anda konfigurasikan, serta variabel yang dikonfigurasi oleh AWS Lambda dan beban kerja yang bergantung.
  • Kontrol akses berbasis atribut dan tag.
  • Mesin status untuk menangani kondisi luar biasa.
  • File image dasar dan konfigurasi (seperti Dockerfile) untuk paket deployment yang menggunakan image container.

Kontrol akses dan izin

Sebagai bagian dari penilaian, sebaiknya Anda menilai persyaratan keamanan beban kerja AWS Lambda Anda dan konfigurasinya dalam hal kontrol akses dan pengelolaan. Informasi ini penting jika Anda perlu menerapkan kontrol serupa di lingkungan Google Cloud Anda. Untuk setiap beban kerja, pertimbangkan hal berikut:

  • Peran eksekusi dan izin.
  • Konfigurasi pengelolaan akses dan identitas yang digunakan workload dan lapisannya untuk mengakses resource lain.
  • Konfigurasi pengelolaan akses dan identitas yang digunakan akun dan layanan lain untuk mengakses workload.
  • Kontrol Tata Kelola.

Persyaratan kepatuhan dan peraturan

Untuk setiap workload AWS Lambda, pastikan Anda memahami persyaratan kepatuhan dan peraturannya dengan melakukan hal berikut:

  • Lakukan penilaian terkait persyaratan kepatuhan dan peraturan yang perlu dipenuhi workload.
  • Menentukan apakah beban kerja saat ini memenuhi persyaratan ini.
  • Tentukan apakah ada persyaratan di masa mendatang yang perlu dipenuhi.

Persyaratan kepatuhan dan peraturan mungkin terpisah dari penyedia cloud yang Anda gunakan, dan persyaratan ini juga dapat berdampak pada migrasi. Misalnya, Anda mungkin perlu memastikan bahwa traffic data dan jaringan tetap berada dalam batas wilayah geografis tertentu, seperti Uni Eropa (EU).

Menilai proses deployment dan operasional Anda

Penting untuk memiliki pemahaman yang jelas tentang cara kerja deployment dan proses operasional Anda. Proses ini adalah bagian dasar dari praktik yang menyiapkan dan memelihara lingkungan produksi serta beban kerja yang berjalan di sana.

Proses deployment dan operasional Anda dapat mem-build artefak yang diperlukan oleh beban kerja Anda agar berfungsi. Oleh karena itu, Anda harus mengumpulkan informasi tentang setiap jenis artefak. Misalnya, artefak dapat berupa paket sistem operasi, paket deployment aplikasi, image sistem operasi container, atau lainnya.

Selain jenis artefak, pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

  • Kembangkan workload Anda. Lakukan penilaian terkait proses yang dimiliki tim pengembangan untuk membangun workload Anda. Misalnya, bagaimana tim pengembangan Anda merancang, melakukan coding, dan menguji workload?
  • Buat artefak yang Anda deploy di lingkungan sumber. Untuk men-deploy workload di lingkungan sumber, Anda mungkin akan membuat artefak yang dapat di-deploy, seperti image container atau image sistem operasi, atau menyesuaikan artefak yang ada, seperti image sistem operasi pihak ketiga dengan menginstal dan mengonfigurasi software. Mengumpulkan informasi tentang cara membuat artefak ini akan membantu Anda memastikan bahwa artefak yang dihasilkan cocok untuk deployment di Google Cloud.

  • Simpan artefak. Jika menghasilkan artefak yang disimpan di artefak registry di lingkungan sumber, Anda harus menyediakan artefak tersebut di lingkungan Google Cloud Anda. Anda dapat melakukannya dengan menggunakan strategi seperti berikut:

    • Buat saluran komunikasi antarlingkungan: Buat artefak di lingkungan sumber Anda dapat dijangkau dari lingkungan Google Cloud target.
    • Faktorkan ulang proses build artefak: Selesaikan pemfaktoran ulang minor pada lingkungan sumber sehingga Anda dapat menyimpan artefak di lingkungan sumber dan lingkungan target. Pendekatan ini mendukung migrasi dengan membangun infrastruktur seperti repositori artefak sebelum Anda harus mengimplementasikan proses build artefak di lingkungan Google Cloud target. Anda dapat menerapkan pendekatan ini secara langsung atau menggunakan pendekatan sebelumnya dalam membangun saluran komunikasi terlebih dahulu.

    Memiliki artefak yang tersedia di lingkungan sumber dan target memungkinkan Anda berfokus pada migrasi tanpa harus mengimplementasikan proses build artefak di lingkungan Google Cloud target sebagai bagian dari migrasi.

  • Pindai dan tanda tangani kode. Sebagai bagian dari proses build artefak, Anda mungkin menggunakan pemindaian kode untuk membantu melindungi dari kerentanan umum dan eksposur jaringan yang tidak diinginkan, serta penandatanganan kode untuk membantu memastikan bahwa hanya kode tepercaya yang berjalan di lingkungan Anda.

  • Deploy artefak di lingkungan sumber Anda. Setelah membuat artefak yang dapat di-deploy, Anda mungkin akan men-deploy-nya di lingkungan sumber. Sebaiknya Anda menilai setiap proses deployment. Penilaian ini membantu memastikan bahwa proses deployment Anda kompatibel dengan Google Cloud. Hal ini juga membantu Anda memahami upaya yang akan diperlukan untuk memfaktorkan ulang proses pada akhirnya. Misalnya, jika proses deployment hanya berfungsi dengan lingkungan sumber, Anda mungkin perlu memfaktorkan ulang proses tersebut untuk menargetkan lingkungan Google Cloud Anda.

  • Memasukkan konfigurasi runtime. Anda mungkin perlu memasukkan konfigurasi runtime untuk cluster, lingkungan runtime, atau deployment workload tertentu. Konfigurasi mungkin melakukan inisialisasi variabel lingkungan dan nilai konfigurasi lainnya, seperti secret, kredensial, dan kunci. Untuk membantu memastikan bahwa proses injeksi konfigurasi runtime Anda berfungsi di Google Cloud, sebaiknya evaluasi cara Anda mengonfigurasi workload yang berjalan di lingkungan sumber Anda.

  • Logging, pemantauan, dan pembuatan profil. Lakukan penilaian terhadap proses logging, pemantauan, dan pembuatan profil yang Anda miliki untuk memantau kondisi lingkungan sumber, metrik yang diinginkan, dan cara Anda memakai data yang disediakan oleh proses ini.

  • Autentikasi. Lakukan penilaian terkait cara Anda melakukan autentikasi terhadap lingkungan sumber.

  • Sediakan dan konfigurasi resource Anda. Untuk menyiapkan lingkungan sumber, Anda mungkin telah mendesain dan menerapkan proses yang menyediakan dan mengonfigurasi resource. Misalnya, Anda mungkin menggunakan Terraform bersama dengan alat manajemen konfigurasi untuk menyediakan dan mengonfigurasi resource di lingkungan sumber Anda.

Menyelesaikan penilaian

Setelah mem-build inventaris dari lingkungan AWS Lambda, selesaikan aktivitas lainnya pada fase penilaian seperti yang dijelaskan dalam Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Merencanakan dan membangun fondasi Anda

Pada fase perencanaan dan build, Anda akan menyediakan dan mengonfigurasi infrastruktur untuk melakukan hal berikut:

  • Dukung workload Anda di Google Cloud lingkungan Anda.
  • Hubungkan lingkungan sumber dan Google Cloud lingkungan Anda untuk menyelesaikan migrasi.

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

  1. Mem-build hierarki resource.
  2. Mengonfigurasi Identity and Access Management (IAM) Google Cloud.
  3. Menyiapkan penagihan.
  4. Menyiapkan konektivitas jaringan.
  5. Perketat keamanan Anda.
  6. Siapkan logging, pemantauan, dan pemberitahuan.

Untuk mengetahui informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Memigrasikan workload AWS Lambda Anda

Untuk memigrasikan workload Anda dari AWS Lambda ke Cloud Run, lakukan langkah berikut:

  1. Desain, sediakan, dan konfigurasi lingkungan Cloud Run Anda.
  2. Jika perlu, faktorkan ulang workload AWS Lambda Anda agar kompatibel dengan Cloud Run.
  3. Faktorkan ulang proses deployment dan operasional untuk men-deploy dan mengamati workload Anda di Cloud Run.
  4. Migrasikan data yang dibutuhkan oleh workload AWS Lambda Anda.
  5. Validasi hasil migrasi dari segi fungsi, performa, dan biaya.

Untuk membantu Anda menghindari masalah selama migrasi, dan untuk membantu memperkirakan upaya yang diperlukan untuk migrasi, sebaiknya Anda mengevaluasi perbandingan fitur AWS Lambda dengan fitur Cloud Run serupa. Fitur AWS Lambda dan Cloud Run mungkin terlihat serupa saat Anda membandingkannya. Namun, perbedaan desain dan penerapan fitur pada kedua penyedia cloud dapat berdampak signifikan pada migrasi Anda dari AWS Lambda ke Cloud Run. Perbedaan ini dapat memengaruhi keputusan desain dan pemfaktoran ulang, seperti yang dijelaskan di bagian berikut.

Merancang, menyediakan, dan mengonfigurasi lingkungan Cloud Run Anda

Langkah pertama dari fase migrasi adalah mendesain lingkungan Cloud Run Anda agar dapat mendukung workload yang akan Anda migrasikan dari AWS Lambda.

Untuk mendesain lingkungan Cloud Run Anda dengan benar, gunakan data yang dikumpulkan selama fase penilaian tentang setiap workload AWS Lambda. Data ini membantu Anda melakukan hal berikut:

  1. Pilih resource Cloud Run yang tepat untuk men-deploy workload Anda.
  2. Desain konfigurasi resource Cloud Run Anda.
  3. Menyediakan dan mengonfigurasi resource Cloud Run.

Memilih resource Cloud Run yang tepat

Untuk setiap workload AWS Lambda yang akan dimigrasikan, pilih resource Cloud Run yang tepat untuk men-deploy workload Anda. Cloud Run mendukung resource utama berikut:

  • Layanan Cloud Run: resource yang menghosting lingkungan runtime dalam container, mengekspos endpoint unik, dan otomatis menskalakan infrastruktur dasar sesuai permintaan.
  • Tugas Cloud Run: resource yang menjalankan satu atau beberapa container untuk diselesaikan.

Tabel berikut merangkum cara resource AWS Lambda dipetakan ke resource Cloud Run utama ini:

Resource AWS Lambda Resource Cloud Run
Fungsi AWS Lambda yang dipicu oleh peristiwa seperti yang digunakan untuk situs dan aplikasi web, API dan microservice, pemrosesan data streaming, serta arsitektur berbasis peristiwa. Cloud Run yang dapat dipanggil dengan pemicu.
Fungsi AWS Lambda yang telah dijadwalkan untuk berjalan, seperti fungsi untuk tugas latar belakang dan tugas batch. Tugas Cloud Run yang berjalan hingga selesai.

Selain layanan dan tugas, Cloud Run menyediakan resource tambahan yang memperluas resource utama ini. Untuk mengetahui informasi selengkapnya tentang semua resource Cloud Run yang tersedia, lihat Model resource Cloud Run.

Mendesain konfigurasi resource Cloud Run

Sebelum menyediakan dan mengonfigurasi resource Cloud Run, desain konfigurasinya. Opsi konfigurasi AWS Lambda tertentu, seperti batas resource dan waktu tunggu permintaan, sebanding dengan opsi konfigurasi Cloud Run yang serupa. Bagian berikut menjelaskan opsi konfigurasi yang tersedia di Cloud Run untuk pemicu layanan dan eksekusi tugas, konfigurasi resource, serta keamanan. Bagian ini juga menyoroti opsi konfigurasi AWS Lambda yang sebanding dengan opsi yang ada di Cloud Run.

Pemicu layanan Cloud Run dan eksekusi tugas

Pemicu layanan dan eksekusi tugas adalah keputusan desain utama yang perlu Anda pertimbangkan saat memigrasikan workload AWS Lambda. Cloud Run menyediakan berbagai opsi untuk memicu dan menjalankan workload berbasis peristiwa yang digunakan di AWS Lambda. Selain itu, Cloud Run menyediakan opsi yang dapat Anda gunakan untuk workload streaming dan tugas terjadwal.

Saat Anda memigrasikan workload, sebaiknya pahami terlebih dahulu pemicu dan mekanisme yang tersedia di Cloud Run. Informasi ini membantu Anda memahami cara kerja Cloud Run. Kemudian, Anda dapat menggunakan pemahaman ini untuk menentukan fitur Cloud Run yang sebanding dengan fitur AWS Lambda, dan fitur Cloud Run yang dapat digunakan saat memfaktorkan ulang beban kerja tersebut.

Untuk mempelajari lebih lanjut pemicu layanan yang disediakan Cloud Run, gunakan referensi berikut:

Untuk mempelajari mekanisme eksekusi tugas yang disediakan Cloud Run lebih lanjut, gunakan referensi berikut:

Untuk membantu Anda memahami mekanisme pemanggilan atau eksekusi Cloud Run yang sebanding dengan mekanisme pemanggilan AWS Lambda, baca tabel berikut. Untuk setiap resource Cloud Run yang perlu Anda sediakan, pastikan Anda memilih mekanisme pemanggilan atau eksekusi yang tepat.

Fitur AWS Lambda Fitur Cloud Run
Pemicu HTTPS (URL fungsi) Pemanggilan HTTPS
Pemicu HTTP/2 (didukung sebagian menggunakan gateway API eksternal) Pemanggilan HTTP/2 (didukung secara native)
WebSockets (didukung menggunakan gateway API eksternal) WebSockets (didukung secara native)
T/A (koneksi gRPC tidak didukung) Koneksi gRPC
Pemanggilan asinkron Integrasi Cloud Tasks
Pemanggilan terjadwal Integrasi Cloud Scheduler
Pemicu berbasis peristiwa dalam format peristiwa eksklusif Pemanggilan berbasis peristiwa dalam format CloudEvents
Integrasi Amazon SQS dan Amazon SNS Integrasi Pub/Sub
Fungsi Langkah AWS Lambda Integrasi Workflows
Konfigurasi resource Cloud Run

Untuk melengkapi keputusan desain yang Anda buat untuk memicu dan menjalankan workload yang dimigrasikan, Cloud Run mendukung beberapa opsi konfigurasi yang memungkinkan Anda menyesuaikan beberapa aspek lingkungan runtime. Opsi konfigurasi ini terdiri dari layanan dan tugas resource.

Seperti yang disebutkan sebelumnya, Anda dapat lebih memahami cara kerja Cloud Run dengan terlebih dahulu mengembangkan pemahaman tentang semua opsi konfigurasi yang tersedia di Cloud Run. Pemahaman ini kemudian membantu Anda membandingkan fitur AWS Lambda dengan fitur Cloud Run serupa, dan membantu Anda menentukan cara memfaktorkan ulang workload.

Untuk mempelajari konfigurasi yang disediakan layanan Cloud Run lebih lanjut, gunakan resource berikut:

Untuk mempelajari tugas yang disediakan Cloud Run lebih lanjut, gunakan referensi berikut:

Untuk membantu Anda memahami opsi konfigurasi Cloud Run mana yang sebanding dengan opsi konfigurasi AWS Lambda, gunakan tabel berikut. Untuk tiap resource Cloud Run yang perlu Anda sediakan, pilih opsi konfigurasi yang tepat.

Fitur AWS Lambda Fitur Cloud Run
Konkurensi yang disediakan Instance minimum
Konkurensi yang dicadangkan per instance
(Kumpulan konkurensi dibagikan di seluruh fungsi AWS Lambda pada akun AWS Anda.)		 Instance maksimum per layanan
T/A (tidak didukung, satu permintaan dipetakan ke satu instance) Permintaan serentak per instance
T/A (bergantung pada alokasi memori) Alokasi CPU
Setelan skalabilitas Penskalaan otomatis instance untuk layanan
Paralelisme untuk tugas
Konfigurasi instance (CPU, memori) Batas CPU dan memori
Waktu eksekusi maksimum Waktu tunggu permintaan untuk layanan
Waktu tunggu tugas untuk tugas
SnapStart AWS Lambda Boost CPU startup
Variabel lingkungan Variabel lingkungan
Penyimpanan data ephemeral Pemasangan volume dalam memori
Koneksi Amazon Elastic File System Pemasangan volume NFS
Pemasangan volume S3 tidak didukung Dudukan volume Cloud Storage
AWS Secret Manager dalam workload AWS Lambda Rahasia
URL workload dan endpoint HTTP(S) URL yang ditetapkan secara otomatis
Integrasi Cloud Run dengan Google Cloud produk
Sesi persisten (menggunakan load balancer eksternal) Afinitas sesi
Penentu Revisi

Selain fitur yang tercantum dalam tabel sebelumnya, Anda juga harus mempertimbangkan perbedaan antara cara AWS Lambda dan Cloud Run menyediakan instance lingkungan eksekusi. AWS Lambda menyediakan satu instance untuk setiap permintaan serentak. Namun, Cloud Run memungkinkan Anda menetapkan jumlah permintaan serentak yang dapat dilayani oleh sebuah instance. Artinya, perilaku penyediaan AWS Lambda setara dengan menetapkan jumlah maksimum permintaan serentak per instance menjadi 1 di Cloud Run. Menetapkan jumlah maksimum permintaan serentak ke lebih dari 1 dapat menghemat biaya secara signifikan karena CPU dan memori instance digunakan bersama oleh permintaan serentak, tetapi keduanya hanya ditagih sekali. Sebagian besar framework HTTP dirancang untuk menangani permintaan secara paralel.

Kontrol akses dan keamanan Cloud Run

Saat mendesain resource Cloud Run, Anda juga perlu memutuskan kontrol akses dan keamanan yang diperlukan untuk workload yang dimigrasikan. Cloud Run mendukung beberapa opsi konfigurasi untuk membantu Anda mengamankan lingkungan, serta menetapkan peran dan izin untuk workload Cloud Run Anda.

Bagian ini menjelaskan kontrol keamanan dan akses yang tersedia di Cloud Run. Informasi ini membantu Anda memahami cara kerja workload yang dimigrasikan di Cloud Run dan mengidentifikasi opsi Cloud Run yang mungkin diperlukan jika Anda memfaktorkan ulang workload tersebut.

Untuk mempelajari lebih lanjut mekanisme autentikasi yang disediakan Cloud Run, gunakan referensi berikut:

Untuk mempelajari lebih lanjut fitur keamanan yang disediakan Cloud Run, gunakan referensi berikut:

Untuk membantu Anda memahami kontrol akses dan keamanan Cloud Run mana yang sebanding dengan yang tersedia di AWS Lambda, lihat tabel berikut. Untuk setiap resource Cloud Run yang perlu Anda sediakan, pastikan untuk memilih kontrol akses dan fitur keamanan yang tepat.

Fitur AWS Lambda Fitur Cloud Run
Kontrol akses dengan akses dan pengelolaan identitas AWS Kontrol akses dengan IAM Google Cloud
Peran eksekusi Peran IAMGoogle Cloud
Batas izin Izin IAM dan audiens kustomGoogle Cloud
Mengontrol tata kelola Organization Policy Service
Penandatanganan kode Otorisasi biner
Akses VPC penuh Kontrol akses keluar VPC yang terperinci

Menyediakan dan mengonfigurasi resource Cloud Run

Setelah memilih resource Cloud Run untuk men-deploy beban kerja, Anda harus menyediakan dan mengonfigurasi resource tersebut. Untuk mengetahui informasi selengkapnya tentang penyediaan resource Cloud Run, lihat referensi berikut:

Memfaktorkan ulang workload AWS Lambda

Untuk memigrasikan workload AWS Lambda ke Cloud Run, Anda mungkin perlu memfaktorkan ulang workload tersebut. Misalnya, jika beban kerja berbasis peristiwa menerima pemicu yang berisi peristiwa Amazon CloudWatch, Anda mungkin perlu memfaktorkan ulang beban kerja tersebut agar dapat menerima peristiwa dalam format CloudEvents.

Ada beberapa faktor yang dapat memengaruhi jumlah pemfaktoran ulang yang Anda perlukan untuk setiap workload AWS Lambda, seperti berikut:

  • Arsitektur. Pertimbangkan bagaimana workload dirancang dalam hal arsitektur. Misalnya, beban kerja AWS Lambda yang telah dengan jelas memisahkan logika bisnis dari logika untuk mengakses API khusus AWS mungkin memerlukan pemfaktoran ulang yang lebih sedikit dibandingkan dengan workload yang menggabungkan dua logika.
  • Idempotensi. Pertimbangkan apakah workload bersifat idempoten dalam kaitannya dengan inputnya. Workload yang bersifat idempoten terhadap input mungkin memerlukan lebih sedikit pemfaktoran ulang dibandingkan dengan workload yang perlu mempertahankan status terkait input yang telah mereka proses.
  • Negara Bagian/Provinsi. Pertimbangkan apakah workload bersifat stateless atau tidak. Workload stateless mungkin memerlukan lebih sedikit pemfaktoran ulang dibandingkan dengan workload yang mempertahankan status. Untuk mengetahui informasi selengkapnya tentang layanan yang didukung Cloud Run untuk menyimpan data, lihat opsi penyimpanan Cloud Run.
  • Lingkungan runtime. Pertimbangkan apakah workload membuat asumsi apa pun tentang lingkungan runtime-nya. Untuk jenis workload ini, Anda mungkin perlu memenuhi asumsi yang sama di lingkungan runtime Cloud Run atau memfaktorkan ulang workload jika Anda tidak dapat mengasumsikan hal yang sama untuk lingkungan runtime Cloud Run. Misalnya, jika beban kerja memerlukan paket atau library tertentu agar tersedia, Anda harus menginstalnya di lingkungan runtime Cloud Run yang akan menghosting beban kerja tersebut.
  • Injeksi konfigurasi. Pertimbangkan apakah workload mendukung penggunaan variabel lingkungan dan secret untuk memasukkan (menetapkan) konfigurasinya. Beban kerja yang mendukung jenis injeksi ini mungkin memerlukan lebih sedikit pemfaktoran ulang dibandingkan dengan workload yang mendukung mekanisme injeksi konfigurasi lainnya.
  • API. Pertimbangkan apakah workload berinteraksi dengan AWS Lambda API. Workload yang berinteraksi dengan API ini mungkin perlu difaktorkan ulang agar dapat menggunakan Cloud API dan Cloud Run API.
  • Pelaporan error. Pertimbangkan apakah workload melaporkan error menggunakan output standar dan aliran error. Beban kerja yang melakukan pelaporan error tersebut mungkin memerlukan lebih sedikit pemfaktoran ulang dibandingkan dengan beban kerja yang melaporkan error menggunakan mekanisme lain.

Untuk mengetahui informasi selengkapnya tentang cara mengembangkan dan mengoptimalkan beban kerja Cloud Run, lihat referensi berikut:

Memfaktorkan ulang proses deployment dan operasional

Setelah memfaktorkan ulang workload, Anda memfaktorkan ulang proses deployment dan operasional untuk melakukan hal berikut:

  • Sediakan dan konfigurasi resource di lingkungan Google Cloud Anda, bukan menyediakan resource di lingkungan sumber.
  • Bangun dan konfigurasi workload serta deploy workload di Google Cloud Anda, bukan men-deploy-nya di lingkungan sumber.

Anda mengumpulkan informasi tentang proses ini selama fase penilaian sebelumnya dalam proses ini.

Jenis pemfaktoran ulang yang perlu Anda pertimbangkan untuk proses ini bergantung pada cara Anda merancang dan menerapkannya. Pemfaktoran ulang juga bergantung pada apa yang Anda inginkan status akhir untuk setiap proses. Misalnya, pertimbangkan hal berikut:

  • Anda mungkin telah mengimplementasikan proses ini di lingkungan sumber dan ingin mendesain serta mengimplementasikan proses serupa di Google Cloud. Misalnya, Anda dapat memfaktorkan ulang proses ini untuk menggunakan Cloud Build, Cloud Deploy, dan Pengelola Infrastruktur.
  • Anda mungkin telah menerapkan proses ini di lingkungan pihak ketiga lain di luar lingkungan sumber. Dalam hal ini, Anda perlu memfaktorkan ulang proses ini untuk menargetkan Google Cloud lingkungan, bukan ke lingkungan sumber.
  • Gabungan dari pendekatan sebelumnya.

Pemfaktoran ulang proses deployment dan operasional dapat bersifat kompleks dan dapat membutuhkan upaya yang signifikan. Jika Anda mencoba melakukan tugas ini sebagai bagian dari migrasi workload, migrasi workload dapat menjadi lebih kompleks, dan dapat menimbulkan risiko. Setelah menilai proses deployment dan operasional, Anda mungkin telah memahami desain dan kompleksitasnya. Jika Anda memperkirakan bahwa Anda memerlukan upaya besar untuk memfaktorkan ulang proses deployment dan operasional, sebaiknya pertimbangkan pemfaktoran ulang proses tersebut sebagai bagian dari project khusus yang terpisah.

Untuk informasi selengkapnya tentang cara mendesain dan menerapkan proses deployment di Google Cloud, lihat:

Dokumen ini berfokus pada proses deployment yang menghasilkan artefak untuk di-deploy, dan men-deploy-nya di lingkungan runtime target. Strategi pemfaktoran ulang sangat bergantung pada kompleksitas proses ini. Daftar berikut menguraikan strategi pemfaktoran ulang umum yang mungkin dilakukan:

  1. Menyediakan repositori artefak di Google Cloud. Misalnya, Anda dapat menggunakan Artifact Registry untuk menyimpan artefak dan dependensi build.
  2. Faktorkan ulang proses build Anda untuk menyimpan artefak di lingkungan sumber dan di Artifact Registry.
  3. Faktorkan ulang proses deployment untuk men-deploy workload di lingkunganGoogle Cloud target. Misalnya, Anda dapat mulai dengan men-deploy sebagian kecil workload di Google Cloud, menggunakan artefak yang disimpan di Artifact Registry. Kemudian, Anda secara bertahap meningkatkan jumlah workload yang di-deploy di Google Cloud, hingga semua workload yang akan dimigrasikan berjalan pada Google Cloud.
  4. Faktorkan ulang proses build Anda untuk menyimpan artefak hanya di Artifact Registry.
  5. Jika perlu, migrasikan versi artefak sebelumnya untuk di-deploy dari repositori di lingkungan sumber Anda ke Artifact Registry. Misalnya, Anda dapat menyalin image container ke Artifact Registry.
  6. Nonaktifkan repositori di lingkungan sumber saat Anda tidak lagi memerlukannya.

Untuk memfasilitasi rollback akhir karena masalah tak terduga selama migrasi, Anda dapat menyimpan image penampung di repositori artefak saat ini di Google Cloud saat migrasi ke Google Cloud sedang berlangsung. Terakhir, sebagai bagian dari penonaktifan lingkungan sumber, Anda dapat memfaktorkan ulang proses pembuatan image container untuk menyimpan artefak diGoogle Cloud saja.

Meskipun mungkin tidak penting untuk keberhasilan migrasi, Anda mungkin perlu memigrasikan versi artefak sebelumnya dari lingkungan sumber ke repositori artefak di Google Cloud. Misalnya, untuk mendukung roll back workload ke titik waktu arbitrer, Anda mungkin perlu memigrasikan versi artefak sebelumnya ke Artifact Registry. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan image dari registry pihak ketiga.

Jika Anda menggunakan Artifact Registry untuk menyimpan artefak, sebaiknya konfigurasi kontrol untuk membantu Anda mengamankan repositori artefak Anda, seperti kontrol akses, pencegahan pemindahan data yang tidak sah, pemindaian kerentanan, dan Otorisasi Biner. Untuk mengetahui informasi selengkapnya, lihat Mengontrol akses dan melindungi artefak.

Memfaktorkan ulang proses operasional

Sebagai bagian dari migrasi ke Cloud Run, sebaiknya Anda melakukan pemfaktoran ulang proses operasional untuk memantau lingkungan Cloud Run Anda secara terus-menerus dan efektif.

Cloud Run terintegrasi dengan layanan operasional berikut:

Migrasikan data

Fase penilaian di awal proses ini akan membantu Anda menentukan apakah workload AWS Lambda yang akan dimigrasikan bergantung pada atau menghasilkan data yang tersimpan di lingkungan AWS Anda. Misalnya, Anda mungkin telah menentukan bahwa Anda perlu memigrasikan data dari AWS S3 ke Cloud Storage, atau dari Amazon RDS dan Aurora ke Cloud SQL serta AlloyDB untuk PostgreSQL. Untuk mengetahui informasi selengkapnya tentang memigrasikan data dari AWS keGoogle Cloud, lihat Bermigrasi dari AWS ke Google Cloud: Memulai.

Seperti halnya proses deployment dan operasional pemfaktoran ulang, memigrasikan data dari AWS ke Google Cloud dapat menjadi hal yang kompleks dan memerlukan upaya yang signifikan. Jika Anda mencoba melakukan tugas migrasi data ini sebagai bagian dari migrasi workload AWS Lambda, proses migrasi dapat menjadi kompleks dan dapat menimbulkan risiko. Setelah menganalisis data yang akan dimigrasikan, Anda mungkin akan memiliki pemahaman tentang ukuran dan kompleksitas data. Jika Anda memperkirakan bahwa memerlukan upaya besar untuk memigrasikan data ini, sebaiknya pertimbangkan untuk memigrasikan data sebagai bagian dari project khusus yang terpisah.

Memvalidasi hasil migrasi

Memvalidasi migrasi workload bukan peristiwa satu kali, tetapi merupakan proses yang berkelanjutan. Anda perlu mempertahankan fokus pada pengujian dan validasi sebelum, selama, dan setelah migrasi dari AWS Lambda ke Cloud Run.

Untuk membantu memastikan keberhasilan migrasi dengan performa yang optimal dan minim gangguan, sebaiknya gunakan proses berikut untuk memvalidasi beban kerja yang Anda migrasikan dari AWS Lambda ke Cloud Run:

  • Sebelum memulai fase migrasi, faktorkan ulang kasus pengujian yang ada untuk mempertimbangkan lingkungan Google Cloud target.
  • Selama migrasi, validasi hasil pengujian pada setiap tahap pencapaian migrasi dan lakukan pengujian integrasi secara menyeluruh.
  • Setelah migrasi, lakukan pengujian berikut:
    • Pengujian dasar: Tetapkan tolok ukur performa workload asli di AWS Lambda, seperti waktu eksekusi, penggunaan resource, dan tingkat error pada pemuatan yang berbeda. Buat replika pengujian ini di Cloud Run untuk mengidentifikasi perbedaan yang dapat menyebabkan masalah migrasi atau konfigurasi.
    • Pengujian fungsional: Pastikan logika inti dari beban kerja Anda tetap konsisten dengan membuat dan menjalankan kasus pengujian yang mencakup berbagai skenario input dan output yang diharapkan di kedua lingkungan.
    • Pengujian beban: Tingkatkan traffic secara bertahap untuk mengevaluasi performa dan skalabilitas Cloud Run dalam kondisi sebenarnya. Untuk membantu memastikan migrasi yang lancar, atasi perbedaan seperti error dan batasan resource.

Optimalkan lingkungan Google Cloud Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda melakukan iterasi pada tugas pengoptimalan hingga lingkungan target memenuhi persyaratan pengoptimalan. Langkah-langkah dari setiap iterasi adalah sebagai berikut:

  1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
  2. Tetapkan persyaratan dan sasaran pengoptimalan Anda.
  3. Optimalkan lingkungan dan tim Anda.
  4. Sesuaikan loop pengoptimalan.

Anda mengulangi urutan ini sampai Anda mencapai sasaran pengoptimalan.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan Google Cloud lingkungan, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Google Cloud Framework yang Ahli: Pengoptimalan performa.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: