อะไรคือกลยุทธ์ที่ดีในการทำให้เว็บไซต์ของฉันออนไลน์เมื่อ S3 ออฟไลน์

อะไรคือกลยุทธ์ที่ดีในการทำให้เว็บไซต์ของฉันออนไลน์เมื่อ S3 ออฟไลน์

หาก S3 US East 1 ออฟไลน์ฉันจะกำหนดค่าแอปของฉัน / กำหนดโครงสร้างเพื่อป้องกันไม่ให้ไซต์ทั้งหมดของฉันออฟไลน์ได้อย่างไร

อะไรคือกลยุทธ์ที่ดีที่สุดในการกระจายความเสี่ยงในสถานการณ์เช่นนี้?

ในเดือนมีนาคมปี 2015 Amazon AWS ประกาศว่าพวกเขาสนับสนุนการจำลองแบบ S3 ทั่วภูมิภาค เมื่อภูมิภาคหนึ่งใน S3 ออฟไลน์คุณสามารถให้บริการไฟล์จากมิเรอร์ของคุณในภูมิภาคอื่น

^{แหล่งที่มา: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

การฝึกฝนให้โครงสร้างพื้นฐานของคุณออนไลน์โดยทำการสลับไปยังภูมิภาคอื่นนั้นเป็นสิ่งที่ซับซ้อน แต่ S3 เป็นองค์ประกอบที่ค่อนข้างเล็กและเรียบง่าย Netflix มีบทความที่ยอดเยี่ยมเกี่ยวกับประสบการณ์ของพวกเขากับ Chaos Gorilla

นอกจากนี้ยังนำไปใช้กับการลดลงของบริการเช่นเวลาแฝงที่เพิ่มขึ้น ไม่ใช่แค่เมื่อบริการที่คุณพึ่งพานั้นออฟไลน์โดยสมบูรณ์ Netflix มีบทความเกี่ยวกับเรื่องนี้เช่นกัน: Chaos วิศวกรรมการอัพเกรด

สิ่งที่คุณต้องการคือความพร้อมใช้งานสูง ในการทำให้ระบบพร้อมใช้งานสูงคุณต้องมีสามสิ่ง:

1. กำจัดจุดล้มเหลวเดียว
2. กลไกการสลับจากจุดปลายไปยังจุดอื่น
3. วิธีการตรวจสอบความล้มเหลว

กำจัดจุดล้มเหลวเดียว

ในกรณีของ S3, จุด # 1 เป็น addressed เป็น Evgeny ชี้ให้เห็นโดยS3 จำลองแบบข้ามภูมิภาค

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

กลไกการสลับจากจุดปลายไปยังจุดอื่น

สำหรับ S3 นั่นหมายความว่าในกรณีที่ไฟดับคุณต้องการให้แอปพลิเคชันหยุดอ่านและเขียนจาก / ถึงที่เก็บข้อมูล A และใช้ที่ฝากข้อมูล B แทน

วิธีการบรรลุเป้าหมายนี้เท่าที่ฉันรู้นั้นขึ้นอยู่กับคุณในตอนนี้ บริการ AWS อื่น ๆ บางตัวให้การล้มเหลวแบบโปร่งใสอย่างสมบูรณ์ แต่ฉันไม่ทราบถึงสิ่งนี้สำหรับ S3 ในขณะนี้

มีหลายวิธีในการบรรลุเป้าหมายนี้ ตัวอย่างหนึ่งคือการใช้พร็อกซีที่จะกำหนดเส้นทางการรับส่งข้อมูลไปยังที่ฝากข้อมูลที่เหมาะสม ในระหว่างที่ไฟดับคุณจะต้องอัพเดต / เปลี่ยนพรอกซีเพื่อกำหนดเส้นทางทราฟฟิกไปยังที่ฝากข้อมูลที่ไม่ได้รับผลกระทบจากไฟดับ อีกตัวอย่างหนึ่งคือการทำให้การกำหนดค่าแอปพลิเคชันของคุณเป็นแบบไดนามิกและเก็บไว้ในที่เก็บคีย์ - ค่า หากแอปพลิเคชันอ่านที่เก็บ KV สำหรับคุณสมบัติที่ได้รับการปรับปรุงบ่อยครั้งเพียงพอคุณสามารถสลับตำแหน่งที่คุณอ่านและเขียนได้ (Spring Cloud มีการรองรับผู้ฟัง "EnvironmentChange" ตัวอย่างเช่น)

วิธีการตรวจสอบความล้มเหลว

ฉันคิดว่าเป็นเรื่องง่าย เพียงตั้งค่าห่วงการเขียน + อ่านและการแจ้งเตือนทันทีที่มีบางอย่างไม่ถูกต้อง :)

การปิดบันทึก

• หากใบสมัครของคุณเขียนถึงที่เก็บข้อมูลคุณต้องคิดว่าจะเกิดอะไรขึ้นในกรณีที่เกิดข้อผิดพลาด การเขียนทั้งหมดส่งไปยังที่ฝากข้อมูลปลายทาง (และคุณสามารถบอกได้) คุณสามารถอนุญาตให้เขียนไปยังที่ฝากข้อมูลปลายทาง (ทำให้เป็น "หลัก" ใหม่) ได้หรือไม่ การวางแผนอย่างรอบคอบจะหลีกเลี่ยงการแยกสมองหรือสถานการณ์การอัพเดทที่สูญหาย
• ขึ้นอยู่กับ SLA ของคุณคุณอาจต้องการให้คะแนน # 2 และ # 3 เป็นแบบอัตโนมัติหรือแบบอัตโนมัติ ที่ต้องมีการวางแผนเพิ่มเติมการใช้เครื่องมือและการทดสอบ แต่สคริปต์ที่เขียนขึ้นอย่างดีจะตอบสนองได้เร็วกว่าและคาดการณ์ได้ดีกว่าความสามารถของมนุษย์ (ความล้มเหลวยังมีนิสัยที่น่ารำคาญเกิดขึ้นในกลางดึก
• เป็นมูลค่าการกล่าวขวัญว่าแม้การจำลองแบบข้ามภูมิภาคไม่ได้ขจัดความล้มเหลวจุดเดียวอย่างสมบูรณ์ แน่นอนว่าถ้าภูมิภาคใดภาคหนึ่งล่มคุณก็จะได้รับความคุ้มครอง แต่จะเกิดอะไรขึ้นถ้าไฟดับ AWS ของสหรัฐฯเกิดขึ้น? สีฟ้าก็มีบางส่วน แต่เกิดดับทั่วโลกและหนึ่งในปี 2014 เช่นกัน