الغوص العميق في هندسة وخدمات AWS
خدمات تخزين AWS: S3، EBS، EFS و FSx
اختيار التخزين يؤثر على الأداء والتكلفة والتوافر. يسأل المحاورون كثيراً عن المقايضات بين خيارات التخزين.
S3: تخزين الكائنات
فئات التخزين وحالات الاستخدام
| الفئة | وقت الاسترجاع | حالة الاستخدام | التكلفة (لكل GB/شهر) |
|---|---|---|---|
| Standard | فوري | الوصول المتكرر | $0.023 |
| Intelligent-Tiering | فوري | أنماط وصول غير معروفة | $0.0025 + مراقبة |
| Standard-IA | فوري | نادر، الحاجة للوصول السريع | $0.0125 |
| One Zone-IA | فوري | بيانات قابلة للتكرار، حساسة للتكلفة | $0.01 |
| Glacier Instant | ميلي ثانية | أرشيف، وصول فوري | $0.004 |
| Glacier Flexible | 1-12 ساعة | أرشيف، استرجاع مرن | $0.0036 |
| Glacier Deep Archive | 12-48 ساعة | أرشيف طويل المدى | $0.00099 |
⚠ Prices change frequently. The values above are for illustration only and may be out of date. Always verify current pricing directly with the provider before making cost decisions: Anthropic · OpenAI · Google Gemini · Google Vertex AI · AWS Bedrock · Azure OpenAI · Mistral · Cohere · Together AI · DeepSeek · Groq · Fireworks AI · Perplexity · xAI · Cursor · GitHub Copilot · Windsurf.
سؤال المقابلة: أداء S3
س: "تطبيقك يحتاج لقراءة 50,000 كائن من S3 في أقل من 60 ثانية. كيف تحسّن؟"
ج: استراتيجيات تحسين أداء S3:
- موازاة البادئة: وزع الكائنات عبر بادئات متعددة (3,500 PUT/5,500 GET لكل بادئة في الثانية)
- S3 Transfer Acceleration: استخدم مواقع CloudFront الطرفية للتحميلات الأسرع
- التنزيلات متعددة الأجزاء: نزّل الكائنات الكبيرة في قطع متوازية
- موازاة الطلبات: استخدم اتصالات متزامنة (50K كائن ÷ 60s = ~833 طلب/ثانية قابلة للتحقيق)
- S3 Select: استعلم البيانات داخل الكائنات لتقليل النقل
أفضل ممارسات أمان S3
- فعّل S3 Block Public Access على مستوى الحساب
- استخدم سياسات bucket مع أقل امتياز
- فعّل تشفير SSE-S3 أو SSE-KMS افتراضياً
- فعّل الإصدار للبيانات الحرجة
- استخدم S3 Access Points للتحكم في الوصول متعدد المستأجرين
EBS: تخزين الكتل
مقارنة أنواع المجلدات
| النوع | IOPS | الإنتاجية | حالة الاستخدام |
|---|---|---|---|
| gp3 | حتى 16,000 | 1,000 MB/s | الأحمال العامة، مجلدات الإقلاع |
| gp2 | دفعة حتى 16,000 | 250 MB/s | قديم، أحمال قابلة للدفعات |
| io2 Block Express | 256,000 | 4,000 MB/s | قواعد بيانات حرجة، SAP HANA |
| st1 | غير متاح | 500 MB/s | البيانات الكبيرة، معالجة السجلات |
| sc1 | غير متاح | 250 MB/s | البيانات الباردة، الوصول النادر |
سؤال المقابلة: EBS مقابل Instance Store
س: "متى ستستخدم instance store بدلاً من EBS؟"
ج: Instance store (المؤقت) يناسب:
- البيانات المؤقتة: مساحة العمل، المخازن المؤقتة، الذاكرة المخبأة
- احتياجات IOPS العالية: مثيلات i3en تقدم 400K IOPS
- حساسية التكلفة: لا رسوم تخزين إضافية
- الأنظمة الموزعة: حيث البيانات مكررة في مكان آخر (Cassandra، Kafka)
حرج: البيانات تُفقد عند الإيقاف/الإنهاء. لا تستخدم أبداً للتخزين الدائم.
نمط تحسين EBS
طبقة قاعدة البيانات:
- الأساسي: io2 (256K IOPS، Multi-Attach معطل)
- النسخ: gp3 (16K IOPS، محسّن للتكلفة)
طبقة التطبيق:
- الإقلاع: gp3 (3,000 IOPS أساسي)
- البيانات: حسب حمل العمل
الأرشيف:
- اللقطات إلى S3 Glacier
EFS: نظام الملفات المرن
أوضاع الأداء
| الوضع | حالة الاستخدام | التأخير |
|---|---|---|
| General Purpose | خدمة الويب، CMS، الحاويات | منخفض (أقل من ms) |
| Max I/O | البيانات الكبيرة، معالجة الوسائط | أعلى (ms) |
أوضاع الإنتاجية
| الوضع | السلوك | حالة الاستخدام |
|---|---|---|
| Bursting | يتناسب مع حجم التخزين | أحمال العمل المتغيرة |
| Provisioned | إنتاجية ثابتة | أداء ثابت |
| Elastic | توسع تلقائي للإنتاجية | أحمال العمل غير المتوقعة |
سؤال المقابلة: EFS مقابل EBS
س: "تطبيقك يعمل على 5 مثيلات EC2 ويحتاج تخزين ملفات مشترك. قارن EFS و EBS."
ج:
| العامل | EFS | EBS Multi-Attach |
|---|---|---|
| المشاركة | آلاف المثيلات | حتى 16 مجلد io2 |
| البروتوكول | NFS (متوافق مع POSIX) | مستوى الكتل |
| نطاق المنطقة | متعدد AZ | AZ واحدة |
| حالة الاستخدام | محتوى مشترك، CMS | قواعد بيانات مجمعة |
| التكلفة | أعلى ($0.30/GB) | أقل ($0.125/GB لـ gp3) |
التوصية: EFS لاحتياجات نظام الملفات المشترك الحقيقية؛ EBS Multi-Attach فقط لتطبيقات المجموعات المحددة.
FSx: أنظمة الملفات المُدارة
خيارات FSx
| الخدمة | نظام الملفات | حالة الاستخدام |
|---|---|---|
| FSx for Windows | NTFS | أحمال Windows، تكامل AD |
| FSx for Lustre | Lustre | HPC، تدريب ML، تصيير الفيديو |
| FSx for NetApp ONTAP | ONTAP | بديل NAS المؤسسي |
| FSx for OpenZFS | ZFS | أحمال Linux/NFS |
سؤال المقابلة: FSx for Lustre مع S3
س: "تحتاج لمعالجة 10TB من البيانات من S3 بإنتاجية عالية لتدريب ML. ما الهندسة المعمارية؟"
ج: استخدم FSx for Lustre مع تكامل S3:
- أنشئ FSx for Lustre مرتبط بـ S3 bucket
- البيانات تُحمَّل تكاسلياً (لا تُنسخ) من S3
- إنتاجية 100+ GB/s لأحمال ML
- اكتب النتائج مرة أخرى إلى S3 تلقائياً
- احذف FSx بعد المعالجة (ادفع فقط لوقت الحوسبة)
إطار قرار التخزين
تخزين كائنات (أي حجم، قابل للوصول من الويب)؟ → S3
تخزين كتل (مثيل واحد)؟
└── IOPS عالي (>16K)؟ → io2 Block Express
└── حمل عمل عام؟ → gp3
└── مكثف الإنتاجية؟ → st1
نظام ملفات مشترك؟
└── Windows؟ → FSx for Windows
└── HPC/ML؟ → FSx for Lustre
└── Linux عام؟ → EFS أو FSx for OpenZFS
نصيحة التكلفة: اعتبر دائماً S3 Intelligent-Tiering للبيانات ذات أنماط الوصول غير المعروفة - تحسّن التكاليف تلقائياً.
بعد ذلك، سنغطي أساسيات شبكات AWS. :::