نکات کلیدی
-
معماری مبتنی بر سلول، تابآوری و تحمل خطای میکروسرویسها را بهبود میدهد.
-
مشاهدهپذیری (Observability) کلید توسعه و راهبری معماری مبتنی بر سلول است.
-
روتر سلول (Cell Router) یک مؤلفه کلیدی معماری مبتنی بر سلول است، و باید به تغییرات دسترسپذیری و سلامت سلولها سریع واکنش نشان دهد.
-
برای رسیدن به پذیرش موفق معماری مبتنی بر سلول، یک رویکرد کلنگر و جامع نسبت به مشاهدهپذیری لازم است.
-
معماری مبتنی بر سلول از همان ستونهای مشاهدهپذیری میکروسرویسها استفاده میکند اما برای جا دادن عناصر اختصاصی این نوع معماری به سفارشیسازی نیاز دارد.
معماریهای مبتنی بر سلول در چند سال اخیر یک پارادایم نوظهور بودهاند، با شرکتهایی مثل Slack (که مهمترین سرویسهای کاربر-محورِ بحرانی را از مونولیت به معماریهای مبتنی بر سلول مهاجرت داد)، Flickr (که از یک رویکرد فدرالشده استفاده کرد تا دادههای کاربران را روی یک shard یا یک خوشه از سرویسهای زیاد ذخیره کند)، Salesforce (که یک راهکار را در قالب podها طراحی کرد، با قابلیتهای خود-محتوا که از ۵۰ نود تشکیل میشد)، و Facebook (که بلوکهای سازندهای با سرویسهایی به نام سلولها پیشنهاد داد، هر سلول شامل یک خوشه، یک مخزن متادیتا، و کنترلرهایی در Zookeeper). آنها از این معماریها برای پاسخ دادن به چالشهای تابآوری و تحمل خطا استفاده کردهاند. دلایل محبوبشدن شامل ایزولهسازی خرابیها، مقیاسپذیری بهتر، نگهداشت سادهتر، تحمل خطای تقویتشده، انعطافپذیری، و مقرونبهصرفه بودن است.
در مسیر رسیدن به تابآوری و تحمل خطا، طرفداران معماریهای مبتنی بر سلول به مشاهدهپذیری تکیه کردهاند، که نقش حیاتی در تکمیل پیادهسازیها داشته است. این موضوع درباره Interact هم صدق میکند، یکی از اولین شرکتهایی که مستندسازی کرد مشاهدهپذیری برای تضمین معماریهای مبتنی بر سلولِ سالم حیاتی بوده است. تیم مهندسی Interact از مشاهدهپذیری استفاده کرد تا بینشهای عمیقی درباره رفتار سیستم فراهم کند، که به آنها اجازه داد مسائل را پیشدستانه شناسایی کنند و بازیابی سریعتر از خرابیها را تسهیل نمایند. بهطور مشخص، آنها از حداکثر تعداد کلاینتهای میزبانیشده و حداکثر تعداد درخواستهای روزانه به ازای هر سلول استفاده کردند تا زیرساخت جدید را در کنار معماری موجود ایجاد کنند.
این مقاله به مزایای تابآوری و تحمل خطا در پذیرش معماریهای مبتنی بر سلول میپردازد، با تمرکز روی جنبه مشاهدهپذیری. بخش اول به یک سؤال رایج میپردازد: چرا از معماریهای مبتنی بر سلول استفاده کنیم اگر میکروسرویسها همین حالا هم تابآور و خطاپذیر هستند؟ با آن توضیح، بخش دوم روی مشاهدهپذیری و ملاحظات تحلیل ورودیها و خروجیهای معماریهای مبتنی بر سلول تمرکز میکند. در نهایت، بهترین شیوهها و نکات کلیدی را مرور میکند تا به دیدپذیری لازم برای شناسایی زودهنگام مسائل، تشخیص سریع مشکلات، و تصمیمگیریهای آگاهانهای برسیم که تابآوری و تحمل خطا را تقویت میکنند.
چرا از معماریهای مبتنی بر سلول استفاده کنیم اگر میکروسرویسها تابآور و خطاپذیر هستند؟
این یک واقعیت است که میکروسرویسها ریسک این را کاهش میدهند که یک خطای واحد کل سیستم را از کار بیندازد، چون از واحدهای کوچکتر و مستقلقابلاستقرار استفاده میکنند. این پارادایم اجازه میدهد خرابی در یک میکروسرویس کل اپلیکیشن را تحت تأثیر قرار ندهد. اما این هم یک واقعیت است که سروکار داشتن با پیچیدگی ناشی از ارتباط بین سرویسها، سطح تابآوری و تحمل خطا را کاهش میدهد. در حالی که میکروسرویسها برای مدیریت اپلیکیشنهای سازمانی در مقیاس بزرگ که روی ماژولار بودن و قابلمدیریت بودن متمرکزند مناسباند، معماریهای مبتنی بر سلول در سناریوهایی که به ماژولار بودن شدید، مقیاسپذیری، و بهرهوری منابع نیاز دارند مزیتهایی ارائه میکنند. این همان دلیلی بود که Tumblr، که در چند ماه از یک استارتاپ به یک شرکت فوقالعاده موفق تبدیل شد، ترجیح داد از مونولیت به معماریهای مبتنی بر سلول مهاجرت کند و نه به میکروسرویسها. مقیاسپذیری برای آنها اولویت بود چون باید زیرساختهایشان را تکامل میدادند در حالی که افزایشهای عظیم ماهبهماهِ ترافیک را مدیریت میکردند.
راهبرد مبتنی بر سلول: دسترسپذیری بالا (High Availability) برای نیازمندیهای رشد سریع
انتخاب معماریهای مبتنی بر میکروسرویس نیازمند تحلیل دقیق تعادل بین مزایا و معایب آن است. در حالی که مقیاسپذیری بهتر، تحمل خطا، و عملیات آسانتر را ارائه میدهد، همچنین پیچیدگیهایی در پیادهسازی و مدیریت ایجاد میکند. با این حال، معماریهای مبتنی بر سلول برای سیستمهایی که دسترسپذیری بالا را در اولویت میگذارند مناسباند، جایی که تجربه رشد سریع لازم است، یا توانایی مقیاسدهی مؤلفههای منفرد و ایزولهسازی خرابیها یک اولویت است.
معماری مبتنی بر سلول یک راهکار همگانی نیست، بلکه یک انتخاب راهبردی است که با نیازهای مشخص کسبوکار و فنی همراستا میشود. شکل ۱ نشان میدهد چگونه معماریهای مبتنی بر میکروسرویس میتوانند سیستمهای بزرگتر را به مؤلفههایی تفکیک کنند که دامنههای کسبوکارِ bounded context را در خود میپیچند. شکل ۲ نشان میدهد چگونه معماریهای مبتنی بر سلول پیچیدگی مرتبط با ارتباط بین آن سرویسها را ساده میکنند، جایی که هر سلول یکسان است و نماینده یک پشته کامل است که بهصورت مستقل مقیاس میگیرد.
شکل ۱. معماریهای مبتنی بر میکروسرویسها
شکل ۲. معماریهای مبتنی بر سلولها
در مورد شکل ۲، دو دیدگاه برای پیادهسازی معماریهای مبتنی بر سلول وجود دارد: یکی که در آن سلولها مؤلفههای تغییرناپذیر (immutable) هستند که در کنار هم یک سرویس را ارائه میدهند، و دیگری که در آن هر سلول یکسان است و نماینده یک سرویس کامل است. در دیدگاه اول، سلولها میتوانند با هم ارتباط برقرار کنند. در دیدگاه دوم، سلولها بهصورت مستقل بهعنوان یک واحد کامل ساخته، مستقر، و مدیریت میشوند چون هیچ ارتباطی بین سلولها وجود ندارد.
معماریهای مبتنی بر سلول میتوانند تابآوری و تحمل خطای بهتری ارائه کنند، اما اپراتورها چطور میتوانند تعیین کنند آیا سیستم این مزایا را ارائه میدهد؟ پاسخ مشاهدهپذیری است.
ملاحظات برای مشاهده معماریهای مبتنی بر سلول
معماریهای مبتنی بر سلول یک رویکرد قدرتمند برای ساخت سیستمهای تابآور ارائه میکنند. آنها این کار را از طریق اصول هستهایِ ایزولهسازی، خودمختاری، و تکرار (replication) انجام میدهند. هر سلول بهصورت مستقل عمل میکند، منابعش را مدیریت میکند، و بهصورت خودمختار تصمیم میگیرد. دادهها و سرویسهای حیاتی داخل سلول برای دسترسپذیری بهتر تکرار میشوند.
این معماریها سلولها را در چندین zone یا دیتاسنتر توزیع میکنند تا تابآوری و تحمل خطا را تضمین کنند و در برابر قطعیهای منطقهای محافظت کنند. بررسیهای سلامت پیوسته (continuous health checks) و مانیتورینگ خرابیها را زود تشخیص میدهند، در حالی که circuit breakerها از خرابیهای آبشاری جلوگیری میکنند. load balancing توزیع کارآمد ترافیک را تضمین میکند و در طول خرابیهای جزئی، عملکردهای ضروری را در اولویت قرار میدهد. chaos engineering بهصورت منظم تابآوری را با شبیهسازی خرابیها آزمایش میکند.
مشاهدهپذیری ابزار روزِ (state-of-the-art) فهمیدن وضعیت و سازوکارهای درونی پیادهسازیهای فعلی است. اگرچه یک سیستم میتواند بدون آن کار کند، جمعآوری، پردازش، تجمیع، و نمایش متریکهای کمیِ بلادرنگ تابآوری و تحمل خطا را افزایش میدهد. این دقیقاً یکی از دلایل گنجاندن آن بهعنوان یک اصل در Site Reliability Engineering است.
مشاهدهپذیری یک ستونِ معماریهای عالی است
علاوه بر اینکه یک راهبرد برای فهمیدن رفتار یک سیستم است، مشاهدهپذیری برای رسیدن به اهداف معماری خوب حیاتی است، بهخصوص در حوزههای برتری عملیاتی، قابلیت اطمینان، و بهرهوری عملکرد. شکل ۳ ستونهای رایج چارچوبهای well-architected را نشان میدهد و نسبت آنها با مشاهدهپذیری را قابلمشاهده میکند. از منظر برتری عملیاتی، مشاهدهپذیری بینشهای لازم را فراهم میکند تا بفهمیم سیستمها چطور عمل میکنند، مشکلات بالقوه را شناسایی کنیم، و تصمیمهای آگاهانه درباره بهینهسازی آنها بگیریم. برای رسیدن به بهرهوری عملکرد، مشاهدهپذیری به سازمانها اجازه میدهد گلوگاهها و ناکارآمدیها را در سیستمهایشان شناسایی کنند تا بتوانند اقدام کنند و عملکرد را بهبود دهند و هزینهها را کاهش دهند. در نهایت، قابلیت اطمینان، از طریق مانیتور کردن رفتار سیستم و تشخیص زودهنگام ناهنجاریها، مشاهدهپذیری کمک میکند خرابیها جلوگیری شوند و downtime کمینه شود.
شکل ۳. Well-Architected Framework + Observability
در مسیر مشاهده یک معماری مبتنی بر سلول، گام اول تعریف اهداف و شناسایی متریکها است، مثل mean time between failures (MTBF)، mean time to repair (MTTR)، availability، و recovery time objectives (RTOs)، که برای ارزیابی سطح تابآوری و تحمل خطا مناسباند. وقتی متریکها مشخص شدند، فعالیت بعدی فراهم کردن سازوکارهای instrumentation است که logging، جمعآوری متریکها، tracing، و event tracking را در بر میگیرد تا دادههای مرتبط جمعآوری شوند. سپس یک زیرساخت قدرتمند برقرار میشود تا این دادهها را بهطور کارآمد جمعآوری و تجمیع کند. در این نقطه، مشاهدهگران معمولاً دادههای جمعآوریشده را در مخزنهای مناسب مثل دیتابیسهای time-series ذخیره میکنند و آن را از طریق filtering، transformation، و enrichment پردازش میکنند. ابزارهای تحلیل و visualization بینشها را استخراج میکنند، الگوها را شناسایی میکنند، و ناهنجاریها را تشخیص میدهند. این بینشها در workflowهای توسعه و عملیات ادغام میشوند و حلقههای بازخورد برقرار میکنند که به بهبود طراحی سیستم و عملکرد رانده میشوند. در نهایت، فرایند بهصورت تکرارشونده پالایش میشود، با تنظیمهای پیوسته روی instrumentation، جمعآوری داده، و تحلیل بر اساس بازخورد و نیازمندیهای در حال تکامل. کل فرایند در شکل ۴ نشان داده شده است.
سفارشیسازی مشاهدهپذیری برای معماریهای مبتنی بر سلول
مشاهدهپذیری برای معماری مبتنی بر سلول به یک رویکرد سفارشی نیاز دارد تا با چالشها و فرصتهای منحصربهفردی که این طراحی سیستم توزیعشده ارائه میدهد مواجه شود. با در نظر گرفتن اینکه مشاهدهپذیری درباره مانیتورینگ، tracing، و logging است، instrumentation آگاه از سلول شامل جمعآوری متریکها در سطح سلول است، یعنی در قالب کلی، ثبت مصرف منابع (CPU، حافظه، شبکه)، تأخیر درخواست، نرخ خطا، و متریکهای سفارشی کسبوکار که به عملکرد هر سلول مرتبط است. distributed tracing درباره پیادهسازی tracing است تا درخواستها را در میان مرزهای سلول دنبال کند، بینشهایی درباره جریان تعاملها فراهم کند، و گلوگاهها را دقیق مشخص کند. در نهایت، تجمیع لاگ باید از سلولهای منفرد به یک سیستم متمرکز انجام شود، تا همبستگی و تحلیل در سراسر کل معماری ممکن شود.
ملاحظه دوم ایجاد داشبوردهای سطح سلول است که برای عملکردها و KPIهای مشخص هر سلول سفارشی شدهاند، که مانیتورینگ و عیبیابی مناسب را ممکن میکنند. با این پیکربندی، هشدارهای اختصاصی سلول بر اساس آستانهها و ناهنجاریهای اختصاصی سلول تضمین میکنند که اعلان سریع درباره مسائلی که سلولهای منفرد را تحت تأثیر قرار میدهند انجام شود.
ملاحظه سوم که به بهترین شیوهها در مشاهدهپذیری مرتبط است، نیاز به یک پروژه منحصربهفرد است که دادهها را از ابزارهای مختلف مشاهدهپذیری سطح سلول در یک پلتفرم متمرکز ادغام کند تا مانیتورینگ و تحلیل کلنگر انجام شود. این کار استفاده از پلتفرم متمرکز را آسانتر میکند تا رخدادها و متریکها بین سلولها همبسته شوند، وابستگیها و خرابیهای آبشاری بالقوه آشکار شوند.
شکل ۴. یک چارچوب پیشنهادی برای مشاهدهپذیری در معماریهای مبتنی بر سلول
ملاحظه نهایی ایزولهسازی سلول است، که سلولهای منفرد را تست میکند تا گلوگاههای عملکرد و حالتهای خرابیِ اختصاصی عملکردشان شناسایی شوند. در این ملاحظه، انتظار میرود آزمایشهای chaos طراحی و توسعه داده شوند تا اختلالهای کنترلشده (مثلاً network latency، محدودیتهای منابع) در سطح سلول اعمال شود تا تابآوری سنجیده شود و ضعفها شناسایی شوند.
با پیادهسازی این شیوهها، سازمانها میتوانند دیدپذیری عمیقی نسبت به رفتار معماری مبتنی بر سلول خود به دست آورند، که مانیتورینگ پیشدستانه، عیبیابی سریعتر، و بهبود کلی قابلیت اطمینان و عملکرد سیستم را ممکن میسازد. همیشه در نظر داشته باشید که ترکیب خودِ یک سلول میتواند از کسبوکاری به کسبوکار دیگر متفاوت باشد، که میتواند یک مزیت باشد چون تنوع دقیقاً یکی از مزایای معماریهای مبتنی بر سلول است.
چطور لایه مسیریابی (Routing Layer) تابآوری، تحمل خطا، و مشاهدهپذیری را فراهم میکند
علاوه بر سلولها و control plane، مسیریابی سلول در فراهمکردن تابآوری و تحمل خطا در معماریهای مبتنی بر سلول حیاتی است. مأموریت آن این است که درخواستها را بر اساس partition key به سلول درست توزیع کند، در حالی که یک اندپوینت واحد به کلاینتها ارائه میدهد. طبق DoorDash، این مؤلفه چندین مزیت ارائه میکند، از جمله حفظ تعادل ترافیک، حتی وقتی سرویسها بهطور ناهمگون در مناطق قابل دسترس توزیع شدهاند. این امکان را فراهم میکند که وزنهای ترافیک بین podها بهصورت پویا تنظیم شوند، عملیات دستی حذف شود و blast radius یک قطعی تک-AZ یا چند-AZ کاهش یابد، که در تحمل خطا حیاتی است و همچنین latency ترافیک را کاهش میدهد چون سرویسهای فراخواننده به فراخواندههای نزدیکتر متصل میشوند.
برای رسیدن به تحمل خطا در شبکهها، لایه مسیریابی از چندین سازوکار استفاده میکند، که بهعنوان راهکارهای نوآورانه برای فراهمکردن تابآوری مستندسازی شدهاند. یکی از آنها path redundancy است، که در آن پروتکلهای مسیریابی چندین مسیر به سمت مقصد را کشف و نگهداری میکنند؛ به این شکل، اگر مسیر اصلی خراب شود، ترافیک بهصورت خودکار از یک مسیر جایگزین دوباره مسیردهی میشود. راهبرد دیگر fast rerouting است، که طراحی شده تا خرابیها را سریع تشخیص دهد و روی یک راهکار مسیریابی جدید همگرا شود، downtime و اختلالهای سرویس را کمینه کند؛ load balancing کلاسیک که ترافیک را روی چندین مسیر توزیع میکند، که از ازدحام جلوگیری میکند و بهرهبرداری از منابع شبکه را بهینه میسازد. و در نهایت، failure detection and recovery که در آن پروتکل مسیریابی وقتی خرابی تشخیص داده شد فرایند بازیابی را فعال میکند تا یک مسیر جایگزین پیدا کند.
نقش لایه مسیریابی در مشاهدهپذیری معماری
لایه مسیریابی همچنین بهطور معناداری روی مشاهدهپذیری اثر میگذارد بهخاطر ماهیت توزیعشده سیستمهای مبتنی بر سلول. چون این یک مؤلفه است که عملیات سلولها را متمرکز میکند، بهترین نامزد برای فراهمکردن بینش درباره سلامت و عملکرد کل سیستم است. مشاهده معماری از این مؤلفه اجازه میدهد الگوهای ترافیک، latency، و خطاها در نقاط مختلف شبکه دیده شوند. این به اپراتورها اجازه میدهد گلوگاهها را دقیق مشخص کنند، مؤلفههای در حال خرابی را شناسایی کنند، و تصمیمهای مسیریابی را برای عملکرد بهتر بهینه کنند.
علاوه بر این، لایه مسیریابی میتواند instrument شود تا متریکها و لاگهای دقیق جمعآوری کند، دادههای ارزشمندی برای عیبیابی و تحلیل علت ریشهای فراهم کند. برای مثال، tracing مسیر یک درخواست در میان چندین سلول میتواند آشکار کند تأخیرها کجا رخ میدهند یا خطاها از کجا منشأ میگیرند. این دیدپذیری دانهریز برای حفظ قابلیت اطمینان و کارایی اپلیکیشنهای پیچیده مبتنی بر سلول ضروری است.
در نتیجه، لایه مسیریابی در یک معماری مبتنی بر سلول فقط مسئول هدایت ترافیک نیست، بلکه بهعنوان یک مؤلفه حیاتی برای مشاهدهپذیری هم عمل میکند. مانیتور و تحلیل الگوهای ترافیک بینشهای ارزشمندی درباره رفتار سیستم فراهم میکند، که عیبیابی پیشدستانه و بهینهسازی را ممکن میسازد. این تضمین میکند که سیستم مبتنی بر سلول تابآور و مقیاسپذیر باقی بماند و تحت بارهای کاری متغیر، بهصورت بهینه عمل کند.
بهترین شیوهها برای فراهم کردن تابآوری، تحمل خطا، و مشاهدهپذیری برای معماریهای مبتنی بر سلول
مشاهدهپذیری در معماریهای مبتنی بر سلول برای حفظ سلامت و عملکرد سیستم حیاتی است. یک بهترین شیوه بنیادین، لاگبرداری متمرکز است، جایی که لاگها از همه سلولها در یک مخزن یکپارچه تجمیع میشوند. این یکپارچهسازی عیبیابی و تحلیل را ساده میکند، به اپراتورها اجازه میدهد مسائل را در سراسر کل سیستم سریع شناسایی و رسیدگی کنند. قالبهای لاگبرداری ساختیافته این فرایند را بیشتر تقویت میکنند با اینکه امکان query و filter کارآمد دادههای لاگ را فراهم میکنند.
متریکها و مانیتورینگ
متریکها و مانیتورینگ به همان اندازه مؤلفههای حیاتی مشاهدهپذیری هستند. جمعآوری متریکهای دقیق درباره عملکرد سلول، مصرف منابع، و نرخ خطا بینشهای ارزشمندی درباره رفتار سیستم فراهم میکند. راهاندازی داشبوردها و هشدارها بر اساس این متریکها اجازه میدهد ناهنجاریها و گلوگاههای بالقوه بهصورت پیشدستانه شناسایی شوند. ابزارهای visualization مثل Grafana میتوانند این متریکها را بهطور مؤثر نمایش دهند، که دیدن روندها و الگوهایی را که ممکن است نشاندهنده مشکلات زیربنایی باشند آسانتر میکند.
ردیابی توزیعشده
ردیابی توزیعشده یک بهترین شیوه ضروری دیگر برای فهمیدن جریان درخواستها از طریق یک معماری مبتنی بر سلول است. با دنبالکردن درخواستها وقتی در میان چندین سلول حرکت میکنند، اپراتورها میتوانند گلوگاههای عملکرد، مسائل latency، و خرابیها در تعاملهای میکروسرویسها را دقیق مشخص کنند. ابزارهای ردیابی توزیعشده مثل Jaeger، Zipkin، یا AWS X-Ray میتوانند به visualization این تعاملهای پیچیده کمک کنند، که تشخیص و حل مشکلات ناشی از ارتباط بین سلولها را سرراستتر میسازد.
هشداردهی و مدیریت رخداد
هشداردهی و مدیریت رخداد بخش جداییناپذیر یک راهبرد مشاهدهپذیری کامل و همهجانبه هستند. پیکربندی هشدارها بر اساس آستانههای از پیش تعریفشده یا ناهنجاریها در لاگها و متریکها اعلانهای بهموقع درباره مسائل بالقوه را ممکن میکند. این هشدارها میتوانند از طریق کانالهای مختلف مثل ایمیل و SMS ارسال شوند یا در پلتفرمهای مدیریت رخداد مثل PagerDuty ادغام شوند. داشتن فرایندهای مدیریت رخدادِ خوب تعریفشده پاسخهای سریع و سازمانیافته به هشدارها را تضمین میکند، که downtime و اثر روی کل سیستم را کمینه میکند.
یک رویکرد کلنگر نسبت به مشاهدهپذیری
علاوه بر این شیوههای هستهای، پذیرش یک رویکرد کلنگر نسبت به مشاهدهپذیری مفید است. این شامل بازبینی و پالایش منظم پیکربندیهای لاگبرداری، مانیتورینگ، و tracing است تا با نیازمندیهای در حال تکامل سیستم سازگار شود. علاوه بر این، وارد کردن بازخورد از postmortemهای رخداد میتواند کمک کند حوزههای قابل بهبود در راهبرد مشاهدهپذیری شناسایی شوند. با ارتقای پیوسته مشاهدهپذیری، سازمانها میتوانند تضمین کنند معماریهای مبتنی بر سلولشان تابآور، پرفورمنسدار، و آسان برای مدیریت باقی میمانند.
