نشر بتاريخ : 30 الإثنين , مايو, 2022

الانتقال إلى التطبيقات والبيانات السحابية الأصلية (Cloud-Native) باستخدام Kubernetes و Apache Cassandra

يمكن أن تكون إدارة قاعدة بيانات موزعة مثل Cassandra معقدة. لإدارة المعاملات عبر خوادم متعددة ، يتطلب الأمر بعض الفهم للمفاضلات المقدمة في نظرية بروير (Brewer’s Theorem)

 

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

ماذا يعني هذا في الممارسة العملية؟ يتضمن فهم الدور الذي تلعبه الحاويات وأدوات التنسيق في أتمتة تطبيقاتك ، وكيفية استخدام واجهات برمجة التطبيقات بشكل فعال ، وكيف تتأثر العناصر الأخرى مثل البيانات بالتغييرات الديناميكية في البنية التحتية للتطبيق. وبشكل أكثر تحديدًا ، فهذا يعني تشغيل تطبيقك باستخدام حوسبة وتخزين غير محدودين تقريبًا في السحابة جنبًا إلى جنب مع الانتقال إلى البيانات الموزعة. تم تصميم قاعدة بيانات Apache Cassandra القابلة للتطوير الخطي والمتسامحة للغاية مع الأخطاء والمتاحة دائمًا   للبيانات السحابية وأصبحت الآن اختيار المطورين للتطبيقات السحابية الأصلية.

بداية الحكاية

على مدار العشرين عامًا الماضية ، كان هناك العديد من الاتجاهات الكبيرة في الحوسبة الموزعة(distributed computing).  كانت الشبكات الموثوقة على نطاق واسع هي مجال التركيز الكبير في العقد الأول من القرن الحادي والعشرين ، مما مكّن من ربط العديد من المواقع والخدمات معًا حتى تتمكن من العمل بالسرعة والحجم المطلوبين للإنترنت. تبع ذلك في 2010 من خلال نقل الحوسبة والتخزين إلى السحابة ، والتي استخدمت قوة تلك الشبكة الموزعة لربط البنية التحتية للتطبيق معًا عند الطلب مع المرونة. يعمل هذا بشكل جيد مع التطبيق نفسه ، لكنه لا يغير الطريقة التي ندير بها البيانات.

يمكن أن تكون إدارة قاعدة بيانات موزعة مثل Cassandra معقدة. لإدارة المعاملات عبر خوادم متعددة ، يتطلب الأمر بعض الفهم للمفاضلات المقدمة في نظرية بروير (Brewer’s Theorem) والتي تغطي الاتساق والتوافر والتسامح التقسيمي (Consistency, Availability and Partition Tolerance CAP): كيف يمكن لقاعدة البيانات إدارة البيانات عبر العقد ؛ توافر تلك البيانات ؛ وما يحدث في مواقع مختلفة على التوالي. والأهم من ذلك ، أنه يتحكم في كيفية تفاعل قاعدة البيانات عند وجود ظروف غير مثالية - حالات الفشل الحتمية التي تحدث في نظام متعدد الأجزاء.

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

الوضع الحالي

اليوم ، يستخدم المزيد من المطورين تصميمات الخدمات المصغرة (microservices designs) لتحليل التطبيقات إلى وحدات أصغر وأكثر قابلية للإدارة. تحقق كل وحدة غرضًا محددًا يمكن أن يتوسع بشكل مستقل باستخدام الحاويات (containers).  لإدارة حالات الحاوية هذه ، أصبحت أداة تنسيق الحاوية  Kubernetes  هي الاختيار الفعلي.

يمكن لـ Kubernetes إنشاء طبعات حاوية جديدة (new container instances) حسب الحاجة والتي تساعد في قياس مقدار قوة الحوسبة المتاحة لتطبيق ما. وبالمثل ، يتتبع Kubernetes ديناميكيًا صحة الحاويات قيد التشغيل - إذا تعطلت الحاوية ، يتولى Kubernetes إعادة تشغيلها وجدولة استبدال الحاوية الخاصة بها على أجهزة أخرى. يمكنك إنشاء تطبيقات مدعومة بالخدمات المصغرة بسرعة والتأكد من أنها تعمل كما تم تصميمها عبر أي منصة Kubernetes . يعد تمكين أحد التطبيقات من العمل بشكل مستمر دون فترات توقف ، حتى أثناء حدوث أخطاء ، سمة قوية لـ Kubernetes. 

لتشغيل Kubernetes مع Apache Cassandra ، تحتاج إلى  مشغل Cassandra  داخل  مجموعة Kubernetes .  يسمح هذا لعقد Cassandra بالعمل أعلى مجموعة Kubernetes الحالية كخدمة. . يوفر المشغلون واجهة بين Kubernetes والعمليات الأكثر تعقيدًا مثل Cassandra حتى تتمكن من إدارتها معًا. يتعامل مشغل Kubernetes مع بدء مجموعة Cassandra ، وتوسيع نطاقها ، والتعامل مع الإخفاقات بطريقة تفهمها Cassandra.
نظرًا لأن عُقد Cassandra تعتبر خدمات ذات حالة (stateful services)، فستحتاج إلى توفير أجزاء إضافية من مجموعة Kubernetes الخاصة بك. يمكن لـ PersistentVolumes و StatefulSets على Kubernetes  تلبية متطلبات التخزين المطلوبة بواسطة Cassandra لضمان إرفاق وحدات تخزين البيانات بنفس العقد قيد التشغيل بين أي حدث إعادة تشغيل. تم تصميم حاويات عقد Cassandra مع فكرة الأحجام الخارجية وهي عنصر أساسي في نجاح نشر البرنامج. عند تكوينه بشكل صحيح ، يمكن لملف YAML  واحد نشر كل من التطبيق وطبقات البيانات بطريقة متسقة عبر مجموعة متنوعة من البيئات.

التخطيط للمستقبل

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