AWS MSK للمبتدئين: دليل شامل للبدء

إعداد AWS MSK

للبدء مع AWS MSK، أنشئ أولاً حساب AWS الخاص بك. إذا كانت هذه أول مرة تستخدم فيها خدمة AWS، تعلم كيفية إعداد وتكوين حساب AWS الخاص بك باستخدام البرنامج التعليمي الشامل لدينا.

قم بتسجيل الدخول إلى واجهة تحكم إدارة AWS وافتح واجهة تحكم MSK. انقر على “إنشاء مجموعة” لبدء عملية الإعداد. 

البدء مع AWS MSK. مصدر الصورة: AWS

حدد “الإنشاء السريع” للإعدادات الافتراضية، ثم أدخل اسمًا وصفيًا للمجموعة.

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

• نوع العقد: “تخصيص” أو “خادم غير مُدار”
• إصدار Apache Kafka
• نوع الوسيط: “قياسي” أو “سريع”
• حجم الوسيط
• حجم تخزين EBS

خيارات تكوين AWS MSK

يتم إنشاء العنقود دائمًا داخل VPC الخاص بأمازون. يمكنك اختيار استخدام VPC الافتراضي أو تكوين وتحديد VPC مخصص.

الآن، عليك فقط انتظار تنشيط العنقود الخاص بك، والذي قد يستغرق من 15 إلى 30 دقيقة. يمكنك مراقبة حالة عنقودك من صفحة ملخص العنقود، حيث سترى تغيير الحالة من “جارٍ الإنشاء” إلى “نشط”.

استيعاب ومعالجة البيانات مع خدمة AWS MSK

بمجرد إعداد عنقود MSK الخاص بك، ستحتاج إلى إنشاء جهاز عميل لإنتاج البيانات واستهلاكها عبر مواضيع واحدة أو أكثر. نظرًا لأن Apache Kafka يتكامل بشكل جيد مع العديد من منتجي البيانات (مثل المواقع الإلكترونية، أجهزة IoT، حالات Amazon EC2، إلخ)، فإن MSK يشترك أيضًا في هذه الفائدة.

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

مصطلحات رئيسية لمعرفتها عند التعامل مع تجمعات أباتشي كافكا:

• المواضيع هي الطريقة الأساسية لتنظيم البيانات في كافكا.
• المنتجون هم التطبيقات التي تقوم بنشر البيانات إلى المواضيع – ينشئون ويكتبون البيانات في كافكا. يكتبون البيانات على مواضيع وأقسام محددة.
• المستهلكون هي التطبيقات التي تقرأ وتعالج البيانات من المواضيع. إنهم يستخرجون البيانات من المواضيع التي يكونون مشتركين فيها.

عند بناء بنية معمارية مدفوعة بالأحداث باستخدام AWS MSK، تحتاج إلى تكوين عدة طبقات، حيث تعتبر MSK المكون الرئيسي لاستيعاب البيانات. إليك نظرة عامة على الطبقات التي قد تكون مطلوبة:

1. إعداد استيعاب البيانات
2. طبقة المعالجة
3. طبقة التخزين
4. طبقة التحليل

مثال على البنية المعمارية المدفوعة بالأحداث مع Amazon MSK و Amazon EventBridge.مصدر الصورة: AWS

إذا كنت مهتمًا بالاستفادة من لغة Python في سير العمل الخاص بأنابيب البيانات الخاصة بك ، تحقق من دورتنا مقدمة إلى AWS Boto في Python.

أفضل الممارسات لاستخدام AWS MSK

يُعتبر AWS MSK نسبيًا سهلًا للإعداد والبدء في استخدامه على الفور. ومع ذلك ، ستحسن بعض الممارسات الأساسية الأداء لعناقيدك وتوفر لك الوقت لاحقًا.

ضبط حجم العنقود الخاص بك

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

