كيف تقوم AWS بإعداد خدماتها المرنة. توسيع نطاق الخوادم وقاعدة البيانات

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

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

عن المتحدث: فاسيلي بانتيوخين (دجاجة) بدأ كمشرف Unix في شركات .ru، وعمل على أجهزة Sun Microsystem الكبيرة لمدة 6 سنوات، ودعا إلى عالم يتمحور حول البيانات في EMC لمدة 11 عامًا. تطورت بشكل طبيعي إلى سحابات خاصة، وفي عام 2017 انتقلت إلى سحابات عامة. وهو الآن يقدم المشورة الفنية للمساعدة في العيش والتطوير في سحابة AWS.

إخلاء المسؤولية: كل ما هو مذكور أدناه هو رأي شخصي لفاسيلي وقد لا يتوافق مع موقف Amazon Web Services. تسجيل الفيديو التقرير الذي يستند إليه المقال متاح على قناتنا على اليوتيوب.

لماذا أتحدث عن جهاز أمازون؟

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

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

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

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

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

ماذا علينا أن نتحدث عن

اخترت نهجا متنوعا - اخترت 4 خدمات مثيرة للاهتمام تستحق الحديث عنها.

تحسين الخادم. سحب سريعة الزوال ذات تجسيد مادي: مراكز بيانات فعلية حيث توجد خوادم فعلية تدندن وتسخن وتومض بالأضواء.

وظائف بدون خادم (Lambda) ربما تكون الخدمة الأكثر قابلية للتوسع في السحابة.

تحجيم قاعدة البيانات. سأخبرك عن كيفية بناء قواعد البيانات القابلة للتطوير الخاصة بنا.

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

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

الخوادم

السحابة سريعة الزوال. لكن هذا الزوال لا يزال له تجسيد مادي - الخوادم. في البداية، كانت هندستهم المعمارية كلاسيكية. مجموعة شرائح x86 القياسية وبطاقات الشبكة وLinux وXen Hypervisor التي تم تشغيل الأجهزة الافتراضية عليها.

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

تحسين الأجهزة وبرنامج Hypervisor

إن القيام بكل شيء دفعة واحدة والقيام بذلك بشكل جيد لن ينجح. ما هو "الجيد" كان أيضًا غير واضح في البداية.

قررنا اتباع نهج تطوري - حيث قمنا بتغيير أحد العناصر المهمة في الهندسة المعمارية وإدخاله في الإنتاج.

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

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

بعد ذلك قررنا تحسين الوصول إلى تخزين البيانات المحظورة EBS - Elastic Block Storage. إنه مزيج من الشبكة والتخزين. تكمن الصعوبة في أنه على الرغم من وجود بطاقات Network Accelerator في السوق، لم يكن هناك خيار لشراء أجهزة Storage Accelerator ببساطة. لذلك لجأنا إلى شركة ناشئة مختبرات أنابورنا، الذي طور شرائح ASIC خاصة لنا. لقد سمحوا بتركيب وحدات تخزين EBS البعيدة كأجهزة NVMe.

في الحالات C4 لقد حللنا مشكلتين. الأول هو أننا وضعنا أساسًا لمستقبل تقنية NVMe الواعدة، ولكن الجديدة في ذلك الوقت. ثانيًا، قمنا بتفريغ المعالج المركزي بشكل كبير عن طريق نقل معالجة الطلبات إلى EBS إلى بطاقة جديدة. لقد اتضح الأمر جيدًا، والآن أصبحت Annapurna Labs جزءًا من أمازون.

بحلول نوفمبر 2017، أدركنا أن الوقت قد حان لتغيير برنامج Hypervisor نفسه.

تم تطوير برنامج Hypervisor الجديد استنادًا إلى وحدات KVM kernel المعدلة.

لقد جعل من الممكن تقليل الحمل الزائد لمحاكاة الجهاز بشكل أساسي والعمل مباشرة مع أجهزة ASIC الجديدة. المثيلات S5 كانت الأجهزة الافتراضية الأولى المزودة ببرنامج Hypervisor الجديد الذي يعمل تحت الغطاء. لقد أطلقنا عليه اسم نيترو.

تطور الحالات على الجدول الزمني.

تعمل جميع الأنواع الجديدة من الأجهزة الافتراضية التي ظهرت منذ نوفمبر 2017 على برنامج Hypervisor هذا. لا تحتوي مثيلات Bare Metal على برنامج Hypervisor، ولكن يطلق عليهم أيضًا اسم Nitro، نظرًا لأنهم يستخدمون بطاقات Nitro المتخصصة.

على مدى العامين المقبلين، تجاوز عدد أنواع مثيلات Nitro بضع عشرات: A1، C5، M5، T3 وغيرها.

أنواع المثيلات.

كيف تعمل ماكينات النيترو الحديثة

وهي تحتوي على ثلاثة مكونات رئيسية: برنامج Nitro Hypervisor (الذي تمت مناقشته أعلاه) وشريحة الأمان وبطاقات Nitro.

شريحة الأمان مدمجة مباشرة في اللوحة الأم. فهو يتحكم في العديد من الوظائف المهمة، مثل التحكم في تحميل نظام التشغيل المضيف.

