Availability Tactics

ระบบล่ม!!! เดี๋ยวนี้กลายเป็นปัญหาที่พบเจอได้บ่อยครั้ง แถมหลายครั้งยังเกิดกับระบบในองค์กรขนาดใหญ่ที่มีชื่อเสียงอีกด้วย ไม่ว่าจะเป็น ธนาคาร หน่วยงานภาครัฐ บริษัทเอกชน สำหรับสาเหตุนั้นมีไม่มาก ไว้มีโอกาสจะมาเล่าสู่กัน หลักๆ มักเกี่ยวกับความสะเพร่า ประมาท ขาดความรู้และทักษะ และชอบใช้ ‘ของแพง’ กัน พอใช้ของแพงมากมันก็เทอะทะยุ่งยากใหญ่โต จะขยับขยายจะสำรองกันก็ลำบาก เพราะอะไรๆ ก็เงินๆๆ และที่สำคัญมักมุ่งเน้นไปที่ฮาร์ดแวร์กันมากเกินไป จนลืมเรื่องการออกแบบระบบและการเขียนโปรแกรมว่าควรทำอย่างไรไม่ให้ระบบมันล่ม ให้มันมีเสถียรภาพ ให้มันแข็งแกร่ง แข็งแรง สุขภาพ ไม่เจ็บไม่ป่วยง่าย

Availability เป็นคุณภาพสำคัญหนึ่งของสถาปัตยกรรมซอฟต์แวร์หรือระบบไอที จงจำไว้เลยว่า… เราต้องออกแบบสถาปัตยกรรมซอฟต์แวร์หรือระบบก่อน… ก่อนกำหนดสเป๊กฮาร์ดแวร์ จะสร้างบ้าน ยังไม่ได้ออกแบบเลย จะไปรู้ได้อย่างไร ว่าจะซื้อวัสดุ อุปกรณ์อะไรกันบ้าง specification และ qualification อะไรดี??? ก็บ้านเรามันชอบซื้อฮาร์ดแวร์และออกแบบเน็ตเวิร์กกันก่อน เอะอะก็อ้างว่าทำ  sizing ได้ ทำ benchmark มาแล้ว โน่นนี่นั่น สาเหตุหนึ่งมักมาจากการเบิกจ่ายและจัดการงบประมาณ การทุจริตคอร์รัปชั่น การฮั้วประมูล การมีช่องโหว่ในการจัดซื้อจัดจ้าง การเชื่อเวนเดอร์มากเกินไป หรือการสมรู้ร่วมคิด เพราะคงคิดว่าเงินก็เงินผู้ถือหุ้น เงินภาษีประชาชน เงินเจ้าของบริษัท ไม่ใช่เงินฉัน (กรู) ถ้าไม่ทำ configuration management และเก็บข้อมูลสถิติมาดีไม่มีทางรู้หรอกว่าจะใช้อุปกรณ์อะไร สเป๊กอะไรดี รุ่นไหนดี ราคาเท่าไรดี…

อ๊ะ บ่นมามาก เรื่องระบบล่มนี่มันดราม่า น้ำเน่ายิ่งกว่าละครหลังข่าว ไว้จะมาเล่ากันครับ มาดู tactic เกี่ยวกับการจัดการคุณภาพด้าน Availability กันดีกว่า ว่าจะออกแบบสถาปัตยกรรมซอฟต์แวร์อย่างไรให้มีสุขภาพดี ไม่ล่มไม่ล้มง่าย…

ใบ้ให้นิดว่าเรื่อง Availability นั้นต้องออกแบบร่วมกันทั้ง ซอฟต์แวร์ ฮาร์ดแวร์ เน็ตเวิร์ก… บ้านเรามันชอบแยกกันทำ เพราะบ้านเราองค์กรส่วนมากไม่มี architect ไงครับ แถมถ้าองค์กรใหญ่ต้องเป็น architect ระดับ enterprise architect หรืออย่างน้อยๆ ก็ต้อง solution architect… เฮ้อ ใบ้อีกทีละกันครับว่าระบบล่มสาเหตุหลักคือมาจากวิสัยทัศน์และฝีมือของผู้บริหารไอทีครับ… บ้านเรามีผู้บริหารไอที (IT manager/CIO/CTO) เก่งๆ เนี่ยน้อยมาก พวกนี้เนี่ยจุดอ่อนขององค์กรเลยล่ะ… ยกเว้นคนที่เก่งจริงนะ ก็จะกลายเป็นจุดแข็งแทน…

