Membandingkan App Engine dan Cloud Run

ID region

REGION_ID adalah kode singkat yang ditetapkan Google berdasarkan region yang Anda pilih saat membuat aplikasi. Kode ini tidak sesuai dengan negara atau provinsi, meskipun beberapa ID region mungkin tampak mirip dengan kode negara dan provinsi yang umum digunakan. Untuk aplikasi yang dibuat setelah Februari 2020, REGION_ID.r disertakan dalam URL App Engine. Untuk aplikasi lama yang dibuat sebelum tanggal tersebut, ID region bersifat opsional dalam URL.

Pelajari ID region lebih lanjut.

Panduan ini menyediakan pengantar Cloud Run bagi pengguna yang sudah memahami App Engine. Panduan ini membahas beberapa kesamaan dan perbedaan utama antara platform Serverless untuk membantu mempersiapkan migrasi dari lingkungan standar App Engine atau lingkungan fleksibel App Engine.

Ringkasan

Cloud Run adalah evolusi terbaru dari Google Cloud Serverless, yang dikembangkan berdasarkan pengalaman menjalankan App Engine selama lebih dari satu dekade. Cloud Run berjalan pada banyak infrastruktur yang sama dengan lingkungan standar App Engine, sehingga ada banyak kesamaan di antara kedua platform ini.

Cloud Run dirancang untuk meningkatkan pengalaman App Engine, yang menggabungkan banyak fitur terbaik dari lingkungan standar App Engine dan lingkungan fleksibel App Engine. Layanan Cloud Run dapat menangani beban kerja yang sama dengan layanan App Engine, tetapi Cloud Run menawarkan fleksibilitas yang lebih besar kepada pelanggan dalam mengimplementasikan layanan ini. Fleksibilitas ini, bersama dengan peningkatan integrasi dengan Google Cloud dan layanan pihak ketiga, juga memungkinkan Cloud Run menangani workload yang tidak dapat berjalan di App Engine.

Ringkasan perbandingan

Meskipun ada banyak kesamaan dan perbedaan antara App Engine dan Cloud Run, ringkasan ini berfokus pada area yang paling relevan bagi pelanggan App Engine yang memulai Cloud Run.

Lingkungan standar App Engine Lingkungan fleksibel App Engine Cloud Run
Terminologi Aplikasi T/A
Layanan Layanan
Versi Revisi

Endpoint URL

URL aplikasi
(layanan default)
https://PROJECT_ID.REGION_ID.r.appspot.com T/A
URL Layanan https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com https://SERVICE_IDENTIFIER.run.app
URL Versi/Revisi https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com https://TAG---SERVICE_IDENTIFIER.run.app

Penskalaan

Penskalaan otomatis Ya Ya Ya
Penskalaan manual Ya Ya Meskipun tidak ada setelan penskalaan manual tertentu, perilaku yang sama dapat direplikasi dengan mengonfigurasi instance maksimum yang sama dengan instance minimum
Penskalaan hingga nol Ya Tidak Ya
Warmup request Dapat Dikonfigurasi Tidak Otomatis
Waktu tunggu instance tidak ada aktivitas (setelah menyelesaikan permintaan terakhir) Hingga 15 menit Bergantung pada setelan alokasi CPU. Gunakan CPU always allocated untuk mengemulasi perilaku App Engine
Waktu tunggu permintaan
  • Penskalaan otomatis: 10 menit
  • Penskalaan Manual/Dasar: 24 jam
60 menit Dapat dikonfigurasi hingga 60 menit (default: 5 menit)

Deployment

Dari sumber Ya Ya
Image container Tidak Ya (runtime kustom) Ya

Resource komputasi

vCPU
Class instance vCPU* Memori
F/B1 ,25 384MB
F/B2 .5 768MB
F/B4 1 1,5 GB
F/B4_1G 1 3GB
B8 2 3GB
* vCPU yang setara merupakan perkiraan
Hingga 80 vCPU Hingga 8 vCPU
Memori Hingga 6,5 GB per vCPU Hingga 32 GB

Model penetapan harga

Biaya per permintaan Tidak Tidak, saat CPU selalu dialokasikan.
Ya, saat CPU hanya dialokasikan selama pemrosesan permintaan.
Instance minimum tanpa aktivitas Biaya yang sama seperti instance aktif Biaya yang lebih rendah untuk instance minimum tanpa aktivitas (lihat Waktu instance container yang dapat ditagih)
Diskon abonemen (CUD) Tidak Ya

Keamanan