بطاقات نيترو - هناك أربعة أنواع منها. تم تطويرها جميعًا بواسطة Annapurna Labs وتعتمد على أجهزة ASIC الشائعة. بعض البرامج الثابتة الخاصة بهم شائعة أيضًا.

أربعة أنواع من بطاقات نيترو.

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

حدد البطاقات التي تعمل مع تخزين الكتلة EBS والأقراص المضمنة في الخادم. تظهر للجهاز الظاهري الضيف على أنها محولات NVMe. كما أنهم مسؤولون عن تشفير البيانات ومراقبة القرص.

تم دمج نظام بطاقات Nitro وبرنامج Hypervisor ورقاقة الأمان في شبكة SDN أو الشبكة المعرفة بالبرمجيات. المسؤول عن إدارة هذه الشبكة (طائرة التحكم) بطاقة تحكم.

وبطبيعة الحال، نحن نواصل تطوير ASICs جديدة. على سبيل المثال، في نهاية عام 2018، أطلقوا شريحة Inferentia، والتي تتيح لك العمل بشكل أكثر كفاءة مع مهام التعلم الآلي.

شريحة معالج التعلم الآلي Inferentia.

قاعدة بيانات قابلة للتطوير

تحتوي قاعدة البيانات التقليدية على بنية متعددة الطبقات. للتبسيط إلى حد كبير، يتم تمييز المستويات التالية.

• SQL - يعمل مرسلي العميل والطلب على ذلك.
• أحكام المعاملات - كل شيء واضح هنا، ACID وكل ذلك.
• التخزين المؤقت، والتي يتم توفيرها بواسطة التجمعات العازلة.
• تسجيل - يوفر العمل مع سجلات الإعادة. في MySQL يطلق عليها اسم Bin Logs، في PosgreSQL - كتابة السجلات المسبقة (WAL).
• تخزين - التسجيل المباشر على القرص.

هيكل قاعدة البيانات الطبقات.

هناك طرق مختلفة لتوسيع نطاق قواعد البيانات: التقسيم، وبنية Shared Nothing، والأقراص المشتركة.

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

أمازون أورورا

الفكرة المعمارية الرئيسية هي فصل مستويات التخزين والتسجيل عن قاعدة البيانات الرئيسية.

وبالنظر إلى المستقبل، سأقول أننا جعلنا أيضًا مستوى التخزين المؤقت مستقلاً. لم تعد البنية متماسكة، واكتسبنا درجات إضافية من الحرية في توسيع نطاق الكتل الفردية.

مستويات التسجيل والتخزين منفصلة عن قاعدة البيانات.

يقوم نظام إدارة قواعد البيانات (DBMS) التقليدي بكتابة البيانات إلى نظام تخزين على شكل كتل. في Amazon Aurora، قمنا بإنشاء وحدة تخزين ذكية يمكنها التحدث باللغة إعادة السجلات. وفي الداخل، تقوم وحدة التخزين بتحويل السجلات إلى كتل بيانات، ومراقبة سلامتها وإجراء نسخ احتياطي لها تلقائيًا.

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

يتم تنفيذ طبقة التخزين كنظام موزع. يتكون من عدد كبير جدًا من الخوادم الفعلية. تتم معالجة كل سجل إعادة وحفظه في وقت واحد ستة عقدة. وهذا يضمن حماية البيانات وموازنة التحميل.

يمكن تحقيق قياس القراءة باستخدام النسخ المتماثلة المناسبة. يلغي التخزين الموزع الحاجة إلى المزامنة بين مثيل قاعدة البيانات الرئيسية، التي نكتب من خلالها البيانات، والنسخ المتماثلة المتبقية. نضمن أن تكون البيانات المحدثة متاحة لجميع النسخ المتماثلة.

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

قمنا بفرز التخزين.

كيفية توسيع نطاق طبقات نظام إدارة قواعد البيانات (DBMS).

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

لنفترض أن لدينا تطبيقًا يتواصل مع نظام إدارة قواعد البيانات (DBMS) من خلال عقدة رئيسية.

عند القياس عموديًا، نقوم بتخصيص عقدة جديدة تحتوي على المزيد من المعالجات والذاكرة.

بعد ذلك، نقوم بتبديل التطبيق من العقدة الرئيسية القديمة إلى العقدة الجديدة. تنشأ مشاكل.

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

كيفية تحسين الوضع؟ قم بإعداد وكيل بين التطبيق والعقدة الرئيسية.

ماذا سيعطينا هذا؟ الآن لا تحتاج جميع التطبيقات إلى إعادة توجيهها يدويًا إلى العقدة الجديدة. يمكن إجراء التبديل ضمن وكيل وهو أسرع بشكل أساسي.

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

الحل النهائي مع Amazon Aurora بدون خادم

كيف حللنا هذه المشاكل؟

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

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

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

الوكلاء الموزعون والمثيلات الدافئة والمراقبة.

العقدة مع الطاقة المطلوبة متاحة. يتم نسخ تجمعات المخزن المؤقت إليها، ويبدأ النظام في انتظار لحظة آمنة للتبديل.

عادةً ما تأتي لحظة التبديل بسرعة كبيرة. ثم يتم تعليق الاتصال بين الوكيل والعقدة الرئيسية القديمة، ويتم تحويل كافة الجلسات إلى العقدة الجديدة.

العمل مع استئناف قاعدة البيانات.

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

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

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

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

المصدر: www.habr.com