لقد واجهنا حدودًا عملية غير موثقة لحالات EC2 التي كنا نستخدمها لمجموعة DNS الأساسية لدينا. عادةً ما يعمل تحديد حجم حالات السحابة بناءً على المواصفات التقليدية (المعالج، الذاكرة، إلخ) كما تتوقع، لكن في بعض الأحيان لا ينطبق هذا النموذج التقليدي للأجهزة.
Business in a box.
اكتشف حلولنا.
تحدث إلى فريق المبيعات لدينا
كيف تتبعنا حالات فشل DNS غير المعتادة في AWS
لقد قمنا ببناء SparkPost حول فكرة أن خدمة السحابة مثل خدماتنا يجب أن تكون سحابية الأصل بذاتها. هذا ليس مجرد تظاهر. إنه هيكلنا السحابي الذي يدعم قابلية التوسع والمرونة والموثوقية التي تعتبر جوانب أساسية في خدمة SparkPost. هذه الصفات هي الأسباب الرئيسية التي جعلتنا نبني بنيتنا التحتية على Amazon Web Services (AWS) — ولهذا السبب يمكننا أن نقدم لعملائنا ضمانات مستوى الخدمة ومعدل الانفجار التي لا مثيل لها من قبل أي شخص آخر في القطاع.
لكننا لا ندعي أننا لا نواجه أبدًا تحديات بسبب الأخطاء غير المتوقعة أو حدود التكنولوجيا المتوفرة. لقد واجهنا شيئًا من هذا القبيل يوم الجمعة الماضي، والحادثة أدت إلى تباطؤ متقطع في خدمتنا وتأخير في التسليم لبعض عملائنا.
أولاً دعني أقول، تم حل المشكلة في نفس اليوم. علاوة على ذلك، لم يتم فقدان أي بريد إلكتروني أو بيانات ذات صلة. ومع ذلك، إذا كان تسليم رسائل البريد الإلكتروني الخاصة بك قد تباطأ بسبب هذه المشكلة، يرجى قبول اعتذاري (في الواقع، اعتذار من فريقنا بأكمله). نحن نعلم أنك تعتمد علينا، ومن المحبط عندما لا نؤدي على المستوى الذي تتوقعه.
تحاول بعض الشركات التغاضي عن المشاكل مثل تدهور الخدمة وتأمل ألا يلاحظ أحد. ربما جربت ذلك مع خدمات استخدمتها في الماضي. أنا أعلم أنني قد حدث لي ذلك. لكن هذا ليس طريقتنا في القيام بالأعمال.
كنت أرغب في الكتابة عن هذا الحادث لسبب آخر أيضًا: تعلمنا شيئًا مثيرًا للاهتمام وقيمًا حول هيكل 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 يستفيد من بنيتنا التحتية، آمل أن يكون هذا الشرح لما حدث يوم الجمعة الماضي، وكيف قمنا بحله، مفيداً.
