README.md

آماده برای تولید

در این فصل به مباحث زیر می پردازیم:

• انتخاب یک وب استک
• رویکردهای میزبانی
• بزارهای استقرار
• مانیتورینگ
• نکاتی برای کارایی

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

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

محیط تولید و پروداکشن

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

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

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

اکثر برنامه‌های کاربردی وب در سایت‌هایی با خرابی بسیار کم مستقر می‌شوند، به عنوان مثال، مراکز داده بزرگ در پنج 9، یعنی 99.999 درصد، آپتایم هستند. با طراحی برای خرابی، حتی اگر یک جزء داخلی خراب شود، افزونگی کافی برای جلوگیری از خرابی کل سیستم وجود دارد. مفهوم اجتناب از یک نقطه شکست (SPOF) را می توان در هر سطح، سخت افزار یا نرم افزار اعمال کرد.

این امر درواقع مجموعه ای مهم از نرم افزارهایی است که شما انتخاب می کنید تا در محیط تولید خود اجرا شوند.

انتخاب یک پشته وب(استک)

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

با یک پشته وب، به مجموعه فناوری هایی اشاره می کنیم که برای ساخت یک برنامه وب استفاده می شوند. معمولاً به صورت مجموعه‌ای از مؤلفه‌ها، مانند سیستم عامل، پایگاه داده و وب سرور، که همگی روی یکدیگر جمع شده‌اند، نشان داده می‌شود. از این رو، از آن به عنوان پشته یاد می شود.

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

کامپوننت های یک پشته

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

• کدام سیستم عامل و توزیع؟ به عنوان مثال، دبیان، رد هت یا OpenBSD
• کدام سرور WSGI؟ به عنوان مثال، Gunicorn یا uWSGI.
• کدام وب سرور؟ به عنوان مثال، Apache یا Nginx.
• کدام دیتابیس؟ به عنوان مثال، PostgreSQL، MySQL یا Redis
• کدام سیستم کش؟ مثلا Memcached یا Redis.
• کدام سیستم کنترل فرآیند و مانیتورینگ؟ به عنوان مثال، Upstart، Systemd، یا Supervisord.
• چگونه رسانه های استاتیک را ذخیره کنیم؟ به عنوان مثال، Amazon S3 یا CloudFront

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

وقتی نوبت به انتخاب پشته شما می رسد، هیچ پاسخی برای همه وجود ندارد. اجزای مختلف نقاط قوت و ضعف متفاوتی دارند. آنها را تنها پس از بررسی دقیق و آزمایش انتخاب کنید. به عنوان مثال، ممکن است شنیده باشید که Nginx یک انتخاب محبوب برای وب سرور است، اما ممکن است در واقع به اکوسیستم غنی ماژول ها یا گزینه های آپاچی نیاز داشته باشید.

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

از این رو، نحوه انتخاب میزبانی برنامه جنگو یکی از عوامل کلیدی در تعیین تنظیمات تولید شما است.

ماشینهای مجازی یا داکر

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

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

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

میکروسرویس ها

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

مثال زیر یک مثال ساده از یک برنامه وب جنگو است که به عنوان میکروسرویس با استفاده از کانتینرها اجرا شده است:

این میکروسرویس واحد از سه کانتینر با اجزای منطقی مجزا تشکیل شده است: ظرف Nginx (وب سرور)، کانتینر Gunicorn/Django (برنامه وب) و کانتینر PostgreSQL (پایگاه داده). هر ظرف از یک داکر ایمیج که ممکن است با استفاده از یک Dockerfile ساخته شود، نمونه سازی شده است.

کانتینرهای Docker یک سیستم فایل زودگذر دارند، بنابراین داده‌های پایدار با ایجاد صریح یک حجم مدیریت می‌شوند. از ولوم ها می توان برای اشتراک گذاری داده ها بین کانتینرها استفاده کرد. در این حالت، فایل‌های استاتیک پروژه جنگو را می‌توان در کانتینر Nginx به اشتراک گذاشت تا مستقیماً به آن‌ها سرویس داده شود.

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

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

میزبانی و هاستینگ

وقتی نوبت به هاستینگ می رسد، باید مطمئن شوید که آیا به دنبال بستر(پلتفرم) میزبانی مانند Heroku هستید یا خیر. اگر اطلاعات زیادی در مورد مدیریت سرور ندارید یا کسی با آن دانش در تیم خود ندارید، پلتفرم میزبانی گزینه مناسبی است.

