در دنیای محاسبات Serverless، استارتهای سرد اغلب به عنوان مشکل اصلی مطرح میشوند، اما تنها قاتل عملکردی که در معماری شما کمین کرده است، نیستند. برای بسیاری از توسعهدهندگان، گلوگاه خاموش، اضافهبار اتصال به پایگاه داده است. سرورهای برنامه سنتی اتصالات پایدار را حفظ میکنند، اما توابع Serverless زودگذر (Ephemeral) هستند. هر فراخوانی ممکن است یک کانتینر جدید ایجاد کند، به این معنی که هر کوئری پایگاه داده اغلب نیاز به یک دستتکانی TCP جدید و احراز هویت دارد. این تبادل پروتکل «پرگفتگو» میتواند تأخیر را به طور قابل توجهی افزایش دهد و عملیاتی که در حد میلیثانیه است را به یک تأخیر دهها میلیثانیهای تبدیل کند.
برای حل این مشکل بدون مدیریت زیرساختهای پیچیده، صنعت به سمت اتصال به عنوان سرویس (CPaaS) در حال حرکت است. این مقاله بررسی میکند که چگونه یکپارچهسازی لایههای مدیریتشده اتصال میتواند تأخیر را به شدت کاهش داده و بهرهوری هزینه را در محیطهای Serverless بهبود بخشد.
مشکل اتصال زودگذر
پلتفرمهای Serverless مانند AWS Lambda، Azure Functions یا Google Cloud Functions به شدت مقیاسپذیر هستند. وقتی ترافیک اوج میگیرد، پلتفرم هزاران نمونه تابع را راهاندازی میکند. اگر هر نمونه مستقیماً به یک پایگاه داده PostgreSQL یا MySQL متصل شود، با دو مشکل حیاتی روبرو میشوید:
- افزایش ناگهانی تأخیر: ایجاد یک اتصال TCP جدید و احراز هویت با پایگاه داده زمانبر است. در یک معماری میکروسرویس با چندین مرحله، این موضوع به سرعت جمع میشود.
- بار بیش از حد پایگاه داده: پایگاههای داده محدودیتی در اتصالات همزمان دارند. یک انفجار ناگهانی در فراخوانیهای Serverless میتواند مخزن اتصال در سرور پایگاه داده را تخلیه کند که منجر به خطاهای «تعداد بیش از حد اتصالات» و کرش کردن برنامه میشود.
اتصال به عنوان سرویس چگونه کار میکند؟
راهحلهای CPaaS (مانند AWS Aurora Proxy، Supavisor یا PgBouncer-as-a-Service) بین توابع Serverless شما و پایگاه داده قرار میگیرند. آنها یک مجموعه ثابت از اتصالات پایدار به پایگاه داده را حفظ میکنند، صرفنظر از اینکه چند تابع در حال اجرا هستند. وقتی تابعی نیاز به کوئری زدن به پایگاه داده دارد، پراکسی درخواست را از طریق یک اتصال بلااستفاده موجود هدایت میکند.
این رویکرد تعداد نمونههای برنامه را از تعداد اتصالات پایگاه داده جدا میکند. حتی اگر شما ۱۰۰۰ تابع Lambda در حال استارت سرد داشته باشید، پایگاه داده ممکن است تنها ۵۰ اتصال فعال از پراکسی را مشاهده کند.
استراتژی پیادهسازی
پیادهسازی یک لایه پراکسی نیاز به تغییرات حداقلی در کد دارد. شما به سادگی نقطه پایانی پایگاه داده خود را به جای اشاره مستقیم به نمونه پایگاه داده، به نام میزبان پراکسی بهروز میکنید. با این حال، بهترین شیوههایی برای اطمینان از کارایی وجود دارد.
نمونه کد: Node.js با پراکسی PgBouncer
در زیر یک مثال عملیاتی برای اتصال به پایگاه داده از طریق یک پراکسی اتصال در یک تابع Serverless Node.js آورده شده است. توجه داشته باشید که پیکربندی مشابه باقی میماند، اما میزبان به پراکسی اشاره میکند.
const { Pool } = require('pg');
// پیکربندی اکنون به پراکسی اتصال اشاره میکند
const pool = new Pool({
user: 'dbuser',
password: 'securepassword',
host: 'proxy-endpoint.supabase.co', // اشاره به پراکسی، نه پایگاه داده
port: 6543, // پورت استاندارد PgBouncer
database: 'myserverlesdb',
ssl: { rejectUnauthorized: false },
// زمانبندی بلاتکلیفی برای Serverless حیاتی است تا اتصالات را به مخزن بازگرداند
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000,
});
exports.handler = async (event) => {
const client = await pool.connect();
try {
const result = await client.query('SELECT now()');
return {
statusCode: 200,
body: JSON.stringify({ time: result.rows[0].now }),
};
} finally {
// همیشه کلاینت را به مخزن بازگردانید
client.release();
}
};
ملاحظات کلیدی پیکربندی
هنگام استفاده از پراکسیهای اتصال، باید مقدار idleTimeoutMillis را در کتابخانه کلاینت خود تنظیم کنید. اگر این مقدار خیلی بالا باشد، اتصالات بلااستفاده در مخزن سمت کلاینت انباشته شده و منابع را هدر میدهند. اگر خیلی پایین باشد، هزینه اتصال مجدد را به طور مکرر متحمل میشوید. تعادلی بین ۳۰ تا ۶۰ ثانیه معمولاً برای بارهای کاری Serverless ایدهآل است.
مزایای هزینه و تأخیر
فراتر از عملکرد، CPaaS صرفهجویی در هزینه ارائه میدهد. بسیاری از موتورهای پایگاه داده Serverless بر اساس IOPS اختصاصیافته یا تعداد اتصالات هزینه دریافت میکنند. با محدود کردن حداکثر تعداد اتصالات، میتوانید اندازه نمونه پایگاه داده خود را با دقت بیشتری تنظیم کنید. علاوه بر این، کاهش تأخیر منجر به زمان اجرای سریعتر تابع میشود که مستقیماً هزینه محاسبات را در مدلهای پرداخت به ازای استفاده کاهش میدهد.
نتیجهگیری
اتصال به عنوان سرویس فقط یک لوکس برای برنامههای با ترافیک بالا نیست؛ بلکه یک بهترین شیوه برای هر معماری Serverless جدی است. با انتزاع لایه مدیریت اتصال، شما اطمینان حاصل میکنید که برنامه شما پاسخگو، مقیاسپذیر و مقرونبهصرفه باقی میماند. هنگامی که پروژه Serverless بعدی خود را طراحی میکنید، در نظر بگیرید که یک پراکسی اتصال را به لایه زیرساخت خود اضافه کنید. این یک تغییر معماری کوچک با تأثیر عظیم بر تجربه کاربری و پایداری سیستم است.