اپلیکیشنهای سنگین
سامانههایی که ساعت اوج را دوام میآورند
وقتی دههزار کاربر همزمان روی یک سرویساند، تفاوت معماری درست و معماری خوشظاهر در عدد تأخیر دیده میشود. کار ما دقیقاً همان عدد است.
درخواست جلسه فنی
هر سامانهای بالاخره زیر بار کم میآورد؛ پرسش این است که در چه عددی و با چه رفتاری. پیش از نوشتن یک خط کد، بار هدف، تأخیر قابل قبول و رفتار سیستم در لحظه اشباع را مکتوب میکنیم و همان اعداد معیار پذیرش پروژه میشوند. اگر به آنها نرسیم، کار تمامشده حساب نمیشود.
چهار حوزه کاری
نقطه شروع، تفکیک مرزهای سرویس بر پایه الگوی واقعی بار است، نه بر پایه نمودار سازمانی. مسیرهای پرتکرار را از مسیرهای کمتکرار جدا میکنیم تا هرکدام مستقل از دیگری مقیاس بگیرد.
- تفکیک سرویسها بر پایه مسیرهای داغ و مرزهای داده
- انتخاب الگوی ذخیرهسازی: پایگاه داده رابطهای، کش و صف پیام
- طراحی لایه کاربردی بدون حالت، برای مقیاس افقی
- تعیین رفتار در اشباع: صفگذاری، پسزدن درخواست و تخریب کنترلشده
خروجی این مرحله یک سند معماری با نمودار جریان داده و فهرست مفروضات است. هر مفروض بعداً در آزمون بار سنجیده میشود؛ آنچه سنجیده نشود، فرض باقی میماند.
کارایی را حدس نمیزنیم. سناریوی بار را از گزارش ترافیک واقعی یک روز اوج میسازیم و روی محیطی با همان ابعاد سختافزاری محیط تولید اجرا میکنیم.
- پروفایلگیری پرسوجوها و رفع قفلهای پایگاه داده
- آزمون بار پلکانی، آزمون ماندگاری و یافتن نقطه شکست
- لایه کش و سیاست روشن برای بیاعتبارسازی آن
- بودجه تأخیر برای هر مسیر و هشدار در صورت عبور از آن
گزارش پایانی صدک ۹۵ و صدک ۹۹ را میدهد، نه میانگین را؛ میانگین دقیقاً همان جایی را پنهان میکند که کاربر درد میکشد.
هیچ سامانه سنگینی در خلأ کار نمیکند؛ باید با هسته قدیمی، سامانه مالی و سرویسهای سازمانی دیگر حرف بزند — سرویسهایی که معمولاً نه مستندات کاملی دارند و نه اجازه تغییر.
- دروازه رابطها، نسخهبندی و قرارداد روشن میان سرویسها
- همگامسازی داده و مدیریت ناسازگاری موقت میان سامانهها
- اتصال به سامانههای قدیمی از راه آداپتور، بدون دستزدن به هسته
- احراز هویت یکپارچه و ثبت رد ممیزی برای هر تراکنش
برای هر سرویسی که مالکش نیستیم فرض میکنیم روزی پاسخ نخواهد داد؛ مهلت پاسخ، تلاش مجدد و قطعکننده مدار از روز اول در طراحی هست. زیرساخت اجرای این سرویسها
کدی که روی رایانه تیم توسعه کار میکند هنوز ارزشی نساخته است. ارزش وقتی ساخته میشود که انتشار بدون قطعی انجام شود و مسیر بازگشت هم روشن باشد.
- خط لوله ساخت و انتشار خودکار، با اجرای آزمون در هر مرحله
- انتشار مرحلهای و بازگشت به نسخه پیشین در کمتر از ده دقیقه
- پایش تأخیر، نرخ خطا، توان عملیاتی و اشباع منابع روی یک داشبورد
- دفترچه عملیات و تمرین حادثه، پیش از نخستین انتشار روی تولید
پس از انتشار، سرویس زیر پایش میماند و زمان پاسخ و مسیر ارجاع از پیش تعیینشده است. سطوح خدمت پشتیبانی
نتیجه آزمون بار روی یک سامانه نمونه
جدول زیر خروجی آزمون بار درگاه پرداخت داخلی یک بانک خصوصی است که معماریاش را بازطراحی کردیم. سناریو از گزارش ترافیک یک روز اوج واقعی ساخته شده و آزمون روی محیط شبیه تولید اجرا شده است.
| همزمانی | تأخیر صدک ۹۵ | توان عملیاتی | نرخ خطا |
|---|---|---|---|
| ۵۰۰ کاربر | ۴۸ میلیثانیه | ۹۴۰ درخواست بر ثانیه | ۰٫۰۰٪ |
| ۲٬۰۰۰ کاربر | ۷۶ میلیثانیه | ۳٬۶۰۰ درخواست بر ثانیه | ۰٫۰۱٪ |
| ۵٬۰۰۰ کاربر | ۱۳۰ میلیثانیه | ۸٬۲۰۰ درخواست بر ثانیه | ۰٫۰۳٪ |
| ۱۰٬۰۰۰ کاربر | ۱۹۰ میلیثانیه | ۱۴٬۵۰۰ درخواست بر ثانیه | ۰٫۰۸٪ |
| ۱۵٬۰۰۰ کاربر | ۴۱۰ میلیثانیه | ۱۷٬۹۰۰ درخواست بر ثانیه | ۰٫۹۰٪ |
این عددها کجا معتبر نیستند
بار هدف قرارداد ۱۰٬۰۰۰ کاربر همزمان بود؛ پله آخر فقط برای پیداکردن نقطه اشباع اجرا شد و جایی است که صفها شروع به پرشدن میکنند. هر عدد کارایی به سه چیز گره خورده است: سختافزار، سناریو و نسخه کد. با تغییر هر کدام، آزمون باید دوباره اجرا شود.
به همین دلیل آزمون بار را یک رویداد پایان پروژه نمیدانیم؛ در خط تحویل مینشیند و پیش از هر انتشار مهم دوباره اجرا میشود. اگر روی داده همین پایش تحلیل و پیشبینی ظرفیت هم لازم داشتید، تحلیل داده و پایش ادامه طبیعی همین کار است.
پرسشهای متداول
از کجا بفهمیم مشکل از معماری است یا از سختافزار؟
معمولاً در یک ارزیابی دو تا سه هفتهای روشن میشود. اگر با دوبرابرکردن منابع، تأخیر صدک ۹۵ تقریباً نصف شود، مشکل ظرفیتی است؛ اگر تغییر محسوسی نکند، جایی در مسیر یک گلوگاه سریالی دارید — یک قفل پایگاه داده، یک فراخوانی همگام یا یک کش غایب. این ارزیابی خروجی مستقل دارد و به ادامه همکاری با ما مشروط نیست.
سامانه فعلی را بازنویسی میکنید یا اصلاح؟
پیشفرض ما اصلاح است. بازنویسی کامل پرهزینهترین گزینه است و ریسک آن معمولاً دستکم گرفته میشود. در بیشتر پروژهها با جداکردن دو یا سه مسیر پرتکرار از هسته و انتقال تدریجی آنها، بخش بزرگی از مسئله حل میشود و سامانه در تمام مدت در حال سرویسدهی میماند.
اگر واقعاً بازنویسی لازم باشد، آن را با دلیل فنی و برآورد زمان میگوییم، نه بهعنوان پیشنهاد پیشفرض.
آزمون بار روی محیط تولید انجام میشود؟
نه بدون توافق کتبی و نه در ساعت کاری. قاعده ما این است که آزمون روی محیطی با همان ابعاد سختافزاری و همان نسخه کد اجرا شود. اگر سازمان چنین محیطی ندارد، ساختن آن بخشی از فاز اول پروژه میشود؛ بدون آن، هر عددی که گزارش کنیم قابل اتکا نیست.
چقدر طول میکشد تا اثر بهبود دیده شود؟
در پروژههای بهینهسازی، معمولاً نخستین بهبود قابل اندازهگیری در هفته سوم یا چهارم به دست میآید؛ چون کارهای کمهزینه و پراثر — مثل نمایهگذاری درست و حذف فراخوانیهای تکراری — زود انجام میشوند. تغییرات معماری که نیاز به انتشار مرحلهای دارند، بسته به دامنه، هشت تا شانزده هفته میبرند.
با چه پشته فناوری کار میکنید؟
سمت خدمتدهنده بیشتر با جاوا، داتنت، گو و پایتون کار کردهایم و در لایه داده با پایگاههای رابطهای، کش درونحافظهای و صف پیام. اما انتخاب فناوری را از سازمان جدا نمیکنیم: اگر تیم داخلی شما قرار است سامانه را نگه دارد، پشتهای انتخاب میشود که همان تیم بتواند با آن کار کند.
پس از تحویل، نگهداری با کیست؟
هر دو حالت ممکن است. اگر تیم داخلی دارید، مستندات، دفترچه عملیات و دو جلسه انتقال دانش را تحویل میدهیم و کنار میرویم. اگر ترجیح میدهید سرویس زیر پایش ما بماند، قرارداد پشتیبانی با سطح خدمت مشخص بسته میشود. شرایط پشتیبانی و زمانهای پاسخ در صفحه پشتیبانی آمده است.
بار هدفتان را میدانید؟
اگر عددی در دست دارید، از همان شروع میکنیم. اگر ندارید، در جلسه اول با هم بیرونش میآوریم و بعد درباره معماری حرف میزنیم.