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

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

    Buka pemilih project

  2. Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.

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

  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 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 penyaluran instance VM tunggal

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

  1. Siapkan instance VM yang menyalurkan 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 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

  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-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' 
  2. 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 
  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 melihat kumpulan Mandelbrot yang dihitung:

    Screenshot browser yang menampilkan kumpulan Mandelbrot yang dirender

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

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

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

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

    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.

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

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

  1. 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'
  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)"

    Output-nya adalah alamat IP publik dari 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 seperti yang Anda lihat sebelumnya. Namun, kali ini image ditayangkan dari salah satu instance VM dalam grup yang baru dibuat.

  6. Login ke perangkat loadtest:

    gcloud compute ssh loadtest
  7. 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:

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

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

  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 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
    
  5. Setelah semua instance di-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 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:

  1. Di konsol Google Cloud, buka halaman Manage resource.

    Buka Manage resource

  2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
  3. 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: