استراتيجية تجميع الاتصال لقاعدة بيانات Azure ل PostgreSQL باستخدام PgBouncer

إرشادات استراتيجية لتحديد آلية تجميع الاتصال لقاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة.

مقدمة

عند استخدام قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن، يتضمن إنشاء اتصال بقاعدة البيانات إنشاء قناة اتصال بين تطبيق العميل والخادم. هذه القناة مسؤولة عن إدارة البيانات وتنفيذ الاستعلامات وبدء المعاملات. بمجرد تأسيس الاتصال، يمكن لتطبيق العميل إرسال أوامر إلى الخادم وتلقي الاستجابات. ومع ذلك، يمكن أن يؤدي إنشاء اتصال جديد لكل عملية إلى حدوث مشكلات في الأداء للتطبيقات ذات المهام الحرجة. في كل مرة يتم فيها إنشاء اتصال جديد، تولد قاعدة بيانات Azure ل PostgreSQL عملية جديدة باستخدام عملية postmaster، والتي تستهلك المزيد من الموارد.

للتخفيف من هذه المشكلة، يتم استخدام تجميع الاتصال لإنشاء ذاكرة تخزين مؤقت للاتصالات التي يمكن إعادة استخدامها في قاعدة بيانات Azure ل PostgreSQL. عندما يطلب تطبيق أو عميل اتصالا، يتم إنشاؤه من تجمع الاتصال. بعد اكتمال الجلسة أو المعاملة، يتم إرجاع الاتصال إلى التجمع لإعادة استخدامه. من خلال إعادة استخدام الاتصالات، يتم تقليل استخدام الموارد، وتحسين الأداء.

على الرغم من وجود أدوات مختلفة لتجميع الاتصال، فإننا نناقش في هذا القسم استراتيجيات مختلفة لاستخدام تجمع الاتصال باستخدام PgBouncer.

ما هو PgBouncer؟

PgBouncer هو تجمع اتصال فعال مصمم ل PostgreSQL، ويوفر ميزة تقليل وقت المعالجة وتحسين استخدام الموارد في إدارة اتصالات العملاء المتعددة إلى قاعدة بيانات واحدة أو أكثر. يتضمن PgBouncer ثلاثة وضع تجميع مميز لتدوير الاتصال:

• تجميع الجلسة: يعين هذا الأسلوب اتصال خادم لتطبيق العميل طوال مدة اتصال العميل. عند قطع اتصال تطبيق العميل، يقوم PgBouncer على الفور بإرجاع اتصال الخادم مرة أخرى إلى التجمع. آلية تجميع الجلسة هي الوضع الافتراضي في PgBouncer مفتوح المصدر. راجع تكوين PgBouncer
• تجميع المعاملات: مع تجميع المعاملات، يتم تخصيص اتصال خادم لتطبيق العميل أثناء المعاملة. بمجرد اكتمال المعاملة بنجاح، يقوم PgBouncer بتحرير اتصال الخادم بذكاء، مما يجعلها متاحة مرة أخرى داخل التجمع. تجميع المعاملات هو الوضع الافتراضي في قاعدة بيانات Azure ل PgBouncer المدمج في PostgreSQL، ولا يدعم المعاملات المعدة.
• تجميع العبارات: في تجميع العبارات، يتم تخصيص اتصال خادم لتطبيق العميل لكل عبارة فردية. عند اكتمال العبارة، يتم إرجاع اتصال الخادم على الفور إلى تجمع الاتصال. من المهم ملاحظة أن المعاملات متعددة العبارات غير مدعومة في هذا الوضع.

يمكن تصنيف الاستخدام الفعال ل PgBouncer إلى ثلاثة أنماط استخدام مميزة.

• نشر PgBouncer وApplication Colocation
• عمليات توزيع PgBouncer المركزية المستقلة للتطبيق
• نشر PgBouncer وقاعدة البيانات الموفرة

كل من هذه الأنماط له مزاياه وعيوبه الخاصة.

1. توزيع PgBouncer و colocation للتطبيق

عند استخدام هذا الأسلوب، يتم نشر PgBouncer على نفس الخادم حيث تتم استضافة التطبيق الخاص بك. يمكن نشر التطبيق وPgBouncer إما على الأجهزة الظاهرية التقليدية أو داخل بنية تستند إلى الخدمات المصغرة كما هو موضح:

ط. تم نشر PgBouncer في Application VM

إذا كان التطبيق الخاص بك يعمل على Azure VM، يمكنك إعداد PgBouncer على نفس الجهاز الظاهري. لتثبيت PgBouncer وتكوينه كوكيل تجميع اتصال مع مثيل خادم Azure Database for PostgreSQL المرن، اتبع الإرشادات الواردة في الارتباط التالي.

يمكن أن يوفر نشر PgBouncer في خادم التطبيق العديد من المزايا، خاصة عند العمل مع قاعدة بيانات Azure لقواعد بيانات الخادم المرنة PostgreSQL. بعض الفوائد والقيود الرئيسية لأسلوب النشر هذا هي:

الفوائد:

• زمن الانتقال المنخفض: من خلال نشر PgBouncer على نفس الجهاز الظاهري للتطبيق، يكون الاتصال بين التطبيق الأساسي وتجمع الاتصال فعالا بسبب قربهما. يؤدي نشر PgBouncer في Application VM إلى تقليل زمن الانتقال ويضمن تفاعلات سلسة وسريعة.
• الأمان المحسن:يمكن أن يعمل PgBouncer كوسيط آمن بين التطبيق وقاعدة البيانات، ما يوفر طبقة إضافية من الأمان. يمكنه فرض المصادقة والتشفير، ما يضمن أن العملاء المعتمدين فقط يمكنهم الوصول إلى قاعدة البيانات.

بشكل عام، يوفر نشر PgBouncer في خادم التطبيق نهجا أكثر كفاءة وأمانا وقابلية للتطوير لإدارة الاتصالات بقاعدة بيانات Azure لقواعد بيانات الخادم المرنة PostgreSQL، ما يعزز أداء التطبيق وموثوقيته.

القيود:

• نقطة فشل واحدة: إذا تم نشر PgBouncer كمثيل واحد على خادم التطبيق، فإنه يصبح نقطة فشل واحدة محتملة. إذا انخفض مثيل PgBouncer، فإنه يمكن أن يعطل تجمع اتصال قاعدة البيانات بالكامل، مما يتسبب في توقف التطبيق. للتخفيف من نقطة الفشل الفردية، يمكنك إعداد مثيلات PgBouncer متعددة خلف موازن تحميل لقابلية وصول عالية.
• قابلية التوسع المحدودة: تعتمد قابلية توسع PgBouncer على سعة الخادم حيث يتم نشره. إذا وصل خادم التطبيق إلى حد الاتصال الخاص به، فقد يصبح PgBouncer ازدحاما، ما يحد من القدرة على توسيع نطاق التطبيق. قد تحتاج إلى توزيع تحميل الاتصال عبر مثيلات PgBouncer متعددة أو التفكير في حلول بديلة مثل تجميع الاتصال على مستوى التطبيق.
• تعقيد التكوين: يمكن أن يكون تكوين PgBouncer وضبطه معقدا، خاصة عند التفكير في عوامل مثل حدود الاتصال، وتغيير حجم التجمع، وموازنة التحميل. يحتاج المسؤولون إلى ضبط تكوين PgBouncer بعناية لمطابقة متطلبات التطبيق وضمان الأداء والاستقرار الأمثل.

من المهم تقييم هذه القيود مقابل المزايا وتقييم ما إذا كان PgBouncer هو الخيار الصحيح لإعداد التطبيق وقاعدة البيانات المحددين.

2. تم نشر PgBouncer كبيان جانبي AKS

من الممكن استخدام PgBouncer كحاوية sidecar إذا كان التطبيق الخاص بك في حاوية ويعمل على خدمة Azure Kubernetes (AKS) أو Azure Container Instance (ACI) أو Azure Container Apps (ACA) أو Azure Red Hat OpenShift (ARO). يستمد نمط Sidecar إلهامه من مفهوم السيارة الجانبية المرفقة بدراجة نارية، حيث يتم إرفاق حاوية مساعدة، والمعروفة باسم حاوية sidecar، بالتطبيق الأصل. يثري هذا النمط التطبيق الأصلي من خلال توسيع وظائفه وتقديم الدعم الإضافي.

