با ما همراه شوید تا به گذشته نگاهی بیندازیم و به سفر طراحی معماری‌های مرجع ما بپردازیم تا به کاربران کمک کنیم به راحتی گیت‌لب را در مقیاس بزرگ مستقر کنند. اهداف، فرآیند و آنچه در پنج سال گذشته رخ داده است را بیاموزید.
پنج سال پیش، اولین معماری‌های مرجع GitLab را معرفی کردیم. این معماری‌ها که در ابتدا به عنوان همکاری بین پلتفرم تست GitLab (پیش‌تر مهندسی کیفیت) و تیم‌های پشتیبانی و همراه با سایر مشارکت‌کنندگان توسعه یافتند، هدف دارند تا نقاط شروع مقیاس‌پذیر و انعطاف‌پذیر برای استقرار GitLab در مقیاس بزرگ، متناسب با بار هدف یک سازمان، ارائه دهند.
از زمان معرفی آنها، ما از تأثیر این معماری‌ها بر مشتریان خود در مسیر DevSecOps آنها هیجان‌زده هستیم. ما همچنان به تکرار، گسترش و پالایش این معماری‌ها ادامه می‌دهیم تا به شما آخرین و بهترین راهنمایی‌ها در مورد استقرار، مقیاس‌بندی و نگهداری محیط‌های GitLab خود ارائه دهیم.
به مناسبت پنج سالگی، در اینجا نگاهی به پشت پرده طراحی معماری‌های مرجع و نحوه کاربرد آن در امروز می‌اندازیم.
قبل از معرفی معماری‌های مرجع، ما اغلب از مشتریان خود در مورد موانعی که هنگام استقرار GitLab در مقیاس بزرگ برای رسیدن به اهداف عملکرد و در دسترس بودن خود با آن مواجه بودند، شنیدیم.با وجود اینکه هر محیط GitLab به دلیل نیاز به برآورده کردن الزامات خاص مشتریان، تا حدودی منحصر به فرد است، اما ما از طریق اجرای GitLab.com و همچنین از طریق تعامل با مشتریان بزرگ خود متوجه شدیم که اصول مشترکی برای استقرار GitLab در مقیاس بزرگ وجود دارد که ارزش به اشتراک گذاشتن را دارند.هدف ما این بود که نیازهای مشتریان را برطرف کنیم و در عین حال، بهترین شیوه‌های استقرار را ترویج دهیم تا انحراف را کاهش داده و هم‌راستایی را افزایش دهیم.
ما تصمیم گرفتیم که آزمایش‌های عملکردی را افزایش دهیم تا تیم‌های مهندسی ما بهتر بتوانند مشکلات عملکردی را شناسایی و حل کنند. هدف ما این بود که عملکرد GitLab را بهبود دهیم و اطمینان حاصل کنیم که در آینده نیز عملکرد خوبی داشته باشد.
برای انجام آزمایش‌های دقیق و مفید، ابتدا باید یک محیط GitLab استاندارد و قابل مقایسه ایجاد کنیم که بتواند حجم کاری مورد انتظار را تحمل کند.
وارد معماری‌های مرجع شوید
ما فهمیدیم که نیاز به یک معماری مشترک داریم، بنابراین شروع کردیم به تعیین اهداف برای این پروژه. و در نهایت، این اهداف را تعیین کردیم:
عملکرد: باید اطمینان حاصل کنیم که معماری طراحی شده، توانایی پاسخگویی به نیازهای عملکردی سیستم را داشته باشد و بتواند حجم کاری مورد انتظار را بدون افت کیفیت و سرعت اجرا کند.
دسترسی‌پذیری: تا حد امکان، زمان فعالیت و قابلیت اطمینان را به حداکثر برسانید.(یکی از اهداف اصلی در طراحی و پیاده‌سازی این معماری، افزایش دسترسی‌پذیری سیستم است. به عبارت دیگر، باید تلاش شود تا سیستم به صورت مداوم و بدون وقفه کار کند و کاربران بتوانند در هر زمان به آن دسترسی داشته باشند. برای رسیدن به این هدف، باید زمان فعالیت سیستم را به حداکثر رساند و قابلیت اطمینان آن را افزایش داد.)
مقیاس‌پذیری و انعطاف‌پذیری: اطمینان حاصل کنید که این معماری قابل مقیاس‌بندی و انعطاف‌پذیر است تا نیازهای فردی مشتریان را برآورده کند.طراحی معماری باید به گونه‌ای باشد که بتواند با رشد و تغییر نیازهای مشتریان سازگار شود و به راحتی بزرگ‌تر یا کوچک‌تر شود. این به معنای آن است که سیستم باید بتواند به صورت خودکار منابع خود را افزایش یا کاهش دهد تا با حجم کاری متغیر مشتریان مطابقت داشته باشد.
صرفه اقتصادی: تخصیص منابع را بهینه کنید تا از هزینه‌های غیر ضروری جلوگیری شود.باید منابع را به گونه‌ای تخصیص دهیم که بیشترین بازده را داشته باشیم و از هدر رفتن منابع جلوگیری کنیم. به عبارت دیگر، باید هزینه‌های غیر ضروری را کاهش دهیم و در عین حال به اهداف خود دست پیدا کنیم.
نگهداری‌پذیری: استقرار و مدیریت معماری را با استفاده از پیکربندی‌های استاندارد تا حد ممکن ساده کنید..
لازم به ذکر است که این اهداف به ترتیب اولویت نبودند و ما همچنان به آنها پایبند هستیم.
بعد از اینکه تصمیم گرفتیم چه چیزی را می‌خواهیم انجام دهیم، باید یک طرح کلی برای انجام آن طراحی می‌کردیم. سپس باید بررسی می‌کردیم که این طرح به درستی کار می‌کند و به اهداف ما می‌رسد.
طراحی این فرایند به طور نسبی ساده است.
اطلاعاتی در مورد سیستم‌های فعلی و میزان کاری که توانسته‌اند انجام دهند، جمع‌آوری کنید.
با استفاده از اطلاعاتی که جمع‌آوری کرده‌ایم (معیارها)، یک طرح کلی و اولیه برای ساختار سیستم را طراحی کنید.
محیط را بسازید و آزمایش کنید تا اعتبارسنجی شود.
محیط را به صورت تدریجی بر اساس نتایج آزمون و معیارها تنظیم کنید تا زمانی که به یک معماری معتبر که اهداف را برآورده کند، دست یابیم.
اگرچه طراحی اولیه این فرایند ساده به نظر می‌رسید، اما در واقعیت، اجرای آن ساده نبود و نیاز به کار و تلاش داشت.
ابتدا، ما داده‌ها را جمع‌آوری و بررسی کردیم.
برای اینکه بتوانیم بفهمیم چه محیط‌هایی برای چه حجم کاری مناسب هستند، ما هم به داده‌های داخلی GitLab.com و هم به داده‌های چند مشتری بزرگ که از GitLab استفاده می‌کنند، مراجعه کردیم و اطلاعات مربوط به عملکرد و ظرفیت این محیط‌ها را بررسی کردیم.
برای اینکه بتوانیم به طور دقیق اندازه‌گیری کنیم که هر محیط چقدر کار می‌کند، ما از یک واحد اندازه‌گیری به نام درخواست‌ها در ثانیه (RPS) استفاده کردیم. RPS نشان می‌دهد که سیستم در هر ثانیه چند درخواست را می‌تواند پردازش کند.
با استفاده از RPS می‌توانیم بفهمیم که هر محیط چقدر کار می‌تواند انجام دهد و این را با تعداد کاربرانی که از آن محیط استفاده می‌کنند مقایسه کنیم. به این ترتیب می‌توانیم بفهمیم که هر کاربر چقدر فشار روی سیستم می‌آورد.
با بررسی داده‌هایی که جمع‌آوری کردیم، توانستیم متوجه شویم که بین اندازه محیط‌ها و عملکرد آنها چه ارتباطی وجود دارد. این به ما کمک کرد تا الگوهای مشترکی را در معماری‌های مختلف پیدا کنیم.بعد از جمع‌آوری اطلاعات، ما شروع به طراحی یک نمونه اولیه برای سیستم کردیم. این طراحی باید با اطلاعاتی که جمع‌آوری کرده بودیم مطابقت داشته باشد.ما جمع‌آوری داده‌ها (مرحله اول) را با شروع طراحی اولیه (مرحله دوم) همزمان انجام دادیم. دلیل این کار این بود که ایده خوبی در مورد نحوه شروع داشتیم. این ایده شامل گرفتن طراحی اصلی GitLab.com و کوچک کردن آن برای مطابقت با نیازهای هر مشتری و در عین حال حفظ مقرون به صرفه بودن بود.این به ما اجازه داد تا با استفاده از داده‌هایی که در حال تحلیل آنها بودیم، آزمایش عملکرد نمونه اولیه را شروع کنیم تا به طور متناسب تأیید کنیم.بعد از اینکه چندین بار طرح اولیه را تغییر دادیم و اصلاح کردیم، بالاخره به یک طرح اولیه مناسب برای شروع کار رسیدیم.
برای بررسی اینکه آیا معماری ما به درستی کار می‌کند و می‌تواند بار مورد انتظار را تحمل کند، ما باید آزمایش‌های عملکردی انجام دهیم. برای این کار، ما نقاط مهمی از سیستم را انتخاب کردیم و با استفاده از داده‌های نمونه، آزمایش کردیم که سیستم چگونه در شرایط مختلف عمل می‌کند. همچنین، فهمیدیم که برای ساخت و مدیریت این سیستم، به ابزارهای خودکار نیاز داریم.
ما با تلاش‌های خود دو ابزار جدید به نام‌های GitLab Performance Tool و GitLab Environment Toolkit را ساختیم. قبلاً در مورد این ابزارها نوشته‌ام و ما همچنان از آنها استفاده می‌کنیم. شما هم می‌توانید از این ابزارها استفاده کنید
بعد از آماده شدن همه چیز، شروع کردیم به آزمایش کردن معماری نمونه. ما این کار را چندین بار تکرار کردیم و هر بار نتایج را بررسی می‌کردیم و تغییراتی در معماری ایجاد می‌کردیم. به این ترتیب، توانستیم مشکلات واقعی را از مشکلات محیطی تشخیص دهیم و در نهایت، اولین معماری مناسب را طراحی کنیم.معماری که ما طراحی کردیم، اکنون به عنوان معماری مرجع برای سیستم‌هایی با 200 درخواست در ثانیه یا 10،000 کاربر شناخته می‌شود.
مشکلات خاص باگ‌ها یا الگوریتم‌ها را با دستوراتی مانند زیر حل کنید.
ما اولین معماری مرجع را چند سال پیش منتشر کردیم و از آن زمان تاکنون، همچنان به بهبود و توسعه آن ادامه داده‌ایم. ما این معماری‌ها را به عنوان مستندات زنده توصیف می‌کنیم، زیرا آنها همیشه در حال تغییر و به‌روزرسانی هستند.
معماری‌های مرجع در اندازه‌ها و مقیاس‌های مختلفی طراحی می‌شوند تا بتوان آنها را برای انواع مختلف استقرارها (deployment) به کار برد. به عبارت دیگر، بسته به نیازهای هر پروژه و حجم کاری که سیستم باید تحمل کند، می‌توان از یک معماری مرجع با اندازه مناسب استفاده کرد.
برای محیط‌های کوچک‌تر و کم اهمیت‌تر، از سیستم‌هایی با قابلیت دسترسی پایین‌تر استفاده می‌شود. به عبارت دیگر، در این محیط‌ها، الزامی نیست که سیستم همیشه در دسترس باشد و در صورت بروز مشکل، ممکن است مدتی از کار بیفتد.
مستندات کامل گام به گام در همکاری با همکارانمان در بخش نگارش فنی و پشتیبانی
ما راهکارها و توصیه‌های بیشتری را ارائه داده‌ایم تا به شما در تعیین اندازه مناسب برای پیکربندی GitLab خود، مقیاس‌بندی آن متناسب با نیازهایتان و مدیریت مؤثر پروژه‌های بزرگ و پیچیده مانند مونورپوها کمک کنیم.
انواع ترکیبی cloud native که در آنها برخی مؤلفه‌ها در Kubernetes اجرا می‌شوند(ما در مورد سیستم‌هایی صحبت می‌کنیم که هم ویژگی‌های cloud native دارند (یعنی برای اجرا در محیط‌های ابری طراحی شده‌اند) و هم ترکیبی از اجزای مختلف هستند. در این سیستم‌ها، برخی از اجزا (مثلاً سرویس‌های میکروسرویس) در یک محیط کانتینری مانند Kubernetes اجرا می‌شوند و برخی دیگر ممکن است در محیط‌های سنتی یا سایر محیط‌های ابری اجرا شوند.)
توصیه‌ها و راهنمایی‌ها برای خدمات ارائه دهندگان ابری ( ارائه پیشنهادها و دستورالعمل‌هایی است که به شما کمک می‌کند تا بهترین خدمات ارائه دهنده ابری را انتخاب کنید و از آن به بهترین نحو استفاده کنید.)
و موارد دیگر! بخش تاریخچه به‌روزرسانی‌ها را در مستندات معماری مرجع بررسی کنید!تا اطلاعات کامل‌تری کسب کنید.
ما یک برنامه آزمایشی کامل ایجاد کرده‌ایم تا هر هفته بررسی کنیم که معماری‌های مرجع ما هنوز هم به خوبی کار می‌کنند و با آخرین تغییرات در GitLab سازگار هستند.
ما بسیار خوشحال هستیم که این تلاش‌ها به بسیاری از مشتریان و همچنین تیم‌های داخلی ما کمک کرده است تا خدمات جدید و خوبی ارائه دهند. ما برای توسعه GitLab Dedicated از معماری‌های مرجع استفاده کردیم. حتی بعد از پنج سال، ما همچنان به تلاش برای بهبود و توسعه معماری‌های مرجع ادامه می‌دهیم تا بهترین راهنمایی‌ها را برای شما ارائه دهیم.
در صورتی که این مقاله ( GitLab Duo Chat : ابزاری برای استفاده بهتر از هوش مصنوعی ) برای شما مفید و آموزنده بود، پیشنهاد می‌شود برای اطلاع از سایر مقالات مستر لایسنس به صفحه وبلاگ مستر لایسنس مراجعه نمایید.
تیم مستر لایسنس با بهره گیری از متخصصان مجرب امنیتی قادر به ارائه خدمات و راهکار در زمینه مهندسی معکوس و ایجاد لایسنس نرم افزارهای خارجی با تمامی امکانات کامل می باشد .
تمامی حقوق قانونی این سایت مربوط به MRlicense میباشد
