هبوط السحابة: كيف دمجنا السحابة العامة مع شبكة توصيل المحتوى وما نتج عنها

عندما يكون لديك في الوقت نفسه سحابة قوية مع بنية تحتية في الولايات المتحدة الأمريكية والاتحاد الأوروبي ورابطة الدول المستقلة وآسيا وأستراليا و CDN مع 100 نقطة تواجد في أكثر من 70 مدينة في خمس قارات ، يأتي الحل بشكل طبيعي - تحتاج إلى دمجها! ومن الواضح أن هذا التآزر سيعزز قدرات البنية التحتية. بالطبع ، لم نتمكن من تفويت هذه الفرصة ، لكننا واجهنا في نفس الوقت عددًا من التحديات.



كان التكامل مصحوبًا بصراع مع كل مللي ثانية من وقت الاستجابة ، وترقية البنية التحتية وتطوير تقنيات توصيل المحتوى ، والتي كان علينا أن نبتكر أسماء أنفسنا. نخبرك بما واجهناه أثناء العمل ، وما حدث في النهاية ولماذا يحتاج المستخدمون إليه.



صورة



لماذا تكامل السحابة مع CDN على الإطلاق



بادئ ذي بدء ، تعد السحابة العامة قدرة قابلة للتطوير. يمكن استخدامها بأي شكل من الأشكال: لتطوير الخدمات واختبارها ، وكذلك لتخزين البيانات ومعالجتها. أطلقنا في G-Core Labs السحابة العام الماضي وتمكنا بالفعل من استخدامها في المشاريع عالية التحميل. على سبيل المثال ، يستخدم عميلنا منذ فترة طويلة - Wargaming - هذا الحل لعدة مهام في وقت واحد:



  • اختبار الميزات والخدمات الجديدة للمشاريع المختلفة ؛
  • إعداد نماذج أولية للاختبار مع المطورين الخارجيين الذين يحتاجون إلى الوصول إلى موارد مخصصة وخاضعة للرقابة ؛
  • تشغيل لعبة الإنترنت "Calibre" على الأجهزة الافتراضية.


تتواءم السحابة مع كل ما سبق بضجة كبيرة ، لكن العمل لا ينتهي عند هذا الحد. بغض النظر عن الغرض من استخدام هذه القدرات أو تلك القدرات ، لا تزال نتيجة عملهم بحاجة إلى التسليم إلى الوجهة المقصودة. بغض النظر عما إذا كنا نتحدث عن لعبة على الإنترنت أو عن تشكيلات عسكرية حقيقية ، فهذا هو المكان الذي تبرز فيه المشكلة: من الصعب للغاية توصيل بيانات ثقيلة بسرعة إلى مناطق نائية ذات معدات عسكرية متعددة الأطنان. يمكن تبسيط هذه المهمة من خلال دمج السحابة مع شبكة توصيل المحتوى. بمساعدة CDN ، يمكن طرح الجزء القابل للنقل - البيانات الثابتة - "عبر الهواء" مباشرة إلى نقطة الوجهة ، وكل ما تبقى هو إرسال بيانات ديناميكية "كبيرة الحجم" من السحابة. باستخدام هذا النهج ، يمكنك بدء العمل بأمان حتى في القارات الأخرى ، لأن التكامل يسمح للمنافسين الأسرع بتقديم محتوى ثقيل حول العالم.



صورة



, , : CDN



دعنا ننتقل إلى التفاصيل. نحن نعلم بشكل مباشر أن الأمر يستغرق وقتًا طويلاً لتوصيل المحتوى الثقيل إلى المناطق النائية مباشرةً من السحابة ، وقد يكون من المكلف زيادة سعة البنية التحتية باستمرار وفقًا لزيادة الحمل. لحسن الحظ ، بالإضافة إلى السحابة العامة ، انتهى بنا الأمر مع CDN الخاص بنا ، والذي دخل حتى في موسوعة جينيس للأرقام القياسية ، مما يوفر تجربة متواصلة للعب World of Tanks خلال فترات الذروة.



لقتل عصفورين بحجر واحد ، احتجنا إلى دمجه مع السحابة. وبعد ذلك سنكون قادرين على تزويد المستخدمين بحل أقل تكلفة من ترقية البنية التحتية ويسمح بتسليم البيانات بشكل أسرع إلى المناطق النائية. لذلك بدأنا المرحلة الأولى من العمل وحلنا المشاكل الرئيسية:



1. كانت الخدمات السحابية تحت عبء مستمر.طلب مستخدمو المشاريع عالية التحميل بانتظام محتوى من سحابة عملائنا. نتج عن ذلك حمل كبير وإرجاع بيانات طويل. هناك حاجة إلى حل يمكن أن يقلل بسهولة من عدد الإشارات إلى المصدر. للقيام بذلك ، قمنا بدمج الخوادم السحابية العامة وخوادم ذاكرة التخزين المؤقت CDN ، كما أنشأنا واجهة واحدة لإدارة هذه الخدمات. بمساعدتها ، يمكن للمستخدمين نقل البيانات الثابتة إلى نقاط التواجد المطلوبة على الشبكة. نتيجة لذلك ، لا تحدث المكالمات إلى السحابة إلا عند الطلبات الأولى للمحتوى. يعمل بطريقة قياسية: تأخذ CDN البيانات من المصدر وترسلها إلى المستخدم ، وكذلك إلى أقرب خادم ذاكرة تخزين مؤقت ، حيث يتم توزيع المحتوى على الطلبات اللاحقة ؛



2. تم نقل البيانات لفترة طويلة بين السحابة و CDN.من خلال الجمع بين السحابة وشبكة توصيل المحتوى ، لاحظنا أنه يمكن تقليل وقت استجابة تسليم البيانات. لتوفير أكبر عدد ممكن من المللي ثانية الثمينة ، كان علينا تنفيذ تبادل حركة المرور بين خوادم ذاكرة التخزين المؤقت والسحابة داخل العمود الفقري ؛



صورة



3. كان الحمل على المصدر متفاوتًا. حتى بعد توصيل CDN ، تم توزيع الطلبات المتبقية على السحابة بشكل غير فعال. لقد أصلحنا ذلك باستخدام موازين HTTP (S). الآن ، في وقت طلب المحتوى ، يحددون من أي مصدر (جهاز افتراضي أو مجموعة تخزين سحابية) يجب أخذ البيانات للتخزين المؤقت ؛



4. استغرق المحتوى الثقيل وقتًا طويلاً للوصول إلى المستخدمين.لتقليل وقت الانتظار ، قمنا باستمرار بزيادة سعة وجود شبكة CDN وجغرافيتها. لم يعد يتعين على المستخدمين الآن انتظار وصول المحتوى إليهم في منتصف الطريق عبر العالم - في وقت الاتصال ، تختار شبكة توصيل المحتوى أقرب 100 نقطة تواجد في القارات الخمس. نتيجة لذلك ، يكون متوسط ​​وقت الاستجابة في جميع أنحاء العالم في حدود 30 مللي ثانية.



بعد أن تعاملنا مع هذه المشاكل ، فقد اعتبرنا بالفعل أن العمل قد انتهى. لكن السحابة مع CDN لديها خطط أخرى لنا.



هذه هي الطريقة التي تم بها تلطيف الفولاذ: نقوم بتحديث البنية التحتية



في مرحلة ما ، أصبح من الواضح أن تأثير جميع جهودنا لا يمكن أن يعبر عن نفسه تمامًا أثناء استخدامنا لتكوين الأجهزة القديم. لجعل الخوادم والتطبيقات المستضافة عليها تعمل بشكل أفضل ونقل المحتوى بشكل أسرع ، كان يلزم ترقية البنية التحتية. تقاربت النجوم في السماء في وقت سابق من هذا العام: بدأنا في الترقية بمجرد إطلاق الجيل الثاني من معالجات Intel Xeon Scalable.



الآن يبدو تكوين الخادم القياسي كما يلي:



  • تعمل الخدمات السحابية على معالجات Intel Xeon Gold 6152 و 6252 و 5220 ، وتحتوي على ما يصل إلى 1 تيرابايت من ذاكرة الوصول العشوائي ، بالإضافة إلى SSD و HDD مع النسخ المتماثل الثلاثي ؛
  • تم تجهيز خوادم ذاكرة التخزين المؤقت CDN بـ Intel Xeon Platinum و RAID الظاهري على وحدة المعالجة المركزية و SSD D3-S4610.


نتيجة للترقية ، زاد الأداء بشكل كبير لدرجة أننا تخلينا عن بعض الخوادم وخفضنا تكلفة تشغيلها. يبدو أن كل ما سبق سيكون أكثر من كافٍ لعمل أي مشروع. ولكن مرة واحدة هذا لم يكن كافيا.



الحماية والتجزئة والتوزيع الجغرافي: تسريع تسليم المحتوى في الظروف القاسية