عدد من العوامل يمكن أن تؤثر على قراراتك هنا؛ ومع ذلك، قدمت خدمة AWS بعض التوصيات والموارد المفيدة لتوجيهك خلال هذه العملية.

بالإضافة إلى ذلك، توفر خدمة AWS جدول تحديد الحجم والتسعير بسهولة لمساعدتك في تقدير الحجم الصحيح لعنقودتك والتكاليف المرتبطة باستخدام AWS MSK مقابل عنقود Kafka EC2 الذاتي المُدار بنفسك.

بناء عناقيد متاحة بشكل عالي

توصي خدمة AWS بإعداد عناقيدك لتكون متاحة بشكل عالي. هذا أمر مهم بشكل خاص عند أداء تحديث (مثل تحديث إصدار Apache Kafka) أو عندما تقوم AWS باستبدال وسيط.

لضمان أن عناقيدك متاحة بشكل عالي، يجب عليك القيام بثلاثة أشياء:

1. قم بإعداد عناقيدك عبر ثلاث مناطق توافر (معروفة أيضًا باسم عنقود ثلاثي المناطق).
2. قم بتعيين عامل التكرار إلى 3 أو أكثر.
3. قم بتعيين الحد الأدنى لعدد النسخ المتزامنة إلى RF-1.

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

راقب استخدام القرص ووحدة المعالجة المركزية

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

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

بالإضافة إلى ذلك، للحفاظ على أداء الكلستر الخاص بك وتجنب الاختناقات، توصي AWS بالحفاظ على إجمالي استخدام وحدة المعالجة المركزية للوسطاء تحت 60%. يمكنك مراقبة ذلك باستخدام AWS CloudWatch ثم اتخاذ إجراءات تصحيحية عن طريق تحديث حجم الوسيط، على سبيل المثال.

احمِ بياناتك باستخدام التشفير أثناء النقل

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

تحقق من دورتنا إدارة أمان AWS والتكاليف لمعرفة المزيد حول كيفية تأمين وتحسين بيئة AWS السحابية الخاصة بك وإدارة التكاليف والموارد في AWS.

مقارنة AWS MSK بأدوات البث الأخرى

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

AWS MSK مقابل Apache Kafka على EC2

الصراع الرئيسي بين MSK والخيار الذي يستضيف بنفسه باستخدام EC2 هو بين الراحة والتحكم: يمنحك MSK أقل ما يجب إدارته ولكن أقل مرونة، بينما يمنحك EC2 تحكمًا كاملاً ولكن يتطلب المزيد من العمل.

يتولى AWS MSK جميع المهام التشغيلية المعقدة، مع التوفير التلقائي والتكوين. الجانب الإيجابي في ذلك هو عدم وجود تكاليف تحتية مقدمة. كما يتمتع بتكامل سلس مع خدمات AWS الأخرى وميزات أمان قوية.

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

AWS MSK vs. Kinesis

استخدم Kinesis للبساطة والتكامل العميق مع AWS و MSK لتوافق Kafka أو للحصول على مزيد من التحكم في إعداد البث المباشر الخاص بك.

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

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

إذا لم تكن ملمًا بـ Kinesis، لدينا دورة تدريبية ترشدك خلال العمل مع بيانات البث الحي باستخدام AWS Kinesis و Lambda.

AWS MSK مقابل Confluent

اختر Confluent إذا كنت بحاجة إلى ميزات شاملة ودعم، واختر MSK إذا كنت مستثمرًا بشكل كبير في AWS وتمتلك خبرة في Kafka داخل الشركة.

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

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

الجدول التالي يقدم مقارنة بين AWS MSK وبديلها:

أفكار الختام

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

الحصول على شهادة AWS هو وسيلة ممتازة لبدء حياتك المهنية في AWS. يمكنك بناء مهاراتك في AWS من خلال الاطلاع على كتالوج الدورات والحصول على تجربة عملية من خلال المشاريع!