ابر ترکیبی برای سازمان‌ها؛ چرا و چگونه زیرساخت خود را ترکیبی کنیم

تصور کنید سازمان شما یک وب‌سایت فروشگاهی با ترافیک فصلی دارد و هم‌زمان یک پایگاه‌داده مالی حساس که نمی‌خواهید حتی یک رکورد آن از دیوارهای دیتاسنتر خودتان بیرون برود. اگر همه‌چیز را به ابر عمومی بسپارید، نگران حریم داده‌ها هستید؛ اگر همه‌چیز را داخلی نگه دارید، برای پیک ترافیک باید سرورهایی بخرید که یازده ماه سال بیکارند. راه حل میانی، ابر ترکیبی است؛ معماری‌ای که در آن بخشی از بار کاری روی زیرساخت داخلی (on-premises) و بخشی روی ابر عمومی اجرا می‌شود و این دو از طریق یک اتصال امن و کم‌تأخیر با هم حرف می‌زنند.

در این مقاله قرار نیست تعریف تئوری بدهیم. قرار است بفهمیم چرا یک سازمان واقعی باید سراغ ابر ترکیبی برود، چه چیزهایی را باید داخلی نگه دارد، اتصال بین دو سمت را چطور طراحی کند و کجاها معمولاً همه چیز خراب می‌شود.

چرا ابر ترکیبی؟ سه دلیل که ربطی به مد روز بودن ندارد

ابر ترکیبی یک انتخاب لوکس نیست؛ در خیلی از موارد تنها گزینه‌ای است که هم الزامات فنی و هم محدودیت‌های قانونی را ارضا می‌کند. سه دلیل اصلی را با جزئیات بررسی می‌کنیم.

۱. داده‌هایی که قانون اجازه خروج نمی‌دهد

در ایران و بسیاری از کشورها، داده‌های مالی، پزشکی و برخی داده‌های دولتی مشمول مقرراتی هستند که نگهداری آن‌ها را در خارج از مرز یا حتی خارج از دیتاسنتر مشخصی الزامی می‌کند. اگر سازمان شما با چنین داده‌هایی کار می‌کند، ابر عمومی خالص عملاً از گزینه‌ها حذف می‌شود. اما این به آن معنا نیست که نتوانید از مزایای ابر برای بخش‌های دیگر استفاده کنید. داده‌های حساس روی سرورهای داخلی می‌مانند و بخش‌های کم‌حساسیت‌تر مثل وب‌سرور عمومی یا محیط تست روی ابر اجرا می‌شوند.

۲. بار کاری نوسانی و هزینه‌ی خرید سخت‌افزار

فرض کنید سامانه‌ی ثبت‌نام کنکور دارید که در دو هفته‌ی خاص از سال، ترافیکش ۵۰ برابر حالت عادی می‌شود. اگر بخواهید این پیک را با خرید سرور داخلی جواب بدهید، باید سخت‌افزاری بخرید که ۵۰ برابر نیاز عادی است و ۱۱ ماه سال بیکار می‌ماند. در ابر ترکیبی، ظرفیت پایه را داخلی نگه می‌دارید و در پیک، نمونه‌های (instances) ابری را بالا می‌آورید. این کار هم هزینه‌ی خرید را کاهش می‌دهد و هم انعطاف‌پذیری می‌دهد که بعد از تمام شدن پیک، منابع ابری را آزاد کنید.

۳. تأخیر بحرانی برای پردازش‌های بلادرنگ

بعضی پردازش‌ها مثل تشخیص تقلب در تراکنش‌های بانکی یا کنترل کیفیت خط تولید، به تأخیر زیر ۱۰ میلی‌ثانیه نیاز دارند. ارسال داده به یک دیتاسنتر ابری که شاید صدها کیلومتر آن طرف‌تر است، این الزام را نقض می‌کند. این پردازش‌ها باید روی سخت‌افزار داخلی اجرا شوند. اما نتیجه‌ی نهایی آن‌ها را می‌توانید برای تحلیل‌های بعدی به ابر بفرستید.

