Artikel ini menjelaskan kriteria yang perlu dipertimbangkan saat memilih region Google Cloudyang akan digunakan untuk resource Compute Engine. Keputusan ini biasanya dibuat oleh cloud architect atau manajemen engineering. Dokumen ini berfokus terutama pada aspek latensi proses pemilihan dan ditujukan untuk aplikasi yang diakses oleh konsumen, seperti aplikasi atau game seluler atau web. Namun, banyak konsep dapat berlaku untuk kasus penggunaan lain.
Google menawarkan multi-region di seluruh dunia untuk men-deploy resource Compute Engine Anda. Ada beberapa faktor yang perlu diperhatikan saat memilih region:
- Pembatasan spesifik per region
- Latensi pengguna berdasarkan region
- Persyaratan latensi aplikasi Anda
- Tingkat kontrol atas latensi
- Keseimbangan antara latensi rendah dan kemudahan
Terminologi
- region
- Area geografis independen tempat Anda menjalankan resource. Setiap region terdiri atas beberapa zona, biasanya minimal tiga zona.
- zona
- Area deployment untuk resource Google Cloud dalam suatu region. Menempatkan resource di zona berbeda dalam suatu region akan mengurangi risiko pemadaman infrastruktur yang memengaruhi semua resource secara bersamaan.
- Resource Compute Engine
- Resource di Compute Engine, seperti instance Virtual machine, di-deploy di sebuah 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 tahap perancangan awal aplikasi, tentukan jumlah dan region Compute Engine yang akan digunakan. Pilihan Anda dapat memengaruhi aplikasi Anda, misalnya:
- Arsitektur aplikasi dapat berubah jika Anda menyinkronkan beberapa data antar-salinan karena pengguna yang sama dapat terhubung melalui region berbeda pada waktu yang berbeda.
- Harga berbeda menurut wilayah.
- Proses pemindahan aplikasi dan datanya dari satu region ke region yang lain itu rumit dan terkadang membutuhkan biaya besar, jadi sebaiknya dihindari setelah aplikasi aktif.
Faktor-faktor yang perlu dipertimbangkan saat memilih region
Pengguna biasanya melakukan deployment di region tempat mereka berada, tetapi mereka tidak mempertimbangkan apakah hal itu memberikan pengalaman terbaik bagi pengguna. Misalkan Anda berada di Eropa dengan basis pengguna global dan ingin melakukan deployment di satu region. Kebanyakan orang akan mempertimbangkan deployment di region Eropa, tetapi biasanya pilihan terbaiknya adalah menghosting aplikasi ini di salah satu region AS, karena AS memiliki koneksi paling banyak ke region lain.
Keputusan Anda terkait region untuk men-deploy aplikasi dapat dipengaruhi oleh sejumlah faktor.
Latensi
Faktor utama yang perlu dipertimbangkan adalah latensi yang dialami pengguna. Namun, hal ini merupakan masalah kompleks karena latensi pengguna dipengaruhi oleh beberapa aspek, seperti mekanisme caching dan load balancing.
Dalam kasus penggunaan perusahaan, latensi pada sistem lokal atau latensi untuk subset pengguna atau partner tertentu lebih penting. Misalnya, memilih region yang paling dekat dengan developer atau layanan database lokal yang saling terhubung denganGoogle Cloud dapat menjadi faktor penentu.
Harga
Biaya resourceGoogle Cloud berbeda-beda di setiap region. Referensi berikut tersedia untuk memperkirakan harga:
Jika Anda memutuskan untuk melakukan deployment 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 di region yang sama dengan layanan Google Cloudlainnya, 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 resource tersebut menurut zona.
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 melakukan deployment. Jika Anda merencanakan deployment yang sangat besar, hubungi tim penjualan sejak awal untuk mendiskusikan pemilihan region guna memastikan Anda memiliki kapasitas kuota yang memadai.
Persentase energi bebas karbon
Untuk menyuplai daya ke setiap region Google Cloud , Google menggunakan listrik dari jaringan listrik tempat region tersebut berada. Emisi karbon yang dihasilkan listrik ini dapat tinggi atau rendah, tergantung jenis pembangkit yang menghasilkan listrik untuk jaringan tersebut dan kapan Google memakainya. Belum lama ini, Google menetapkan target bahwa selambat-lambatnya pada tahun 2030, kami akan memiliki listrik bebas karbon yang mendukung aplikasi Anda kapan pun dan di mana pun Anda membutuhkannya—24 jam sehari, di setiap region Google Cloud .
Hingga target tersebut tercapai, setiap region Google Cloud akan disuplai oleh campuran sumber energi berbasis karbon dan bebas karbon setiap jamnya. 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 persentase CFE lebih tinggi berarti, rata-rata, aplikasi Anda akan lebih sering ditenagai energi bebas karbon, 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 berupaya mengoptimalkan latensi, banyak arsitek sistem hanya mempertimbangkan latensi jaringan atau jarak antara ISP pengguna dan instance virtual machine. Namun, ini hanyalah salah satu dari banyak faktor yang memengaruhi latensi pengguna, seperti yang dapat Anda lihat dalam diagram berikut.
Sebagai arsitek aplikasi, Anda dapat mengoptimalkan pemilihan region dan latensi aplikasi, tetapi tidak memiliki kontrol atas kilometer terakhir dan latensi pengguna ke Titik Kehadiran (POP) edge Google terdekat.
Pemilihan region hanya dapat memengaruhi latensi ke region Compute Engine dan bukan keseluruhan latensi. Bergantung pada kasus penggunaannya, pemilihan region mungkin hanya memengaruhi sebagian kecil dari keseluruhan latensi. Misalnya, jika pengguna Anda lebih cenderung menggunakan jaringan seluler, pengoptimalan region mungkin kurang memberi dampak, karena hal tersebut hampir tidak memengaruhi total latensi pengguna.
Latensi kilometer terakhir
Latensi segmen ini berbeda-beda, bergantung pada teknologi yang digunakan untuk mengakses internet. Misalnya, latensi standar untuk menjangkau sebuah ISP adalah 1-10 mdtk di jaringan modern. Sebaliknya, latensi standar di jaringan seluler 3G adalah 100-500 mdtk. Rentang latensi untuk penyedia DSL dan kabel adalah sekitar 10-60 mdtk.
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 disajikan, banyak perjalanan bolak-balik mungkin berakhir di sini karena hanya sebagian data yang perlu diambil dari keseluruhan proses. Latensi ini mungkin akan jauh lebih tinggi jika Anda menggunakan paket layanan jaringan standar.
Latensi region Compute Engine
Permintaan pengguna memasuki jaringan Google di POP edge. Region Compute Engine adalah tempat resource Google Cloud menangani permintaan. 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 toleran dengan masalah latensi. Aplikasi yang berinteraksi secara asinkron atau aplikasi seluler dengan nilai minimum latensi yang 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 aplikasi semacam ini di banyak 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 region tunggal.
Meskipun aplikasi Anda melayani basis pengguna global, dalam banyak kasus, region tunggal masih menjadi pilihan terbaik. Manfaat latensinya yang lebih rendah mungkin tidak mengalahkan kerumitan ekstra dari deployment multi-region. Meskipun menggunakan deployment region tunggal, Anda masih dapat menggunakan pengoptimalan, seperti Cloud CDN dan load balancing global, untuk mengurangi latensi pengguna. Anda dapat menggunakan region kedua untuk pencadangan dan disaster recovery, tetapi hal ini tidak memengaruhi jalur penyajian aplikasi sehingga tidak berdampak pada latensi pengguna.
Frontend terdistribusi di beberapa region dan backend di satu region
Diagram berikut menunjukkan model deployment di mana 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 caching 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—penawaran database terkelola yang konsisten secara global—memiliki opsi multi-regional tiga benua dengan replika baca-tulis di AS, dan dua replika baca di Eropa dan Asia. Opsi ini memberikan akses baca berlatensi rendah ke data pada instance komputasi yang berada di AS, Eropa, atau Asia. Jika layanan Anda menarget 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 membutuhkan upaya yang signifikan, karena menjaga data tetap sinkron secara konsisten di seluruh dunia sulit dilakukan. Pengelolaan akan lebih mudah jika database hanya ditulis ke satu region melalui penulisan asinkron, sedangkan region lainnya menghosting replika hanya baca database tersebut.
Mereplikasi database di berbagai region bukanlah pekerjaan mudah. Sebaiknya Anda melibatkan partner andal yang memiliki pengalaman dalam 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 akan replikasi data yang terus-menerus. Seperti yang ditunjukkan dalam gambar berikut, terdapat beberapa aplikasi paralel, yang semuanya terdiri atas frontend dan backend, dan pengguna dialihkan ke aplikasi yang benar. Hanya sebagian kecil data yang dibagikan antar-situs.
Misalnya, saat menjalankan bisnis retail, Anda mungkin melayani pengguna di beberapa region berbeda melalui domain negara yang berbeda dan menjalankan situs paralel di semua region tersebut. Anda hanya menyinkronkan data produk dan pengguna jika diperlukan. Situs lokal menjaga ketersediaan stok lokal dan pengguna terhubung ke situs yang dihosting secara lokal dengan memilih domain negara. Saat pengguna mengunjungi domain negara lain, ia akan dialihkan ke domain yang benar.
Contoh lainnya adalah game real-time. Anda mungkin hanya memiliki layanan lobi global tempat pengguna memilih ruang game atau dunia yang dekat dengan lokasi mereka, dan ruang atau dunia tersebut tidak saling berbagi data.
Contoh ketiga adalah menawarkan Software as a Service (SaaS) di berbagai region, dengan lokasi data yang ditentukan selama proses pembuatan akun, berdasarkan lokasi pengguna atau pilihan mereka. Setelah login, pengguna dialihkan ke subdomain spesifik lokasi dan menggunakan layanan ini secara regional.
Mengoptimalkan latensi antara pengguna dan region
Apa pun model deployment-nya, Anda dapat menggabungkan metode pengoptimalan untuk mengurangi latensi yang dialami pengguna akhir. Sebagian metode ini merupakan fiturGoogle Cloud , sementara sebagian lainnya mengharuskan Anda mengubah aplikasi.
Menggunakan jaringan Paket Premium
Google menawarkan Network Service Tiers premium (default) dan standar. Traffic Paket Standar dikirim melalui ISP transit dari region Google Cloud, sedangkan Paket Premium menawarkan latensi yang lebih rendah dengan mengirim traffic melalui jaringan pribadi global Google. Jaringan Paket Premium mengurangi latensi pengguna dan sebaiknya 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 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 makin mengurangi latensi pengguna.
Meng-cache secara lokal
Jika lokasi frontend berbeda dengan lokasi backend, pastikan untuk meng-cache jawaban 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. Anda dapat menggunakan Memorystore for Redis untuk penyimpanan data dalam memori yang terkelola sepenuhnya.
Mengoptimalkan klien aplikasi atau frontend web
Anda dapat menggunakan berbagai teknik di sisi klien, entah itu aplikasi seluler atau frontend web, untuk mengoptimalkan latensi pengguna. Misalnya, mempramuat 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 menetapkan dasar pengukuran persyaratan latensi Anda, lihat basis pengguna Anda untuk menentukan penempatan terbaik resource Google Cloud Anda. Bergantung pada apakah ini aplikasi baru atau lama, ada berbagai strategi yang dapat Anda gunakan.
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 melalui Cloud VPN atau Dedicated Interconnect.
Memperkirakan latensi untuk workload baru
Jika Anda belum memiliki aplikasi dengan basis pengguna yang mirip 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 mdtk untuk setiap 100 km yang ditempuh. Karena jaringan tidak mengikuti jalur ideal dari sumber ke tujuan, Anda dapat mengira-ngira jarak sebenarnya, yaitu sekitar 1,5 hingga 2 kali jarak yang diukur pada peta. Tentu saja, di wilayah yang tidak padat penduduknya, jaringan mungkin mengikuti jalur yang jauh kurang ideal. Penambahan latensi akibat peralatan aktif dalam jaringan ISP biasanya dapat diabaikan saat melihat jarak lintas regional.
Angka-angka ini dapat membantu Anda memperkirakan latensi ke node POP edge dan Cloud CDN, serta region Compute Engine di seluruh dunia seperti yang tercantum di peta jaringan.
Mengukur latensi ke pengguna yang ada
Jika Anda sudah memiliki aplikasi dengan basis pengguna yang mirip, ada beberapa alat yang dapat Anda gunakan untuk memperkirakan latensi dengan lebih baik.
- Pengguna representatif: Jika Anda memiliki pengguna atau partner, yang mewakili sebagian distribusi geografis Anda dan bersedia bekerja sama dengan Anda, atau karyawan di negara tersebut, minta mereka untuk mengukur latensi ke berbagai region Google Cloud . Situs pihak ketiga seperti pingGoogle Cloud dapat membantu Anda melakukan beberapa pengukuran.
- Log akses: Jika Anda memiliki aplikasi aktif yang dihosting di luarGoogle Cloud, gunakan data dari log akses untuk mendapatkan gambaran kasar jumlah pengguna dari lokasi berbeda. Log Anda mungkin memberikan informasi negara atau kota, yang juga dapat Anda gunakan untuk 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 octet IP terakhir untuk mendapatkan respons dari perangkat lain yang memiliki latensi serupa dengan aplikasi Anda.
Informasi latensi dari Google Cloud: Jika Anda sudah memiliki aplikasi di Google Cloud, ada beberapa cara untuk mengumpulkan informasi latensi.
- Header permintaan yang ditentukan pengguna**: Aktifkan header untuk mendapatkan informasi negara, subwilayah, dan kota pelanggan, serta perkiraan RTT antara load balancer dan klien.
- Metrik Cloud Monitoring untuk load balancing HTTP(S): Sertakan latensi RTT frontend dan backend.
- Log Alur VPC: Dapatkan RTT TCP 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 dapat ditemukan.
- Konektivitas: Antara POP dan region.
Temukan daftar lokasi tempat Google saling terhubung dengan ISP lain di PeeringDB.
Pastikan untuk mempertimbangkan topologi antar-region saat menentukan di region mana aplikasi akan di-deploy. Misalnya, jika Anda ingin men-deploy aplikasi dengan basis pengguna global di satu region, sebaiknya hosting aplikasi ini di salah satu region AS, karena AS terhubung ke sebagian besar region lain. Meskipun ada konektivitas langsung antara banyak benua, koneksi bisa hilang, 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 antara region tersebut. Meskipun dapat berubah dari waktu ke waktu, latensi ini biasanya stabil. Ukur sendiri latensi dengan menampilkan instance pengujian di semua region potensial, atau gunakan situs pihak ketiga untuk mengetahui latensi antar-region saat ini.
Merangkum pemahaman
Setelah mempertimbangkan persyaratan latensi, kemungkinan model deployment, dan distribusi geografis basis pengguna, sekarang Anda memahami pengaruh faktor-faktor tersebut terhadap latensi ke region tertentu. Saatnya menentukan region untuk meluncurkan aplikasi Anda.
Meskipun tidak ada cara 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, misalnya harga atau kolokasi. Hilangkan faktor tersebut dari daftar region Anda.
- Pilih model deployment berdasarkan persyaratan latensi dan arsitektur umum aplikasi. Untuk sebagian besar aplikasi seluler dan aplikasi lain yang tidak mementingkan latensi, deployment region tunggal dengan pengiriman konten yang dapat di-cache melalui Cloud CDN dan penghentian SSL di edge mungkin merupakan pilihan yang optimal.
Bergantung pada model deployment Anda, pilih region berdasarkan distribusi geografis basis pengguna dan pengukuran latensi Anda:
Untuk deployment region tunggal:
- Jika Anda membutuhkan akses berlatensi rendah ke lokasi perusahaan, lakukan deployment di region yang paling dekat dengan lokasi tersebut.
- Jika kebanyakan pengguna Anda berasal dari satu negara atau wilayah, deploy di region yang paling dekat dengan pengguna representatif Anda.
- Untuk basis pengguna global, deploy di salah satu region AS.
Untuk deployment multi-region:
- Pilih region yang dekat dengan pengguna Anda berdasarkan distribusi geografis mereka dan persyaratan latensi aplikasi. Bergantung pada aplikasi Anda, lakukan pengoptimalan untuk mencapai median latensi tertentu atau pastikan 95—99% pengguna dilayani dengan latensi target tertentu. Pengguna di lokasi geografis tertentu sering memiliki toleransi latensi yang lebih tinggi karena keterbatasan infrastruktur.
Jika latensi pengguna di beberapa region mirip, harga dapat menjadi faktor penentu.
Saat memilih region Compute Engine, latensi merupakan 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 berikutnya
- Tinjau region dan zona Compute Engine.
- Pelajari cara Mengoptimalkan latensi aplikasi dengan load balancing.
- Baca panduan Google Cloud untuk profesional pusat data.
- Tonton seri video Cloud performance atlas.
- Untuk mengetahui lebih jauh 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.