نحوه شناسایی و حل مشکلات مقیاس وب

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

داشتن برخی مشکلات خوب است… اما همچنان مشکل هستند. شرکتی که مشکلات مقیاس وب دارد احتمالاً در حال رشد و نوآوری است – اما با سرعتی چنان سریع که زیرساخت فعلی نمی تواند ادامه یابد. چالش این است که شرکت‌ها همیشه نمی‌دانند که حتی یک مشکل در مقیاس وب دارند.

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

هشدارهای اولیه

ما یکی از اولین منادی نگرانی‌های مقیاس وب را در همه جا، صنعت کارت تبریک دیدیم. برای تقریباً ۱۰۰ سال، شرکت‌های کارت تبریک در ایالات متحده، کارت‌هایی را تولید و عرضه می‌کردند که روی هدایا چسبانده می‌شد، از طریق پست ارسال می‌شد و روی یخچال‌ها چسبانده می‌شد. سپس، در اواسط دهه ۱۹۹۰، همه چیز تغییر کرد. این ظهور شبکه جهانی وب بود و همه می خواستند بخشی از آن باشند. در سال ۱۹۹۶، کوه آبی، سلام های آمریکایی و Hallmark< /a> همه سایت‌های دات‌کام را برای ارائه کارت‌های الکترونیکی راه‌اندازی کردند—و نبرد دیجیتالی درگرفت.

درس کسب و کار که ما به سرعت آموختیم این بود که زیرساخت وب می تواند مزیتی در افزایش درآمد باشد.

طلوع نگرانی های مقیاس وب

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

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

مشکلات مقیاس وب به جریان اصلی تبدیل می شوند

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

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

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

آیا به هر یک از این سؤالات بله گفتید؟ آیا فکر می‌کنید در طی سه تا پنج سال آینده به هر یک از این سؤالات  بله می‌گویید؟

حل مشکلات در مقیاس وب به زیبایی

بازگشت به American Greetings (و سالها پس از آن در جاهای دیگر)، من مشکلات مقیاس وب را با نرم افزار معادل بند کفش و آدامس حل کردم. در آن زمان، تیم ما از ترکیبی از راه حل های منبع باز و محلی برای مدیریت یکی از بزرگترین وب سایت های اینترنت استفاده کرد. با استفاده از ابزارهایی مانند لینوکس، آپاچی، و یک ماکت CFEngine —بله، یک ماکت—ما توانستیم بیش از ۱۰۰۰ مورد را مدیریت کنیم. سرورها و ۷۰ برنامه با تقریباً سه نفر (چیزی که امروزه بیشتر مهندسین قابلیت اطمینان سایت می نامند).

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

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

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

نیاز به Kubernetes

در زمان ساخت، Kubernetes و کانتینرها یک روش استاندارد را برای ساخت برنامه‌ها فعال می‌کنند. همه می توانند از این طریق یاد بگیرند: از Dockerfiles/Containerfiles استفاده کنید و آنها را در Git commit کنید. این زبان استاندارد شده برای مدیریت ساخت، بار شناختی را ساده می‌کند و دانشی را که SREs دارند برای سایر سیستم‌های درون سازمان شما و سایر سازمان‌ها قابل حمل می‌سازد (به کارگیری افراد جدید آسان‌تر می‌شود). همچنین آزمایش برنامه‌ها قبل از تولید آنها را بسیار آسان‌تر می‌کند.

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

تئوری من این است که افرادی که می گویند به Kubernetes نیاز ندارند، متوجه نمی شوند که مشکلاتی در مقیاس وب دارند. (و، به احتمال زیاد این کار را انجام دهند.)

پروژه Kubernetes، در ترکیب با بسیاری از ابزارهای منبع باز طراحی شده برای تکمیل آن، سازمان ها را قادر می سازد تا به طور موثر نیازهای مقیاس وب را برآورده کنند. توجه داشته باشید که نگفتم “به راحتی ملاقات کنید.” من قصد ندارم وانمود کنم که کوبرنتس آسانسوری است، زیرا اینطور نیست. اما، به یاد داشته باشید، مشکلات مقیاس وب آسان نیستند، و تقریباً همه امروزه یک (یا بیشتر) دارند. Kubernetes دارای قابلیت‌هایی است که من هرگز نمی‌توانستم تصورش را بکنم وقتی دیوانه می‌شدم و سعی می‌کردم روز ولنتاین را از شکستن قلب فن‌آوری شرکتم جلوگیری کنم.

در Red Hat، اسکات مک کارتی مدیر ارشد محصول برای سرور RHEL است، احتمالا بزرگترین تجارت نرم افزار منبع باز در جهان مناطق تمرکز شامل ابر، کانتینرها، گسترش حجم کاری و اتوماسیون است. اسکات با همکاری نزدیک با مشتریان، شرکا، تیم‌های مهندسی، فروش، بازاریابی، سایر تیم‌های محصول و حتی در جامعه، تجربه شخصی را با بازخورد مشتری و شریک ترکیب می‌کند تا قابلیت‌های استراتژیک را در Red Hat Enterprise Linux بهبود بخشد و تطبیق دهد. /p>