چه چیزی را داخلی نگه داریم؟ یک چارچوب تصمیم‌گیری

به جای اینکه لیست آماده بدهیم، یک چارچوب سه‌سؤالی پیشنهاد می‌کنم. برای هر سرویس یا داده‌ای این سه سؤال را بپرسید:

1. آیا قانون یا قرارداد، محل نگهداری داده را مشخص کرده است؟ اگر بله، آن داده داخلی می‌ماند.
2. آیا سرویس به تأخیر کمتر از ۲۰ میلی‌ثانیه نیاز دارد؟ اگر بله، اجرای داخلی الزامی است مگر اینکه ابری با موقعیت جغرافیایی بسیار نزدیک داشته باشید.
3. آیا نوسان بار کاری بیش از ۵ برابر میانگین است؟ اگر بله، این سرویس کاندیدای خوبی برای بخش ابری است تا مجبور نباشید برای پیک، سخت‌افزار بخرید.

با این چارچوب، یک الگوی رایج شکل می‌گیرد: پایگاه‌داده‌های اصلی، سرویس‌های پرداخت و پردازش‌های بلادرنگ داخلی می‌مانند؛ وب‌سرورهای عمومی، محیط‌های تست و توسعه، سرویس‌های تحلیل داده و پردازش‌های دسته‌ای (batch) به ابر می‌روند.

معماری اتصال در ابر ترکیبی؛ جایی که همه‌چیز خراب می‌شود

بزرگ‌ترین چالش فنی ابر ترکیبی، اتصال بین دو سمت است. اگر این اتصال درست طراحی نشود، کل معماری از هم می‌پاشد. سه لایه‌ی اتصال را باید جداگانه طراحی کنید.

لایه‌ی شبکه: VPN یا اتصال اختصاصی؟

ساده‌ترین راه، برقراری تونل VPN بین دیتاسنتر داخلی و VPC ابری است. برای شروع کار و حجم‌های کم، IPSec Site-to-Site VPN کافی است. اما دو محدودیت دارد: پهنای باند محدود به اینترنت شماست و پایداری آن به کیفیت لینک اینترنت بستگی دارد.

اگر حجم داده‌ی جابجایی بالا است (مثلاً بیش از ۵۰ گیگابایت در روز) یا به پایداری بالا نیاز دارید، باید به فکر اتصال اختصاصی باشید. خیلی از ارائه‌دهندگان ابری، سرویس اتصال مستقیم (Direct Connect) دارند که از طریق یک لینک اختصاصی به دیتاسنتر شما وصل می‌شود. در این حالت، تأخیر پایدارتر و پهنای باند قابل پیش‌بینی است.

یک نکته‌ی مهم: هرگز به یک لینک واحد اکتفا نکنید. حداقل دو مسیر اتصال (redundant) طراحی کنید تا اگر یکی قطع شد، ترافیک از مسیر دیگر عبور کند.

لایه‌ی داده: سنکرون‌سازی دوطرفه

وقتی پایگاه‌داده داخلی دارید و برنامه‌های ابری هم به آن نیاز دارند، دو گزینه دارید:

• دسترسی مستقیم: برنامه‌های ابری از طریق اتصال شبکه به پایگاه‌داده داخلی وصل می‌شوند. ساده است اما اگر اتصال قطع شود، برنامه‌های ابری از کار می‌افتند.
• سنکرون‌سازی داده: یک کپی از داده‌ها در ابر نگه‌داری می‌شود و به‌صورت دوره‌ای (مثلاً هر ۵ دقیقه) با منبع داخلی سنکرون می‌شود. برنامه‌های ابری به کپی محلی خودشان وصل می‌شوند. این روش مقاوم‌تر است اما پیچیدگی سنکرون‌سازی را اضافه می‌کند.

