راه‌اندازی و امن‌سازی Redis روی سرور مجازی و اختصاصی: نصب، پایداری داده و استفاده به‌عنوان کش

Redis یک ذخیره‌ساز دادهٔ درون‌حافظه‌ای است که برای کش، صف پیام، شمارنده و نگه‌داری موقت sessionها استفاده می‌شود. سرعت بالای آن از این واقعیت می‌آید که داده‌ها عمدتاً در RAM قرار دارند؛ بنابراین تنظیم درست حافظه، پایداری و دسترسی شبکه اهمیت زیادی دارد. در این راهنما، راه‌اندازی Redis روی سرور مجازی یا اختصاصی لینوکس را مرحله‌به‌مرحله انجام می‌دهیم و سپس نکات امنیتی، persistence، سیاست حذف داده و تست کارایی را بررسی می‌کنیم.

پیش‌نیازهای نصب Redis

پیش از نصب، سیستم‌عامل را به‌روز کنید و یک کاربر معمولی با دسترسی sudo داشته باشید. اجرای سرویس با کاربر root ریسک خطاهای ناخواسته را بیشتر می‌کند. برای یک کش کوچک، ۱ تا ۲ گیگابایت RAM کافی است؛ اما اگر قرار است دادهٔ اصلی یا صف‌های بزرگ نگه‌داری شوند، ظرفیت RAM و دیسک را بر اساس حجم واقعی داده انتخاب کنید. اگر با تنظیمات پایهٔ دسترسی امن به سرور آشنا نیستید، ابتدا امن‌سازی دسترسی SSH به سرور لینوکس را انجام دهید. همچنین باید مشخص کنید Redis فقط از همان سرور قابل دسترسی باشد یا برنامه‌ای روی شبکهٔ خصوصی به آن وصل شود. در حالت دوم، شبکهٔ خصوصی، فایروال و احراز هویت را هم‌زمان تنظیم کنید؛ باز گذاشتن پورت Redis روی اینترنت عمومی راه‌اندازی امن محسوب نمی‌شود.

نصب Redis در توزیع‌های رایج

Ubuntu و Debian

در نسخه‌های جدید اوبونتو و دبیان می‌توانید از بستهٔ رسمی توزیع استفاده کنید:

sudo apt update
sudo apt install redis-server
sudo systemctl enable --now redis-server

وضعیت سرویس را بررسی کنید:

sudo systemctl status redis-server
redis-cli ping

اگر پاسخ PONG بود، سرویس در حال اجراست. برای مشاهدهٔ نسخه نیز از redis-server --version استفاده کنید. در محیط تولیدی که به قابلیت‌های نسخهٔ جدید نیاز دارید، مخزن رسمی Redis یا ساخت از سورس را با توجه به سیاست به‌روزرسانی سازمان انتخاب کنید.

Rocky Linux، AlmaLinux و CentOS Stream

در خانوادهٔ RHEL معمولاً بستهٔ Redis از مخزن AppStream نصب می‌شود:

sudo dnf install redis
sudo systemctl enable --now redis
redis-cli ping

نام سرویس در این توزیع‌ها redis است. فایل تنظیمات عموماً در /etc/redis/redis.conf قرار دارد. بعد از هر تغییر، ابتدا ساختار فایل را بررسی و سپس سرویس را restart کنید:

sudo systemctl restart redis
sudo journalctl -u redis --since "10 minutes ago"

امن‌سازی دسترسی شبکه

فایل تنظیمات را با ویرایشگر مورد اعتماد باز کنید:

sudo nano /etc/redis/redis.conf

مهم‌ترین گزینه، bind است. اگر برنامه و Redis روی یک ماشین هستند، فقط loopback را مجاز کنید:

bind 127.0.0.1 ::1
protected-mode yes

برای اتصال از چند سرور، آدرس IP خصوصی سرور را نیز اضافه کنید؛ برای نمونه:

bind 127.0.0.1 10.10.0.15

از قرار دادن 0.0.0.0 در bind خودداری کنید، مگر این‌که فایروال و شبکهٔ خصوصی به‌دقت محدود شده باشند. در فایروال UFW، فقط IP برنامه را برای پورت پیش‌فرض ۶۳۷۹ مجاز کنید:

sudo ufw allow from 10.10.0.21 to any port 6379 proto tcp
sudo ufw deny 6379/tcp

در صورت استفاده از firewalld، معادل همین محدودیت را در zone مناسب اعمال کنید. پورت باز روی اینترنت عمومی، حتی با رمز عبور، سطح حملهٔ غیرضروری ایجاد می‌کند.

تنظیم احراز هویت

در نسخه‌های جدید Redis، روش ACL انعطاف‌پذیرتر است؛ با این حال، requirepass برای نصب‌های ساده همچنان کاربرد دارد:

requirepass یک-رمز-طولانی-و-تصادفی

رمز را در فایل‌های عمومی، مخزن کد یا اسکریپت‌های قابل خواندن قرار ندهید و مجوز فایل تنظیمات را محدود کنید:

sudo chown redis:redis /etc/redis/redis.conf
sudo chmod 640 /etc/redis/redis.conf

پس از restart، اتصال را با احراز هویت آزمایش کنید:

redis-cli -a 'رمز-طولانی-و-تصادفی' ping

برای محیط چندکاربره، ACL بسازید تا هر برنامه فقط فرمان‌ها و keyهای موردنیاز خود را ببیند:

redis-cli
> ACL SETUSER app on >رمز-اختصاصی ~app:* +get +set +del +expire
> ACL SAVE

در این مثال، کاربر app فقط به keyهایی با پیشوند app: و چند فرمان محدود دسترسی دارد.

رمزنگاری ارتباط با TLS

اگر Redis بین چند سرور یا از طریق شبکه‌ای خارج از کنترل شما ارتباط دارد، TLS را فعال کنید. Redis باید با گواهی سرور، کلید خصوصی و گواهی CA پیکربندی شود. مسیر فایل‌ها را فقط برای کاربر سرویس قابل خواندن کنید و در کلاینت نیز بررسی گواهی را روشن نگه دارید. TLS جای فایروال و ACL را نمی‌گیرد؛ هر سه لایه باید با هم استفاده شوند. این موارد بخشی از یک رویکرد امنیتی گسترده‌تر برای کل سرور هستند؛ برای گام‌های تکمیلی به افزایش امنیت سرور لینوکس مراجعه کنید.

انتخاب persistence: RDB یا AOF

Redis می‌تواند داده را روی دیسک ذخیره کند. دو روش اصلی، RDB و AOF هستند. RDB در بازه‌های زمانی از وضعیت کامل داده snapshot می‌گیرد و فایل فشرده‌تری تولید می‌کند. AOF هر تغییر را ثبت می‌کند و در صورت تنظیم appendfsync everysec معمولاً حداکثر حدود یک ثانیه دادهٔ اخیر را از دست می‌دهد. جدول زیر تفاوت عملی آن‌ها را نشان می‌دهد:

ویژگی	RDB	AOF
حجم فایل	معمولاً کمتر	معمولاً بیشتر
سرعت بازیابی	سریع‌تر برای snapshot بزرگ	وابسته به حجم log
میزان از دست رفتن داده	تا فاصلهٔ snapshot	معمولاً تا یک ثانیه
مناسب برای	کش و پشتیبان دوره‌ای	دادهٔ مهم‌تر و تغییرات پیوسته
فشار نوشتن دیسک	دوره‌ای	مداوم‌تر

برای کشی که بازسازی آن آسان است، می‌توانید RDB را فعال نگه دارید یا persistence را کاملاً خاموش کنید تا latency نوشتن کاهش یابد. برای صف‌ها یا sessionهایی که از دست رفتن آن‌ها هزینه دارد، AOF همراه با snapshot پشتیبان انتخاب محتاطانه‌تری است. persistence پشتیبان‌گیری نیست؛ فایل‌های RDB و AOF را به دیسک یا فضای دیگری کپی و بازیابی آن‌ها را به‌صورت دوره‌ای آزمایش کنید. برای این کار می‌توانید از الگوی پشتیبان‌گیری خودکار و رمزنگاری‌شده با Restic استفاده کنید. تنظیم نمونه:

save 900 1
save 300 10
appendonly yes
appendfsync everysec

در سرورهای پرترافیک، فضای دیسک و IOPS را پایش کنید. عملیات بازنویسی AOF می‌تواند هم‌زمان CPU و دیسک مصرف کند و روی latency اثر بگذارد.

تنظیم Redis برای استفاده به‌عنوان کش

اگر Redis نقش کش دارد، برای جلوگیری از مصرف بی‌نهایت RAM مقدار maxmemory تعیین کنید:

maxmemory 2gb
maxmemory-policy allkeys-lru

allkeys-lru کلیدهایی را حذف می‌کند که مدت بیشتری استفاده نشده‌اند و برای کش عمومی مناسب است. اگر فقط کلیدهای دارای تاریخ انقضا باید حذف شوند، volatile-lru را انتخاب کنید. سیاست noeviction در کش معمولاً باعث خطای نوشتن در زمان پر شدن حافظه می‌شود و باید آگاهانه استفاده شود. TTL را در برنامه تنظیم کنید تا دادهٔ قدیمی باقی نماند:

redis-cli -a 'رمز' set product:42 "..." ex 300
redis-cli -a 'رمز' ttl product:42

