خب من داشتم سعی می‌کردم اولین مطلبم رو تو ویرگول بنویسم، بعد شروع به نوشتن دررابطه با چند موضوع کردم و دیدم همه اینا نیاز به یکسری دانش پیشین دارن که توضیحشون تو هر مطلب باعث می شد کلا از موضوع اصلی خارج بشم. پس گفتم چرا از همین مسائل ابتدایی شروع نکنم؟
این مطلب هم پارت اول از سری پارت های زیرساخت ابریه که من سعی میکنم تو هر قسمت یه توضیح جامع در حد دانش خودم در رابطه با مفاهیم زیرساخت ابری بدم.
من همیشه وقتی میخوام یک موضوعی رو توضیح بدم سعی میکنم اول نیازمندی به اون رو توضیح بدم که ممکنه مخاطبِ آشنا به موضوع قبلا بهش برخورد کرده باشه یا حداقل متوجهش میشه. اینجا هم همین رویکرد رو جلو میبرم.
خب تا قبل وجود زیرساخت های ابری یا کلا به وجود اومدن مفاهیم Self-Service مثل IaaS شما باید خیلی از مسائل زیرساختی رو از قبل واسشون برنامه ریزی می‌کردی و کلا یه آمادگی از معماری، محدودیت ها و کلی چیز دیگه میداشتی. البته الان هم همینه ولی با یکسری تفاوت عمده.
فرضا این سناریو رو در نظر بگیرید:
شما در شرکتی با پوزیشن DevOps کار می‌کنید که طبق اصول این شرکت کلا Bare Metal کار می‌کنن و فرض کنید نمیخوان به سمت هیچ سرویس دهنده خارجی دیگه ای برای برون سپاری سرویس هاشون روی بیارن. طبق برنامه هایی که امسال برای شرکت مطرح شده ما میخوایم زیرساخت رو بهبود بدیم. برای این موضوع اول باید ببینیم اصلا چه اتفاقاتی افتاده که همچین نیازی مطرح شده. خب اگر همه چی به خوبی کار می‌کنه و مشکلی نیست چرا باید اصلا به فکر بهبود باشیم؟ اینجاست که هم خود شما و هم باقی تیم های شرکت میان وسط و یکسری چالش که تو این مدت بهش برخورد کردن رو مطرح می‌کنن.
بزارید از خودمون که DevOps ای هستیم شروع کنیم. شما به عنوان یک DevOps ای تا الان احتمالا با چنین مشکلاتی روبرو شدید:
خب شما معمولا اپلیکیشن رو از توسعه دهنده می‌گرفتید و به هر شکلی که می‌خواستید روی یکی از سرورهای زیرساخت موجود می‌اوردید بالا. در همین مسیر برای بالا اوردن اپ باید با تیم نتوورک هماهنگ می‌شدید که دسترسی رو بهتون بدن و همچنین فایروال سیستم رو تنظیم کنن که امنیت تضمین بشه و همچنین با تیم Infra درگیر می‌شدید که منابع مورد نیاز رو در اختیارتون بزارن. در نهایت باید با هردوی این تیم ها همانگ می‌شدید که پیکربندی درست سرورهارو براتون انجام بدن تا در نهایت بتونید روی یدونه سرور اپلیکیشن رو بالا بیارید (و هزارتا کار دیگه که ذکر کردن همین ها به نظرم کافی بود). خب نیاز اولتون اینجاست که شما نمی‌تونید Self-Service کارتون رو جلو ببرید. نکته اول اینه که شما تا جلو نرید متوجه این موضوع نمی‌شید که چه نیازمندی هایی رو دقیق دارید که بخواید همه اون هارو لیست کنید و در اختیار یک تیم دیگه بزارید. خیلی وقت ها هم، باید یک کاری رو با یک تیم اولی هماهنگ کنید و باز برید سراغ تیم دوم و باز برای ادامه کار برگردید سراغ تیم اول. به طور ساده بخوام بگم، تصمیمات و اعمال شما بسیار وابسته به هماهنگی های بیش از حد با تیم های دیگه است.
بعد از یک مدتی شما می‌بینید که دارید به ازای هر اپلیکیشنی یک سرور بزرگ Bare Metal رو در اختیار اپلیکیشن می‌زارید. با Monitor کردن در طول زمان کم‌کم متوجه می‌شید که یکسری از اپلیکیشن ها روی سروری که بهشون اختصاص داده میشه تنها ۱ درصد از تمام منابع موجود اون سرور رو استفاده می‌کنن در حالی که چندین بار شده خیلی از اپلیکیشن های دیگه به خاطر کمبود منابع توی سرور خودشون پایین اومدن و یا عملکرد ایده‌آل رو نداشتن. خب با نیازمندی بعدیتون روبرو شدید. تخصیص درست و موزون (وزن دار) منابع.
خیلی وقتا شده شما اومدید و یک اپلیکیشن رو بالا اوردی ولی خیلی اتفاقی یک مشکل فنی/سخت‌افزاری برای سروری که اپ روش هست رخ میده که شما باید شروع کنید به جا‌به‌جایی یا مهاجرت (Migration). خب اگر رویکردی که برای پیاده سازی اولیه اپ که بالاتر بهتون توضیح دادم رو مدنظر بگیرید می‌بینید که برای بالا اوردن اولیه چقدر نیاز به زمان و هماهنگی وجود داشت. حالا که ساعت ۲ شب فرضا اپلیکیشن پایین اومده میخواید چیکار کنید؟ پس یا اپلیکیشن تا فردا و برای چند روز پایین می‌مونه که بالاخره یه جا‌به‌جایی صورت بگیره یا باید همین الان مشکل سخت افزاری رو حل کنید که خیلی وقتا نیاز به کار فیزیکی داره که اونم خیلی سریع امکان رخ دادنش نیست. از طرفی اصلا این رو مدنظر بگیرید که اپلیکیشن روی اون سرور Stateful بوده. مثل یک دیتابیس و به راحتی وقتی سرور در دسترس نیست نمیشه منتقلش کرد و حتما باید روی همون سرور بیاد بالا (یا اینکه رویکرد های سخت‌تری رو پیش بگیرید، مثلا از Backup و Restore به شکل دستی که درصد خطای بالایی دارن استفاده کنید). اینجاست که می‌گن زیرساخت پیاده سازی شما High Available نیست و دسترسی پذیری بالایی نداره. گویا که باید از قبل با مشتریاتون هماهنگ بشید که ممکنه و محتمل هست که یک‌زمانی واقعا چندروزی سرویس دهی نداشته باشید که این یکی از عوامل موثر تمایز شما با رقیباتونه. احتمالا خیلیاتون اتفاقی که برای شرکت Meta در October سال 2021 افتاد و سرویس های این شرکت برای حدود ۶ ساعت از دسترس خارج شدن (یا برای بعضی ها کیفیت سرویس دهی پایین اومده بود) رو به یاد بیارید. نمی‌خوایم خیلی روی این اتفاق الان تمرکز کنیم، اما اتفاق جالبی که افتاد مهاجرت تعداد بسیار زیادی از کاربران پیام‌رسان های Whats App و Facebook Messenger به یک راهکار موثر در اون لحظه بود. انتخاب بسیاری از کاربران هم در اون تایم استفاده از تلگرام بود که یهو تعداد خیلی زیادی از آدما اومدن داخل تلگرام ثبت نام کنن. پس شرکت متایی که خیلی اوقات سعی کرده و هزینه کرده که کاربرای پلتفرم های دیگه رو به خودش جذب کنه الان فقط بخاطر ۶ ساعت عدم دسترسی به سرویس هاش داره بسیاری از کاربرانش رو از دست میده، چه بسا خیلی ها هم از تلگرام خوششون اومد و همونجا موندن. (البته تلگرام هم تحت تاثیر این اتفاق قرار گرفت و انتظار این تعداد از کاربر رو در لحظه نداشت ولی حداقل دست و پا شکسته در دسترس بود و کار خیلی هارو راه انداخت). پس این موضوع دسترسی پذیری پایین اپلیکیشن، نه تنها شما رو بی خواب می‌کنه بلکه کاربر رو معطل نگه می‌داره و اصلا خود محصول و شرکت رو در معرض ضرر های بزرگ قرار میده.
فرض کنید تیم فروش شرکت شروع به یک تبلیغ گسترده و پر هزینه در راستای محصولات شرکت می‌کنه. از قبل به شما گفته میشه که انتظار می‌ره آمار بازدید از سایت بالا بره و فرضا یک تخمین ۳ برابری هم به شما می‌دن. شما و تیم فروش خوب می‌دونید که اگر الان تعداد بازدید کنندگان/استفاده کنندگان از سایتتون به طور میانگین ۱۰۰۰ نفر هست، قراره در طی این تبلیغات گسترده به مدت یک هفته به ۳۰۰۰ نفر برسه و بعدش به ۱۵۰۰ نفر کاهش پیدا کنه (طبیعتا خیلی ها میان می‌بینن و استفاده نمی‌کنن در آینده). حالا شما این وسط با چه چالشی روبرو هستید؟ خب شما می‌دونید زیرساخت و پیاده سازی شما در بدترین حالت ممکن طبق مشاهداتون بیشتر از ۱۴۰۰ نفر رو جواب نمیده چه بسا هیچ‌وقت بیشتر از ۱۲۰۰ نفر رو تجربه نکردید، پس الان باید زیرساختتون رو گسترش بدید که بهش می‌گیم Scale Up. از طرفی این وضعیت فقط برای یک هفته قراره باشه و بعدش میخواید زیرساخت رو به امون خدا ول کنید و اون همه منابع رو بلاستفاده بزارید بمونه؟ اینطوری نگاه کنید که شما همواره به دنبال هزینه کردن به اندازه نیازتون هستید و داشتن یک زیرساخت با ظرفیت ۲ برابری که می‌دونید ۹۰ درصد مواقع ۵۰ درصد منابعش قراره بلاستفاده باشه براتون کاملا آشکاره. پس می‌دونید که بعدش باید منابع بلاستفاده رو آزاد کنید که بهش می‌گیم Scale Down. اینجاست که همه تیم های فنی دست به دست هم می‌دن که گسترش رو شروع کنن. تیم زیرساخت سرورها و سخت‌افزار های جدید شبکه رو سفارش میده و کلی بالا پایین می‌کنه که سریعا به دستش برسه که ممکنه دیر بشه. شما هم شروع به هماهنگی‌ها می‌کنید و اینور اونور می‌رید تا منابعتون رو تحویل بگیرید. بعدش هم باید با چالش های پیاده سازی توی این Scale دست و پنجه نرم کنید و هزارتا تست بگیرید که مطمئن بشید توی اون یک هفته زحمتتاتون به فنا نره. پس خیلی واضحه که اگه یک چیزی بود که این Scale Up و Scale Down رو براتون سریع می‌کرد اونوقت می‌تونستید زمان بیشتری برای تست بزارید و تو این مسیر ممکن بود با چالش هایی روبرو بشید که اصلا مرتبط با منابع نیست و خیلی وابسته به خود نرم‌افزار و چیزای دیگه است. پس شما فهمیدی زیرساخت شما از منظر منابع پویا (Dynamic) نیست و برای گسترش خیلی باید انرژی بزارید. از طرفی تمام این مسائل رو با این فرض جلو بردیم که تخمینمون از ۳۰۰۰ نفر در بیشترین حالت کاملا دقیق باشه و یهو نشه که محصول هایپ بشه و ۱۰۰۰۰ نفر بیان :)
خب حالا که یکسری از چالش های مدیریت زیرساخت رو در سیستم های به اصطلاح سنتی دیدیم، بیاین ببینیم چه راهکارهای نوین و مناسبی الان در اختیارمون هست.
در پارت بعدی درباره مجازی سازی صحبت می‌کنیم که یکی از پایه ای و قدیمی ترین نیازمندی های زیرساخت های ابری/غیر ابری از گذشته تا الان بوده.