پلتفرم به عنوان سرویس

پلتفرم به عنوان سرویس (PaaS) یک سرویس ابری است که در آن راه حل از قبل برای شما ارائه و مدیریت شده است. پلتفرم های محبوب برای میزبانی جنگو عبارتند از Heroku، PythonAnywhere و Google App Engine.

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

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

نکته منفی دیگر این است که برنامه شما ممکن است به یک پلتفرم گره بخورد یا پورت کردن آن دشوار شود. به عنوان مثال، Google App Engine فقط برای پشتیبانی از یک پایگاه داده غیررابطه ای استفاده می شود، به این معنی که شما باید از django-nonrel، یک فورکی(کپی) از جنگو، استفاده کنید. این محدودیت اکنون با Google Cloud SQL تا حدودی کاهش یافته است.

سرورهای مجازی اختصاصی

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

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

در مقایسه با PaaS، VPS ممکن است ارزش بیشتری دربرابر پول پرداختی داشته باشد، به خصوص برای سایت های پربازدید. ممکن است بتوانید چندین سایت از یک سرور را نیز اجرا کنید.

سرورلس

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

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

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

جنگو ممکن است به نظر در چنین محیطی کار نکند، اما Zappa استقرار برنامه های جنگو (در واقع، هر برنامه سازگار با WSGI) را بر روی یک پلتفرم بدون سرور مانند AWS Lambda با حداقل تغییرات آسان می کند. این امکان لذت بردن از تمام مزایای بدون سرور را در هنگام استفاده از جنگو باز می کند.

رویکردهای دیگر برای هاستینگ

اگرچه میزبانی بر روی یک پلتفرم یا VPS دو گزینه محبوب میزبانی هستند، گزینه های زیاد دیگری نیز وجود دارد. اگر به افزایش کارایی علاقه دارید، می توانید یک سرور فیزیکی (bare metal) با هماهنگی از ارائه دهندگان، مانند Rackspace انتخاب کنید.

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

داکر برای میزبانی برنامه های برپایه میکروسرویس ایده آل است. تقریباً هر ارائه دهنده PaaS و VPS از آنها پشتیبانی می کند و در همه جا در حال فراگیر شدن است.

همچنین یک پلتفرم توسعه عالی است زیرا کانتینرهای داکر کل حالت برنامه را در خود محصور می کنند و می توانند مستقیماً در تولید دیپلوی و مستقر شوند.

ابزارهای استقرار سازی و دیپلوی

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

کلید یک فرآیند استقرار موفق، اتوماسیون است. از آنجایی که استقرار برنامه ها شامل یک سری مراحل کاملاً تعریف شده است، می توان به درستی به عنوان یک مشکل برنامه نویسی به آن نگاه کرد. هنگامی که یک استقرار اتوماسیون شده دارید، از ترس از دست دادن یک مرحله، لازم نیست نگران استقرار باشید.

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

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

بیایید نگاهی به برخی از ابزارهای محبوب برای استقرار برنامه های جنگو بیندازیم.

Fabric

این مورد به دلیل سادگی و سهولت استفاده در بین توسعه دهندگان وب پایتون مورد علاقه است. فایلی به نام fabfile.py را در نظر دارد که تمام اقدامات (برای استقرار یا غیره) در پروژه شما را تعریف میکند. هر یک از این اقدامات می تواند یک shell command محلی یا راه دور باشد. میزبان راه دور از طریق SSH متصل می شود.

نقطه قوت اصلی Fabric توانایی آن در اجرای دستورات روی مجموعه ای از میزبان های راه دور است. به عنوان مثال، می توانید یک گروه وبرا تعریف کنید که شامل نام میزبان همه وب سرورهای در حال تولید است.

نکته: با تعیین نام گروه وب در خط فرمان، می‌توانید یک اکشن Fabric را فقط در برابر این سرورهای وب اجرا کنید. برای نشان دادن وظایف مربوط به استقرار یک سایت با استفاده از Fabric، اجازه دهید نگاهی به یک سناریوی استقرار معمولی بیندازیم.

گام های ساده برای استقرار