عادة ما يستخدم نمط sidecar مع الحاويات التي يتم جدولتها كمجموعة حاويات ذرية. يؤدي نشر PgBouncer في سيارة جانبية AKS إلى اقتران التطبيق ودورات حياة السيارة الجانبية بإحكام ويشارك الموارد مثل اسم المضيف والشبكات للاستفادة الفعالة من الموارد. تعمل العربة الجانبية PgBouncer جنبا إلى جنب مع حاوية التطبيق داخل نفس الجراب في Azure Kubernetes Service (AKS) مع تعيين 1:1، وتعمل كوكيل تجميع اتصال لقاعدة بيانات Azure لمثيلات الخادم المرنة PostgreSQL.

عادة ما يستخدم نمط sidecar هذا مع الحاويات التي يتم جدولتها كمجموعة حاويات ذرية. يربط نمط sidecar بشدة التطبيق ودورات حياة السيارة الجانبية ولديه موارد مشتركة مثل اسم المضيف والشبكات. باستخدام هذا الإعداد، يعمل PgBouncer على تحسين إدارة الاتصال وتسهيل الاتصال الفعال بين التطبيق ومثيل الخادم المرن لقاعدة بيانات Azure ل PostgreSQL.

نشرت Microsoft صورة وكيل جانبية PgBouncer في سجل حاويات Microsoft.

راجع هذا لمزيد من التفاصيل.

بعض الفوائد والقيود الرئيسية لأسلوب النشر هذا هي:

الفوائد:

• زمن الانتقال المنخفض: من خلال نشر PgBouncer كواجهة جانبية ل AKS، يكون الاتصال بين التطبيق الأساسي وتجمع الاتصال سلسا وفعالا بسبب قربهما. يؤدي نشر PgBouncer sidecar في AKS إلى تقليل زمن الانتقال ويضمن تفاعلات سلسة وسريعة.
• الإدارة والتوزيع المبسطان: يعمل الاقتران المحكم ل PgBouncer مع حاوية التطبيق على تبسيط عملية الإدارة والتوزيع. كلا المكونين متكاملان بإحكام، مما يسمح بإدارة أسهل وتنسيق سلس.
• قابلية الوصول العالية ومرونة الاتصال: إذا فشل حاوية تطبيق أو إعادة التشغيل، فإن حاوية PgBouncer الجانبية تتبع عن كثب، ما يضمن توفرا عاليا. يضمن هذا الإعداد مرونة الاتصال ويحافظ على أداء يمكن التنبؤ به حتى أثناء تجاوز الفشل، مما يساهم في نظام موثوق وقوي.

من خلال النظر في PgBouncer كجانب AKS، يمكنك استخدام هذه المزايا لتحسين أداء التطبيق الخاص بك، وتبسيط الإدارة، وضمان التوفر المستمر لمجمع الاتصال.

القيود:

• مشكلات أداء الاتصال: قد تواجه التطبيقات واسعة النطاق التي تستخدم آلاف الكبسولات، كل pgBouncer قيد التشغيل، تحديات محتملة تتعلق باستنفاد اتصال قاعدة البيانات. يمكن أن يؤدي هذا الموقف إلى تدهور الأداء وتعطل الخدمة. يؤدي نشر pgBouncer sidecar لكل جراب إلى زيادة عدد الاتصالات المتزامنة بخادم قاعدة البيانات، والتي يمكن أن تتجاوز سعتها. ونتيجة لذلك، قد تواجه قاعدة البيانات صعوبة في التعامل مع الحجم الكبير للاتصالات الواردة، وقد تؤدي إلى مشكلات في الأداء مثل زيادة أوقات الاستجابة أو حتى انقطاع الخدمة.
• التوزيع المعقد: يؤدي استخدام نمط sidecar إلى مستوى من التعقيد لعملية التوزيع، لأنه يتضمن تشغيل حاويتين داخل نفس الحاوية. قد يؤدي ذلك إلى تعقيد أنشطة استكشاف الأخطاء وإصلاحها وتصحيح الأخطاء، مما يتطلب جهدا إضافيا لتحديد المشكلات وحلها.
• تحديات التحجيم: من المهم ملاحظة أن نمط السيارة الجانبية قد لا يكون الخيار المثالي للتطبيقات التي تتطلب قابلية توسع عالية. يمكن أن يفرض تضمين حاوية sidecar المزيد من متطلبات الموارد، مما قد يحد من عدد الجرابات التي يمكن إنشاؤها وإدارتها بشكل فعال.

