Praktik terbaik untuk jaringan App Engine

Halaman ini menguraikan praktik terbaik untuk mengonfigurasi opsi jaringan untuk resource App Engine. Sebaiknya Anda meninjau semua bagian di halaman ini untuk memahami opsi jaringan yang didukung App Engine, dan implikasinya.

Praktik terbaik:

Pengelolaan alamat IP.
Memantau penggunaan alamat IP.
Menggunakan alamat IP non-RFC 1918.
Gunakan subnet IPv4 dan IPv6 (dual-stack).
Gunakan penggabungan koneksi dan gunakan kembali koneksi.
Gunakan runtime yang didukung.
Throughput eksternal yang lebih cepat ke internet.
Throughput internal yang lebih cepat ke Google API.

Pengelolaan IP

Anda harus mengelola alamat IP karena setiap instance layanan App Engine menggunakan alamat IP dari subnet Anda. Gunakan strategi berikut untuk mengelola alamat IP Anda:

  • Alokasi IP alternatif: Alokasikan rentang pribadi standar atau rentang IP alternatif untuk mengurangi kehabisan alamat IP. Lihat Strategi kehabisan alamat IP.

  • Ukuran subnet: Pastikan rentang alamat IPv4 subnet Anda adalah /26 atau lebih besar untuk menyediakan alamat IP yang cukup untuk penskalaan.

  • Menyediakan alamat IP secara berlebihan: Sebaiknya sediakan jumlah alamat IP yang tersedia secara berlebihan di subnet Anda untuk menghindari kehabisan alamat IP. Serupa dengan layanan App Engine lainnya, Anda biasanya harus menggunakan alamat IP empat kali lebih banyak (2X untuk status stabil dan 2X tambahan selama deployment) daripada jumlah instance yang berjalan untuk memfasilitasi penskalaan dan update yang lancar.

Memantau penggunaan alamat IP

Jika Anda menggunakan egress Direct VPC, pastikan Anda memiliki alamat IP yang cukup yang dialokasikan untuk subnet Anda. Jumlah alamat IP yang Anda gunakan bergantung pada jumlah instance yang dijalankan workload Anda, jadi sebaiknya pantau penggunaan alamat IP Anda. Pastikan penggunaan IP Anda dari waktu ke waktu tetap berada dalam batas yang didukung oleh subnet.

Untuk memperkirakan penggunaan alamat IP Anda:

  1. Di konsol Google Cloud , buka halaman Metrics Explorer:

    Buka Metrics Explorer

  2. Cari cepat jumlah instance dalam project Anda menggunakan jenis metrik appengine.googleapis.com/system/instance_count. Metrik ini menghitung semua instance App Engine di seluruh project. Untuk versi yang dikonfigurasi dengan traffic keluar VPC Langsung, filter menurut label module_id, yang mengidentifikasi layanan, atau menurut label version_id. Cloud Monitoring memungkinkan Anda melihat nilai metrik ini dari waktu ke waktu.

  3. Kalikan nilai metrik jumlah instance dengan 2 untuk mendapatkan perkiraan jumlah alamat IP yang digunakan.

Strategi kehabisan alamat IP

Memiliki workload App Engine dalam jumlah besar dapat menyebabkan tantangan kehabisan IP saat menggunakan ruang alamat IP pribadi RFC 1918 dengan traffic keluar VPC Langsung. Strategi berikut dapat membantu Anda mengelola kehabisan alamat IP dengan menggunakan rentang alamat IP alternatif.

Menggunakan alamat IPv4 non-RFC 1918

Selain rentang alamat IPv4 RFC 1918, App Engine juga mendukung rentang RFC 6598 dan Class E/RFC 5735. Semua layanan dan fiturGoogle Cloud berfungsi dengan rentang non-RFC 1918 ini, termasuk jaringan VPC, Cloud Load Balancing, dan Private Service Connect.

Untuk kompatibilitas terbaik, sebaiknya mulai dengan rentang RFC 6598 (100.64.0.0/10). Jika Anda sudah menggunakan rentang ini di tempat lain, pertimbangkan Class E/RFC 5735 (240.0.0.0/4). Kelas E adalah ruang yang sangat besar dengan lebih dari 268 juta alamat IP yang tersedia, sehingga akan mendukung pertumbuhan Anda untuk waktu yang lama. Namun, Class E memiliki beberapa batasan. Misalnya, fitur ini tidak didukung di Windows dan di beberapa hardware lokal. Baca cara memanfaatkan ruang Alamat IPv4 Class E untuk mengurangi masalah kehabisan IPv4 di GKE.

Menggunakan Cloud NAT atau Private Service Connect

Jika workload App Engine Anda berada dalam rentang non-RFC 1918 dan perlu menjangkau tujuan lokal yang hanya menerima RFC 1918, pilih salah satu solusi berikut:

  • Gunakan Hybrid NAT untuk melakukan penerjemahan alamat dan egress melalui rentang RFC 1918 yang kecil.
  • Mengekspos layanan lokal sebagai layanan hybrid Private Service Connect.

Menggunakan subnet IPv4 dan IPv6 (dual-stack)

Meskipun tidak akan mengurangi kehabisan IPv4, pertimbangkan untuk memindahkan aplikasi Anda ke IPv6. Untuk menghindari masalah kehabisan IPv4 di masa mendatang, Siapkan resource stack ganda.

Strategi pengurangan kehabisan port

Bagian berikut menjelaskan strategi untuk mengurangi kehabisan port dengan App Engine.

Menggunakan penggabungan koneksi dan menggunakan kembali koneksi

Saat mengirim permintaan dalam jumlah besar dari aplikasi App Engine ke satu alamat IP tujuan, gunakan penggabungan koneksi untuk mempertahankan dan menggunakan kembali koneksi ke tujuan. Tingkat koneksi yang tinggi ke satu alamat IP dapat menghabiskan port keluar dan menyebabkan error koneksi ditolak.

Strategi performa dan throughput

Bagian ini membahas opsi skalabel untuk meningkatkan performa jaringan dan throughput ke internet dan layanan Google.

Menggunakan runtime yang didukung

Traffic keluar VPC langsung hanya didukung pada runtime generasi kedua standar. Runtime yang didukung menjalankan implementasi bahasa standar, mendukung integrasi library modern, dan menawarkan performa jaringan yang lebih cepat dan lebih kuat.

Menggunakan egress Direct VPC untuk throughput egress jaringan yang lebih cepat

Untuk mencapai throughput yang lebih cepat di seluruh koneksi egress jaringan, gunakan egress VPC Langsung untuk merutekan traffic melalui jaringan VPC Anda.

Contoh 1: Traffic eksternal ke internet

Jika Anda mengirim traffic eksternal ke internet publik, rutekan semua traffic melalui jaringan VPC dengan menetapkan kolom vpc_egress ke all-traffic di file app.yaml. Dengan pendekatan ini, Anda harus menyiapkan Cloud NAT untuk menjangkau internet publik.

Untuk menyiapkan Cloud NAT untuk layanan App Engine Anda, lihat Menyiapkan alamat IP keluar statis. Untuk setelan gateway Cloud NAT yang akan digunakan dengan traffic keluar Direct VPC untuk Public NAT atau Private NAT, lihat Interaksi traffic keluar Direct VPC Cloud NAT.

Contoh 2: Traffic internal ke Google API

Jika Anda menggunakan traffic egress VPC Langsung untuk mengirim traffic ke Google API, seperti Cloud Storage, pilih salah satu opsi berikut:

  • Tentukan private-ranges-only (default) dengan Akses Google Pribadi:
    1. Tetapkan vpc_egress: private-ranges-only di file app.yaml Anda.
    2. Mengaktifkan Akses Google Pribadi.
    3. Konfigurasikan DNS untuk Akses Google Pribadi. Pastikan domain target Anda (seperti storage.googleapis.com) dipetakan ke salah satu rentang alamat IP internal berikut:
      • 199.36.153.8/30
      • 199.36.153.4/30
  • Tentukan all-traffic dengan Akses Google Pribadi:
    1. Tetapkan vpc_egress: all-traffic di file app.yaml Anda.
    2. Mengaktifkan Akses Google Pribadi.

Menggunakan setelan MTU default untuk App Engine

Jangan mengubah setelan unit transmisi maksimum (MTU) jaringan VPC saat menggunakannya dengan App Engine. Gunakan MTU default 1.460 byte.

Pertimbangan biaya

Saat mengonfigurasi opsi jaringan untuk resource Anda, pertimbangkan hal berikut:

  • Tempatkan resource Anda di lokasi yang sama: Coba deploy resource App Engine Anda di region yang sama dengan database backend Anda, seperti Cloud SQL, Firestore, dan bucket Cloud Storage. Transfer data antara resource Google Cloud dalam region yang sama tidak dikenai biaya.
  • Beralih ke traffic keluar VPC Langsung: Jika Anda merutekan traffic dengan aman ke resource jaringan VPC internal, pertimbangkan untuk beralih ke traffic keluar VPC Langsung dari konektor Akses VPC Serverless. Traffic keluar VPC langsung tidak dikenai biaya komputasi dasar, sehingga menghilangkan overhead komputasi dasar dan biaya tidak ada aktivitas yang terkait dengan instance konektor.
  • Gunakan Cloud CDN: Kurangi beban aset statis dan konten yang sangat dapat di-cache dengan menempatkan Cloud CDN di depan resource App Engine Anda. Menyajikan data dari edge jauh lebih murah daripada membayar traffic egress internet standar langsung dari App Engine. Anda tidak dapat mengaktifkan Cloud CDN langsung di URL appspot.com default. Sebagai gantinya, rutekan permintaan melalui Load Balancer Aplikasi eksternal yang memiliki backend grup endpoint jaringan (NEG) serverless. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan App Engine.
  • Pantau traffic egress internet: Traffic keluar yang melintasi batas region atau menuju internet publik akan dikenai biaya standar. Fokuskan upaya pemantauan Anda pada traffic keluar yang melintasi batas region.

Tinjau harga App Engine atau perkirakan biaya dengan kalkulator harga untuk mengetahui informasi selengkapnya.

Langkah berikutnya