برای سنکرون‌سازی، ابزارهای متن‌باز مثل pglogical برای PostgreSQL یا MySQL Replication برای MySQL کار می‌کنند. نکته‌ی حیاتی این است که سنکرون‌سازی باید دوطرفه باشد و conflict resolution تعریف شده باشد. مثلاً اگر یک رکورد هم در سمت داخلی و هم در سمت ابری ویرایش شود، کدام نسخه برنده است؟

# مثال: تنظیم replication یک‌طرفه از داخلی به ابر با pglogical
-- روی سرور داخلی (provider)
SELECT pglogical.create_node(
    node_name := 'internal',
    dsn := 'host=192.168.1.10 port=5432 dbname=mydb'
);

-- روی سرور ابری (subscriber)
SELECT pglogical.create_node(
    node_name := 'cloud',
    dsn := 'host=10.0.0.5 port=5432 dbname=mydb'
);
SELECT pglogical.create_subscription(
    subscription_name := 'internal_to_cloud',
    provider_node := 'internal',
    replication_sets := '{default}'
);

لایه‌ی برنامه: یکپارچگی و کش

برنامه‌هایی که روی ابر اجرا می‌شوند باید طوری طراحی شوند که قطعی موقت اتصال را تحمل کنند. این یعنی استفاده از الگوی Circuit Breaker و Retry با Backoff. همچنین برای کاهش وابستگی به اتصال، از کش (Cache) استفاده کنید. مثلاً اگر برنامه‌ی ابری به لیست محصولات نیاز دارد که هر ساعت یک بار تغییر می‌کند، آن را در Redis کش کنید و هر ساعت یک بار از منبع داخلی به‌روزرسانی کنید. این کار تعداد درخواست‌های عبوری از اتصال را به شدت کاهش می‌دهد.

امنیت در مرز ابر ترکیبی

وقتی شبکه‌ی داخلی به ابر وصل می‌شود، سطح حمله بزرگ‌تر می‌شود. چند اقدام ضروری را جدی بگیرید:

Segment و Micro-segmentation

شبکه‌ی داخلی را به بخش‌های مجزا تقسیم کنید. پایگاه‌داده‌های حساس در یک VLAN جدا باشند و فقط از طریق یک Jump Server قابل دسترسی باشند. در سمت ابر هم، از Security Group ها استفاده کنید که فقط پورت‌های لازم را باز کنند. مثلاً اگر برنامه‌ی ابری فقط به پورت 5432 پایگاه‌داده داخلی نیاز دارد، هیچ پورت دیگری نباید از سمت ابر به سمت داخلی باز باشد.

رمزنگاری در حال انتقال و در حالت سکون

تمام ترافیک بین دو سمت باید با TLS یا IPSec رمزنگاری شود. داده‌های ذخیره‌شده در هر دو سمت هم باید رمزنگاری شوند. برای کلیدهای رمزنگاری، از یک سرویس مدیریت کلید (KMS) استفاده کنید که کلیدها را به‌صورت متمرکز مدیریت کند و دسترسی به آن‌ها را لاگ بگیرد.

مانیتورینگ و هشدار

ترافیک عبوری بین دو سمت را مانیتور کنید. حجم غیرعادی داده، تعداد اتصال‌های ناموفق یا الگوهای زمانی غیرعادی می‌تواند نشانه‌ی نفوذ باشد. ابزارهایی مثل Prometheus و Grafana برای مانیتورینگ و Alertmanager برای هشدار، انتخاب‌های متن‌باز و رایجی هستند.

سناریوی عملی: فروشگاه اینترنتی با پیک فصلی

برای اینکه همه‌چیز ملموس شود، یک سناریوی کامل را با هم طراحی می‌کنیم. فرض کنید یک فروشگاه اینترنتی دارید که در مناسبت‌های خاص (مثل شب یلدا یا عید) ترافیکش ۲۰ برابر می‌شود.

معماری پیشنهادی