تصور کنید که یک برنامه وب با اندازه متوسط دارید که بر روی یک وب سرور واحد مستقر شده است. Git به عنوان ابزار کنترل نسخه و همکاری انتخاب شده است. یک مخزن مرکزی که با همه کاربران به اشتراک گذاشته شده است به شکل درخت Git برهنه ایجاد شده است.

فرض کنید سرور تولید شما به طور کامل راه اندازی شده است. هنگامی که فرمان استقرار Fabric خود را اجرا می کنید، مثلاً fab deploy، دنباله اسکریپت زیر از اقدامات انجام می شود:

1. تمام تست ها را به صورت محلی اجرا می کند
2. تمام تغییرات محلی Git را انجام می دهد
3. به یک مخزن مرکزی راه دور Git فشار می آورد
4. در صورت وجود، تضادهای ادغام را حل می کند
5. فایل های ثابت (CSS، تصاویر) را جمع آوری می کند.
6. فایل های استاتیک را در سرور فایل استاتیک کپی می کند
7. در میزبان راه دور، تغییرات را از یک مخزن مرکزی Git می کشد
8. در میزبان راه دور، مهاجرت (پایگاه داده) را اجرا می کند
9. در میزبان راه دور، app.wsgi را برای راه اندازی مجدد سرور WSGI لمس کنید

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

مدیریت پیکره بندی ها

مدیریت چندین سرور در حالت های مختلف می تواند با Fabric سخت باشد. ابزارهای مدیریت پیکربندی مانند Chef، Puppet یا Ansible سعی می کنند یک سرور را به وضعیت مطلوبی برسانند.

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

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

یکی از مهمترین مزایای ابزارهای مدیریت پیکربندی این است که به طور پیش فرض فاقد قدرت هستند. سرورهای شما می توانند از یک حالت ناشناخته به یک وضعیت شناخته شده بروند و در نتیجه مدیریت پیکربندی سرور آسان تر و استقرار قابل اعتماد را به همراه داشته باشند.

در میان ابزارهای مدیریت پیکربندی، Chef و Puppet از محبوبیت زیادی برخوردار هستند زیرا یکی از اولین ابزارها در این دسته بودند. با این حال، ریشه آنها در Ruby می تواند آنها را برای برنامه نویس پایتون کمی ناآشنا نشان دهد. برای چنین افرادی، ما Salt و Ansible را به عنوان جایگزین های عالی داریم.

ابزارهای مدیریت پیکربندی در مقایسه با ابزارهای ساده تر، مانند Fabric، منحنی یادگیری قابل توجهی دارند. با این حال، آنها ابزار ضروری برای ایجاد محیط های تولید قابل اعتماد هستند و مطمئنا ارزش یادگیری را دارند.

مانیتورینگ

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

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

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

ابزارهای مانیتورینگ معمولاً به یک سرویس پشتیبان (گاهی اوقات به نام عوامل) برای جمع آوری آمار و سرویس ظاهری برای نمایش داشبوردها یا تولید گزارش نیاز دارند. پشتیبان های محبوب جمع آوری داده ها عبارتند از StatsD و Monit. این داده ها را می توان به ابزارهای frontend مانند Graphite منتقل کرد.

چندین ابزار مانیتورینگ میزبان مانند New Relic و Status.io وجود دارد که راه‌اندازی و استفاده از آنها آسان‌تر است.

اندازه گیری عملکرد یکی دیگر از نقش های مهم نظارت است. همانطور که به زودی در بخش بعدی خواهیم دید، هر بهینه سازی پیشنهادی باید قبل از اجرا به دقت اندازه گیری و نظارت شود.

بهبود کارایی

عملکرد یک ویژگی است. مطالعات نشان می‌دهد که سایت‌های کند چگونه تأثیر نامطلوبی بر کاربران و در نتیجه درآمد دارند. به عنوان مثال آزمایش هایی در آمازون در سال 2007 نشان داد که به ازای هر 100 میلی ثانیه افزایش زمان بارگذاری amazon.com فروش 1 درصد کاهش می یابد.

با اطمینان، چندین برنامه وب با کارایی بالا مانند Disqus و Instagram بر روی جنگو ساخته شده اند. در Disqus، در سال 2013، آنها می‌توانستند 1.5 میلیون کاربر متصل همزمان، 45000 اتصال جدید در ثانیه، 165000 پیام در ثانیه را با تأخیر سرتاسر کمتر از 0.2 ثانیه مدیریت کنند.

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

