أساسيات السحابة: خدمات AWS الأساسية

S3 بعمق: التخزين والدورة الحياتية والإصدارات والروابط الموقعة

22 دقيقة الدرس 5 من 30

S3 بعمق: التخزين والدورة الحياتية والإصدارات والروابط الموقعة

يُعدّ Amazon S3 (Simple Storage Service) العمود الفقري لتخزين الكائنات في AWS. كل نظام إنتاج جادّ يعتمد عليه: الأصول الثابتة، وقطع أثر خطوط الأنابيب، ونسخ احتياطية لقواعد البيانات، ومجموعات بيانات تدريب نماذج ML، وسجلات التدقيق، وحالة Terraform — كلها تعيش في S3. تبدو واجهة برمجة التطبيقات بسيطة بخداع: PUT وGET وDELETE فحسب، لكن تشغيل S3 بشكل صحيح على نطاق واسع يتطلب فهم نموذج الاتساق، ومفاتيح التكلفة، ومواطن الخطر التشغيلية التي تسببت في انقطاعات حقيقية في شركات حقيقية.

الحاويات (Buckets): قواعد التسمية ومساحة الأسماء التي تفاجئ الفِرق

الحاوية هي حاوية بمساحة أسماء مسطّحة للكائنات. كل كائن يمتلك مفتاحًا (يشبه مسار الملف، وإن لم تكن في S3 مجلدات حقيقية). عدة خصائص تفاجئ المهندسين:

مساحة أسماء عالمية — أسماء الحاويات فريدة عالميًا عبر جميع حسابات AWS. أضف معرّف الحساب أو بادئة المؤسسة لتجنب التعارضات: acme-123456789012-prod-backups.
مرتبطة بمنطقة — رغم مساحة الأسماء العالمية، تعيش الحاوية فعليًا في منطقة واحدة. البيانات لا تغادرها إلا إن هيّأت النسخ عبر المناطق (CRR). هذا مهم للامتثال لـGDPR وسياسات الإقامة البيانية.
اتساق فوري قوي (منذ 2020) — يوفّر S3 الآن اتساق القراءة-بعد-الكتابة للعمليتين PUT وDELETE. لم تعد بحاجة إلى حلقات إعادة المحاولة مع كسر الكاش للتعامل مع القراءات المتقادمة بعد الكتابة.
الحد الأقصى لحجم الكائن — 5 تيرابايت للكائن الواحد؛ أي شيء يتجاوز 100 ميغابايت يجب أن يستخدم واجهة برمجة التحميل متعدد الأجزاء (Multipart Upload).

S3 ليس نظام ملفات ويجب ألا يُعامَل معاملته. إدراج الكائنات تحت بادئة باستخدام ListObjectsV2 يكلّف استدعاء API واحد لكل ألف مفتاح. عند عشرة ملايين كائن، ذلك يعني 10,000 استدعاء API لمجرد تعداد "المجلد". صمّم مساحة أسماء المفاتيح لتجنب عمليات الإدراج الشاملة في المسارات الحرجة.

فئات التخزين: مطابقة التكلفة لنمط الوصول

تقدم S3 سبع فئات تخزين، كل منها يوازن بين تكلفة التخزين وتكلفة الاسترداد وزمن الاسترداد. اختيار الفئة الخطأ هو أكثر أسباب الإنفاق الزائد على S3 شيوعًا.

فئات تخزين S3 مجمّعة حسب طبقة التكلفة. تُؤتمت قواعد دورة الحياة الانتقالات كلما تقادمت الكائنات وتراجعت حاجة الوصول إليها.

الفئات الأساسية التي يجب حفظها:

S3 Standard — متانة 11 تسعة، مخزّن عبر ثلاثة AZs على الأقل، استرداد في ملي ثانية. للكائنات التي يُصل إليها أكثر من مرة شهريًا.
S3 Standard-IA — نفس المتانة وتكرار AZ، أرخص تخزينًا بنحو 46%، لكن مع رسوم استرداد لكل غيغابايت. للكائنات التي يُصل إليها عدة مرات سنويًا. الحد الأدنى لمدة التخزين: 30 يومًا.
S3 One Zone-IA — يُخزَّن في AZ واحد فقط؛ أرخص بـ20% من Standard-IA. مناسب فقط للبيانات القابلة لإعادة الإنشاء.
S3 Intelligent-Tiering — يراقب أنماط الوصول لكل كائن وينقله بين الطبقات تلقائيًا دون رسوم استرداد. رسوم المراقبة تجعله فعّالًا فقط للكائنات التي يزيد حجمها عن 128 كيلوبايت تقريبًا.
Glacier Instant Retrieval — للوصول الفصلي أو أقل. استرداد في ملي ثانية، تكلفة تخزين أقل بنحو 68% من Standard.
Glacier Flexible Retrieval — استرداد في دقائق إلى ساعات. لأرشيفات التعافي من الكوارث.
Glacier Deep Archive — الأرخص بنحو $0.00099/غيغابايت/شهر، استرداد في 12 ساعة. للاحتفاظ التنظيمي بسجلات غير قابلة للتغيير (سجلات تدقيق لـ7 سنوات).

