تشبه السحب صندوقًا سحريًا - تسأل عما تحتاج إليه ، والموارد تظهر من العدم. الأجهزة الافتراضية وقواعد البيانات والشبكة - كل هذا ينتمي لك فقط. هناك مستأجرين آخرين من السحابة ، لكن في كونك أنت الحاكم الوحيد. أنت متأكد من أنك ستتلقى دائمًا الموارد المطلوبة ، ولا تحسب حساب أي شخص وتحدد بشكل مستقل ما ستكون عليه الشبكة. كيف هو هذا السحر الذي يجعل السحابة تخصيص الموارد بشكل مرن وعزل المستأجرين تماما عن بعضها البعض؟
AWS Cloud هو نظام متطور للغاية تم تطويره منذ عام 2006. تم العثور على جزء من هذا التطور بواسطة
فاسيلي بانتيوكين ، مهندس خدمات الويب الأمازون. كمهندس معماري ، يرى من الداخل ليس فقط النتيجة النهائية ، ولكن أيضًا التحديات التي تتغلب عليها AWS. لمزيد من فهم النظام ، والمزيد من الثقة. لذلك ، سوف فاسيلي تبادل أسرار الخدمات السحابية AWS. تحت القصاص هو جهاز للخوادم المادية AWS ، وقابلية التوسع المرنة لقاعدة البيانات ، وقاعدة بيانات أمازون مخصصة وطرق لتحسين أداء الأجهزة الافتراضية مع خفض أسعارها. ستساعدك معرفة الأساليب الأمازون المعمارية على الاستفادة بشكل أفضل من خدمات AWS وقد توفر أفكارًا جديدة لبناء الحلول الخاصة بك.
نبذة عن المتحدث: بدأ Vasily Pantyukhin ( Hen ) كمسؤول في شركة Unix in.ru ، وقضى 6 سنوات في العمل في غدد Sun Microsystem الكبيرة ، وظل لمدة 11 عامًا يبشر بمركزية البيانات في العالم في EMC. تطورت بشكل طبيعي إلى غيوم خاصة ، وفي عام 2017 تحولت إلى غيوم عامة. الآن مع نصائح فنية ، فهو يساعد على العيش والتطور في سحابة AWS.
إخلاء المسئولية: كل ما سبق هو رأي فاسيلي الشخصي ، وقد لا يتطابق مع موقع Amazon Web Services. يتوفر مقطع فيديو للتقرير على أساسه المقال على قناة YouTube الخاصة بنا.لماذا أتحدث عن جهاز أمازون
كانت سيارتي الأولى مزودة "بمقبض" - على علبة تروس يدوية. لقد كان رائعًا بسبب الشعور بأنني أستطيع التحكم في الماكينة والتحكم فيها بالكامل. أحببت أيضًا أنني على الأقل أفهم مبدأ عملها تقريبًا. وبطبيعة الحال ، تخيلت جهاز الصندوق بدائيًا تمامًا - مثل علبة التروس على دراجة هوائية.
كل شيء كان رائعا ، باستثناء شيء واحد - الوقوف في الاختناقات المرورية. يبدو أنك جالس ولا تفعل شيئًا ، لكنك تقوم دائمًا بتحريك التروس ، والضغط على القابض ، والغاز ، والفرامل - لقد سئمت من ذلك بالفعل. تم حل مشكلة الاختناقات المرورية جزئيًا عندما ظهرت آلة على الجهاز في العائلة. في عجلة القيادة ، كان هناك وقت للتفكير في شيء ما ، والاستماع إلى كتاب مسموع.
ظهر لغز في حياتي ، لأنني توقفت عمومًا عن فهم كيف تعمل سيارتي. السيارة الحديثة هي جهاز معقد. تتكيف السيارة في وقت واحد مع عشرات المعايير المختلفة: الضغط على الغاز ، الفرامل ، أسلوب القيادة ، جودة الطريق. لم أعد أفهم كيف يعمل هذا.
عندما بدأت في تشغيل Amazon Cloud ، كان هذا غموضًا بالنسبة لي. هذا السر فقط هو ترتيب أعلى من حيث الحجم ، لأنه يوجد سائق واحد في السيارة ، وهناك الملايين في AWS. جميع المستخدمين توجيه في وقت واحد ، اضغط على الغاز والفرامل. إنه لأمر مدهش أنهم يذهبون إلى حيث يريدون - بالنسبة لي إنها معجزة! يقوم النظام تلقائيًا بالتكيف مع كل مستخدم وقياسه وضبطه بمرونة بحيث يبدو له أنه وحيد في هذا الكون.
تبدد السحر قليلاً عندما جئت لاحقًا للعمل كمهندس معماري في أمازون. لقد رأيت المشكلات التي نواجهها وكيف نحلها وكيف نطور الخدمات. مع زيادة فهم النظام ، هناك ثقة أكبر في الخدمة. لذلك أريد أن أشارك صورة لما تحت غطاء سحابة AWS.
ما سوف نتحدث عنه
لقد اخترت مقاربة متنوعة - لقد اخترت 4 خدمات مثيرة للاهتمام تستحق الحديث عنها.
تحسين الخادم . غيوم سريعة الزوال مع تجسيد مادي: مراكز بيانات فعلية ، حيث توجد خوادم فعلية تحترق وتسخن وتضيء المصابيح الضوئية.
من المحتمل أن تكون
وظائف الخادم (Lambda) الخدمة الأكثر قابلية للتوسعة في السحابة.
توسيع قاعدة البيانات . سأتحدث عن كيفية بناء قواعد البيانات القابلة للتطوير الخاصة بنا.
تحجيم الشبكة . الجزء الأخير الذي سأفتح فيه جهاز شبكتنا. هذا شيء رائع - يعتقد كل مستخدم في السحابة أنه وحده في السحابة ولا يرى مستأجرين آخرين على الإطلاق.
المذكرة. سوف تركز هذه المقالة على تحسين الخادم وتوسيع نطاق قاعدة البيانات. ستتم مناقشة توسيع الشبكة في المقالة التالية. أين هي وظائف serverless؟ ظهر نسخة منفصلة عنهم: " مال ، نعم جريئة. Anboxing من الألعاب النارية microvirtuals ". يتحدث عن عدة طرق مختلفة للتحجيم ، ويتم تحليل حل Firecracker بالتفصيل - تعايش مع أفضل صفات الجهاز الظاهري والحاويات.
الخوادم
السحابة سريعة الزوال. ولكن لا تزال هذه الفوقية تجسيد مادي - خوادم. في البداية ، كانت الهندسة المعمارية الكلاسيكية. شرائح x86 القياسية ، بطاقات الشبكة ، Linux ، Xen hypervisor ، التي تدير الأجهزة الافتراضية.
في عام 2012 ، قامت هذه الهندسة بعملها بشكل جيد. Xen كبير المشرفين ، ولكن مع وجود عيب واحد كبير. لديه
النفقات العامة عالية إلى حد ما
لمحاكاة الأجهزة . مع ظهور بطاقات شبكة أو محركات أقراص صلبة جديدة أسرع ، أصبحت هذه النفقات العامة مرتفعة للغاية. كيف تتعامل مع هذه المشكلة؟ قررنا العمل على جبهتين في وقت واحد -
لتحسين كل من الأجهزة و hypervisor . المهمة خطيرة جدا.
تعظيم الاستفادة من الحديد و hypervisor
أن تفعل كل شيء دفعة واحدة ولن تعمل بشكل جيد. ما هو "الخير" كان في البداية غير مفهوم.
قررنا تطبيق نهج تطوري - نغير عنصرًا مهمًا في الهندسة المعمارية ونرميه في الإنتاج.
نحن نخطو على جميع المشاحنات ، نستمع إلى الشكاوى والاقتراحات ثم نغير عنصر آخر. لذلك ، في زيادات صغيرة ، نقوم بتغيير البنية بالكامل بشكل جذري بناءً على تعليقات المستخدمين والدعم.
بدأ التحول في عام 2013 مع أصعب شيء - الشبكة. في الحالات
C3 ، تمت إضافة بطاقة Network Accelerator خاصة إلى بطاقة الشبكة القياسية. كان متصلاً بكابل استرجاع قصير حرفيًا على اللوحة الأمامية. قبيحة ، ولكن غير مرئية في السحابة. ولكن التفاعل المباشر مع الأجهزة تحسنت بشكل أساسي غضب وعرض النطاق الترددي للشبكة.
ثم قررنا التركيز على تحسين الوصول إلى تخزين كتل EBS - تخزين البلوك المرن. هذا هو مزيج من الشبكة والتخزين. تكمن الصعوبة في أنه في حالة وجود بطاقات Network Accelerator في السوق ، فلا توجد طريقة لشراء أجهزة التخزين Accelerator. لذلك ، لجأنا إلى شركة
Annapurna Labs الناشئة ، التي طورت رقائق ASIC الخاصة لنا. سمحت لك بتوصيل وحدات تخزين EBS عن بعد كأجهزة NVMe.
في حالات
C4 ، قمنا بحل مشكلتين. أولاً ، قمنا بتطبيق الأسس المستقبلية للمستقبل بتكنولوجيا NVMe الواعدة ، ولكن الجديدة في ذلك الوقت. الثاني - تفريغ المعالج المركزي بشكل ملحوظ عن طريق نقل معالجة الطلبات إلى EBS إلى بطاقة جديدة. لقد اتضح جيدًا ، لذلك أصبحت أنابورنا لابز جزءًا من أمازون.
بحلول نوفمبر 2017 ، أدركنا أن الوقت قد حان لتغيير برنامج Hypervisor نفسه.
تم تطوير برنامج Hypervisor الجديد بناءً على وحدات KVM kernel المعدلة.
لقد سمح ذلك بتخفيض التكاليف العامة لأجهزة محاكاة بشكل أساسي والعمل مباشرة مع ASICs الجديدة. كانت مثيلات
C5 أول الأجهزة الافتراضية التي يعمل برنامج Hypervisor تحت غطاء محركها. أطلقنا عليه
نيترو .
تطور الحالات على الجدول الزمني.تعمل جميع الأنواع الجديدة من الأجهزة الافتراضية التي ظهرت منذ نوفمبر 2017 على برنامج Hypervisor.
لا تحتوي مثيلات Iron Bare Metal على برنامج مراقبة ، ولكنها تسمى أيضًا Nitro لأنها تستخدم بطاقات Nitro المتخصصة.
على مدار العامين القادمين ، تجاوز عدد أنواع مثيلات نيترو دزينة: A1 ، C5 ، M5 ، T3 ، وغيرها.
أنواع الحالات.كيف سيارات نيترو الحديثة العمل
لديهم ثلاثة مكونات رئيسية: برنامج Hypervisor (الذي تمت مناقشته أعلاه) ، ورقاقة الأمان ، وبطاقات Nitro.
تم دمج
رقاقة الأمان مباشرة في اللوحة الأم. يتحكم في العديد من الوظائف المهمة ، على سبيل المثال ، التحكم في تحميل نظام التشغيل المضيف.
بطاقات نيترو - هناك أربعة أنواع منها. تم تطويرها جميعًا بواسطة Annapurna Labs وتستند إلى ASICs الشائعة. جزء من البرامج الثابتة الخاصة بهم هو أيضا شائع.
أربعة أنواع من بطاقات نيترو.تم تصميم إحدى البطاقات للعمل مع
شبكة VPC . هي التي تكون مرئية في
الأجهزة الظاهرية مثل بطاقة شبكة
ENA - محول الشبكة المرن . كما أنه يغلف حركة المرور عندما يتم إرسالها عبر الشبكة الفعلية (سنتحدث عن ذلك في الجزء الثاني من المقال) ، ويتحكم في جدار حماية مجموعات الأمان ، وهو مسؤول عن التوجيه وأشياء أخرى على الشبكة.
تعمل البطاقات المنفصلة مع تخزين كتل
EBS والأقراص المدمجة في الخادم. يتم تقديمها إلى الأجهزة الظاهرية الضيف مثل
محولات NVMe . كما أنها مسؤولة عن تشفير البيانات ومراقبة القرص.
تم دمج نظام بطاقات Nitro و hypervisor ورقاقة الأمان في شبكة SDN أو
البرامج المعرفة بالبرامج .
بطاقة التحكم مسؤولة عن إدارة هذه الشبكة (طائرة التحكم).
بالطبع ، نواصل تطوير أسيك جديدة. على سبيل المثال ، في نهاية عام 2018 ، أصدروا شريحة Inferentia ، والتي تتيح المزيد من العمل الفعال مع مهام التعلم الآلي.
الجهنمية آلة التعلم المعالج رقاقة.قاعدة بيانات قابلة للتحجيم
قاعدة البيانات التقليدية لديها هيكل الطبقات. إذا تم تبسيطها إلى حد كبير ، يتم تمييز المستويات التالية.
- مزود - العميل والاستعلام المرسلين العمل على ذلك.
- تأمين المعاملات - كل شيء واضح هنا ، ACID وكل ذلك.
- التخزين المؤقت التي توفرها تجمعات العازلة.
- تسجيل - يوفر العمل مع سجلات إعادة. في MySQL يطلق عليهم سجلات Bin ، في PosgreSQL يطلق عليهم Write Ahead Logs (WAL).
- التخزين - الكتابة مباشرة إلى القرص.
هيكل قاعدة البيانات الطبقات.هناك طرق مختلفة لتوسيع نطاق قواعد البيانات: المشاركة ، هندسة لا شيء مشترك ، محركات أقراص مشتركة.
ومع ذلك ، فإن كل هذه الأساليب تحتفظ بنفس بنية قاعدة البيانات المتجانسة. هذا يحد بشكل كبير التحجيم. لحل هذه المشكلة ، قمنا بتطوير قاعدة البيانات الخاصة بنا -
Amazon Aurora . وهو متوافق مع MySQL و PostgreSQL.
الأمازون أورورا
الفكرة المعمارية الرئيسية هي تقسيم مستويات التخزين والتسجيل من قاعدة البيانات الرئيسية.
بالنظر إلى المستقبل ، أقول إننا جعلنا مستوى ذاكرة التخزين المؤقت مستقلًا أيضًا. لم تعد الهندسة المعمارية متراصة ، ونحصل على درجات إضافية من الحرية في توسيع نطاق الكتل الفردية.
مستويات التسجيل والتخزين منفصلة عن قاعدة البيانات.يقوم نظام DBMS التقليدي بكتابة البيانات إلى نظام التخزين في شكل كتل. في Amazon Aurora ، أنشأنا مستودعًا "ذكيًا" يمكنه التحدث بلغة
سجلات الإعادة . في الداخل ، يقوم المستودع بتحويل السجلات إلى كتل بيانات ، ومراقبة سلامتها والنسخ الاحتياطي تلقائيًا.
هذا النهج يسمح لك بتنفيذ أشياء مثيرة للاهتمام مثل
الاستنساخ . إنه يعمل بشكل أساسي بشكل أسرع وأكثر اقتصادا بسبب حقيقة أنه لا يتطلب إنشاء نسخة كاملة من جميع البيانات.
يتم تنفيذ مستوى التخزين كنظام موزع. يتكون من عدد كبير جدًا من الخوادم الفعلية. تتم معالجة كل سجل الإعادة وتخزينها في وقت واحد من قبل
ستة العقد . وهذا يوفر حماية البيانات وموازنة الحمل.
يمكن أن يتحقق تحجيم القراءة باستخدام النسخ المتماثلة المناسبة. التخزين الموزع يلغي الحاجة إلى التزامن بين مثيل قاعدة البيانات الرئيسي الذي من خلاله نكتب البيانات والنسخ المتماثلة الأخرى. البيانات الحالية مضمونة لتكون متاحة لجميع النسخ المتماثلة.
المشكلة الوحيدة هي التخزين المؤقت للبيانات القديمة على النسخ المتماثلة للقراءة. ولكن يتم حل هذه المشكلة عن طريق
نقل كافة سجلات إعادة الإعادة إلى النسخ المتماثلة على الشبكة الداخلية. إذا كان السجل في ذاكرة التخزين المؤقت ، فسيتم وضع علامة غير صالحة ويتم استبداله. إذا لم يكن في ذاكرة التخزين المؤقت ، ثم يتم تجاهلها ببساطة.
اكتشفنا التخزين.
كيفية توسيع نطاق مستويات DBMS
القياس الأفقي هنا أصعب بكثير. لذلك ، دعنا نذهب إلى المسار
المضاعف للقياس الرأسي الكلاسيكي .
لنفترض أن لدينا تطبيقًا يتصل بنظام إدارة قواعد البيانات من خلال عقدة رئيسية.
باستخدام التحجيم العمودي ، نختار عقدة جديدة تحتوي على مزيد من المعالجات والذاكرة.
بعد ذلك ، قم بتبديل التطبيق من العقدة الرئيسية القديمة إلى العقدة الجديدة. هناك مشاكل.
- سيتطلب ذلك تعطلًا ملحوظًا للتطبيق.
- سيكون لدى العقدة الرئيسية الجديدة ذاكرة التخزين المؤقت الباردة. سيكون الحد الأقصى لأداء قاعدة البيانات فقط بعد تحسّن ذاكرة التخزين المؤقت.
كيفية تحسين الوضع؟ ضع وكيلًا بين التطبيق والعقدة الرئيسية.
ماذا سيعطينا؟ الآن لا تحتاج جميع التطبيقات إلى إعادة توجيهها يدويًا إلى عقدة جديدة. يمكن إجراء التبديل تحت وكيل وفي نفس الوقت أسرع بشكل أساسي.
يبدو أن المشكلة قد تم حلها. لكن لا ، ما زلنا نعاني من الحاجة إلى تسخين ذاكرة التخزين المؤقت. بالإضافة إلى ذلك ، ظهرت مشكلة جديدة - الآن الوكيل هو نقطة الفشل المحتملة.
الحل النهائي مع Amazon Aurora Serverless
كيف يمكننا حل هذه المشاكل؟
غادر وكيل . هذه ليست نسخة منفصلة ، ولكن مجموعة كاملة من الوكلاء الموزعة التي من خلالها تتصل التطبيقات بقاعدة البيانات. في حالة حدوث فشل ، يمكن استبدال أي من العقد على الفور تقريبًا.
أضفنا مجموعة من العقد الدافئة من مختلف الأحجام . لذلك ، إذا كان من الضروري تخصيص عقدة جديدة بحجم أكبر أو أصغر ، فهي متوفرة على الفور. لا حاجة لانتظار تحميله.
يتم التحكم في عملية القياس بالكامل بواسطة نظام مراقبة خاص. تراقب المراقبة باستمرار حالة العقدة الرئيسية الحالية. إذا اكتشف ، على سبيل المثال ، أن حمل المعالج قد وصل إلى قيمة حرجة ، فإنه يخطر مجموعة من الحالات الدافئة بضرورة تخصيص عقدة جديدة.
الوكلاء الموزعون والحالات الدافئة والمراقبة.تتوفر عقدة الطاقة المطلوبة. يتم نسخ تجمعات التخزين المؤقت إليه ، ويبدأ النظام في انتظار لحظة آمنة للتبديل.
عادة ما تأتي لحظة التبديل بسرعة كافية. ثم يتم تعليق الاتصال بين الوكيل والعقدة الرئيسية القديمة ، وتبديل جميع الجلسات إلى العقدة الجديدة.
العمل مع استئناف قاعدة البيانات.
يوضح الرسم البياني أن التعليق قصير جدًا حقًا. على الرسم البياني الأزرق ، الحمل ، وعلى الدرجات الحمراء - لحظات التحجيم. الانخفاضات قصيرة الأجل في الرسم البياني الأزرق هي بالضبط هذا التأخير القصير.
بالمناسبة ، يتيح لك Amazon Aurora حفظ قاعدة البيانات وإيقافها تمامًا عندما لا تكون قيد الاستخدام ، على سبيل المثال ، في عطلة نهاية الأسبوع. بعد إيقاف التحميل ، تقلل قاعدة البيانات تدريجياً من قوتها وتنطفئ لفترة من الوقت. عندما يعود الحمل ، سوف يرتفع مرة أخرى بسلاسة.
في الجزء التالي من حديث جهاز Amazon ، سنتحدث عن توسيع نطاق الشبكة. اشترك في النشرة الإخبارية ولا تنزعج حتى لا تفوت هذه المادة.
في HighLoad ++ ، سيقدم Vasily Pantyukhin عرضًا تقديميًا " Houston ، لدينا مشكلة. تصميم أنظمة الأعطال ، وأنماط الأمازون السحابية لتطوير الخدمات الداخلية . " ما يستخدمه مطورو تصميم Amazon لأنماط تصميم النظام الموزعة ، ما هي أسباب فشل الخدمة ، وما هو العمارة المستندة إلى الخلية ، العمل المتواصل ، Shuffle Sharding - سيكون ذلك مثيرًا للاهتمام. قبل أقل من شهر من المؤتمر - حجز التذاكر الخاصة بك . 24 أكتوبر ، وزيادة السعر النهائي.