Artikel ini menjelaskan kriteria yang perlu dipertimbangkan saat memilih region Google Cloud yang akan digunakan untuk resource Compute Engine. Keputusan ini biasanya dibuat oleh arsitek cloud atau pengelolaan engineering. Dokumen ini terutama berfokus pada aspek latensi proses pemilihan dan ditujukan untuk aplikasi yang diakses oleh konsumen, seperti aplikasi atau game seluler atau web. Namun, banyak konsep yang dapat berlaku untuk kasus penggunaan lainnya singkat ini.
Google menawarkan beberapa region di seluruh dunia untuk men-deploy resource Compute Engine Anda. Ada beberapa faktor yang berperan dalam memilih region Anda:
- Pembatasan spesifik per region
- Latensi pengguna menurut region
- Persyaratan latensi aplikasi
- Jumlah kontrol atas latensi
- Seimbangkan antara latensi rendah dan kemudahan
Terminologi
- region
- Area geografis independen tempat Anda menjalankan resource Anda. Setiap region terdiri dari zona, biasanya setidaknya tiga zona.
- zona
- Area deployment untuk resource Google Cloud dalam satu region. Menempatkan resource di zona berbeda dalam satu region akan mengurangi risiko pemadaman infrastruktur yang memengaruhi semua resource secara bersamaan.
- Referensi Compute Engine
- Resource di Compute Engine, seperti Instance virtual machine, di-deploy di zona dalam suatu region. Produk lainnya, seperti Google Kubernetes Engine dan Dataflow menggunakan resource Compute Engine, sehingga dapat di-deploy di region atau zona yang sama.
- Waktu round-trip (RTT)
- Waktu yang diperlukan untuk mengirim paket IP dan menerima konfirmasi.
Kapan harus memilih region Compute Engine
Pada awal fase arsitektur aplikasi, tentukan jumlah dan region Compute Engine yang akan digunakan. Pilihan Anda dapat memengaruhi aplikasi, misalnya:
- Arsitektur aplikasi dapat berubah jika Anda menyinkronkan beberapa data antar-salinan karena pengguna yang sama dapat terhubung melalui region yang berbeda pada waktu yang berbeda.
- Harga berbeda menurut wilayah.
- Proses untuk memindahkan aplikasi dan datanya antar-region tidak praktis dan terkadang mahal, jadi harus dihindari setelah aplikasi aktif.
Faktor-faktor yang perlu dipertimbangkan saat memilih region
Sangat umum bagi pengguna untuk men-deploy di region tempat mereka berada, tetapi mereka tidak mempertimbangkan apakah ini adalah pengalaman pengguna terbaik. Misalkan Anda berada di Eropa dengan basis pengguna global dan ingin melakukan deployment di satu region. Sebagian besar orang akan mempertimbangkan untuk melakukan deployment di region di Eropa, tetapi biasanya ini menjadi pilihan terbaik untuk menghosting aplikasi ini di salah satu region AS, karena AS adalah yang paling terhubung dengan region lain.
Beberapa faktor memengaruhi tempat Anda memutuskan untuk men-deploy aplikasi.
Latensi
Faktor utama yang perlu dipertimbangkan adalah latensi yang dialami pengguna. Namun, hal ini adalah masalah yang kompleks karena latensi pengguna dipengaruhi oleh beberapa aspek, seperti mekanisme caching dan load balancing.
Dalam kasus penggunaan perusahaan, latensi ke sistem lokal atau latensi untuk sebagian pengguna atau partner tertentu menjadi lebih penting. Misalnya, memilih region terdekat dengan developer atau layanan database lokal yang terhubung dengan Google Cloud mungkin menjadi faktor penentu.
Harga
Biaya resource Google Cloud berbeda-beda di setiap region. Referensi berikut tersedia untuk memperkirakan harga:
Jika Anda memutuskan untuk men-deploy aplikasi di beberapa region, perhatikan bahwa ada biaya transfer data untuk data yang disinkronkan antar-region.
Kolokasi dengan layanan Google Cloud lainnya
Tempatkan resource Compute Engine Anda dengan layanan Google Cloud lainnya, jika memungkinkan. Meskipun sebagian besar layanan yang sensitif terhadap latensi tersedia di setiap region, beberapa layanan hanya tersedia di lokasi tertentu.
Ketersediaan jenis mesin
Tidak semua platform CPU dan jenis mesin tersedia di setiap region. Ketersediaan platform CPU tertentu atau jenis instance tertentu berbeda-beda menurut region dan bahkan zona. Jika Anda ingin men-deploy resource menggunakan jenis mesin tertentu, cari tahu ketersediaan zona resource ini.
Kuota resource
Kemampuan Anda untuk men-deploy resource Compute Engine dibatasi oleh kuota resource regional, jadi pastikan Anda meminta kuota yang cukup di region tempat Anda akan men-deploy. Jika Anda merencanakan deployment yang sangat besar, bekerja samalah dengan tim penjualan sejak awal untuk mendiskusikan pilihan pemilihan region Anda guna memastikan Anda memiliki kapasitas kuota yang memadai.
Persentase energi bebas karbon
Untuk menyediakan daya ke setiap region Google Cloud, Google menggunakan listrik dari jaringan listrik tempat region berada. Listrik ini menghasilkan lebih banyak atau lebih sedikit emisi karbon, bergantung pada jenis pembangkit listrik yang menghasilkan listrik untuk jaringan tersebut dan saat Google memakainya. Google baru-baru ini menetapkan sasaran bahwa pada tahun 2030, kami akan memiliki listrik bebas karbon yang mendukung aplikasi Anda di waktu dan tempat yang Anda butuhkan —24 jam sehari, di setiap region Google Cloud.
Hingga tujuan tersebut tercapai, setiap region Google Cloud akan disuplai oleh campuran sumber energi berbasis karbon dan bebas karbon setiap jam. Kami menyebut metrik ini sebagai persentase energi bebas karbon (CFE%) dan kami memublikasikan CFE% untuk region Google Cloud. Untuk aplikasi baru di Google Cloud, Anda dapat menggunakan tabel ini untuk mulai menyertakan dampak karbon ke dalam keputusan arsitektur Anda. Memilih region dengan % CFE yang lebih tinggi berarti rata-rata, aplikasi Anda akan disuplai energi bebas karbon dengan persentase jam yang lebih tinggi untuk aplikasi tersebut, sehingga mengurangi emisi karbon kotor aplikasi tersebut.
Mengevaluasi persyaratan latensi
Latensi sering kali menjadi pertimbangan utama saat memilih region karena latensi pengguna yang tinggi dapat mengakibatkan pengalaman pengguna yang rendah. Anda dapat memengaruhi beberapa aspek latensi, tetapi beberapa di antaranya berada di luar kendali Anda.
Saat mengoptimalkan latensi, banyak arsitek sistem hanya mempertimbangkan latensi jaringan atau jarak antara ISP pengguna dan instance mesin virtual. Namun, ini hanyalah salah satu dari banyak faktor yang memengaruhi latensi pengguna, seperti yang dapat Anda lihat pada diagram berikut.
Sebagai arsitek aplikasi, Anda dapat mengoptimalkan pemilihan region dan latensi aplikasi, tetapi tidak memiliki kontrol atas kilometer terakhir dan latensi pengguna ke edge Google terdekatTitik Kehadiran (POP) singkat ini.
Pemilihan region hanya dapat memengaruhi latensi ke region Compute Engine dan bukan keseluruhan latensi. Bergantung pada kasus penggunaannya, hal ini mungkin hanya sebagian kecil dari keseluruhan latensi. Misalnya, jika pengguna utamanya menggunakan jaringan seluler, mungkin tidak ada baiknya untuk mencoba mengoptimalkan region Anda, karena hal ini hampir tidak memengaruhi total latensi pengguna.
Latensi kilometer terakhir
Latensi segmen ini berbeda-beda, bergantung pada teknologi yang digunakan untuk mengakses internet. Misalnya, latensi umum untuk menjangkau ISP adalah 1-10 md pada jaringan modern. Sebaliknya, latensi standar pada jaringan seluler 3G adalah 100-500 md. Rentang latensi untuk penyedia DSL dan kabel sekitar 10-60 md.
Latensi POP frontend dan edge Google
Bergantung pada model deployment Anda, latensi ke edge jaringan Google juga penting. Di sinilah produk load balancing global menghentikan sesi TCP dan SSL, dan dari sinilah Cloud CDN mengirimkan hasil yang di-cache. Berdasarkan konten yang ditayangkan, banyak perjalanan bolak-balik mungkin sudah berakhir di sini karena hanya sebagian data yang perlu diambil seluruhnya. Latensi ini mungkin jauh lebih tinggi jika Anda menggunakan tingkat layanan jaringan standar.
Latensi region Compute Engine
Permintaan pengguna memasuki jaringan Google di POP edge. Region Compute Engine adalah tempat permintaan penanganan resource Google Cloud berada. Segmen ini adalah latensi antara POP edge dan region Compute Engine, dan sepenuhnya berada di dalam jaringan global Google.
Latensi aplikasi
Ini adalah latensi dari aplikasi yang merespons permintaan, termasuk waktu yang dibutuhkan aplikasi untuk memproses permintaan.
Aplikasi yang berbeda memiliki persyaratan latensi yang berbeda. Bergantung pada aplikasinya, pengguna lebih mudah memaklumi masalah latensi. Aplikasi yang berinteraksi secara asinkron atau aplikasi seluler dengan batas latensi tinggi—100 milidetik atau lebih—dapat di-deploy di satu region tanpa menurunkan pengalaman pengguna. Namun, untuk aplikasi seperti game real-time, latensi beberapa milidetik dapat berdampak lebih besar pada pengalaman pengguna. Deploy jenis aplikasi ini di beberapa region yang dekat dengan pengguna.
Pola deployment global
Bagian ini menjelaskan pengaruh berbagai model deployment terhadap faktor latensi.
Deployment region tunggal
Gambar berikut mengilustrasikan deployment satu region.
Meskipun aplikasi Anda melayani basis pengguna global, dalam banyak kasus, satu region masih menjadi pilihan terbaik. Manfaat latensi yang lebih rendah mungkin tidak melebihi kompleksitas tambahan dari deployment multi-region. Meskipun dengan deployment region tunggal, Anda masih dapat menggunakan pengoptimalan, seperti Cloud CDN dan load balancing global, untuk mengurangi latensi pengguna. Anda dapat memilih untuk menggunakan region kedua untuk alasan pencadangan dan pemulihan dari bencana (disaster recovery), tetapi hal ini tidak memengaruhi jalur penyaluran aplikasi sehingga tidak akan memengaruhi latensi pengguna.
Frontend terdistribusi di beberapa region dan backend dalam satu region
Diagram berikut menunjukkan model deployment tempat Anda mendistribusikan frontend di beberapa region, tetapi membatasi backend ke satu region. Model ini memberi Anda manfaat latensi yang lebih rendah ke server frontend tanpa perlu menyinkronkan data di beberapa region.
Model deployment ini memberikan latensi pengguna yang rendah dalam skenario ketika permintaan pengguna rata-rata tidak melibatkan permintaan data atau hanya melibatkan beberapa permintaan data ke backend pusat sebelum aplikasi dapat memberikan hasil. Contohnya adalah aplikasi yang men-deploy lapisan cache cerdas di frontend atau yang menangani penulisan data secara asinkron. Aplikasi yang membuat banyak permintaan yang memerlukan perjalanan dua arah penuh ke backend mungkin tidak mendapatkan manfaat dari model ini.
Frontend dan backend terdistribusi di beberapa region
Model deployment yang mendistribusikan frontend dan backend di beberapa region akan memungkinkan Anda meminimalkan latensi pengguna karena aplikasi dapat sepenuhnya menjawab permintaan apa pun secara lokal. Namun, model ini memiliki kompleksitas tambahan karena semua data harus disimpan dan dapat diakses secara lokal. Untuk menjawab semua permintaan pengguna, data harus direplikasi sepenuhnya di semua region.
Spanner, yang merupakan penawaran database terkelola yang konsisten secara global, memiliki opsi multi-regional tiga benua, dengan selain replika baca-tulis di AS, dua replika baca terletak di Eropa dan Asia. Opsi ini memberikan akses baca berlatensi rendah ke data tersebut untuk menghitung instance yang terletak di AS, Eropa, atau Asia. Jika layanan Anda menargetkan AS, opsi multi-regional dengan replikasi di AS juga tersedia.
Jika memutuskan untuk menjalankan layanan database Anda sendiri di Compute Engine, Anda harus mereplikasi data sendiri. Replikasi ini adalah upaya yang signifikan karena sulit dilakukan untuk menjaga data secara konsisten agar disinkronkan secara global. Akan lebih mudah mengelola jika database hanya ditulis ke satu region melalui penulisan asinkron, sedangkan region lain menghosting replika hanya baca database tersebut.
Mereplikasi database di berbagai region bukanlah hal yang mudah, dan sebaiknya libatkan partner kuat yang memiliki pengalaman di area ini, seperti Datastax untuk replikasi Cassandra.
Beberapa aplikasi paralel
Bergantung pada sifat aplikasi Anda, dengan variasi pendekatan sebelumnya, Anda dapat mempertahankan latensi pengguna yang rendah sekaligus mengurangi kebutuhan replikasi data konstan. Seperti yang ditunjukkan dalam gambar berikut, ada beberapa aplikasi paralel, yang semuanya terdiri dari frontend dan backend, serta pengguna diarahkan ke aplikasi yang benar. Hanya sebagian kecil data yang dibagikan antar-situs.
Misalnya, saat menjalankan bisnis retail, Anda mungkin melayani pengguna di berbagai wilayah melalui domain negara yang berbeda dan menjalankan situs paralel di semua region tersebut. Anda hanya perlu menyinkronkan data produk dan pengguna jika diperlukan. Situs lokal akan mempertahankan ketersediaan stok lokal mereka dan pengguna terhubung ke situs yang dihosting secara lokal dengan memilih domain negara. Saat pengguna mengunjungi domain negara lain, mereka akan dialihkan ke domain yang benar.
Contoh lainnya adalah dalam game real-time. Anda mungkin hanya memiliki layanan lobi global di mana pengguna memilih ruang game atau dunia yang dekat dengan lokasi mereka dan kamar atau dunia tersebut tidak berbagi data satu sama lain.
Contoh ketiga menawarkan Software-as-a-Service (SaaS) di berbagai region, dengan lokasi data dipilih saat pembuatan akun, baik berdasarkan lokasi pengguna maupun pilihan mereka. Setelah login, pengguna dialihkan ke subdomain spesifik per lokasi dan menggunakan layanan ini secara regional.
Mengoptimalkan latensi antara pengguna dan region
Apa pun model deployment, Anda dapat menggabungkan metode pengoptimalan untuk mengurangi latensi yang terlihat kepada pengguna akhir. Beberapa metode ini adalah fitur Google Cloud, sementara metode lainnya mengharuskan Anda mengubah aplikasi.
Menggunakan jaringan Paket Premium
Google menawarkan Network Service Tiers premium (default) dan standar. Traffic Tingkat Standar dikirimkan melalui ISP transit dari region Google Cloud, sedangkan Paket Premium menawarkan latensi yang lebih rendah dengan mengirimkan traffic melalui jaringan pribadi global Google. Jaringan Paket Premium mengurangi latensi pengguna dan harus digunakan untuk semua bagian aplikasi di jalur penayangan. Jaringan Paket Premium juga diperlukan untuk menggunakan produk load balancing global Google.
Menggunakan Cloud Load Balancing dan Cloud CDN
Cloud Load Balancing, seperti load balancing HTTP(S), TCP, dan proxy SSL, memungkinkan Anda secara otomatis mengalihkan pengguna ke region terdekat yang memiliki backend dengan kapasitas yang tersedia.
Meskipun aplikasi Anda hanya berada di satu region, penggunaan Cloud Load Balancing tetap akan memberikan latensi pengguna yang lebih rendah karena sesi TCP dan SSL dihentikan di edge jaringan. Hentikan traffic pengguna dengan mudah menggunakan HTTP/2 dan Quick UDP Internet Connections (QUIC). Anda juga dapat mengintegrasikan Cloud CDN dengan load balancing HTTP(S) untuk mengirimkan aset statis langsung dari edge jaringan, sehingga semakin mengurangi latensi pengguna.
Menyimpan cache secara lokal
Jika lokasi frontend berbeda dengan lokasi backend, pastikan untuk menyimpan jawaban ke dalam cache dari layanan backend jika memungkinkan. Saat frontend dan backend berada di region yang sama, latensi aplikasi akan berkurang karena kueri yang memakan waktu juga berkurang. Memorystore for Redis adalah penyimpanan data dalam memori yang terkelola sepenuhnya yang dapat Anda gunakan.
Mengoptimalkan klien aplikasi atau frontend web Anda
Anda dapat menggunakan teknik di sisi klien, baik aplikasi seluler maupun frontend web, untuk mengoptimalkan latensi pengguna. Misalnya, lakukan pramuat beberapa aset atau data cache dalam aplikasi.
Anda juga dapat mengoptimalkan cara aplikasi mengambil informasi dengan mengurangi jumlah permintaan dan mengambil informasi secara paralel, jika memungkinkan.
Mengukur latensi pengguna
Setelah Anda menetapkan dasar pengukuran persyaratan latensi, lihat basis pengguna Anda untuk menentukan penempatan terbaik untuk resource Google Cloud. Bergantung pada apakah ini aplikasi baru atau yang sudah ada, ada berbagai strategi yang dapat digunakan.
Gunakan strategi berikut untuk mengukur latensi ke partner yang Anda akses selama penayangan aplikasi atau untuk mengukur latensi ke jaringan lokal yang mungkin saling terhubung dengan project Google Cloud Anda menggunakan Cloud VPN atau Dedicated Interconnect.
Memperkirakan latensi untuk workload baru
Jika Anda belum memiliki aplikasi dengan basis pengguna yang serupa dengan aplikasi baru, perkirakan latensi dari berbagai region Google Cloud berdasarkan distribusi lokasi kasar dari basis pengguna yang Anda harapkan.
Perkirakan latensi bolak-balik 1 md untuk setiap 100 km yang ditempuh. Karena jaringan tidak mengikuti jalur ideal dari sumber ke tujuan, biasanya Anda dapat menebak bahwa jarak sebenarnya adalah sekitar 1,5 hingga 2 kali jarak yang diukur pada peta. Tentu saja, di wilayah yang tidak padat penduduknya, jaringan mungkin mengikuti jalur yang bahkan kurang ideal. Latensi yang ditambahkan melalui peralatan aktif dalam jaringan ISP biasanya dapat diabaikan saat melihat jarak lintas regional.
Angka-angka ini dapat membantu Anda memperkirakan latensi ke node POP dan Cloud CDN edge, serta region Compute Engine di seluruh dunia seperti yang tercantum di peta jaringan.
Mengukur latensi untuk pengguna yang ada
Jika Anda sudah memiliki aplikasi dengan basis pengguna serupa, ada beberapa alat yang dapat digunakan untuk memperkirakan latensi dengan lebih baik.
- Pengguna representatif: Jika Anda memiliki pengguna atau partner, yang mewakili seluruh distribusi geografis dan bersedia bekerja sama dengan Anda, atau karyawan di negara tersebut, tanyakan kepada mereka untuk mengukur latensi ke berbagai region Google Cloud. Situs pihak ketiga seperti ping Google Cloud dapat membantu Anda melakukan beberapa pengukuran.
- Log akses: Jika Anda memiliki aplikasi aktif yang dihosting di luar Google Cloud, gunakan data dari log akses untuk mendapatkan gambaran kasar tentang lintas bagian pengguna. Log Anda mungkin memberikan informasi negara atau kota, yang juga memungkinkan Anda memperkirakan latensi.
- Alamat IP: Jika Anda memiliki akses ke alamat IP pengguna, buat skrip untuk menguji keterjangkauan dan latensi dari berbagai region Google Cloud. Jika firewall mereka memblokir pemeriksaan Anda, coba acak oktet IP terakhir untuk mendapatkan respons dari perangkat lain yang memiliki latensi serupa dengan aplikasi Anda.
Informasi latensi dari Google Cloud: Jika Anda memiliki aplikasi yang ada di Google Cloud, ada beberapa cara untuk mengumpulkan informasi latensi.
- Header permintaan yang ditentukan pengguna**: Aktifkan header untuk informasi negara, subwilayah, dan kota pelanggan, serta perkiraan RTT antara load balancer dan klien.
- Metrik Cloud Monitoring untuk load balancing HTTP(S): Menyertakan RTT frontend dan latensi backend.
- Log Alur VPC: Anda mendapatkan TCP RTT di antara kedua ujung koneksi sebagai bagian dari metrik yang disediakan.
Konektivitas global
Saat memperkirakan latensi, perhatikan topologi jaringan global Google.
- POP: Tempat traffic pengguna memasuki jaringan.
- Node Cloud CDN: Tempat traffic di-cache.
- Region: Tempat resource Anda dapat berada.
- Konektivitas: Antara POP dan region.
Temukan daftar lokasi tempat Google saling terhubung dengan ISP lain di PeeringDB.
Pastikan untuk mempertimbangkan topologi antarregional saat menentukan region yang akan di-deploy. Misalnya, jika Anda ingin men-deploy aplikasi dengan basis pengguna global di satu region, sebaiknya jalankan aplikasi ini di salah satu region AS–karena AS terhubung ke sebagian besar region lain. Meskipun ada konektivitas langsung antara banyak benua, ada kasus di mana koneksi langsung tidak ada, misalnya, antara Eropa dan Asia, sehingga traffic antara Eropa dan Asia mengalir melalui AS.
Jika aplikasi Anda dihosting di beberapa region dan Anda perlu menyinkronkan data, perhatikan latensi di antara region tersebut. Meskipun latensi ini dapat berubah dari waktu ke waktu, latensi ini biasanya stabil. Ukur latensi sendiri dengan menampilkan instance pengujian di semua region potensial atau gunakan situs pihak ketiga untuk mengetahui latensi saat ini antar-region.
Menyatukan semuanya
Setelah mempertimbangkan persyaratan latensi, kemungkinan model deployment, dan distribusi geografis basis pengguna, Anda memahami pengaruh faktor-faktor ini terhadap latensi pada region tertentu. Saatnya menentukan region untuk meluncurkan aplikasi Anda.
Meskipun tidak ada cara yang tepat untuk menimbang berbagai faktor, metodologi langkah demi langkah berikut dapat membantu Anda memutuskan:
- Periksa apakah ada faktor terkait non-latensi yang menghalangi Anda melakukan deployment di region tertentu, seperti harga atau kolokasi. Hapus tabel tersebut dari daftar region Anda.
- Pilih model deployment berdasarkan persyaratan latensi dan arsitektur umum aplikasi. Untuk sebagian besar aplikasi penting non-latensi lainnya, deployment satu region dengan pengiriman konten yang dapat di-cache dengan Cloud CDN dan penghentian SSL di edge mungkin menjadi pilihan yang optimal.
Berdasarkan model deployment Anda, pilih region berdasarkan distribusi geografis basis pengguna dan pengukuran latensi Anda:
Untuk deployment region tunggal:
- Jika Anda membutuhkan akses latensi rendah ke lokasi perusahaan Anda, deploy di region yang paling dekat dengan lokasi ini.
- Jika pengguna Anda terutama berasal dari satu negara atau wilayah, deploy di region yang paling dekat dengan pengguna perwakilan Anda.
- Untuk basis pengguna global, deploy dalam region di AS.
Untuk deployment multi-region:
- Pilih region yang dekat dengan pengguna berdasarkan distribusi geografis dan persyaratan latensi aplikasi. Bergantung pada aplikasi Anda, optimalkan latensi median tertentu atau pastikan 95-99% pengguna dilayani dengan latensi target tertentu. Pengguna di lokasi geografis tertentu sering kali memiliki toleransi latensi yang lebih tinggi karena keterbatasan infrastruktur.
Jika latensi pengguna serupa di beberapa region, harga dapat menjadi faktor penentu.
Saat memilih region Compute Engine, latensi adalah salah satu faktor terbesar yang perlu dipertimbangkan. Evaluasi dan ukur persyaratan latensi untuk memberikan pengalaman pengguna yang berkualitas, dan ulangi proses ini jika distribusi geografis basis pengguna Anda berubah.
Langkah selanjutnya
- Tinjau region dan zona Compute Engine.
- Pelajari cara Mengoptimalkan latensi aplikasi dengan load balancing.
- Baca panduan Google Cloud untuk profesional pusat data.
- Tonton serial video Cloud performance atlas.
- Untuk mengetahui tampilan lebih lengkap tentang cara mengoptimalkan latensi pengguna, lihat situs Jaringan browser berperforma tinggi.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.