على نطاق الشركات الكبرى، أعلى تأثير لتحسين تكاليف S3 هو نقل قطع أثر خطوط الأنابيب وكاشات البناء إلى Standard-IA بعد 30 يومًا، ثم إلى Glacier بعد 90 يومًا. تُنجز قواعد دورة الحياة ذلك تلقائيًا دون أي تكاليف تشغيلية. نظام CI لمستودع ضخم قد يُنتج مئات التيرابايت سنويًا — التصنيف السليم يوفر عشرات الآلاف من الدولارات.

قواعد دورة الحياة: إدارة التكاليف الآلية

قاعدة دورة الحياة هي سياسة JSON مرفقة بالحاوية تنقل الكائنات بين فئات التخزين أو تنهيها (تحذفها) بناءً على العمر أو البادئة. هذا هو الآلية الأساسية لإدارة التكاليف الآلية على نطاق واسع. يجب أن تكون قواعد دورة الحياة موجودة على كل حاوية تتراكم فيها الكائنات بمرور الوقت.

aws s3api put-bucket-lifecycle-configuration \
  --bucket acme-prod-ci-artifacts \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "artifact-tiering",
        "Status": "Enabled",
        "Filter": { "Prefix": "builds/" },
        "Transitions": [
          { "Days": 30, "StorageClass": "STANDARD_IA" },
          { "Days": 90, "StorageClass": "GLACIER_IR" }
        ],
        "Expiration": { "Days": 365 }
      },
      {
        "ID": "expire-incomplete-multipart",
        "Status": "Enabled",
        "Filter": { "Prefix": "" },
        "AbortIncompleteMultipartUpload": {
          "DaysAfterInitiation": 7
        }
      }
    ]
  }'

القاعدة الثانية — AbortIncompleteMultipartUpload — هي التي تنساها معظم الفِرق. عمليات التحميل متعددة الأجزاء التي تفشل في منتصف الطريق تترك أجزاء يتيمة في S3 تُحسب عليك في الفاتورة. هذه القاعدة تنظّفها تلقائيًا بعد 7 أيام. يجب وجودها في كل حاوية.

الإصدارات: الاسترداد اللحظي وفخّ علامات الحذف

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

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

أكثر مخاطر الإصدارات شيوعًا هي علامات الحذف (delete markers). عند حذف كائن في حاوية ذات إصدارات دون تحديد معرّف الإصدار، يُدرج S3 علامة حذف بدلًا من إزالة الكائن. يبدو الكائن محذوفًا لطلبات GET العادية، لكن جميع الإصدارات السابقة (والعلامة نفسها) لا تزال موجودة وتُراكم تكاليف تخزين. لحذف جميع الإصدارات فعليًا، يجب إدراجها صراحةً وحذف كل منها. تستطيع قواعد دورة الحياة أتمتة ذلك: اضبط NoncurrentVersionExpiration لإنهاء الإصدارات القديمة بعد N يومًا، وExpiredObjectDeleteMarker: true لتنظيف علامات الحذف اليتيمة.

# List all versions and delete markers for a key
aws s3api list-object-versions \
  --bucket acme-prod-config \
  --prefix "app/settings.json"

# Permanently delete a specific version
aws s3api delete-object \
  --bucket acme-prod-config \
  --key "app/settings.json" \
  --version-id "3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo"

# Lifecycle rule to expire noncurrent versions after 90 days
# Add to your lifecycle configuration:
# {
#   "ID": "noncurrent-expiry",
#   "Status": "Enabled",
#   "Filter": { "Prefix": "" },
#   "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
#   "Expiration": { "ExpiredObjectDeleteMarker": true }
# }

الروابط الموقعة مسبقًا: وصول آمن مؤقت بدون بيانات اعتماد

