เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

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

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

วิธีการ จำกัด โซลูชันการตรวจสอบแอปพลิเคชัน EC2 ให้แคบลง

ขั้นตอนแรกในการค้นหาโซลูชันการตรวจสอบ EC2 ที่สมบูรณ์แบบของคุณควรเข้าใจความต้องการของคุณและความสามารถด้านเทคนิคของคุณเอง  โซลูชันการตรวจสอบนั้นไม่เหมือนกันทั้งหมด

คุณสนใจโซลูชันที่มีคุณสมบัติหลากหลายซึ่งตรวจสอบระบบที่หลากหลายหรือไม่? หรือสิ่งที่มุ่งเน้นไปที่ชุดหลักของระบบเช่นสภาพแวดล้อม EC2 ของคุณ?

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

และความอยากด้านเทคนิคของคุณในการติดตั้งและจัดการแอปพลิเคชันอื่นคืออะไร? คุณรักการเขียนสคริปต์หรือไม่? หรือคุณต้องการบางสิ่งที่เป็น“ set-it-and-forget-it”?

การค้นหา“ โซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน” บน Google จะแสดงผลลัพธ์ 1,170,000,000 ผลลัพธ์! ข้ามไปที่ตลาด Amazon AWS และคุณจะพบผลิตภัณฑ์ 453 รายการในหมวดหมู่ DevOps – การตรวจสอบ  การเข้าใจถึงความต้องการของคุณอย่างชัดเจนและความสามารถด้านเทคนิคของคุณเองจะช่วยให้การค้นหาของคุณแคบลง

การตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 ด้วย Amazon CloudWatch หรือโซลูชั่น APM อื่น ๆ

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

อีกทางเลือกหนึ่งคือให้คุณประเมินและรับหนึ่งในโซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน (“ APM”) ที่มีวางจำหน่ายทั่วไปในท้องตลาดเช่น AppDynamics, Datadog, Dynatrace หรือ New Relic  แต่โปรดคำนึงถึงความต้องการของคุณ  คุณต้องการตรวจสอบในวงกว้างแค่ไหน? และคุณต้องการจะทำอะไรกับข้อมูลนั้น? คุณพร้อมที่จะรับการแจ้งเตือนหรือไม่ และโปรดทราบว่าโซลูชัน APM จำนวนมากไม่ได้ช่วยอะไรคุณในการกู้คืนเกินกว่าที่จะระบุปัญหา  คุณยังต้องวางทุกอย่างเพื่อเริ่มบริการใหม่ด้วยตนเองหรือเริ่มต้นอินสแตนซ์ของคุณใหม่

ตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 โดยใช้ SIOS AppKeeper

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

SIOS AppKeeper เริ่มต้นเพียง US $ 40 ต่ออินสแตนซ์ต่อเดือน เราขอเชิญคุณดูวิดีโอสั้น ๆ นี้เพื่อดูว่าการติดตั้งและใช้ AppKeeper ง่ายแค่ไหน

เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

ซอฟต์แวร์ความพร้อมใช้งานสูงคือการประกันการหยุดทำงานของ SAP

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

6 ความท้าทายในการย้ายระบบคลาวด์ทั่วไป

ในฐานะวิศวกรซอฟต์แวร์สำหรับประสบการณ์ของลูกค้ากับ SIOS ฉันมักจะช่วย บริษัท ที่กำลังโยกย้ายสภาพแวดล้อมการจัดกลุ่มที่มีความพร้อมใช้งานสูงในสถานที่ไปยังระบบคลาวด์

การโอนย้ายระบบคลาวด์เป็นกระบวนการไม่ใช่ปลายทาง เมื่อเราดึงดูดลูกค้าที่เปลี่ยนไปใช้ระบบคลาวด์นั้นมักจะมาช้าในกระบวนการวางแผนซึ่งไม่เหมาะ แต่ไม่ผิดปกติในการย้ายระบบคลาวด์ ด้านล่างนี้คือความท้าทายในการย้ายระบบคลาวด์หกประการที่เราเห็นบ่อยเกินไป

