Pengelolaan kapasitas dengan load balancing

Last reviewed 2018-01-18 UTC

Sebagian besar load balancer menggunakan pendekatan hashing berbasis round-robin atau alur untuk mendistribusikan traffic. Load balancer yang menggunakan pendekatan ini dapat mengalami kesulitan dalam beradaptasi saat permintaan traffic melonjak melebihi kapasitas penyaluran yang tersedia. Tutorial ini menunjukkan cara Cloud Load Balancing mengoptimalkan kapasitas aplikasi global Anda, sehingga menghasilkan pengalaman pengguna yang lebih baik dan biaya yang lebih rendah dibandingkan dengan sebagian besar penerapan load balancing.

Artikel ini adalah bagian dari rangkaian praktik terbaik untuk produk Cloud Load Balancing. Tutorial ini disertai dengan Pengoptimalan kapasitas aplikasi dengan load balancing global, sebuah artikel konseptual yang menjelaskan mekanisme dasar overflow load balancing global secara lebih mendetail. Untuk mempelajari latensi secara lebih mendalam, lihat Mengoptimalkan Latensi Aplikasi dengan Cloud Load Balancing.

Tutorial ini mengasumsikan bahwa Anda memiliki pengalaman menggunakan Compute Engine. Anda juga harus memahami dasar-dasar Load Balancer Aplikasi Eksternal.

Tujuan

Dalam tutorial ini, Anda akan menyiapkan server web sederhana yang menjalankan aplikasi intensif CPU yang menghitung set Mandelbrot. Anda memulai dengan mengukur kapasitas jaringannya menggunakan alat pengujian beban (siege dan httperf). Selanjutnya, Anda akan menskalakan jaringan ke beberapa instance VM dalam satu region dan mengukur waktu respons di bawah beban. Terakhir, Anda akan menskalakan jaringan ke beberapa region menggunakan load balancing global, lalu mengukur waktu respons server dalam load balancing dan membandingkannya dengan load balancing satu region. Dengan menjalankan urutan pengujian ini, Anda dapat melihat efek positif dari pengelolaan beban lintas regional Cloud Load Balancing.

Kecepatan komunikasi jaringan pada arsitektur server tiga tingkat standar biasanya dibatasi oleh kecepatan server aplikasi atau kapasitas database, bukan oleh beban CPU di server web. Setelah menjalankan tutorial, Anda dapat menggunakan alat pengujian beban dan setelan kapasitas yang sama untuk mengoptimalkan perilaku load balancing di aplikasi dunia nyata.

Anda akan:

Pelajari cara menggunakan alat pengujian beban (siege dan httperf).
Menentukan kapasitas penayangan satu instance VM.
Ukur efek kelebihan beban dengan load balancing satu region.
Mengukur efek overflow ke region lain dengan load balancing global.

Biaya

Tutorial ini menggunakan komponen Google Cloud yang dapat ditagih, termasuk:

Compute Engine
Aturan penerusan dan Load Balancing

Gunakan Kalkulator Harga untuk membuat perkiraan biaya berdasarkan penggunaan yang Anda proyeksikan.

Sebelum memulai

Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

Buka pemilih project
Make sure that billing is enabled for your Google Cloud project.
Aktifkan API Compute Engine.
Mengaktifkan API

Menyiapkan lingkungan Anda

Di bagian ini, Anda akan mengonfigurasi setelan project, jaringan VPC, dan aturan firewall dasar yang diperlukan untuk menyelesaikan tutorial.

Memulai instance Cloud Shell

Buka Cloud Shell dari Google Cloud Console. Kecuali jika dinyatakan lain, Anda menjalankan tutorial lainnya dari dalam Cloud Shell.

Konfigurasikan setelan project

Untuk menjalankan perintah gcloud dengan lebih mudah, Anda dapat menetapkan properti sehingga Anda tidak perlu memberikan opsi untuk properti ini dengan setiap perintah.

