สถาปัตยกรรมแบบผู้เช่าหลากหลาย Multi-tenancy Architecture

การบริการคลาวด์ในปัจจุบัน มีบริการหนึ่งคือ SaaS หรือ Software as a Service ซึ่งผู้ให้บริการ SaaS รายใหญ่ๆ ในการบริการให้กับลูกค้า หรือผู้เช่า โดยส่วนมากและให้ความสำตัญไปที่การใช้สถาปัตยกรรม Multi-tenancy การบริการนี้สามารถใช้ทรัพยากร(resources)ร่วมกัน ที่ยังคงมีการแยกความแตกต่างระหว่างผู้เช่า(tenant)แต่ละรายไว้

ตัวอย่างง่ายๆ: ลองนึกถึงอาคารสำนักงาน — ตึกเดียว แต่มีหลายบริษัทเช่าพื้นที่อยู่ แต่ละบริษัทมีห้องและกุญแจของตัวเอง ใช้ลิฟต์และล็อบบี้ร่วมกัน แต่ไม่สามารถเข้าห้องของบริษัทใดบริษัทหนึ่งที่ไม่ใช่เจ้าของได้

การแยกระหว่างผู้ใช้

การออกแบบ multi-tenancy application จะต้องมีการแยกระหว่าง tenant เป็นสิ่งที่ขาดไม่ได้

Application แบบ multi-tenancy จะเป็น single instant (เป็น 1 instant application ที่ทำงานได้หลายๆ tenant) และส่งต่อไปยังฐานข้อมูล ระบบฐานข้อมูลจะแยกตามแต่ละ tenant ในการเข้าถึงการใช้งาน วิธีการแยกตามฐานข้อมูลสามารถทำได้หลายรูปแบบ เช่น

1. แยกฐานข้อมูลเฉพาะ (Database per Tenant)

สร้างฐานข้อมูลแยกสำหรับแต่ละ tenant

Tenant A  →  Database A
Tenant B  →  Database B
Tenant C  →  Database C

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

2. แยกด้วย Schema (Shared Database, Separate Schema)

Database เดียว
├── Schema: tenant_a
│     └── table: patients, appointments, ...
├── Schema: tenant_b
│     └── table: patients, appointments, ...
└── Schema: tenant_c
      └── table: patients, appointments, ...

เหมาะกับ: ระบบที่ต้องการสมดุลระหว่างการแยกข้อมูลและการประหยัดต้นทุน

3. แยกด้วยคอลัมน์ / Sharding (Shared Database, Shared Schema)

ใช้ฐานข้อมูลและตารางเดียวกัน แต่มีคอลัมน์ tenant_id เพื่อระบุว่าข้อมูลแถวนี้เป็นของ tenant ใด

ตาราง patients (ร่วมกัน)
┌────────────┬─────────────┬────────────┐
│ tenant_id  │ patient_id  │ name       │
├────────────┼─────────────┼────────────┤
│ tenant_a   │ 001         │ สมชาย      │
│ tenant_b   │ 001         │ John       │
│ tenant_a   │ 002         │ สมหญิง      │
└────────────┴─────────────┴────────────┘

Database Sharding เป็นอีกรูปแบบที่ขยายจากแนวคิดนี้ โดยแบ่งข้อมูลตามช่วง tenant_id ออกเป็นหลาย shard เพื่อกระจาย load

เหมาะกับ: SaaS ขนาดใหญ่ที่มี tenant จำนวนมาก และ tenant แต่ละรายมีข้อมูลไม่มาก

สถาปัตยกรรม

โครงสร้่างของ multi-tenancy architecture ลักษณะการออกแแบแสดงตามรูปข้างล่าง เป็นดังนี้

1. Application - โปรแกรมใช้งาน ทำหน้าที่ติดต่อกับผู้ใช้ตามแต่ละ tenant และเชื่อมไปยังส่วนหลัง middle ware
   การปรับหรือ customize ของแต่ละ tenant จะทำที่ชั้น application นี้ และโปรแกรมออกแบบมาให้ทำงานลักษณะ multi-concurrency
2. Middleware - ทำหน้าที่เชื่อมกับ application และ mapping เข้ากับ database
3. Database - ฐานข้อมูลของผู้ใช้งานตามแต่ละ tenant
4. Virtual machine/container - สำหรับทำหน้าที่ให้โปรแกรมทำงานโดยใช้ resources จากส่วนกลาง ซึ่งสามารถเป็นได้ทั้ง virtual machine หรือ container(เข่น docker หรือ podman) ในหนึ่ง virtual machine หรือ container สามารถทำงานได้หลายๆ tenant ขึ้นอยู่กับ resources ที่ได้กำหนดไว้
5. Common-resources(hardware, networking, etc) - resources ส่วนกลางที่ผู้ให้บริการ(service provider)จัดหาให้ และส่วน networking เชื่อมต่อไปยังปลายทางที่ต่างๆ

นอกจากนี้การออกแบบ multi-tenancy ยังสามารถสร้าง database กลางเพื่อใช้กับ tenant ต่างๆ ซึ่งเป็นข้อมูลที่ต้องการแบ่งปันการใช้ระหว่าง tenant(เป็นข้อมูลเปิด) เช่น ICD-9(Procedure), ICD-10, ICD-11