المصيبة لا تأتي وحدها. هذا صحيح بشكل خاص عندما يتعلق الأمر بالمشاريع العالمية. عدم وجود بنية تحتية موزعة جغرافيًا ، وأحمال عالية بسبب وجود العديد من المستخدمين من جميع أنحاء العالم وبحر من البيانات غير المتجانسة التي يحتاجون إلى تقديمها بسرعة - أحد عملائنا ، مورد وسائط كبير ، يحتاج إلى التعامل مع كل هذه التعقيدات في وقت واحد. تفاصيل قليلة:



  • استغرق المحتوى وقتًا طويلاً للوصول إلى المستخدمين ، وأحيانًا لم يصلهم على الإطلاق بسبب التأخيرات الكبيرة ومشاكل الشبكة. تكمن الصعوبة في أن المجموعة الكبيرة من الخوادم التي تحتوي على بيانات تقع في نقطة جغرافية واحدة ؛
  • تم الوصول إلى مصدر المحتوى من قبل المستخدمين من جميع أنحاء العالم ، مما تسبب في زيادة العبء على البنية التحتية وأدى إلى ارتفاع تكلفة الخدمة ، فضلاً عن بطء تسليم البيانات ؛
  • يحتاج المستخدمون إلى تقديم قدر هائل من المحتوى المحدث باستمرار والذي يكون فريدًا لكل منطقة.


كانت القدرات الأساسية للتكامل السحابي مع CDN لا غنى عنها هنا. بدأنا في تطوير حلول إضافية.



كيف توصلنا إلى التدريع الإقليمي



لقد أدخلنا هذا المفهوم ، والآن خدمة موجودة ، على وجه التحديد لحل المشكلة مع بعد مصدر المحتوى. نظرًا لحقيقة أن جميع خوادم العميل تقع في نقطة جغرافية واحدة ، فقد استغرقت البيانات الواردة منها وقتًا طويلاً للوصول إلى المستخدمين من مختلف أنحاء العالم. كان الوضع معقدًا بسبب حقيقة أنه كان من الضروري تقديم محتوى مختلف يتم تحديثه باستمرار إلى مناطق مختلفة. لن يؤدي التخزين المؤقت البسيط للبيانات على خوادم الحافة إلى حل المشكلة - فغالبًا ما يمكنهم الوصول إلى المصدر في منتصف الطريق عبر العالم.



لقد قمنا بحل المشكلة من خلال نشر مجموعة كبيرة من خوادم ذاكرة التخزين المؤقت في نقاط تبادل حركة المرور الشائعة في قارات مختلفة. أصبحت "الحماية الإقليمية" نوعًا من الطبقات بين المصدر وخوادم الحافة في بلدان المستخدم. الآن سقط كل المحتوى المطلوب في الأجزاء المقابلة من العالم عليهم أولاً ، ثم تم نقله إلى خوادم ذاكرة التخزين المؤقت. وبهذه الطريقة ، أدى التدريع إلى تقليل الحمل على مصدر العميل دفعة واحدة وتقليل التأخيرات التي يتعرض لها المستخدمون النهائيون. العميل ، بدوره ، وفر على استضافة العديد من مجموعات الخوادم بنفس المحتوى في أجزاء مختلفة من العالم ، لأنه مع مبدأ العمل هذا ، كان مصدر بيانات واحد كافياً.



صورة



لماذا احتجت إلى تقسيم المحتوى



حلت التدريع الإقليمية مشكلة تسليم المحتوى على المدى الطويل إلى أجزاء مختلفة من العالم بالكامل. ومع ذلك ، نشأت الآن صعوبة جديدة: نظرًا لأن العميل لديه الكثير من البيانات ويتم تحديثها باستمرار ، لم ينته الأمر في ذاكرة التخزين المؤقت لخوادم الحافة التي يصل إليها المستخدمون. أدى ذلك إلى حقيقة أن عددًا كبيرًا من الطلبات من خوادم ذاكرة التخزين المؤقت يتم ضخها باستمرار في مجموعات إقليمية ، وصل عددها في مجموعة واحدة إلى 20-30 قطعة. لإزالة بعض هذا الحمل من الدروع وتسليم المحتوى للمستخدمين بشكل أسرع ، أضفنا القدرة على أخذ البيانات الضرورية من أقرب خادم حافة في المجموعة.



