Skalakan Klien API Anda dengan Multikoneksi

Solusi Klien API WhatsApp Business standar berjalan pada satu kontainer Docker. Jika Anda ingin membagi beban dan memiliki beberapa server yang mengirim dan menerima pesan ke WhatsApp, Anda juga dapat menggunakan solusi multikoneksi kami.

Ringkasan

Dengan ketersediaan tinggi, hanya satu kontainer Docker yang bertanggung jawab untuk mengirim dan menerima pesan dari server WhatsApp. Jika traffic pengiriman pesan melebihi throughput maksimum sebuah kontainer Docker, akan terjadi backlog pengiriman pesan dan latensi penyampaian pesan akan meningkat. Untuk menyesuaikan skala Klien API WhatsApp Business, multikoneksi mendukung sharding untuk menyebar muatan ke beberapa kontainer Docker. Saat ini, kami hanya mendukung sharding statis dengan jumlah partisi 1, 2, 4, 8, 16, atau 32. Ketersediaan tinggi adalah kasus istimewa multikoneksi dengan jumlah partisi 1.

Klaster multikoneksi 2 partisi

Di dalam klaster, terdapat dua node CoreApp (CoreApp 1 dan CoreApp 3) yang bertanggung jawab untuk mengirim dan menerima pesan dari server WhatsApp pada saat yang sama. Setiap pesan hanya akan dimiliki oleh satu partisi berdasarkan ID penerima.

Sharding

Klien API WhatsApp Business menggunakan sharding untuk mencapai multikoneksi. Tergantung pada jumlah partisi yang Anda siapkan, database akan menyimpan peta partisi yang menentukan partisi mana yang harus dituju pesan sesuai dengan ID penerima (atau nama pengguna WhatsApp). Fungsi untuk menentukan ini adalah:

shard_id = hash(recipient-id) % shard-number

Setiap partisi dipetakan ke kontainer Docker yang berjalan (CoreApp). Aplikasi Web akan mengetahui kontainer Docker mana yang akan dikirimi permintaan pesan berdasarkan pengembalian fungsi ini. Anda direkomendasikan untuk menyiapkan jumlah partisi + X mesin untuk dapat menoleransi X kegagalan mesin.

Dalam diagram multikoneksi 2 partisi di atas, pesan diarahkan ke CoreApp 1 dan CoreApp 3 berdasarkan fungsi sharding. CoreApp 2 adalah sekunder — CoreApp ini hangat, tetapi tidak memiliki koneksi aktif ke server WhatsApp. Anggap CoreApp 1 mendapatkan pesan untuk shard=0 dan CoreApp 3 mendapatkan pesan untuk shard=1. Jika CoreApp 1 mati, hanya pesan untuk shard=0 yang akan terpengaruh. Sistem masih akan mengirim dan menerima pesan milik shard=1 menggunakan CoreApp 3. Mirip dengan ketersediaan tinggi, Master 1 akan mendeteksi kegagalan CoreApp 1 dan mengarahkan traffic shard=0 untuk failover ke CoreApp 2. Failover ini akan memakan sekitar 35 detik.

Menyiapkan Multikoneksi

Setelah Anda menyiapkan klaster Anda sesuai dengan Dokumentasi Ketersediaan Tinggi, gunakan permintaan berikut untuk mengaktifkan multikoneksi.

Permintaan

POST /v1/account/shards
{
    "cc": "country-code",
    "phone_number": "phone-number",
    "shards": 1 | 2 | 4 | 8 | 16 | 32,
    "pin": "pin",
    "cert": "verified-name-cert-in-base64"
}

Parameter

Tanggapan

201 Created   : You successfully changed shard number 
403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it

Mengambil Informasi Partisi

Permintaan

GET /v1/account/shards

Tanggapan

{
  "account": {
      "shards": number-of-shards 
  }
}

Laju Pengiriman Pesan

Lihat Referensi, Pesan, Kinerja.

Detail Penerapan AWS

URL Template:

• Enterprise: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• DB: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• Jaringan: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

Template ini memungkinkan Anda untuk mengonfigurasi jumlah instance kontainer CoreApp aktif yang akan dibuat. Template membuat satu instance kontainer CoreApp tambahan untuk membantu peralihan cepat jika terjadi kegagalan CoreApp.

Template membuat sejumlah instance per jenis lingkungan berikut untuk Multikoneksi, secara default, saat Ketersediaan Tinggi diaktifkan:

• Produksi: Instance EC2: 3, Kontainer Web: 3, Kontainer CoreApp: 3, Kontainer Master: 3
• Staging: Instance EC2: 2, Kontainer Web: 2, Kontainer CoreApp: 2, Kontainer Master: 2

Template ini dikonfigurasikan untuk penskalaan otomatis instance EC2, bergantung pada penggunaan memori. Utilisasi memori meningkat (atau menurun) dengan peningkatan (atau penurunan) dalam jumlah instance kontainer CoreApp “aktif”. Oleh karena itu, ketika lebih banyak instance CoreApp dibuat, instance EC2 akan diskalakan secara otomatis. Namun, jumlah maksimum instance EC2 yang dapat dibuat dibatasi sebagai berikut:

Ukuran Instance RDS

Laju permintaan API & jumlah instance CoreApp aktif menentukan jumlah koneksi ke database. Dengan 8 instance CoreApp aktif dan laju API 100 pesan/detik, dibutuhkan sekitar 700 koneksi DB (SSL dinonaktifkan) dan 1200 koneksi DB (saat SSL diaktifkan). Namun, dengan 32 instance CoreApp aktif dan laju API 250 pesan/detik, dibutuhkan sekitar 1.700 koneksi DB.

Dalam rilis saat ini, kami menggunakan db.m4.2xlarge untuk 8 instance CoreApp aktif (enkripsi koneksi DB dinonaktifkan) dan db.m4.4x.large untuk 32 instance CoreApp aktif (enkripsi koneksi DB diaktifkan). Tabel berikut memberikan panduan tentang pemilihan kelas instance RDS dan jumlah koneksi maksimum yang dapat didukungnya:

Konfigurasi

• Instance CoreApp aktif yang diatur dalam template hanya mengatur jumlah instance CoreApp yang dibuat. Namun, untuk mengaktifkan hal yang sama, Atur Partisi (didokumentasikan di bagian Menyiapkan Multikoneksi) harus digunakan. Nilai default partisi adalah 1.
• Pastikan bahwa jumlah instance CoreApp selalu lebih besar dari atau sama dengan jumlah partisi yang diatur dalam API.
• Untuk meningkatkan jumlah partisi:

  • Membuat atau memperbarui stack dengan jumlah instance CoreApp aktif yang diinginkan.
  • Setelah berhasil, gunakan Atur Partisi untuk mengaktifkan jumlah instance/partisi CoreApp aktif yang sama.
  • Catatan:Atur Partisi menyebabkan semua instance kontainer CoreApp berhenti dan dimulai ulang secara otomatis. Akan ada waktu henti sekitar 45 detik sampai 1 menit ketika Atur Partisi dieksekusi.
• Untuk mengurangi jumlah partisi:

  • Gunakan Atur Partisi untuk mengurangi jumlah instance/partisi CoreApp aktif yang sama.
  • Setelah semua instance CoreApp berhasil dimulai ulang, perbarui stack dengan jumlah instance CoreApp aktif yang sama.
  • Catatan: Memperbarui stack dapat menghentikan instance CoreApp yang sedang aktif yang melayani partisi. Namun, instance CoreApp lainnya yang masih aktif akan segera ditetapkan. Dengan kata lain, mungkin ada waktu henti tambahan (~35 detik) selama prosedur ini.