• "اگر نتوانید آن را اندازه گیری کنید، نمی توانید آن را بهبود ببخشید"

در بیشتر برنامه‌های کاربردی وب، گلوگاه‌ها احتمالاً در انتهای مرورگر یا پایگاه داده به جای جنگو هستند. با این حال، برای کاربر، کل برنامه باید پاسخگو باشد.

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

کارایی سمت فرانت

برنامه نویسان جنگو ممکن است عملکرد frontend را نادیده بگیرند زیرا با درک نحوه عملکرد سمت کلاینت، معمولاً یک مرورگر، سروکار دارد. با این حال، بیایید از مطالعه استیو سادرز در مورد 10 وب سایت برتر رتبه بندی الکسا نقل قول کنیم:

• "80 تا 90 درصد از زمان پاسخ‌دهی کاربر نهایی در قسمت فرانت صرف می‌شود. از آنجا شروع کنید."

یک نقطه شروع خوب برای بهینه سازی frontend این است که سایت خود را با سرعت صفحه گوگل یا یاهو بررسی کنید! YSlow (معمولاً به عنوان پلاگین مرورگر استفاده می شود). این ابزارها سایت شما را رتبه بندی می کنند و بهترین روش ها را توصیه می کنند، مانند به حداقل رساندن تعداد درخواست های HTTP یا gzip نمودن محتوا.

به عنوان بهترین روش، دارایی های استاتیک شما، مانند تصاویر، شیوه نامه ها و فایل های جاوا اسکریپت، نباید از طریق جنگو ارائه شوند. به جای یک فایل سرور استاتیک و ثابت، فضای ذخیره سازی ابری مانند آمازون S3 یا یک شبکه تحویل محتوا (CDN) باید برای عملکرد بهتر مورد استفاده قرار گیرد.

حتی در این صورت، جنگو می‌تواند به چندین روش به شما در بهبود عملکرد frontend کمک کند:

• کش بی نهایت با CachedStaticFilesStorage: سریع ترین راه برای بارگیری assets ایستا، استفاده از حافظه پنهان مرورگر است. با تنظیم زمان کش طولانی، می توانید از بارگیری مجدد همان دارایی دوباره و دوباره خودداری کنید. با این حال، چالش این است که بدانیم چه زمانی از حافظه پنهان هنگام تغییر محتوا استفاده نکنیم.
  • کلاس CachedStaticFilesStorage این مشکل را با افزودن هش MD5 asset به نام فایل حل می کند. به این ترتیب می توانید TTL کش را برای این فایل ها بی نهایت افزایش دهید.
  • برای استفاده از این، تنظیم CACHES با نام staticfiles را روی CachedStaticFilesStorage تنظیم کنید یا اگر فضای ذخیره سازی سفارشی دارید، از CachedFilesMixin ارث بری نمایید. همچنین، بهتر است کش های خود را به گونه ای پیکربندی کنید که از پشتیبان کش حافظه محلی برای انجام نام فایل استاتیک در جستجوی نام هش شده آن استفاده کند.
• از یک asset manager ایستا استفاده کنید: یک asset manager می تواند دارایی های استاتیک شما را از قبل پردازش کند تا آنها را کوچک کند، فشرده یا به هم متصل کند، در نتیجه اندازه آنها را کاهش داده و درخواست ها را به حداقل برساند. همچنین می‌تواند آنها را از قبل پردازش کند و به شما امکان می‌دهد آن‌ها را به زبان‌های دیگر بنویسید، مانند CoffeeScript و stylesheets از لحاظ نحوی عالی (Sass). چندین بسته جنگو وجود دارد که asset manager ثابت مانند django-pipeline یا websets را ارائه می دهد.

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

دامنه کارایی سمت Backend تمامی وب استک سمت سرور شما را شامل می شود، از جمله پرس و جوهای پایگاه داده، رندر قالب، ذخیره سازی و کارهایی که در پس زمینه انجام می شوند. ممکن است بالاترین عملکرد را از آنها استخراج کنید زیرا کاملاً در کنترل شما است.