Setelan ingress Ya Ya Ya
Peran Invoker Tidak Ya
IAP Ya Ya Mengonfigurasi menggunakan Cloud Load Balancing
Firewall Ya Ya Mengonfigurasi menggunakan Google Cloud Armor

Konektivitas

Domain kustom Ya Ya Mengonfigurasi menggunakan Cloud Load Balancing
Konektivitas VPC (termasuk VPC Bersama) Ya T/A Ya
Setelan traffic keluar VPC Ya T/A Ya
Load balancing multi-region Tidak Ya

Mengakses layanan Google Cloud

Cloud SQL Ya Ya Ya
Library Klien Cloud Jika menggunakan Library Klien Cloud di App Engine, Anda tidak perlu mengubah apa pun saat bermigrasi ke Cloud Run. Library klien ini berfungsi di mana saja, sehingga aplikasi Anda menjadi lebih portabel.
Paket layanan lama App Engine Ya (khusus Java, Python, Go, PHP) Tidak Tidak

Model resource

Diagram model resource App Engine dan Cloud Run

Model resource Cloud Run sangat mirip dengan App Engine, tetapi terdapat beberapa perbedaan utama:

  • Cloud Run tidak memiliki resource Aplikasi tingkat atas, atau layanan default yang sesuai.
  • Layanan Cloud Run dalam project yang sama dapat di-deploy ke region yang berbeda. Di App Engine, semua layanan dalam project berada di region yang sama.
  • Cloud Run menggunakan istilah Revisi, bukan Versi, agar selaras dengan Model resource Knative.
  • Nama revisi Cloud Run menggunakan format: SERVICE_NAME-REVISION_SUFFIX, dengan REVISION_SUFFIX dibuat secara otomatis, atau ditetapkan menggunakan tanda deployment --revision-suffix=REVISION_SUFFIX.
  • Revisi Cloud Run tidak dapat diubah, artinya Anda tidak dapat menggunakan kembali nama seperti yang dapat Anda lakukan pada versi App Engine (menggunakan tanda deployment --version=VERSION_ID).
  • URL layanan Cloud Run didasarkan pada ID Layanan yang dibuat secara otomatis saat deployment pertama layanan. ID Layanan menggunakan format: SERVICE_NAME-<auto-generated identifier>. ID Layanan bersifat unik, dan tidak berubah selama masa aktif layanan.
  • Di Cloud Run, hanya URL layanan (SERVICE_IDENTIFIER.run.app) yang ditampilkan secara default. Untuk mengatasi revisi tertentu, Anda harus mengonfigurasi tag traffic. Di App Engine, URL layanan dan versi ditampilkan secara otomatis.

Deployment dan konfigurasi

Di App Engine, sebagian besar konfigurasi dilakukan di app.yaml yang disertakan di setiap deployment. Kemudahan ini menimbulkan biaya, karena, meskipun beberapa setelan dapat diperbarui menggunakan Admin API, sebagian besar perubahan memerlukan deployment ulang layanan.

Meskipun Cloud Run memiliki file konfigurasi service.yaml, file tersebut tidak digunakan dengan cara yang sama seperti app.yaml. service.yaml Cloud Run tidak dapat digunakan saat men-deploy dari sumber, karena salah satu elemen yang diperlukan adalah jalur ke image container akhir. Selain itu, service.yaml sesuai dengan spesifikasi Knative, dan mungkin sulit dibaca bagi mereka yang tidak terbiasa dengan file konfigurasi gaya Kubernetes. Untuk mengetahui informasi selengkapnya tentang cara menggunakan service.yaml untuk mengelola konfigurasi, lihat dokumentasi Cloud Run.

Bagi pelanggan App Engine yang baru mulai menggunakan Cloud Run, penggunaan tanda deployment gcloud CLI lebih selaras dengan pengelolaan konfigurasi saat deployment App Engine.

Untuk menetapkan konfigurasi saat men-deploy kode baru di Cloud Run, gunakan flag gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Meskipun Anda tidak diharuskan menggunakan tanda konfigurasi pada setiap deployment (lihat Mengelola konfigurasi), Anda dapat melakukannya untuk membantu menyederhanakan pengelolaan konfigurasi.

Di Cloud Run, Anda juga dapat memperbarui konfigurasi tanpa men-deploy ulang kode sumber menggunakan gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Karena revisi Cloud Run tidak dapat diubah, perintah ini akan membuat revisi baru dengan konfigurasi yang diperbarui, tetapi akan menggunakan image container yang sama dengan revisi yang ada.

Mengelola konfigurasi

