ขยายขนาดไคลเอ็นต์ API ด้วยการเชื่อมต่อหลายจุด

โซลูชั่นไคลเอ็นต์ WhatsApp Business API มาตรฐานทำงานบนคอนเทนเนอร์ Docker เดี่ยว ในกรณีที่คุณต้องการแยกยอดการเข้าใช้งานและมีหลายเซิร์ฟเวอร์ในการส่งและรับข้อความให้กับ WhatsApp คุณสามารถใช้โซลูชั่นการเชื่อมต่อหลายจุดของเราเพิ่มเข้าไปได้

ภาพรวม

สำหรับความพร้อมใช้งานตลอดเวลา จะมีเพียงคอนเทนเนอร์ Docker เดียวเท่านั้นที่รับผิดชอบในการส่งและรับข้อความจากเซิร์ฟเวอร์ของ WhatsApp หากจำนวนการส่งข้อความสูงเกินกว่าปริมาณสูงสุดของคอนเทนเนอร์ Docker แบบเดี่ยว ระบบจะส่งข้อความที่คั่งค้างและเวลาแฝงของการส่งข้อความจะเพิ่มขึ้น เมื่อต้องการปรับขนาดไคลเอ็นต์ WhatsApp Business API การเชื่อมต่อหลายจุดจะรองรับการสร้างชาร์ดเพื่อกระจายโหลดไปยังคอนเทนเนอร์ Docker หลายตัว ขณะนี้เราสนับสนุนเฉพาะการสร้างชาร์ดแบบคงที่โดยมีจำนวนชาร์ดอยู่ที่ 1, 2, 4, 8, 16 หรือ 32 ความพร้อมใช้งานระดับสูงถือเป็นกรณีพิเศษของการเชื่อมต่อหลายจุดโดยจะมีจำนวนชาร์ดอยู่ที่ 1

คลัสเตอร์การเชื่อมต่อหลายจุดแบบ 2 ชาร์ด

ในคลัสเตอร์ มีโหนด Coreapp อยู่ 2 โหนด (CoreApp 1 และ CoreApp 3) ที่ทำหน้าที่ในการส่งและรับข้อความจากเซิร์ฟเวอร์ของ WhatsApp ในขณะเดียวกัน ทุกข้อความจะเป็นของชาร์ดเดียวเท่านั้นโดยอิงจาก ID ของผู้รับ

การสร้างชาร์ด

ไคลเอ็นต์ WhatsApp Business API ใช้การสร้างชาร์ดเพื่อให้มีการเชื่อมต่อหลายจุด ฐานข้อมูลจะจัดเก็บแผนที่ชาร์ดที่กำหนดว่าข้อความควรจะไปที่ชาร์ดใดโดยขึ้นอยู่กับ ID ของผู้รับ (หรือชื่อผู้ใช้ WhatsApp) ทั้งนี้ขึ้นอยู่กับจำนวนของชาร์ดที่คุณตั้งค่าไว้ ฟังก์ชั่นในการกำหนดนี้คือ:

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

แต่ละชาร์ดจะจับคู่กับคอนเทนเนอร์ Docker (Coreapp) ที่กำลังทำงานอยู่ Webapp รู้ว่าจะส่งคำขอข้อความไปยังคอนเทนเนอร์ Docker ใดโดยอิงจากการส่งกลับฟังก์ชั่นนี้ ขอแนะนำให้คุณตั้งค่าจำนวนโหนดและเครื่อง X เพื่อให้สามารถทนทานต่อความขัดข้องของเครื่อง X

