Optus ปรับปรุงประสบการณ์ของลูกค้าบรอดแบนด์และมือถือโดยใช้แพลตฟอร์มการวิเคราะห์ข้อมูลเครือข่ายบน AWS . ได้อย่างไร

เผยแพร่ซ้ำโดยเพลโต

ผู้ติดตาม: 0

นี่เป็นบล็อกโพสต์รับเชิญที่เขียนโดย Rajagopal Mahendran ผู้จัดการฝ่ายพัฒนาที่ Optus IT Innovation Team

Optus เป็นส่วนหนึ่งของกลุ่ม The Singtel ซึ่งดำเนินงานในภูมิภาคที่เติบโตเร็วที่สุดแห่งหนึ่งของโลกและมีพลวัตที่สุด โดยมีการดำเนินงานอยู่ใน 21 ประเทศ Optus ไม่เพียงแต่ให้บริการโทรคมนาคมหลักเท่านั้น แต่ยังให้บริการโซลูชันดิจิทัลที่หลากหลาย ซึ่งรวมถึงระบบคลาวด์ ความปลอดภัยทางไซเบอร์ และการโฆษณาดิจิทัลแก่องค์กรต่างๆ ตลอดจนความบันเทิงและบริการทางการเงินบนมือถือแก่ผู้บริโภคหลายล้านคน Optus ให้บริการสื่อสารเคลื่อนที่แก่ลูกค้ากว่า 10.4 ล้านราย และบริการบรอดแบนด์แก่บ้านและธุรกิจกว่า 1.1 ล้านแห่ง นอกจากนี้ Optus Sport ยังเชื่อมโยงแฟน ๆ เกือบ 1 ล้านคนเข้ากับเนื้อหาพรีเมียร์ลีก ฟุตบอลต่างประเทศ และฟิตเนส

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

ความท้าทาย

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

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

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

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

ข้อควรพิจารณาในการออกแบบ

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

เรามีข้อกำหนดด้านการทำงานและไม่เป็นไปตามข้อกำหนดดังต่อไปนี้:

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

ภาพรวมโซลูชัน

ด้วยเป้าหมายของแพลตฟอร์มและการพิจารณาการออกแบบ เราจึงตัดสินใจใช้บริการที่มีลำดับสูงกว่าและบริการแบบไร้เซิร์ฟเวอร์จาก AWS หากเป็นไปได้ เพื่อหลีกเลี่ยงค่าใช้จ่ายในการดำเนินงานที่ไม่จำเป็นสำหรับทีมของเราและมุ่งเน้นที่ความต้องการทางธุรกิจหลัก ซึ่งรวมถึงการใช้กลุ่มบริการ Kinesis สำหรับการนำเข้าและประมวลผลสตรีม AWS แลมบ์ดา สำหรับการประมวลผล; อเมซอน ไดนาโมดีบี, บริการฐานข้อมูลเชิงสัมพันธ์ของ Amazon (Amazon RDS) และ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) สำหรับการคงอยู่ของข้อมูล และ AWS ยืดหยุ่น Beanstalk และ Amazon API Gateway Amazon สำหรับแอปพลิเคชันและการให้บริการ API แผนภาพต่อไปนี้แสดงวิธีแก้ปัญหาโดยรวม

โซลูชันจะนำเข้าไฟล์บันทึกจากอุปกรณ์เครือข่ายของลูกค้าหลายพันเครื่อง (เราเตอร์ในบ้าน) ในช่วงเวลาที่กำหนดไว้ล่วงหน้า อุปกรณ์ของลูกค้าสามารถส่งคำขอ HTTP PUT และ POST ธรรมดาเพื่อโอนไฟล์บันทึกเท่านั้น ในการรับไฟล์เหล่านี้ เราใช้แอปพลิเคชัน Java ที่ทำงานในกลุ่ม Auto Scaling ของ อเมซอน อีลาสติก คอมพิวท์ คลาวด์ (Amazon EC2) อินสแตนซ์ หลังจากตรวจสอบเบื้องต้นแล้ว แอปพลิเคชั่นตัวรับจะทำการล้างข้อมูลและจัดรูปแบบ จากนั้นจะสตรีมไฟล์บันทึกไปที่ สตรีมข้อมูล Amazon Kinesis.

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

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

ข้อมูลเชิงลึกส่วนบุคคล – คำถามที่ตอบในหมวดนี้รวมถึง:
- อุปกรณ์ของลูกค้ารายหนึ่งพบข้อผิดพลาดกี่ครั้งในช่วง 15 นาทีที่ผ่านมา
- ข้อผิดพลาดล่าสุดคืออะไร?
- ปัจจุบันมีอุปกรณ์กี่เครื่องที่เชื่อมต่อที่บ้านลูกค้ารายหนึ่ง
- อัตราการถ่ายโอน/การรับที่อุปกรณ์ของลูกค้าบางเครื่องจับได้คือเท่าใด
ข้อมูลเชิงลึกพื้นฐาน – เกี่ยวกับกลุ่มหรือฐานผู้ใช้ทั้งหมด คำถามในหมวดหมู่นี้รวมถึง:
- มีอุปกรณ์ของลูกค้ากี่เครื่องที่แจ้งว่าบริการหยุดชะงักใน 24 ชั่วโมงที่ผ่านมา
- อุปกรณ์ (รุ่น) ประเภทใดพบข้อผิดพลาดบ่อยที่สุดในช่วง 6 เดือนที่ผ่านมา
- หลังจากอัพเดตแพตช์เมื่อคืนในกลุ่มอุปกรณ์ พวกเขาได้รายงานข้อผิดพลาดใดๆ หรือไม่? การบำรุงรักษาสำเร็จหรือไม่?

