مقدمة

في مقالتي Amazon DevOps Guru للتطبيقات بدون خادم - الجزء 10 الكشف عن الحالات الشاذة في Aurora Serverless v2، علمنا أن DevOps Guru كان قادرًا على اكتشاف الحالات الشاذة بنجاح باستخدام قاعدة بيانات PostgreSQL Aurora (Serverless v2) في حالة وظيفة Lambda مع Java 21 المُدارة تم توصيل وقت التشغيل به عبر JDBC. لقد قمنا بتوسيع قاعدة البيانات الخاصة بنا من 0.5 إلى 1 ACU فقط وقمنا بإنشاء حمل عالي جدًا على قاعدة البيانات عن طريق استدعاء وظيفة Lambda لاسترداد المنتج حسب المعرف عدة مئات من المرات بشكل متزامن لعدة دقائق. لقد رأينا أن DevOps Guru أشار بشكل صحيح إلى المجموع المتزايد لاتصالات قاعدة البيانات وتحميل قاعدة البيانات (CPU) المرتفع باستمرار. في هذه المقالة، أود معرفة ما إذا كان DevOps Guru سيكتشف الحالة الشاذة بإجراء نفس التجربة ولكن باستخدام Data API لـ Aurora Serverless v2 مع AWS SDK لـ Java بدلاً من JDBC.

اكتشاف الحالات الشاذة في الإصدار الثاني من Aurora Serverless باستخدام Data API

دعونا نلقي نظرة على نموذج التطبيق الخاص بنا ونستخدم قالب SAM لإنشاء البنية التحتية ونشر التطبيق الموضح في الصورة التالية:

يقوم التطبيق بإنشاء المنتجات المخزنة في قاعدة بيانات Aurora Serverless v2 PostgreSQL ويستردها عن طريق المعرف باستخدام Data API. وظيفة Lambda ذات الصلة والتي سنستخدمها لاسترداد المنتج بواسطة المعرف الخاص بها هي GetProductByIdViaAuroraServerlessV2DataApi وتنفيذ معالجها هو GetProductByIdViaAuroraServerlessV2DataApiHandler.

كما في المقالة السابقة نستخدم أداة Hey لإجراء اختبار التحمل مثل هذا

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

في هذا المثال، نقوم باستدعاء نقطة نهاية بوابة API مع 300 حاوية متزامنة لمدة 15 دقيقة. خلف نقطة النهاية prod/productsWithoutDataApi سيتم استدعاء وظيفة Lambda GetProductByIdViaAuroraServerlessV2WithoutDataApi والتي ستقوم باسترداد المنتج بواسطة المعرف 1 من قاعدة بيانات Aurora Serverless v2 PostgreSQL.

