المراقبة عبر CloudWatch والمراجعة بإطار Well-Architected

أصبح Lantern يعمل في الإنتاج: الموقع على CloudFront، وتأكيدات الحضور على Lambda وDynamoDB، والفعاليات في RDS. على الخادم القديم، كانت “المراقبة” تعني أن يلاحظ أحد المتطوّعين أن الموقع متوقّف. يمنح هذا الدرس Lantern عيونًا، عبر Amazon CloudWatch، ثم يرجع خطوة إلى الوراء ليراجع التصميم كله باستخدام AWS Well-Architected Framework.

المقاييس: ما الذي يحدث

تنشر خدمات AWS المقاييس (metrics) إلى CloudWatch تلقائيًا. يعيش كل مقياس في namespace وله أبعاد (dimensions)، مثل AWS/Lambda مع FunctionName=lantern-rsvp. وهذه الحفنة هي الأهم بالنسبة إلى Lantern:

السجلات: لماذا حدث ذلك

كل ما تكتبه دالة Lambda إلى stdout يصل إلى CloudWatch Logs، في مجموعة السجلات /aws/lambda/lantern-rsvp. حوّل صيغة سجلات الدالة إلى JSON في إعدادات التسجيل الخاصة بها، وسجّل كائنات بدلًا من جمل، وستستطيع الاستعلام عنها لاحقًا عبر CloudWatch Logs Insights:

fields @timestamp, level, message, eventId
| filter level = "ERROR"
| sort @timestamp desc
| limit 20

aws logs put-retention-policy \
  --log-group-name /aws/lambda/lantern-rsvp --retention-in-days 30

الإنذارات: أخبر إنسانًا

المقياس الذي لا ينظر إليه أحد مجرد معلومة عابرة. الإنذار (alarm) يراقب مقياسًا واحدًا مقابل حدّ معيّن، ويغيّر حالته حين يُتجاوز الحد، فيرسل إشعارًا إلى topic في Amazon SNS يرسل بريدًا إلى القائمين على المشروع:

aws cloudwatch put-metric-alarm --alarm-name lantern-rsvp-errors \
  --namespace AWS/Lambda --metric-name Errors \
  --dimensions Name=FunctionName,Value=lantern-rsvp \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 5 --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:lantern-alerts

خمسة أخطاء في خمس دقائق تستدعي أحدهم؛ أما ليلة خاملة، بلا بيانات على الإطلاق، فلا. يبدأ Lantern بثلاثة إنذارات: أخطاء Lambda، واستجابات 5xx من API Gateway، وحالات الـ throttling في DynamoDB. إنذارات أقل وذات معنى أفضل من إنذارات كثيرة مزعجة يتعلّم الناس تجاهلها.

مراجعة Well-Architected

AWS Well-Architected Framework قائمة AWS المرجعية لأسئلة التصميم، مجمّعة في ست ركائز (pillars). وتأخذك أداة AWS Well-Architected Tool المجانية في الـ console عبرها خطوة خطوة. إليك أول مراجعة لـ Lantern، بملاحظة واحدة لكل ركيزة:

تحسين التكلفة كعادة

التكلفة حاضرة في كل درس من هذه الدورة؛ وهي هنا قائمة مرجعية تطبّقها على كل حساب:

1. احذف الخامل. الـ instances القديمة، والـ volumes غير المرفقة في EBS، وعناوين Elastic IP غير المستخدمة، وبوابات NAT المنسيّة.
2. اضبط الحجم المناسب. استخدم المقاييس، لا التخمين، لاختيار أحجام الـ instances والدوال.
3. استخدم نموذج التسعير الصحيح. Savings Plans للحد الأدنى الثابت، وSpot للعمل الدفعي القابل للمقاطعة، وserverless للعمل المتقطّع.
4. دع البيانات تتقادم وتُحذف. قواعد دورة الحياة في S3 وفترات الاحتفاظ بالسجلات.
5. أبقِ الزيارات محلية. نقاط النهاية من نوع gateway لـ S3 وDynamoDB؛ وCloudFront أمام كل ما هو عام.
6. ضع الوسوم وانظر. ضع على كل مورد الوسم project=lantern، وفعّله لتوزيع التكاليف، وافتح AWS Cost Explorer كل شهر. تنبيه الميزانية من الدرس الثالث شبكة أمان، لا خطة.

هذا هو الانتقال كله. انتقل Lantern من خادم واحد هشّ إلى مجموعة من القطع المُدارة، لكلٍّ منها مالك، وحدود صلاحيات، وإنذار، وسعر تستطيع تفسيره. أصبحت الآن تستطيع إعداد حساب بأمان، وقراءة سياسات IAM وكتابتها، واختيار الخدمات الأساسية الصحيحة، ونشر حمل عمل حقيقي وتشغيله، مع تصميم التكلفة والأمان من الأساس بدلًا من إلحاقهما في النهاية.