في أثناء النظر في هذا النمط الجانبي، من الضروري تقييم المقايضات بعناية بين تعقيد التوزيع ومتطلبات قابلية التوسع لتحديد النهج الأنسب لسيناريو التطبيق الخاص بك.

2. التطبيق المستقل - نشر PgBouncer المركزي

عند استخدام هذا النهج، يتم نشر PgBouncer كخدمة مركزية، مستقلة عن التطبيق. يمكن نشر خدمة PgBouncer إما على الأجهزة الظاهرية التقليدية أو داخل بنية تستند إلى الخدمات المصغرة كما هو موضح:

ط. تم نشر PgBouncer في ubuntu VM خلف Azure Load Balancer

يتم إعداد وكيل اتصال PgBouncer بين التطبيق وطبقة قاعدة البيانات خلف موازن تحميل Azure كما هو موضح في الصورة. في هذا النمط، يتم نشر مثيلات PgBouncer متعددة خلف موازن تحميل كخدمة للتخفيف من نقطة فشل واحدة. هذا النمط مناسب أيضا في السيناريوهات التي يعمل فيها التطبيق على خدمة مدارة مثل Azure App Services أو Azure Functions والاتصال بخدمة PgBouncer للتكامل السهل مع البنية الأساسية الحالية.

ارجع إلى الارتباط لتثبيت وكيل تجميع اتصال PgBouncer وإعداده باستخدام قاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة.

بعض الفوائد والقيود الرئيسية لأسلوب النشر هذا هي:

الفوائد:

• إزالة نقطة فشل واحدة: قد لا يتأثر اتصال التطبيق بفشل جهاز ظاهري PgBouncer واحد، حيث توجد العديد من مثيلات PgBouncer خلف Azure Load Balancer.
• التكامل السلس مع الخدمات المدارة: إذا كان التطبيق الخاص بك مستضافا على نظام أساسي للخدمة المدارة مثل Azure App Services أو Azure Functions، فإن نشر PgBouncer على جهاز ظاهري يسمح بالتكامل السهل مع البنية الأساسية الحالية.
• الإعداد المبسط على Azure VM: إذا كنت تقوم بالفعل بتشغيل التطبيق الخاص بك على جهاز Azure الظاهري، فإن إعداد PgBouncer على نفس الجهاز الظاهري أمر مباشر. يضمن نشر PgBouncer في الجهاز الظاهري نشر PgBouncer على مقربة من التطبيق الخاص بك، ما يقلل من زمن انتقال الشبكة وزيادة الأداء إلى أقصى حد.
• التكوين غير التدخلي: من خلال نشر PgBouncer على جهاز ظاهري، يمكنك تجنب تعديل معلمات الخادم على قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. هذا مفيد عندما تريد تكوين PgBouncer على قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. على سبيل المثال، قد يؤدي تغيير معلمة SSL إلى "مطلوب" على مثيل خادم مرن Azure Database for PostgreSQL إلى فشل بعض التطبيقات التي تعتمد على SSLMODE=FALSE. يسمح لك نشر PgBouncer على جهاز ظاهري منفصل بالاحتفاظ بتكوين الخادم الافتراضي مع الاستمرار في استخدام مزايا PgBouncer.

من خلال النظر في هذه الفوائد، يوفر نشر PgBouncer على جهاز ظاهري حلا مناسبا وفعالا لتحسين أداء وتوافق تطبيقك الذي يعمل على البنية الأساسية ل Azure.

القيود:

• الحمل الإداري: عند تثبيت PgBouncer في الجهاز الظاهري، قد يكون هناك حمل إداري لإدارة ملفات تكوين متعددة. وهذا يجعل من الصعب التعامل مع ترقيات الإصدار والإصدارات الجديدة وتحديثات المنتجات.
• تكافؤ الميزة: إذا كنت تقوم بالترحيل من PostgreSQL التقليدي إلى قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن وتستخدم PgBouncer، فقد تكون هناك بعض فجوات الميزات. على سبيل المثال، عدم وجود دعم md5 في قاعدة بيانات Azure ل PostgreSQL.

2. PgBouncer المركزي الذي تم نشره كخدمة داخل AKS

إذا كنت تعمل مع عمليات نشر كبيرة وقابلة للتطوير في حاويات على Azure Kubernetes Service (AKS)، تتكون من مئات الحجيرات، أو في الحالات التي تحتاج فيها تطبيقات متعددة إلى الاتصال بقاعدة بيانات مشتركة، يمكن استخدام PgBouncer كخدمة مستقلة بدلا من حاوية جانبية.

باستخدام PgBouncer كخدمة منفصلة، يمكنك إدارة ومعالجة تجميع الاتصال لتطبيقاتك بكفاءة على نطاق أوسع. يسمح هذا الأسلوب بمركزية وظيفة تجميع الاتصال، ما يتيح تطبيقات متعددة للاتصال بنفس مورد قاعدة البيانات مع الحفاظ على الأداء الأمثل واستخدام الموارد.

يمكن استخدام صورة وكيل PgBouncer sidecar المنشورة في سجل حاويات Microsoft لإنشاء خدمة ونشرها.

بعض الفوائد والقيود الرئيسية لأسلوب النشر هذا هي:

الفوائد:

• الموثوقية المحسنة: يسمح نشر PgBouncer كخدمة مستقلة بالتكوين بطريقة متوفرة بشكل كبير. وهذا يحسن الموثوقية الإجمالية للبنية الأساسية لتجميع الاتصال، ما يضمن التوفر المستمر حتى في مواجهة حالات الفشل أو الاضطرابات.
• الاستخدام الأمثل للموارد: إذا كان التطبيق أو خادم قاعدة البيانات لديه موارد محدودة، فقد يكون اختيار جهاز منفصل مخصص لتشغيل خدمة PgBouncer مفيدا. من خلال نشر PgBouncer على جهاز يحتوي على موارد وافرة، يمكنك ضمان الأداء الأمثل ومنع مشكلات التنازع على الموارد.
• إدارة الاتصال المركزية: عندما تكون الإدارة المركزية لاتصالات قاعدة البيانات مطلبا، توفر خدمة PgBouncer المستقلة نهجا أكثر انسيابية. من خلال دمج مهام إدارة الاتصال في خدمة مركزية، يمكنك مراقبة اتصالات قاعدة البيانات والتحكم فيها بفعالية عبر تطبيقات متعددة، وتبسيط الإدارة وضمان التناسق.

من خلال النظر في PgBouncer كخدمة مستقلة داخل AKS، يمكنك استخدام هذه الفوائد لتحقيق موثوقية محسنة وكفاءة الموارد والإدارة المركزية لاتصالات قاعدة البيانات.

القيود:

• زيادة زمن الانتقال N/W: عند نشر PgBouncer كخدمة مستقلة، من المهم مراعاة الإدخال المحتمل لوقت انتقال أكبر. ويرجع ذلك إلى الحاجة إلى تمرير الاتصالات بين التطبيق وخدمة PgBouncer عبر الشبكة. من الضروري تقييم متطلبات زمن الانتقال للتطبيق الخاص بك والنظر في المفاضلات بين إدارة الاتصال المركزية ومشكلات زمن الانتقال المحتملة.

بينما يوفر PgBouncer الذي يعمل كخدمة مستقلة فوائد مثل الإدارة المركزية وتحسين الموارد، من المهم تقييم تأثير زمن الانتقال المحتمل على أداء التطبيق الخاص بك لضمان توافقه مع متطلباتك المحددة.

3. PgBouncer المدمج في قاعدة بيانات Azure ل PostgreSQL

تقدم قاعدة بيانات Azure ل PostgreSQL PgBouncer كحل مضمن لتجميع الاتصالات. يتم تقديم هذا كخدمة اختيارية يمكن تمكينها على أساس خادم لكل قاعدة بيانات. يعمل PgBouncer في نفس الجهاز الظاهري مثل قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. مع زيادة عدد الاتصالات إلى ما يتجاوز بضع مئات أو آلاف، قد تواجه قاعدة بيانات Azure ل PostgreSQL قيودا على الموارد. في مثل هذه الحالات، يمكن أن يوفر PgBouncer المضمن ميزة كبيرة من خلال تحسين إدارة الاتصالات الخاملة قصيرة الأجل في خادم قاعدة البيانات.

