เหตุใดบริษัทอย่าง MegaFon จึงต้องใช้ Tarantool ในการเรียกเก็บเงิน จากภายนอกดูเหมือนว่าผู้ขายมักจะมา นำกล่องขนาดใหญ่มา เสียบปลั๊กเข้ากับเต้ารับ - เท่านี้ก็เรียกเก็บเงินแล้ว! ครั้งหนึ่งเคยเป็นเช่นนี้ แต่ตอนนี้มันคร่ำครึ และไดโนเสาร์เหล่านี้ก็ได้สูญพันธุ์ไปแล้วหรือกำลังจะสูญพันธุ์ไปแล้ว ในตอนแรกการเรียกเก็บเงินเป็นระบบการออกใบแจ้งหนี้ - เครื่องนับหรือเครื่องคิดเลข ในโทรคมนาคมสมัยใหม่นี่คือ ระบบอัตโนมัติตลอดวงจรชีวิตของการโต้ตอบกับสมาชิกตั้งแต่การสรุปสัญญาจนถึงการยกเลิกรวมถึงการเรียกเก็บเงินแบบเรียลไทม์ การรับชำระเงิน และอื่นๆ อีกมากมาย การเรียกเก็บเงินในบริษัทโทรคมนาคมก็เหมือนกับหุ่นยนต์ต่อสู้ มีขนาดใหญ่ ทรงพลัง และเต็มไปด้วยอาวุธ
Tarantool เกี่ยวอะไรกับมัน? พวกเขาจะพูดถึงมัน โอเล็ก อีฟเลฟ и อันเดรย์ คยาเซฟ. Oleg เป็นหัวหน้าสถาปนิกของบริษัท ด้วยประสบการณ์มากมายในการทำงานในบริษัทต่างประเทศ Andrey ดำรงตำแหน่งผู้อำนวยการฝ่ายระบบธุรกิจ จากสำเนารายงานของพวกเขาเมื่อ คุณจะได้เรียนรู้ว่าทำไมการวิจัยและพัฒนาจึงเป็นสิ่งจำเป็นในองค์กรต่างๆ Tarantool คืออะไร ความอับจนของการปรับขนาดแนวตั้งและโลกาภิวัตน์กลายเป็นข้อกำหนดเบื้องต้นสำหรับการปรากฏของฐานข้อมูลนี้ในบริษัทอย่างไร เกี่ยวกับความท้าทายทางเทคโนโลยี การเปลี่ยนแปลงทางสถาปัตยกรรม และวิธีที่เทคโนโลยีของ MegaFon มีความคล้ายคลึงกับ Netflix , กูเกิล และอเมซอน
โครงการ "การเรียกเก็บเงินแบบรวม"
โครงการที่เป็นปัญหามีชื่อว่า "Unified Billing" ที่นี่คือที่ Tarantool แสดงให้เห็นคุณสมบัติที่ดีที่สุด
การเติบโตของผลผลิตของอุปกรณ์ระดับไฮเอนด์ไม่ได้ทันกับการเติบโตของฐานสมาชิกและการเติบโตของจำนวนบริการ คาดว่าจำนวนสมาชิกและบริการจะเพิ่มขึ้นอีกเนื่องจาก M2M, IoT และฟีเจอร์สาขาที่นำไปสู่ เพื่อการเสื่อมสภาพของเวลาในการออกสู่ตลาด บริษัทตัดสินใจสร้างระบบธุรกิจแบบครบวงจรด้วยสถาปัตยกรรมโมดูลาร์ระดับโลกที่มีเอกลักษณ์ แทนที่จะเป็นระบบการเรียกเก็บเงินที่แตกต่างกัน 8 ระบบในปัจจุบัน
MegaFon คือแปดบริษัทในหนึ่งเดียว. ในปี 2009 การปรับโครงสร้างองค์กรเสร็จสมบูรณ์: สาขาต่างๆ ทั่วรัสเซียได้รวมเข้าด้วยกันเป็นบริษัทเดียวคือ MegaFon OJSC (ปัจจุบันคือ PJSC) ดังนั้นบริษัทจึงมีระบบการเรียกเก็บเงิน 8 ระบบพร้อมโซลูชัน "แบบกำหนดเอง" คุณลักษณะของสาขาและโครงสร้างองค์กร ไอที และการตลาดที่แตกต่างกัน
ทุกอย่างเรียบร้อยดีจนกระทั่งเราต้องเปิดตัวผลิตภัณฑ์ของรัฐบาลกลางทั่วไปหนึ่งรายการ มีปัญหามากมายเกิดขึ้นที่นี่: สำหรับบางคนจะมีการปัดเศษภาษีขึ้นสำหรับบางคนปัดเศษลงและสำหรับคนอื่น ๆ - ขึ้นอยู่กับค่าเฉลี่ยเลขคณิต มีช่วงเวลาดังกล่าวหลายพันครั้ง
แม้ว่าระบบการเรียกเก็บเงินจะมีเพียงเวอร์ชันเดียว มีซัพพลายเออร์เพียงรายเดียว แต่การตั้งค่าก็แตกต่างกันมากจนต้องใช้เวลานานในการรวบรวม เราพยายามลดจำนวนลง และพบปัญหาที่สองที่หลายบริษัทคุ้นเคย
การปรับขนาดแนวตั้ง. แม้แต่ฮาร์ดแวร์ที่เจ๋งที่สุดในเวลานั้นก็ไม่สามารถตอบสนองความต้องการได้ เราใช้อุปกรณ์ของ Hewlett-Packard จากกลุ่มผลิตภัณฑ์ Superdome Hi-End แต่ไม่สามารถตอบสนองความต้องการของสาขาทั้งสองได้ ฉันต้องการการปรับขนาดแนวนอนโดยไม่ต้องมีต้นทุนการดำเนินงานและเงินลงทุนจำนวนมาก
ความคาดหวังการเติบโตของจำนวนสมาชิกและบริการ. ที่ปรึกษาได้นำเรื่องราวเกี่ยวกับ IoT และ M2M มาสู่โลกโทรคมนาคมมาเป็นเวลานาน: ถึงเวลาที่โทรศัพท์และเตารีดทุกเครื่องจะมีซิมการ์ด และอีกสองอันอยู่ในตู้เย็น วันนี้เรามีสมาชิกจำนวนหนึ่ง แต่ในอนาคตอันใกล้นี้จะมีสมาชิกอีกมากมาย
ความท้าทายทางเทคโนโลยี
เหตุผลสี่ประการนี้กระตุ้นให้เราเปลี่ยนแปลงอย่างจริงจัง มีตัวเลือกระหว่างการอัพเกรดระบบและการออกแบบตั้งแต่เริ่มต้น เราคิดอยู่นาน ตัดสินใจอย่างจริงจัง ทำการประมูล ด้วยเหตุนี้ เราจึงตัดสินใจออกแบบตั้งแต่เริ่มต้น และเผชิญกับความท้าทายที่น่าสนใจ นั่นคือความท้าทายทางเทคโนโลยี
ความสามารถในการปรับขนาด
ถ้าเป็นเมื่อก่อนสมมุติว่าสมมุติ 8 บิลสำหรับสมาชิก 15 ล้านรายและตอนนี้มันควรจะได้ผลแล้ว สมาชิก 100 ล้านรายและอีกมากมาย - ภาระมีลำดับความสำคัญสูงกว่า
เราเทียบเคียงได้กับผู้เล่นอินเทอร์เน็ตรายใหญ่อย่าง Mail.ru หรือ Netflix
แต่การเคลื่อนไหวเพิ่มเติมเพื่อเพิ่มปริมาณการใช้งานและฐานสมาชิกได้สร้างความท้าทายที่สำคัญสำหรับเรา
ภูมิศาสตร์ของประเทศอันกว้างใหญ่ของเรา
ระหว่างคาลินินกราดและวลาดิวอสต็อก 7500 กม. และ 10 โซนเวลา. ความเร็วแสงมีจำกัด และที่ระยะทางดังกล่าวความล่าช้าก็มีนัยสำคัญอยู่แล้ว 150 มิลลิวินาทีบนช่องสัญญาณออปติคอลที่ทันสมัยที่สุดนั้นมากเกินไปสำหรับการเรียกเก็บเงินแบบเรียลไทม์ โดยเฉพาะอย่างยิ่งเมื่อขณะนี้อยู่ในระบบโทรคมนาคมในรัสเซีย นอกจากนี้ คุณต้องอัปเดตภายในหนึ่งวันทำการ และด้วยเขตเวลาที่แตกต่างกัน ปัญหานี้จะเกิดขึ้น
เราไม่เพียงแค่ให้บริการโดยเสียค่าธรรมเนียมการสมัครสมาชิกเท่านั้น แต่ยังมีอัตราภาษี แพ็คเกจ และตัวแก้ไขต่างๆ ที่ซับซ้อนอีกด้วย เราไม่เพียงต้องอนุญาตหรือปฏิเสธผู้สมัครสมาชิกเท่านั้น แต่ยังให้โควต้าบางอย่างแก่เขา - คำนวณการโทรและการดำเนินการแบบเรียลไทม์เพื่อไม่ให้เขาสังเกตเห็น
ความอดทนต่อความผิดพลาด
นี่คืออีกด้านหนึ่งของการรวมศูนย์
หากเรารวบรวมสมาชิกทั้งหมดไว้ในระบบเดียว เหตุการณ์ฉุกเฉินและภัยพิบัติใดๆ ก็ตามจะถือเป็นหายนะสำหรับธุรกิจ ดังนั้นเราจึงออกแบบระบบในลักษณะที่จะขจัดผลกระทบจากอุบัติเหตุที่มีต่อฐานสมาชิกทั้งหมด
นี่เป็นผลสืบเนื่องมาจากการปฏิเสธที่จะขยายขนาดในแนวตั้งอีกครั้ง เมื่อเราขยายขนาดในแนวนอน เราได้เพิ่มจำนวนเซิร์ฟเวอร์จากหลักร้อยเป็นพัน จำเป็นต้องได้รับการจัดการและสับเปลี่ยนกันได้ สำรองข้อมูลโครงสร้างพื้นฐานด้านไอทีโดยอัตโนมัติ และกู้คืนระบบแบบกระจาย
เราเผชิญกับความท้าทายที่น่าสนใจเช่นนี้ เราออกแบบระบบ และในขณะนั้นเราพยายามค้นหาแนวทางปฏิบัติที่ดีที่สุดในโลกเพื่อตรวจสอบว่าเรามีแนวโน้มมากน้อยเพียงใด เราติดตามเทคโนโลยีขั้นสูงมากเพียงใด
ประสบการณ์โลก
น่าแปลกที่เราไม่พบข้อมูลอ้างอิงแม้แต่รายการเดียวในโทรคมนาคมทั่วโลก
ยุโรปลดลงในแง่ของจำนวนสมาชิกและขนาด สหรัฐอเมริกา - ในแง่ของความคงที่ของภาษี เราดูบางแห่งในจีน และพบบางแห่งในอินเดีย และจ้างผู้เชี่ยวชาญจาก Vodafone India
เพื่อวิเคราะห์สถาปัตยกรรม เราได้รวบรวมดรีมทีมที่นำโดย IBM ซึ่งเป็นสถาปนิกจากสาขาต่างๆ คนเหล่านี้สามารถประเมินสิ่งที่เรากำลังทำอยู่ได้อย่างเพียงพอและนำความรู้บางอย่างมาสู่สถาปัตยกรรมของเรา
ขนาด
ตัวเลขเล็กน้อยสำหรับภาพประกอบ
เราออกแบบระบบให้ สมาชิก 80 ล้านราย โดยมีทุนสำรองหนึ่งพันล้าน. นี่คือวิธีที่เราลบเกณฑ์ในอนาคต นี่ไม่ใช่เพราะว่าเรากำลังจะยึดครองจีน แต่เป็นเพราะการโจมตีของ IoT และ M2M
ประมวลผลเอกสาร 300 ล้านรายการแบบเรียลไทม์. แม้ว่าเราจะมีสมาชิก 80 ล้านราย แต่เราทำงานร่วมกับทั้งผู้มีโอกาสเป็นลูกค้าและผู้ที่ทิ้งเราไปหากเราต้องการรวบรวมลูกหนี้ ดังนั้นปริมาณจริงจึงมีมากกว่าอย่างเห็นได้ชัด
ธุรกรรม 2 พันล้าน ยอดคงเหลือเปลี่ยนแปลงทุกวัน ได้แก่ การชำระเงิน การเรียกเก็บเงิน การโทร และกิจกรรมอื่น ๆ ข้อมูล 200 TB กำลังเปลี่ยนแปลงอย่างต่อเนื่อง,เปลี่ยนช้าลงหน่อย ข้อมูล 8 PBและนี่ไม่ใช่การเก็บถาวร แต่เป็นข้อมูลสดในการเรียกเก็บเงินครั้งเดียว ขนาดตามศูนย์ข้อมูล - เซิร์ฟเวอร์ 5 แห่งใน 14 ไซต์.
กองเทคโนโลยี
เมื่อเราวางแผนสถาปัตยกรรมและเริ่มประกอบระบบ เราได้นำเข้าเทคโนโลยีที่น่าสนใจและล้ำสมัยที่สุด ผลลัพธ์ที่ได้คือกลุ่มเทคโนโลยีที่ผู้เล่นอินเทอร์เน็ตและองค์กรต่างๆ คุ้นเคยซึ่งสร้างระบบที่มีภาระงานสูง
สแต็กนั้นคล้ายกับสแต็คของผู้เล่นหลักรายอื่น: Netflix, Twitter, Viber ประกอบด้วยองค์ประกอบ 6 ส่วน แต่เราต้องการย่อให้สั้นลงและรวมเข้าด้วยกัน
ความยืดหยุ่นเป็นสิ่งที่ดี แต่ในองค์กรขนาดใหญ่ ไม่มีทางใดหากปราศจากการรวมเป็นหนึ่ง
เราจะไม่เปลี่ยน Oracle เดียวกันเป็น Tarantool ในความเป็นจริงของบริษัทขนาดใหญ่ นี่คือโลกในอุดมคติหรือสงครามครูเสดที่กินเวลานาน 5-10 ปีโดยที่ผลลัพธ์ไม่ชัดเจน แต่สามารถแทนที่ Cassandra และ Couchbase ด้วย Tarantool ได้อย่างง่ายดาย และนั่นคือสิ่งที่เรามุ่งมั่น
ทำไมต้องทารันทูล?
มีเกณฑ์ง่ายๆ 4 ข้อว่าทำไมเราถึงเลือกฐานข้อมูลนี้
ความเร็ว. เราทำการทดสอบโหลดบนระบบอุตสาหกรรม MegaFon Tarantool ชนะ - แสดงให้เห็นประสิทธิภาพที่ดีที่สุด
นี่ไม่ได้เป็นการบอกว่าระบบอื่นไม่ตรงกับความต้องการของ MegaFon โซลูชันหน่วยความจำในปัจจุบันมีประสิทธิภาพมากจนมีปริมาณสำรองของบริษัทมากเกินพอ แต่เราสนใจที่จะติดต่อกับผู้นำ ไม่ใช่กับคนที่ล้าหลัง รวมถึงใน Load Test ด้วย
Tarantool ครอบคลุมความต้องการของบริษัทแม้ในระยะยาว
ต้นทุนการเป็นเจ้าของ. การสนับสนุน Couchbase บนวอลุ่ม MegaFon มีค่าใช้จ่ายมหาศาล แต่ด้วย Tarantool สถานการณ์ก็น่าพึงพอใจกว่ามาก และพวกมันก็คล้ายกันในด้านการใช้งาน
คุณสมบัติที่ดีอีกประการหนึ่งที่มีอิทธิพลเล็กน้อยต่อการเลือกของเราก็คือ Tarantool ทำงานได้ดีกับหน่วยความจำมากกว่าฐานข้อมูลอื่น เขาแสดงให้เห็น ประสิทธิภาพสูงสุด.
ความเชื่อถือได้. MegaFon ลงทุนในความน่าเชื่อถือ อาจจะมากกว่าใครๆ ดังนั้นเมื่อเราดูที่ Tarantool เราก็ตระหนักว่าเราต้องทำให้มันตรงตามความต้องการของเรา
เราลงทุนทั้งเวลาและการเงิน และร่วมกับ Mail.ru เราได้สร้างเวอร์ชันสำหรับองค์กร ซึ่งขณะนี้ใช้ในบริษัทอื่นๆ หลายแห่ง
Tarantool-enterprise ทำให้เราพึงพอใจอย่างยิ่งในแง่ของความปลอดภัย ความน่าเชื่อถือ และการบันทึก
หุ้นส่วน
สิ่งที่สำคัญที่สุดสำหรับฉันคือ ติดต่อโดยตรงกับผู้พัฒนา. นี่คือสิ่งที่คนจาก Tarantool ติดสินบน
หากคุณมาหาผู้เล่น โดยเฉพาะอย่างยิ่งผู้ที่ทำงานกับลูกค้าหลัก และบอกว่าคุณต้องการฐานข้อมูลเพื่อทำสิ่งนี้ สิ่งนี้ และสิ่งนี้ เขามักจะตอบว่า:
- โอเค วางข้อกำหนดไว้ที่ด้านล่างของกองนั้น - สักวันหนึ่ง เราคงจะบรรลุข้อกำหนดเหล่านั้น
หลายคนมีแผนงานในอีก 2-3 ปีข้างหน้า และแทบจะเป็นไปไม่ได้เลยที่จะบูรณาการเข้ากับที่นั่น แต่นักพัฒนาของ Tarantool หลงใหลในความเปิดกว้างของพวกเขา และไม่เพียงแต่จาก MegaFon เท่านั้น และปรับระบบให้เข้ากับลูกค้าด้วย มันเจ๋งและเราชอบมันมาก
ที่เราใช้ Tarantool
เราใช้ Tarantool ในหลายองค์ประกอบ คนแรกอยู่ในนักบินซึ่งเราทำบนระบบไดเร็กทอรีที่อยู่ ครั้งหนึ่งฉันอยากให้มันเป็นระบบที่คล้ายกับ Yandex.Maps และ Google Maps แต่มันกลับแตกต่างออกไปเล็กน้อย
ตัวอย่างเช่น แค็ตตาล็อกที่อยู่ในอินเทอร์เฟซการขาย บน Oracle การค้นหาที่อยู่ที่ต้องการจะใช้เวลา 12-13 วินาที - ตัวเลขอึดอัด เมื่อเราเปลี่ยนมาใช้ Tarantool แทนที่ Oracle ด้วยฐานข้อมูลอื่นในคอนโซล และทำการค้นหาแบบเดียวกัน เราจะได้รับความเร็วเพิ่มขึ้น 200 เท่า! เมืองปรากฏขึ้นหลังตัวอักษรตัวที่สาม ตอนนี้เรากำลังปรับอินเทอร์เฟซเพื่อให้สิ่งนี้เกิดขึ้นหลังจากอันแรก อย่างไรก็ตาม ความเร็วในการตอบสนองแตกต่างอย่างสิ้นเชิง - เป็นมิลลิวินาทีแทนที่จะเป็นวินาที
แอปพลิเคชั่นที่สองเป็นธีมยอดนิยมที่เรียกว่าไอทีสองความเร็ว. เนื่องจากที่ปรึกษาจากทุกมุมบอกว่าองค์กรควรไปที่นั่น
มีชั้นโครงสร้างพื้นฐาน ด้านบนมีโดเมน เช่น ระบบการเรียกเก็บเงิน เช่น โทรคมนาคม ระบบองค์กร การรายงานขององค์กร นี่คือแก่นที่ไม่จำเป็นต้องสัมผัส แน่นอนว่ามันเป็นไปได้ แต่รับประกันคุณภาพอย่างหวาดระแวง เพราะมันนำเงินมาสู่องค์กร
ถัดมาคือเลเยอร์ของไมโครเซอร์วิส - สิ่งที่ทำให้ผู้ปฏิบัติงานหรือผู้เล่นรายอื่นแตกต่าง ไมโครเซอร์วิสสามารถสร้างได้อย่างรวดเร็วตามแคชบางตัว โดยนำข้อมูลจากโดเมนต่างๆ ไปที่นั่น ที่นี่ สนามสำหรับการทดลอง — หากมีบางอย่างไม่ได้ผล ฉันจะปิดไมโครเซอร์วิสหนึ่งแล้วเปิดอีกอันหนึ่ง สิ่งนี้ช่วยเพิ่มเวลาออกสู่ตลาดได้อย่างแท้จริงและเพิ่มความน่าเชื่อถือและความรวดเร็วของบริษัท
ไมโครเซอร์วิสอาจเป็นบทบาทหลักของ Tarantool ที่ MegaFon
ที่เราวางแผนจะใช้ Tarantool
หากเราเปรียบเทียบโครงการเรียกเก็บเงินที่ประสบความสำเร็จของเรากับโปรแกรมการเปลี่ยนแปลงที่ Deutsche Telekom, Svyazcom, Vodafone India ก็ถือว่ามีความเคลื่อนไหวและสร้างสรรค์อย่างน่าประหลาดใจ ในกระบวนการดำเนินโครงการนี้ ไม่เพียงแต่ MegaFon และโครงสร้างของมันได้รับการเปลี่ยนแปลงเท่านั้น แต่ยังรวมถึง Tarantool-enterprise ที่ Mail.ru และผู้จำหน่ายของเรา Nexign (เดิมคือ Peter-Service) - BSS Box (โซลูชันการเรียกเก็บเงินแบบบรรจุกล่อง)
ในแง่หนึ่ง นี่คือโครงการประวัติศาสตร์สำหรับตลาดรัสเซีย สามารถนำมาเปรียบเทียบกับสิ่งที่อธิบายไว้ในหนังสือ “The Mythical Man-Month” ของ Frederick Brooks ได้ จากนั้นในช่วงทศวรรษที่ 60 IBM จ้างพนักงาน 360 คนเพื่อพัฒนาระบบปฏิบัติการ OS/5 ใหม่สำหรับเมนเฟรม เรามีน้อยกว่า - 000 แต่ของเรายังอยู่ในสภาพดี และเมื่อคำนึงถึงการใช้โอเพ่นซอร์สและวิธีการใหม่ ๆ เราจึงทำงานได้อย่างมีประสิทธิผลมากขึ้น
ด้านล่างนี้คือโดเมนของการเรียกเก็บเงินหรือระบบธุรกิจ ผู้คนจากองค์กรรู้จัก CRM เป็นอย่างดี ทุกคนควรมีระบบอื่นอยู่แล้ว: Open API, API Gateway
เปิด API
มาดูตัวเลขอีกครั้งและวิธีการทำงานของ Open API ในปัจจุบัน โหลดของมันคือ 10 ธุรกรรมต่อวินาที. เนื่องจากเราวางแผนที่จะพัฒนาไมโครเซอร์วิสเลเยอร์อย่างแข็งขันและสร้าง MegaFon API สาธารณะ เราจึงคาดหวังการเติบโตที่มากขึ้นในอนาคตในส่วนนี้ จะมีธุรกรรม 100 รายการแน่นอน.
ฉันไม่รู้ว่าเราสามารถเปรียบเทียบกับ Mail.ru ใน SSO ได้หรือไม่ - ดูเหมือนว่าพวกเขาจะมีธุรกรรม 1 รายการต่อวินาที โซลูชันของพวกเขาน่าสนใจอย่างยิ่งสำหรับเรา และเราวางแผนที่จะนำประสบการณ์ของพวกเขาไปใช้ เช่น การสร้างการสำรองข้อมูล SSO ที่ใช้งานได้โดยใช้ Tarantool ตอนนี้นักพัฒนาจาก Mail.ru กำลังทำสิ่งนี้เพื่อเรา
CRM
CRM มีจำนวนสมาชิก 80 ล้านรายเดียวกันกับที่เราต้องการที่จะเพิ่มเป็นพันล้าน เนื่องจากมีเอกสาร 300 ล้านฉบับที่รวมประวัติสามปีไว้ด้วย เรากำลังรอคอยบริการใหม่ ๆ และที่นี่ จุดเติบโตคือบริการที่เชื่อมต่อกัน. นี่คือลูกบอลที่จะเติบโตเพราะจะมีบริการมากขึ้นเรื่อยๆ ดังนั้นเราจึงต้องมีเรื่องราวและเราไม่อยากสะดุดกับเรื่องนี้
วางบิลเองในแง่ของการออกใบแจ้งหนี้ ทำงานร่วมกับบัญชีลูกหนี้ของลูกค้า กลายเป็นโดเมนที่แยกจากกัน. เพื่อปรับปรุงประสิทธิภาพ สถาปัตยกรรมโดเมนประยุกต์ รูปแบบสถาปัตยกรรม.
ระบบแบ่งออกเป็นโดเมน มีการกระจายโหลดและรับประกันความทนทานต่อข้อผิดพลาด นอกจากนี้ เรายังทำงานร่วมกับสถาปัตยกรรมแบบกระจายอีกด้วย
ทุกสิ่งทุกอย่างล้วนเป็นโซลูชันระดับองค์กร ในการจัดเก็บสาย - 2 พันล้านต่อวัน, 60 พันล้านต่อเดือน. บางครั้งคุณต้องนับมันในหนึ่งเดือนและมันก็จะดีขึ้นอย่างรวดเร็ว การตรวจสอบทางการเงิน - นี่คือ 300 ล้านเดียวกันกับที่มีการเติบโตและเติบโตอย่างต่อเนื่อง: สมาชิกมักจะทำงานระหว่างผู้ให้บริการ โดยเพิ่มส่วนนี้
องค์ประกอบโทรคมนาคมส่วนใหญ่ของการสื่อสารเคลื่อนที่คือ การเรียกเก็บเงินออนไลน์. เหล่านี้คือระบบที่ให้คุณโทรหรือไม่โทร ตัดสินใจได้แบบเรียลไทม์ ที่นี่ปริมาณงานอยู่ที่ 30 ธุรกรรมต่อวินาที แต่เมื่อคำนึงถึงการเติบโตของการถ่ายโอนข้อมูล เราวางแผนไว้ ธุรกรรม 250 รายการดังนั้นเราจึงสนใจ Tarantool มาก
รูปภาพก่อนหน้าคือโดเมนที่เราจะใช้ Tarantool แน่นอนว่า CRM นั้นกว้างกว่า และเราจะใช้มันในแกนกลางของมันเอง
ตัวเลข TTX โดยประมาณของเราที่มีสมาชิก 100 ล้านคนทำให้ฉันสับสนในฐานะสถาปนิก - จะเกิดอะไรขึ้นถ้า 101 ล้านคน? คุณต้องทำซ้ำทุกอย่างอีกครั้งหรือไม่? เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น เราใช้แคช ขณะเดียวกันก็เพิ่มการเข้าถึง
โดยทั่วไป การใช้ Tarantool มีสองวิธี อันดับแรก - สร้างแคชทั้งหมดในระดับไมโครเซอร์วิส. เท่าที่ฉันเข้าใจ VimpelCom กำลังติดตามเส้นทางนี้โดยสร้างแคชของไคลเอ็นต์
เราพึ่งพาผู้จำหน่ายน้อยลง เรากำลังเปลี่ยนแกน BSS ดังนั้นเราจึงมีไฟล์ไคลเอนต์เดียวทันที แต่เราต้องการที่จะขยายมัน ดังนั้นเราจึงใช้แนวทางที่แตกต่างออกไปเล็กน้อย - สร้างแคชภายในระบบ.
วิธีนี้ทำให้การซิงโครไนซ์น้อยลง - ระบบหนึ่งรับผิดชอบทั้งแคชและแหล่งที่มาหลัก
วิธีการนี้เข้ากันได้ดีกับแนวทาง Tarantool ที่มีโครงกระดูกของธุรกรรม เมื่อมีการอัปเดตเฉพาะส่วนที่เกี่ยวข้องกับการอัปเดต ซึ่งก็คือการเปลี่ยนแปลงข้อมูลเท่านั้น ทุกสิ่งทุกอย่างสามารถเก็บไว้ที่อื่นได้ ไม่มี Data Lake ขนาดใหญ่ แคชส่วนกลางที่ไม่มีการจัดการ แคชได้รับการออกแบบมาสำหรับระบบ ผลิตภัณฑ์ หรือสำหรับไคลเอ็นต์ หรือเพื่อให้การบำรุงรักษาง่ายขึ้น เมื่อสมาชิกโทรมาและไม่พอใจกับคุณภาพบริการของคุณ คุณต้องการให้บริการที่มีคุณภาพ
RTO และ RPO
มีสองคำในไอที - RTO и RPO.
วัตถุประสงค์ของเวลาฟื้นตัว คือเวลาที่ใช้ในการกู้คืนบริการหลังจากเกิดความล้มเหลว RTO = 0 หมายความว่าแม้ว่าจะมีบางอย่างล้มเหลว บริการยังคงทำงานต่อไป
วัตถุประสงค์จุดฟื้นตัว - นี่คือระยะเวลาในการกู้คืนข้อมูล ปริมาณข้อมูลที่เราอาจสูญเสียไปในช่วงระยะเวลาหนึ่ง RPO = 0 หมายความว่าเราไม่สูญเสียข้อมูล
งานทารันทูล
มาลองแก้ปัญหาให้กับ Tarantool กัน
ที่ให้ไว้: ตะกร้าแอปพลิเคชันที่ทุกคนเข้าใจ เช่น ใน Amazon หรือที่อื่น ๆ ต้อง เพื่อให้ตะกร้าสินค้าทำงานได้ตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ หรือ 99,99% ของเวลาทั้งหมด คำสั่งซื้อที่มาหาเราจะต้องคงอยู่ตามลำดับ เนื่องจากเราไม่สามารถเปิดหรือปิดการเชื่อมต่อของสมาชิกแบบสุ่มได้ - ทุกอย่างจะต้องสอดคล้องกันอย่างเคร่งครัด การสมัครสมาชิกครั้งก่อนจะส่งผลต่อการสมัครสมาชิกครั้งถัดไป ดังนั้นข้อมูลจึงมีความสำคัญ - ไม่มีอะไรจะขาดหายไป
การตัดสิน. คุณสามารถลองแก้ปัญหาแบบตรงหน้าและถามนักพัฒนาฐานข้อมูลได้ แต่ปัญหาไม่สามารถแก้ไขได้ทางคณิตศาสตร์ คุณสามารถจำทฤษฎีบท กฎการอนุรักษ์ ฟิสิกส์ควอนตัม ได้ แต่ทำไมจึงไม่สามารถแก้ไขได้ในระดับ DB
วิธีการทางสถาปัตยกรรมแบบเก่าที่ดีได้ผลที่นี่ - คุณจำเป็นต้องรู้หัวข้อเรื่องเป็นอย่างดี และใช้มันเพื่อไขปริศนานี้
โซลูชันของเรา: การสร้างรีจิสทรีแบบกระจายของแอปพลิเคชันบน Tarantool ซึ่งเป็นคลัสเตอร์แบบกระจายทางภูมิศาสตร์. ในแผนภาพ นี่คือศูนย์ประมวลผลข้อมูลที่แตกต่างกันสามแห่ง - สองแห่งก่อนเทือกเขาอูราล หนึ่งแห่งอยู่เลยเทือกเขาอูราล และเรากระจายคำขอทั้งหมดไปยังศูนย์เหล่านี้
Netflix ซึ่งปัจจุบันถือว่าเป็นหนึ่งในผู้นำด้านไอที มีศูนย์ข้อมูลเพียงแห่งเดียวจนถึงปี 2012 เนื่องในวันคริสต์มาสคาทอลิก วันที่ 24 ธันวาคม ศูนย์ข้อมูลแห่งนี้ปิดให้บริการ ผู้ใช้ในแคนาดาและสหรัฐอเมริกาถูกทิ้งไว้โดยไม่มีภาพยนตร์เรื่องโปรด รู้สึกเสียใจมากและเขียนเกี่ยวกับเรื่องนี้บนโซเชียลเน็ตเวิร์ก ขณะนี้ Netflix มีศูนย์ข้อมูลสามแห่งบนชายฝั่งตะวันตก-ตะวันออกและอีกหนึ่งแห่งในยุโรปตะวันตก
ในตอนแรก เรากำลังสร้างโซลูชันแบบกระจายตามภูมิศาสตร์ การทนทานต่อข้อผิดพลาดเป็นสิ่งสำคัญสำหรับเรา
เรามีคลัสเตอร์ แต่ RPO = 0 และ RTO = 0 ล่ะ วิธีแก้ปัญหานั้นง่าย ขึ้นอยู่กับหัวข้อ
สิ่งสำคัญในการใช้งานคืออะไร? สองส่วน: การขว้างตะกร้า ไปยัง การตัดสินใจซื้อและ หลัง. โดยทั่วไปเรียกว่าส่วน DO ในโทรคมนาคม สั่งจับ หรือ การเจรจาต่อรองการสั่งซื้อ. ในด้านโทรคมนาคมสิ่งนี้อาจยากกว่าในร้านค้าออนไลน์มากเพราะต้องให้บริการลูกค้าที่นั่นโดยเสนอ 5 ตัวเลือกและทั้งหมดนี้เกิดขึ้นระยะหนึ่ง แต่ตะกร้าเต็ม ในขณะนี้ ความล้มเหลวเกิดขึ้นได้ แต่ก็ไม่น่ากลัว เพราะมันเกิดขึ้นแบบโต้ตอบได้ภายใต้การดูแลของมนุษย์
หากศูนย์ข้อมูลมอสโกล่มกะทันหัน เราจะยังคงทำงานต่อไปโดยการเปลี่ยนไปใช้ศูนย์ข้อมูลอื่นโดยอัตโนมัติ ตามทฤษฎีแล้ว ผลิตภัณฑ์หนึ่งรายการอาจสูญหายในรถเข็น แต่คุณเห็นแล้ว ให้เพิ่มลงในรถเข็นอีกครั้งและทำงานต่อไป ในกรณีนี้ RTO = 0
ในขณะเดียวกันก็มีตัวเลือกที่สอง: เมื่อเราคลิก "ส่ง" เราต้องการให้ข้อมูลไม่สูญหาย จากนี้ไป ระบบอัตโนมัติจะเริ่มทำงาน - นี่คือ RPO = 0 การใช้รูปแบบที่แตกต่างกันสองรูปแบบนี้ ในกรณีหนึ่งอาจเป็นคลัสเตอร์ที่กระจายทางภูมิศาสตร์ที่มีต้นแบบที่สลับได้หนึ่งรายการ ในอีกกรณีหนึ่ง บันทึกองค์ประชุมบางประเภท รูปแบบอาจแตกต่างกันไป แต่เราแก้ปัญหาได้
นอกจากนี้ การมีรีจิสทรีของแอปพลิเคชันแบบกระจาย เรายังสามารถปรับขนาดได้ทั้งหมด - มีผู้มอบหมายงานและผู้ดำเนินการจำนวนมากที่เข้าถึงรีจิสทรีนี้
แคสแซนดราและทารันทูลอยู่ด้วยกัน
มีอีกกรณีหนึ่ง - "ตู้โชว์ยอดคงเหลือ". นี่เป็นกรณีที่น่าสนใจของการใช้ Cassandra และ Tarantool ร่วมกัน
เราใช้ Cassandra เนื่องจากไม่จำกัดการโทร 2 พันล้านครั้งต่อวัน และจะมีเพิ่มมากขึ้น นักการตลาดชอบที่จะเปลี่ยนสีการเข้าชมตามแหล่งที่มา ตัวอย่างเช่น มีรายละเอียดมากขึ้นเรื่อยๆ บนโซเชียลเน็ตเวิร์ก ทั้งหมดนี้ช่วยเพิ่มเรื่องราว
Cassandra ช่วยให้คุณสามารถปรับขนาดในแนวนอนได้ทุกขนาด
เรารู้สึกสบายใจกับแคสแซนดรา แต่มีปัญหาอยู่อย่างหนึ่งคืออ่านหนังสือไม่เก่ง ทุกอย่างโอเคในการบันทึก 30 ต่อวินาทีไม่ใช่ปัญหา - ปัญหาการอ่าน.
ดังนั้นจึงมีหัวข้อที่มีแคชปรากฏขึ้นและในเวลาเดียวกันเราก็แก้ไขปัญหาต่อไปนี้: มีกรณีดั้งเดิมแบบเก่าเมื่ออุปกรณ์จากสวิตช์จากการเรียกเก็บเงินออนไลน์เข้ามาในไฟล์ที่เราโหลดลงในคาสซานดรา เราต่อสู้กับปัญหาการดาวน์โหลดไฟล์เหล่านี้ที่เชื่อถือได้ แม้จะใช้คำแนะนำในการถ่ายโอนไฟล์ของตัวจัดการ IBM ก็มีโซลูชันที่จัดการการถ่ายโอนไฟล์อย่างมีประสิทธิภาพ เช่น โดยใช้โปรโตคอล UDP แทนที่จะเป็น TCP นี่เป็นสิ่งที่ดี แต่ยังเหลือเวลาอีกไม่กี่นาทีและเรายังไม่ได้โหลดทั้งหมด เจ้าหน้าที่ในศูนย์บริการทางโทรศัพท์ไม่สามารถตอบลูกค้าได้ว่าเกิดอะไรขึ้นกับยอดคงเหลือของเขา - เราต้องรอ
เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้นเรา เราใช้การสำรองฟังก์ชันแบบขนาน. เมื่อเราส่งเหตุการณ์ผ่าน Kafka ไปยัง Tarantool โดยจะคำนวณผลรวมใหม่แบบเรียลไทม์ เช่น สำหรับวันนี้ เราได้ ยอดเงินสดซึ่งสามารถโอนยอดคงเหลือได้ทุกความเร็ว เช่น 100 ธุรกรรมต่อวินาที และ 2 วินาทีเท่าเดิม
เป้าหมายคือหลังจากโทรออก ภายใน 2 วินาทีในบัญชีส่วนตัวของคุณ ไม่เพียงแต่ยอดคงเหลือที่เปลี่ยนแปลงเท่านั้น แต่ยังรวมถึงข้อมูลเกี่ยวกับสาเหตุที่มันเปลี่ยนแปลงด้วย
ข้อสรุป
นี่คือตัวอย่างของการใช้ Tarantool เราชอบความเปิดกว้างของ Mail.ru และความเต็มใจที่จะพิจารณากรณีต่างๆ กันมาก
เป็นเรื่องยากอยู่แล้วสำหรับที่ปรึกษาจาก BCG หรือ McKinsey, Accenture หรือ IBM ที่จะทำให้เราประหลาดใจด้วยสิ่งใหม่ๆ ซึ่งส่วนใหญ่สิ่งที่พวกเขานำเสนอ เราทำไปแล้ว ได้ทำไปแล้ว หรือกำลังวางแผนที่จะทำ ฉันคิดว่า Tarantool จะเข้ามาแทนที่เทคโนโลยีที่มีอยู่ของเราอย่างเหมาะสม และจะเข้ามาแทนที่เทคโนโลยีที่มีอยู่มากมาย เราอยู่ในขั้นตอนการพัฒนาโครงการนี้
รายงานของ Oleg และ Andrey เป็นหนึ่งในรายงานที่ดีที่สุดในการประชุม Tarantool เมื่อปีที่แล้ว และในวันที่ 17 มิถุนายน Oleg Ivlev จะพูดที่ พร้อมรายงาน . Alexander Deulin จะให้การนำเสนอจาก MegaFon ด้วย . มาดูกันว่ามีอะไรเปลี่ยนแปลงบ้าง มีแผนอะไรบ้างที่ได้ดำเนินการไปแล้ว เข้าร่วม - การประชุมฟรี สิ่งที่คุณต้องทำคือ . ทั้งหมด และโปรแกรมการประชุมได้ถูกสร้างขึ้น: เคสใหม่ ประสบการณ์ใหม่ในการใช้ Tarantool สถาปัตยกรรม องค์กร บทช่วยสอน และไมโครเซอร์วิส
ที่มา: will.com