الرابط الموقّع مسبقًا (Presigned URL) هو رابط موقّع بـHMAC ومحدود الوقت يمنح حامله الوصول إلى كائن S3 خاص دون الحاجة إلى بيانات اعتماد AWS. يحسب التوقيع مبدأ IAM يمتلك أذونات S3 اللازمة، ويُرمّز في الرابط وقت الانتهاء. عند استخدام العميل للرابط، يتحقق S3 من التوقيع وتاريخ الانتهاء.

هذا النمط المعياري لتقديم المحتوى الخاص (وثائق المستخدمين المحمّلة، التقارير المُنشأة، روابط التنزيل) دون توجيه البيانات عبر طبقة التطبيق. يُنشئ تطبيقك الرابط من الواجهة الخلفية ويمرره للعميل، فيُنزّل العميل مباشرةً من S3 — توفير لنطاق الخروج على خوادم التطبيق وتقليل لزمن الاستجابة.

# Generate a presigned GET URL (valid for 15 minutes = 900 seconds)
aws s3 presign s3://acme-prod-user-uploads/reports/invoice-2024-q4.pdf \
  --expires-in 900

# Output: a long URL the client can use directly in a browser or curl
# https://acme-prod-user-uploads.s3.us-east-1.amazonaws.com/reports/invoice-2024-q4.pdf
#   ?X-Amz-Algorithm=AWS4-HMAC-SHA256
#   &X-Amz-Credential=...
#   &X-Amz-Date=...
#   &X-Amz-Expires=900
#   &X-Amz-Signature=...

# Generate a presigned PUT URL (for direct client uploads)
aws s3 presign s3://acme-prod-user-uploads/avatars/user-42.jpg \
  --expires-in 300

# In production, generate presigned URLs with the AWS SDK:
# Python (boto3) example:
# url = s3_client.generate_presigned_url(
#   ClientMethod='get_object',
#   Params={'Bucket': 'acme-prod-user-uploads', 'Key': 'reports/invoice.pdf'},
#   ExpiresIn=900
# )

تُنشأ الروابط الموقّعة مسبقًا بواسطة أي مبدأ IAM. إذا أُلغيت بيانات اعتماد ذلك المبدأ قبل انتهاء الرابط، لا تُلغي AWS الروابط الجارية لـS3 القياسية. إذا كنت بحاجة إلى إلغاء فوري، استخدم سياسات S3 Block Public Access أو Access Points ذات ضوابط أكثر إحكامًا. بالنسبة لبيانات اعتماد STS المستمدة (تحمّلات الأدوار)، ينتهي الرابط الموقّع مسبقًا عند انتهاء الجلسة الأساسية — أيهما أقصر.

أنماط الفشل الإنتاجية الواجب معرفتها

S3 موثوق للغاية لكنه ليس معصومًا. أنماط الفشل التالية تسببت في انقطاعات حقيقية:

سياسة الحاوية تقفل جميع المبادئ — عبارة Deny خاطئة في سياسة الحاوية يمكن أن تجعلها غير قابلة للوصول بشكل دائم. اختبر سياسات الحاوية دائمًا بـIAM Policy Simulator قبل تطبيقها.
S3 كنقطة فشل وحيدة لبدء تشغيل التطبيق — إذا سحبت بيانات user-data أو بدء تشغيل الحاوية ملف إعداد من S3 وكان S3 يعاني من معدلات خطأ مرتفعة، فستفشل كل إعادة تشغيل في ASG. خزّن الإعداد مسبقًا وقت بناء AMI.
أقسام المفاتيح الساخنة — يُوسّع S3 نفسه تلقائيًا لمعدلات الطلبات العالية، لكن ذلك يستغرق وقتًا. اضرب بأحرف عشوائية في بداية أسماء المفاتيح للأحمال ذات الانفجار المفاجئ: sha256(id)[:4]/المفتاح-الحقيقي.
تكاليف نقل البيانات عبر المناطق — قراءة EC2 في us-east-1 من S3 في eu-west-1 تدفع رسوم الخروج عبر المناطق. تحقق دائمًا من أن الحوسبة والتخزين في نفس المنطقة للأحمال عالية الإنتاجية.

فعّل S3 Server Access Logging أو S3 Event Notifications (إلى SQS أو Lambda) على كل حاوية إنتاجية من اليوم الأول. تصحيح الخطأ "من حذف ذلك الملف الأسبوع الماضي؟" بدون سجلات الوصول أمر بالغ الصعوبة. السجلات رخيصة؛ سجلات التدقيق المفقودة مُكلفة.