อ้ะ มาดู availability tactic กันดีกว่า…

Fault Detection คือ การดักจับข้อผิดพลาด ได้แก่

Ping/Echo

  • Ping/Echo คือ เป็นการ ping ไปยังเซิร์ฟเวอร์/อุปกรณ์ที่ต้องการ เพื่อดูว่าเซิร์ฟเวอร์ยัง ‘alive’ หรือมีความพร้อมอยู่หรือไม่ก่อนที่จะส่ง request ออกไปเรียกอิลิเม้นต์บนเครื่องนั้น แต่เทคนิคนี้เป็นการตรวจสอบที่ระดับเครื่องเซิร์ฟเวอร์ ดังนั้นหากต้องการตรวจสอบที่ระดับแอพพลิเคชั่นจึงต้องออกแบบประยุกต์เพิ่มเติมต่างหาก

Heartbeat

  • Heartbeat คือ การ Ping/Echo เป็นจังหวะที่สม่ำเสมอเหมือนการเต้นของหัวใจ อาทิ ตรวจสอบความพร้อมของเซิร์ฟเวอร์/อุปกรณ์ทุก 30 วินาที
  • ข้อดีของ Heartbeat คือ สามารถจัดการ performance ได้ดี โดยไม่จำเป็นต้อง Ping ก่อนส่ง request ไปเรียกอิลิเม้นต์ยังเครื่องเซิร์ฟเวอร์ปลายทางทุกครั้ง อาทิ ระบบ A ต้องส่ง request ไปยังระบบบนเซิร์ฟเวอร์ XYZ เฉลี่ยชั่วโมงละ 360,000 request หากต้อง Ping ทุกครั้งที่ส่ง request จะทำให้ต้อง Ping ถึง 360,000 ครั้ง/ชั่วโมง ทำให้ต้องใช้เน็ตเวิร์กรวมทั้งสิ้น 720,000 ครั้ง/ชั่วโมง, หากใช้ Heartbeat โดย Ping ทุก 30 วินาที จะเหลือ Ping เพียง 120 ครั้ง/ชั่วโมง ทำให้ต้องใช้เน็ตเวิร์กรวมเหลือเพียง 360,120 ครั้ง/ชั่วโมง เท่านั้น

Exception

  • Exception คือ การดักจับข้อผิดพลาด (exception/error) ก่อนที่จะเกิดขึ้นจริง ด้วยการกำหนดกรอบการจัดการเอาไว้ล่วงหน้า โดยวิเคราะห์แต่ละขึ้นตอนใน process หรืออัลกอริธึม หรือแต่ละ statement ในซอร์สโค้ด แล้ววางการจัดการผิดพลาดให้สัมพันธ์กับประเภทข้อผิดพลาดที่อาจเกิดขึ้น
  • Exception มีวัตถุประสงค์คือเพื่อดักข้อผิดพลาด ไม่ให้ข้อผิดพลาดที่เกิดขึ้นส่งผลทำให้ระบบทำงานสะดุดหรือหยุดลง
  • Exception มีหัวใจสำคัญคือไม่ว่าข้อผิดพลาดจะเกิดที่จุดใดจะต้องส่งต่อรายละเอียด (exception/error message) ขึ้นมาจนถึงระดับไคลเอ็นต์หรือหน้าจอได้ โดยไม่สะดุกหรือหยุดกลางทาง อันอาจทำให้ระบบทำงานค้างได้
  • Exception มักออกแบบเป็นระดับขั้น (Hierarchy) ดังนั้นจึงศึกษาการจัดการ Exception ของภาษาโปรแกรมที่ใช้หรือเฟรมเวิร์กที่ใช้ให้ดี
  • Exception เป็นการจัดการที่ควรออกแบบและวางกรอบการจัดการในระดับสถาปัตยกรรม ไม่ควรปล่อยให้โปรแกรมเมอร์ที่ขาดความชำนาญด้านนี้เขียนโปรแกรมจัดการเอง เพราะบ่อยครั้งที่ระบบล่มมักเกิดจากความบกพร่องในการจัดการ Exception ที่ระดับซอร์สโค้ด แต่ก็เพราะจากความละเลยและไม่รู้ของ system analyst หรือ software architecture  เองด้วย

 