Untuk deployment App Engine, semua setelan harus disediakan untuk setiap deployment, dan setiap setelan yang tidak disediakan akan diberi nilai default. Misalnya, ambil App Engine service-a, dengan versi yang menggunakan file app.yaml ditampilkan di bawah ini:

App Engine service-a version1 App Engine service-a version2
app.yaml

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a
Konfigurasi yang diterapkan

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 dikonfigurasi dengan instance_class: F4, sedangkan version2, yang tidak memberikan nilai untuk instance_class, dikonfigurasi dengan instance_class: F1 default.

Untuk Cloud Run, semua setelan konfigurasi yang disediakan akan diterapkan, tetapi yang tidak disediakan akan dipertahankan nilainya yang ada. Anda hanya perlu memberikan nilai untuk setelan yang akan diubah. Contoh:

Cloud Run service-a revision1 Cloud Run service-a revision2
Perintah deployment

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a
Konfigurasi yang diterapkan

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

Di App Engine, deployment tanpa setelan konfigurasi akan membuat versi menggunakan semua setelan default. Di Cloud Run, men-deploy tanpa setelan konfigurasi akan membuat revisi menggunakan setelan konfigurasi yang sama dengan revisi sebelumnya. Untuk revisi pertama layanan Cloud Run, men-deploy tanpa setelan konfigurasi akan membuat revisi menggunakan semua setelan default.

Default konfigurasi

Setelan konfigurasi Lingkungan standar App Engine Lingkungan fleksibel App Engine Cloud Run
Resource komputasi F1 1 vCPU, 0,6 GB 1 vCPU, 512MB
Konkurensi maksimum (permintaan) 10 Tidak ada 80
Waktu tunggu permintaan
  • Penskalaan otomatis: 10 menit
  • Penskalaan Manual/Dasar: 24 jam
60 menit 5 menit
Target penggunaan CPU 60% 50% 60%
Instance maksimum Tidak ada 20 100
Instance minimum 0 2 0

Entrypoint

Saat melakukan deployment dari sumber, App Engine membaca perintah entrypoint dari atribut entrypoint di app.yaml. Jika tidak ada titik entri yang diberikan, setelan default khusus runtime akan digunakan. Cloud Run menggunakan buildpack Google Cloud saat men-deploy dari sumber, dan beberapa bahasa tidak memiliki entrypoint default. Artinya, Anda harus menyediakannya atau build akan gagal. Misalnya, buildpack Python memerlukan Procfile, atau menentukan variabel lingkungan build GOOGLE_ENTRYPOINT.

Tinjau dokumentasi buildpack untuk mengetahui persyaratan konfigurasi khusus bahasa.

Penskalaan

Meskipun Cloud Run dan lingkungan standar App Engine memiliki banyak infrastruktur penskalaan yang sama, Cloud Run telah disederhanakan untuk memungkinkan penskalaan yang jauh lebih cepat. Sebagai bagian dari penyederhanaan ini, setelan yang dapat dikonfigurasi terbatas pada:

Untuk instance Cloud Run, pemakaian CPU target tidak dapat dikonfigurasi, dan ditetapkan pada tingkat 60%. Lihat dokumentasi Cloud Run untuk mengetahui detail selengkapnya tentang penskalaan otomatis.

Lingkungan fleksibel App Engine menggunakan Autoscaler Compute Engine, sehingga memiliki karakteristik penskalaan yang sangat berbeda dengan lingkungan standar App Engine dan Cloud Run.

Waktu tunggu instance tanpa aktivitas

Di App Engine, instance tanpa aktivitas tetap aktif hingga 15 menit setelah permintaan terakhir selesai diproses. Dengan Cloud Run, Anda dapat mengonfigurasi perilaku ini menggunakan alokasi CPU. Untuk mendapatkan perilaku yang sama dengan App Engine, tetapkan alokasi CPU ke CPU always allocated. Atau, gunakan CPU only allocated during request processing agar instance tanpa aktivitas segera dimatikan (jika tidak ada permintaan yang tertunda).

Warmup request

Cloud Run otomatis menghangatkan instance menggunakan perintah entrypoint container, sehingga Anda tidak perlu mengaktifkan permintaan pemanasan secara manual atau mengonfigurasi pengendali /_ah/warmup. Jika memiliki kode yang ingin dijalankan saat instance dimulai, sebelum permintaan apa pun diproses, Anda dapat:

Konten statis

Di lingkungan standar App Engine, Anda dapat menayangkan konten statis tanpa menggunakan resource komputasi dengan menyalurkan dari Cloud Storage, atau dengan mengonfigurasi pengendali. Cloud Run tidak memiliki opsi pengendali untuk menyajikan konten statis, sehingga Anda dapat menyajikan konten dari layanan Cloud Run (sama seperti konten dinamis), atau dari Cloud Storage.