برای نیازهای پروفایل سریع و آسان، django-debug-toolbar بسیار مفید است. همچنین می‌توانیم از ابزارهای پروفایل پایتون مانند ماژول hotshot برای تجزیه و تحلیل دقیق استفاده کنیم. در جنگو، می توانید از یکی از چندین قطعه میان افزار پروفایل برای نمایش خروجی هات شات در مرورگر استفاده کنید.

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

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

تمپلیت ها

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

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

دیتابیس

گاهی اوقات، Django ORM می تواند کد SQL ناکارآمد تولید کند. چندین الگوی بهینه سازی برای بهبود این امر وجود دارد که به شرح زیر است:

• کاهش بازدیدهای پایگاه داده با select_related: اگر از یک رابطه یک به یک یا یک کلید خارجی، در جهت فوروارد، برای تعداد زیادی از اشیاء استفاده می کنید، select_related() می تواند یک جوین را انجام دهد و تعداد بازدیدهای پایگاه داده را کاهش دهد.
• کاهش بازدید پایگاه داده با prefetch_related: برای دسترسی به متد ManyToManyField یا یک رابطه کلید خارجی در جهت معکوس، یا یک رابطه کلید خارجی در تعداد زیادی از اشیاء، استفاده از prefetch_related را برای کاهش تعداد بازدیدهای پایگاه داده در نظر بگیرید.
• واکشی فیلدهای مورد نیاز با ولیوها یا values_list: می‌توانید با محدود کردن کوئری‌ها برای بازگشت فیلدهای مورد نیاز و چشم پوشی کردن از نمونه‌سازی مدل با استفاده از values() یا values_list در زمان و استفاده از حافظه صرفه‌جویی کنید.
• مدل‌های دینرمال شده: denormalization انتخابی، کارایی را از طریق کاهش جوین ها برای افزایش سازگاری داده‌ها بهبود می‌بخشد. همچنین می توان از آن برای پیش محاسبه مقادیر، مانند مجموع فیلدها یا گزارش وضعیت فعال در یک ستون اضافی استفاده کرد. در مقایسه با استفاده از مقادیر مشروح در پرس و جوها، فیلدهای غیرعادی شده اغلب ساده تر و سریعتر هستند.
• یک شاخص اضافه کنید: اگر یک کلید غیر اصلی در جستارهای شما زیاد جستجو می شود، db_index آن فیلد را در تعریف مدل خود روی True قرار دهید.
• ایجاد، به روز رسانی و حذف چندین ردیف به طور همزمان: چندین شی را می توان در یک کوئری پایگاه داده واحد با متدهای bulk_create()، update() و delete() اجرا کرد. با این حال، آنها با چندین اخطار مهم مانند چشم پوشی از متد save() در آن مدل همراه هستند. بنابراین، قبل از استفاده از آنها، اسناد را به دقت بخوانید.

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

ذخیره سازی

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

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

اکثر سیستم های تولیدی از یک سیستم کش مبتنی بر حافظه مانند Redis یا Memcached استفاده می کنند. این صرفاً به این دلیل است که حافظه فرار بسیار سریعتر از ذخیره سازی مبتنی بر دیسک است.

چنین حافظه های کش برای ذخیره سازی داده های پرکاربرد اما زودگذر، مانند جلسات کاربر، ایده آل هستند..

بکند سشن ذخیره شده

به طور پیش فرض، جنگو یوزر سشن خود را در پایگاه داده ذخیره می کند. این معمولاً برای هر درخواست بازیابی می شود. برای بهبود عملکرد، داده های سشن را می توان با تغییر تنظیمات SESSION_ENGINE در حافظه ذخیره کرد. به عنوان مثال، موارد زیر را در settings.py اضافه کنید تا داده‌های جلسه را در حافظه پنهان خود ذخیره کنید:

• SESSION_ENGINE = "django.contrib.sessions.backends.cache"

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

فریم ورک های ذخیره سازی

