(استنادًا إلى كتاب Designing Data-Intensive Applications)
"الإنترنت تم تنفيذه بإتقان لدرجة أن أغلب الناس بيشوفوه كأنه مورد طبيعي زي المحيط الهادئ، مش حاجة من صنع البشر. متى كانت آخر مرة شفنا فيها تكنولوجيا بالحجم ده وبدون أخطاء تقريبًا؟"
— آلان كاي، من مقابلة مع Dr Dobb’s Journal، سنة 2012
الجملة دي هي اللي بدأ بيها الكاتب مارتن كليبتمن كتابه، وهي مش بس جملة جذابة، لكن كمان بتفتح الباب لفهم عميق عن السبب الحقيقي وراء وجود مجال اسمه "تصميم الأنظمة المعتمدة على البيانات" أو "System Design".
ليه أصلاً محتاجين نفكر في تصميم أنظمة متقدمة؟
زمان، لما كانت البيانات صغيرة والأنظمة بسيطة، كنا ممكن نستخدم قواعد بيانات تقليدية وعمليات برمجية مباشرة عشان نخزن البيانات ونتعامل معاها. الأمور كانت واضحة، ومفيش تعقيد كبير.
لكن مع ظهور الإنترنت، والداتا اللي بتتولد من ملايين المستخدمين والتطبيقات، حجم البيانات زاد بشكل مهول، ومعاه زادت تعقيدات العمليات:
بقى عندنا احتياج نخزن الداتا في أماكن تقدر تستحمل الحجم الكبير ده. بقى لازم نوصل لنتائج معقدة بسرعة.
بقينا محتاجين نبحث في ملايين السجلات في أجزاء من الثانية. بقينا محتاجين نخزن نتايج العمليات نفسها علشان نستخدمها لاحقًا.
كل ده خلانا نفكر من جديد:
هل الأدوات والأساليب القديمة لسه تنفع؟ هل لازم كل نظام يكون مصمم بنفس الشكل؟
وهنا بييجي دور الأدوات الجديدة اللي ظهرت:
أنظمة تخزين مؤقت (Caching)
أنظمة رسائل (Message Queues)
قواعد بيانات موزعة
أنظمة تحليل بيانات لحظية (Real-time analytics)
وغيرها...
لكن مع تعدد الأدوات، بنرجع نسأل سؤال مهم:
إمتى نستخدم كل أداة؟
وإيه اللي يخليني أختار Redis مثلاً بدل Kafka؟ أو PostgreSQL بدل MongoDB؟
ودي الأسئلة اللي الكتاب بيجاوب عليها فصل ورا فصل، بداية من فهم أساسيات الأنظمة، لحد بناء أنظمة فعلاً قوية، سريعة، وقابلة للتطوير.
ومع استكمال الدوران حول الفكرة الاساسية نجد اننا بحاجة الي تطبيق 3 مفاهيم اساسية للتاكد من اننا نقوم بعمل نظام صلب قابل للتحمل ويعمل بكفاءة وهم مفاهيم
Reliability , Scalability , Maintainability
وهي المفاهيم الاساسية اللي بيقوم عليها اي نظام في العصر الحالي
وبامكاننا ذكر تفاصيل عامة عن كل مصطلح منهم
فـ Reliability هي التاكد ان النظام يعمل بالكفاءة المطلوبة بدون اخطاء بدون وجود وقت يكون فيه النظام خارج الخدمة، و سنتطرق في طرق الاخطاء اللي يمكن ان تظهر في اي نظام مستقبلا وكيف يمكننا معالجتها.
Scalability وهو مفهوم ظهر حديثا مع زيادة الضغط الموجود علي الانظمة ومع وجود منصات تحتوي علي ملايين المستخدمين، فاصبحت المنصات يجب ان تكون قابله ان تتحمل هذا العدد المهول من الطلبات والمستخدمين في نفس الثانية، فمثلا:
المنصة التي كانت تتحمل 1000 طلب في الثانية هل يمكنها ان تتحمل 10 الاف طلب في الثانية ام لا؟
Maintainability وهي تتمحور حول مفهوم الصيانة وسياسة العمل علي المنصة. فالمنصات دائما ما يعمل عليها اشخاص مختلفين ودائما ما تتغير الاشخاص الذين يعملون علي المنصة، فلو قام شخص بكتابة ما يريده بدون الاعتماد علي سياسة واضحة لأصبح الكود اشبه بطبق اسباجتي لا تستطيع لا قراءته ولا فهمه، ويحتوي هذا الفرع علي مفاهيم عديدة سيتطرق اليها الكتاب في وقت اخر.
نبدأ باول مصطلح معانا بنتطرق اليه وهو Reliability:
والتي ذكرنا سابقا مفهومها هي ضمان ان النظام يعمل بكفاءة وبدون مشاكل وبدون انقطاع في الخدمة.
ويمكننا التفصيل اكتر في هذه النقطة كما ذكر الكتاب:
ان النظام لابد ان يقدم للمستخدم الخدمة التي يتوقعها.
النظام لابد ان يتعامل مع الاخطاء التي يمكن ان تحدث او مثلا استخدام النظام بطريقة غير متوقعه.
النظام يقوم بمنع اي وصول غير مصرح لاي جزء من اجزاءه.
فلو استطعنا توفير هذه النقاط الاساسية في اي نظام فيمكننا ان نقول ان النظام يعمل بكفاءة وبشكل ممتاز.
وبيجي هنا توضيح لمفهوم مهم جدا وهو الفرق بين
fault / failure
في ضوء فهمنا لطريقة الوصول لعمل النظام المثالي لابد من فهمنا الفارق بينهما:
fault بمفهومها ان احد مكونات النظام صدر منها سلوك غير متوقع او نتيجة خارج النتيجة المتوقعه.
failure هي ان النظام قد توقف عن اداء الخدمة المتوقع منه اداءها.
فغالبا fault يكون هو المسبب لـ failure وليس العكس.
فلكي يكون النظام الخاص بنا ممتاز علي نطاق reliability
لابد ان يتعامل مع faults بطريقة تمنع وقوع failures، وهذا ما يسمي fault-tolerance.
لكن علي ارض الواقع لا يوجد نظام يكفل بنسبة 100% انه لن تقع اخطاء في نطاق عمله، لانه لايوجد نظام خالي من الاخطاء التي يمكن ان تحدث لاي سبب والتي سنتطرق اليها مع الوقت.
ولكن احيانا بيتم اختبار انظمة fault-tolerance كل مدة زمنية عن طريق عمل خطأ مقصود كل فترة والتأكد ان النظام قادر انه يتعامل مع الخطأ ده.
لكن مش كل الاخطاء ينفع معها هذه الطريقة، كمثال حالات الاختراق وتسريب البيانات يلزم معها تعامل خاص.
كمثال علي احد هذه الانظمة التي تتعامل مع الاخطاء:
شركة Netflix واداة Chaos Monkey، كل غرضها انها تقوم بايقاف بعض الخدمات عشوائيا ويتابعوا اداء النظام في تصحيح الخطأ لمنع تعطل النظام ككل.
الاخطاء التي يمكن ان تحدث في الانظمة متعددة ومختلفة وتختلف من نظام لاخر، لكن ممكن نصنفها لـ 3 اقسام:
Hardware faults
أول قسم بيبدأ معانا علي نطاق الهاردوير الخاص بالاجهزة والسيرفرات التي يعمل عليها النظام، ففي الانظمة الكبيرة التي تحتوي علي العديد من الاجهزة واقراص التخزين، توجد دائما احتمالية لتلف الاجهزة او احتراقها او مثلا مشاكل في الطاقة.
والحل اللي اتبعناه في حل مثل هذه المشاكل هو الاعتماد كمثال علي مصادر طاقة متعددة تقوم بتوفير طاقة دائمة للانظمة، وايضا اعتماد علي تبديل تلقائي للقطع التالفة مثل الاقراص واخذ نسخ احتياطية للبيانات وتحميلها عليها وفصل القطع التالفة بطريقة اوتوماتيكية، حيث يتم وضع
hard disks in RAID configurations.
بتوضيح اكتر عن مفهوم RAID
ممكن نتخيلها بالمنظور الاتي اننا عندينا مصفوفة من اقراص التخزين عليها نسخ من BACKUPS بتاعت النظام بحيث لو في قطعة تلفت يتم تبديلها بقطعة مختلفة تؤدي وظيفتها فده باختصار مفهوم RAID ( Redundant Array of independent Disks )
Software faults
وهي الاخطاء اللي بتنتج من مكونات النظام مثل التعامل مع حالات جديدة، وفي الاغلب تكون هذه الحالات نادرة الحدوث، ويكون بناءً علي افتراضات خاطئة بسبب ندرة حدوث هذا الحدث.
وهذا النوع من الاخطاء غير قابل للتنبؤ به، ويمكننا تجنبه عن طريق القيام بعمليات اختبار دائمة للانظمة، التأكد من عزل كل عملية عن الاخري، المتابعة المستمرة للنظام.
Human errors
واخر قسم لدينا هو قسم الاخطاء البشرية، الناتجة دائما عن misconfiguration في النظام، والتي يمكن حلها عن طريق اختبار النظام قبل تحويله الي نطاق التشغيل، وهذا عن طريق اتباع طرق واضحة، مثلا:
sandbox environment
designing safe APIs
automated & manual testing
وبكده الي حدا ما يمكننا ان نقول اننا وصلنا لنظام يحقق مفاهيم reliability الاساسية وبالتاكيد سنناقش امور مختلف ضمن هذا النطاق مرورا بفصول الكتاب المختلفة
سنستكمل باقي الفصل في الموضوع التالي متحدثين عن Scalability , maintainability
و twitter home page 2012 problem
#SystemDesign
#DataIntensiveApplications
#SoftwareEngineering
#BackendDevelopment
#TechArchitecture
"الإنترنت تم تنفيذه بإتقان لدرجة أن أغلب الناس بيشوفوه كأنه مورد طبيعي زي المحيط الهادئ، مش حاجة من صنع البشر. متى كانت آخر مرة شفنا فيها تكنولوجيا بالحجم ده وبدون أخطاء تقريبًا؟"
— آلان كاي، من مقابلة مع Dr Dobb’s Journal، سنة 2012
الجملة دي هي اللي بدأ بيها الكاتب مارتن كليبتمن كتابه، وهي مش بس جملة جذابة، لكن كمان بتفتح الباب لفهم عميق عن السبب الحقيقي وراء وجود مجال اسمه "تصميم الأنظمة المعتمدة على البيانات" أو "System Design".
ليه أصلاً محتاجين نفكر في تصميم أنظمة متقدمة؟
زمان، لما كانت البيانات صغيرة والأنظمة بسيطة، كنا ممكن نستخدم قواعد بيانات تقليدية وعمليات برمجية مباشرة عشان نخزن البيانات ونتعامل معاها. الأمور كانت واضحة، ومفيش تعقيد كبير.
لكن مع ظهور الإنترنت، والداتا اللي بتتولد من ملايين المستخدمين والتطبيقات، حجم البيانات زاد بشكل مهول، ومعاه زادت تعقيدات العمليات:
بقى عندنا احتياج نخزن الداتا في أماكن تقدر تستحمل الحجم الكبير ده. بقى لازم نوصل لنتائج معقدة بسرعة.
بقينا محتاجين نبحث في ملايين السجلات في أجزاء من الثانية. بقينا محتاجين نخزن نتايج العمليات نفسها علشان نستخدمها لاحقًا.
كل ده خلانا نفكر من جديد:
هل الأدوات والأساليب القديمة لسه تنفع؟ هل لازم كل نظام يكون مصمم بنفس الشكل؟
وهنا بييجي دور الأدوات الجديدة اللي ظهرت:
أنظمة تخزين مؤقت (Caching)
أنظمة رسائل (Message Queues)
قواعد بيانات موزعة
أنظمة تحليل بيانات لحظية (Real-time analytics)
وغيرها...
لكن مع تعدد الأدوات، بنرجع نسأل سؤال مهم:
إمتى نستخدم كل أداة؟
وإيه اللي يخليني أختار Redis مثلاً بدل Kafka؟ أو PostgreSQL بدل MongoDB؟
ودي الأسئلة اللي الكتاب بيجاوب عليها فصل ورا فصل، بداية من فهم أساسيات الأنظمة، لحد بناء أنظمة فعلاً قوية، سريعة، وقابلة للتطوير.
ومع استكمال الدوران حول الفكرة الاساسية نجد اننا بحاجة الي تطبيق 3 مفاهيم اساسية للتاكد من اننا نقوم بعمل نظام صلب قابل للتحمل ويعمل بكفاءة وهم مفاهيم
Reliability , Scalability , Maintainability
وهي المفاهيم الاساسية اللي بيقوم عليها اي نظام في العصر الحالي
وبامكاننا ذكر تفاصيل عامة عن كل مصطلح منهم
فـ Reliability هي التاكد ان النظام يعمل بالكفاءة المطلوبة بدون اخطاء بدون وجود وقت يكون فيه النظام خارج الخدمة، و سنتطرق في طرق الاخطاء اللي يمكن ان تظهر في اي نظام مستقبلا وكيف يمكننا معالجتها.
Scalability وهو مفهوم ظهر حديثا مع زيادة الضغط الموجود علي الانظمة ومع وجود منصات تحتوي علي ملايين المستخدمين، فاصبحت المنصات يجب ان تكون قابله ان تتحمل هذا العدد المهول من الطلبات والمستخدمين في نفس الثانية، فمثلا:
المنصة التي كانت تتحمل 1000 طلب في الثانية هل يمكنها ان تتحمل 10 الاف طلب في الثانية ام لا؟
Maintainability وهي تتمحور حول مفهوم الصيانة وسياسة العمل علي المنصة. فالمنصات دائما ما يعمل عليها اشخاص مختلفين ودائما ما تتغير الاشخاص الذين يعملون علي المنصة، فلو قام شخص بكتابة ما يريده بدون الاعتماد علي سياسة واضحة لأصبح الكود اشبه بطبق اسباجتي لا تستطيع لا قراءته ولا فهمه، ويحتوي هذا الفرع علي مفاهيم عديدة سيتطرق اليها الكتاب في وقت اخر.
نبدأ باول مصطلح معانا بنتطرق اليه وهو Reliability:
والتي ذكرنا سابقا مفهومها هي ضمان ان النظام يعمل بكفاءة وبدون مشاكل وبدون انقطاع في الخدمة.
ويمكننا التفصيل اكتر في هذه النقطة كما ذكر الكتاب:
ان النظام لابد ان يقدم للمستخدم الخدمة التي يتوقعها.
النظام لابد ان يتعامل مع الاخطاء التي يمكن ان تحدث او مثلا استخدام النظام بطريقة غير متوقعه.
النظام يقوم بمنع اي وصول غير مصرح لاي جزء من اجزاءه.
فلو استطعنا توفير هذه النقاط الاساسية في اي نظام فيمكننا ان نقول ان النظام يعمل بكفاءة وبشكل ممتاز.
وبيجي هنا توضيح لمفهوم مهم جدا وهو الفرق بين
fault / failure
في ضوء فهمنا لطريقة الوصول لعمل النظام المثالي لابد من فهمنا الفارق بينهما:
fault بمفهومها ان احد مكونات النظام صدر منها سلوك غير متوقع او نتيجة خارج النتيجة المتوقعه.
failure هي ان النظام قد توقف عن اداء الخدمة المتوقع منه اداءها.
فغالبا fault يكون هو المسبب لـ failure وليس العكس.
فلكي يكون النظام الخاص بنا ممتاز علي نطاق reliability
لابد ان يتعامل مع faults بطريقة تمنع وقوع failures، وهذا ما يسمي fault-tolerance.
لكن علي ارض الواقع لا يوجد نظام يكفل بنسبة 100% انه لن تقع اخطاء في نطاق عمله، لانه لايوجد نظام خالي من الاخطاء التي يمكن ان تحدث لاي سبب والتي سنتطرق اليها مع الوقت.
ولكن احيانا بيتم اختبار انظمة fault-tolerance كل مدة زمنية عن طريق عمل خطأ مقصود كل فترة والتأكد ان النظام قادر انه يتعامل مع الخطأ ده.
لكن مش كل الاخطاء ينفع معها هذه الطريقة، كمثال حالات الاختراق وتسريب البيانات يلزم معها تعامل خاص.
كمثال علي احد هذه الانظمة التي تتعامل مع الاخطاء:
شركة Netflix واداة Chaos Monkey، كل غرضها انها تقوم بايقاف بعض الخدمات عشوائيا ويتابعوا اداء النظام في تصحيح الخطأ لمنع تعطل النظام ككل.
الاخطاء التي يمكن ان تحدث في الانظمة متعددة ومختلفة وتختلف من نظام لاخر، لكن ممكن نصنفها لـ 3 اقسام:
Hardware faults
أول قسم بيبدأ معانا علي نطاق الهاردوير الخاص بالاجهزة والسيرفرات التي يعمل عليها النظام، ففي الانظمة الكبيرة التي تحتوي علي العديد من الاجهزة واقراص التخزين، توجد دائما احتمالية لتلف الاجهزة او احتراقها او مثلا مشاكل في الطاقة.
والحل اللي اتبعناه في حل مثل هذه المشاكل هو الاعتماد كمثال علي مصادر طاقة متعددة تقوم بتوفير طاقة دائمة للانظمة، وايضا اعتماد علي تبديل تلقائي للقطع التالفة مثل الاقراص واخذ نسخ احتياطية للبيانات وتحميلها عليها وفصل القطع التالفة بطريقة اوتوماتيكية، حيث يتم وضع
hard disks in RAID configurations.
بتوضيح اكتر عن مفهوم RAID
ممكن نتخيلها بالمنظور الاتي اننا عندينا مصفوفة من اقراص التخزين عليها نسخ من BACKUPS بتاعت النظام بحيث لو في قطعة تلفت يتم تبديلها بقطعة مختلفة تؤدي وظيفتها فده باختصار مفهوم RAID ( Redundant Array of independent Disks )
Software faults
وهي الاخطاء اللي بتنتج من مكونات النظام مثل التعامل مع حالات جديدة، وفي الاغلب تكون هذه الحالات نادرة الحدوث، ويكون بناءً علي افتراضات خاطئة بسبب ندرة حدوث هذا الحدث.
وهذا النوع من الاخطاء غير قابل للتنبؤ به، ويمكننا تجنبه عن طريق القيام بعمليات اختبار دائمة للانظمة، التأكد من عزل كل عملية عن الاخري، المتابعة المستمرة للنظام.
Human errors
واخر قسم لدينا هو قسم الاخطاء البشرية، الناتجة دائما عن misconfiguration في النظام، والتي يمكن حلها عن طريق اختبار النظام قبل تحويله الي نطاق التشغيل، وهذا عن طريق اتباع طرق واضحة، مثلا:
sandbox environment
designing safe APIs
automated & manual testing
وبكده الي حدا ما يمكننا ان نقول اننا وصلنا لنظام يحقق مفاهيم reliability الاساسية وبالتاكيد سنناقش امور مختلف ضمن هذا النطاق مرورا بفصول الكتاب المختلفة
سنستكمل باقي الفصل في الموضوع التالي متحدثين عن Scalability , maintainability
و twitter home page 2012 problem
#SystemDesign
#DataIntensiveApplications
#SoftwareEngineering
#BackendDevelopment
#TechArchitecture