Pengelolaan kapasitas menggunakan load balancing

Last reviewed 2018-01-18 UTC

Sebagian besar load balancer menggunakan pendekatan hashing round-robin atau berbasis alur untuk mendistribusikan traffic. Load balancer yang menggunakan pendekatan ini dapat mengalami kesulitan untuk beradaptasi saat lonjakan permintaan traffic melebihi kapasitas penayangan yang tersedia. Tutorial ini menunjukkan cara Load Balancing Cloud 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 artikel konseptual Pengoptimalan kapasitas aplikasi menggunakan load balancing global yang menjelaskan mekanisme yang mendasari overflow load balancing global secara lebih mendetail. Untuk mengetahui informasi selengkapnya tentang latensi, 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). Kemudian, Anda menskalakan jaringan ke beberapa instance VM dalam satu region dan mengukur waktu respons saat beban. Terakhir, Anda menskalakan jaringan ke beberapa region menggunakan load balancing global, lalu mengukur waktu respons server saat beban dan membandingkannya dengan load balancing satu region. Dengan melakukan urutan pengujian ini, Anda dapat melihat efek positif dari pengelolaan beban lintas regional Cloud Load Balancing.

Kecepatan komunikasi jaringan dari arsitektur server tiga tingkat biasa 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).
  • Tentukan kapasitas penayangan satu instance VM.
  • Mengukur efek kelebihan beban dengan load balancing region tunggal.
  • 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 perkirakan.

Sebelum memulai

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. Enable the Compute Engine API.

    Enable the 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 konsol Google Cloud. Kecuali jika dinyatakan lain, Anda dapat menjalankan tutorial selanjutnya dari dalam Cloud Shell.

Konfigurasikan setelan project

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

  1. Tetapkan project default Anda, menggunakan project ID untuk [PROJECT_ID]:

    gcloud config set project [PROJECT_ID]

  2. Tetapkan zona Compute Engine default Anda, menggunakan zona pilihan Anda 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

  1. Buat jaringan VPC untuk pengujian:

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

  2. 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

  3. 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 penayangan satu instance VM

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

  1. Siapkan instance VM yang menayangkan contoh beban kerja (instance server web).

  2. Buat instance VM kedua di zona yang sama (instance pengujian beban).

Dengan instance VM kedua, Anda akan mengukur performa menggunakan alat pengukuran performa dan pengujian beban 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 intensif CPU dengan menghitung dan menampilkan gambar set Mandelbrot pada setiap permintaan ke jalur root (/). Hasil 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

  1. 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-12 \
    --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'

  2. Buat aturan firewall untuk mengizinkan akses eksternal ke instance webserver dari komputer 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

  3. Dapatkan alamat IP instance webserver:

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

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

    Screenshot browser yang menampilkan himpunan Mandelbrot yang dirender

  5. Buat instance pengujian beban:

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

Menguji instance VM

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

  1. Gunakan perintah ssh untuk terhubung ke instance VM pengujian beban:

    gcloud compute ssh loadtest

  2. 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, yang membuat permintaan lanjutan hanya setelah pengguna menerima respons. Hal ini memberi Anda insight tentang kapasitas dan waktu respons yang diharapkan untuk aplikasi di lingkungan dunia nyata.

    Alat httperf memungkinkan pengiriman sejumlah permintaan per detik, terlepas dari apakah respons atau error diterima. Hal ini memberi Anda insight tentang cara aplikasi merespons beban tertentu.

  3. Ukur waktu permintaan sederhana ke server web:

    curl -w "%{time_total}\n" -o /dev/#objectives_2 -s webserver

    Anda akan mendapatkan respons seperti 0,395260. Artinya, server memerlukan waktu 395 milidetik (md) untuk merespons permintaan Anda.

  4. 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
**

    Output dijelaskan sepenuhnya dalam manual siege, 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 direspons. Data ini membantu memperkirakan kapasitas penayangan sistem.

  5. 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 dijelaskan dalam file README httperf. 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.

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

    Blok berikut menunjukkan 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

  7. Keluar dari instance webserver:

    exit

Anda dapat menyimpulkan dari pengukuran ini bahwa sistem memiliki kapasitas sekitar 5 permintaan per detik (RPS). Dengan 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 meningkat drastis menjadi lebih dari 10 detik dengan beberapa error koneksi. Dengan kata lain, apa pun yang melebihi 5 permintaan per detik akan menyebabkan perlambatan yang signifikan.

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