Tetapkan project default Anda, menggunakan project ID untuk [PROJECT_ID]:
```
gcloud config set project [PROJECT_ID]
```
Tetapkan zona Compute Engine default Anda, menggunakan zona pilihan untuk [ZONE], lalu tetapkan ini sebagai variabel lingkungan untuk digunakan nanti:
```
gcloud config set compute/zone [ZONE]
export ZONE=[ZONE]
```

Membuat dan mengonfigurasi jaringan VPC

Buat jaringan VPC untuk pengujian:

gcloud compute networks create lb-testing --subnet-mode auto

Tentukan aturan firewall untuk mengizinkan traffic internal:

gcloud compute firewall-rules create lb-testing-internal \
    --network lb-testing --allow all --source-ranges 10.128.0.0/11

Tentukan aturan firewall untuk mengizinkan traffic SSH berkomunikasi dengan jaringan VPC:

gcloud compute firewall-rules create lb-testing-ssh \
    --network lb-testing --allow tcp:22 --source-ranges 0.0.0.0/0

Menentukan kapasitas penyaluran instance VM tunggal

Untuk memeriksa karakteristik performa jenis instance VM, Anda perlu melakukan hal berikut:

Siapkan instance VM yang menyalurkan contoh beban kerja (instance server web).
Buat instance VM kedua di zona yang sama (instance pengujian beban).

Dengan instance VM kedua, Anda akan mengukur performa menggunakan alat pengujian beban dan pengukuran performa yang sederhana. Anda akan menggunakan pengukuran ini nanti dalam tutorial untuk membantu menentukan setelan kapasitas load balancing yang benar untuk grup instance.

Instance VM pertama menggunakan skrip Python untuk membuat tugas yang menggunakan CPU secara intensif dengan menghitung dan menampilkan gambar yang ditetapkan Mandelbrot pada setiap permintaan ke jalur root (/). Hasilnya tidak di-cache. Selama tutorial, Anda akan mendapatkan skrip Python dari repositori GitHub yang digunakan untuk solusi ini.

Penyiapan 2 server untuk menguji respons server web

Menyiapkan instance VM

Siapkan instance VM webserver sebagai instance VM 4 core dengan menginstal, lalu memulai server Mandelbrot:

gcloud compute instances create webserver --machine-type n1-highcpu-4 \
    --network=lb-testing --image-family=debian-10 \
    --image-project=debian-cloud --tags=http-server \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
    git clone \
https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
    cd lb-app-capacity-tutorial-python
python webserver.py'

Buat aturan firewall untuk mengizinkan akses eksternal ke instance webserver dari mesin Anda sendiri:
```
gcloud compute firewall-rules create lb-testing-http \
    --network lb-testing --allow tcp:80 --source-ranges 0.0.0.0/0 \
    --target-tags http-server 
```
Catatan: Langkah ini juga akan membuka firewall untuk rentang alamat IP 130.211.0.0/22 dan 35.191.0.0/16 yang digunakan untuk health check.

Dapatkan alamat IP instance webserver:

gcloud compute instances describe webserver \
    --format "value(networkInterfaces[0].accessConfigs[0].natIP)"

Di browser web, buka alamat IP yang ditampilkan oleh perintah sebelumnya. Anda melihat kumpulan Mandelbrot yang dihitung:

Buat instance pengujian beban:

gcloud compute instances create loadtest --machine-type n1-standard-1 \
    --network=lb-testing --image-family=debian-10 \
    --image-project=debian-cloud

Menguji instance VM

Langkah selanjutnya adalah menjalankan permintaan untuk mengukur karakteristik performa instance VM pengujian beban.

Gunakan perintah ssh untuk terhubung ke instance VM pengujian beban:
```
gcloud compute ssh loadtest
```
Catatan: Anda melakukan langkah-langkah yang tersisa dalam prosedur pengujian ini dari command line instance tempat Anda login.
Pada instance pengujian beban, instal siege dan httperf sebagai alat pengujian beban Anda:
```
sudo apt-get install -y siege httperf
```
Alat siege memungkinkan simulasi permintaan dari sejumlah pengguna tertentu, sehingga membuat permintaan lanjutan hanya setelah pengguna menerima respons. Hal ini memberi Anda insight tentang kapasitas dan waktu respons yang diharapkan untuk aplikasi di lingkungan aktual.

Alat httperf memungkinkan untuk mengirim jumlah permintaan tertentu per detik, terlepas dari apakah respons atau error diterima. Hal ini memberi Anda insight tentang cara aplikasi merespons beban tertentu.
Mengatur waktu permintaan sederhana ke server web:
```
curl -w "%{time_total}\n" -o /dev/#objectives_2 -s webserver
```
Anda mendapatkan respons seperti 0,395260. Artinya, server memerlukan waktu 395 milidetik (md) untuk merespons permintaan Anda.

Gunakan perintah berikut untuk menjalankan 20 permintaan dari 4 pengguna secara paralel:

siege -c 4 -r 20 webserver

Anda akan melihat output yang mirip dengan berikut ini:

** SIEGE 4.0.2
** Preparing 4 concurrent users for battle.
The server is now under siege...
Transactions:                    80 hits
Availability:                 100.00 %
Elapsed time:                  14.45 secs
Data transferred:               1.81 MB
Response time:                  0.52 secs
Transaction rate:               5.05 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                    3.92
Successful transactions:         80
Failed transactions:               0
**Longest transaction:            0.70
Shortest transaction:           0.37
**

Outputnya dijelaskan sepenuhnya dalam manual pengepungan, tetapi Anda dapat melihat dalam contoh ini bahwa waktu respons bervariasi antara 0,37 detik dan 0,7 detik. Rata-rata, 5,05 permintaan per detik ditanggapi. Data ini membantu memperkirakan kapasitas penayangan sistem.

Jalankan perintah berikut untuk memvalidasi temuan menggunakan alat pengujian beban httperf:

httperf --server webserver --num-conns 500 --rate 4

Perintah ini menjalankan 500 permintaan dengan kecepatan 4 permintaan per detik, yang kurang dari 5,05 transaksi per detik yang diselesaikan siege.

Anda akan melihat output yang mirip dengan berikut ini:

httperf --client=0/1 --server=webserver --port=80 --uri=/ --rate=4
--send-buffer=4096 --recv-buffer=16384 --num-conns=500 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to
FD_SETSIZE
Maximum connect burst length: 1

Total: connections 500 requests 500 replies 500 test-duration 125.333 s

Connection rate: 4.0 conn/s (251.4 ms/conn, <=2 concurrent connections)
**Connection time [ms]: min 369.6 avg 384.5 max 487.8 median 377.5 stddev 18.0
Connection time [ms]: connect 0.3**
Connection length [replies/conn]: 1.000

Request rate: 4.0 req/s (251.4 ms/req)
Request size [B]: 62.0

Reply rate [replies/s]: min 3.8 avg 4.0 max 4.0 stddev 0.1 (5 samples)
Reply time [ms]: response 383.8 transfer 0.4
Reply size [B]: header 117.0 content 24051.0 footer 0.0 (total 24168.0)
Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0

