Kumpulan koneksi

Topik ini menjelaskan cara kerja kumpulan koneksi di Bigtable , dampak ukuran kumpulan koneksi tersebut pada aplikasi yang menggunakan Bigtable, dan kapan Anda mungkin ingin mengubah setelan kumpulan koneksi default.

Setelah membaca halaman ini, jika Anda menentukan untuk mengubah ukuran kumpulan koneksi, lihat Mengonfigurasi kumpulan koneksi untuk mempelajari cara menentukan ukuran yang optimal dan cara mengubahnya. Jumlah koneksi di setiap kumpulan hanya dapat dikonfigurasi dalam kode Anda saat Anda menggunakan library klien Go, C++, atau Java untuk Cloud Bigtable.

Cara kerja kumpulan koneksi

Kumpulan koneksi, yang juga dikenal sebagai kumpulan saluran, adalah cache koneksi database yang dibagikan dan digunakan kembali untuk meningkatkan latensi dan performa koneksi. Koneksi digunakan dalam sistem {i>round robin<i}.

Saat menggunakan Bigtable, Anda membuat satu klien data per proses aplikasi. Setiap klien memiliki satu kumpulan koneksi. Setiap kumpulan koneksi berisi sejumlah koneksi gRPC, yang masing-masing dapat menangani hingga 100 streaming serentak. Permintaan yang dikirim melalui koneksi ini akan melewati middleware Google, yang kemudian akan mengarahkannya ke tabel Anda. Lapisan middleware terdiri dari banyak instance load balanced, dan setiap permintaan dirutekan melalui instance middleware yang memiliki ketersediaan paling banyak.

Anda dapat menganggap koneksi (atau saluran) seperti jalan raya yang memiliki hingga 100 jalur, dan setiap jalur (aliran) hanya dapat berisi satu mobil (permintaan) pada waktu tertentu. Batas 100 streaming serentak per koneksi gRPC diterapkan di lapisan middleware Google, dan Anda tidak dapat mengonfigurasi ulang jumlah ini.

Koneksi diperbarui secara otomatis sekali setiap jam. Selain itu, jika koneksi belum melihat permintaan dalam lima menit, middleware akan otomatis menghapus koneksi dan tidak membuatnya ulang hingga koneksi tambahan diperlukan.

Di balik layar, setiap channel memiliki satu subchannel. Setiap subsaluran memiliki koneksi HTTP2 yang menggunakan TCP untuk mengonversi permintaan menjadi byte dan mengirimkannya melalui middleware, lalu ke tabel Anda. Proses ini ditangani dengan lancar oleh layanan Bigtable, dan Anda tidak perlu mengonfigurasi apa pun untuk melakukannya.

Kumpulan koneksi dan traffic

Cara kumpulan koneksi memengaruhi performa

Idealnya, Anda harus memiliki koneksi gRPC yang cukup untuk menangani permintaan tanpa buffering. Namun, Anda tidak boleh memiliki begitu banyak koneksi yang sering kali terputus karena kurangnya penggunaan.

Koneksi tidak cukup

Jika kumpulan koneksi tidak memiliki cukup koneksi untuk menangani traffic Anda, middleware akan mulai melakukan buffering dan mengantrekan permintaan. Buffering ini memperlambat traffic, mengurangi jumlah permintaan per detik, dan meningkatkan latensi saat permintaan kembali.

Terlalu banyak koneksi

Jika kumpulan memiliki terlalu banyak koneksi, yang berarti beberapa koneksi tidak ada aktivitas, middleware akan memutuskan koneksi tidak ada aktivitas. Kemudian, jika ada permintaan baru yang mengharuskannya, koneksi ini akan dibuat kembali. Artinya, saat traffic meningkat, permintaan dapat mengalami cache sisi server yang tidak ditemukan, sehingga menyebabkan pekerjaan tambahan dan latensi. Jika hal ini sering terjadi karena tingkat traffic yang bervariasi, aktivitas ini dapat berwujud sebagai lonjakan latensi tail yang dirasakan di sisi klien.

Waktu untuk mengubah setelan default

Ukuran kumpulan koneksi default sudah tepat untuk sebagian besar aplikasi, dan umumnya tidak perlu mengubahnya. Bergantung pada library klien yang Anda gunakan dalam aplikasi, Anda mungkin tidak dapat mengubah ukuran kumpulan koneksi. Jumlah koneksi di setiap kumpulan dapat dikonfigurasi dalam kode Anda hanya jika Anda menggunakan library klien Go, C++, atau Java untuk Cloud Bigtable.

Sebagai aturan umum, kumpulan koneksi yang ideal memiliki setidaknya dua kali jumlah koneksi yang diperlukan untuk saturasi maksimum. Hal ini memberikan ruang untuk fluktuasi lalu lintas data. Misalnya, jika Anda memiliki 4 koneksi dan masing-masing menangani jumlah permintaan maksimum (100), sebaiknya kurangi jumlah permintaan per koneksi menjadi angka antara 10 dan 50, sehingga ukuran kumpulan koneksi yang ideal minimal dua kali lipat, atau minimal 8 koneksi.

Sinyal yang harus Anda pertimbangkan untuk mengubah jumlah koneksi dalam kumpulan meliputi hal berikut:

Throughput rendah dikombinasikan dengan lonjakan latensi tail sisi klien

Jika throughput biasanya cukup rendah, seperti kurang dari satu permintaan per detik per koneksi, dan Anda mengamati latensi tail yang tinggi secara berkala untuk aplikasi, Anda mungkin tidak mengirim traffic yang cukup untuk menjaga koneksi tetap aktif. Dalam hal ini, Anda mungkin perlu menurunkan jumlah koneksi dalam kumpulan. Lihat Mengonfigurasi kumpulan koneksi untuk mempelajari cara menentukan jumlah yang tepat.

Permintaan buffer

Jika Anda mengamati bahwa permintaan menumpuk di sisi klien, hal ini mungkin menunjukkan bahwa Anda mengirim lebih banyak permintaan serentak daripada yang dapat ditangani kumpulan koneksi. Hitung angka optimal, lalu ubah kode jika perlu.

Untuk menentukan apakah permintaan bertumpuk, Anda dapat menggunakan OpenCensus untuk melihat perbedaan antara metrik grpc.io/client/started_rpcs dan grpc.io/client/completed_rpcs.

Lingkungan virtual

Dalam beberapa kasus yang jarang terjadi, klien Bigtable tidak dapat mengetahui jumlah CPU tempat aplikasi berjalan dan mengalokasikan koneksi seolah-olah hanya ada satu CPU yang digunakan. Misalnya, hal ini dapat terjadi saat Anda menggunakan instance CPU virtual di Kubernetes atau Docker. Jika hal ini terlihat, Anda harus mengonfigurasi jumlah kumpulan sesuai dengan pedoman berdasarkan QPS dan latensi aplikasi Anda.

Langkah Berikutnya