Mengukur efek overload dengan load balancer satu region

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

Konfigurasi load balancer dalam deployment regional satu zona

Membuat load balancer HTTP(S) satu region

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

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

    gcloud compute instance-templates create webservers \
    --machine-type n1-highcpu-4 \
    --image-family=debian-12 --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'

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

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

  3. 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

  4. Dapatkan alamat IP aturan penerusan:

    gcloud compute forwarding-rules describe --global web-rule --format "value(IPAddress)"

    Outputnya adalah alamat IP publik load balancer yang Anda buat.

  5. Di browser, buka alamat IP yang ditampilkan oleh perintah sebelumnya. Setelah beberapa menit, Anda akan melihat gambar Mandelbrot yang sama dengan yang Anda lihat sebelumnya. Namun, kali ini image ditayangkan dari salah satu instance VM dalam grup yang baru dibuat.

  6. Login ke komputer loadtest:

    gcloud compute ssh loadtest

  7. Di command line mesin 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 meningkatnya jumlah RPS setelah 12 atau 13 RPS. Berikut adalah visualisasi hasil standar:

    Grafik yang menunjukkan waktu respons meningkat tajam seiring meningkatnya permintaan per menit

  8. Logout dari instance VM loadtest:

    exit

Performa ini merupakan hal yang wajar untuk sistem yang di-load balance secara regional. Seiring meningkatnya beban di luar kapasitas penayangan, latensi permintaan rata-rata dan maksimum 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 penurunan pengguna atau waktu tunggu aplikasi habis, 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 overflow 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 memvalidasinya 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-langkah berikut, Anda akan menambahkan grup backend lain di region lain dan menetapkan kapasitas 10 RPS per region. Kemudian, Anda dapat melihat reaksi load balancing saat batas ini terlampaui.

  1. Di Cloud Shell, pilih zona di region yang berbeda dengan zona default Anda dan tetapkan sebagai variabel lingkungan:

    export ZONE2=[zone]

  2. 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

  3. 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

  4. Sesuaikan max-rate ke 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

  5. Setelah semua instance melakukan booting, login ke instance VM loadtest:

    gcloud compute ssh loadtest

  6. 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.

  7. Karena alat pengujian Anda langsung menjalankan beban penuh dan tidak meningkatkan beban secara perlahan seperti implementasi di dunia nyata, Anda harus mengulangi pengujian beberapa kali agar mekanisme overflow dapat berlaku. 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 yang sangat besar dibandingkan dengan latensi 5.000 ms yang ditawarkan oleh load balancer regional, dan menghasilkan pengalaman pengguna yang jauh lebih baik.

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

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

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 penayangan di region tersebut, kedua sistem memiliki latensi pengguna akhir yang serupa, karena pengguna selalu dialihkan ke region terdekat.

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

  • Solusi load balancing regional menjadi kelebihan beban saat traffic meningkat melebihi kapasitas, karena traffic tidak dapat mengalir ke mana pun kecuali ke instance VM backend yang kelebihan beban. Hal ini mencakup load balancer lokal tradisional, Load Balancer Jaringan passthrough eksternal di Google Cloud, dan Load Balancer Aplikasi eksternal dalam satu konfigurasi region (misalnya, menggunakan jaringan Paket Standar). Latensi permintaan rata-rata dan maksimum meningkat lebih dari faktor 10, sehingga menyebabkan pengalaman pengguna yang buruk yang pada akhirnya dapat menyebabkan penurunan pengguna yang signifikan.

  • Application Load Balancer eksternal global dengan backend di beberapa region memungkinkan traffic meluap ke region terdekat yang memiliki kapasitas penayangan yang tersedia. Hal ini menyebabkan peningkatan latensi pengguna akhir yang terukur, tetapi relatif rendah, dan memberikan pengalaman pengguna yang jauh lebih baik. Jika aplikasi Anda tidak dapat diskalakan di region dengan cukup cepat, Load Balancer Aplikasi eksternal global adalah opsi yang direkomendasikan. Bahkan selama kegagalan server aplikasi pengguna di seluruh region, traffic akan segera dialihkan 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:

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Langkah selanjutnya

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