برای جلوگیری از هجوم هم‌زمان درخواست‌ها هنگام انقضای یک key، TTL را کمی تصادفی کنید. نام‌گذاری با پیشوندهایی مانند page:، session: و rate: نیز پاک‌سازی و محدودسازی ACL را ساده‌تر می‌کند. مقدار maxmemory-reserved را برای سربار داخلی و اتصال‌ها در نظر بگیرید تا Redis پیش از رسیدن کامل به سقف، پایدار بماند.

اتصال برنامه و الگوی Cache-Aside

در الگوی Cache-Aside، برنامه ابتدا Redis را می‌خواند؛ اگر key وجود نداشت، داده را از پایگاه‌داده می‌گیرد و با TTL در Redis می‌نویسد. هنگام تغییر دادهٔ اصلی، key مرتبط را حذف یا مقدار آن را به‌روزرسانی کنید. خطاهای Redis نباید لزوماً کل درخواست را از کار بیندازند؛ timeout کوتاه و مسیر جایگزین برای خواندن مستقیم از پایگاه‌داده تعریف کنید. برای عملیات چندمرحله‌ای، از pipeline یا تراکنش استفاده کنید تا رفت‌وبرگشت شبکه کم شود. از نگه‌داری payloadهای بسیار بزرگ در یک key پرهیز کنید؛ چند key کوچک‌تر معمولاً مدیریت حافظه و حذف را آسان‌تر می‌کند.

پایش، تست و عیب‌یابی

شاخص‌های used_memory, maxmemory, evicted_keys, keyspace_hits و keyspace_misses را با INFO بررسی کنید:

redis-cli -a 'رمز' INFO memory
redis-cli -a 'رمز' INFO stats
redis-cli -a 'رمز' SLOWLOG GET 20

نسبت hit را از تعداد hit و miss به‌دست آورید. hit پایین می‌تواند از TTL کوتاه، کلیدگذاری نادرست یا بی‌اثر بودن کش خبر دهد. افزایش evicted_keys نیز یعنی سقف حافظه مرتباً پر می‌شود و باید حجم داده یا سیاست حذف را بازبینی کنید. برای یک تست اولیهٔ کنترل‌شده:

redis-benchmark -h 127.0.0.1 -p 6379 -a 'رمز' -n 100000 -c 50 -t get,set

این آزمون را در ساعات کم‌ترافیک اجرا کنید؛ نتیجه به CPU، نوع دیسک، تعداد اتصال‌ها و اندازهٔ payload وابسته است. در تولید، latency صدک‌های ۹۵ و ۹۹ و همچنین زمان fork هنگام snapshot را جداگانه پایش کنید. اگر می‌خواهید این شاخص‌ها را در طول زمان و کنار سایر سرویس‌ها ببینید، راه‌اندازی مانیتورینگ سرور با Prometheus و Grafana مسیر مناسبی است.

چک‌لیست عملیاتی

• نصب سرویس از مخزن قابل اعتماد و فعال‌سازی اجرای خودکار
• محدود کردن bind به loopback یا IP خصوصی
• بستن پورت ۶۳۷۹ از اینترنت و استفاده از فایروال
• فعال کردن requirepass یا ACL با کمترین سطح دسترسی
• تعیین maxmemory و سیاست حذف متناسب با نوع داده
• انتخاب آگاهانهٔ RDB، AOF یا ترکیب آن‌ها
• تعریف TTL برای keyهای کش و استفاده از پیشوند نام‌گذاری
• پایش حافظه، hit rate، eviction، slowlog و فضای دیسک
• تهیه و آزمون بازیابی نسخهٔ پشتیبان
• مستندسازی رمزها و قرار ندادن آن‌ها در کد منبع اگر برای اجرای Redis به منابع پایدار، دیسک پرسرعت و شبکهٔ خصوصی نیاز دارید، سرور مجازی آریانت را بررسی کنید. انتخاب اندازهٔ RAM و امکان ارتقا کمک می‌کند سقف maxmemory را بدون فشار بر سرویس‌های دیگر تنظیم کنید.

جمع‌بندی

راه‌اندازی Redis روی سرور مجازی زمانی نتیجهٔ خوبی می‌دهد که نصب، امنیت و سیاست حافظه هم‌زمان طراحی شوند. Redis را فقط روی آدرس‌های لازم در دسترس بگذارید، احراز هویت و ACL را فعال کنید و persistence را بر اساس ارزش داده انتخاب کنید. برای کش، TTL و maxmemory-policy مهم‌تر از ذخیرهٔ دائمی هستند؛ برای صف یا session، AOF و پشتیبان‌گیری اهمیت بیشتری پیدا می‌کنند. پس از راه‌اندازی نیز با شاخص‌های حافظه و latency رفتار واقعی سیستم را بسنجید و تنظیمات را بر اساس بار کاری اصلاح کنید.