Fault Recovery คือ การกู้หรือแก้ไขเมื่อเกิดข้อผิดพลาดขึ้น ได้แก่

Voting

  • Voting คือ การโหวตที่จะกู้อิลิเม้นต์ใดบ้างเมื่อระบบล่มไปแล้ว เพราะในหลายสถานการณ์อาจไม่สามารถกู้ทุกอิลิเม้นต์ได้ เพราะบางอิลิเม้นต์อาจไม่คุ้มค่าที่จะกู้ อาทิ กู้ทรานแซกชั่นที่มีผลต่อธุรกิจมากๆ ขึ้นมาเท่านั้น, กู้ข้อมูลทรานแซกชั่นที่คืบหน้าไปไม่ต่ำกว่า 80 เปอร์เซ็นต์, ไม่กู้ทรานแซกชั่นที่ทำงานคืบหน้าไปยังไม่ถึง 20 เปอร์เซ็นต์ เป็นต้น
  • Voting ควรมีการวางกรอบและแนวทางเอาไว้ล่วงหน้าเผื่อกรณีฉุกเฉิน ซึ่งควรมีแนวปฏิบัติที่ชัดเจน
  • Voting สามารถเครื่องมือกดดันเพื่อขับเคลื่อนแนวทางการจัดการ Backup & Recovery อาทิ หากระบบมีทรานแซกชั่นที่มีผลต่อธุรกิจมากๆ หากระบบล่มต้องกู้ขึ้นมาให้ได้ไม่ต่ำกว่า 80 เปอร์เซ็นต์ของทรานแซกชั่นทั้งหมดที่ทำงานค้าง ฉะนั้นการ backup จึงควรทำบ่อยและถี่ขึ้น เพื่อลดการสูญเสียที่เกิดจากช่องว่างของเวลาระหว่างการ backup แต่ละครั้ง

Redundancy

  • Redundancy คือ การมีอิลิเม้นต์ที่ทำงานซ้ำกับอิลิเม้นต์หลัก เมื่ออิลิเม้นต์หลักล่ม อาทิ มีเครื่องเซิร์ฟเวอร์ 2 ตัวทำ Redundancy กัน โดย Redundancy มีหลายประเภท อาทิ
    • Active redundancy หรือ hot start คือ การมีอิลิเม้นต์ทำงานคู่ขนานกับอิลิเม้นต์หลัก เมื่ออิลิเม้นต์หลักหยุดทำงานก็สลับให้อิลิเม้นต์รองที่เป็น active redundancy ขึ้นมาเป็นอิลิเม้นต์หลักแทนแล้วทำงานต่อ
    • Passive redundancy คือ การมีอิลิเม้นต์สำรองที่ความพร้อม เมื่ออิลิเม้นต์หลักหยุดทำงานก็สลับมา activate ให้อิลิเม้นต์ที่เป็น passive redundancy ทำงานต่อเนื่องได้ทันที แต่อาจมีเวลาหน่วงในช่วงสลับกันบ้าง โดย passive redundancy มีหลายประเภทอาทิ
      • Warm start คือ การ activate อิลิเม้นต์สำรองที่ต้องมีเวลาหน่วง เช่น เครื่องสำรองปิดอยู่ ต้องสตาร์ทก่อน
      • Dual/double redundancy คือ มีอิลิเม้นต์สำรองชุดหนึ่งแยกจากอิลิเม้นต์หลัก เหมือนมีเครื่องเหมือนกัน 2 ชุด ชุดหลักล่มก็ยังมีอีกชุด
      • Triple redundancy คือ มีอิลิเม้นต์สำรอง 2 ชุด เหมือนมีเครื่องเหมือนกัน 3 ชุด ชุดหลักล่มยังมีอีก 2 ชุด ชุดที่ 2 ล่มก็ยังมีชุดที่ 3

Spare

  • Spare คือ การมีอิลิเม้นต์สำรอง เพื่อใช้แทนกัน อาทิ ไลเซนส์สำรอง, อุปกรณ์สำรอง, ไฟล์ไลบรารี่สำรอง, หน่วยความจำสำรอง เป็นต้น

