ย้ายไปยังคลาวด์? ลำดับความสำคัญ DevOps ของคุณควรเปลี่ยนไปเมื่อคุณย้ายไปที่ Amazon EC2

บริษัท ส่วนใหญ่ที่ย้ายไปใช้ระบบคลาวด์หรือสร้างแอปพลิเคชัน“ ระบบคลาวด์เนทีฟ” กำลังดำเนินการดังกล่าวด้วย Amazon Web Services (AWS)AWS มีข้อได้เปรียบด้านต้นทุนและฟังก์ชันการทำงานมากมายบริษัท ที่ใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับการปฏิบัติงานของนักพัฒนาตามมาตรฐานอุตสาหกรรม (“ DevOps”) สำหรับการตรวจสอบและจัดการสภาพแวดล้อมภายในองค์กรมักถามตัวเองว่าพวกเขาปรับตัวให้เข้ากับสภาพแวดล้อมและแอปพลิเคชันระบบคลาวด์ใหม่อย่างไร

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

ลำดับความสำคัญของ DevOps ในระบบคลาวด์?เหมือน. แต่แตกต่างกัน.

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

บริษัท ต่างๆที่ย้ายไปยัง Amazon AWS สามารถใช้ประโยชน์จากต้นทุนและทรัพยากรกำลังคนที่ลดลงเมื่อต้องจัดหาฮาร์ดแวร์การจัดเตรียมและการบำรุงรักษาแต่คุณต้องคำนึงว่าเมื่อคุณตัดสินใจโฮสต์แอปพลิเคชันบน Amazon EC2 สิ่งใดก็ตามที่อยู่เหนือเลเยอร์ระบบปฏิบัติการถือเป็นความรับผิดชอบของคุณ

เมื่อพูดถึงการสำรองข้อมูล / การรับประกันความพร้อมใช้งาน / มาตรการรักษาความปลอดภัย ฯลฯ สำหรับสภาพแวดล้อม Amazon EC2 ของคุณลำดับความสำคัญจะเหมือนกับว่าเป็นแอปพลิเคชันในองค์กร และ Amazon มีเครื่องมือและฟังก์ชันดั้งเดิมบางอย่างแต่คุณต้องตัดสินใจว่าเหมาะสมกับความต้องการหรือไม่

ความปลอดภัยการสำรองข้อมูล … คุณต้องรู้อะไรบ้างเมื่อจัดการสภาพแวดล้อม Amazon AWS

ดังนั้นข้อควรพิจารณาเฉพาะของ AWS ที่คุณต้องคำนึงถึงเมื่อย้ายไปใช้ Amazon EC2 คืออะไรแล้วเครื่องมือที่เหมาะกับคุณคืออะไร?เวลาที่คุณลงทุนล่วงหน้าในการออกแบบแอปพลิเคชันของคุณและวิธีการปรับใช้และจัดการแอปพลิเคชันจะคุ้มค่า

สิ่งแรกที่คุณควรพิจารณาคือวิธีที่คุณจะรักษาความปลอดภัยให้กับแอปพลิเคชัน Amazon EC2 ของคุณการออกแบบเครือข่ายเช่น“ พอร์ตที่จะเปิด” และ“ จากที่ใดที่จะอนุญาตให้เข้าถึง” จะต้องได้รับการพิจารณาในลักษณะเดียวกับแอปพลิเคชันในองค์กรของคุณสิ่งเหล่านี้สามารถกำหนดค่าใน AWS โดยใช้กลุ่มความปลอดภัยและ ACL ของเครือข่าย (รายการควบคุมการเข้าถึง)

คุณสามารถใช้ฟังก์ชัน AWS Trusted Advisor * ซึ่งจะตรวจสอบสภาพแวดล้อม AWS ของคุณโดยอัตโนมัติและชี้ให้เห็นว่ามีการตั้งค่าตามการตั้งค่าที่แนะนำหรือไม่ทำให้สามารถตรวจสอบสภาพแวดล้อม AWS ของ บริษัท ของคุณสำหรับปัญหาด้านความปลอดภัยเราขอแนะนำให้ตรวจสอบกับ AWS Trusted Advisor ทั้งในเวลาที่ใช้งานและเป็นระยะ

ความปลอดภัยที่สำคัญอีกประการหนึ่งคือการจัดการการรับรองความถูกต้องและสิทธิ์การเข้าถึงAWS รวมสิ่งเหล่านี้ทั้งหมดไว้ใน AWS Identity and Access Management (AWS IAM)นอกเหนือจากการควบคุมว่าใครสามารถเข้าถึงอินสแตนซ์ EC2 ใดได้แล้วคุณยังสามารถใช้ AWS IAM เพื่อตั้งค่าสิทธิ์การเข้าถึงจากอินสแตนซ์ EC2 ไปยังทรัพยากรอื่น ๆ (เช่น DBs) เป็นต้นเมื่อคุณย้ายไปยัง AWS แล้วสิ่งแรกที่คุณต้องทำ คือการตั้งค่าบัญชีและข้อ จำกัด การเข้าถึงอย่างถูกต้องใน AWS IAM