จากแผนภาพการเชื่อมต่อหลายจุดแบบ 2 ชาร์ดด้านบน ข้อความจะถูกนำทางไปยัง CoreApp 1 และ CoreApp 3 ตามฟังก์ชั่นของชาร์ด โดย CoreApp 2 จะอยู่ในลำดับรองลงมาและมีความอุ่น แต่ไม่มีการเชื่อมต่อที่ใช้งานไปยังเซิร์ฟเวอร์ของ WhatsApp สมมติว่า CoreApp 1 รับข้อความของ shard=0 และ CoreApp 3 รับข้อความของ shard=1 หาก CoreApp 1 ล้มเหลว จะส่งผลกระทบกับข้อความของ shard=0 เท่านั้น ระบบจะยังคงส่งและรับข้อความที่เป็นของ shard=1 อยู่โดยใช้ CoreApp 3 คล้ายกับการทำให้ระบบพร้อมใช้งานตลอดเวลา Master 1 จะตรวจพบความล้มเหลวของ CoreApp 1 และย้ายการใช้งาน shard=0 ไปยังระบบสำรอง CoreApp 2 การย้ายไปยังระบบสำรองจะใช้เวลาประมาณ 35 วินาที

การตั้งค่าการเชื่อมต่อแบบหลายจุด

เมื่อคุณตั้งค่าคลัสเตอร์ของคุณตามเอกสารเกี่ยวกับความพร้อมใช้งานตลอดเวลาแล้ว ให้ใช้คำขอต่อไปนี้ในการเปิดการเชื่อมต่อหลายจุด

คำขอ

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"
}

พารามิเตอร์

การตอบกลับ

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

การดึงข้อมูลชาร์ด

คำขอ

GET /v1/account/shards

การตอบกลับ

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

อัตราการส่งข้อความ

ดูการอ้างอิง, ข้อความ, ประสิทธิภาพการทำงาน

รายละเอียดการนำ AWS ไปใช้

URL เทมเพลต:

• 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
• Network: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

เทมเพลตจะช่วยให้คุณสามารถกำหนดค่าจำนวนอินสแตนซ์คอนเทนเนอร์ Coreapp ที่ใช้งานที่คุณจะสร้าง เทมเพลตจะสร้างอินสแตนซ์คอนเทนเนอร์ Coreapp เพิ่มเติมหนึ่งอัน เพื่อช่วยให้ทำการเปลี่ยนได้อย่างรวดเร็วในกรณีที่เกิดความล้มเหลวของ Coreapp

เทมเพลตจะสร้างจำนวนของอินสแตนซ์ต่อไปนี้ต่อประเภทสภาพแวดล้อมสำหรับการเชื่อมต่อหลายจุด เมื่อเปิดใช้งานความพร้อมใช้งานตลอดเวลา:

• การผลิต: EC2 instances: 3, Web container: 3, Coreapp container: 3, Master container: 3
• การจัดเตรียม: อินสแตนซ์ EC2: 2 คอนเทนเนอร์เว็บ: 2 คอนเทนเนอร์ Coreapp: 2 คอนเทนเนอร์หลัก: 2

เทมเพลตกำหนดค่าไว้เป็นอินสแตนซ์ EC2 แบบปรับขนาดอัตโนมัติขึ้นอยู่กับการใช้หน่วยความจำ การใช้หน่วยความจำเพิ่มขึ้น (หรือลดลง) ด้วยจำนวนอินสแตนซ์คอนเทนเนอร์ Coreapp "ที่ใช้งาน" ที่เพิ่มขึ้น (หรือลดลง) ดังนั้น เมื่อมีการสร้างอินสแตนซ์ Coreapp มากขึ้น อินสแตนซ์ EC2 จะปรับขนาดตามโดยอัตโนมัติ อย่างไรก็ตาม จำนวนสูงสุดของอินสแตนซ์ EC2 ที่สามารถสร้างได้จำกัดไว้ดังนี้:

การปรับขนาดอินสแตนซ์ RDS