لقد قمنا بتكوين [قالب SAM] ((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) مجموعة قاعدة بيانات Aurora للتوسع من الحد الأدنى للسعة 0.5 إلى الحد الأقصى للسعة 1 ACU (وهو حجم قاعدة البيانات صغير جدًا) في حالة زيادة التحميل لغرض توفير التكاليف.

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

تدير قاعدة بيانات Aurora (Serverless v2) الحد الأقصى لعدد اتصالات قاعدة البيانات المتاحة بما يتناسب مع حجم قاعدة البيانات (في حالتنا إعداد ACU) أيضًا مع Data API لـ Aurora Serverless v2 (وهو فرق كبير عن الإصدار 1 الذي سيصبح خارج الدعم في نهاية عام 2024 حيث كانت الحصة الثابتة تبلغ 1000 اتصال بقاعدة البيانات في الثانية). لمزيد من المعلومات، يرجى قراءة الوثائق حول الحد الأقصى لعدد الاتصالات لـ Aurora Serverless v2. لذلك، مع زيادة عدد الاستدعاءات، نتوقع الوصول إلى الحد الأقصى لعدد اتصالات قاعدة البيانات المتاحة وتحميل قاعدة البيانات العالية (CPU) قريبًا، بحيث لن تتمكن قاعدة البيانات هذه من الاستجابة لطلبات وظائف Lambda الجديدة لاسترداد المنتج بواسطة id (سيتم تشغيل Lambda أيضًا). بهذا سنقوم بإثارة الحالة الشاذة ونود معرفة ما إذا كان DevOps Guru سيكون قادرًا على اكتشافها. وكان قادرًا نوعًا ما.... تم إنشاء الرؤية التالية:

وتم تحديد المقاييس الشاذة المجمعة التالية:

مقارنة بالمقاييس الشاذة المجمعة التي تم تحديدها في حالة استخدام JDBC بدلاً من Data API الموضحة في مقالتي Amazon DevOps Guru للتطبيقات بدون خادم - الجزء 10 الكشف عن الشذوذ في Aurora Serverless v2، نحن نهتم تمامًا بالمقاييس الشاذة لقاعدة بيانات Aurora: اتصال قاعدة البيانات يتم تحميل المجموع وقاعدة البيانات (CPU) ولكن يتم رؤية الخطأ بشكل صحيح في Lambda والذي حدث في الوقت المحدد من 15 ثانية لأن قاعدة البيانات لم تتمكن من الاستجابة.

.

إذن ما الفرق؟ دعونا نستكشف كلا الحادثين اللذين قمنا بإعادة إنتاجهما على مجموعة Aurora Serverless v2 PostgreSQL مع JDBC (Non Data API) وData API:

فيما يتعلق باستخدام/قياس وحدة التحكم ACU، يبدو كلاهما متماثلين:

فيما يتعلق بمقاييس قاعدة البيانات الأخرى مثل: استخدام وحدة المعالجة المركزية، DatabaseConnection DBLload(CPU) هناك اختلافات كبيرة:

• يبدو استخدام وحدة المعالجة المركزية (CPU) هو نفسه بالنسبة لحالات JDBC(Non-Data API) وData API. ولكن يبدو أن DevOps Guru لا يأخذ في الاعتبار هذا المقياس، حيث أننا لم نلاحظه حتى في تجربة JDBC
• DBLoad(CPU) وهو منخفض جدًا لاستخدام Data API. يبدو أنه بالنسبة لـ Dat API، يوجد بعض موازن التحميل أمام قاعدة بيانات Aurora Serverless v2 الذي يراقب استخدام الاتصال ويحمي قاعدة البيانات من التحميل الزائد.
• لا يتم عرض مقياس DatabaseConnection (أو يظهر كـ 0) لاستخدام Data API. والسبب في ذلك هو أننا لا ندير اتصال قاعدة البيانات لـ Data API، بل يتم ذلك على الجانب الآخر بالنسبة لنا. بالطبع ما زالوا يلعبون دورًا مهمًا تعلمناه في الحد الأقصى للاتصالات لـ Aurora Serverless v2، ولكن يبدو أن هذا المقياس مكشوف للخارج في CloudWatch Metrics وحتى DevOps Guru ليس لديه أي إمكانية للوصول إلى الأرقام الحقيقية.

بفضل ذلك ومع انخفاض مستوى DLoad(CPU) المنخفض جدًا، لم يتم إنشاء رؤى DevOps Guru لمجموعة Aurora Serverless v2 مع استخدام Data API مقارنة بحالة استخدام JDBC.

لقد أجريت التجربة الثانية من خلال الاتصال بمجموعة Aurora Serverless v2 مباشرة وكتبت البرنامج النصي لإنشاء اختبار التحميل عن طريق كتابة البرنامج النصي الذي يجلب المنتج عن طريق المعرف عدة مئات من المرات باستخدام الطريقة القياسية (واجهة برمجة تطبيقات غير البيانات). تمامًا كما فعلنا مع أداة Hey، ولكن مع الانتقال إلى قاعدة البيانات مباشرة بدلاً من استدعاء Api Gateway. بعد أن قمت بتحميل قاعدة البيانات، بدأت نفس التجربة باستخدام أداة Hey كما هو موضح أعلاه وأردت معرفة ما سيحدث. تم إنشاء نفس الرؤية ولكن هذه المرة باستخدام المقاييس الشاذة التالية:

نرى الآن على الأقل مجموع قياس شاذ لاتصال قاعدة بيانات Aurora Serverless v2 الإضافي، لكن مقاييس DLoad(CPU) لا تزال مفقودة.

تبدو الحالات الشاذة في الرسم البياني كما يلي:

بالطبع، لم تكن التجربة نظيفة، حيث قمت بإجراء اختبارين للتحميل تلو الآخر وبالتوازي جزئيًا: الأول يتصل بقاعدة البيانات مباشرة دون استخدام بوابة API والثاني باستخدام Data API. أكد هذا افتراضاتي الأولية بأن مقاييس مجموع اتصال قاعدة البيانات هي معيار مهم جدًا لإنشاء رؤية DevOps Guru لـ Aurora Serverless v2 (وللـ RDS بشكل عام) ولا يتم الكشف عنها بشكل عام في حالة استخدام Data API.
لقد اتصلت بالفعل بفريق Devops Guru وشاركت معهم أفكاري مع التوقعات بأنهم سيعملون على تحسين الخدمة. أو أولاً وقبل كل شيء، سيتم إصلاح الكشف عن اتصال قاعدة البيانات كمقياس CloudWatch لاستخدام Aurora Serverless v2 مع Data API.

خاتمة

علمت في هذه المقالة أن DevOps Guru يمكنه اكتشاف الحالات الشاذة بنجاح باستخدام قاعدة بيانات Aurora (Serverless v2) PostgreSQL في حالة وظيفة Lambda مع وقت تشغيل Java 21 المُدار المتصل بها عبر Data API ولكن يمكنه فقط إظهار المقاييس الشاذة المتعلقة بوظيفة Lambda انتهاء المهلة لأن قاعدة البيانات لم تستجب. يبدو أن السبب الرئيسي لذلك هو أن اتصال قاعدة البيانات باعتباره CloudWatch Metric لا يتم كشفه (أو يتم عرضه دائمًا كـ 0) في حالة استخدام Aurora Serverless v2 مع Data API. تم عرض مقاييس قاعدة بيانات Aurora Serverless v2 (مجموع اتصال قاعدة البيانات) فقط خلال التجربة الاصطناعية الثانية.