نوشته های javadalipanah

کیفیت سرویس‌دهی؛ چگونه نجوا را بهبود دادیم؟

javadalipanah — Sat, 31 Jul 2021 14:57:19 +0430

شاید بسیاری از شما با اصطلاح SLA یا توافقنامه‌ی سطح کیفیت خدمات آشنا باشید، اما این توافقنامه از کجا میاد؟ چه عواملی در اون دخیل هستن و نحوه‌ی محاسبه‌اش به چه صورته؟ در این نوشتار سعی می‌کنیم به سوالاتی از این دست با چندتا مثال عملی جواب بدیم. ضمنا لازم به ذکره که مرجع بسیاری از مطالب این نوشتار کتاب SRE گوگل هست.سرواژه‌ی SRE مخفف Site Reliability Engineering هست. اگر بخوام به صورت نادقیق بگم SREها کسانی هستند که زیرساخت امن، پایدار و قابل اتکا ارائه می‌دن و وظیفه‌ی ایجاد فرآیندهای اتوماتیک برای کارهای پرتکرار رو دارن.نجوا یک سرویس ارسال پوش نوتیفیکیشن و ایمیل مارکتینگ هست که روزانه میلیون‌ها پوش نوتیفیکیشن ارسال می‌کنه. مدتی بود که ما متوجه شده بودیم که این سرویس اون‌طوری که انتظار داریم کار نمی‌کنه و دنبال بهبود اون بودیم ولی نمی‌دونستیم که باید از کجا شروع کنیم و معیارهای ما برای کیفیت سرویس‌دهی باید چی باشه. معیارهای زیادی بود که می‌شد با استفاده از اون‌ها کیفیت سرویس‌دهی رو اندازه‌گیری کرد اما ما تصمیم گرفتیم که خودمون رو جای مشتری‌های این سرویس بذاریم و از دید اون‌ها به قضیه نگاه کنیم. این شد که سوالات زیر رو از خودمون پرسیدیم:من به عنوان مشتری چه انتظاراتی از این سرویس دارم؟در صورت مشاهده‌ی چه رفتاری از این سرویس اعتماد من به اون کاهش پیدا می‌کنه؟من به عنوان مشتری سرویس تا چه حد خرابی/کارکرد ناصحیح سرویس رو می‌تونم تحمل کنم؟این سوالات و سوالاتی از این دست ما رو به سمت تعریف SLA یا «توافقنامه‌ی سطح کیفیت خدمات» سوق داد. در ادامه با بررسی موردی سرویس نجوا اصطلاحاتی رو توضیح خواهیم داد که به ما در تعریف SLA کمک کردند.شاخص‌های سرویس، SLIیک SLI شاخصی از سطح سرویس‌دهی است؛ به عبارت دیگر یک معیار عددی از یک جنبه‌ی خاص سطح سرویس‌دهی است. ها ای که گفتی یعنی چه؟بذارید با یک مثال توضیح بدم. فرض کنید شما یک وب‌سرور دارید که به درخواست‌های کاربرها پاسخ میده؛ تاخیر یا latency می‌تونه یک SLI برای سرویس شما باشه. همینطور میشه نسبت خطاهای سرور (5xx) به کل درخواست‌ها رو یه SLI مناسب برای سرویس در نظر گرفت.در حالت ایده‌آل یه SLI خوب به صورت مستقیم سطح سرویس مورد نظر رو اندازه میگیره ولی ممکنه گاهی معیار گفته شده قابل اندازه‌گیری نباشه. به عنوان مثال ایده‌آل این هست که تأخیر پاسخ از دید کاربر نهایی اندازه‌گیری بشه ولی این کار شدنی نیست؛ پس تأخیر پاسخ‌دهی در سرور به عنوان معیاری از تأخیر کل اندازه‌گیری میشه.پس ما باید یک سری SLI رو به عنوان معیار کیفیت سرویس نجوا معرفی می‌کردیم؛ پس از بررسی و ارزیابی جنبه‌های مختلف سرویس به SLIهای زیر رسیدیم:در دسترس بودن وب‌سرور (درصد خطای درخواست‌های رسیده به وب‌سرور)تأخیر وب‌سرورتأخیر در ارسال پوش نوتیفیکیشن‌های غیر VIPتأخیر در ارسال پوش نوتیفیکیشن‌های VIPاما هنوز یک جای کار می‌لنگید؛ چه میزان از در دسترس بودن سرویس، ایده‌آل مشتری‌های ما بود؟ مشتری‌های ما تا چه میزان تأخیر رو می‌تونستن تحمل بکنن؟ ما هنوز نیاز به تعریف مفاهیم بیشتری داشتیم. نیاز داشتیم که معیارهای گفته شده رو به صورت دقیق و عددی تعیین و محدود کنیم. این کار با استفاده از تعریف SLO انجام شد که در ادامه اون رو توضیح می‌دیم.اهداف سرویس، SLOیک SLO هدف معینی برای سطح سرویس‌دهی است. به عبارت دیگر مقدار یا بازه‌ای از مقادیر از سطح سرویس‌دهی است که توسط یک SLI اندازه‌گیری می‌شود.به عبارت دیگه میشه SLO رو به صورت "SLI <= value" یا "lower bound <= SLI <= upper bound" تعریف کرد. برای نمونه، مثال وب‌سرور رو در نظر بگیرید؛ اگر SLI ما میانگین تأخیر درخواست‌ها باشه میشه SLO رو به این صورت تعریف کرد که این میانگین کمتر از ۲۵۰ میلی‌ثانیه باشه.اما هدف از مشخص کردن SLO چیه؟ هدف اینه که کاربران اون سرویس بدونن که باید چه انتظاری از نحوه‌ی کارکرد اون سرویس داشته باشن. اگر SLO به صورت دقیق و مناسب تعیین بشه می‌تونه مانع از ایجاد انتظارات بیش از حد از سرویس بشه. به عنوان یک مثال جالب از چنین انتظاراتی میشه به سرویس Chubby اشاره کرد. Chubby یک سرویس توزیع‌شده‌ی مدیریت قفل (lock service) هست که توسط گوگل توسعه داده شده و هدفش مدیریت قفل برای منابع مختلف و نگهداری فایل‌هایی مثل تنظیمات سیستم‌های توزیع شده است. به مرور زمان گوگل مشاهده کرد که هر بار که Chubby دچار مشکل میشه سرویس‌های متعددی با اون دچار مشکل میشن! دلیل این اتفاق این بود که Chubby اینقدر به ندرت دچار اشکال می‌شد که همه فرض کرده بودن همیشه بالاست و هیچوقت دچار مشکل نمیشه و به مرور زمان وابستگی به اون زیاد شده بود. اما راه‌حلی که گوگل برای این موضوع داشت جالب بود:تیم SRE گوگل انتهای هر فصل در صورتی که Chubby در اون فصل دچار مشکل نشده بود عمدا سیستم رو پایین میاوردن (البته نه به اندازه‌ای که SLO نقض بشه) تا مطمئن بشن انتظارات بی‌جا راجع به در دسترس بودن همیشگی سیستم شکل نمی‌گیره. اینطوری کسانی که به Chubby وابسته بودن مجبور می‌شدن فکری به حال این سناریوی بعید ولی محتمل بکنن.اما ما برای سرویس نجوا چه SLOهایی تعیین کردیم؟ بعد از بررسی عملکرد سیستم به نظر رسید که SLOهای زیر برای این سیستم مناسب باشه:۹۹.۵٪ درخواست‌های رسیده به سرور بدون خطا پاسخ داده شوند. (غیر 5xx)۹۵٪ درخواست‌های رسیده به سرور زیر ۱ ثانیه جواب داده شوند.۹۹٪ نوتیفیکیشن‌های کاربران غیر VIP در کمتر از ۱ ساعت ارسال شوند.۹۵٪ نوتیفیکیشن‌های کاربران VIP زیر ۵ دقیقه ارسال شوند.شاید برای شما عجیب به نظر برسه که چرا این SLOها به صورت درصدی تعریف شدن؟ برای مثال چه اشکالی داشت که بگیم «میانگین زمان پاسخ به درخواست‌های رسیده به سرور زیر ۱ ثانیه باشد»؟اینجاست که باید درباره‌ی نحوه‌ی انتخاب شاخص‌ها کمی توضیح بدیم.نحوه‌ی انتخاب شاخص‌هاشاید وقتی که در بادی امر راجع به تأخیر صحبت می‌کنیم نحوه‌ی اندازه‌گیری واضح به نظر برسه: مدت‌زمانی که طول می‌کشه تا یک درخواست جواب داده بشه. اما راجع به سیستمی که در ثانیه چندین درخواست رو پاسخ میده چطور؟ آیا اندازه‌گیری همینقدر واضحه؟ چه معیاری باید انتخاب بشه؟ آیا میانگین تأخیر درخواست‌ها در یک ثانیه خوبه؟ میانگین در یک دقیقه چطور؟فرض کنید که میانگین تأخیر درخواست‌ها در هر دقیقه SLIای هست که ما اندازه می‌گیریم. فرض کنید وب‌سرور ما دو API فراهم می‌کنه که اولی میانگین تأخیر ۱۰ میلی‌ثانیه و دومی میانگین تأخیر ۵۰۰ میلی‌ثانیه داره. حالا برای راحتی کار فرض کنید که در هر دقیقه تعداد مساوی از دو نوع درخواست به وب‌سرور می‌رسه. پس میانگین تأخیر ما در هر دقیقه ۲۵۵ میلی‌ثانیه خواهد بود. اما آیا این عدد معیار خوبی از کندی سیستم ماست؟ فرض کنید که تمامی درخواست‌ها از وبسایتی میاد که کاربر به صورت مستقیم باهاش کار می‌کنه و صفحه‌ای لود نمیشه مگر اینکه هر دو API مذکور رو فراخوانی کنه. درسته که در این حالت هم میانگین پاسخ ما عملا ۲۵۵ میلی‌ثانیه‌اس ولی لود شدن یک صفحه برای کاربر در بهترین حالت ۵۰۰ میلی‌ثانیه طول خواهد کشید. از طرف دیگه تجربه نشون داده که کاربران سیستم کند رو به سیستمی که واریانس زیادی در زمان پاسخش وجود داره ترجیح میدن؛ پس ما باید دنبال معیاری باشیم که اثر این واریانس رو بهتر در خودش نشون بده.اینجاست که توصیه میشه به جای میانگین، توزیع آماری SLI مورد توجه قرار بگیره. برای مثال شکل زیر رو که از کتاب SRE گوگل برداشته شده رو مشاهده کنید:رنگ‌ها به ترتیب از پایین نماینده‌ی ۵۰٪، ۸۵٪، ۹۵٪ و ۹۹٪ از درخواست‌ها هستند.محور عمودی میزانی هست که یک درخواست طول کشیده (به میلی‌ثانیه) و محور افقی زمان رو نشون میده. رنگ‌ها هم از پایین به بالا به ترتیب نشون‌دهنده‌ی ۵۰ درصد اول، ۸۵ درصد اول، ۹۵ درصد اول و ۹۹ درصد اول درخواست‌ها از نظر زمان پاسخگویی هستند.همونطور که می‌بینید گرچه یک درخواست در حالت عادی ممکنه ۵۰ میلی‌ثانیه طول بکشه (توی ۵۰ درصد اول باشه) ولی درخواست‌هایی هستند که تا ۲۰ برابر کندترن!به این ترتیب با اندازه‌گیری بازه‌های درصدی مختلف می‌تونید شکل توزیع آماری شاخص موردنظرتون رو تخمین بزنید. برای مثال بازه‌ی ۹۹.۹٪ تا ۱۰۰٪ معیار خوبی از بدترین حالت برای شاخص موردنظره.حالا شاید برای شما واضح شده باشه که چرا هنگام تعریف SLOهای نجوا از عباراتی شبیه به «۹۹.۵٪ درخواست‌های رسیده به سرور بدون خطا پاسخ داده شوند. (غیر 5xx)» استفاده کردیم.در ادامه مختصرا SLA رو توضیح میدیم و در باقی این نوشتار به توضیح فنی نحوه‌ی اندازه‌گیری این شاخص‌ها می‌پردازیم.قرارداد سطح سرویس، SLAقرارداد سطح سرویس یا SLA قراردادی است که به صورت التزامی یا ضمنی با کاربران سرویس منعقد شده و شامل تبعات ارضا و یا عدم ارضای SLOهاست.این بخش به صورت خاص مربوط به بخش مالی و بیزنسی کسب و کار و سرویس هست. برای مثال ممکنه شما به صورت دقیق با کاربرانتون توافق کنید که اگر سرویس شما بیش از مدت معینی در دسترس نبود بهشون مبلغی رو به عنوان جریمه پرداخت کنید؛ البته SLA همیشه به صورت ضمنی تعریف نمی‌شه. برای مثال ممکنه شما هیچ قراردادی با کاربرانتون برای سرویسی که بهشون میدین امضا نکرده باشین اما سرویس شما اینقدر حیاتی باشه که حتی یک وقفه‌ی کوتاه در عملکرد اون به اعتبار شما صدمه بزنه و یا باعث بشه منبع درآمدی شما دچار مشکل بشه.اگر به مثال این نوشتار راجع به سرویس نجوا برگردیم می‌بینیم که ما SLOای تحت عبارت «۹۵٪ نوتیفیکیشن‌های کاربران VIP زیر ۵ دقیقه ارسال شوند» تعریف کردیم. اگر این SLO محقق نشه به اعتبار این سرویس لطمه می‌خوره چون کاربری که پول داده و نوتیفیکیشن VIP تعریف کرده انتظار داره که در کوتاه‌ترین زمان ممکن نوتیفیکیشن ارسال بشه.نحوه‌ی تعریف اهداف سرویسبرای تعریف هر SLO لازمه که گفته بشه چطور اندازه‌گیری شده و تحت چه شرایطی معتبر هست. برای مثال:باید ۹۹٪ از پاسخ درخواست‌های وب‌سرور زیر ۱۰۰ میلی‌ثانیه پاسخ داده شوند (میانگین تمامی سرورها که در بازه‌های ۱ دقیقه‌ای اندازه‌گیری شده است).تعریف ۱۰۰ درصدی یک هدف معمولا اشتباه و یک کار بی‌معنیه چون باعث میشه افراد از خطا دوری کنن و در نتیجه تعداد دیپلوی‌ها و خلاقیت افراد کاهش پیدا کنه. اینجاست که مفهوم بودجه‌ی خطا یا Error Budget مطرح میشه.بودجه‌ی خطا معیاری عددی از میزان اجازه داده شده برای هزینه‌کردن از SLO در بازه‌ی معین (روز، هفته یا ماه) است.فرآیند تعریف بودجه‌ی خطاپروداکت منیجر یا کسی که آشنایی کافی با کاربران سیستم و انتظارات اون‌ها داره یک عدد به عنوان میزانی از سالم بودن سرویس که انتظار داره ارائه می‌کنه.مدت زمان واقعی سالم بودن سرویس توسط سیستم مانیتورینگ اندازه‌گیری میشه.تفاوت دو عدد بالا میزان بودجه‌ی خطا رو مشخص می‌کنه؛ یعنی میزانی از خرابی که در سیستم قابل تحمله.تا زمانی که بودجه‌ی خطا صفر نشده دولوپرها اجازه دارند که کد جدید دیپلوی کنند.نحوه‌ی محاسبه‌ی شاخص‌های سرویساما ما چطور این متریک‌ها رو اندازه میگیریم؟ با استفاده از پرومتئوس! پرومتئوس یک ابزار رایگان و متن‌باز هست که برای مانیتورینگ و اطلاع‌رسانی (Alerting) استفاده میشه. این ابزار متریک‌ها رو به صورت real-time در یک دیتابیس سری‌زمانی ذخیره میشه و زبان جستجوی نسبتا ساده‌ای داره. برای اطلاعات بیشتر می‌تونید به اینجا مراجعه کنید.در ادامه به جزئیات محاسبه‌ی یکی از متریک‌ها به صورت نمونه می‌پردازیم.سرویس نجوا یک اندپوینت برای تیم SRE فراهم کرده که از طریق اون متریک‌های مربوط به تأخیر در ارسال نوتیفیکیشن‌ها رو به صورت هیستوگرام در اختیار ما می‌ذاره. اگر با تایپ متریک‌های پرومتئوس آشنا نیستید اینجا رو مطالعه کنید. اگر بخوام به صورت مختصر هیستوگرام رو تعریف کنم باید بگم:هیستوگرام یک نمایش تقریبی از توزیع داده‌ی عددی است. برای اطلاعات بیشتر به این صفحه‌ی ویکی‌پدیا مراجعه کنید.برای مثال در تصویر زیر می‌تونید نتیجه‌ی کوئری روی این متریک رو در سرویس نجوا مشاهده کنید:نتیجه‌ی جستجو روی هیستوگرام تأخیر در ارسال نوتیفیکیشن‌های نجواهمونطور که از تصویر می‌بینید هر خط یک سری برچسب تحت عنوان "le" داره. یعنی «کوچکتر یا مساوی». به زبان ساده هر خط بیان می‌کنه که در یک زمان خاص، چه تعداد از نوتیفیکیشن‌ها تأخیری کوچکتر یا مساوی یک عدد خاص داشتن. برای مثال:‌ خط سبز رنگ نشون میده که در ۱۱:۳۰ تعداد ۱۵۰ نوتیفیکیشن وجود داشته که تأخیری کوچکتر یا مساوی ۱۰ ثانیه داشتن. واضحه که هرچیزی که کوچکتر یا مساوی ۱۰ باشه کوچکتر یا مساوی ۱۰۰ هم هست پس خط "le: +inf" نمایانگر تمامی نوتیفیکیشن‌هاست.حالا ما از این متریک چطور برای محاسبه‌ی SLI استفاده می‌کنیم؟ اینجاست که باید کمی با زبان PromQL یا زبان جستجوی پرومتئوس آشنا باشید. برای اطلاعات بیشتر به این صفحه مراجعه کنید.برای محاسبه‌ی SLI از این متریک ابتدا افزایش هر باکت و افزایش کل رو در بازه‌ی ۳۰ روزه محاسبه می‌کنیم:- record: najva:notification_delay_bucket:increase30d expr: |- increase(najva_najva_notification_delay_bucket[30d]) - record: najva:notification_delay_counter:increase30d expr: |- increase(najva_najva_notification_delay_count[30d])و سپس نسبت این دو رو به هم حساب می‌کنیم:- record: najva:non_vip_wait_time_slo:ratio_rate30d expr: |- ( sum( najva:notification_delay_bucket:increase30d{le="3600.0", queue="1"} ) / sum( najva:notification_delay_counter:increase30d{queue="1"} ) ) * 100عدد ۳۶۰۰ به ثانیه (برابر با ۱ ساعت) و queue=1 بیانگر غیر VIP بودن نوتیفیکیشن هست. عدد نهایی درصد نوتیفیکیشن‌هایی رو نشون میده که کمتر از ۱ ساعت منتظر ارسال بودن.حالا برای محاسبه‌ی بودجه‌ی خطا کافیه که این مقدار رو از SLO کم کنیم (اگر یادتون نیست SLO برای این متریک برابر با ۹۹٪ تعریف شده بود) یعنی:najva:non_vip_wait_time_slo:ratio_rate30d - 99که برای این سرویس در ابتدا نتیجه به صورت زیر شد:بودجه‌ی خطای نجوا برای نوتیفیکیشن‌های غیر VIP در روزهای اول این نمودار نشون میده که در طول زمان بودجه‌ی خطای سرویس نجوا برای SLOی مورد نظر چقدر هست. یعنی چی؟ به زبان ساده یعنی اینکه چقدر دیگه حق داریم که از این SLO مایه بذاریم! توی نمودار بالا می‌بینید که این مقدار منفی هست. به عبارت دیگه اگر SLOی مورد نظر ۹۹٪ بوده باشه این نشون میده که حوالی ساعت ۲ ظهر در نمودار بالا ۹۹ منهای ۲ درصد از نوتیفیکیشن‌های غیر VIP ما کمتر از ۱ ساعت منتظر ارسال بودن. به عبارت دیگه ۳ درصد از نوتیفیکیشن‌ها زمانی بیش از این مقدار رو در انتظار ارسال سپری کردن.همونطور که می‌بینید این مقدار منفی هست که به این معنیه که از مقدار SLO تخطی شده ولی چون به تازگی SLO برای این سرویس تعریف شده بود این موضوع قابل انتظار بود. همینطور تأثیر تعریف SLO رو در نمودار بالا می‌بینید که دولوپرها به محض اینکه متوجه شدند که وضعیت خوبی از نظر تأخیر در ارسال نوتیفیکیشن ندارند اون رو اصلاح کردند و بودجه‌ی خطا در حال برگشت به مقدار بالای صفر هست.الان که در حال اعمال اصلاحات نهایی روی این نوشتار هستم بودجه‌ی خطای نجوا به شکل زیر در اومده:بودجه‌ی خطای نجوا برای نوتیفیکیشن‌های غیر VIP هنگام انتشار این نوشتار و بله! می‌بینید که نه تنها از SLO تخطی نشده بلکه بودجه‌ی خطا روند صعودی داره و دولوپرهای نجوا با خیال آسوده می‌تونن به توسعه‌ی قابلیت‌های جدید بپردازن! و این نتیجه‌ی مانیتورینگ صحیح و آگاهی از وضعیت سیستم هست.سخن آخرهمانطور که در این نوشتار دیدیم تعریف SLI و SLO برای سرویس اهمیت بالایی داره و باعث شفافیت انتظارات از سرویس میشه. یکی از وظایف ما در تیم SRE یکتانت ایجاد زیرساخت برای تعریف، محاسبه و مانیتورینگ SLOهاست. در صورتی که علاقه‌مندید تا با مسائلی از این دست دست و پنجه نرم کنید خوشحال میشیم سری به صفحه‌ی فرصت‌های شغلی ما بزنید.