• داخلی: پایگاه‌داده‌ی اصلی PostgreSQL، سرویس پرداخت، انبارداری و نرم‌افزار حسابداری.
• ابر: وب‌سرورهای Nginx، سرورهای برنامه (مثلاً Node.js یا PHP-FPM)، Redis برای کش و session، و محیط تست.

در حالت عادی، ۲ نمونه‌ی ابری برای وب و برنامه کافی است. در پیک، به‌صورت خودکار (با Auto Scaling) تعداد نمونه‌ها به ۲۰ می‌رسد. برنامه‌های ابری از طریق اتصال اختصاصی به پایگاه‌داده‌ی داخلی وصل می‌شوند. برای کاهش بار روی پایگاه‌داده، همه‌ی خواندن‌های پرتکرار (مثل لیست محصولات و قیمت‌ها) از Redis کش می‌شوند و فقط نوشتن‌ها (سفارش‌ها) مستقیم به پایگاه‌داده می‌روند.

مدیریت خرابی

اگر اتصال بین دو سمت قطع شود، چه اتفاقی می‌افتد؟ برنامه‌های ابری باید طوری طراحی شوند که سفارش‌ها را در یک صف محلی (مثلاً RabbitMQ روی همان نمونه‌ی ابری) نگه دارند و وقتی اتصال برگشت، آن‌ها را به پایگاه‌داده‌ی داخلی ارسال کنند. این الگو را Store and Forward می‌نامند و برای تاب‌آوری در ابر ترکیبی حیاتی است.

اشتباهات رایج در پیاده‌سازی ابر ترکیبی

در پایان، چهار اشتباهی که تقریباً در همه‌ی پروژه‌های ناموفق دیده‌ام را مرور می‌کنیم:

1. بی‌توجهی به تأخیر شبکه: فرض می‌کنند چون اتصال برقرار است، پس تأخیر不重要 است. غافل از اینکه هر درخواست برنامه‌ی ابری که به پایگاه‌داده‌ی داخلی می‌رود، دو بار از شبکه عبور می‌کند (رفتن و برگشتن). اگر تأخیر یک‌طرفه ۵ میلی‌ثانیه باشد، هر کوئری ۱۰ میلی‌ثانیه بیشتر طول می‌کشد. برای برنامه‌هایی با هزاران کوئری در ثانیه، این عدد فاجعه است.
2. عدم تست قطعی اتصال: قطعی اتصال را در محیط تست شبیه‌سازی نمی‌کنند. روزی که واقعاً قطع می‌شود، تازه می‌فهمند برنامه‌های ابری به‌کلی از کار افتاده‌اند.
3. سنکرون‌سازی یک‌طرفه: داده‌ها را فقط از داخلی به ابر سنکرون می‌کنند و فراموش می‌کنند که بعضی داده‌ها (مثل سبد خرید کاربران) در ابر تولید می‌شوند و باید به داخلی برگردند.
4. نبود استراتژی خروج: اگر یک روز خواستید از ابر خارج شوید یا ارائه‌دهنده را عوض کنید، چطور داده‌ها را برمی‌گردانید؟ این را از روز اول باید طراحی کنید، نه وقتی که به آن نیاز پیدا می‌کنید.

جمع‌بندی

ابر ترکیبی یک معماری بالغ است که به شما اجازه می‌دهد هم از مزایای ابر عمومی (مقیاس‌پذیری، هزینه‌ی متغیر) استفاده کنید و هم کنترل داده‌های حساس را در دست خودتان نگه دارید. کلید موفقیت، تصمیم‌گیری آگاهانه درباره‌ی محل اجرای هر سرویس، طراحی دقیق اتصال شبکه و سنکرون‌سازی داده، و آمادگی برای قطعی‌هاست. اگر این سه رکن را جدی بگیرید، ابر ترکیبی به یکی از قدرتمندترین ابزارهای زیرساختی سازمان شما تبدیل می‌شود. اگر هم تازه شروع کرده‌اید، با یک بار کاری کوچک و غیرحساس شروع کنید، تجربه کسب کنید و سپس معماری را گسترش دهید.