برای استراتژی های ذخیره سازی اولیه، ممکن است استفاده از فریم ورک ذخیره سازی آسان تر باشد. از جمله محبوب ترین ها می توان به django-cache-machine و django-cachalot اشاره کرد. آنها می توانند سناریوهای رایج را مدیریت کنند، مانند ذخیره خودکار نتایج جستجوها برای جلوگیری از بازدید از پایگاه داده هر بار که خواندن انجام می دهید. ساده ترین آنها جنگو-کاچالوت، جانشین Johnny Cache است. به پیکربندی بسیار کمی نیاز دارد. این برای سایت‌هایی که دارای چندین خواندن و نوشتن نادر هستند (یعنی اکثریت قریب به اتفاق برنامه‌ها) ایده‌آل است، تمام پرس‌و‌جوهای خوانده‌شده جنگو ORM را به شیوه‌ای ثابت ذخیره می‌کند.

الگوهای ذخیره سازی

هنگامی که سایت شما شروع به دریافت ترافیک سنگین نمود، باید شروع به کاوش چندین استراتژی ذخیره سازی در سراسر پشته خود کنید. با استفاده از Varnish، یک سرور کش که بین کاربران شما و جنگو قرار می گیرد، بسیاری از درخواست های شما ممکن است حتی به سرور جنگو هم نرسند.

وارنیش می تواند باعث شود صفحات بسیار سریع بارگذاری شوند (گاهی اوقات صدها برابر سریعتر از حالت عادی). با این حال، در صورت استفاده نادرست، ممکن است صفحات ایستا را به کاربران شما ارائه دهد. Varnish را می توان به راحتی برای تشخیص صفحات پویا یا بخش های پویا از یک صفحه مانند سبد خرید پیکربندی کرد.

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

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

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

اساساً، یک استراتژی ذخیره سازی موفق، بخش های استاتیک و پویا یک سایت را شناسایی می کند. برای بسیاری از سایت‌ها، بخش‌های پویا، داده‌های خاص کاربر هستند زمانی که وارد سیستم میشوید.

ذخیره سازی نهان را به عنوان بخش جدایی ناپذیر عملکرد سایت خود تلقی نکنید. حتی اگر سیستم کش خراب شود، سایت باید به حالت کندتر اما کارآمد برگردد.