สิ่งที่ต้องพิจารณาต่อไปคือ“ ฉันจะสำรองข้อมูลแอปพลิเคชันของฉันใน Amazon EC2 ได้อย่างไร” Amazon EC2 ให้ความสามารถในการถ่ายภาพรวมซึ่งช่วยให้คุณสามารถทำได้นอกจากนี้การใช้“ Amazon Data Lifecycle Manager” ทำให้ง่ายต่อการตั้งค่าสแนปชอตตามระยะเวลารวมทั้งการสำรองข้อมูลเพิ่มเติมไฟล์สแน็ปช็อตจะถูกเก็บไว้ในบริการจัดเก็บข้อมูล Amazon S3คุณจะถูกเรียกเก็บเงินตามความจุดังนั้นคุณต้องระวังปริมาณข้อมูลที่คุณมีและตั้งค่าเช่น "ลดความจุโดยการสำรองข้อมูลส่วนเพิ่ม" และ "ลบจากข้อมูลเก่า"

"ความพร้อมใช้งาน" จะต้องพิจารณาล่วงหน้า กุญแจสำคัญคือการใช้งานระบบตามระดับความสำคัญของระบบ

ข้อพิจารณาสุดท้ายคือความพร้อมใช้งานด้วยแอปพลิเคชัน Amazon EC2 รวมถึงแอปพลิเคชันที่มีอยู่ในองค์กรคุณควรพิจารณาระดับความพร้อมใช้งานที่จำเป็นตามต้นทุนและความสำคัญของระบบ อย่างไรก็ตามหากคุณใช้ฟังก์ชันการปรับใช้หลาย AZ ของ Amazon คุณสามารถระบุการกำหนดค่าที่ซ้ำซ้อนระหว่างศูนย์ข้อมูลต่างๆได้อย่างไรก็ตามการใช้ Multi-AZ มีค่าใช้จ่ายมากกว่าการใช้การกำหนดค่า AZ เดียว (แม้ว่าจะไม่มากเท่ากับว่าคุณมีระบบในองค์กรซ้ำซ้อน)เมื่อออกแบบแอปพลิเคชันของคุณคุณต้องพิจารณาว่าต้องใช้ Multi-AZ หรือไม่และคุณควรลงทุนในความพร้อมใช้งานเท่าใด

หากคุณไม่ได้ลงทุนใน Failover อย่างน้อยคุณควรตรวจสอบแอปพลิเคชันของคุณและวางแผนว่าจะกู้คืนแอปพลิเคชันอย่างไรเมื่อเกิดปัญหาการหยุดทำงาน คุณสามารถใช้ Amazon CloudWatch เพื่อตรวจสอบรายการทั่วไปเช่น CPU หน่วยความจำและดิสก์ได้อย่างง่ายดายและคุณยังสามารถตั้งโปรแกรมฟังก์ชัน Amazon EC2 Auto Recovery เพื่อกู้คืนอินสแตนซ์โดยอัตโนมัติเมื่อเกิดข้อผิดพลาดใน EC2

หากแอปพลิเคชันของคุณมีความสำคัญต่อภารกิจคุณจะต้องลงทุนเพิ่มเติมในความพร้อมใช้งานคุณควรพิจารณาโซลูชันของบุคคลที่สามที่ยอดเยี่ยมมากมายที่นำเสนอฟังก์ชันการทำงานที่มีคุณค่าให้กับชุมชน AWSทางเลือกหนึ่งคือ SIOS AppKeeper ซึ่งเป็นโซลูชันที่ง่ายต่อการกำหนดค่าและใช้งานที่ตรวจสอบอินสแตนซ์ Amazon EC2 ของคุณและรีสตาร์ทบริการโดยอัตโนมัติหรือรีบูตอินสแตนซ์หากประสบความล้มเหลวของระบบนี่คือวิดีโอสั้น ๆ เกี่ยวกับวิธีการทำงานของ AppKeeper

ในขณะที่การย้ายไปยังระบบคลาวด์สำหรับแอปพลิเคชันของคุณมีเหตุผลมากมาย แต่คุณไม่สามารถละทิ้งแนวทางปฏิบัติที่ดีที่สุดของ DevOpsAmazon AWS มีชุดฟังก์ชันและเครื่องมือมากมายให้คุณ แต่คุณยังต้องรับผิดชอบหลักในการรักษาความปลอดภัยการสำรองข้อมูลและความพร้อมใช้งานของแอปพลิเคชันของคุณวิธีที่คุณทำขึ้นอยู่กับทักษะของคุณและความสำคัญของแอปพลิเคชัน