Peran Invoker Cloud Run

Cloud Run juga menawarkan kemampuan untuk mengontrol akses ke layanan dengan Identity and Access Management (IAM). Binding kebijakan IAM untuk layanan dapat ditetapkan menggunakan gcloud CLI, Console, atau Terraform.

Untuk mereplikasi perilaku App Engine, Anda dapat membuat layanan menjadi publik dengan mengizinkan permintaan yang tidak diautentikasi. Hal ini dapat ditetapkan saat deployment, atau dengan memperbarui binding kebijakan IAM pada Layanan yang ada.

Deployment

Gunakan tanda deployment --allow-unauthenticated:

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

Layanan yang ada

Gunakan perintah gcloud run services add-iam-policy-binding:

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

dengan SERVICE_NAME adalah nama layanan Cloud Run.

Atau, Anda dapat memilih untuk mengontrol siapa yang memiliki akses ke layanan dengan memberikan peran IAM Invoker Cloud Run yang dapat dikonfigurasi per layanan.

Deployment

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

dengan SERVICE_NAME sebagai nama layanan, dan MEMBER_TYPE adalah jenis utamanya. Contoh, user:email@domain.com.

Untuk mengetahui daftar nilai yang dapat diterima untuk MEMBER_TYPE, lihat halaman konsep IAM.

Layanan yang ada

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

dengan SERVICE_NAME sebagai nama layanan, dan MEMBER_TYPE adalah jenis utamanya. Contoh, user:email@domain.com.

Untuk mengetahui daftar nilai yang dapat diterima untuk MEMBER_TYPE, lihat halaman konsep IAM.

Variabel dan metadata lingkungan

App Engine dan Cloud Run memiliki variabel lingkungan tertentu yang ditetapkan secara otomatis. Tabel di bawah ini menampilkan variabel lingkungan App Engine, beserta Cloud Run yang setara. Cloud Run hanya menerapkan lebih sedikit variabel lingkungan dibandingkan dengan App Engine, tetapi data yang tersedia dari server metadata sebagian besar setara.

Variabel lingkungan default

Nama App Engine Nama Cloud Run Deskripsi
GAE_SERVICE K_SERVICE Nama layanan saat ini. Di App Engine, parameter ini disetel ke `default` jika tidak ditentukan.
GAE_VERSION K_REVISION Label versi layanan Anda saat ini.
PORT PORT Port yang menerima permintaan HTTP.
T/A K_CONFIGURATION Nama konfigurasi Cloud Run yang membuat revisi.
GOOGLE_CLOUD_PROJECT T/A ID project Cloud yang terkait dengan aplikasi Anda.
GAE_APPLICATION ID aplikasi App Engine Anda. ID ini diawali dengan 'kode region~' seperti 'e~' untuk aplikasi yang di-deploy di Eropa.
GAE_DEPLOYMENT_ID ID deployment saat ini.
GAE_ENV Lingkungan App Engine. Tetapkan ke `standar` jika di lingkungan standar.
GAE_INSTANCE ID instance tempat layanan Anda saat ini berjalan.
GAE_MEMORY_MB Jumlah memori yang tersedia untuk proses aplikasi, dalam MB.
NODE_ENV (Hanya tersedia di runtime Node.js) Tetapkan ke produksi saat layanan Anda di-deploy.
GAE_RUNTIME Runtime yang ditentukan dalam file app.yaml Anda.

Jalur server metadata umum

Jalur Deskripsi Contoh
/computeMetadata/v1/project/project-id ID project yang mencerminkan project tempat layanan tersebut berada test_project
/computeMetadata/v1/project/numeric-project-id Nomor project untuk layanan ini 12345678912
/computeMetadata/v1/instance/id ID unik instance container (juga tersedia di log). 16a61494692b7432806a16
(string karakter alfanumerik)
/computeMetadata/v1/instance/region
** Tidak tersedia untuk lingkungan fleksibel App Engine
Region layanan ini, menampilkan projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
/computeMetadata/v1/instance/service-accounts/default/email Email untuk akun layanan runtime layanan ini. service_account@test_project.iam.gserviceaccount.com
/computeMetadata/v1/instance/service-accounts/default/token Membuat token akses OAuth2 untuk akun layanan dari layanan ini. Endpoint ini akan menampilkan respons JSON dengan atribut access_token. {
"access_token":"<TOKEN>",
"expires_in":1799,
"token_type":"Bearer"
}

Langkah selanjutnya