อัตราคำขอ API และจำนวนของอินสแตนซ์ Coreapp ที่ใช้งานจะเป็นตัวกำหนดจำนวนการเชื่อมต่อกับฐานข้อมูล เมื่ออินสแตนซ์ Coreapp ที่ใช้งานอยู่ 8 ตัวและอัตรา API 100 ข้อความ/วินาที จะต้องมีการเชื่อมต่อประมาณ 700 DB (ปิดใช้งาน SSL) และการเชื่อมต่อ 1200 DB (เมื่อเปิดใช้งาน SSL) อย่างไรก็ตาม เมื่ออินสแตนซ์ Coreapp ที่ใช้งานอยู่ 32 ตัวและอัตรา API 250 ข้อความ/วินาที จะต้องมีการเชื่อมต่อประมาณ 1,700 DB

ในรุ่นปัจจุบันเราใช้ db.m4.2xlarge สำหรับอินสแตนซ์ Coreapp ที่ใช้งานอยู่ 8 ตัว (ปิดใช้งานการเข้ารหัสการเชื่อมต่อ DB) และ db.m4.4x.large สำหรับอินสแตนซ์ Coreapp ที่ใช้งานอยู่ 32 ตัว (เปิดใช้งานการเข้ารหัสการเชื่อมต่อ DB) ตารางต่อไปนี้ให้คำแนะนำเกี่ยวกับการเลือกคลาสอินสแตนซ์ RDS และจำนวนการเชื่อมต่อสูงสุดที่สามารถรองรับได้:

การกำหนดค่า

• อินสแตนซ์ Coreapp ที่ใช้งานที่ตั้งค่าไว้ในเทมเพลตจะควบคุมเฉพาะจำนวนของอินสแตนซ์ Coreapp ที่สร้างขึ้นเท่านั้น อย่างไรก็ตาม หากต้องการตั้งค่าการทำงานเเบบเดียวกัน จะต้องใช้ ชาร์ดที่กำหนด (จัดทำเป็นเอกสารไว้ในหัวข้อการตั้งค่าการเชื่อมต่อหลายจุด ค่าเริ่มต้นของชาร์ดคือ 1
• ตรวจสอบให้แน่ใจอยู่เสมอว่าจำนวนของอินสแตนซ์ Coreapp มากกว่าหรือเท่ากับจำนวนชาร์ดที่กำหนดใน API เสมอ
• การเพิ่มจำนวนชาร์ด:

  • สร้างหรืออัพเดตสแต็กด้วยจำนวนอินสแตนซ์ Coreapp ที่ใช้งานที่ต้องการ
  • เมื่อทำสำเร็จแล้ว ให้ใช้ชาร์ดที่กำหนดเพื่อเปิดใช้งานจำนวนอินสแตนซ์ Coreapp ที่ใช้งาน/ชาร์ดที่เท่ากัน
  • หมายเหตุ:ชาร์ดที่กำหนดทำให้อินสแตนซ์ของคอนเทนเนอร์ Coreapp ทั้งหมดหยุดทำงานและรีสตาร์ทโดยอัตโนมัติ จะมีการหยุดทำงานประมาณ 45 วินาทีถึง 1 นาทีเมื่อใช้งานชาร์ดที่กำหนด
• การลดจำนวนชาร์ด:

  • ใช้ชาร์ดที่กำหนดเพื่อลดจำนวนอินสแตนซ์ Coreapp ที่ใช้งาน/ชาร์ดที่เท่ากัน
  • เมื่อรีสตาร์ทอินสแตนซ์ Coreapp ทั้งหมดสำเร็จแล้ว ให้อัพเดตสแต็กด้วยจำนวนอินสแตนซ์ Coreapp ที่ใช้งานที่เท่ากัน
  • หมายเหตุ: การอัพเดตสแต็กอาจยุติการทำงานของอินสแตนซ์ Coreapp ที่ให้บริการชาร์ดที่ใช้งานอยู่ อย่างไรก็ตาม จะมีการกำหนดอินสแตนซ์ Coreapps ที่มีอยู่ในไม่ช้า กล่าวอีกนัยหนึ่งคือ อาจมีการหยุดทำงานเพิ่มเติม (ประมาณ 35 วินาที) ในระหว่างกระบวนการนี้