เราขอเชิญคุณเข้าร่วมกับลูกค้าหลายร้อยรายที่ใช้ประโยชน์จาก AppKeeper เพื่อลดเวลาหยุดทำงานของ Amazon EC2 โดยสมัครทดลองใช้บริการฟรี 14 วัน

* หมายเหตุ: ในการใช้ AWS Trusted Advisor จำเป็นต้องมีสัญญาสำหรับการสนับสนุนทางธุรกิจหรือสูงกว่า

ทำซ้ำโดยได้รับอนุญาตจาก SIOS

ขยายเมตริกความพร้อมใช้งานสูงของคุณ

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

แดกดันในระบบความพร้อมใช้งานสูงและการกู้คืนความเสียหาย (HA / DR) มีเมตริกบางอย่างที่ไม่ได้รับความสนใจเพียงพอ

นี่คือเมตริกความพร้อมใช้งานสูงอื่น ๆ อีกแปดรายการที่คุณควรดูเพื่อจัดการสภาพแวดล้อมของคุณ:

1.  การแจ้งเตือนความปลอดภัย

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

2. การเชื่อมต่อที่ไม่ได้ใช้งาน

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

3. แบบสอบถามคำสั่งหรืองานที่ใช้งานมานาน

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

4. ดิสก์ IO

โดยทั่วไป Disk IO หมายถึงการดำเนินการอินพุต / เอาต์พุตของระบบที่เกี่ยวข้องกับกิจกรรมของดิสก์ การวัดดิสก์ I / O สามารถช่วยระบุปัญหาคอขวดการกำหนดค่าฮาร์ดแวร์ที่ไม่ดีดิสก์ที่มีขนาดไม่เหมาะสมหรือเค้าโครงดิสก์ที่ได้รับการปรับแต่งไม่ดีสำหรับปริมาณงานที่กำหนด  การตรวจสอบดิสก์ I / O สามารถช่วยบอกคุณได้ว่าคิวรีที่รันเป็นเวลานานเป็นฟังก์ชันของไวยากรณ์ sql ที่ไม่ดีแอปพลิเคชันที่เข้ารหัสไม่ดีหรือปัญหาเวลาแฝงและการเข้าถึงหรือไม่

5. หน่วยความจำ

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

6. พื้นที่ดิสก์

ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าครั้งหนึ่งฉันเคยมีประสบการณ์ที่โชคร้ายในการตื่น แต่เช้าเพื่อโทรฉุกเฉิน  ลูกค้าประสบปัญหาระบบการผลิตล่มหลังจากไฟฟ้าดับ  เมื่อพยายามรีสตาร์ทระบบแอปพลิเคชันที่ได้รับการป้องกันไม่สามารถเริ่มทำงานได้  หลังจากตรวจสอบบันทึกข้อผิดพลาดอย่างรวดเร็วเป็นที่ชัดเจนว่ารูทไดรฟ์เต็ม 100%  แอปพลิเคชันไม่สามารถเขียนลงในระบบไฟล์ใด ๆ  การตรวจสอบพื้นที่ดิสก์มีให้ใช้งานในหลายรูปแบบและหลายวิธีและการมีเป็นเมตริกสามารถป้องกันปัญหาที่ไม่จำเป็นและการแย่งชิงในนาทีสุดท้ายที่มีราคาแพงเพื่อเพิ่ม .

7. ข้อผิดพลาดและการแจ้งเตือน

ข้อผิดพลาดการแจ้งเตือนและข้อความการกู้คืนในบันทึกเป็นอีกหนึ่งเมตริกที่ควรพิจารณา  โซลูชันความพร้อมใช้งานของคุณอาจทำให้ลูกค้าของคุณออนไลน์และมีความสุข แต่ก็อาจปกปิดปัญหาที่คุณจะต้องดำเนินการในไม่ช้า  การเพิ่มการตรวจสอบบันทึกสำหรับข้อความ FATAL, PANIC และคีย์ ERROR สามารถช่วยคุณระบุปัญหาที่โซลูชันความพร้อมใช้งานของคุณมักจะกู้คืนเช่นฐานข้อมูลล่มแอปพลิเคชันตื่นตระหนกหรือการทิ้งข้อมูลหลักหรือข้อผิดพลาดร้ายแรงที่ต้องรีสตาร์ทเย็น

8. หมายเลขการกู้คืน

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

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

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า