المشاركات

EBS مقابل EFS لمشاركة المجلدات بين عدة EC2 Instances

عندما تحتاج إلى مشاركة مجلد واحد بين خمسة EC2 instances تعمل في نفس الوقت، فإن الخطأ الأكثر شيوعاً هو محاولة تركيب EBS volume على أكثر من instance واحد — وهو سيناريو يبدو منطقياً للوهلة الأولى لكنه يؤدي إلى تلف البيانات في معظم الحالات. الفهم الصحيح للفرق بين EBS وEFS يوفر عليك ساعات من استكشاف الأخطاء وربما خسارة بيانات حقيقية في بيئة الإنتاج. TL;DR — EBS مقابل EFS لمشاركة الملفات المعيار EBS EFS المشاركة بين instances متعددة محدودة جداً (Multi-Attach لـ io1/io2 فقط) نعم، بشكل أصلي بروتوكول الوصول Block storage (مثل قرص محلي) NFS v4.1/4.0 نظام الملفات المشترك يتطلب cluster-aware filesystem مدمج ومُدار بالكامل الأداء أعلى (latency أقل) مناسب لمعظم حالات الاستخدام التسعير يُدفع بحجم المساحة المحجوزة يُدفع بحجم البيانات المخزنة فعلياً التوافر عبر Availability Zones محدود بـ AZ واحد (في الغالب) Regional — عبر AZs متعددة كيف يعمل EBS وEFS — الفرق الجوهري EBS هو block storage — يتصرف بالضبط كق...
إرسال تعليق
قراءة المزيد

فهم نماذج T3 القابلة للتوسع: ما معنى 'أرصدة المعالج' ولماذا يتباطأ الخادم فجأة؟

وصلني تذكرة دعم في منتصف الليل: 'الخادم أصبح بطيئاً جداً فجأة بعد ساعات من الأداء الجيد.' بعد التحقيق، اتضح أن الفريق اختار نموذج T3 لأنه 'أرخص'، دون أن يفهم آلية أرصدة المعالج التي تتحكم في أداء هذه النماذج بشكل جذري. ملخص سريع (TL;DR): أرصدة المعالج في نماذج T3 المفهوم الشرح المختصر رصيد المعالج (CPU Credit) وحدة قياس تمثل دقيقة واحدة من استخدام معالج واحد بنسبة 100% معدل تراكم الأرصدة يختلف حسب حجم النموذج، يُحدد بعدد الأرصدة المكتسبة في الساعة الحد الأساسي (Baseline) نسبة المعالج المضمونة دون استهلاك أرصدة وضع Unlimited يسمح بتجاوز الأرصدة مقابل تكلفة إضافية سبب التباطؤ المفاجئ نفاد الأرصدة يُقيّد المعالج عند الحد الأساسي فقط كيف تعمل نماذج T3: آلية أرصدة المعالج نماذج T3 هي نماذج قابلة للتوسع (Burstable Performance) ، وهي مختلفة جوهرياً عن نماذج M5 أو C5. الف...
إرسال تعليق
قراءة المزيد

استعادة الملفات المحذوفة من S3: دليل عملي لاستخدام الإصدارات

حذفت ملفاً من S3 عن طريق الخطأ — هذا الموقف يحدث في الإنتاج أكثر مما يُعترف به. إذا كان لديك خاصية 'Versioning' مفعّلة على الـ Bucket، فالملف لم يُحذف فعلياً؛ بل أُضيف إليه علامة Delete Marker ، والنسخة الأصلية لا تزال موجودة ويمكن استعادتها. ملخص سريع (TL;DR): استعادة ملف محذوف من S3 الخطوة الإجراء الأداة 1 التحقق من تفعيل الإصدارات على الـ Bucket AWS CLI / Console 2 تحديد الـ Delete Marker وحذفه AWS CLI 3 التحقق من ظهور الملف مجدداً AWS CLI كيف يعمل S3 Versioning عند حذف ملف عندما تُفعّل Versioning على Bucket في S3، يحتفظ S3 بكل نسخة من كل كائن (Object). عند تنفيذ أمر حذف عادي ( DELETE ) بدون تحديد VersionId ، لا يُحذف الكائن فعلياً — بل يُضاف كائن خاص يُسمى Delete Marker يحمل VersionId جديداً. هذا الـ Marker يجعل الكائن يبدو محذوفاً لأي طلب GET عادي، لكن النسخ السابقة لا تزال مخزّنة. ف...
إرسال تعليق
قراءة المزيد

Lambda لا تتصل بـ RDS في الشبكة الخاصة — دليل التشخيص الكامل

أكثر سؤال يتكرر عند بناء تطبيقات Serverless: لماذا لا تستطيع Lambda الاتصال بـ RDS رغم أن كل شيء يبدو صحيحاً في الكود؟ الجواب دائماً في طبقة الشبكة، وتحديداً في إعدادات VPC التي يغفلها كثير من المطورين عند تهيئة Lambda لأول مرة. TL;DR — ملخص سريع المشكلة السبب الجذري الحل Lambda لا تصل إلى RDS Lambda خارج VPC أو في Subnet خاطئة ربط Lambda بـ VPC وSubnets الصحيحة Connection timeout Security Group لا يسمح بالمنفذ 5432/3306 إضافة Inbound Rule في SG الخاص بـ RDS Lambda تتجمد ولا تعود لا يوجد NAT Gateway أو VPC Endpoint إضافة NAT أو تهيئة Endpoints للخدمات الأخرى خطأ في الصلاحيات Execution Role لا تملك صلاحيات VPC إضافة AWSLambdaVPCAccessExecutionRole كيف تعمل Lambda مع VPC — الأساس قبل التشخيص Lambda بطبيعتها تعمل خارج VPC الخاص بك. عندما تُفعّل VPC Configuration، تقوم AWS بإنشاء Elastic Network Interface داخل الـ Subnet التي تحددها، وتربطها بالـ Security Group الذي تختاره. من هذه اللحظة، تصبح Lambda ت...
إرسال تعليق
قراءة المزيد

متى تستخدم ElastiCache Redis: تسريع قاعدة البيانات بطبقة التخزين المؤقت

قاعدة بيانات RDS تستجيب ببطء، والسبب ليس دائماً ضعف الأجهزة أو غياب الفهارس — أحياناً المشكلة أبسط من ذلك: نفس الاستعلام يُنفَّذ مئات المرات في الدقيقة على بيانات لا تتغير. إضافة طبقة ElastiCache Redis بين التطبيق وقاعدة البيانات هي الحل الأكثر مباشرة لهذا النوع من الضغط. TL;DR — متى تستخدم ElastiCache Redis الحالة التوصية استعلامات قراءة متكررة لبيانات شبه ثابتة ✅ Redis مناسب — تخزين النتيجة مؤقتاً بـ TTL بيانات تتغير بشكل متكرر جداً (ثانية بثانية) ⚠️ تقييم دقيق مطلوب — تكلفة إبطال الكاش قد تفوق الفائدة جلسات المستخدمين وبيانات المصادقة ✅ حالة استخدام مثالية لـ Redis استعلامات تحليلية معقدة (OLAP) ❌ Redis ليس الأداة الصحيحة — فكر في Read Replica أو Redshift ضغط عالٍ على RDS يسبب CPU spikes ✅ Redis يخفف الضغط بتحويل القراءات بعيداً عن قاعدة البيانات كيف يعمل ElastiCache Redis كطبقة ...
إرسال تعليق
قراءة المزيد

LSI مقابل GSI في DynamoDB: متى تستخدم كل نوع من الفهارس الثانوية؟

عندما تحتاج إلى الاستعلام عن بيانات DynamoDB باستخدام حقل غير مفتاح الجدول الأساسي، يقع كثير من المهندسين في فخ الاختيار العشوائي بين LSI وGSI — ثم يكتشفون لاحقاً أن الخيار الخاطئ يعني إما قيوداً لا يمكن تجاوزها أو تكاليف غير متوقعة في الإنتاج. ملخص سريع: LSI مقابل GSI في DynamoDB الفرق الجوهري: LSI يشارك مفتاح التقسيم مع الجدول الأساسي ويُنشأ فقط عند إنشاء الجدول، بينما GSI يملك مفتاح تقسيم مستقلاً تماماً ويمكن إضافته في أي وقت. الاختيار بينهما ليس مجرد تفضيل — له تداعيات على الاتساق والتكلفة وحدود الحجم. المعيار LSI (فهرس ثانوي محلي) GSI (فهرس ثانوي عام) مفتاح التقسيم نفس مفتاح التقسيم للجدول الأساسي أي حقل في الجدول وقت الإنشاء عند إنشاء الجدول فقط في أي وقت اتساق القراءة يدعم القراءة المتسقة بشكل قوي (Strongly Consistent) قراءة متسقة في نهاية المطاف فقط (Eventually Consistent) حد حجم التقسي...
إرسال تعليق
قراءة المزيد