شرکت ما در مالزی از حدود 26 سال پیش فقط و فقط روی محاسبات مالیاتی در غالب نرم افزار تمرکز کرده و به دلیل هوش و مقاومت شخصی موجود در شخصیت صاحب شرکت که یک مرد 51 ساله نیوزلندی است ، تقریبا این شرکت پرچمدار بی رقیب عرصه کاری خود است. به عنوان مثال ، شرکت اینتل آمریکا نرم افزار همه شرکتها را رد کرد و سیستم ما را خرید.
اگر پستهای قبلی من را در مورد شرکت خوانده باشید، تا حدودی مطلع هستید که دیتاهای شرکت ما مانند حسابداری نیست که سال مالی را ببندیم و فقط بخشی از داده ها در یک دیتابیس جدید تجمیع شود و دیتابیس تا حدودی سبک شود. دیتاهای هر مشتری برای 7 سال تقریبا Transactionalحساب میشه و به قول معروف Archive نمی شود کرد پس با حجم بالایی از دیتا روبرو هستیم.
مساله بعدی ماهیت SaaS بودن سیستم است که سبب میشود از همه طرف سیستم محدودیت خاصی برای مشتری ایجاد نکند و هر مشتری نهایتا با دادن هزینه میتواند N مشتری برای محاسبات مالیاتی به سیستم وارد کند که به آنها TaxPayer گفته میشود. پس شما با ممکن است به یک مشتری گنده برخورد کنید که 50000 مشتری دارد و بعد از لاگین باید TaxPayerانتخاب شود و همه محاسبات سیستم برای این TaxPayer انتخاب شده انجام خواهد شد.
مساله بعدی دارائیهای فیزیکی مشتری است که به آنها Assetگفته می شود. این مشابه دارائیهای است که در ایران برچسب اموال میزنیم و ثبت میشود. 50000 TaxPayerبالا را باز به یاد بیاورید ، هر کدام ممکن است 200000 دارایی داشته باشد که تازه به دلیل شکل محاسبات مالیاتی ، هر کدام میتواند سبب داشتن اقلن 50 رکورد جدا درون سیستم شود. به عنوان مثال مبحثی در محاسبات مالیاتی داریم به نام Dispose که می تواند Partial Dispose هم داشت و این یعنی مثلن یک Assetمیتواند طی 20 تحرک جدا در سالهای مختلف Dispose شود و این سبب میشود هم رکوردها زیاد شود و هم به اطلاعات سالهای قبل هم نیاز باشد تا در محاسبات معلوم شود چقدر آن Dispose شده و ....
قصه بعدی این است که هر سال میتواند به زیر سالهایی تحت عنوان تقسیم شود که Version نامیده میشه و در هنگام ایجاد ورژن جدید کلیه اطلاعات ورژن قبلی به ورژن جدید منتقل میشه و این هم سبب میشه دیتابیس به شدت بزرگ شود.
حتی تعداد فرمها و بدنه فرمهای سیستم ما هم از سمت اداره مالیات ممکن است تغییر کند، لذا همه اینها هم درون دیتابیس ذخیره خواهد شد و این هم یعنی دیتای بیشتر برای هر سال درون دیتابیس به اضافه Query های بیشتر.
خوب حالا شرکت ما از سال 2011 تقریبا وقتی که سر و کله آژور پیدا شده، دیتاها رو به دلیل ترس از نابودی دیتا در SQL Azure نگه داشته و تا 2 سال پیش هم از Azure Service برای هاست کردن خود سیستم استفاده میکرد.
شایان ذکر است که پس از ورود من سیستم با NO-SQL هم درگیر شد که سبب یک Performance Improvement بزرگ شد ولی چون Azure بجز CosMosDB که یک NOSQLبسیار گران است چیز دیگری ندارد و ما در حال استفاده از Redis و MongoDB در بستر Digital Oceanهستیم و این یعنی اندکی Latency ولی خوب مهم نیست ، اوکی است.
نکته : قیمت سرورهای Digital Oceanتقریبا 70 برابر از CosMosDBارزانتر و از نظر Resource هم اقلن 500 بار قوی تر است.
حدود 2 سال پیش فریاد مشتریها به دلیل سرعت پایین سیستم بالا می رفت و در کنار آن Azure Service شدیدن درگیر میشد و همه Diagram ها به 100 درصد میچسبید و کلن فلج میشدیم. اینجا بود که از برادارن ماکروسافت مشورت خواستیم و عملن هیچ کار مثبتی انجام نشد. با داد و فریادهای من مدیریت شرکت یک سرور Xeon با 64 گیگ رم گرفت و من کارهاش رو کردم و از آن روز صدای مشتری کلن قطع شد. سیستم را روی یک سرور Dedicatedهاست کردیم و از شر Azure Service راحت شدیم.
حال اجازه دهید برویم و سری به SQL Azureبزنیم. هر بار که این دیاگرام که DTU (یک نوع واحد محاسباتی در آژور) را به سمت 100 درصد رفته نشان دهد ، فریاد مشتری بالا میرود.
مشکلی که هست این که است ملاک خاصی برای اینکه چرا بالا میرود وجود ندارد. حالا به تصویر زیر دقت کنید
این Pricing Tier را ببینید. هزینه این Plan که S2 است اندازه یک سرور کامل در مثلن Digital ocean است و برادر عزیز ماکروسافت رسمن میگوید تا وقتی که زیر پلن S4 هستید ، جوابگویی خاصی از طرف ماکروسافت وجود ندارد و یک جور Development Plan است و شما فقط در حال استفاده از بخشی از یک Core یک CPUهستید.
به محض بالا رفتن DTU Level کاهش سرعت تحرکات روی دیتابیس شروع میشه و Dead Lock ها آغاز میشه.
حالا باید گزارشهای شرکت ما را هم ببینید، بعضی 600 صفحه PDFمیشود و مشتری در دوران Peak Period شدیدن دیتا عوض میکند و گزارش میگیرد. اینجاهاست که DTU از 100 هم میزند بالا و سیستم برای آن مشتری فلج میشود و تنها پیشنهاد ماکروسافت تغییر Plan و پرداخت بیشتر و بیشتر پول است.
نکته : حتی شما در Azure نمیتوانید به سادگی و مجانی SQL Profilerداشته باشید !. خوب چطوری ببینم الان روی این دیتابیس چه خبر است ؟!.
نکته 2 : برای صحبت در مورد پلنها، رفرنس ماکروسافت موجود است
نکته 3 : 4 ساعت رفتم از ایران DataBase Admin و Performace Tuner آوردم، 80 درصد تحرکاتی که بلد است یا روی Azureجواب نمیده یا روی پلنهای زیر S6 و این دیگه خیلی زور است
نکته 4 : Plan های زیر استاندارد، حتی مکانیزم Backupدرستی هم ندارند. این قانون Azure است
مساله بعدی این است که چون ما مشتری OnSite هم داریم، اگر چیزی اختصاصی در Azureاستفاده کنیم، برای مشتریهای OnSiteباید به فکر موردی خارج از Azure هم باشیم.
برای استفاده از ServiceBUS اگر دقت کرده باشید به پستهام در مورد RabbitMQ ، باز باید سرور جدا بگیرم چون AzureServiceBUS به شدت گران و محدود است
حالا قصد دارم یک Server Blade با مثلن 480 گیگ رم و N تا هسته سرور بگیرم و بدهمش کامل دست یک فرد حرفه ای تا دو تا سرور SQL و به تعداد کافی NO-SQL و Application Server و ServiceBUS و LoadBalancer و .... راه بندازه و Backup Mechanism ایجاد کنه و باز هم هزینه ماهانه اش اندازه هزینه پرداختی یکی از مشتریها هم برای Azureنیست و ضمنن چون Azureفعلی در سنگاپور است و باز هم کمی Latency داریم و این سرور را درون مالزی خراب شده خواهیم گرفت و همه چیز ساده تر خواهد بود.
ضمنن روال DevOps هم به شکلی که دوست داریم در Azure قابل پیاده سازی نیست. حالا این روند که ما انتخاب کردیم شاید درست یا غلط یا Custom باشد.
مساله بعدی کار با Docker در بستر Azure است که خود داستانی جدا است ولی خوب شدنی است
برای هر گونه سرویس تستی و فقط در جهت R&D هم باید پول بدهیم که مطلوب نیست
این یک توضیح کوتاه بود که دوستان بدانند ماها شامل ، من ، عرفان، پژمان، کریشنا و عایشا ، آقای کیگان با 30 سال سابقه برنامه نویسی و خانم Yeo به عنوان کسی که دهها سیستم بزرگ را در انگلیس و استرالیا پیاده سازی کرده، به علاوه دهها مشاور و .... که حتی از آمریکا و ... به ما مشورت میدهند، همه اینقدر هم گاو نیستیم که اگر میشد با Azureادامه داد، باز هم می رفتیم سرور میگرفتیم و خودمان را جر میدادیم.
باشد که پند گیریم......