آیینه‌ی اسکندر |‌ مفاهیم پیشرفته درباره‌ی اِستکِ اِلَستیک

javadalipanah — Fri, 17 Jul 2020 19:05:31 +0430

مقدمهاگر با استک الستیک آشنایی ندارید ابتدا خوندن این پست رو بهتون توصیه می‌کنم.این نوشتار از دو بخش تشکیل شده؛ در بخش اول «تجربه‌ی ما» از معماری استک قدیمی خودمون توی یکتانت صحبت می‌کنیم،‌ چالش‌هایی که داشت رو بررسی و معماری جدید رو معرفی می‌کنیم و در بخش دوم «بایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری!» یه سری نکات کلی راجع به استک الستیک رو مورد بررسی قرار می‌دیم که موقع بالا آوردن استک باید به اون‌ها توجه بشه.تجربه‌ی ماتصور کنید که به عنوان نیروی SRE توی یک شرکت استخدام شدید و اولین وظیفه‌ای که دارین اینه که استک قبلی شرکت رو به یک استک جدید منتقل کنید و کاری کنید که قابل اتکا باشه و بشه در مقیاس بالا ازش استفاده کرد؛ واکنشتون چیه؟ واکنش من:تصویر ۱ - واکنش من به اولین وظیفه‌ام من جواد علی‌پناه هستم. مدتیه که در شرکت یکتانت به عنوان نیروی SRE مشغول به کار شدم و قراره توی این نوشتار براتون از تجربیاتم روی استک الستیک و موارد مهم راجع به تنظیمات اون بگم. اگر هم براتون سوال یا ابهامی پیش اومد خوشحال می‌شم زیر این نوشته کامنت بذارید.معماری قدیمیوقتی من وارد یکتانت شدم دیدم که بعضی از تیم‌ها از استک الستیک استفاده می‌کنن؛ باقی تیم‌ها هم وسوسه شده بودن که سمتش بیان و جوّ غالب استفاده از امکانات جذاب این تکنولوژی بود. سؤالی که وجود داشت اما این بود که آیا معماری فعلی برای استفاده همه‌ی تیم‌ها مناسبه؟ مناسب به این معنی که ۱. تیم‌ها بدون درد و خون‌ریزی و در مدت زمان خیلی کم بتونن لاگ‌هایی که داشتن رو به الستیک بفرستن و ازش استفاده کنن ۲. استک موجود کشش اضافه شدن تیم‌ها رو داشته باشه ۳. تیم‌ها بتونن لاگ‌ها رو به هر فُرمتی بفرستن و در هر زمانی این فرمت بتونه تغییر کنه.برای اینکه یه دید کلی از معماری قدیمی داشته باشید تصویر ۲ رو نگاه کنید:تصویر ۲ - معماری قدیمیهمونطور که توی تصویر می‌بینید توی این معماری روی هر سرور یک نسخه فایل‌بیت وجود داره که فایل لاگ سرویس رو می‌خونه و اون رو به لاگ‌استش Forward می‌کنه؛ لاگی که به دست لاگ‌استش می‌رسه بدون ساختار هست پس لاگ‌استش باید اون رو Parse کنه و به فرمت JSON در بیاره و بعد برای الستیک‌سرچ بفرسته. در انتها کاربر از طریق کیبانا برای داده‌ها داشبورد می‌سازه و اون‌ها رو به صورت نمودار و چارت مشاهده می‌کنه.معماری جدید ؟سوال مهمی که ابتدای کار برای ما وجود داشت این بود که آیا به معماری جدیدی نیاز داریم یا نه؟معایب معماری قدیمی:اضافه کردن تیم جدید کار زمان‌بر و پرهزینه‌ای بود؛ چون به ازای هر تیم جدید باید تنظیمات لاگ‌استش رو تغییر می‌دادیم تا لاگ‌ها رو بگیره، به فرمت مناسبی برای الستیک‌سرچ تبدیل کنه و اون‌ها رو به الستیک‌سرچ تحویل بده. یک لاگ‌استش مرکزی به عنوان Parser و Forwarder وجود داشت که هم داده‌ها رو Parse می‌کرد و هم اون‌ها رو به الستیک‌سرچ می‌فرستاد؛ همچنین با توجه به مورد قبلی تغییرات در تنظیمات اون امری متداول و اجتناب ناپذیر بود و تبدیل به یه غول بزرگ داخل استک شده بود که همه چیز به اون وابسته بود.نزدیک به ۱۰۰٪ لاگ‌ها بدون ساختار (Unstructured) بودن و تغییر در فرمت اون‌ها به وفور اتفاق می‌افتاد.تعداد شاردها و ایندکس‌های الستیک‌سرچ به سرعت در حال افزایش بود و همین کارکرد سرویس رو به شدت تحت تأثیر می‌ذاشت.به صورت آزمایشی بالا اومده بود و بعضا تنظیمات اولیه‌ی نادرست موجب کاهش عملکرد و سخت‌تر شدن فرآیند نگهداری شده بود.برای موارد ۴ و ۵ که بهشون اشاره شد راهکار مناسب بدون تغییر معماری وجود داشت ولی موارد دیگه استفاده از سیستم فعلی رو با چالش مواجه کرده بود. این شد که من و تعدادی از دوستان مأمور تحقیق و توسعه‌ی یک معماری مناسب در زمان کوتاه شدیم...معماری جدید ✅برای اینکه این نوشتار طولانی نشه از پرداختن به فرآیند تصمیم‌گیری و گزینه‌های پیش‌رو صرف‌نظر می‌کنم و فقط تصمیماتی که برای حل معایب بالا گرفتیم رو می‌گم:برای این مورد تصمیم گرفتیم که تنظیمات پایپ‌لاین‌های لاگ‌استش رو قاعده‌مند کنیم. یعنی یک قالب مشخص برای همه‌ی اون‌ها داشته باشیم و فرآیند ساخت پایپ‌لاین رو اتوماتیک کنیم. برای اینکه این تنظیمات بلافاصله برای لاگ‌استش تعریف بشن از قابلیت Reload اتوماتیک لاگ‌استش استفاده کردیم. در حال حاضر ساخت یه پایپ‌لاین آماده که ورودی رو بگیره، روش فیلتر اعمال کنه و اون رو به الستیک‌سرچ بفرسته کمتر از ۳۰ ثانیه زمان می‌بره. می‌گین چطور؟ برای اینکار باید راه‌حلی برای معایب ۲ و ۳ پیدا می‌کردیم...اصلا چرا باید تغییر در فرمت لاگ تا مرحله‌ی تنظیمات پایپ‌لاین منتشر می‌شد؟ دلیلش این بود که لاگ‌استش در معماری قدیمی بیش از حد بزرگ شده بود و هم Parser بود و هم Forwarder. چی می‌شد اگر می‌تونستیم قسمت عمده‌ی فرآیند Parse کردن رو از دل لاگ‌استش بیرون بکشیم و ببریم جایی که باید؟ یعنی همونجایی که لاگ‌ها ازش میان!برای این کار ما چندین گزینه داشتیم:گزینه‌ی اول این بود که چرا اصلا سرویس‌ها بدون ساختار لاگ کنن؟ بیاین کاری کنیم که هر سرویس در یک فرمت استاندارد و ساختارمند لاگش رو بنویسه! واکنش همه‌ی تیم‌ها:تصویر ۳ - واکنش تیم‌ها به پیشنهاد ساختارمند کردن لاگ‌هاشونکه پُرواضحه یعنی نه! :) گزینه‌ی دوم این بود که تیم‌ها با همون فرمت قبلی لاگ کنن اما ما لاگ ‌ساختارمند توی لاگ‌استش دریافت کنیم. چطوری؟ با Parser/Forwarderهای محلی (کنار خود سرویس). از بین همه‌ی گزینه‌ها ما تصمیم گرفتیم فلوئنت‌بیت رو به استک‌مون اضافه کنیم چون خیلی Lightweight و سریعه، تنظیمات راحت و سرراستی داره، میشه براش پایپ‌لاین تعریف کرد و از منابع متعدد لاگ‌های متفاوت با فرمت‌های مختلف رو پارس کرد و جدای از همه‌ی این‌ها پلاگین‌های متعددی رو هم پشتیبانی می‌کنه که دقیقا مناسب کار ما بود.ما همین گزینه رو انتخاب کردیم و با همین تصمیم به چندین دستاورد مهم رسیدیم:- بار خیلی زیادی از روی دوش لاگ‌استش برداشته می‌شد. (Parse کردن و ساختار دادن)- می‌شد فرمت مشترکی برای پایپ‌لاین‌های مختلف در آورد.- تغییر فرمت لاگ یک سرویس فقط تا فلوئنت‌بیت منتشر می‌شد و نیازی به تغییر در جاهای دیگه نداشت.۳. با تصمیمی که برای حل مشکل دوم گرفتیم این مشکل هم خودبخود حل شد و معماری جدید ما به شکل زیر در اومد:تصویر ۴ - معماری جدید سیستم مرکزی Log Managementراه‌حل‌های پیشنهادی برای موارد ۴ و ۵ توی بخش «بایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری!» اومده. سوالاتی درباره‌ی معماری جدیدآن کس که بداند و بداند که بدانداسب خرد از گنبد گردون بجهاندبا در نظر گرفتن این بیت، بهتره که همیشه تا جایی که میشه از خودمون سوال بپرسیم، به ایرادات خودمون واقف باشیم و در آینده در صدد اصلاح اونا بربیایم یا حدأقل اثر منفی اون‌ها رو کمینه کنیم.ایراداتی که به معماری جدید وارده به صورت تیتروار:چرا هنوز لاگ‌استش توی این معماری وجود داره؟ فلوئنت‌بیت می‌تونه مستقیما به الستیک‌سرچ متصل بشه. وجود لاگ‌استش با توجه به اینکه فلوئنت‌بیت تقریبا تمامی نیازهای ما رو برآورده می‌کنه فقط پیچیدگی به سیستم اضافه می‌کنه. چرا مکانیزم بافرینگ درستی دیده نشده؟ در مواقعی که بار (Load) سیستم بالاست و یا مشکلی توی استک ایجاد می‌شه ممکنه قسمتی از داده از دست بره.برای مدیریت پایپ‌لاین‌های لاگ‌استش یک API اختصاصی توسعه داده شده در حالی که می‌شد از نسخه‌ی پولی الستیک استفاده کرد که خودش APIهایی برای مدیریت پایپ‌لاین در اختیار می‌ذاره. چرا این کار انجام نشده؟چرا هنوز سیستم‌هایی وجود دارند که به فلوئنت‌بیت مهاجرت نکردن؟ چه محدودیتی وجود داشت که این پروسه برای اون‌ها هم تکرار نشد؟هیچوقت کار روی یک سیستم زیرساختی تموم نمیشه. حتی اگر در اون تغییری هم ایجاد نکنید همیشه باید حواستون به دسترس‌پذیری (Availability)، اتکاپذیر بودن و امن بودن اون باشه. ما هم با در نظر گرفتن این موارد به مرور به رفع ایرادات می‌پردازیم و اگر نکته‌ی جالب‌توجهی وجود داشت حتما در آینده پست‌های بیشتری در این باره منتشر می‌کنیم.پاسخ به این سؤالات به صورت خلاصه:سرویس‌هایی وجود دارند که هنوز به معماری جدید مهاجرت نکردن و پایپ‌لاین اختصاصی خودشون رو دارن.برای این مورد گزینه‌ی اضافه کردن کافکا به استک پیش‌بینی شده که در آینده انجام میشه.توسعه‌ی این API چندان زمان‌بر نبود ولی در صورتی که نیاز حس بشه ممکنه در آینده به سمت خرید License بریم.این سرویس‌ها از قابلیت‌هایی در لاگ‌استش استفاده می‌کردن که یا در فلوئنت‌بیت قابل انجام نیست و یا محیط اجراشون به صورتی بوده که قابلیت اضافه کردن فلوئنت‌بیت به اون محیط وجود نداشته و یا پرهزینه بوده؛ گرچه ما هنوز دنبال راه‌حلی هستیم که تمامی سرویس‌ها از فلوئنت‌بیت استفاده کنن تا معماری یکپارچه‌ای داشته باشیم.در نهایت معماری‌ای که مد نظر ماست و باید بهش برسیم مطابق تصویر ۵ خواهد بود:تصویر ۵ - معماری‌ای که می‌خوایم بهش برسیمبایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری! توی این بخش از کلی‌ترین بایدها و نبایدها شروع می‌کنم و به مرور وارد نکات جزئی توی تنظیمات ELK می‌شم. پُرواضحه که همه چیز را همگان دانند؛ فلذا اگر چیزی رو از قلم انداختم، که حتما انداختم، خوشحال می‌شم که زیر همین پست اون‌ها رو با من به اشتراک بذارید.مشکل Split Brainقبل از اینکه به توضیح این مشکل بپردازم باید بدونید که الستیک‌سرچ به صورت کلاستر استفاده می‌شه که از ۱ یا بیشتر الستیک‌سرچ تشکیل شده. این کلاستر یک مستر (Master) داره که وظایف مشخصی از قبیل ساخت و حذف ایندکس‌ها، تخصیص شارد و ... رو انجام می‌ده.مستر از طریق مکانیزم رأی‌گیری انتخاب میشه و نودهایی (Node) که واجد شرایط (master eligible) هستن می‌تونن توی فرآیند رأی‌گیری شرکت کنن و اون رو انتخاب کنن. حالا فرض کنید که دوتا نود واجد شرایط دارید: A و B؛ و A به عنوان مستر انتخاب شده. یک لحظه ارتباط بین این دوتا دچار اختلال میشه؛ توی چنین شرایطی هر نود خودش رو تنها عضو کلاستر می‌بینه و خودش رو به عنوان مستر انتخاب می‌کنه و وظایف مستر رو به عهده می‌گیره. این اتفاق باعث میشه که شما دوتا مستر داشته باشید و تمامی کارهایی که باید یک مستر مجزا انجام می‌داد در دو جا انجام می‌شن و ممکنه ناسازگاری توی کلاستر بروز کنه. برای مثال توی تصویر ۶ می‌بینید که نود B بعد از Split Brain شارد کپی (Replica) رو شارد اصلی (Primary) در نظر گرفته.تصویر ۶ - قبل و بعد از Split Brainبرای حل این مشکل چیکار میشه کرد؟خبر خوب! توی ورژن‌های جدید الستیک‌سرچ یعنی ۷ به بعد این مشکل پیش نمیاد. اینجا یه پست خیلی جالب از خود الستیک هست که توضیح داده چطور این مشکل رو رفع کردن. البته همیشه توصیه می‌شه که تعداد نودهای واجد شرایطتون فرد باشه تا تعداد رأی‌ها مساوی نشه و بشه تصمیم‌گیری کرد.اگر به هر دلیلی از ورژن‌های قبلی استفاده می‌کنید باید علاوه بر فرد بودن تعداد نودها مقدار discovery.zen.minimum_master_nodes رو برابر با e/2 + 1 بذارید که e تعداد کل نودهای واجد شرایطه. این مقدار میگه که حتما نصف بعلاوه یک از تعداد کل نودهای واجد شرایط باید حضور داشته باشن تا بشه فرآیند انتخاب مستر رو انجام داد. پس اگر کلاستر شما دو تیکه بشه، فقط توی بخش بزرگ‌تر مستر انتخاب میشه.تنظیمات حافظهزمان اجرای الستیک‌سرچ شما باید مقدار حدأقل و حدأکثر RAMی که استفاده می‌کنید رو به JVM اعلام کنید. البته این فقط مربوط به استفاده از فضای Heap مربوط به JVM هست و نود شما مقدار بیشتری رو مصرف خواهد کرد. همه جا توصیه شده که این مقادیر رو یکسان و کمتر از ۳۲ گیگابایت مقداردهی کنید؛ ولی چرا؟نکته اینجاست که الستیک‌سرچ زمان اجرا سعی می‌کنه تمامی Heapای که بهش اختصاص داده شده رو از سیستم‌عامل بگیره و اون رو قفل کنه (برای اطلاعات بیشتر راجع به قفل کردن فضای آدرس مجازی اینجا رو ببینید). اگر شما مقادیر -Xms و -Xmx که به ترتیب حدأقل و حدأکثر رو مشخص می‌کنن یکسان نذارید باعث میشه که نود شما نتونه تمامی فضای Heapش رو قفل کنه، پس بنا به شرایط تعدادی از صفحات حافظه‌اش Swap میشن، فرآیند Gorbage Collection به شدت طولانی میشه و در کل عملکرد سیستم افت می‌کنه.حالا چرا زیر ۳۲ گیگابایت؟ در واقع اگر بخوام دقیق‌تر بگم این مقدار آستانه‌ی Compressed oops روی سیستم شماست (برای اطلاعات بیشتر راجع به Compressed oops اینجا کلیک کنید). فرض کنید شما میزان RAM رو کمی بالاتر از این آستانه گذاشته باشید؛ در این حالت مقدار رم قابل استفاده برای الستیک‌سرچ کمتر از حالتیه که مقدار RAM رو کمی پایین‌تر از آستانه ست کرده باشید. جالبه نه؟ برای اطلاعات بیشتر اینجا رو ببینید.اگر سروری دارید که منابع زیادی داره، توصیه میشه که به جای یک الستیک‌سرچ با RAM خیلی زیاد چندین نود با مقدار RAMی حدود ۳۰ گیگابایت روش بالا بیارید.تعداد شارد و تعداد ایندکسفرض من اینه که مخاطب این نوشته با مفاهیم کلاستر، ایندکس و شارد توی الستیک‌سرچ آشنایی داره؛ اگر با این مفاهیم آشنایی ندارید اینجا می‌تونه نقطه‌ی شروع خوبی باشه. همینطور تصاویر ۷ و ۸ می‌تونه یک دید کلی راجع به این مفاهیم بهتون بده.تصویر ۷ - شمای کلی کلاستر الستیک‌سرچتصویر ۸ - شمای کلی یک ایندکس روی یک نود الستیک‌سرچ۱. چندتا نود داشته باشم؟۲. چندتا ایندکس توی هر نود داشته باشم؟۳. چندتا شارد به ازای هر نود داشته باشم؟این‌ها سوالاتیه که هرکسی که سعی می‌کنه الستیک‌سرچ بالا بیاره حدأقل یه بار از خودش می‌پرسه. جواب این سوالات یه جمله‌اس:بستگی داره!و واقعا هم به خیلی چیزها بستگی داره. هیچ کس نمی‌تونه هیچ نسخه‌ی از پیش تعیین شده‌ای برای همه راجع به این سوالات بده ولی راه‌هایی هست که بتونید از طریق اون‌ها برای کارکرد مدنظر خودتون جواب درستی به این سوالات بدید. یکی از متدلوژی‌هایی که می‌شه استفاده کرد توی این لینک قابل مشاهده است.برای مثال توی استفاده‌ای که ما داشتیم به نظر می‌رسه تا مدت زیادی ۳ نود الستیک‌سرچ با ۱ شارد اصلی (Primary) و ۱ الی ۲ شارد کپی (Replica) به ازای هر ایندکس کافی باشه. اما برای مقایسه نت‌فلیکس از کلاستری با ۲۵۰ نود استفاده می‌کنه. پس واقعا بستگی داره!تنها نکته‌ای که باید توجه کنید اینه که در هر نود تعداد شاردها از ۲۰تا به ازای هر گیگابایت RAMی که به الستیک‌سرچ اختصاص دادید بیشتر نشه و سایز هر ایندکس هم کمتر از چیزی حدود ۵۰گیگابایت باشه تا جستجوهای شما در زمان معقول پاسخ داده بشن. در حالت کلی شاردهای کم‌حجم با تعداد زیاد باعث کند شدن عملیات Recovery، ایندکس کردن و عملکرد کلی الستیک‌سرچ میشه و شاردهای حجیم هم به شدت روی زمان جستجوی شما تأثیر منفی می‌ذاره.اگر در کارکرد شما جستجو بیشتر اتفاق می‌افته (Read Heavy)‌ توصیه می‌شه که تعداد کپی بیشتری به ازای هر شارد داشته باشید تا عملیات جستجو سریعتر باشه ولی اگر بیشتر نوشتن و ایندکس کردن اتفاق می‌افته (Write Heavy) تعداد کپی بیشتر به معنی لود بیشتر روی استک برای پخش کردن این کپی‌ها بین نودهای شماست.سخن آخرایجاد یک سرویس امن،‌ اتکاپذیر و همیشه در دسترس کاری سخت، زمان‌بر و نیازمند دانش کافی از اون سیستم و تحقیق و توسعه‌ی مداومه. کاری که در تیم SRE یکتانت در حال انجامش هستیم و داریم یک راه طولانی، پر از چالش و جذاب رو طی می‌کنیم. اگر فکر می‌کنید که این مسائل برای شما جذابه و دوست دارید در این راه کنار ما باشید حتما به صفحه‌ی فرصت‌های شغلی ما سر بزنید.