เลนบนสุดในสถาปัตยกรรมแสดงไปป์ไลน์ที่สร้างข้อมูลเชิงลึกแต่ละรายการ

การแมปแหล่งที่มาของเหตุการณ์ของฟังก์ชัน Lambda ได้รับการกำหนดค่าให้ใช้บันทึกจากสตรีมข้อมูล Kinesis ฟังก์ชันนี้จะอ่านเรกคอร์ด จัดรูปแบบ และจัดเตรียมตามข้อมูลเชิงลึกที่จำเป็น สุดท้าย จะเก็บผลลัพธ์ไว้ในตำแหน่ง Amazon S3 และยังอัปเดตตาราง DynamoDB ที่เก็บรักษาข้อมูลสรุปและข้อมูลเมตาของข้อมูลจริงที่จัดเก็บไว้ใน Amazon S3

ในการเพิ่มประสิทธิภาพการทำงาน เราได้กำหนดค่าตัววัดสองตัวในการแมปแหล่งที่มาของเหตุการณ์ Lambda:

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

สุดท้าย API ถูกจัดเตรียมผ่าน API Gateway และรันบนแอปพลิเคชัน Spring Boot ที่โฮสต์บน Elastic Beanstalk ในอนาคต เราอาจจำเป็นต้องรักษาสถานะระหว่างการเรียก API ซึ่งเป็นสาเหตุที่เราใช้ Elastic Beanstalk แทนแอปพลิเคชันแบบไร้เซิร์ฟเวอร์

เลนล่างสุดในสถาปัตยกรรมคือไปป์ไลน์ที่สร้างรายงานพื้นฐาน

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

ข้อมูลเชิงลึกจะถูกนำเสนอในแดชบอร์ดโดยใช้เว็บแอปพลิเคชันที่ทำงานบน Elastic Beanstalk

บทเรียนที่ได้รับ

การใช้รูปแบบแบบไร้เซิร์ฟเวอร์และบริการที่มีลำดับสูงกว่า โดยเฉพาะอย่างยิ่ง Lambda, Kinesis Data Streams, Kinesis Data Analytics และ DynamoDB ให้ความยืดหยุ่นอย่างมากในสถาปัตยกรรมของเรา และช่วยให้เราก้าวไปสู่ไมโครเซอร์วิสมากกว่างานแบทช์ขนาดใหญ่

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

โซลูชันนี้ยังช่วยให้เราสามารถปรับใช้ DevOps และวิธีการทำงานที่คล่องตัวมากขึ้น ในแง่ที่ว่าทีมเล็กๆ ทีมเดียวพัฒนาและใช้งานระบบ ซึ่งจะทำให้องค์กรมีความคล่องตัวและมีนวัตกรรมมากขึ้นในโดเมนนี้

เรายังได้ค้นพบเคล็ดลับทางเทคนิคบางประการผ่านหลักสูตรการพัฒนาและการผลิตซึ่งควรค่าแก่การแบ่งปัน:

ผลลัพธ์และผลประโยชน์

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

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

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

มองไปข้างหน้า

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

ความต้องการอีกด้านคือการบำรุงรักษาเชิงคาดการณ์: เราต้องการแนะนำแมชชีนเลิร์นนิงในไปป์ไลน์เหล่านี้ เพื่อช่วยขับเคลื่อนข้อมูลเชิงลึกได้เร็วและแม่นยำยิ่งขึ้นโดยใช้พอร์ตโฟลิโอของบริการ AWS Machine Learning

เกี่ยวกับผู้แต่ง

ราชาโกปาล มเหนทราน เป็นผู้จัดการฝ่ายพัฒนาของ Optus IT Innovation Team Mahendran มีประสบการณ์มากกว่า 14 ปีในองค์กรต่างๆ ที่ให้บริการแอปพลิเคชันระดับองค์กรตั้งแต่ระดับกลางไปจนถึงขนาดใหญ่มาก โดยใช้เทคโนโลยีที่ได้รับการพิสูจน์แล้วว่าล้ำหน้าในด้านบิ๊กดาต้า แอปพลิเคชันสตรีมข้อมูล แอปพลิเคชันมือถือ และแอปพลิเคชันบนคลาวด์ ความหลงใหลของเขาคือการขับเคลื่อนความคิดสร้างสรรค์โดยใช้เทคโนโลยีเพื่อชีวิตที่ดีขึ้น ในเวลาว่าง เขาชอบเดินป่าและว่ายน้ำ

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

มาซูดูร์ ราฮามาน ซาเยม เป็น Specialist Solution Architect สำหรับ Analytics ที่ AWS เขาทำงานร่วมกับลูกค้าของ AWS เพื่อให้คำแนะนำและความช่วยเหลือด้านเทคนิคเกี่ยวกับโครงการข้อมูลและการวิเคราะห์ ช่วยปรับปรุงคุณค่าของโซลูชันเมื่อใช้ AWS เขาหลงใหลเกี่ยวกับระบบแบบกระจาย เขาชอบอ่านโดยเฉพาะหนังสือการ์ตูนคลาสสิก