لقد واجهنا حدودًا عملية غير موثقة لحالات EC2 التي كنا نستخدمها لمجموعة DNS الأساسية لدينا. عادةً ما يعمل تحديد حجم حالات السحابة بناءً على المواصفات التقليدية (المعالج، الذاكرة، إلخ) كما تتوقع، لكن في بعض الأحيان لا ينطبق هذا النموذج التقليدي للأجهزة.
كيف تتبعنا حالات فشل DNS غير المعتادة في AWS
لقد أنشأنا SparkPost حول فكرة أن خدمة سحابية مثلها يجب أن تكون بنفسها سحابية. هذا ليس مجرد ادعاء. إنه هيكلنا السحابي الذي يدعم القابلية للتوسع، والمرونة، والموثوقية التي تعتبر جوانب أساسية لخدمة SparkPost. هذه الصفات هي الأسباب الرئيسية التي جعلتنا نبني بنيتنا التحتية على Amazon Web Services (AWS)—ولهذا السبب يمكننا توفير مستوى خدمة وضمانات معدلات انفجار لعملائنا لا مثيل لها في هذا المجال.
لكننا لا ندعي أننا لا نتحدى أبدًا بالأخطاء غير المتوقعة أو حدود التكنولوجيا المتاحة. واجهنا شيئًا من هذا القبيل يوم الجمعة الماضي، وأدى ذلك الحادث إلى تباطؤ متقطع في خدماتنا وتأخير في التسليم لبعض عملائنا.
أولاً دعوني أقول، تم حل المشكلة في نفس اليوم. وعلاوة على ذلك، لم يتم فقد أي بريد إلكتروني أو بيانات ذات صلة. ومع ذلك، إذا كان تسليم رسائلك الإلكترونية قد تباطأ بسبب هذه المشكلة، فيرجى قبول اعتذاري (في الحقيقة، اعتذاري من فريقنا بأكمله). عزز هذا الحادث أهمية وجود استراتيجيات احتياطية شاملة - سواء كنت تستخدم نسخ احتياطية لقاعدة بيانات PostgreSQL أو طرق حماية بيانات أخرى لضمان استمرارية العمل أثناء تحديات البنية التحتية. نحن نعلم أنك تعتمد علينا، ومن المحبط عندما لا نعمل بالمستوى الذي تتوقعه.
بعض الشركات تميل إلى تجاهل المشكلات مثل تدهور الخدمة وتأمل ألا يلاحظها أحد. قد تكون قد جربت ذلك مع الخدمات التي استخدمتها في الماضي. أعلم أنني قد فعلت ذلك. لكن هذه ليست الطريقة التي نحب أن ندير بها الأعمال.
أردت أن أكتب عن هذا الحادث لسبب آخر أيضًا: تعلمنا شيئًا مثيرًا للاهتمام وقيمًا عن هيكلنا السحابي لدى AWS. قد تكون الفرق التي تبني خدمات سحابية أخرى مهتمة بمعرفة ذلك.
باختصار
التعمق في DNS
لماذا يعد استخدامنا لنظام أسماء النطاقات (DNS) مميزًا؟ حسنًا، إنه يتعلق بشكل كبير بالطريقة التي يعمل بها البريد الإلكتروني، مقارنةً بنموذج المحتوى الذي تم تصميم AWS من أجله في الأصل. يعتمد تسليم المحتوى المستند إلى الويب بشكل كبير على ما قد يُعتبر سيناريوهات "سحب" تقليدية: يطلب العميل البيانات، سواء كانت HTML أو بث فيديو، أو أي شيء آخر، من السحابة. ولكن حالات الاستخدام لمزودي خدمات الرسائل مثل SparkPost تعتبر استثناءً للسيناريو المعتاد لـ AWS. في حالتنا، نقوم بالكثير من دفع حركة المرور الصادرة: وتحديدًا البريد الإلكتروني (وأنواع الرسائل الأخرى مثل الرسائل القصيرة أو إشعارات الدفع عبر الجوال). وتعتمد حركة المرور على أسلوب الدفع بشكل كبير على DNS.
إذا كنت familiar بنظام DNS، قد تعرف أنه عمومًا خفيف البيانات. لطلب صفحة HTML معينة، عليك أولاً أن تسأل عن مكان العثور عليها على الإنترنت، لكن هذا الطلب هو جزء صغير من حجم المحتوى الذي تسترجعه.
ومع ذلك، البريد الإلكتروني يستخدم DNS بشكل مكثف بشكل استثنائي للبحث عن نطاقات التسليم—مثلاً، يرسل SparkPost مليارات عديدة من رسائل البريد الإلكتروني إلى أكثر من مليون نطاق فريد كل شهر. لكل بريد إلكتروني نقوم بتسليمه، علينا القيام بما لا يقل عن عمليتي بحث DNS، واستخدام سجلات DNS "txt" لتقنيات مكافحة الاحتيال مثل SPF وDKIM يعني أن DNS مطلوب أيضًا لتلقي البريد. أضف إلى ذلك استخدامنا الأكثر تقليدية لخدمات API من AWS لتطبيقاتنا، وسيكون من الصعب المبالغة في أهمية DNS لبنيتنا التحتية.
كل هذا يعني أننا واجهنا حالة غير عادية حيث أن الحجم المتزايد لرسائلنا الصادرة أنشأ حجم حركة مرور DNS وصل إلى حد أقصى لتوصيل الشبكة على أنواع مثيلات يبدو بخلاف ذلك أن لديها موارد كافية لخدمة هذا الحمل. وكما أثبتت هجمات حجب الخدمة على بنية DNS التحتية لشركة Dyn العام الماضي، عندما يتعطل DNS، يتعطل كل شيء. (هذا شيء يعرفه جيدًا أي شخص يقوم ببناء أنظمة تعتمد على DNS).
تسببت المشاكل المفاجئة في DNS في استجابة من قبل فرق العمليات والهندسة الموثوقية لتحديد المشكلة. تعاونوا مع شركائنا في Amazon للتصعيد في جانب عمليات AWS. عملنا معًا لتحديد السبب والحل. نشرنا مجموعة من الخوادم المسماة ذات السعة الأكبر مع تركيز أكبر على سعة الشبكة التي يمكن أن تلبي احتياجات DNS دون مواجهة حدود لحجم البيانات المدفوعة. ولحسن الحظ، لأن كل هذا كان داخل AWS، تمكنا من تشغيل المثيلات الجديدة وتغيير حجم المثيلات الحالية بسرعة كبيرة. استأنف DNS السلوك العادي، توقفت حالات فشل البحث، وكنا نحن (وتسليم الرسائل الصادرة) على المسار الصحيح.
لتخفيف من هذه المشكلة المحددة في المستقبل، نقوم أيضًا بإجراء تغييرات في هندسة DNS لعزل مكوناتنا الأساسية بشكل أفضل عن تأثير مواجهة عتبات مماثلة غير متوقعة. نحن نعمل أيضًا مع فريق Amazon لتحديد نماذج المراقبة المناسبة التي ستمنحنا تحذيرات كافية لمنع وقوع حادث مماثل قبل أن يؤثر على أي من عملائنا.
AWS وسحابة الأفق الفضي
لا أريد أن أتغاضى عن تأثير هذا الحادث على عملائنا. لكن قدرتنا على تحديد المشكلة الأساسية كتفاعل غير متوقع لحالة الاستخدام الخاصة بنا مع البنية التحتية لـ AWS - ثم العثور على حل لها في وقت قصير للغاية - له علاقة كبيرة بكيفية قيامنا ببناء SparkPost، وعلاقتنا الرائعة مع فريق أمازون.
إن فريق العمليات الممتاز لـ SparkPost، وفريق هندسة موثوقية الموقع (SRE)، و المهندسين الفنيين الرئيسيين لدينا يعملون مع أمازون كل يوم. لقد أعطت نقاط القوة في البنية التحتية لـ AWS لنا ميزة كبيرة لتحسين بنية SparkPost للغيمة. عملنا عن كثب مع AWS على مدار العامين الماضيين علمنا الكثير أيضًا عن إنشاء البنية التحتية لـ AWS وتشغيلها بسرعة، ولدينا أيضًا ميزة الدعم العميق من فريق AWS.
إذا كان علينا التحايل على قيود مماثلة في نموذج مركز بيانات تقليدي، فقد يستغرق مثل هذا الأمر أيامًا أو حتى أسابيع لحله بشكل كامل. تلك المرونة والاستجابة هما فقط اثنين من الأسباب التي جعلتنا نعتمد أعمالنا على السحابة وAWS. معًا، يعتبر نوع الخبرة السحابية التي تشاركها شركاتنا من الصعب الحصول عليها. كانت أمازون شريكًا عظيميًا للعمل بالنسبة لنا، ونحن فخورون بما أنجزناه مع مجموعة AWS.
SparkPost هو أول خدمة تسليم بريد إلكتروني تم بناؤها للسحابة من البداية. هذا النهج السحابي الأصلي أساسي لكيفية تصميمنا لبريدنا الإلكتروني لواجهات برمجة التطبيقات للبنية التحتية السحابية، مما يضمن القابلية للتوسع والموثوقية للمطورين. نحن نرسل بريدًا إلكترونيًا من منصة حقيقية سحابية أكثر من أي شخص، وأحيانًا يعني ذلك دخول أراضي مجهولة. إنها حقيقة أساسية في علم الحاسوب أنك لا تعرف ما هي التحديات التي تحدث عند المستوى حتى تصل إليها. وجدنا واحدة على AWS، لكن استجابتنا السريعة هي مثال رائع على المرونة التي تجعلها السحابة ممكنة. إنه أيضًا التزامنا تجاه عملائنا.
سواء كنت تقوم ببناء بنيتك التحتية الخاصة على AWS، أو كنت عميل SparkPost الذي يستفيد من بنيتنا التحتية، آمل أن يكون هذا التفسير لما حدث يوم الجمعة الماضي، وكيف حللناه، قد كان مفيداً.
