Governance (Governance)

space-based architecture ซึ่งมีส่วนประกอบที่เคลื่อนไหวจำนวนมาก เป็น architectural style ที่ซับซ้อนในการ ออกแบบและ implement governance ที่เหมาะสมมีความสำคัญอย่างยิ่งต่อความสำเร็จ—โดยเฉพาะการควบคุมการใช้ memory เนื่องจาก style นี้มีปัญหาด้านการใช้ internal memory (ตามที่เราได้กล่าวไว้ก่อนหน้านี้ใน “Common Risks” )

เพื่อแก้ปัญหาเรื่อง memory เหล่านี้ เราแนะนำให้เขียน governance fitness function แบบต่อเนื่องและอัตโนมัติ เพื่อให้ processing unit แต่ละ instance สามารถแสดงการใช้ memory ปัจจุบันของตัวเองได้เป็นระยะ เนื่องจาก instance ทั้งหมดของ processing unit มี replicated cache เดียวกัน fitness function จึงจำเป็นต้องรายงาน แค่ชื่อของ processing unit เท่านั้น ใช้ fitness function แยกต่างหากเพื่อบันทึกจำนวน instance ของ processing unit แต่ละตัว ทำให้สามารถคำนวณการใช้ memory รวมต่อ processing unit ได้ Figure 16-15 แสดงตัวอย่าง output ของ continuous fitness function นี้

Figure 16-15. ตัวอย่าง fitness function สำหรับติดตามการใช้ memory

อีก governance strategy หนึ่งที่มีประโยชน์ในการรักษา data consistency โดยรวมคือการติดตามและวัด synchronization time—โดยเฉพาะระยะเวลาที่ใช้ในการ sync การอัปเดต cache ไปยังฐานข้อมูลที่เกี่ยวข้อง วิธีที่ ดีคือให้ processing unit แต่ละตัว stream request ID ของการอัปเดตพร้อมกับ timestamp ที่เกี่ยวข้อง และให้ data writer แต่ละตัว stream request ID เดียวกันพร้อม timestamp หลังจาก commit ฐานข้อมูล จากนั้นเขียน fitness function เพื่อจับคู่ request ID เหล่านี้และลบ timestamp เพื่อคำนวณ synchronization time fitness function สามารถติดตามในระดับ atomic โดยใช้เวลาที่เกี่ยวข้องกับ processing unit เฉพาะตัว หรือในภาพรวม โดยการหาค่าเฉลี่ยของ synchronization time ทั้งหมด การวิเคราะห์แนวโน้มเหล่านี้ช่วยให้สถาปนิกติดตามผล กระทบของการเปลี่ยนแปลง architecture ได้ เช่นว่าการเปลี่ยนแปลงนั้นทำให้ synchronization time ดีขึ้นหรือ แย่ลง และ architecture ตอบสนองเป้าหมายด้านเวลา synchronization ของธุรกิจหรือไม่ Figure 16-16 แสดงตัวอย่าง governance ประเภทนี้ผ่าน continuous fitness function

Figure 16-16. ตัวอย่าง fitness function สำหรับติดตามค่าเฉลี่ย synchronization time โดยรวม

ตามที่เราได้กล่าวไว้ เนื่องจาก data pump ทำหน้าที่เป็นจุด backpressure ใน space-based architecture และ เนื่องจากการเขียนฐานข้อมูลใช้เวลานานกว่าการเขียน cache data pump จึงอาจกลายเป็น bottleneck ของระบบโดยรวม ได้ เพื่อควบคุมสิ่งนี้ เราแนะนำให้ติดตามและวัด bottleneck ประเภทนี้เมื่อเกิดขึ้น ก่อนอื่น เพื่อหาขอบเขต ของ bottleneck ให้เขียน fitness function เพื่อติดตาม queue depth ของ queue ที่ใช้ใน data pump bottleneck ที่มากเกินไปจะเพิ่ม synchronization time (และส่งผลต่อ data consistency) และยังเพิ่มโอกาสเกิด การสูญหายของข้อมูลและ data collision โดยเฉพาะในช่วงที่มี user-concurrency สูง เช่นเดียวกับ fitness function ก่อนหน้า function นี้สามารถรายงานแบบ atomic สำหรับแต่ละ data-pump queue หรือรวมเป็นค่าเฉลี่ย ของทั้งระบบก็ได้ Figure 16-17 แสดงการวิเคราะห์ bottleneck สำหรับ processing unit Order Placement และ data pump ที่เกี่ยวข้อง ในระบบ order-processing ทั่วไป

Figure 16-17. ตัวอย่าง fitness function สำหรับติดตาม bottleneck ของ data pump

governance fitness function อื่น ๆ สำหรับ space-based architecture สามารถติดตามความถี่ของการอ่านฐาน ข้อมูล (request ไปยัง data reader) ซึ่งอาจส่งผลต่อ scalability, elasticity และ responsiveness นอกจากนี้ ยังเป็นความคิดที่ดีที่จะใช้ fitness function เพื่อวัด scalability, elasticity และ responsiveness เนื่องจากลักษณะ architectural เหล่านี้เป็นเหตุผลหลักในการใช้ space-based architecture การติดตามและวัด ค่าเหล่านี้จึงสมเหตุสมผล