Resynchronization

  • Resynchronization คือ การเชื่อมต่อการทำงานให้สอดประสานเข้าจังหวะกัน หลังจากเมื่อเกิดข้อผิดพลาดที่ทำให้การทำงานขาดช่วง โดย Resynchronization มีหลายประเภท อาทิ
    • Shadow resynchronization คือ การมีอิลิเม้นต์ที่ทำงานคู่ขนานกับ อิลิเม้นต์หลัก เมื่ออิลิเม้นต์หลักหยุดทำงานก็จะสลับ priority แล้ว synchronize มาให้อีกอิลิเม้นต์ขึ้นเป็นอิลิเม้นต์หลักและทำงานต่อเนื่อง โดยหลักการคล้ายกับ Redundancy แต่กรณี Resynchronization พิจารณาไปที่ความต่อเนื่องของการทำงาน
    • State resynchronization คือ การ synchronize สถานการณ์ทำงานต่อจากอิลิเม้นต์ที่หยุดทำงาน สถานการณ์ทำงานได้แก่ process การทำงาน และข้อมูลระหว่างการทำงาน เช่น ข้อมูลทรานแซกชั่น

Checkpoint/Rollback

  • Checkpoint/Rollback คือ การกำหนดจุด Checkpoint (บางทีเรียกว่า ‘savepoint’) ในช่วงต่างๆ ตั้งแต่ 1 จุดหรือมากกว่าภายใน process หรือทรานแซกชั่น เมื่อการทำงานเกิดข้อผิดพลาดใดๆ ขึ้น จะสามารถกำหนดให้ Rollback หรือย้อนสถานะกลับไปยังจุด Checkpoint ใดก็ได้ตามที่ได้กำหนดไว้ก่อนหน้า ทำให้ไม่ต้อง Rollback ทั้งหมดโดยย้อนกลับไปยังจุดต้นใหม่
  • ควรกำหนดจุด Checkpoint/Rollback ให้สอดคล้องกับ business process และ business rule/logic
  • การใช้ Checkpoint/Rollback ให้ศึกษาหลักการและเทคนิคของ resource system, resource driver (เช่น database driver) และภาษาโปรแกรมนั้นๆ ให้ดีๆ และเลือกใช้ให้เหมาะสม

 

Fault Prevention คือ การป้องกันข้อผิดพลาดก่อนที่จะเกิดขึ้นจริง ได้แก่

Remove from Service

  • Remove from Service คือ การลบหรือปิดอิลิเม้นต์ที่กำลังทำงานผิดปกติที่อาจส่งผลต่อการทำงานโดยรวมของระบบซึ่งมีความน่าจะเป็นสูงที่อาจทำให้ระบบหยุดทำงานหรือล่ม หากไม่ลบหรือปิดอาจเลือกใช้การหยุดการทำงานชั่วคราวแต่ก็ประเมินเรื่องการ lock resource ที่อาจค้างจนอาจทำให้เกิด deadlock ให้ดีๆ ด้วย
  • Remove from Service อาจทำแบบ manual โดยมีผู้ดูแลระบบคอยเฝ้ามอนิเตอร์ หรือทำแบบอัตโนมัติโดยใช้ซอฟต์แวร์ควบคุม

Transaction

  • Transaction คือ การป้องกันความผิดพลาดที่อาจเกิดขึ้นระหว่างการทำงาน โดยการทำงานจะยังไม่ส่งผลกระทบต่อข้อมูลจริง เพราะการทำงานอยู่ในเซสชั่น (transaction session) และหากเมื่อเกิดข้อผิดพลาดขึ้นก็สามารถ Rollback ได้ทำให้ไม่ส่งกระทบต่อข้อมูลจริง และไม่เกิดความเสียหายจากการทำงานได้

Process Monitor

  • Process Monitor คือ การติดตามการทำงานของ process ต่างๆ ภายในระบบหรือภายในเครื่อง ทำให้เห็นรายละเอียดต่างๆ (เช่น การใช้ซีพียู, หน่วยความจำ, ความคืบหน้าของการทำงาน ฯ) ของแต่ละ process ได้ หากมี process ใดทำงานไม่ชอบมาพากลอันอาจก่อให้เกิดข้อผิดพลาดได้ ผู้ดูแลระบบก็จะได้จัดการได้ทันท่วงทีก่อนปัญหาจะเกิดขึ้นจริง

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s