اليوم الذي وصل فيه نظام أسماء النطاقات الخاص بنا إلى حد غير موثق في خدمات أمازون ويب
طائر
07/02/2017
الهندسة
1 min read
النقاط الرئيسية
واجه SparkPost حدود تدفق الشبكة غير الموثق على نوع معين من مثيلات AWS EC2 التي كانت تدعم مجموعة DNS الأساسية الخاصة به.
لم تكشف أحجام المثيلات التقليدية (CPU، RAM، القرص) عن هذا الاختناق لأن المشكلة كانت مرتبطة بـ حركة مرور الشبكة DNS المجمعة، وليس نقص الموارد.
استخدام DNS للبريد الإلكتروني الصادر بكميات كبيرة هو أمر غير معتاد: ينتج SparkPost ملايين من الاستعلامات DNS لتوجيه النطاق، والمصادقة (SPF/DKIM)، وتفاعلات واجهة برمجة تطبيقات AWS.
لم تكن فشل DNS ناتجة عن ردود DNS غير صحيحة — بل، تم تجاوز عتبات سعة الشبكة على مستوى المثيل بصمت، مما تسبب في فشل واسع النطاق في الاستعلامات.
نظرًا لأن AWS لا توثق هذه الحدود الشبكية اللينة بشكل صريح، تطلب تشخيص المشكلة تعاونًا عميقًا بين فريق SRE في SparkPost ومهندسي AWS.
قام الفريق بحل المشكلة عن طريق نقل خدمات DNS إلى أنواع مثيلات أكبر ذات عرض نطاق شبكة أكبر وإعادة تصميم أجزاء من بنية DNS لتحسين العزل والتبديل في حالات الفشل.
لم يتم فقد أي بيانات أو رسائل العملاء، لكن الحدث سلط الضوء على كيفية إمكانية أن تواجه البنى التحتية المستندة إلى السحاب حدودًا غير متوقعة عند النطاق الكبير — ومدى سرعة إصلاحها بفضل مرونة AWS.
أهم النقاط في الأسئلة والأجوبة
ماذا حدث؟
وصلت مجموعة DNS التابعة لـ SparkPost إلى حد غير متوقع في عرض النطاق الترددي لشبكة AWS، مما تسبب في فشل عمليات البحث عن DNS بشكل متقطع - مما أدى إلى تأخير تسليم البريد الإلكتروني.
لماذا تعطلت DNS أصلاً؟
نظام أسماء النطاقات (DNS) يعتمد بشكل كبير على الاعتماد للخارج في البريد الإلكتروني. كل إرسال يتطلب عدة عمليات بحث (MX، TXT، SPF، DKIM)، لذلك فإن حجم الإرسال العالي = حركة مرور ضخمة عبر نظام أسماء النطاقات.
نمط هذه الحركة تجاوز حدًا غير موثق على نوع مثيل EC2 الذي يستضيف خوادم الأسماء.
كيف يختلف نظام أسماء النطاقات للبريد الإلكتروني عن تطبيقات الويب؟
تطبيقات الويب في الغالب تسحب المحتوى (العملاء يطلبون البيانات).
خدمات توصيل البريد الإلكتروني تدفع الحركة، مما يؤدي إلى تفعيل الكثير من عمليات البحث في DNS — غالبًا مليارات في الشهر.
يعتمد البريد الإلكتروني على DNS للتوجيه والتحقق من الأمان والتعويض عن الفشل.
كيف تجلى الفشل؟
بدأت طلبات DNS تتعطل أو تنتهي في الوقت المحدد
تراجعت قوائم التسليم
زادت فترة الانتظار عبر أجزاء من النظام
لم يُفقد شيء — فقط تأخر.
لماذا كان من الصعب تشخيص ذلك؟
لم يتم توثيق الحد
لم تُظهر مراقبة AWS بشكل صريح الاختناق
بدت جميع المقاييس التقليدية (CPU، RAM، القرص) طبيعية
ظهرت المشكلة فقط تحت نمط حركة مرور DNS معين وعالي الحجم.
كيف أصلح SparkPost ذلك؟
تم الترقية إلى أنواع مثيلات EC2 بحدود أعلى لنقل الشبكة
إعادة هيكلة مجموعات DNS لتكون أكثر مرونة أمام انخفاضات حركة المرور الإجمالية
عملت مع AWS لتحديد أنماط إشارات/تنبيهات أفضل لكشف ذلك في وقت مبكر
هل تم فقدان بيانات العميل أو البريد؟
لا - فقط تم إبطاء التسليم. بمجرد استقرار نظام أسماء النطاقات، استؤنفت جميع الرسائل تسليمها بشكل طبيعي.
ما هي الدرس الأوسع؟
حتى في السحابة، يمكنك مواجهة قيود التوسع غير المرئية — لكن التصاميم السحابية الأصلية تمنحك المرونة للتعافي بسرعة.
تجعل المرونة، والشراكة مع AWS، وممارسات SRE القوية التعافي السريع ممكنًا.
كيف تتبعنا حالات فشل DNS غير العادية في AWS
قمنا ببناء SparkPost حول فكرة أن خدمة سحابية مثل خدماتنا يجب أن تكون سحابية الأصل. هذا ليس مجرد ادعاء. إن بنية السحابة لدينا هي التي تدعم قابلية التوسع والمرونة والموثوقية التي تعد جوانب أساسية في خدمة SparkPost. هذه الصفات هي أسباب رئيسية جعلتنا نبني بنيتنا التحتية فوق خدمات أمازون ويب (AWS)—وهذا هو السبب في أننا قادرون على تقديم مستوى الخدمة وضمانات معدل الذروة لعملائنا والتي لا تضاهيها أي جهة أخرى في هذا المجال.
لكننا لا نتظاهر بأننا لا نتعرض أبدًا للتحديات بسبب أخطاء غير متوقعة أو حدود التكنولوجيا المتاحة. واجهنا شيئًا مثل هذا يوم الجمعة الماضي، وهذا الحادث أدى إلى بطء متقطع في خدمتنا وتأخيرات في التسليم لبعض عملائنا.
أولاً، دعني أقول إن المشكلة قد تم حلها في نفس اليوم. علاوة على ذلك، لم تُفقد أي رسالة بريد إلكتروني أو بيانات ذات صلة. ومع ذلك، إذا كانت عملية تسليم رسائلك الإلكترونية قد تأخرت بسبب هذه المشكلة، فأرجو قبول اعتذاري (في الواقع، اعتذار من فريقنا بأكمله). عززت هذه الحادثة أهمية وجود استراتيجيات نسخ احتياطي شاملة - سواء كنت تستخدم نسخ احتياطية من قاعدة بيانات PostgreSQL أو طرق حماية بيانات أخرى لضمان استمرارية الأعمال خلال تحديات البنية التحتية. نحن نعلم أنك تعتمد علينا، ومن المحبط عندما لا نؤدي بالمستوى الذي تتوقعه.
بعض الشركات تميل إلى إخفاء مشاكل مثل تدهور الخدمة تحت السجاد وتأمل ألا يلاحظ أحد. قد تكون قد واجهت ذلك مع الخدمات التي استخدمتها في الماضي. أعلم أنني قد واجهت ذلك. لكن هذه ليست الطريقة التي نحب أن نعمل بها.
أردت الكتابة عن هذه الحادثة لسبب آخر كذلك: لقد تعلمنا شيئًا مثيرًا للاهتمام وقيمًا حول بنية السحابة AWS لدينا. قد تكون الفرق التي تبني خدمات سحابية أخرى مهتمة بالتعرف عليها.
قمنا ببناء SparkPost حول فكرة أن خدمة سحابية مثل خدماتنا يجب أن تكون سحابية الأصل. هذا ليس مجرد ادعاء. إن بنية السحابة لدينا هي التي تدعم قابلية التوسع والمرونة والموثوقية التي تعد جوانب أساسية في خدمة SparkPost. هذه الصفات هي أسباب رئيسية جعلتنا نبني بنيتنا التحتية فوق خدمات أمازون ويب (AWS)—وهذا هو السبب في أننا قادرون على تقديم مستوى الخدمة وضمانات معدل الذروة لعملائنا والتي لا تضاهيها أي جهة أخرى في هذا المجال.
لكننا لا نتظاهر بأننا لا نتعرض أبدًا للتحديات بسبب أخطاء غير متوقعة أو حدود التكنولوجيا المتاحة. واجهنا شيئًا مثل هذا يوم الجمعة الماضي، وهذا الحادث أدى إلى بطء متقطع في خدمتنا وتأخيرات في التسليم لبعض عملائنا.
أولاً، دعني أقول إن المشكلة قد تم حلها في نفس اليوم. علاوة على ذلك، لم تُفقد أي رسالة بريد إلكتروني أو بيانات ذات صلة. ومع ذلك، إذا كانت عملية تسليم رسائلك الإلكترونية قد تأخرت بسبب هذه المشكلة، فأرجو قبول اعتذاري (في الواقع، اعتذار من فريقنا بأكمله). عززت هذه الحادثة أهمية وجود استراتيجيات نسخ احتياطي شاملة - سواء كنت تستخدم نسخ احتياطية من قاعدة بيانات PostgreSQL أو طرق حماية بيانات أخرى لضمان استمرارية الأعمال خلال تحديات البنية التحتية. نحن نعلم أنك تعتمد علينا، ومن المحبط عندما لا نؤدي بالمستوى الذي تتوقعه.
بعض الشركات تميل إلى إخفاء مشاكل مثل تدهور الخدمة تحت السجاد وتأمل ألا يلاحظ أحد. قد تكون قد واجهت ذلك مع الخدمات التي استخدمتها في الماضي. أعلم أنني قد واجهت ذلك. لكن هذه ليست الطريقة التي نحب أن نعمل بها.
أردت الكتابة عن هذه الحادثة لسبب آخر كذلك: لقد تعلمنا شيئًا مثيرًا للاهتمام وقيمًا حول بنية السحابة AWS لدينا. قد تكون الفرق التي تبني خدمات سحابية أخرى مهتمة بالتعرف عليها.
قمنا ببناء SparkPost حول فكرة أن خدمة سحابية مثل خدماتنا يجب أن تكون سحابية الأصل. هذا ليس مجرد ادعاء. إن بنية السحابة لدينا هي التي تدعم قابلية التوسع والمرونة والموثوقية التي تعد جوانب أساسية في خدمة SparkPost. هذه الصفات هي أسباب رئيسية جعلتنا نبني بنيتنا التحتية فوق خدمات أمازون ويب (AWS)—وهذا هو السبب في أننا قادرون على تقديم مستوى الخدمة وضمانات معدل الذروة لعملائنا والتي لا تضاهيها أي جهة أخرى في هذا المجال.
لكننا لا نتظاهر بأننا لا نتعرض أبدًا للتحديات بسبب أخطاء غير متوقعة أو حدود التكنولوجيا المتاحة. واجهنا شيئًا مثل هذا يوم الجمعة الماضي، وهذا الحادث أدى إلى بطء متقطع في خدمتنا وتأخيرات في التسليم لبعض عملائنا.
أولاً، دعني أقول إن المشكلة قد تم حلها في نفس اليوم. علاوة على ذلك، لم تُفقد أي رسالة بريد إلكتروني أو بيانات ذات صلة. ومع ذلك، إذا كانت عملية تسليم رسائلك الإلكترونية قد تأخرت بسبب هذه المشكلة، فأرجو قبول اعتذاري (في الواقع، اعتذار من فريقنا بأكمله). عززت هذه الحادثة أهمية وجود استراتيجيات نسخ احتياطي شاملة - سواء كنت تستخدم نسخ احتياطية من قاعدة بيانات PostgreSQL أو طرق حماية بيانات أخرى لضمان استمرارية الأعمال خلال تحديات البنية التحتية. نحن نعلم أنك تعتمد علينا، ومن المحبط عندما لا نؤدي بالمستوى الذي تتوقعه.
بعض الشركات تميل إلى إخفاء مشاكل مثل تدهور الخدمة تحت السجاد وتأمل ألا يلاحظ أحد. قد تكون قد واجهت ذلك مع الخدمات التي استخدمتها في الماضي. أعلم أنني قد واجهت ذلك. لكن هذه ليست الطريقة التي نحب أن نعمل بها.
أردت الكتابة عن هذه الحادثة لسبب آخر كذلك: لقد تعلمنا شيئًا مثيرًا للاهتمام وقيمًا حول بنية السحابة AWS لدينا. قد تكون الفرق التي تبني خدمات سحابية أخرى مهتمة بالتعرف عليها.
ملخص
واجهنا حدودًا عملية غير موثقة للنسخ الاحتياطي EC2 التي كنا نستخدمها لعنقود DNS الأساسي لدينا. يعدّ توسيع حالة السحابة استنادًا إلى المواصفات التقليدية (المعالج، الذاكرة، وما إلى ذلك) عادةً كما تتوقع، لكن في بعض الأحيان لا ينطبق هذا النموذج التقليدي للأجهزة. هذا صحيح بشكل خاص في حالات الاستخدام غير العادية حيث يمكن أن تأتي الحدود التراكمية إلى اللعب - وهناك أوقات تواجه فيها تلك السيناريوهات فجأة دون تحذير.
وصلنا إلى مثل هذه الحدود يوم الجمعة عندما خلق حجم استعلام DNS لدينا نمط استخدام للشبكة لم يكن نوع نسختنا مستعدًا له. ومع ذلك، نظرًا لأن تلك الحدود لم تكن واضحة من الوثائق أو المقاييس القياسية المتاحة، لم نكن نعلم أننا قد وصلنا إليها. ما لاحظناه كان معدلًا عاليًا جدًا من فشل DNS، مما أدى بدوره إلى تأخيرات متقطعة في نقاط مختلفة من بنيتنا المعمارية.
واجهنا حدودًا عملية غير موثقة للنسخ الاحتياطي EC2 التي كنا نستخدمها لعنقود DNS الأساسي لدينا. يعدّ توسيع حالة السحابة استنادًا إلى المواصفات التقليدية (المعالج، الذاكرة، وما إلى ذلك) عادةً كما تتوقع، لكن في بعض الأحيان لا ينطبق هذا النموذج التقليدي للأجهزة. هذا صحيح بشكل خاص في حالات الاستخدام غير العادية حيث يمكن أن تأتي الحدود التراكمية إلى اللعب - وهناك أوقات تواجه فيها تلك السيناريوهات فجأة دون تحذير.
وصلنا إلى مثل هذه الحدود يوم الجمعة عندما خلق حجم استعلام DNS لدينا نمط استخدام للشبكة لم يكن نوع نسختنا مستعدًا له. ومع ذلك، نظرًا لأن تلك الحدود لم تكن واضحة من الوثائق أو المقاييس القياسية المتاحة، لم نكن نعلم أننا قد وصلنا إليها. ما لاحظناه كان معدلًا عاليًا جدًا من فشل DNS، مما أدى بدوره إلى تأخيرات متقطعة في نقاط مختلفة من بنيتنا المعمارية.
واجهنا حدودًا عملية غير موثقة للنسخ الاحتياطي EC2 التي كنا نستخدمها لعنقود DNS الأساسي لدينا. يعدّ توسيع حالة السحابة استنادًا إلى المواصفات التقليدية (المعالج، الذاكرة، وما إلى ذلك) عادةً كما تتوقع، لكن في بعض الأحيان لا ينطبق هذا النموذج التقليدي للأجهزة. هذا صحيح بشكل خاص في حالات الاستخدام غير العادية حيث يمكن أن تأتي الحدود التراكمية إلى اللعب - وهناك أوقات تواجه فيها تلك السيناريوهات فجأة دون تحذير.
وصلنا إلى مثل هذه الحدود يوم الجمعة عندما خلق حجم استعلام DNS لدينا نمط استخدام للشبكة لم يكن نوع نسختنا مستعدًا له. ومع ذلك، نظرًا لأن تلك الحدود لم تكن واضحة من الوثائق أو المقاييس القياسية المتاحة، لم نكن نعلم أننا قد وصلنا إليها. ما لاحظناه كان معدلًا عاليًا جدًا من فشل DNS، مما أدى بدوره إلى تأخيرات متقطعة في نقاط مختلفة من بنيتنا المعمارية.
التعمق في نظام اسماء النطاقات (DNS)
لماذا يعتبر استخدام نظام أسماء النطاقات لدينا مميزًا؟ حسنًا، يتعلق الأمر إلى حد كبير بالطريقة التي تعمل بها رسائل البريد الإلكتروني، مقارنةً بنموذج المحتوى الذي تم تصميم AWS لأجله في الأصل. يستفيد تسليم المحتوى المستند إلى الويب بشكل كبير من السيناريوهات التقليدية المعروفة بوضع "سحب" القادم: يطلب العميل البيانات، سواء كانت HTML أو تدفقات فيديو أو أي شيء آخر، من السحاب. ولكن استخدام خدمات رسائل البريد مثل SparkPost يعد استثناءً للسيناريو العادي لـ AWS. في حالتنا، نقوم بالكثير من دفع حركة المرور الخارجة: وبالتحديد، البريد الإلكتروني (وأنواع الرسائل الأخرى مثل SMS أو إشعارات الدفع إلى الهواتف المحمولة). وتعتمد حركة المرور من هذا النوع بشكل كبير على نظام أسماء النطاقات.
إذا كنت معتادًا على نظام أسماء النطاقات، فقد تعلم أنه عادة ما يكون بيانات خفيفة جدًا. لطلب صفحة HTML معينة، يجب عليك أولاً أن تسأل أين يمكن العثور على تلك الصفحة على الإنترنت، لكن هذا الطلب هو جزء ضئيل من حجم المحتوى الذي تسترده.
ومع ذلك، يستخدم البريد الإلكتروني بشكل استثنائي نظام أسماء النطاقات للبحث عن مجالات التسليم، على سبيل المثال، ترسل SparkPost العديد من المليارات من رسائل البريد الإلكتروني إلى أكثر من مليون نطاق فريد كل شهر. لكل بريد إلكتروني نقوم بتوصيله، يجب علينا إجراء حد أدنى من عمليتي بحث عن نظام أسماء النطاقات، ويعني استخدام سجلات “txt” الخاصة بـ DNS لتقنيات مكافحة التصيد مثل SPF و DKIM أن نظام أسماء النطاقات مطلوب أيضًا لاستلام البريد. بالإضافة إلى ذلك، فإن استخدامنا الأكثر تقليدية لخدمات واجهات برمجة التطبيقات من AWS لتطبيقاتنا يجعل من الصعب المبالغة في أهمية نظام أسماء النطاقات بالنسبة لبنيتنا التحتية.
كل هذا يعني أننا واجهنا حالة غير عادية حيث أدى حجم رسائلنا الخارجة المتزايد إلى خلق حجم حركة مرور DNS يصل إلى حد سعة الشبكة الإجمالية على أنواع المثيلات التي بدت خلاف ذلك أنها تمتلك موارد كافية للتعامل مع ذلك الحمل. وكما أظهرت هجمات الحرمان من الخدمة على بنية DNS الخاصة بـ Dyn العام الماضي، عندما يتعطل DNS، يتعطل كل شيء. (هذا شيء يعرفه أي شخص يبني أنظمة تعتمد على نظام أسماء النطاقات بشكل مؤلم جيدًا).
أدت المشكلات المفاجئة في نظام أسماء النطاقات إلى استجابة من فرق العمليات والهندسة الموثوقة لدينا لتحديد المشكلة. تعاونوا مع شركائنا في أمازون لتصعيد الأمور من جانب عمليات AWS. بالتعاون، حددنا السبب والحل. نشرنا مجموعة من خوادم الأسماء ذات السعة الأكبر مع تركيز أكبر على سعة الشبكة التي يمكن أن تلبي احتياجات DNS لدينا دون الوصول إلى الخطوط الحمراء للقدرة على النقل. ولحسن الحظ، نظرًا لأن كل هذا كان ضمن AWS، تمكنا من إنشاء المثيلات الجديدة وتغيير حجم المثيلات الموجودة بسرعة. استأنف نظام أسماء النطاقات سلوكه الطبيعي، وتوقفت حالات الفشل في البحث، وعدنا (وتم تسليم الرسائل الخارجة) إلى المسار الصحيح.
لتخفيف هذا المشكلة المحددة في المستقبل، نجري أيضًا تغييرات في هيكل نظام أسماء النطاقات لتحسين عزل مكوناتنا الأساسية عن تأثير التعامل مع عتبات غير متوقعة مشابهة. نحن نعمل أيضًا مع فريق أمازون لتحديد نماذج المراقبة المناسبة التي ستمنحنا تحذيرًا كافيًا لدرء حادث مشابه قبل أن يؤثر على أي من عملائنا.
الموضوع | حمل عمل AWS النموذجي | حمل رسائل البريد الإلكتروني الخارجة من SparkPost |
|---|---|---|
نمط الحركة | طلبات "سحب" واردة بشكل أساسي (صفحات الويب، واجهات برمجة التطبيقات، الوسائط) | حركة مرور "دفع" ثقيلة (مليارات من رسائل البريد الإلكتروني) |
اعتماد DNS | خفيف: 1-2 بحث لكل طلب محتوى | ثقيل جدًا: عمليات بحث متعددة في DNS لكل بريد إلكتروني + فحوصات TXT لـ SPF/DKIM |
حجم الاستعلام | يمكن التنبؤ به ويتناسب مع نشاط المستخدم | ينفجر مع الحملات الخارجية المستهدفة لملايين النطاقات |
نوع الاختناق | حدود CPU أو الذاكرة أو التخزين | حدود سعة الشبكة الإجمالية على أنواع المثيلات |
وضع الفشل | تأخر منخفض أو انتهاء وقت واجهة برمجة التطبيقات | فشل بحث DNS مما يؤدي إلى تأخيرات في التسليم |
الرؤية | تُوثق الحدود عادةً وتظهر في المقاييس | كان سقف القدرة على النقل غير موثق وغير مرئي في CloudWatch |
نهج التخفيف | توسيع موارد المثيلات أو إضافة التخزين المؤقت | الانتقال إلى عائلات المثيلات ذات النطاق الترددي العالي + إعادة تصميم هيكل DNS |
لماذا يعتبر استخدام نظام أسماء النطاقات لدينا مميزًا؟ حسنًا، يتعلق الأمر إلى حد كبير بالطريقة التي تعمل بها رسائل البريد الإلكتروني، مقارنةً بنموذج المحتوى الذي تم تصميم AWS لأجله في الأصل. يستفيد تسليم المحتوى المستند إلى الويب بشكل كبير من السيناريوهات التقليدية المعروفة بوضع "سحب" القادم: يطلب العميل البيانات، سواء كانت HTML أو تدفقات فيديو أو أي شيء آخر، من السحاب. ولكن استخدام خدمات رسائل البريد مثل SparkPost يعد استثناءً للسيناريو العادي لـ AWS. في حالتنا، نقوم بالكثير من دفع حركة المرور الخارجة: وبالتحديد، البريد الإلكتروني (وأنواع الرسائل الأخرى مثل SMS أو إشعارات الدفع إلى الهواتف المحمولة). وتعتمد حركة المرور من هذا النوع بشكل كبير على نظام أسماء النطاقات.
إذا كنت معتادًا على نظام أسماء النطاقات، فقد تعلم أنه عادة ما يكون بيانات خفيفة جدًا. لطلب صفحة HTML معينة، يجب عليك أولاً أن تسأل أين يمكن العثور على تلك الصفحة على الإنترنت، لكن هذا الطلب هو جزء ضئيل من حجم المحتوى الذي تسترده.
ومع ذلك، يستخدم البريد الإلكتروني بشكل استثنائي نظام أسماء النطاقات للبحث عن مجالات التسليم، على سبيل المثال، ترسل SparkPost العديد من المليارات من رسائل البريد الإلكتروني إلى أكثر من مليون نطاق فريد كل شهر. لكل بريد إلكتروني نقوم بتوصيله، يجب علينا إجراء حد أدنى من عمليتي بحث عن نظام أسماء النطاقات، ويعني استخدام سجلات “txt” الخاصة بـ DNS لتقنيات مكافحة التصيد مثل SPF و DKIM أن نظام أسماء النطاقات مطلوب أيضًا لاستلام البريد. بالإضافة إلى ذلك، فإن استخدامنا الأكثر تقليدية لخدمات واجهات برمجة التطبيقات من AWS لتطبيقاتنا يجعل من الصعب المبالغة في أهمية نظام أسماء النطاقات بالنسبة لبنيتنا التحتية.
كل هذا يعني أننا واجهنا حالة غير عادية حيث أدى حجم رسائلنا الخارجة المتزايد إلى خلق حجم حركة مرور DNS يصل إلى حد سعة الشبكة الإجمالية على أنواع المثيلات التي بدت خلاف ذلك أنها تمتلك موارد كافية للتعامل مع ذلك الحمل. وكما أظهرت هجمات الحرمان من الخدمة على بنية DNS الخاصة بـ Dyn العام الماضي، عندما يتعطل DNS، يتعطل كل شيء. (هذا شيء يعرفه أي شخص يبني أنظمة تعتمد على نظام أسماء النطاقات بشكل مؤلم جيدًا).
أدت المشكلات المفاجئة في نظام أسماء النطاقات إلى استجابة من فرق العمليات والهندسة الموثوقة لدينا لتحديد المشكلة. تعاونوا مع شركائنا في أمازون لتصعيد الأمور من جانب عمليات AWS. بالتعاون، حددنا السبب والحل. نشرنا مجموعة من خوادم الأسماء ذات السعة الأكبر مع تركيز أكبر على سعة الشبكة التي يمكن أن تلبي احتياجات DNS لدينا دون الوصول إلى الخطوط الحمراء للقدرة على النقل. ولحسن الحظ، نظرًا لأن كل هذا كان ضمن AWS، تمكنا من إنشاء المثيلات الجديدة وتغيير حجم المثيلات الموجودة بسرعة. استأنف نظام أسماء النطاقات سلوكه الطبيعي، وتوقفت حالات الفشل في البحث، وعدنا (وتم تسليم الرسائل الخارجة) إلى المسار الصحيح.
لتخفيف هذا المشكلة المحددة في المستقبل، نجري أيضًا تغييرات في هيكل نظام أسماء النطاقات لتحسين عزل مكوناتنا الأساسية عن تأثير التعامل مع عتبات غير متوقعة مشابهة. نحن نعمل أيضًا مع فريق أمازون لتحديد نماذج المراقبة المناسبة التي ستمنحنا تحذيرًا كافيًا لدرء حادث مشابه قبل أن يؤثر على أي من عملائنا.
الموضوع | حمل عمل AWS النموذجي | حمل رسائل البريد الإلكتروني الخارجة من SparkPost |
|---|---|---|
نمط الحركة | طلبات "سحب" واردة بشكل أساسي (صفحات الويب، واجهات برمجة التطبيقات، الوسائط) | حركة مرور "دفع" ثقيلة (مليارات من رسائل البريد الإلكتروني) |
اعتماد DNS | خفيف: 1-2 بحث لكل طلب محتوى | ثقيل جدًا: عمليات بحث متعددة في DNS لكل بريد إلكتروني + فحوصات TXT لـ SPF/DKIM |
حجم الاستعلام | يمكن التنبؤ به ويتناسب مع نشاط المستخدم | ينفجر مع الحملات الخارجية المستهدفة لملايين النطاقات |
نوع الاختناق | حدود CPU أو الذاكرة أو التخزين | حدود سعة الشبكة الإجمالية على أنواع المثيلات |
وضع الفشل | تأخر منخفض أو انتهاء وقت واجهة برمجة التطبيقات | فشل بحث DNS مما يؤدي إلى تأخيرات في التسليم |
الرؤية | تُوثق الحدود عادةً وتظهر في المقاييس | كان سقف القدرة على النقل غير موثق وغير مرئي في CloudWatch |
نهج التخفيف | توسيع موارد المثيلات أو إضافة التخزين المؤقت | الانتقال إلى عائلات المثيلات ذات النطاق الترددي العالي + إعادة تصميم هيكل DNS |
لماذا يعتبر استخدام نظام أسماء النطاقات لدينا مميزًا؟ حسنًا، يتعلق الأمر إلى حد كبير بالطريقة التي تعمل بها رسائل البريد الإلكتروني، مقارنةً بنموذج المحتوى الذي تم تصميم AWS لأجله في الأصل. يستفيد تسليم المحتوى المستند إلى الويب بشكل كبير من السيناريوهات التقليدية المعروفة بوضع "سحب" القادم: يطلب العميل البيانات، سواء كانت HTML أو تدفقات فيديو أو أي شيء آخر، من السحاب. ولكن استخدام خدمات رسائل البريد مثل SparkPost يعد استثناءً للسيناريو العادي لـ AWS. في حالتنا، نقوم بالكثير من دفع حركة المرور الخارجة: وبالتحديد، البريد الإلكتروني (وأنواع الرسائل الأخرى مثل SMS أو إشعارات الدفع إلى الهواتف المحمولة). وتعتمد حركة المرور من هذا النوع بشكل كبير على نظام أسماء النطاقات.
إذا كنت معتادًا على نظام أسماء النطاقات، فقد تعلم أنه عادة ما يكون بيانات خفيفة جدًا. لطلب صفحة HTML معينة، يجب عليك أولاً أن تسأل أين يمكن العثور على تلك الصفحة على الإنترنت، لكن هذا الطلب هو جزء ضئيل من حجم المحتوى الذي تسترده.
ومع ذلك، يستخدم البريد الإلكتروني بشكل استثنائي نظام أسماء النطاقات للبحث عن مجالات التسليم، على سبيل المثال، ترسل SparkPost العديد من المليارات من رسائل البريد الإلكتروني إلى أكثر من مليون نطاق فريد كل شهر. لكل بريد إلكتروني نقوم بتوصيله، يجب علينا إجراء حد أدنى من عمليتي بحث عن نظام أسماء النطاقات، ويعني استخدام سجلات “txt” الخاصة بـ DNS لتقنيات مكافحة التصيد مثل SPF و DKIM أن نظام أسماء النطاقات مطلوب أيضًا لاستلام البريد. بالإضافة إلى ذلك، فإن استخدامنا الأكثر تقليدية لخدمات واجهات برمجة التطبيقات من AWS لتطبيقاتنا يجعل من الصعب المبالغة في أهمية نظام أسماء النطاقات بالنسبة لبنيتنا التحتية.
كل هذا يعني أننا واجهنا حالة غير عادية حيث أدى حجم رسائلنا الخارجة المتزايد إلى خلق حجم حركة مرور DNS يصل إلى حد سعة الشبكة الإجمالية على أنواع المثيلات التي بدت خلاف ذلك أنها تمتلك موارد كافية للتعامل مع ذلك الحمل. وكما أظهرت هجمات الحرمان من الخدمة على بنية DNS الخاصة بـ Dyn العام الماضي، عندما يتعطل DNS، يتعطل كل شيء. (هذا شيء يعرفه أي شخص يبني أنظمة تعتمد على نظام أسماء النطاقات بشكل مؤلم جيدًا).
أدت المشكلات المفاجئة في نظام أسماء النطاقات إلى استجابة من فرق العمليات والهندسة الموثوقة لدينا لتحديد المشكلة. تعاونوا مع شركائنا في أمازون لتصعيد الأمور من جانب عمليات AWS. بالتعاون، حددنا السبب والحل. نشرنا مجموعة من خوادم الأسماء ذات السعة الأكبر مع تركيز أكبر على سعة الشبكة التي يمكن أن تلبي احتياجات DNS لدينا دون الوصول إلى الخطوط الحمراء للقدرة على النقل. ولحسن الحظ، نظرًا لأن كل هذا كان ضمن AWS، تمكنا من إنشاء المثيلات الجديدة وتغيير حجم المثيلات الموجودة بسرعة. استأنف نظام أسماء النطاقات سلوكه الطبيعي، وتوقفت حالات الفشل في البحث، وعدنا (وتم تسليم الرسائل الخارجة) إلى المسار الصحيح.
لتخفيف هذا المشكلة المحددة في المستقبل، نجري أيضًا تغييرات في هيكل نظام أسماء النطاقات لتحسين عزل مكوناتنا الأساسية عن تأثير التعامل مع عتبات غير متوقعة مشابهة. نحن نعمل أيضًا مع فريق أمازون لتحديد نماذج المراقبة المناسبة التي ستمنحنا تحذيرًا كافيًا لدرء حادث مشابه قبل أن يؤثر على أي من عملائنا.
الموضوع | حمل عمل AWS النموذجي | حمل رسائل البريد الإلكتروني الخارجة من SparkPost |
|---|---|---|
نمط الحركة | طلبات "سحب" واردة بشكل أساسي (صفحات الويب، واجهات برمجة التطبيقات، الوسائط) | حركة مرور "دفع" ثقيلة (مليارات من رسائل البريد الإلكتروني) |
اعتماد DNS | خفيف: 1-2 بحث لكل طلب محتوى | ثقيل جدًا: عمليات بحث متعددة في DNS لكل بريد إلكتروني + فحوصات TXT لـ SPF/DKIM |
حجم الاستعلام | يمكن التنبؤ به ويتناسب مع نشاط المستخدم | ينفجر مع الحملات الخارجية المستهدفة لملايين النطاقات |
نوع الاختناق | حدود CPU أو الذاكرة أو التخزين | حدود سعة الشبكة الإجمالية على أنواع المثيلات |
وضع الفشل | تأخر منخفض أو انتهاء وقت واجهة برمجة التطبيقات | فشل بحث DNS مما يؤدي إلى تأخيرات في التسليم |
الرؤية | تُوثق الحدود عادةً وتظهر في المقاييس | كان سقف القدرة على النقل غير موثق وغير مرئي في CloudWatch |
نهج التخفيف | توسيع موارد المثيلات أو إضافة التخزين المؤقت | الانتقال إلى عائلات المثيلات ذات النطاق الترددي العالي + إعادة تصميم هيكل DNS |
AWS والجانب الإيجابي للسحابة
لا أريد تزيين تأثير هذه الحادثة على عملائنا. ولكن قدرتنا على تحديد القضية الأساسية كالتفاعل غير المتوقع بين استخدامنا وحالة استخدامنا مع بنية AWS التحتية - ثم إيجاد حل لها في وقت قصير جدًا - لها علاقة كبيرة بكيفية بناء SparkPost، وعلاقتنا الرائعة مع فريق أمازون.
تعمل فرق العمليات الممتازة في SparkPost، وفريق هندسة الموثوقية (SRE)، والمعماريون الفنيون الرئيسيون لدينا مع أمازون كل يوم. لقد منحنا صمود بنية AWS التحتية دفعة حقيقية في تحسين بنية SparkPost للسحابة. لقد علمتنا العمل عن كثب مع AWS على مدى العامين الماضيين الكثير عن تشغيل بنية AWS التحتية بسرعة، ولدينا أيضًا فائدة الدعم العميق من فريق AWS.
إذا كان علينا العمل حول قيود مشابهة في نموذج مركز البيانات التقليدي، فقد يستغرق الأمر أيامًا أو حتى أسابيع لحلها بالكامل. تلك المرونة والاستجابة هي مجرد اثنين من الأسباب التي جعلتنا نراهن على أعمالنا في السحابة وAWS. معًا، فإن نوع الخبرة السحابية التي تشاركها شركاتنا يصعب الحصول عليها. كانت أمازون شريكًا تجاريًا رائعًا لنا، ونفخر حقًا بما أنجزناه مع تكوين AWS.
SparkPost هي أول خدمة تسليم البريد الإلكتروني تم بناؤها للسحابة منذ البداية. إن هذا النهج السحابي هو جوهري لكيفية تصميمنا واجهات برمجة التطبيقات البريد الإلكتروني للبنية التحتية السحابية، مما يضمن القابلية للتوسع والموثوقية للمطورين. نحن نرسل المزيد من البريد الإلكتروني من منصة سحابية حقيقية أكثر من أي شخص آخر، وأحيانًا يعني ذلك دخول أراضٍ غير مستكشفة. إنها حقيقة أساسية في علوم الحاسوب أنك لا تعرف التحديات التي تحدث عند المقاييس حتى تواجهها. وجدنا واحدة في AWS، لكن استجابتنا السريعة هي مثال رائع على المرونة التي تجعلها السحابة ممكنة. إنها أيضًا التزامنا تجاه عملائنا.
سواء كنت تبني بنيتك التحتية الخاصة على AWS، أو كنت عميلًا لـ SparkPost يستفيد من بنيتنا، آمل أن تكون هذه الشرح لما حدث يوم الجمعة الماضية، وكيف قمنا بحله، مفيدًا.
لا أريد تزيين تأثير هذه الحادثة على عملائنا. ولكن قدرتنا على تحديد القضية الأساسية كالتفاعل غير المتوقع بين استخدامنا وحالة استخدامنا مع بنية AWS التحتية - ثم إيجاد حل لها في وقت قصير جدًا - لها علاقة كبيرة بكيفية بناء SparkPost، وعلاقتنا الرائعة مع فريق أمازون.
تعمل فرق العمليات الممتازة في SparkPost، وفريق هندسة الموثوقية (SRE)، والمعماريون الفنيون الرئيسيون لدينا مع أمازون كل يوم. لقد منحنا صمود بنية AWS التحتية دفعة حقيقية في تحسين بنية SparkPost للسحابة. لقد علمتنا العمل عن كثب مع AWS على مدى العامين الماضيين الكثير عن تشغيل بنية AWS التحتية بسرعة، ولدينا أيضًا فائدة الدعم العميق من فريق AWS.
إذا كان علينا العمل حول قيود مشابهة في نموذج مركز البيانات التقليدي، فقد يستغرق الأمر أيامًا أو حتى أسابيع لحلها بالكامل. تلك المرونة والاستجابة هي مجرد اثنين من الأسباب التي جعلتنا نراهن على أعمالنا في السحابة وAWS. معًا، فإن نوع الخبرة السحابية التي تشاركها شركاتنا يصعب الحصول عليها. كانت أمازون شريكًا تجاريًا رائعًا لنا، ونفخر حقًا بما أنجزناه مع تكوين AWS.
SparkPost هي أول خدمة تسليم البريد الإلكتروني تم بناؤها للسحابة منذ البداية. إن هذا النهج السحابي هو جوهري لكيفية تصميمنا واجهات برمجة التطبيقات البريد الإلكتروني للبنية التحتية السحابية، مما يضمن القابلية للتوسع والموثوقية للمطورين. نحن نرسل المزيد من البريد الإلكتروني من منصة سحابية حقيقية أكثر من أي شخص آخر، وأحيانًا يعني ذلك دخول أراضٍ غير مستكشفة. إنها حقيقة أساسية في علوم الحاسوب أنك لا تعرف التحديات التي تحدث عند المقاييس حتى تواجهها. وجدنا واحدة في AWS، لكن استجابتنا السريعة هي مثال رائع على المرونة التي تجعلها السحابة ممكنة. إنها أيضًا التزامنا تجاه عملائنا.
سواء كنت تبني بنيتك التحتية الخاصة على AWS، أو كنت عميلًا لـ SparkPost يستفيد من بنيتنا، آمل أن تكون هذه الشرح لما حدث يوم الجمعة الماضية، وكيف قمنا بحله، مفيدًا.
لا أريد تزيين تأثير هذه الحادثة على عملائنا. ولكن قدرتنا على تحديد القضية الأساسية كالتفاعل غير المتوقع بين استخدامنا وحالة استخدامنا مع بنية AWS التحتية - ثم إيجاد حل لها في وقت قصير جدًا - لها علاقة كبيرة بكيفية بناء SparkPost، وعلاقتنا الرائعة مع فريق أمازون.
تعمل فرق العمليات الممتازة في SparkPost، وفريق هندسة الموثوقية (SRE)، والمعماريون الفنيون الرئيسيون لدينا مع أمازون كل يوم. لقد منحنا صمود بنية AWS التحتية دفعة حقيقية في تحسين بنية SparkPost للسحابة. لقد علمتنا العمل عن كثب مع AWS على مدى العامين الماضيين الكثير عن تشغيل بنية AWS التحتية بسرعة، ولدينا أيضًا فائدة الدعم العميق من فريق AWS.
إذا كان علينا العمل حول قيود مشابهة في نموذج مركز البيانات التقليدي، فقد يستغرق الأمر أيامًا أو حتى أسابيع لحلها بالكامل. تلك المرونة والاستجابة هي مجرد اثنين من الأسباب التي جعلتنا نراهن على أعمالنا في السحابة وAWS. معًا، فإن نوع الخبرة السحابية التي تشاركها شركاتنا يصعب الحصول عليها. كانت أمازون شريكًا تجاريًا رائعًا لنا، ونفخر حقًا بما أنجزناه مع تكوين AWS.
SparkPost هي أول خدمة تسليم البريد الإلكتروني تم بناؤها للسحابة منذ البداية. إن هذا النهج السحابي هو جوهري لكيفية تصميمنا واجهات برمجة التطبيقات البريد الإلكتروني للبنية التحتية السحابية، مما يضمن القابلية للتوسع والموثوقية للمطورين. نحن نرسل المزيد من البريد الإلكتروني من منصة سحابية حقيقية أكثر من أي شخص آخر، وأحيانًا يعني ذلك دخول أراضٍ غير مستكشفة. إنها حقيقة أساسية في علوم الحاسوب أنك لا تعرف التحديات التي تحدث عند المقاييس حتى تواجهها. وجدنا واحدة في AWS، لكن استجابتنا السريعة هي مثال رائع على المرونة التي تجعلها السحابة ممكنة. إنها أيضًا التزامنا تجاه عملائنا.
سواء كنت تبني بنيتك التحتية الخاصة على AWS، أو كنت عميلًا لـ SparkPost يستفيد من بنيتنا، آمل أن تكون هذه الشرح لما حدث يوم الجمعة الماضية، وكيف قمنا بحله، مفيدًا.