خواننده‌ای که شعر می‌سرود یا شاعری که می‌خواند؟

javadalipanah — Mon, 01 Apr 2019 04:09:38 +0430

به راستی لئونارد کوهن خواننده‌ای بود که شعر می‌سرود یا شاعری بود که می‌خواند؟مقدمه:تا امروز نمی‌دانستم چطور به این سوال پاسخ دهم اما پس از شنیدن ترانه‌ی «Here It Is» پاسخ مناسبی پیدا کردم. این ترانه یکی از ده ترانه‌ی آلبومی با نام «ده ترانه‌ی جدید» است.کاور آلبوم ده ترانه جدیدچیزی که راجع به این ترانه نظر مرا جلب کرد شعر آن است؛ این شعر یکی از معنوی‌ترین، مذهبی‌ترین، انسانی‌ترین و زیباترین اشعاری است که شنیده‌ام. جالب آن که از نظر ساختار شاهد چیزی شبیه به ترجیع‌بند در انگلیسی هستیم که پس از هر دو قطعه یک قطعه عینا تکرار شده است.کمی پیش‌زمینه راجع به کوهن:کوهن یکی از پیروان مکتب «ذِن» (Zen) بود. از ویژگی‌های این مکتب تفکر در هر آن، ژرف‌نگری و نیز بیان تعالیم به صورت تناقض میان دو چیز است؛ لذا جای تعجب ندارد که کوهن در این شعر در هر بند (شامل سه قطعه) دو قطعه شامل دو چیز متضاد و سپس یک ترجیع‌بند راجع به تفکرِ در لحظه آورده باشد.بررسی بندها و قطعات:در هر قطعه (به جز قطعات هفتم و هشتم) شاهد کلمه‌ی عشق در سومین بند هستیم؛ چنانکه گویی هر قطعه اشاره به یکی از راه‌های عشق‌ورزی دارد. در طول کل ترانه فردی عبارت Here It Is را تکرار می‌کند. راجع به این که این فرد کیست می‌توان چندین نظر ارائه کرد؛ اما به نظر من این صدا از جانب خداست.بند اول، روح و جسم:در قطعه‌ی اول از تاج، مهر و حلقه صحبت می‌شود؛ به نظر من این‌ها نماد معنویات وجود انسان است که باعث می‌شود او پادشاه باشد؛ پس به این ترتیب گاری (Cart) در قطعه‌ی دوم به بدن انسان اشاره دارد که با مقوا و ادرار (نفسانیات) همراه است. بند دوم، عشق آسمانی و عشق زمینی:شراب در قطعه‌ی چهارم می‌تواند نمادی از عشق آسمانی باشد که مستی روحانی به دنبال دارد. در قطعه‌ی پنجم به آلودگی انسان و عشق آسمانی او به عشق زمینی اشاره شده (Sickness) زیرا عشق زمینی انسان را از عشق اصلی دور می‌کند.بند سوم، دختر و پسر، شب و روز، فصل و وصل:در قطعات هفتم و هشتم به فصل و وصل ناشی از مرگ اشاره می‌شود؛ شبی که با مرگ در قلب فرزند پسر شروع شده و طلوعی که با مرگ در قلب فرزند دختر به وقوع می‌پیوندد. بند چهارم، فرآیند و نتیجه، سعادت و شقاوت:قطعه‌ی دهم به شتاب انسان در طول زندگی برای دستیابی به خواسته‌هایش اشاره می‌کند. زندگی غیر از این شتاب و دویدن نیست و تمام زندگی بر روی این شتاب بنا شده است. قطعه‌ی یازدهم بدون در نظر گرفتن ترجیع‌بند، شاه‌بیت این شعر است.ابتدا باید اشاره کرد که یکی از معانی فعل list کج شدن و خم شدن است؛ حال این صحنه‌ی تصلیب را می‌توان چنین توصیف کرد: خواسته‌هایی که در قطعه‌ی قبل ذکر آن رفت، ما را به صوی تصلیب نهایی می‌کشاند. عشقی که به هر سو که بخواهد خم می‌شود به این معناست که اعمال ما سرنوشت ما را تعیین می‌کند؛ سعادت یا شقاوت.و در انتها:حال به ترجیع‌بند و عبارت Here It Is بپردازیم:ترجیع‌بند چنین بیان می‌کند که همه‌ی ما در هر لحظه می‌توانیم زندگی کنیم و یا بمیریم (سعادت و شقاوت) و چنین است که به عشق خواهیم رسید و یا از آن رو گردان خواهیم شد...انتخاب شما همین الان است. همین لحظه. زندگی یا مرگ؟ سعادت یا شقاوت؟به راستی که کوهن شاعری است که می‌خواند...منابع:1. The poetry of Ten New Songs2. What is Zen? | ZEN BUDDHISM3. What Is Zen? - Zen Studiesمتن شعر به انگلیسی:Here is your crownAnd your seal and ringsAnd here is your loveFor all things.Here is your cart,And your cardboard and pissAnd here is your loveFor all of this.May everyone live,And may everyone die.Hello, my love,And my love, Goodbye.Here is your wine,And your drunken fallAnd here is your love.Your love for it all.Here is your sickness.Your bed and your panAnd here is your loveFor the woman, the man.May everyone live,And may everyone die.Hello, my love,And, my love, Goodbye.And here is the night,The night has begunAnd here is your deathIn the heart of your son.And here is the dawn,(Until death do us part)And here is your death,In your daughter's heart.May everyone live,And may everyone die.Hello, my love,And, my love, Goodbye.And here you are hurried,And here you are goneAnd here is the love,That it's all built upon.Here is your cross,Your nails and your hillAnd here is your love,That lists where it willMay everyone live,And may everyone die.Hello, my love,And my love, Goodbye.Songwriters: Leonard Cohen / Sharon Robinson