الآن بدأت خوادم التخزين المؤقت في مناطق التواجد في الوصول إلى الدروع فقط عندما لم تكن البيانات متاحة في المجموعة بأكملها. علاوة على ذلك ، حتى في هذه الحالات ، تم طلب المحتوى على الفور من الخادم الذي يحتويه - بفضل التجزئة ، "عرفت" خوادم الحافة مسبقًا مكان وجود ملف معين ، ولم تقم باستطلاع مجموعة الدروع الإقليمية بالكامل لهذا الغرض. أدى مبدأ التشغيل هذا إلى تقليل عدد الطلبات إلى المستودع وجعل من الممكن توزيع المحتوى بكفاءة عبره بدلاً من تخزين نسخ من البيانات على كل خادم. ونتيجة لذلك ، احتوت الدروع على المزيد من المحتوى ، ونتيجة لذلك ، قللت من الضغط على مصدر العميل.



صورة



إنشاء مثل هذه البنية التحتية لا يمكن إلا أن ينطوي على صعوبة أخرى. بالنظر إلى عدد خوادم ذاكرة التخزين المؤقت في المجموعات ، سيكون من السخف افتراض عدم فشل أي منها. في مثل هذه الحالة ، كما في حالة إضافة خادم جديد إلى التجمع ، يجب إعادة توزيع ذاكرة التخزين المؤقت في المجموعات بالطريقة المثلى. للقيام بذلك ، قمنا بتنفيذ تنظيم ذاكرة تخزين مؤقت مجزأة باستخدام خوارزمية تجزئة متسقة في كتلة المنبع في nginx:



upstream cache_servers {
   hash $cache_key consistent;
   server edge1.dc1.gcorelabs.com;
   server edge2.dc1.gcorelabs.com;
   server edge3.dc1.gcorelabs.com;
}

      
      





كان ظهور الخوادم غير المتاحة في المستودع محفوفًا أيضًا بمشكلة أخرى: استمرت الخوادم الأخرى في إرسال الطلبات إليها وانتظرت الرد. للتخلص من هذا التأخير ، قمنا بكتابة خوارزمية لاكتشاف مثل هذه الخوادم في التجمع. الآن ، نظرًا لحقيقة أنه يتم نقلها تلقائيًا إلى الحالة السفلية في المجموعة الأولية ، لم نعد نصل إلى الخوادم غير النشطة ولا نتوقع بيانات منها.



نتيجة لهذه الأعمال ، قمنا بتخفيض تكلفة الخدمات للعميل ، وتوفيره له من التكاليف الجسيمة لتنظيم بنيته التحتية الخاصة ، وسرّعنا بشكل كبير تسليم البيانات للمستخدمين ، على الرغم من كل الصعوبات.



من يحتاج إلى سحابة مع CDN



انتهى عمل التكامل ، وعمل عملاؤنا يستخدمون المنتج بالفعل. نشارك أي منهم يحقق أقصى استفادة من هذا.



دعنا نقول على الفور أن الحل لم يكن مفيدًا للجميع. لم نتوقع أي شيء آخر: بالنسبة للبعض ، يكفي التخزين والأجهزة الافتراضية فقط ، وبالنسبة للآخرين - شبكات توصيل المحتوى. على سبيل المثال ، عندما يكون جمهور المشروع بأكمله في نفس المنطقة ، فلا داعي عمليًا لتوصيل CDN بالسحابة. لتقليل التأخيرات ، في هذه الحالة ، يكفي وجود خادم يقع في مكان غير بعيد عن المستخدمين.



يتم الكشف عن التكامل بكل مجده عندما تحتاج إلى تقديم محتوى ثقيل بسرعة وبعيدًا لعدد كبير من المستخدمين. في ما يلي بعض الأمثلة عن كيفية مساعدة السحابة مع CDN في مشاريع مختلفة:



  • تضمن خدمات البث ذات الأهمية الحاسمة للكمون والتخزين المؤقت التشغيل المستقر والبث عالي الجودة ؛
  • تقدم خدمات الترفيه عبر الإنترنت ألعابًا ثقيلة إلى أجزاء مختلفة من العالم بشكل أسرع وتقليل الحمل على الخوادم ، بما في ذلك في أوقات الذروة ؛
  • تعمل المشاريع الإعلامية على تسريع أوقات تحميل الإعلانات وتظل متاحة عند ارتفاع حركة المرور ؛
  • يتم تحميل المتاجر عبر الإنترنت بشكل أسرع في مختلف البلدان ، بما في ذلك أثناء العروض الترويجية والمبيعات.


ما زلنا نرى بالضبط كيف يستخدمون السحابة مع CDN. نحن ، مثلك ، مهتمون بالأرقام: مقدار تقليل الحمل على البنية التحتية ، ومدى سرعة تلقي المستخدمين للمحتوى في مناطق معينة ، ومقدار التكامل الذي يساعد على توفير المال. سوف نشارك كل هذا في الحالات المستقبلية.



All Articles