1. เวลา – ทำความเข้าใจว่าต้องใช้เวลานานแค่ไหนในการถ่ายโอนข้อมูลไปยังคลาวด์

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

2. ค่าใช้จ่าย – ทำความเข้าใจกับความหมายของการถ่ายโอนข้อมูลภายในคลาวด์

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

3. การจำลองแบบระหว่างภูมิภาค

   การจำลองแบบระหว่างภูมิภาคนำเสนอความท้าทายอื่น: ประเภทการจำลองแบบ การจำลองแบบอะซิงโครนัสหรือซิงโครนัสภายใน AZ ถูกกำหนดโดยข้อกำหนด RTO และ RPO ของลูกค้า ไม่ว่าจะมีขนาดของอินสแตนซ์หรือไม่การจำลองข้อมูลจะเกิดความล่าช้าเมื่อข้ามระหว่างภูมิภาค SIOS แนะนำให้จำลองแบบอะซิงโครนัสระหว่างภูมิภาคเพื่อลดผลกระทบของเวลาแฝงนั้น Concurrency Labs ให้ข้อมูลที่ชาญฉลาดเกี่ยวกับเวลาแฝงระหว่างภูมิภาค EC2

   

4. องค์ประกอบของ Cloud Configuration

   สามารถปรับใช้อิมเมจระบบปฏิบัติการสำเร็จรูปจากคลาวด์ ความสะดวกสบายนี้มาพร้อมกับค่าใช้จ่ายซึ่งเป็นการแนะนำปัจจัยอีกประการหนึ่งให้กับการจัดการการกำหนดค่า บริการ cloud-init ที่รวมอยู่ในอิมเมจ SuSE Enterprise Linux ที่ปรับให้เหมาะกับคลาวด์สามารถลบที่อยู่ IP เสมือนที่ผู้ใช้กำหนด ไม่มีอะไรจะหยุด PoC เหมือนที่อยู่ IP เสมือนที่หายไปทุกสองนาที!

5. ความปลอดภัยบนคลาวด์

   ขนาดของคลาวด์คอมพิวติ้งมีความปลอดภัยมากกว่าธุรกิจที่สามารถจ่ายได้ในดาต้าเซ็นเตอร์ในสถานที่ ปริมาณงานบนคลาวด์ใช้ประโยชน์จากการรักษาความปลอดภัยที่ทันสมัยโดยที่ไม่รู้ตัว ตัวอย่างเช่นโดยค่าเริ่มต้น AWS EC2 อินสแตนซ์บล็อกการรับส่งข้อมูลใด ๆ ที่ไม่ได้ส่งหรือส่งไปยังอินสแตนซ์เอง นี่เป็นคุณสมบัติที่ยอดเยี่ยมสำหรับการรักษาความปลอดภัยเครือข่ายในคลาวด์ หากระบบต้องการ Network Address Translation (NAT) มาตรการรักษาความปลอดภัยเริ่มต้นของ EC2 จะทำให้ที่อยู่ IP ล้มเหลว การปิดใช้งานการตรวจสอบต้นทาง / ปลายทางจากคอนโซลจะช่วยแก้ปัญหา ขึ้นอยู่กับความคุ้นเคยของผู้ใช้กับ AWS ซึ่งอาจใช้เวลาระหว่างการคลิกไม่กี่ครั้งเพื่อรับการสนับสนุน การทำความเข้าใจกับรายละเอียดว่าระบบโต้ตอบในสภาพแวดล้อมเป็นกุญแจสำคัญในการย้ายระบบคลาวด์ที่ประสบความสำเร็จ

6. การทดสอบการยอมรับของผู้ใช้บนคลาวด์ (UAT)

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

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

-Harrison Howell วิศวกรซอฟต์แวร์สำหรับประสบการณ์ลูกค้า

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