CPU time [s]: user 4.94 system 20.19 (user 19.6% system 80.3% total 99.9%)
Net I/O: 94.1 KB/s (0.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Output-nya dijelaskan dalam file httperf README. Perhatikan baris yang dimulai dengan Connection time [ms], yang menunjukkan bahwa koneksi memerlukan waktu total antara 369,6 dan 487,8 md, dan tidak menghasilkan error apa pun.

Ulangi pengujian 3 kali, menetapkan opsi rate ke 5, 7, dan 10 permintaan per detik.

Blok berikut menampilkan perintah httperf dan output-nya (hanya menampilkan baris yang relevan dengan informasi waktu koneksi).

Perintah untuk 5 permintaan per detik:

httperf --server webserver --num-conns 500 --rate 5 2>&1| grep 'Errors\|ion time'

Hasil untuk 5 permintaan per detik:

Connection time [ms]: min 371.2 avg 381.1 max 447.7 median 378.5 stddev 7.2
Connection time [ms]: connect 0.2
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Perintah untuk 7 permintaan per detik:

httperf --server webserver --num-conns 500 --rate 7 2>&1| grep 'Errors\|ion time'

Hasil untuk 7 permintaan per detik:

Connection time [ms]: min 373.4 avg 11075.5 max 60100.6 median 8481.5 stddev
10284.2
Connection time [ms]: connect 654.9
Errors: total 4 client-timo 0 socket-timo 0 connrefused 0 connreset 4
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Perintah untuk 10 permintaan per detik:

httperf --server webserver --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'

Hasil untuk 10 permintaan per detik:

Connection time [ms]: min 374.3 avg 18335.6 max 65533.9 median 10052.5 stddev
16654.5
Connection time [ms]: connect 181.3
Errors: total 32 client-timo 0 socket-timo 0 connrefused 0 connreset 32
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Logout dari instance webserver:
```
exit
```

Anda dapat menyimpulkan dari pengukuran ini bahwa sistem memiliki kapasitas sekitar 5 permintaan per detik (RPS). Pada 5 permintaan per detik, instance VM akan bereaksi dengan latensi yang sebanding dengan 4 koneksi. Pada 7 dan 10 koneksi per detik, waktu respons rata-rata akan meningkat secara drastis menjadi lebih dari 10 detik dengan beberapa error koneksi. Dengan kata lain, apa pun yang lebih dari 5 permintaan per detik akan menyebabkan pelambatan yang signifikan.

Pada sistem yang lebih kompleks, kapasitas server ditentukan dengan cara yang sama, tetapi sangat bergantung pada kapasitas semua komponennya. Anda dapat menggunakan alat siege dan httperf bersama dengan pemantauan beban CPU dan I/O semua komponen (misalnya, server frontend, server aplikasi, dan server database) untuk membantu mengidentifikasi bottleneck. Hal ini kemudian dapat membantu Anda mengaktifkan penskalaan yang optimal untuk setiap komponen.

Mengukur efek kelebihan beban dengan load balancer satu region

Di bagian ini, Anda akan mempelajari efek overload pada load balancing satu region, seperti load balancer yang umum digunakan di infrastruktur lokal, atau Load Balancer Jaringan passthrough eksternal Google Cloud. Anda juga dapat mengamati efek ini dengan load balancer HTTP(S) saat load balancing digunakan untuk deployment regional (bukan global).

Konfigurasi load balancer dalam deployment regional zona tunggal

Membuat load balancer HTTP(S) satu region

Langkah-langkah berikut menjelaskan cara membuat load balancer HTTP(S) region tunggal dengan ukuran tetap 3 instance VM.

Buat template instance untuk instance VM server web menggunakan skrip pembuatan Python Mandelbrot yang Anda gunakan sebelumnya. Jalankan perintah berikut di Cloud Shell:

gcloud compute instance-templates create webservers \
    --machine-type n1-highcpu-4 \
    --image-family=debian-10 --image-project=debian-cloud \
    --tags=http-server \
    --network=lb-testing \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
git clone \
    https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
cd lb-app-capacity-tutorial-python
python webserver.py'

Buat grup instance terkelola dengan 3 instance berdasarkan template dari langkah sebelumnya:

gcloud compute instance-groups managed create webserver-region1 \
    --size=3 --template=webservers

Buat health check, layanan backend, peta URL, proxy target, dan aturan penerusan global yang diperlukan untuk membuat load balancing HTTP:

gcloud compute health-checks create http basic-check \
    --request-path="/health-check" --check-interval=60s

gcloud compute backend-services create web-service \
    --health-checks basic-check --global
gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE

gcloud compute url-maps create web-map --default-service web-service

gcloud compute target-http-proxies create web-proxy --url-map web-map

gcloud compute forwarding-rules create web-rule --global \
    --target-http-proxy web-proxy --ports 80

Dapatkan alamat IP aturan penerusan:
```
gcloud compute forwarding-rules describe --global web-rule --format "value(IPAddress)"
```
Output-nya adalah alamat IP publik dari load balancer yang Anda buat.
Di browser, buka alamat IP yang ditampilkan oleh perintah sebelumnya. Setelah beberapa menit, Anda akan melihat gambar Mandelbrot yang sama seperti yang Anda lihat sebelumnya. Namun, kali ini image ditayangkan dari salah satu instance VM dalam grup yang baru dibuat.
Login ke perangkat loadtest:
```
gcloud compute ssh loadtest
```
Pada command line perangkat loadtest, uji respons server dengan jumlah permintaan per detik (RPS) yang berbeda. Pastikan Anda menggunakan nilai RPS setidaknya dalam rentang 5 hingga 20.

Misalnya, perintah berikut menghasilkan 10 RPS. Ganti [IP_address] dengan alamat IP load balancer dari langkah sebelumnya dalam prosedur ini.
```
httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'
```
Latensi respons meningkat secara signifikan seiring jumlah RPS meningkat hingga 12 atau 13 RPS terakhir. Berikut adalah visualisasi hasil yang biasanya:
Logout dari instance VM loadtest:
```
exit
```

Performa ini biasanya digunakan untuk sistem load balancing secara regional. Saat beban meningkatkan kapasitas penayangan di masa lalu, latensi permintaan rata-rata dan maksimum akan meningkat tajam. Dengan 10 RPS, latensi permintaan rata-rata mendekati 500 md, tetapi dengan 20 RPS, latensinya adalah 5.000 md. Latensi telah meningkat sepuluh kali lipat dan pengalaman pengguna menurun dengan cepat, yang menyebabkan pengguna berhenti menggunakan aplikasi atau waktu tunggu aplikasi, atau keduanya.

Di bagian berikutnya, Anda akan menambahkan region kedua ke topologi load balancing dan membandingkan pengaruh failover lintas region terhadap latensi pengguna akhir.

Mengukur efek tambahan ke region lain

Jika Anda menggunakan aplikasi global dengan Load Balancer Aplikasi eksternal dan jika Anda memiliki backend yang di-deploy di beberapa region, saat kelebihan kapasitas terjadi di satu region, traffic akan otomatis mengalir ke region lain. Anda dapat memvalidasi hal ini dengan menambahkan grup instance VM kedua di region lain ke konfigurasi yang Anda buat di bagian sebelumnya.

Konfigurasi load balancer dalam deployment multi-region

Membuat server di beberapa region

Pada langkah berikut, Anda akan menambahkan grup backend lain di region lain dan menetapkan kapasitas 10 RPS per region. Anda kemudian dapat melihat reaksi load balancing saat batas ini terlampaui.

Di Cloud Shell, pilih zona di region yang berbeda dengan zona default Anda dan tetapkan sebagai variabel lingkungan:
```
export ZONE2=[zone]
```

Buat grup instance baru di region kedua dengan 3 instance VM:

gcloud compute instance-groups managed create webserver-region2 \
    --size=3 --template=webservers --zone $ZONE2

Tambahkan grup instance ke layanan backend yang ada dengan kapasitas maksimum 10 RPS:

gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region2 \
    --instance-group-zone $ZONE2 --max-rate 10

Sesuaikan max-rate menjadi 10 RPS untuk layanan backend yang ada:

gcloud compute backend-services update-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE --max-rate 10

Setelah semua instance di-booting, login ke instance VM loadtest:
```
gcloud compute ssh loadtest
```

Jalankan 500 permintaan dengan 10 RPS. Ganti [IP_address] dengan alamat IP load balancer:

httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'ion time'

Anda akan melihat hasil seperti berikut:

Connection time [ms]: min 405.9 avg 584.7 max 1390.4 median 531.5 stddev
181.3
Connection time [ms]: connect 1.1

Hasilnya mirip dengan yang dihasilkan oleh load balancer regional.

Karena alat pengujian Anda langsung menjalankan beban penuh dan tidak secara perlahan meningkatkan beban seperti implementasi di dunia nyata, Anda harus mengulangi pengujian beberapa kali agar mekanisme overflow dapat diterapkan. Jalankan 500 permintaan 5 kali dengan 20 RPS. Ganti [IP_address] dengan alamat IP load balancer.

for a in \`seq 1 5\`; do httperf --server [IP_address] \
    --num-conns 500 --rate 20 2>&1| grep 'ion time' ; done

Anda akan melihat hasil seperti berikut:

Connection time [ms]: min 426.7 avg 6396.8 max 13615.1 median 7351.5 stddev
3226.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 417.2 avg 3782.9 max 7979.5 median 3623.5 stddev
2479.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 411.6 avg 860.0 max 3971.2 median 705.5 stddev 492.9
Connection time [ms]: connect 0.7
Connection time [ms]: min 407.3 avg 700.8 max 1927.8 median 667.5 stddev 232.1
Connection time [ms]: connect 0.7
Connection time [ms]: min 410.8 avg 701.8 max 1612.3 median 669.5 stddev 209.0
Connection time [ms]: connect 0.8

Setelah sistem stabil, waktu respons rata-rata adalah 400 md pada 10 RPS, dan hanya meningkat menjadi 700 md pada 20 RPS. Ini adalah peningkatan besar selama penundaan 5.000 md yang ditawarkan oleh load balancer regional, dan menghasilkan pengalaman pengguna yang jauh lebih baik.

Grafik berikut menunjukkan waktu respons yang diukur oleh RPS menggunakan load balancing global:

Grafik yang menunjukkan waktu respons tetap stabil saat permintaan per menit naik

Membandingkan hasil load balancing regional dan global

Setelah menetapkan kapasitas satu node, Anda dapat membandingkan latensi yang diamati oleh pengguna akhir dalam deployment berbasis region dengan latensi dalam arsitektur load balancing global. Meskipun jumlah permintaan ke satu region lebih rendah dari total kapasitas penyaluran di region tersebut, kedua sistem memiliki latensi pengguna akhir yang serupa, karena pengguna selalu dialihkan ke region terdekat.

Jika beban ke suatu region melebihi kapasitas penyaluran untuk region tersebut, latensi pengguna akhir akan berbeda secara signifikan di antara beberapa solusi:

Solusi load balancing regional menjadi kelebihan beban saat traffic meningkatkan kapasitas sebelumnya, karena traffic tidak dapat mengalir ke mana pun kecuali ke instance VM backend yang kelebihan beban. Ini mencakup load balancer lokal tradisional, Load Balancer Jaringan passthrough eksternal di Google Cloud, dan Load Balancer Aplikasi eksternal dalam konfigurasi region tunggal (misalnya, menggunakan jaringan Standard Tier). Latensi permintaan rata-rata dan maksimum meningkat lebih dari faktor 10, yang menyebabkan pengalaman pengguna yang buruk yang pada akhirnya dapat menyebabkan pengguna berhenti menggunakan aplikasi secara signifikan.
Load Balancer Aplikasi eksternal global dengan backend di beberapa region memungkinkan traffic untuk diteruskan ke region terdekat yang memiliki kapasitas penayangan. Hal ini menghasilkan peningkatan latensi pengguna akhir yang terukur, tetapi relatif rendah, dan memberikan pengalaman pengguna yang jauh lebih baik. Jika aplikasi Anda tidak dapat melakukan penyebaran skala di suatu region dengan cukup cepat, Load Balancer Aplikasi eksternal global adalah opsi yang direkomendasikan. Bahkan selama kegagalan region penuh server aplikasi pengguna, traffic akan dialihkan dengan cepat ke region lain, dan membantu menghindari pemadaman layanan secara penuh.

Pembersihan

Menghapus project

Cara termudah untuk menghilangkan penagihan adalah dengan menghapus project yang Anda buat untuk tutorial.

Untuk menghapus project:

Perhatian: Menghapus project memiliki efek berikut:

Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.

Jika Anda berencana mempelajari berbagai arsitektur, tutorial, atau panduan memulai, menggunakan kembali project dapat membantu agar Anda tidak melampaui batas kuota project.

Di konsol Google Cloud, buka halaman Manage resource.
Buka Manage resource
Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Langkah selanjutnya

Halaman berikut memberikan informasi dan latar belakang lebih lanjut tentang opsi load balancing Google: