Membagi Traffic

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.

Anda dapat menggunakan pemisahan traffic untuk menentukan distribusi persentase traffic di dua atau beberapa versi dalam suatu layanan. Dengan membagi traffic, Anda dapat melakukan pengujian A/B antarversi dan dapat mengontrol kecepatan saat meluncurkan fitur.

Pemisahan traffic diterapkan ke URL yang tidak secara eksplisit menargetkan versi. Misalnya, URL berikut membagi traffic karena menargetkan semua versi yang tersedia dalam layanan yang ditentukan:

  • https://PROJECT_ID.REGION_ID.r.appspot.com - Mendistribusikan traffic ke versi layanan default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com - Mendistribusikan traffic ke versi layanan [SERVICE_ID].

Untuk mengetahui informasi tentang cara permintaan mencapai suatu versi, lihat Cara Permintaan Dirutekan.

Sebelum memulai

Sebelum Anda dapat mengonfigurasi traffic ke suatu versi, pastikan akun pengguna Anda menyertakan hak istimewa yang diperlukan.

Menghindari masalah terkait penyimpanan ke dalam cache

Sebelum mengaktifkan pemisahan traffic, Anda mungkin ingin memperhitungkan potensi masalah penyimpanan dalam cache. Masalah penyimpanan dalam cache dapat terjadi untuk semua aplikasi App Engine, terutama saat men-deploy versi baru. Pemisahan traffic sering membuat masalah penyimpanan dalam cache yang samar menjadi lebih terlihat.

Misalnya, anggap Anda membagi traffic antara dua versi, A dan B, dan beberapa resource eksternal yang dapat disimpan dalam cache berubah antara versi, misalnya, file CSS. Sekarang anggaplah bahwa klien membuat permintaan dan respons berisi referensi eksternal ke file yang disimpan dalam cache. Cache HTTP lokal akan mengambil file jika file tersebut berada dalam cache, terlepas dari versi file yang disimpan dalam cache dan versi aplikasi yang mengirim respons. Resource yang disimpan dalam cache mungkin tidak kompatibel dengan data yang dikirim dalam respons.

Untuk menghindari masalah penyimpanan dalam cache:

  • Untuk resource dinamis, tetapkan header Cache-Control dan Expires. Kedua header ini memberi tahu proxy bahwa resource tersebut dinamis. Sebaiknya, tetapkan kedua header tersebut karena tidak semua server proxy mendukung header Cache-Control HTTP/1.1 dengan benar.

    Jika Anda ingin informasi selengkapnya tentang penyimpanan dalam cache secara umum, lihat Kolom Header di HTTP/1.1 RFC dan ringkasan penyimpanan dalam cache HTTP di Dasar-Dasar Web.

  • Untuk resource statis yang dapat disimpan dalam cache dan bervariasi antara versi, ubah URL resource antara versi. Jika resource statis disajikan dari URL yang berbeda, kedua versi tersebut dapat berdampingan dengan baik di server proxy dan cache browser.

Anda juga dapat meminta aplikasi menetapkan header Vary: Cookie, sehingga keunikan resource dihitung dengan menggabungkan cookie dan URL untuk permintaan tersebut. Namun, pendekatan ini meningkatkan beban pada server cache. Ada 1000 kemungkinan nilai GOOGAPPUID, sehingga terdapat 1000 entri yang mungkin untuk setiap URL untuk aplikasi Anda. Bergantung pada beban proxy antara pengguna dan aplikasi Anda, hal ini dapat mengurangi seberapa sering aplikasi Anda menayangkan hasil yang disimpan dalam cache. Selain itu, selama 24 jam setelah menambahkan batch pengguna baru ke suatu versi, pengguna tersebut mungkin masih melihat resource yang disimpan dalam cache. Namun, penggunaan Vary: Cookie dapat mempermudah penggantian nama resource statis yang berubah antara versi.

Teknik Vary: Cookie tidak berfungsi dalam semua situasi. Secara umum, jika aplikasi Anda menggunakan cookie untuk tujuan lain, Anda harus mempertimbangkan bagaimana hal ini memengaruhi beban server proxy. Jika codeninja memiliki cookie sendiri yang memiliki 100 kemungkinan nilai, ruang dari semua kemungkinan entri cache menjadi jumlah yang sangat besar (100 * 1.000 = 100.000). Dalam kasus terburuk, ada cookie unik untuk setiap pengguna. Dua contoh umumnya adalah Google Analytics (__utma) dan SiteCatalyst (s_vi). Dalam kasus ini, setiap pengguna akan mendapatkan salinan unik, yang menurunkan performa cache secara signifikan dan juga dapat meningkatkan tagihan jam kerja instance yang dipakai oleh aplikasi Anda.

Memisahkan traffic di beberapa versi

Jika telah menentukan dua versi atau lebih untuk pemisahan, Anda harus memilih apakah akan memisahkan traffic menggunakan alamat IP pengirim atau cookie HTTP. Menyiapkan pemisahan alamat IP memang lebih mudah, tetapi pemisahan cookie lebih bersifat akurat. Untuk mengetahui informasi selengkapnya, lihat Pemisahan alamat IP dan Pemisahan cookie.

Konsol

Untuk membagi traffic di konsol Google Cloud, buka halaman Versi:

Buka halaman Versions

  1. Pilih satu atau beberapa versi ke mana Anda ingin memisahkan traffic.
  2. Klik Split traffic, lalu tentukan:
    • Metode yang ingin Anda gunakan untuk memisahkan traffic.
    • Persentase traffic yang harus diterima setiap versi.

gcloud

Setelah menginstal Google Cloud CLI, Anda menjalankan perintah berikut untuk memisahkan traffic menjadi beberapa versi, misalnya:

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

Untuk mengetahui detail dan opsi tambahan, lihat referensi gcloud app services set-traffic.

API

Untuk memigrasikan traffic secara terprogram, Anda dapat menggunakan Admin API. Baca Memigrasikan dan Memisahkan Traffic untuk mengetahui detailnya.

Pemisahan alamat IP

Jika Anda memilih untuk memisahkan traffic ke aplikasi menurut alamat IP pengirim, saat aplikasi menerima permintaan, aplikasi akan melakukan hashing pada alamat IP dengan nilai antara 0–999, dan menggunakan angka tersebut untuk merutekan permintaan.

Pemisahan alamat IP memiliki beberapa batasan signifikan:

  • Alamat IP pengirim cukup melekat, tetapi tidak permanen. Pengguna yang terhubung dari ponsel mungkin mengalami peralihan alamat IP selama satu sesi. Demikian pula, pengguna di laptop mungkin berpindah dari rumah ke kafe ke kantor, dan juga akan mengalami peralihan alamat IP. Akibatnya, pengguna mungkin merasakan pengalaman yang tidak konsisten dengan aplikasi Anda karena alamat IP mereka berubah.
  • Karena alamat IP ditetapkan secara independen ke berbagai versi, hasil pemisahan traffic akan sedikit berbeda dari yang Anda tentukan. Namun, saat aplikasi menerima lebih banyak traffic, pemisahan yang sebenarnya akan semakin dekat dengan target Anda. Misalnya, jika Anda meminta 5% traffic dikirim ke versi alternatif, persentase awal traffic ke versi tersebut mungkin sebenarnya antara 3–7%, tetapi rata-ratanya pada akhirnya akan mendekati target 5% Anda.
  • Jika Anda perlu mengirim permintaan internal antara aplikasi, sebaiknya gunakan pemisahan cookie. Permintaan yang dikirim antara aplikasi yang berjalan di infrastruktur cloud Google, berasal dari sejumlah kecil alamat IP yang kemungkinan semuanya ditetapkan ke versi yang sama. Oleh karena itu, semua permintaan internal mungkin berperilaku serupa dengan permintaan yang dikirim dari satu alamat IP, yang berarti semua permintaan tersebut akan dirutekan ke versi yang sama. Akibatnya, permintaan internal tidak mendekati persentase yang Anda tetapkan untuk pemisahan traffic berbasis IP. Misalnya, jika Anda menetapkan versi untuk menerima 1% dari semua traffic ke aplikasi Anda dan alamat infrastruktur Google Cloud secara tidak sengaja ditetapkan ke versi tersebut, hasil aktual mungkin jauh melebihi 1% karena semua permintaan internal selalu dirutekan ke versi yang ditetapkan. Permintaan yang dikirim ke aplikasi Anda dari luar infrastruktur cloud Google akan berfungsi seperti yang diharapkan karena permintaan tersebut berasal dari beragam distribusi alamat IP.

Jika Anda memilih untuk memisahkan traffic ke aplikasi Anda berdasarkan cookie, aplikasi akan mencari cookie bernama GOOGAPPUID yang berisi nilai antara 0–999 di header permintaan HTTP:

  • Jika cookie ada, nilai tersebut akan digunakan untuk merutekan permintaan.
  • Jika tidak ada cookie seperti itu, permintaan akan dirutekan secara acak.

Jika respons tidak berisi cookie GOOGAPPUID, aplikasi akan terlebih dahulu menambahkan cookie GOOGAPPUID dengan nilai acak antara 0–999 sebelum dikirim.

Menggunakan cookie untuk memisahkan traffic akan mempermudah penetapan yang akurat bagi pengguna ke berbagai versi. Akurasi untuk pemilihan rute traffic dapat mencapai hingga 0,1% dengan pemisahan target. Meskipun demikian, pemisahan cookie memiliki batasan berikut:

  • Jika Anda menulis aplikasi seluler atau menjalankan klien desktop, pemisahan ini harus mengelola cookie GOOGAPPUID. Misalnya, saat header respons Set-Cookie digunakan, Anda harus menyimpan cookie dan menyertakannya bersama setiap permintaan berikutnya. Aplikasi berbasis browser sudah mengelola cookie dengan cara ini secara otomatis.

  • Memisahkan permintaan internal memerlukan pekerjaan tambahan. Semua permintaan pengguna yang dikirim dari dalam infrastruktur cloud Google, mengharuskan Anda meneruskan cookie pengguna bersama setiap permintaan. Misalnya, Anda harus meneruskan cookie pengguna dalam permintaan yang dikirim dari aplikasi Anda ke aplikasi lain, atau ke aplikasi itu sendiri. Perlu diperhatikan bahwa Anda tidak direkomendasikan untuk mengirim permintaan internal jika permintaan tersebut tidak berasal dari pengguna.

Menonaktifkan pemisahan traffic

Untuk menonaktifkan pemisahan traffic, Anda harus memigrasikan semua traffic ke satu versi.