Captain Obvious به ما می گوید که در تابستان، هم فعالیت خرید و هم شدت تغییرات در زیرساخت پروژه های وب به طور سنتی کاهش می یابد. صرفاً به این دلیل که حتی متخصصان فناوری اطلاعات گاهی اوقات به تعطیلات می روند. و CTO نیز. برای کسانی که در سمت خود باقی می مانند، دشوارتر است، اما اکنون موضوع این نیست: شاید به همین دلیل است که تابستان بهترین دوره برای فکر کردن به برنامه رزرو موجود و ترسیم برنامه ای برای بهبود آن است. و تجربه یگور آندریف از که وی در این کنفرانس در مورد آن صحبت کرد .
چندین دام وجود دارد که می توانید هنگام ساختن سایت های پشتیبان به آنها بیفتید. و کاملاً غیرممکن است که در آنها گرفتار شوید. و چیزی که ما را در این همه خراب می کند، مثل خیلی چیزهای دیگر، کمال گرایی و... تنبلی است. ما سعی می کنیم همه چیز، همه چیز، همه چیز را عالی انجام دهیم، اما نیازی نیست که آن را به طور کامل انجام دهیم! شما فقط باید کارهای خاصی را انجام دهید، اما آنها را به درستی انجام دهید، آنها را کامل کنید تا به درستی کار کنند.
Failover نوعی سرگرمی و سرگرمی نیست. این چیزی است که باید دقیقاً یک کار را انجام دهد - کاهش زمان خرابی به طوری که خدمات، شرکت، پول کمتری را از دست بدهد. و در تمام روش های رزرو پیشنهاد می کنم در زمینه زیر فکر کنید: پول کجاست؟
تله اول: هنگامی که ما سیستم های بزرگ و قابل اعتماد می سازیم و درگیر افزونگی می شویم، تعداد تصادفات را کاهش می دهیم. این یک تصور اشتباه وحشتناک است. زمانی که ما درگیر کار مازاد هستیم، احتمالاً تعداد تصادفات را افزایش خواهیم داد. و اگر همه چیز را به درستی انجام دهیم، در مجموع زمان خرابی را کاهش خواهیم داد. تصادفات بیشتر خواهد بود، اما با هزینه کمتر اتفاق می افتد. رزرو چیست؟ - این یک عارضه سیستم است. هر عارضه ای بد است: ما چرخ دنده های بیشتر، چرخ دنده های بیشتر، در یک کلام، عناصر بیشتری داریم - و بنابراین، احتمال خرابی بالاتری داریم. و آنها واقعاً خواهند شکست. و آنها اغلب شکسته خواهند شد. یک مثال ساده: فرض کنید یک وب سایت با PHP و MySQL داریم. و نیاز فوری به رزرو دارد.
Shtosh (ج) سایت دوم را می گیریم، یک سیستم یکسان می سازیم... پیچیدگی دو برابر می شود - ما دو موجودیت داریم. ما همچنین منطق خاصی را برای انتقال داده ها از یک سایت به سایت دیگر ایجاد می کنیم - یعنی تکرار داده ها، کپی کردن داده های ثابت و غیره. بنابراین، منطق تکرار معمولا بسیار پیچیده است، و بنابراین، پیچیدگی کل سیستم می تواند نه 2، بلکه 3، 5، 10 برابر بیشتر باشد.
تله دوم: وقتی سیستم های پیچیده واقعا بزرگی می سازیم، در مورد آنچه می خواهیم در پایان به دست آوریم خیال پردازی می کنیم. Voila: ما می‌خواهیم یک سیستم فوق‌العاده قابل اعتماد داشته باشیم که بدون هیچ گونه خرابی کار کند، در نیم ثانیه (یا بهتر است بگویم، فورا) سوئیچ کند و شروع به تحقق رویاها کنیم. اما یک نکته ظریف نیز در اینجا وجود دارد: هرچه زمان سوئیچینگ مورد نظر کوتاهتر باشد، منطق سیستم پیچیده تر می شود. هرچه این منطق را پیچیده‌تر کنیم، سیستم بیشتر خراب می‌شود. و ممکن است در یک موقعیت بسیار ناخوشایند قرار بگیرید: ما با تمام توان خود تلاش می کنیم تا زمان خرابی را کاهش دهیم، اما در واقع همه چیز را پیچیده تر می کنیم و زمانی که مشکلی پیش بیاید، زمان از کار افتادگی در نهایت طولانی تر می شود. در اینجا اغلب خود را درگیر این فکر می‌کنید: خوب... بهتر است رزرو نکنید. اگر به تنهایی و با خرابی قابل درک کار می کرد بهتر بود.
چگونه می توانید با این مبارزه کنید؟ ما باید از دروغ گفتن به خودمان دست برداریم، از تملق گفتن به خودمان که می‌خواهیم یک سفینه فضایی در اینجا بسازیم، دست برداریم، اما به اندازه کافی درک کنیم که این پروژه چقدر می‌تواند دروغ باشد. و برای این حداکثر زمان، ما انتخاب خواهیم کرد که واقعاً از چه روش هایی برای افزایش قابلیت اطمینان سیستم خود استفاده کنیم.
زمان "داستان هایی از w" است ... البته از زندگی.
مثال شماره یک
یک وب سایت کارت ویزیت کارخانه نورد لوله شماره 1 در شهر N را تصور کنید که با حروف بزرگ نوشته شده است - PIP ROLLING PLANT شماره 1. درست در زیر این شعار وجود دارد: "لوله های ما گردترین لوله ها در N هستند." و در زیر شماره تلفن مدیر عامل و نام وی آمده است. ما درک می کنیم که شما باید رزرو کنید - این یک چیز بسیار مهم است! بیایید شروع کنیم تا بفهمیم از چه چیزی تشکیل شده است. Html-statics - یعنی چند تصویر که در آن مدیر کل در واقع در حال بحث در مورد نوعی معامله بعدی روی میز در حمام با شریک زندگی خود است. ما شروع به فکر کردن در مورد تعطیلات می کنیم. این به ذهن خطور می کند: شما باید پنج دقیقه در آنجا دراز بکشید، نه بیشتر. و بعد این سوال پیش می آید که به طور کلی از این سایت ما چقدر فروش داشت؟ چقدر-چقدر؟ "صفر" به چه معناست؟ و این یعنی: چون ژنرال هر چهار معامله را پارسال بر سر یک سفره انجام داد، با همان افرادی که با آنها به غسالخانه رفتند و سر سفره نشستند. و ما درک می کنیم که حتی اگر سایت برای یک روز بنشیند، هیچ چیز وحشتناکی اتفاق نخواهد افتاد.
بر اساس اطلاعات مقدماتی، یک روز برای مطرح کردن این داستان وجود دارد. بیایید شروع به فکر کردن در مورد یک طرح اضافه کاری کنیم. و ایده آل ترین طرح افزونگی را برای این مثال انتخاب می کنیم: ما از افزونگی استفاده نمی کنیم. این را هر ادمینی می تواند در نیم ساعت با دود بریک مطرح کند. یک وب سرور نصب کنید، فایل ها را اضافه کنید - همین. کار خواهد کرد. نیازی نیست به چیزی توجه داشته باشید، نیازی نیست به چیزی توجه خاصی داشته باشید. یعنی نتیجه مثال شماره یک کاملاً واضح است: خدماتی که نیازی به رزرو ندارند نیازی به رزرو ندارند.
مثال شماره دو
وبلاگ شرکت: افراد آموزش دیده خاص در آنجا اخبار می نویسند، ما در فلان نمایشگاه شرکت کردیم، اما یک محصول جدید دیگر منتشر کردیم و غیره. فرض کنید این PHP استاندارد با وردپرس است، یک پایگاه داده کوچک و کمی ثابت است. البته، دوباره به ذهن می رسد که به هیچ وجه نباید دراز بکشید - "بیش از پنج دقیقه!" همین. اما بیایید بیشتر فکر کنیم. این وبلاگ چه کار می کند؟ افراد از Yandex، از Google بر اساس برخی پرس و جوها، به صورت ارگانیک به آنجا می آیند. عالی. آیا فروش ربطی به آن دارد؟ Epiphany: نه واقعا. ترافیک تبلیغات به سایت اصلی می رود که روی دستگاه دیگری است. بیایید شروع کنیم به یک طرح رزرو فکر کنیم. در یک راه خوب، باید ظرف چند ساعت بالا بیاید، و خوب است که برای این کار آماده شوید. منطقی است که یک ماشین را از یک مرکز داده دیگر بگیرید، محیط را روی آن بچرخانید، یعنی یک وب سرور، PHP، WordPress، MySQL، و آن را در آنجا رها کنید. در لحظه ای که متوجه شدیم همه چیز خراب است، باید دو کار انجام دهیم - تخلیه mysql را 50 متر بیرون بیاوریم، در عرض یک دقیقه به آنجا پرواز می کند و تعداد معینی از عکس ها را از پشتیبان در آنجا پخش می کند. این نیز وجود ندارد تا خدا می داند تا کی. بنابراین، در نیم ساعت همه چیز افزایش می یابد. بدون تکرار، یا خدا مرا ببخش، failover خودکار. نتیجه گیری: چیزی که می توانیم به سرعت از یک نسخه پشتیبان تهیه کنیم نیازی به پشتیبان گیری ندارد.
مثال شماره سه، پیچیده تر
فروشگاه آنلاین. PhP با قلب باز کمی بهینه شده است، mysql با پایه محکم. استاتیک بسیار زیاد (به هر حال، فروشگاه آنلاین دارای تصاویر HD زیبا و همه چیز است)، Redis برای جلسه و Elasticsearch برای جستجو. ما شروع به فکر کردن در مورد زمان استراحت می کنیم. و در اینجا، البته، بدیهی است که یک فروشگاه آنلاین نمی تواند یک روز بدون دردسر دراز بکشد. از این گذشته، هر چه مدت طولانی‌تر باشد، پول بیشتری از دست می‌دهیم. ارزش افزایش سرعت را دارد. چقدر؟ فکر می کنم اگر یک ساعت دراز بکشیم هیچکس دیوانه نمی شود. بله، ما چیزی را از دست خواهیم داد، اما اگر سخت کار کنیم، فقط بدتر می شود. ما طرحی از زمان توقف مجاز در هر ساعت تعریف می کنیم.
چگونه می توان این همه را رزرو کرد؟ در هر صورت به ماشین نیاز دارید: یک ساعت زمان بسیار کم است. Mysql: در اینجا ما قبلاً به replication نیاز داریم ، replication زنده ، زیرا در عرض یک ساعت 100 گیگابایت به احتمال زیاد به dump اضافه نخواهد شد. استاتیک، تصاویر: دوباره، در عرض یک ساعت، 500 گیگابایت ممکن است زمان اضافه شدن نداشته باشد. بنابراین، بهتر است بلافاصله تصاویر را کپی کنید. ردیس: اینجاست که همه چیز جالب می شود. در Redis، جلسات ذخیره می‌شوند - ما نمی‌توانیم آن را بگیریم و دفن کنیم. زیرا این خیلی خوب نخواهد بود: همه کاربران از سیستم خارج می شوند، سبدهای آنها خالی می شود و غیره. افراد مجبور می شوند نام کاربری و رمز عبور خود را دوباره وارد کنند و بسیاری از افراد ممکن است از خرید خارج شوند و خرید را تکمیل نکنند. دوباره، تبدیل کاهش خواهد یافت. از سوی دیگر، Redis مستقیماً به‌روز است و احتمالاً به آخرین کاربرانی که وارد سیستم شده‌اند نیز نیازی ندارند. و یک مصالحه خوب این است که Redis را بگیرید و آن را از یک نسخه پشتیبان از دیروز بازیابی کنید، یا اگر این کار را هر ساعت انجام می دهید، از یک ساعت قبل بازیابی کنید. خوشبختانه، بازیابی آن از یک نسخه پشتیبان به معنای کپی کردن یک فایل است. و جالب ترین داستان Elasticsearch است. چه کسی تا به حال تکرار MySQL را انتخاب کرده است؟ چه کسی تا به حال تکرار Elasticsearch را انتخاب کرده است؟ و پس از آن برای چه کسانی به طور معمول کار کرد؟ منظور من این است که ما موجودیت خاصی را در سیستم خود می بینیم. به نظر می رسد مفید باشد - اما پیچیده است.
پیچیده به این معنا که مهندسان همکار ما تجربه کار با آن را ندارند. یا تجربه منفی وجود دارد. یا می‌دانیم که این هنوز یک فناوری نسبتاً جدید با تفاوت‌های ظریف یا خام است. ما فکر می کنیم ... لعنتی، الاستیک هم سالم است، بازیابی آن از پشتیبان هم خیلی طول می کشد، چه کار کنم؟ ما درک می کنیم که الاستیک در مورد ما برای جستجو استفاده می شود. فروشگاه اینترنتی ما چگونه به فروش می رسد؟ به بازاریاب ها می رویم و می پرسیم مردم از کجا آمده اند. آنها پاسخ می دهند: "90٪ از بازار Yandex مستقیماً به کارت محصول می آید." و یا آن را می خرند یا نمی خرند. بنابراین جستجو توسط 10 درصد از کاربران مورد نیاز است. و حفظ تکثیر الاستیک، به ویژه بین مراکز داده مختلف در مناطق مختلف، واقعاً تفاوت های ظریف زیادی دارد. کدام خروجی؟ ما الاستیک را از یک سایت رزرو شده می گیریم و هیچ کاری با آن انجام نمی دهیم. اگر موضوع طولانی شود، احتمالاً روزی آن را مطرح خواهیم کرد، اما این قطعی نیست. در واقع، نتیجه یکسان است، مثبت یا منفی: ما، دوباره، خدماتی را که بر پول تأثیر نمی گذارد، رزرو نمی کنیم. برای اینکه نمودار ساده تر باشد.
مثال شماره چهار، حتی دشوارتر
ادغام کننده: فروش گل، تماس با تاکسی، فروش کالا، به طور کلی، هر چیزی. یک چیز جدی که 24/7 برای تعداد زیادی از کاربران کار می کند. با یک پشته جالب تمام عیار، که در آن پایه های جالب، راه حل ها، بار بالا وجود دارد و مهمتر از همه، بیش از 5 دقیقه دراز کشیدن دردناک است. نه تنها و نه به این دلیل که مردم نمی‌خرند، بلکه چون مردم می‌بینند که این چیزها کار نمی‌کند، ناراحت می‌شوند و ممکن است اصلاً برنگردند.
خوب. پنج دقیقه. قرار است در این مورد چه کنیم؟ در این مورد، ما مانند بزرگسالان، از تمام پول برای ساختن یک سایت پشتیبان واقعی، با تکرار همه چیز استفاده می کنیم و شاید حتی جابجایی به این سایت را تا حد امکان خودکار کنیم. و علاوه بر این، باید به یاد داشته باشید که یک کار مهم را انجام دهید: در واقع، مقررات سوئیچینگ را بنویسید. مقررات، حتی اگر همه چیز را خودکار کنید، می تواند بسیار ساده باشد. از سری "اجرای فلان اسکریپت قابل انجام"، "در مسیر 53 روی فلان باکس کلیک کنید" و غیره - اما این باید نوعی فهرست دقیق از اقدامات باشد.
و همه چیز روشن به نظر می رسد. تغییر تکثیر یک کار پیش پا افتاده است، وگرنه خود به خود تغییر می کند. بازنویسی نام دامنه در DNS از همین سری است. مشکل اینجاست که وقتی چنین پروژه‌ای با شکست مواجه می‌شود، وحشت شروع می‌شود و حتی قوی‌ترین ادمین‌های ریش‌دار نیز می‌توانند مستعد آن باشند. بدون دستورالعمل‌های واضح «ترمینال را باز کنید، بیایید اینجا، آدرس سرور ما هنوز اینگونه است»، رعایت محدودیت زمانی 5 دقیقه‌ای که برای احیا اختصاص داده شده است دشوار است. خوب، به علاوه، وقتی ما از این مقررات استفاده می کنیم، به راحتی می توان برخی تغییرات را در زیرساخت ثبت کرد و بر اساس آن مقررات را تغییر داد.
خوب، اگر سیستم رزرو بسیار پیچیده است و در نقطه ای اشتباه کردیم، می توانیم سایت پشتیبان خود را از بین ببریم و علاوه بر این، داده ها را در هر دو سایت به کدو تنبل تبدیل کنیم - این کاملاً ناراحت کننده خواهد بود.
مثال شماره پنج، هاردکور کامل
یک سرویس بین المللی با صدها میلیون کاربر در سراسر جهان. همه مناطق زمانی وجود دارد، بار بالا با حداکثر سرعت، شما اصلا نمی توانید دراز بکشید. یک دقیقه - و غم انگیز خواهد بود. چه باید کرد؟ دوباره طبق برنامه کامل رزرو کنید. ما هر کاری که در مثال قبلی در مورد آن صحبت کردم و کمی بیشتر انجام دادیم. یک دنیای ایده آل، و زیرساخت ما مطابق با تمام مفاهیم IaaC توسعه یافته است. یعنی همه چیز در git است و شما فقط دکمه را فشار دهید.
چه چیزی جا افتاده؟ یک - تمرینات. بدون آنها غیر ممکن است. به نظر می رسد که همه چیز با ما عالی است، ما به طور کلی همه چیز را تحت کنترل داریم. ما دکمه را فشار می دهیم، همه چیز اتفاق می افتد. حتی اگر اینطور باشد - و ما می‌دانیم که اینطور نیست - سیستم ما با برخی از سیستم‌های دیگر تعامل دارد. به عنوان مثال، این dns از مسیر 53، ذخیره سازی s3، ادغام با برخی از api است. ما نمی توانیم همه چیز را در این آزمایش گمانه زنی پیش بینی کنیم. و تا زمانی که سوئیچ را نکشیم، نمی دانیم که آیا کار می کند یا خیر.
احتمالاً همین است. تنبلی نکنید و زیاده روی نکنید. و ممکن است زمان کار با شما باشد!
منبع: www.habr.com