Cranos:

    It was six in the morning and the SHIM building was surrounded by a
    grey fog. Somewhere inside, a small conference room had been designated
    the war room. For the last three hours, the SuperBook team had been
    holed up here diligently executing their pre-go-live plan.

    More than 30 users had logged on the IRC chatroom #superbookgolive
    from various parts of the world. The chat log was projected on a giant
    whiteboard. When the last item was struck off, Evan glanced at Steve.
    Then, he pressed a key triggering the deployment process.
    
    The room fell silent as the script output kept scrolling off the wall. One
    error, Steve thought, just one error can potentially set them back by hours.
    Several seconds later, the command prompt reappeared. It was live! The
    team erupted in joy. Leaping from their chairs they gave high-fives to
    each other. Some were crying tears of happiness. After weeks of
    uncertainty and hard work, it all seemed surreal.

    However, the celebrations were short-lived. A loud explosion from above
    shook the entire building. Steve knew the second breach had begun. He
    shouted to Evan, "don't turn on the beacon until you get my message",
    and sprinted out of the room.
    
    As Steve hurried up the stairway to the rooftop, he heard the sound of
    footsteps above him. It was Madam O. She opened the door and flung
    herself in. He could hear her screaming "no!" and a deafening blast shortly
    after that.
    
    By the time he reached the rooftop, he saw Madam O sitting with her back
    against the wall. She was clutching her left arm and wincing in pain. Steve
    slowly peered around the wall. At a distance, a tall bald man seemed to be
    working on something with the help of two robots.
    
    "He looks like...." Steve broke off, unsure of himself.
    
    "Yes, it is Hart. Rather I should say he is Cranos now."
    
    "What?"
    
    "Yes, a split personality. A monster that laid hidden in Hart's mind for
    years. I tried to help him control it. Many years back, I thought I had
    stopped it from ever coming back. However, all this stress took a toll on
    him. Poor thing, if only I could get near him."
    
    Poor thing indeed, he nearly tried to kill her. Steve took out his mobile
    and sent out a message to turn on the beacon. He had to improvise.
    
    With his hands high in the air and fingers crossed, he stepped out. The
    two robots immediately aimed directly at him. Cranos motioned them to
    stop.

    "Well, who do we have here? Mr. SuperBook himself. Did I crash into
    your launch party, Steve?"
    
    "It was our launch, Hart."
    
    "Don't call me that", growled Cranos. "That guy was a fool. He wrote the
    Sentinel code but he never understood its potential. I mean, just look at
    what Sentinels can do, unravel every cryptographic algorithm known to
    man. What happens when it enters an intergalactic network?"
    
    The hint was not lost on Steve. "SuperBook?" he asked slowly.
    
    Cranos let out a malicious grin. Behind him, the robots were busy wiring
    into SHIM's core network. "While your SuperBook users will be busy
    playing SuperVille, the tentacles of Sentinel will spread into new
    unsuspecting worlds. Critical systems of every intelligent species will be
    sabotaged. The Supers will have to bow to a new intergalactic supervillain
    Cranos."
    
    As Cranos was delivering this extended monologue, Steve noticed a
    movement of the corner of his eye. It was Acorn, the super-intelligent
    squirrel, scurrying along the right edge of the rooftop. He also spotted
    Hexa hovering strategically on the other side. He nodded at them.
    
    Hexa levitated a garbage bin and flung it towards the robots. Acorn
    distracted them with high-pitched whistles. "Kill them all!" Cranos said
    irritably. As he turned to watch his intruders, Steve fished out his phone,
    dialed into FaceTime and held it towards Cranos.
    
    "Say hello to your old friend, Cranos," said Steve.
    
    Cranos turned to face the phone and the screen revealed Madam O's face.
    With a smile, she muttered under her breath, "Taradiddle Bumfuzzle!"
    
    The expression on Cranos's face changed instantly. The seething anger
    disappeared. He now looked like a man they had once known.
    
    "What happened?" asked Hart confused.
    
    "We thought we had lost you," said Madam O over the phone. "I had to
    use hypnotic trigger words to bring you back."
    
    Hart took a moment to survey the scene around him. Then, he slowly
    smiled and nodded at her.
    
    ----------------------------------------------------
    
    One Year Later
    
    Who would have guessed Acorn would turn into an intergalactic singing
    sensation in less than a year? His latest album Acorn Unplugged debuted
    at the top of Billboard's Top 20 chart. He threw a grand party in his new
    white mansion overlooking a lake.
    
    The guest list included superheroes, pop stars, actors, and celebrities of all
    sorts.
    
    "So, there was a singer in you after all," said Captain Obvious holding a
    martini.
    
    "I guess there was," replied Acorn. He looked dazzling in a golden tuxedo
    with all sorts of bling-bling.
    
    Steve appeared with Hexa in tow, who looked ravishing in a flowing
    silver gown.
    
    "Hey Steve, Hexa. It has been a while. Is SuperBook still keeping you late
    at work, Steve?"
    
    "Not so much these days. Knock on wood," replied Hexa with a smile.
    
    "Ah, you guys did a fantastic job. I owe a lot to SuperBook. My first single,
    'Warning: Contains Nuts', was a huge hit in the Tucana galaxy. They
    watched the video on SuperBook more than a billion times!"
    
    "I am sure every other superhero has a good thing to say about SuperBook
    too. Take Blitz. His AskMeAnything interview won back the hearts of his
    fans. They were thinking that he was on experimental drugs all this time.
    It was only when he revealed that his father was Hurricane that his
    powers made sense."
    
    "By the way, how is Hart doing these days?"
    
    "Much better," said Steve. "He got professional help. The sentinels were
    handed back to S.H.I.M. They are developing a new quantum
    cryptographic algorithm that will be much more secure."
    
    "So, I guess we are safe until the next supervillain shows up," said Captain
    Obvious hesitantly.
    
    "Hey, at least the beacon works," said Steve, and the crowd burst into
    laughter.

خلاصه

در این فصل آخر، ما به رویکردهای مختلف برای پایدار، قابل اعتماد و سریع کردن برنامه جنگو شما نگاه کردیم. به عبارت دیگر، آن را آماده تولید کنیم. اگرچه مدیریت سیستم ممکن است به خودی خود یک رشته کامل باشد، دانش منصفانه از وب استک ضروری است. چندین گزینه میزبانی از جمله PaaS، VPS و Serverless را بررسی کردیم.

همچنین چندین ابزار استقرار خودکار و یک سناریوی استقرار معمولی را بررسی کردیم. در نهایت، چندین تکنیک را برای بهبود عملکرد frontend و backend پوشش دادیم.

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