Load balancing meningkatkan kinerja sistem, terutama dari sudut pandang aplikasi, memungkinkan beberapa komputer untuk menyajikan data yang sama. Ini bekerja sedemikian rupa sehingga beban didistribusikan di antara permintaan klien ke node replika selain dari node utama atau masternya, sementara merutekan modifikasi basis data hanya ke node master saja. Setiap modifikasi pada master node selanjutnya disebarkan ke setiap replika menggunakan PostgreSQL Streaming Replication.
Bagaimana Load Balancer Dapat Mempengaruhi PostgreSQL?
Menggunakan load balancing akan mengarahkan aplikasi klien untuk terhubung ke server load balancing, dan mendistribusikan koneksi yang dimulai ke node PostgreSQL yang tersedia tergantung pada jenis permintaan kueri. Ini membantu menekankan beban luar biasa pada server PostgreSQL tertentu dan mempromosikan keseimbangan beban paralel di antara node yang tersedia dalam cluster.
Menggunakan PostgreSQL, sudah ada beberapa solusi yang ada untuk membuatnya bekerja. Solusi ini dapat bekerja dengan mulus atau load balancing dapat bekerja dengan topologi saat ini--dengan node primer dan standby--namun load balancing diimplementasikan di lapisan aplikasi itu sendiri. Penyeimbangan beban menghadapi tantangan dengan masalah sinkronisasi yang merupakan kesulitan mendasar bagi server yang bekerja bersama. Karena tidak ada solusi tunggal yang menghilangkan dampak masalah sinkronisasi untuk semua kasus penggunaan, ada beberapa solusi. Setiap solusi mengatasi masalah ini dengan cara yang berbeda, dan meminimalkan dampaknya untuk beban kerja tertentu.
Di blog ini, kita akan melihat load balancer tersebut dengan membandingkannya dan seberapa bermanfaatnya untuk beban kerja PostgreSQL Anda.
HAProxy Load Balancing Untuk PostgreSQL
HAProxy adalah mesin non-pemblokiran yang digerakkan oleh peristiwa yang menggabungkan proxy dengan lapisan I/O yang sangat cepat dan penjadwal multi-utas berbasis prioritas. Karena dirancang dengan tujuan penerusan data, arsitekturnya dirancang untuk beroperasi dalam proses ringan yang dioptimalkan untuk memindahkan data secepat mungkin dengan operasi seminimal mungkin. Ini berfokus pada pengoptimalan efisiensi cache CPU dengan menempelkan koneksi ke CPU yang sama selama mungkin. Dengan demikian, ia menerapkan model berlapis yang menawarkan mekanisme bypass di setiap tingkat memastikan data tidak mencapai tingkat yang lebih tinggi kecuali diperlukan. Sebagian besar pemrosesan dilakukan di kernel. HAProxy melakukan yang terbaik untuk membantu kernel melakukan pekerjaan secepat mungkin dengan memberikan beberapa petunjuk atau dengan menghindari operasi tertentu ketika diperkirakan mereka dapat dikelompokkan nanti. Akibatnya, angka tipikal menunjukkan 15% dari waktu pemrosesan yang dihabiskan di HAProxy versus 85% di kernel dalam mode tutup TCP atau HTTP, dan sekitar 30% untuk HAProxy versus 70% untuk kernel dalam mode HTTP keep-alive.
HAProxy juga memiliki fitur tambahan penyeimbangan beban. Misalnya, fitur proxy TCP memungkinkan kita menggunakannya untuk koneksi database terutama untuk PostgreSQL menggunakan dukungan layanan pemeriksaan bawaannya. Meskipun ada dukungan layanan database, itu tidak mencukupi pemeriksaan kesehatan yang diinginkan terutama untuk tipe cluster replikasi. Pendekatan standar saat menerapkannya untuk produksi adalah dengan menggunakan pemeriksaan TCP, kemudian bergantung pada xinetd dengan HAProxy.
Kelebihan Menggunakan HAProxy untuk PostgreSQL
Hal terbaik dengan HAProxy adalah ringan, mudah dikonfigurasi dan digunakan, dan berfungsi seperti yang diharapkan. Menggunakan HAProxy di atas cluster PostgreSQL telah diterapkan dan disebarkan beberapa kali dari organisasi besar ke berbagai UKM/UKM untuk penggunaan produksi mereka. Telah lama terbukti untuk produksi dan kapasitas beban kerja yang tinggi tidak hanya untuk database tetapi bahkan dengan layanan jaringan lain seperti aplikasi web atau untuk penyeimbangan beban geografis (mendistribusikan lalu lintas ke beberapa pusat data). Memiliki HAProxy di atas PostgreSQL, memungkinkan pengguna kemampuan untuk membatasi atau membatasi respons untuk memparalelkan dan mendistribusikan beban dengan benar ke semua node yang tersedia di cluster. Mekanisme bawaan dengan HAProxy juga memungkinkan pengguna untuk mengatur ketersediaan tinggi dengan mulus dan lebih mudah untuk menskalakan jika beban diperlukan dan menghindari satu titik kegagalan (SPOF).
Kontra Penggunaan HAProxy untuk PostgreSQL
HAProxy tidak menyediakan pemfilteran kueri atau analisis kueri untuk mengidentifikasi jenis pernyataan yang diminta. Tidak memiliki kemampuan untuk melakukan split baca/tulis pada satu port. Menyetel penyeimbang beban di atas HAProxy mengharuskan Anda setidaknya menyiapkan port yang berbeda untuk penulisan dan yang berbeda untuk pembacaan Anda. Ini membutuhkan perubahan aplikasi agar sesuai dengan kebutuhan Anda.
HAProxy juga melakukan dukungan fitur yang sangat sederhana dengan PostgreSQL untuk pemeriksaan kesehatan, namun ini hanya menentukan apakah node aktif atau tidak, seolah-olah hanya melakukan ping ke node dan menunggu respons pantulan. Itu tidak mengidentifikasi peran apa yang dicoba oleh node untuk meneruskan koneksi yang diminta dari klien ke node yang diinginkan. Oleh karena itu, tidak mengerti atau tidak ada fitur di HAProxy untuk memahami topologi replikasi. Meskipun, pengguna dapat membuat pendengar terpisah berdasarkan port yang berbeda tetapi masih menambahkan perubahan dalam aplikasi untuk memenuhi kebutuhan penyeimbangan beban. Artinya, menggunakan skrip eksternal dengan xinetd dapat menjadi solusi untuk memenuhi persyaratan. Namun, skrip ini tidak terintegrasi dengan HAProxy dan rentan terhadap kesalahan manusia.
Jika satu node atau sekelompok node harus ditempatkan dalam mode pemeliharaan, maka Anda juga akan diminta untuk menerapkan perubahan pada HAProxy Anda, jika tidak, hal itu dapat menjadi bencana besar.
Pgpool-II Untuk Load Balancing PostgreSQL Anda
Pgpool-II adalah perangkat lunak sumber terbuka dan digunakan oleh komunitas PostgreSQL besar-besaran untuk menerapkan penyeimbangan beban dan menggunakannya untuk bertindak sebagai middleware mereka dari aplikasi hingga ke lapisan proxy, lalu mendistribusikan beban setelah sepenuhnya menganalisis jenis permintaan per kueri atau koneksi database. Pgpool-II telah ada begitu lama sejak tahun 2003 yang awalnya bernama Pgpool hingga menjadi Pgpool-II pada tahun 2006, yang berfungsi sebagai bukti alat proxy yang sangat stabil tidak hanya untuk penyeimbangan beban tetapi juga banyak fitur keren .
Pgpool-II dikenal sebagai pisau tentara swiss untuk PostgreSQL dan merupakan perangkat lunak proxy yang berada di antara server PostgreSQL dan klien database PostgreSQL. Ide dasar dari PgPool-II adalah bahwa ia berada di klien, kemudian kueri baca harus dikirimkan ke node siaga, sementara penulisan atau modifikasi langsung ke primer. Ini adalah solusi penyeimbangan beban yang sangat cerdas yang tidak hanya menyeimbangkan beban, tetapi juga mendukung ketersediaan tinggi dan menyediakan penyatuan koneksi. Mekanisme cerdas memungkinkan untuk menyeimbangkan beban antara master dan slave. Jadi, penulisan dimuat ke master, sementara pemrosesan pembacaan diarahkan ke server hanya-baca yang tersedia, yang merupakan node siaga panas Anda. Pgpool-II juga menyediakan replikasi logis. Meskipun penggunaan dan pentingnya telah menurun karena opsi replikasi bawaan ditingkatkan di sisi server PostgreSQL, ini masih tetap menjadi opsi yang berharga untuk versi PostgreSQL yang lebih lama. Di atas semua ini, ini juga menyediakan penyatuan koneksi.
Pgpool-II memiliki arsitektur yang lebih terlibat daripada PgBouncer untuk mendukung semua fitur yang dimilikinya. Karena keduanya mendukung penyatuan koneksi, yang terakhir tidak memiliki fitur penyeimbang beban.
Pgpool-II dapat mengelola beberapa server PostgreSQL. Menggunakan fungsi replikasi memungkinkan pembuatan cadangan waktu nyata pada 2 atau lebih disk fisik, sehingga layanan dapat berlanjut tanpa menghentikan server jika terjadi kegagalan disk. Karena Pgpool-II juga merupakan kemampuan penyatuan koneksi, Pgpool-II dapat memberikan batasan pada koneksi yang melebihi. Ada batasan jumlah maksimum koneksi bersamaan dengan PostgreSQL, dan koneksi ditolak setelah banyak koneksi ini. Menyetel jumlah maksimum koneksi, bagaimanapun, meningkatkan konsumsi sumber daya dan mempengaruhi kinerja sistem. pgpool-II juga memiliki batas jumlah koneksi maksimum, tetapi koneksi tambahan akan diantrekan alih-alih segera mengembalikan kesalahan.
Dalam load balancing, Jika database direplikasi, mengeksekusi kueri SELECT di server mana pun akan mengembalikan hasil yang sama. pgpool-II memanfaatkan fitur replikasi untuk mengurangi beban pada setiap server PostgreSQL dengan mendistribusikan kueri SELECT di antara beberapa server, meningkatkan throughput sistem secara keseluruhan. Paling-paling, kinerja meningkat secara proporsional dengan jumlah server PostgreSQL. Keseimbangan beban bekerja paling baik dalam situasi di mana ada banyak pengguna yang menjalankan banyak kueri secara bersamaan.
Dengan menggunakan fungsi kueri paralel, data dapat dibagi di antara beberapa server, sehingga kueri dapat dieksekusi di semua server secara bersamaan untuk mengurangi waktu eksekusi secara keseluruhan. Kueri paralel berfungsi paling baik saat menelusuri data berskala besar.
Kelebihan Menggunakan Pgpool untuk PostgreSQL
Ini adalah jenis perangkat lunak yang kaya fitur tidak hanya untuk penyeimbangan beban. Fitur inti dan dukungan alat ini sangat sesuai permintaan yang menyediakan penyatuan koneksi, go PgBouncer alternatif, replikasi asli, pemulihan online, cache kueri dalam memori, failover otomatis, dan ketersediaan tinggi dengan sub prosesnya menggunakan pengawas. Alat ini sudah sangat tua dan terus didukung secara besar-besaran oleh komunitas PostgreSQL, sehingga menangani masalah tidak sulit untuk mencari bantuan. Dokumentasi adalah teman Anda di sini ketika mencari pertanyaan tetapi mencari bantuan di komunitas tidak sulit, dan faktanya alat ini adalah sumber terbuka sehingga Anda dapat menggunakannya dengan bebas selama Anda mematuhi lisensi BSD.
Pgpool-II juga memiliki pengurai SQL. Ini berarti mampu menguraikan SQL secara akurat, dan menulis ulang kueri. Hal ini memungkinkan Pgpool-II untuk meningkatkan paralelisme tergantung pada permintaan kueri.
Kontra Menggunakan Pgpool untuk PostgreSQL
Pgpool-II tidak menawarkan STONITH (tembak node lain di kepala) yang menyediakan mekanisme pagar node. Jika server PostgreSQL gagal, server akan mempertahankan ketersediaan layanan. Pgpool-II juga bisa menjadi titik kegagalan tunggal (SPOF). Setelah node turun, maka konektivitas dan ketersediaan database Anda berhenti dari titik itu. Meskipun ini dapat diperbaiki dengan memiliki redundansi dengan Pgpool-II dan harus menggunakan pengawas untuk mengoordinasikan beberapa node Pgpool-II, itu menambah pekerjaan ekstra.
Untuk connection pooling, sayangnya, bagi mereka yang hanya berfokus pada connection pooling, apa yang Pgpool-II tidak lakukan dengan baik adalah connection pooling, terutama untuk sejumlah kecil klien. Karena setiap proses anak memiliki kumpulannya sendiri, dan tidak ada cara untuk mengontrol klien mana yang terhubung ke proses anak mana, terlalu banyak yang tersisa untuk keberuntungan ketika harus menggunakan kembali koneksi.
Menggunakan Driver JDBC Untuk Menyeimbangkan Beban PostgreSQL Anda
Java Database Connectivity (JDBC) adalah antarmuka pemrograman aplikasi (API) untuk bahasa pemrograman Java, yang mendefinisikan bagaimana klien dapat mengakses database. Ini adalah bagian dari platform Java Standard Edition dan menyediakan metode untuk query dan memperbarui data dalam database, dan berorientasi pada database relasional.
PostgreSQL JDBC Driver (disingkat PgJDBC) memungkinkan program Java untuk terhubung ke database PostgreSQL menggunakan kode Java standar dan independen dari database. Adalah driver JDBC open source yang ditulis dalam Java Murni (Tipe 4), dan berkomunikasi dalam protokol jaringan asli PostgreSQL. Karena itu, driver tidak bergantung pada platform; setelah dikompilasi, driver dapat digunakan di sistem apa pun.
Ini tidak sebanding dengan solusi load balancing yang telah kami tunjukkan sebelumnya. Oleh karena itu, alat ini adalah API antarmuka pemrograman aplikasi Anda yang memungkinkan Anda untuk terhubung dari aplikasi Anda untuk jenis bahasa pemrograman apa pun yang ditulis yang mendukung JDBC atau setidaknya memiliki adaptor untuk terhubung dengan JDBC. Di sisi lain, itu lebih menguntungkan dengan aplikasi Java.
Penyeimbangan beban dengan JDBC cukup naif namun dapat melakukan pekerjaan itu. Dilengkapi dengan parameter koneksi yang dapat memicu mekanisme penyeimbangan beban yang ditawarkan alat ini,
- targetServerType - memungkinkan pembukaan koneksi hanya ke server dengan status/peran yang diperlukan sesuai dengan faktor penentu untuk server PostgreSQL. Nilai yang diperbolehkan adalah any, primary, master (deprecated), slave (deprecated), secondary, preferSlave, dan preferSecondary. Status atau peran ditentukan dengan mengamati apakah server mengizinkan penulisan atau tidak.
- hostRecheckSeconds - mengontrol berapa lama dalam hitungan detik pengetahuan tentang status host di-cache di cache global luas JVM. Nilai defaultnya adalah 10 detik.
- loadBalanceHosts – memungkinkan Anda untuk mengonfigurasi apakah host pertama selalu dicoba (bila disetel ke false) atau jika koneksi dipilih secara acak (bila disetel ke true)
Jadi gunakan loadBalanceHosts yang menerima nilai boolean. loadBalanceHosts dinonaktifkan selama mode defaultnya dan host terhubung dalam urutan tertentu. Jika host yang diaktifkan dipilih secara acak dari kumpulan kandidat yang sesuai. Sintaks dasar saat menghubungkan ke database menggunakan jdbc adalah sebagai berikut,
- jdbc:postgresql:database
- jdbc:postgresql:/
- jdbc:postgresql://host/database
- jdbc:postgresql://host/
- jdbc:postgresql://host:port/database
- jdbc:postgresql://host:port/
Mengingat bahwa loadBalanceHosts dan koneksi menerima beberapa host yang dikonfigurasi seperti di bawah ini,
jdbc:postgresql://host1:port1,host2:port2,host3:port3/databaseIni memungkinkan JDBC untuk memilih secara acak dari sekumpulan kandidat yang cocok.
Pro Menggunakan PgJDBC untuk PostgreSQL
Tidak perlu middleware atau proxy sebagai penyeimbang beban. Proses ini menambahkan lebih banyak peningkatan kinerja dari frontend aplikasi karena tidak ada lapisan tambahan untuk setiap permintaan yang dilewati. Jika Anda memiliki aplikasi yang siap dan ditulis untuk mendukung antarmuka ke JDBC, ini dapat menguntungkan dan jika Anda tidak memerlukan lebih banyak middleware terutama jika anggaran Anda terbatas dan ingin membatasi hanya proses yang didedikasikan untuk tujuan dan fungsinya saja. Tidak seperti dalam aplikasi dengan lalu lintas tinggi dan permintaan besar, ini mungkin memerlukan server proxy yang bertindak sebagai penyeimbang beban Anda dan mungkin memerlukan sumber daya tambahan untuk menangani permintaan koneksi yang tinggi dengan benar, yang juga membutuhkan pemrosesan CPU dan memori.
Kontra Menggunakan PgJDBC untuk PostgreSQL
Anda harus mengatur kode Anda untuk setiap koneksi yang akan diminta. Ini adalah antarmuka pemrograman aplikasi yang berarti, ada pekerjaan di belakang untuk ditangani terutama jika aplikasi Anda sangat menuntut pada setiap permintaan untuk dikirim ke server yang tepat. Tidak ada ketersediaan tinggi, skalabilitas otomatis, dan memiliki satu titik kegagalan.
Bagaimana Dengan Pembungkus atau Alat yang Diimplementasikan Dengan libpq Untuk Menyeimbangkan Beban PostgreSQL Anda?
libpq adalah antarmuka programmer aplikasi C ke PostgreSQL. libpq adalah sekumpulan fungsi library yang memungkinkan program klien meneruskan kueri ke server backend PostgreSQL dan menerima hasil kueri ini.
libpq juga merupakan mesin dasar untuk beberapa antarmuka aplikasi PostgreSQL lainnya, termasuk yang ditulis untuk C++, PHP, Perl, Python, Tcl, Swift, dan ECPG. Jadi beberapa aspek perilaku libpq akan penting bagi Anda jika Anda menggunakan salah satu paket tersebut.
libpq tidak mengotomatiskan penyeimbangan beban dan tidak dianggap sebagai alat untuk solusi penyeimbangan beban. Namun, ia mampu terhubung ke server berikutnya yang tersedia jika server sebelumnya yang terdaftar untuk koneksi gagal. Misalnya, jika Anda memiliki dua node siaga panas yang tersedia, jika node pertama terlalu sibuk dan gagal merespons nilai batas waktu yang sesuai, maka node tersebut akan terhubung ke node berikutnya yang tersedia dalam koneksi yang diberikan. Itu bergantung pada jenis atribut sesi apa yang Anda tentukan. Ini bergantung pada parameter target_session_attrs.
Parameter target_session_attrs menerima nilai baca-tulis, dan apa pun yang merupakan nilai default jika tidak ditentukan. Apa yang dimaksud dengan parameter target_session_attrs adalah, jika disetel ke baca-tulis, hanya koneksi di mana transaksi baca-tulis diterima selama koneksi. Kueri SHOW transaction_read_only akan dikirim setelah koneksi berhasil. Jika hasilnya aktif, maka koneksi akan ditutup, artinya node diidentifikasi sebagai replika atau tidak memproses penulisan. Jika beberapa host ditentukan dalam string koneksi, server yang tersisa akan dicoba sama seperti jika upaya koneksi gagal. Nilai default parameter ini, any, yang berarti semua koneksi dapat diterima. Meskipun mengandalkan target_session_attrs tidak cukup untuk penyeimbangan beban, Anda mungkin dapat mensimulasikan mode round-robin. Lihat contoh kode C saya di bawah ini menggunakan libpq,
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <libpq-fe.h>
const char* _getRoundRobinConn() {
char* h[2];
h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";
h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";
time_t t;
//srand((unsigned)time(&t));
sleep(1.85);
srand((unsigned)time(NULL));
return h[rand() % 2];
}
void
_connect()
{
PGconn *conn;
PGresult *res;
char strConn[120];
snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());
//printf("\nstrConn value is: %s\n", strConn);
conn = PQconnectdb(strConn);
res = PQexec(conn, "SELECT current_database(), inet_client_addr();");
if ( PQresultStatus(res)==PGRES_TUPLES_OK )
{
printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),
PQhost(conn));
} else {
printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));
}
PQclear(res);
PQfinish(conn);
}
int main(void)
{
int i;
for (i=0 ; i<5 ; i++)
_connect();
return 0;
}Hasilnya mengungkapkan,
[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn
current_database = node40 on 192.168.30.40
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50Perhatikan bahwa, jika node .40 (node utama) turun, itu akan selalu mengarahkan koneksi ke .50 selama nilai target_session_attrs Anda adalah apa pun.
Dalam hal ini, Anda cukup membuat sendiri secara bebas dengan bantuan libpq. Meskipun proses mengandalkan libpq dan/atau pembungkusnya terlalu mentah untuk dikatakan bahwa ini dapat memberikan mekanisme penyeimbangan beban yang diinginkan dengan pemerataan ke node yang Anda miliki. Jelas, pendekatan dan pengkodean ini dapat ditingkatkan tetapi pemikirannya adalah bahwa ini gratis dan open source, dan Anda dapat membuat kode tanpa bergantung pada middlewares dan secara bebas merancang cara kerja penyeimbangan beban Anda.
Kelebihan Menggunakan libpq untuk PostgresQL
libpq library adalah antarmuka aplikasi programmer yang dibangun dalam bahasa pemrograman C. Namun, perpustakaan telah diimplementasikan dalam berbagai bahasa sebagai pembungkus sehingga programmer dapat berkomunikasi dengan database PostgreSQL menggunakan bahasa favorit mereka. Anda dapat langsung membuat aplikasi Anda sendiri menggunakan bahasa favorit Anda dan kemudian membuat daftar server yang Anda inginkan, kueri akan dikirim tetapi hanya setelah yang lain, jika kegagalan atau batas waktu mengirim beban Anda ke node yang tersedia yang ingin Anda distribusikan bebannya. Ini tersedia dalam bahasa seperti Python, Perl, PHP, Ruby, Tcl, atau Rust.
Kontra Menggunakan libpq untuk PostgresQL
Implementasi bijaksana untuk paralelisme beban tidak sempurna dan Anda harus menulis mekanisme penyeimbangan beban Anda sendiri dengan kode. Tidak ada konfigurasi yang dapat Anda gunakan atau sesuaikan karena hanya ada antarmuka pemrograman ke database PostgreSQL dengan bantuan parameter target_session_attrs. Artinya, saat membuat koneksi database, Anda harus memiliki serangkaian koneksi baca yang menuju ke node replika/siaga Anda, lalu menulis kueri yang menuju ke penulis atau node utama dalam kode Anda, baik itu di aplikasi Anda atau Anda harus membuat API Anda sendiri untuk mengelola solusi penyeimbangan beban.
Menggunakan pendekatan ini jelas tidak memerlukan atau mengandalkan middleware dari perspektif aplikasi front-end ke database sebagai backend. Tentu saja itu ringan tetapi ketika mengirim daftar server setelah koneksi, itu tidak berarti bahwa beban dipahami dan dikirim secara merata kecuali Anda harus menambahkan kode Anda untuk pendekatan ini. Ini hanya menambah kerumitan, namun, sudah ada solusi yang ada, jadi mengapa perlu menemukan kembali roda?
Kesimpulan
Menerapkan penyeimbang beban Anda dengan PostgreSQL dapat menuntut tetapi tergantung pada jenis aplikasi dan biaya yang Anda hadapi. Terkadang, untuk permintaan beban tinggi, diperlukan middleware yang bertindak sebagai proxy untuk mendistribusikan beban dengan benar dan juga mengawasi status atau kesehatan simpulnya. Di sisi lain, itu mungkin menuntut sumber daya server baik itu harus dijalankan di server khusus atau menuntut CPU dan memori ekstra untuk memenuhi kebutuhan dan ini menambah biaya. Oleh karena itu, ada juga cara sederhana namun memakan waktu tetapi menawarkan distribusi beban ke server yang tersedia yang sudah Anda miliki. Namun itu membutuhkan keterampilan pemrograman dan pemahaman tentang fungsionalitas API.