راجع الارتباط لتمكين تجميع اتصال PgBouncer وإعداده في قاعدة بيانات Azure ل PostgreSQL.

بعض الفوائد والقيود الرئيسية لأسلوب النشر هذا هي:

الفوائد:

• التكوين السلس: باستخدام PgBouncer المضمن في قاعدة بيانات Azure لمثيل الخادم المرن PostgreSQL، ليست هناك حاجة لتثبيت منفصل أو إعداد معقد. يمكن تكوينه بسهولة مباشرة من معلمات الخادم، ما يضمن تجربة خالية من المتاعب.
• راحة الخدمة المدارة: كخدمة مدارة، يمكن للمستخدمين الاستمتاع بمزايا خدمات Azure المدارة الأخرى. يتضمن ذلك التحديثات التلقائية، مما يلغي الحاجة إلى الصيانة اليدوية ويضمن بقاء PgBouncer على اطلاع بأحدث الميزات وتصحيحات الأمان.
• دعم الاتصال العام والخاص: يوفر PgBouncer المضمن في قاعدة بيانات Azure لمثيل الخادم المرن PostgreSQL دعما لكل من الاتصالات العامة والخاصة. يسمح هذا للمستخدمين بإنشاء اتصالات آمنة عبر الشبكات الخاصة أو الاتصال خارجيا، اعتمادا على متطلباتهم المحددة.
• قابلية وصول عالية (HA): في حالة تجاوز الفشل، حيث يتم ترقية خادم الاستعداد إلى الدور الأساسي، تتم إعادة تشغيل PgBouncer بسلاسة في وضع الاستعداد الذي تمت ترقيته حديثا دون أي تغييرات مطلوبة للتطبيق سلسلة الاتصال. وهذا يضمن التوفر المستمر ويقلل من تعطيل التطبيق.
• كفاءة التكلفة: إنها فعالة من حيث التكلفة حيث لا يحتاج المستخدمون إلى الدفع مقابل حساب إضافي مثل الجهاز الظاهري أو الحاويات، على الرغم من أن لها بعض التأثير على وحدة المعالجة المركزية لأنها عملية أخرى تعمل على نفس الجهاز.

باستخدام PgBouncer المضمن في مثيل خادم مرن Azure Database for PostgreSQL، يمكن للمستخدمين الاستمتاع براحة التكوين المبسط وموثوقية الخدمة المدارة ودعم أوضاع التجميع المختلفة والتوافر العالي السلس أثناء سيناريوهات تجاوز الفشل.

القيود:

• غير مدعوم مع الاندفاع:PgBouncer غير مدعوم حاليا مع طبقة حساب خادم قابل للاندفاع. إذا قمت بتغيير طبقة الحوسبة من الغرض العام أو الذاكرة المحسنة إلى طبقة قابلة للاندفاع، فستفقد قدرة PgBouncer .
• إعادة إنشاء الاتصالات بعد إعادة التشغيل: كلما تمت إعادة تشغيل الخادم أثناء عمليات المقياس أو تجاوز فشل HA أو إعادة التشغيل، تتم أيضا إعادة تشغيل PgBouncer مع الجهاز الظاهري للخادم. ومن ثم، يجب إعادة إنشاء الاتصالات الموجودة.

لقد ناقشنا طرقا مختلفة لتنفيذ PgBouncer ويلخص الجدول أسلوب النشر الذي يجب اختياره:

معايير التحديد	PgBouncer على App VM	PgBouncer على الجهاز الظاهري باستخدام ALB*	PgBouncer على AKS Sidecar	PgBouncer كخدمة	قاعدة بيانات Azure ل PostgreSQL PgBouncer مضمنة
إدارة مبسطة
هكتار
التطبيقات المعبأة في حاويات
تقليل حمل الشبكة وزمن الانتقال
التحكم الدقيق في المراقبة وتصحيح الأخطاء

وسيلة الإيضاح

مستوى الصعوبة	رمز
سهل
متوسط
صعب

*ALB: موازن تحميل Azure.