آج، Bitrix24 سروس میں سیکڑوں گیگا بٹس ٹریفک نہیں ہے، اور نہ ہی اس کے پاس سرورز کا ایک بہت بڑا بیڑا ہے (حالانکہ، یقیناً، بہت سے موجود ہیں)۔ لیکن بہت سے کلائنٹس کے لیے یہ کمپنی میں کام کرنے کا اہم ذریعہ ہے؛ یہ ایک حقیقی کاروبار کے لیے اہم ایپلی کیشن ہے۔ لہذا، گرنے کا کوئی راستہ نہیں ہے. کیا ہوگا اگر حادثہ ہو جائے، لیکن سروس اتنی جلدی "بازیافت" ہو گئی کہ کسی نے کچھ محسوس نہیں کیا؟ اور کام کے معیار اور کلائنٹس کی تعداد کو کھوئے بغیر فیل اوور کو لاگو کرنا کیسے ممکن ہے؟ Bitrix24 میں کلاؤڈ سروسز کے ڈائریکٹر، الیگزینڈر ڈیمیدوف نے ہمارے بلاگ کے لیے بات کی کہ پروڈکٹ کے وجود کے 7 سالوں میں ریزرویشن سسٹم کس طرح تیار ہوا ہے۔
"ہم نے 24 سال پہلے Bitrix7 کو SaaS کے طور پر شروع کیا تھا۔ بنیادی مشکل شاید درج ذیل تھی: اس سے پہلے کہ اسے SaaS کے طور پر عوامی طور پر لانچ کیا گیا تھا، یہ پروڈکٹ محض ایک باکسڈ حل کی شکل میں موجود تھی۔ کلائنٹس نے اسے ہم سے خریدا، اپنے سرورز پر اس کی میزبانی کی، ایک کارپوریٹ پورٹل قائم کیا - ملازمین کے مواصلات، فائل اسٹوریج، ٹاسک مینجمنٹ، CRM کے لیے ایک عمومی حل، بس۔ اور 2012 تک، ہم نے فیصلہ کیا کہ ہم اسے SaaS کے طور پر شروع کرنا چاہتے ہیں، خود اس کا انتظام کرتے ہوئے، غلطی کو برداشت کرنے اور قابل اعتماد کو یقینی بنانا چاہتے ہیں۔ ہم نے راستے میں تجربہ حاصل کیا، کیونکہ اس وقت تک ہمارے پاس یہ نہیں تھا - ہم صرف سافٹ ویئر بنانے والے تھے، سروس فراہم کرنے والے نہیں۔
سروس شروع کرتے وقت، ہم نے سمجھا کہ سب سے اہم بات یہ ہے کہ غلطی کی برداشت، قابل اعتماد اور سروس کی مستقل دستیابی کو یقینی بنایا جائے، کیونکہ اگر آپ کے پاس ایک عام عام ویب سائٹ ہے، مثال کے طور پر، ایک اسٹور، اور یہ آپ پر گرتا ہے اور وہاں بیٹھتا ہے۔ ایک گھنٹہ، صرف آپ کو تکلیف ہوتی ہے، آپ آرڈر کھو دیتے ہیں، آپ اپنے گاہکوں کو کھو دیتے ہیں، لیکن خود آپ کے مؤکل کے لیے، یہ اس کے لیے بہت اہم نہیں ہے۔ وہ یقیناً پریشان تھا، لیکن اس نے جا کر اسے دوسری سائٹ پر خرید لیا۔ اور اگر یہ ایک ایسی ایپلی کیشن ہے جس پر کمپنی کے اندر تمام کام، کمیونیکیشنز، فیصلے بندھے ہوئے ہیں، تو سب سے اہم چیز صارفین کا اعتماد حاصل کرنا ہے، یعنی انہیں مایوس نہ کرنا اور نہ گرنا۔ کیونکہ اگر اندر کی کوئی چیز کام نہ کرے تو سارے کام رک سکتے ہیں۔
Bitrix.24 بطور ساس
ہم نے پہلا پروٹو ٹائپ عوامی لانچ سے ایک سال پہلے 2011 میں اسمبل کیا۔ ہم نے اسے تقریباً ایک ہفتے میں اکٹھا کیا، اسے دیکھا، اسے گھمایا - یہ کام کر رہا تھا۔ یعنی، آپ فارم میں جا سکتے ہیں، وہاں پورٹل کا نام درج کریں، ایک نیا پورٹل کھل جائے گا، اور صارف کی بنیاد بن جائے گی۔ ہم نے اسے دیکھا، اصولی طور پر پروڈکٹ کا اندازہ لگایا، اسے ختم کر دیا، اور پورے سال تک اسے بہتر کرتے رہے۔ کیونکہ ہمارے پاس ایک بڑا کام تھا: ہم دو مختلف کوڈ بیس نہیں بنانا چاہتے تھے، ہم ایک الگ پیکڈ پروڈکٹ، الگ کلاؤڈ حل کی حمایت نہیں کرنا چاہتے تھے - ہم یہ سب ایک کوڈ میں کرنا چاہتے تھے۔
اس زمانے میں ایک عام ویب ایپلیکیشن ایک سرور تھا جس پر کچھ پی ایچ پی کوڈ چلتا تھا، ایک mysql ڈیٹابیس، فائلیں اپ لوڈ کی جاتی ہیں، دستاویزات، تصاویر اپ لوڈ فولڈر میں ڈالی جاتی ہیں - ٹھیک ہے، یہ سب کام کرتا ہے۔ افسوس، اس کا استعمال کرتے ہوئے تنقیدی طور پر مستحکم ویب سروس شروع کرنا ناممکن ہے۔ وہاں، تقسیم شدہ کیش تعاون یافتہ نہیں ہے، ڈیٹا بیس کی نقل تیار نہیں کی جاتی ہے۔
ہم نے تقاضے وضع کیے: یہ مختلف مقامات پر واقع ہونے، نقل کی حمایت کرنے، اور مثالی طور پر مختلف جغرافیائی طور پر تقسیم شدہ ڈیٹا سینٹرز میں واقع ہونے کی صلاحیت ہے۔ پروڈکٹ کی منطق اور درحقیقت ڈیٹا اسٹوریج کو الگ کریں۔ متحرک طور پر بوجھ کے مطابق پیمانہ کرنے کے قابل ہو، اور statics کو مکمل طور پر برداشت کریں۔ ان تحفظات سے، درحقیقت، مصنوعات کی ضروریات سامنے آئیں، جنہیں ہم نے سال بھر میں بہتر کیا۔ اس وقت کے دوران، پلیٹ فارم میں، جو متحد نکلا - باکسڈ حل کے لیے، ہماری اپنی خدمت کے لیے - ہم نے ان چیزوں کے لیے تعاون کیا جن کی ہمیں ضرورت تھی۔ خود پروڈکٹ کی سطح پر mysql نقل کے لیے سپورٹ: یعنی کوڈ لکھنے والا ڈویلپر اس بارے میں نہیں سوچتا کہ اس کی درخواستوں کو کس طرح تقسیم کیا جائے گا، وہ ہماری api کا استعمال کرتا ہے، اور ہم جانتے ہیں کہ ماسٹرز کے درمیان لکھنے اور پڑھنے کی درخواستوں کو صحیح طریقے سے کیسے تقسیم کرنا ہے۔ اور غلام.
ہم نے مختلف کلاؤڈ آبجیکٹ اسٹوریجز کے لیے پروڈکٹ کی سطح پر تعاون کیا ہے: گوگل اسٹوریج، ایمیزون ایس 3، نیز اوپن اسٹیک سوئفٹ کے لیے سپورٹ۔ لہذا، یہ ہمارے لیے بطور سروس اور ڈویلپرز دونوں کے لیے آسان تھا جو ایک پیکڈ حل کے ساتھ کام کرتے ہیں: اگر وہ صرف کام کے لیے ہمارا API استعمال کرتے ہیں، تو وہ اس بارے میں نہیں سوچتے کہ فائل آخر کار کہاں محفوظ ہوگی، مقامی طور پر فائل سسٹم پر یا آبجیکٹ فائل اسٹوریج میں
نتیجے کے طور پر، ہم نے فوری طور پر فیصلہ کیا کہ ہم پورے ڈیٹا سینٹر کی سطح پر ریزرو کریں گے۔ 2012 میں، ہم نے مکمل طور پر Amazon AWS پر لانچ کیا کیونکہ ہمیں پہلے ہی اس پلیٹ فارم کا تجربہ تھا - ہماری اپنی ویب سائٹ وہاں ہوسٹ کی گئی تھی۔ ہم اس حقیقت کی طرف متوجہ ہوئے کہ ہر علاقے میں ایمیزون کے کئی دستیابی زونز ہیں - درحقیقت، (ان کی اصطلاح میں) کئی ڈیٹا سینٹرز جو ایک دوسرے سے کم و بیش آزاد ہیں اور ہمیں ایک پورے ڈیٹا سینٹر کی سطح پر ریزرو کرنے کی اجازت دیتے ہیں: اگر یہ اچانک ناکام ہو جاتا ہے تو، ڈیٹا بیسز کو ماسٹر-ماسٹر کی نقل بنایا جاتا ہے، ویب ایپلیکیشن سرورز کا بیک اپ لیا جاتا ہے، اور جامد ڈیٹا کو s3 آبجیکٹ اسٹوریج میں منتقل کر دیا جاتا ہے۔ بوجھ متوازن ہے - اس وقت ایمیزون ایلب کے ذریعہ، لیکن تھوڑی دیر بعد ہم اپنے اپنے لوڈ بیلنسرز پر آئے، کیونکہ ہمیں زیادہ پیچیدہ منطق کی ضرورت تھی۔
وہ جو چاہتے تھے وہی مل گیا...
تمام بنیادی چیزیں جنہیں ہم یقینی بنانا چاہتے تھے - خود سرورز، ویب ایپلیکیشنز، ڈیٹابیسز کی غلطی برداشت - سب کچھ ٹھیک کام کیا۔ سب سے آسان منظر: اگر ہماری ویب ایپلیکیشنز میں سے ایک ناکام ہوجاتی ہے، تو سب کچھ آسان ہے - وہ توازن سے بند کردیئے گئے ہیں۔
بیلنسر (اس وقت یہ ایمیزون کا ایلب تھا) نے ان مشینوں کو غیر صحت بخش کے طور پر نشان زد کیا اور ان پر لوڈ کی تقسیم بند کردی۔ ایمیزون آٹو اسکیلنگ نے کام کیا: جب بوجھ بڑھتا گیا، آٹو اسکیلنگ گروپ میں نئی مشینیں شامل کی گئیں، بوجھ کو نئی مشینوں میں تقسیم کردیا گیا - سب کچھ ٹھیک تھا۔ ہمارے بیلنسرز کے ساتھ، منطق تقریباً ایک جیسی ہے: اگر ایپلیکیشن سرور کو کچھ ہوتا ہے، تو ہم اس سے درخواستیں ہٹا دیتے ہیں، ان مشینوں کو باہر پھینک دیتے ہیں، نئی شروع کرتے ہیں اور کام جاری رکھتے ہیں۔ اسکیم سالوں میں تھوڑا سا تبدیل ہوا ہے، لیکن کام جاری ہے: یہ آسان، قابل فہم ہے، اور اس میں کوئی مشکلات نہیں ہیں۔
ہم پوری دنیا میں کام کرتے ہیں، گاہک کے بوجھ کی چوٹیاں بالکل مختلف ہیں، اور، ایک دوستانہ انداز میں، ہمیں کسی بھی وقت اپنے سسٹم کے کسی بھی اجزاء پر کچھ خدمت کا کام انجام دینے کے قابل ہونا چاہیے - جس پر صارفین کا کوئی دھیان نہیں ہے۔ لہذا، ہمارے پاس ڈیٹا بیس کو آپریشن سے بند کرنے کا موقع ہے، بوجھ کو دوسرے ڈیٹا سینٹر میں دوبارہ تقسیم کرنا۔
یہ سب کیسے کام کرتا ہے؟ - ہم ٹریفک کو کام کرنے والے ڈیٹا سینٹر میں تبدیل کرتے ہیں - اگر ڈیٹا سینٹر میں کوئی حادثہ ہوتا ہے، تو مکمل طور پر، اگر یہ ایک ڈیٹا بیس کے ساتھ ہمارا منصوبہ بند کام ہے، تو ہم ان کلائنٹس کی خدمت کرنے والے ٹریفک کے کچھ حصے کو معطل کرتے ہوئے، دوسرے ڈیٹا سینٹر میں تبدیل کر دیتے ہیں۔ اس کی نقل. اگر ویب ایپلیکیشنز کے لیے نئی مشینوں کی ضرورت ہے کیونکہ دوسرے ڈیٹا سینٹر پر بوجھ بڑھ گیا ہے تو وہ خود بخود شروع ہو جائیں گی۔ ہم کام ختم کرتے ہیں، نقل بحال ہو جاتی ہے، اور ہم پورا بوجھ واپس کر دیتے ہیں۔ اگر ہمیں دوسرے ڈی سی میں کچھ کام کی عکس بندی کرنے کی ضرورت ہے، مثال کے طور پر، سسٹم اپ ڈیٹس انسٹال کریں یا دوسرے ڈیٹا بیس میں سیٹنگز تبدیل کریں، تو عام طور پر، ہم دوسری سمت میں ایک ہی چیز کو دہراتے ہیں۔ اور اگر یہ ایک حادثہ ہے، تو ہم سب کچھ معمولی طور پر کرتے ہیں: ہم مانیٹرنگ سسٹم میں ایونٹ ہینڈلرز کا طریقہ کار استعمال کرتے ہیں۔ اگر کئی چیک ٹرگر کیے جاتے ہیں اور اسٹیٹس نازک ہو جاتا ہے، تو ہم اس ہینڈلر کو چلاتے ہیں، ایک ہینڈلر جو اس یا اس منطق کو انجام دے سکتا ہے۔ ہر ڈیٹا بیس کے لیے، ہم یہ بتاتے ہیں کہ کون سا سرور اس کے لیے فیل اوور ہے، اور اگر یہ دستیاب نہ ہو تو کہاں ٹریفک کو تبدیل کرنے کی ضرورت ہے۔ تاریخی طور پر، ہم ناگیوس یا اس کے کچھ کانٹے کسی نہ کسی شکل میں استعمال کرتے ہیں۔ اصولی طور پر، تقریباً کسی بھی نگرانی کے نظام میں اسی طرح کے میکانزم موجود ہیں؛ ہم ابھی تک کوئی زیادہ پیچیدہ چیز استعمال نہیں کرتے ہیں، لیکن شاید کسی دن ہم کریں گے۔ اب نگرانی غیر دستیابی سے شروع ہوتی ہے اور اس میں کچھ تبدیل کرنے کی صلاحیت ہوتی ہے۔
کیا ہم نے سب کچھ محفوظ کر لیا ہے؟
ہمارے پاس امریکہ سے بہت سے کلائنٹس ہیں، یورپ کے بہت سے کلائنٹس ہیں، بہت سے کلائنٹس ہیں جو مشرق کے قریب ہیں - جاپان، سنگاپور وغیرہ۔ یقیناً، کلائنٹس کا ایک بڑا حصہ روس میں ہے۔ یعنی کام کسی ایک خطے میں نہیں ہوتا۔ صارفین فوری جواب چاہتے ہیں، مختلف مقامی قوانین کی تعمیل کرنے کے تقاضے ہیں، اور ہر علاقے کے اندر ہم دو ڈیٹا سینٹرز محفوظ رکھتے ہیں، اس کے علاوہ کچھ اضافی خدمات بھی ہیں، جو دوبارہ، ایک علاقے کے اندر رکھنے کے لیے آسان ہیں - ان کلائنٹس کے لیے جو یہ علاقہ کام کر رہا ہے. REST ہینڈلرز، اجازت دینے والے سرورز، مجموعی طور پر کلائنٹ کے آپریشن کے لیے کم اہم ہوتے ہیں، آپ ان کے ذریعے تھوڑی قابل قبول تاخیر کے ساتھ سوئچ کر سکتے ہیں، لیکن آپ اس پہیے کو دوبارہ ایجاد نہیں کرنا چاہتے کہ ان کی نگرانی کیسے کی جائے اور کیا کیا جائے۔ ان کے ساتھ. لہذا، ہم اضافی مصنوعات میں کسی قسم کی قابلیت پیدا کرنے کے بجائے موجودہ حل کو زیادہ سے زیادہ استعمال کرنے کی کوشش کر رہے ہیں۔ اور کہیں ہم DNS کی سطح پر معمولی طور پر سوئچنگ کا استعمال کرتے ہیں، اور ہم اسی DNS کے ذریعے سروس کی جانداریت کا تعین کرتے ہیں۔ ایمیزون کے پاس روٹ 53 سروس ہے، لیکن یہ صرف ایک DNS نہیں ہے جس میں آپ اندراجات کر سکتے ہیں اور بس۔ یہ بہت زیادہ لچکدار اور آسان ہے۔ اس کے ذریعے آپ جغرافیائی محل وقوع کے ساتھ جیو ڈسٹری بیوٹڈ سروسز بنا سکتے ہیں، جب آپ اسے استعمال کرتے ہوئے یہ تعین کرتے ہیں کہ کلائنٹ کہاں سے آیا ہے اور اسے کچھ ریکارڈ فراہم کرتے ہیں - اس کی مدد سے آپ فیل اوور آرکیٹیکچرز بنا سکتے ہیں۔ وہی ہیلتھ چیکس روٹ 53 میں ہی ترتیب دیے گئے ہیں، آپ ان پوائنٹس کو سیٹ کرتے ہیں جن کی نگرانی کی جاتی ہے، میٹرکس سیٹ کرتے ہیں، سروس کی "زندگی" کا تعین کرنے کے لیے کون سے پروٹوکول سیٹ کرتے ہیں - tcp, http, https; چیک کی فریکوئنسی سیٹ کریں جو اس بات کا تعین کرے کہ سروس زندہ ہے یا نہیں۔ اور خود ڈی این ایس میں آپ یہ بتاتے ہیں کہ بنیادی کیا ہوگا، کیا سیکنڈری ہوگا، اگر روٹ 53 کے اندر ہیلتھ چیک شروع کیا جائے تو اسے کہاں تبدیل کرنا ہے۔ یہ سب کچھ دوسرے ٹولز سے کیا جا سکتا ہے، لیکن یہ آسان کیوں ہے - ہم نے اسے سیٹ کیا ہے۔ ایک بار اٹھیں اور پھر اس کے بارے میں بالکل بھی نہ سوچیں کہ ہم کس طرح چیک کرتے ہیں، ہم کس طرح سوئچ کرتے ہیں: سب کچھ اپنے طور پر کام کرتا ہے۔
پہلا "لیکن": روٹ 53 کو کیسے اور کس کے ساتھ ریزرو کیا جائے؟ کون جانتا ہے، اگر اسے کچھ ہو جائے؟ خوش قسمتی سے، ہم نے کبھی بھی اس ریک پر قدم نہیں رکھا، لیکن ایک بار پھر، میرے سامنے ایک کہانی ہوگی کہ ہم نے کیوں سوچا کہ ہمیں اب بھی ریزرویشن کرنے کی ضرورت ہے۔ یہاں ہم نے اپنے لیے پہلے سے تنکے بچھائے تھے۔ دن میں کئی بار ہم ان تمام زونز کو مکمل اتارتے ہیں جو ہمارے پاس روٹ 53 میں ہیں۔ ایمیزون کا API آپ کو انہیں آسانی سے JSON میں بھیجنے کی اجازت دیتا ہے، اور ہمارے پاس کئی بیک اپ سرورز ہیں جہاں ہم اسے تبدیل کرتے ہیں، اسے کنفیگرز کی شکل میں اپ لوڈ کرتے ہیں اور تقریباً بولتے ہوئے، بیک اپ کنفیگریشن رکھتے ہیں۔ اگر کچھ ہوتا ہے تو، ہم DNS ترتیبات کے ڈیٹا کو کھوئے بغیر اسے دستی طور پر تیزی سے تعینات کر سکتے ہیں۔
دوسرا "لیکن": اس تصویر میں کیا ہے جو ابھی تک محفوظ نہیں کیا گیا؟ بیلنس خود! علاقے کے لحاظ سے ہمارے گاہکوں کی تقسیم بہت آسان ہے۔ ہمارے پاس bitrix24.ru, bitrix24.com, .de - اب 13 مختلف ڈومینز ہیں، جو مختلف زونز میں کام کرتے ہیں۔ ہم درج ذیل پر آئے ہیں: ہر علاقے کے اپنے بیلنسرز ہوتے ہیں۔ یہ اس بات پر منحصر ہے کہ نیٹ ورک پر چوٹی کا بوجھ کہاں ہے اس پر منحصر ہے کہ تمام خطوں میں تقسیم کرنا زیادہ آسان بناتا ہے۔ اگر یہ واحد بیلنسر کی سطح پر ناکامی ہے، تو اسے آسانی سے سروس سے ہٹا دیا جاتا ہے اور ڈی این ایس سے ہٹا دیا جاتا ہے۔ اگر بیلنسرز کے گروپ میں کچھ مسئلہ ہے، تو دوسری سائٹوں پر ان کا بیک اپ لیا جاتا ہے، اور ان کے درمیان سوئچنگ اسی روٹ53 کا استعمال کرتے ہوئے کی جاتی ہے، کیونکہ مختصر ٹی ٹی ایل کی وجہ سے، سوئچنگ زیادہ سے زیادہ 2، 3، 5 منٹ میں ہوتی ہے۔ .
تیسرا "لیکن": ابھی تک کیا محفوظ نہیں ہے؟ S3، درست۔ جب ہم نے وہ فائلیں رکھی ہیں جو ہم صارفین کے لیے s3 میں محفوظ کرتے ہیں، تو ہم نے خلوص سے یقین کیا کہ یہ بکتر بند ہے اور وہاں کچھ بھی محفوظ کرنے کی ضرورت نہیں تھی۔ لیکن تاریخ بتاتی ہے کہ چیزیں مختلف ہوتی ہیں۔ عام طور پر، Amazon S3 کو ایک بنیادی سروس کے طور پر بیان کرتا ہے، کیونکہ ایمیزون خود S3 کا استعمال مشین کی تصاویر، کنفیگرز، AMI امیجز، سنیپ شاٹس کو ذخیرہ کرنے کے لیے کرتا ہے... اور اگر s3 کریش ہو جاتا ہے، جیسا کہ ان 7 سالوں کے دوران ایک بار ہوا، جب تک کہ ہم استعمال کر رہے ہیں۔ bitrix24، یہ ایک پرستار کی طرح اس کی پیروی کرتا ہے یہاں بہت ساری چیزیں سامنے آتی ہیں - ورچوئل مشینیں شروع کرنے میں ناکامی، api ناکامی، وغیرہ۔
اور S3 گر سکتا ہے - یہ ایک بار ہوا. لہذا، ہم مندرجہ ذیل اسکیم پر آئے: کچھ سال پہلے روس میں عوامی اشیاء کو ذخیرہ کرنے کی کوئی سنجیدہ سہولیات نہیں تھیں، اور ہم نے اپنا کچھ کرنے کے آپشن پر غور کیا... خوش قسمتی سے، ہم نے ایسا کرنا شروع نہیں کیا، کیونکہ ہم اس مہارت میں کھود لیا ہے جو ہمارے پاس نہیں ہے، اور شاید گڑبڑ ہو جائے گی۔ اب Mail.ru کے پاس s3 سے مطابقت رکھنے والا اسٹوریج ہے، Yandex کے پاس ہے، اور بہت سے دوسرے فراہم کنندگان کے پاس ہے۔ آخر کار ہم اس خیال پر پہنچے کہ ہم چاہتے ہیں، سب سے پہلے، بیک اپ، اور دوم، مقامی کاپیوں کے ساتھ کام کرنے کی صلاحیت۔ خاص طور پر روسی علاقے کے لیے، ہم Mail.ru Hotbox سروس استعمال کرتے ہیں، جو API s3 کے ساتھ مطابقت رکھتی ہے۔ ہمیں ایپلیکیشن کے اندر موجود کوڈ میں کسی بڑی ترمیم کی ضرورت نہیں تھی، اور ہم نے مندرجہ ذیل طریقہ کار بنایا: s3 میں ایسے محرکات ہیں جو اشیاء کی تخلیق/حذف کو متحرک کرتے ہیں، Amazon کے پاس Lambda نامی ایک سروس ہے - یہ کوڈ کا سرور لیس لانچ ہے۔ جو صرف اس وقت عمل میں آئے گا جب کچھ محرکات کو متحرک کیا جائے گا۔
ہم نے یہ بہت آسانی سے کیا: اگر ہمارا ٹرگر فائر ہوتا ہے، تو ہم کوڈ پر عمل کرتے ہیں جو اعتراض کو Mail.ru اسٹوریج میں کاپی کرے گا۔ ڈیٹا کی مقامی کاپیوں کے ساتھ کام کو مکمل طور پر شروع کرنے کے لیے، ہمیں ریورس سنکرونائزیشن کی بھی ضرورت ہے تاکہ جو کلائنٹ روسی سیگمنٹ میں ہیں ان کے قریب اسٹوریج کے ساتھ کام کر سکیں۔ میل اپنے اسٹوریج میں محرکات کو مکمل کرنے والا ہے - بنیادی ڈھانچے کی سطح پر ریورس سنکرونائزیشن کرنا ممکن ہو گا، لیکن فی الحال ہم یہ اپنے کوڈ کی سطح پر کر رہے ہیں۔ اگر ہم دیکھتے ہیں کہ ایک کلائنٹ نے فائل پوسٹ کی ہے، تو کوڈ کی سطح پر ہم ایونٹ کو قطار میں رکھتے ہیں، اس پر کارروائی کرتے ہیں اور ریورس ریپلیکشن کرتے ہیں۔ یہ کیوں برا ہے: اگر ہم اپنی اشیاء کے ساتھ اپنی مصنوعات سے باہر کسی قسم کا کام کرتے ہیں، یعنی کسی بیرونی ذرائع سے، تو ہم اسے خاطر میں نہیں لائیں گے۔ اس لیے، ہم آخر تک انتظار کرتے ہیں، جب سٹوریج کی سطح پر محرکات ظاہر ہوتے ہیں، تاکہ اس بات سے کوئی فرق نہیں پڑتا کہ ہم کوڈ کو کہاں سے لاگو کرتے ہیں، ہمارے پاس آنے والی چیز کو دوسری سمت میں نقل کیا جاتا ہے۔
کوڈ کی سطح پر، ہم ہر کلائنٹ کے لیے دونوں اسٹوریج رجسٹر کرتے ہیں: ایک کو اہم سمجھا جاتا ہے، دوسرے کو بیک اپ سمجھا جاتا ہے۔ اگر سب کچھ ٹھیک ہے تو، ہم اس اسٹوریج کے ساتھ کام کرتے ہیں جو ہمارے قریب ہے: یعنی ہمارے کلائنٹ جو ایمیزون میں ہیں، وہ S3 کے ساتھ کام کرتے ہیں، اور جو روس میں کام کرتے ہیں، وہ Hotbox کے ساتھ کام کرتے ہیں۔ اگر جھنڈا ٹرگر ہوتا ہے، تو فیل اوور کو جوڑ دیا جانا چاہیے، اور ہم کلائنٹس کو دوسرے اسٹوریج میں تبدیل کر دیتے ہیں۔ ہم علاقے کے لحاظ سے اس باکس کو آزادانہ طور پر چیک کر سکتے ہیں اور انہیں آگے پیچھے کر سکتے ہیں۔ ہم نے ابھی تک اسے عملی طور پر استعمال نہیں کیا ہے، لیکن ہم نے اس طریقہ کار کو فراہم کیا ہے اور ہم سوچتے ہیں کہ کسی دن ہمیں اس سوئچ کی ضرورت ہوگی اور یہ کام آئے گا۔ ایسا پہلے بھی ایک بار ہو چکا ہے۔
اوہ، اور ایمیزون بھاگ گیا ...
اس اپریل کو روس میں ٹیلیگرام بلاک کرنے کے آغاز کی سالگرہ ہے۔ اس کے تحت سب سے زیادہ متاثرہ فراہم کنندہ ایمیزون ہے۔ اور، بدقسمتی سے، روسی کمپنیاں جنہوں نے پوری دنیا کے لیے کام کیا، زیادہ نقصان اٹھانا پڑا۔
اگر کمپنی عالمی ہے اور روس اس کے لیے ایک بہت چھوٹا طبقہ ہے، 3-5% - ٹھیک ہے، کسی نہ کسی طرح، آپ ان کی قربانی دے سکتے ہیں۔
اگر یہ خالصتاً روسی کمپنی ہے - مجھے یقین ہے کہ اسے مقامی طور پر واقع ہونے کی ضرورت ہے - ٹھیک ہے، یہ خود صارفین کے لیے آسان، آرام دہ اور کم خطرات ہوں گے۔
کیا ہوگا اگر یہ ایک ایسی کمپنی ہے جو عالمی سطح پر کام کرتی ہے اور اس کے پاس روس اور دنیا بھر کے کلائنٹس کی تعداد تقریباً مساوی ہے؟ طبقات کا رابطہ اہم ہے، اور انہیں ایک دوسرے کے ساتھ کسی نہ کسی طریقے سے کام کرنا چاہیے۔
مارچ 2018 کے آخر میں، Roskomnadzor نے سب سے بڑے آپریٹرز کو ایک خط بھیجا جس میں بتایا گیا کہ انہوں نے Zello میسنجر کو بلاک کرنے کے لیے کئی ملین Amazon IPs کو بلاک کرنے کا منصوبہ بنایا ہے۔ انہی فراہم کنندگان کا شکریہ - انہوں نے کامیابی کے ساتھ ہر ایک کو خط لیک کر دیا، اور ایک سمجھ آئی کہ ایمیزون کے ساتھ تعلق ٹوٹ سکتا ہے۔ جمعہ کا دن تھا، ہم گھبراہٹ میں سرورز ڈاٹ آر یو سے اپنے ساتھیوں کے پاس پہنچے اور کہا: "دوستو، ہمیں ایسے کئی سرورز کی ضرورت ہے جو روس میں نہیں، ایمیزون میں نہیں، بلکہ مثال کے طور پر ایمسٹرڈیم میں کہیں موجود ہوں گے۔" تاکہ کم از کم کسی نہ کسی طرح اپنے VPN اور پراکسی کو وہاں انسٹال کرنے کے قابل ہو جائیں جن پر ہم کسی بھی طرح سے اثر انداز نہیں ہو سکتے، مثال کے طور پر اسی s3 کے اینڈ پونٹس - ہم ایک نئی سروس کو بڑھانے اور ایک مختلف آئی پی حاصل کرنے کی کوشش نہیں کر سکتے، ہمیں آپ کو ابھی بھی وہاں پہنچنے کی ضرورت ہے۔ صرف چند دنوں میں، ہم نے ان سرورز کو ترتیب دیا، انہیں تیار کیا اور چلایا، اور، عام طور پر، اس لمحے کے لیے تیار ہیں جب بلاکنگ شروع ہوئی۔ یہ دلچسپ ہے کہ آر کے این نے ہلچل اور گھبراہٹ کو دیکھتے ہوئے کہا: "نہیں، ہم اب کسی چیز کو بلاک نہیں کریں گے۔" (لیکن یہ بالکل اس لمحے تک ہے جب ٹیلی گرام بلاک ہونا شروع ہوا۔) بائی پاس کی صلاحیتوں کو ترتیب دینے اور یہ محسوس کرنے کے بعد کہ بلاکنگ متعارف نہیں ہوئی تھی، تاہم، ہم نے پورے معاملے کو سلجھانا شروع نہیں کیا۔ ہاں، صرف اس صورت میں۔
اور 2019 میں، ہم اب بھی مسدود ہونے کے حالات میں رہتے ہیں۔ میں نے کل رات دیکھا: تقریباً دس لاکھ آئی پیز مسدود ہیں۔ یہ سچ ہے کہ ایمیزون تقریباً مکمل طور پر غیر مسدود تھا، اپنے عروج پر یہ 20 ملین پتوں تک پہنچ گیا... عام طور پر، حقیقت یہ ہے کہ ہم آہنگی، اچھی ہم آہنگی نہیں ہوسکتی ہے۔ اچانک۔ یہ تکنیکی وجوہات کی بناء پر موجود نہیں ہوسکتا ہے - آگ، کھدائی کرنے والے، یہ سب کچھ۔ یا، جیسا کہ ہم نے دیکھا ہے، مکمل طور پر تکنیکی نہیں۔ لہذا، کوئی بڑا اور بڑا، اپنے AS کے ساتھ، شاید دوسرے طریقوں سے اس کا انتظام کر سکتا ہے - براہ راست رابطہ اور دیگر چیزیں پہلے سے ہی l2 سطح پر ہیں۔ لیکن ایک سادہ ورژن میں، ہماری طرح یا اس سے بھی چھوٹے، آپ، صرف اس صورت میں، سرورز کی سطح پر فالتو پن کہیں اور اٹھا سکتے ہیں، پہلے سے ترتیب شدہ vpn، پراکسی، ان حصوں میں کنفیگریشن کو تیزی سے تبدیل کرنے کی صلاحیت کے ساتھ۔ جو آپ کے رابطے کے لیے اہم ہیں۔ یہ ہمارے لیے ایک سے زیادہ بار کام آیا، جب Amazon کی بلاکنگ شروع ہوئی؛ بدترین صورت حال میں، ہم نے صرف S3 ٹریفک کو ان کے ذریعے جانے کی اجازت دی، لیکن آہستہ آہستہ یہ سب حل ہو گیا۔
ایک مکمل فراہم کنندہ کو کیسے محفوظ کیا جائے؟
ابھی ہمارے پاس کوئی منظرنامہ نہیں ہے کہ پورا ایمیزون نیچے چلا جائے۔ ہمارے ہاں روس کا بھی ایسا ہی منظر ہے۔ روس میں، ہماری میزبانی ایک فراہم کنندہ نے کی، جس سے ہم نے متعدد سائٹس کا انتخاب کیا۔ اور ایک سال پہلے ہمیں ایک مسئلہ کا سامنا کرنا پڑا: اگرچہ یہ دو ڈیٹا سینٹرز ہیں، فراہم کنندہ کے نیٹ ورک کنفیگریشن کی سطح پر پہلے سے ہی مسائل ہوسکتے ہیں جو اب بھی دونوں ڈیٹا سینٹرز کو متاثر کریں گے۔ اور ہوسکتا ہے کہ ہم دونوں سائٹوں پر دستیاب نہ ہوں۔ یقیناً ایسا ہی ہوا۔ ہم نے اندر کے فن تعمیر پر دوبارہ غور کیا۔ یہ بہت زیادہ تبدیل نہیں ہوا ہے، لیکن روس کے لیے اب ہمارے پاس دو سائٹس ہیں، جو ایک ہی فراہم کنندہ کی نہیں، بلکہ دو مختلف سائٹس سے ہیں۔ اگر ایک ناکام ہو جاتا ہے، تو ہم دوسرے پر جا سکتے ہیں۔
فرضی طور پر، ایمیزون کے لیے ہم کسی دوسرے فراہم کنندہ کی سطح پر ریزرویشن کے امکان پر غور کر رہے ہیں۔ ہو سکتا ہے گوگل، ہو سکتا ہے کوئی اور... لیکن اب تک ہم نے عملی طور پر مشاہدہ کیا ہے کہ ایمیزون کے ایک دستیابی زون کی سطح پر حادثات ہوتے ہیں، لیکن پورے خطے کی سطح پر حادثات بہت کم ہوتے ہیں۔ لہذا، ہمارے پاس نظریاتی طور پر یہ خیال ہے کہ ہم "ایمیزون ایمیزون نہیں ہے" ریزرویشن کر سکتے ہیں، لیکن عملی طور پر ابھی تک ایسا نہیں ہے۔
آٹومیشن کے بارے میں چند الفاظ
کیا آٹومیشن ہمیشہ ضروری ہے؟ یہاں ڈننگ کروگر اثر کو یاد کرنا مناسب ہے۔ "x" محور پر ہمارا علم اور تجربہ ہے جو ہم حاصل کرتے ہیں، اور "y" محور پر ہمارے اعمال پر اعتماد ہے۔ پہلے تو ہم کچھ نہیں جانتے اور بالکل بھی یقین نہیں رکھتے۔ پھر ہم تھوڑا سا جانتے ہیں اور بڑے پراعتماد ہو جاتے ہیں - یہ نام نہاد "حماقت کی چوٹی" ہے، جس کی تصویر "ڈیمنشیا اور ہمت" سے اچھی طرح سے واضح ہے۔ پھر ہم نے تھوڑا سیکھا ہے اور جنگ میں جانے کے لیے تیار ہیں۔ پھر ہم کچھ بڑی سنگین غلطیوں پر قدم رکھتے ہیں اور خود کو مایوسی کی ایک وادی میں پاتے ہیں، جب بظاہر ہم کچھ جانتے ہیں، لیکن حقیقت میں ہم زیادہ نہیں جانتے۔ پھر، جیسا کہ ہم تجربہ حاصل کرتے ہیں، ہم زیادہ پر اعتماد ہوتے جاتے ہیں۔
بعض حادثات میں مختلف خودکار سوئچز کے بارے میں ہماری منطق اس گراف کے ذریعے بہت اچھی طرح سے بیان کی گئی ہے۔ ہم نے شروع کیا - ہمیں کچھ کرنا نہیں آتا تھا، تقریباً سارا کام ہاتھ سے ہوتا تھا۔ تب ہم نے محسوس کیا کہ ہم ہر چیز کے ساتھ آٹومیشن کو منسلک کر سکتے ہیں اور جیسے کہ سکون سے سو سکتے ہیں۔ اور اچانک ہم ایک میگا ریک پر قدم رکھتے ہیں: ایک غلط مثبت کو متحرک کیا جاتا ہے، اور ہم ٹریفک کو آگے پیچھے کرتے ہیں جب، اچھے طریقے سے، ہمیں ایسا نہیں کرنا چاہیے تھا۔ نتیجتاً نقل ٹوٹ جائے یا کچھ اور—یہ مایوسی کی وادی ہے۔ اور پھر ہم اس سمجھ میں آتے ہیں کہ ہمیں ہر چیز کو عقلمندی سے دیکھنا چاہیے۔ یعنی، غلط الارم کے امکان کو فراہم کرتے ہوئے، آٹومیشن پر انحصار کرنا سمجھ میں آتا ہے۔ لیکن! اگر اس کے نتائج تباہ کن ہو سکتے ہیں، تو بہتر ہے کہ اسے ڈیوٹی شفٹ پر، ڈیوٹی پر موجود انجینئرز پر چھوڑ دیا جائے، جو اس بات کو یقینی بنائیں گے اور نگرانی کریں گے کہ واقعی کوئی حادثہ ہوا ہے، اور ضروری کارروائیاں دستی طور پر کریں گے...
حاصل يہ ہوا
7 سالوں کے دوران، ہم اس حقیقت سے چلے گئے کہ جب کوئی چیز گرتی ہے تو گھبراہٹ ہوتی ہے، یہ سمجھنا کہ مسائل موجود نہیں ہیں، صرف کام ہیں، انہیں حل کیا جانا چاہیے اور کیا جا سکتا ہے۔ جب آپ کوئی سروس بنا رہے ہوں تو اسے اوپر سے دیکھیں، ان تمام خطرات کا اندازہ لگائیں جو ہو سکتے ہیں۔ اگر آپ انہیں فوراً دیکھتے ہیں، تو پہلے سے فالتو پن اور غلطی برداشت کرنے والے انفراسٹرکچر کی تعمیر کے امکانات فراہم کریں، کیونکہ کوئی بھی نقطہ جو ناکام ہو سکتا ہے اور سروس کے ناکارہ ہونے کا باعث بن سکتا ہے وہ یقینی طور پر ایسا کرے گا۔ اور یہاں تک کہ اگر یہ آپ کو لگتا ہے کہ بنیادی ڈھانچے کے کچھ عناصر یقینی طور پر ناکام نہیں ہوں گے - اسی s3 کی طرح، پھر بھی ذہن میں رکھیں کہ وہ کر سکتے ہیں۔ اور کم از کم نظریہ میں، اس بات کا اندازہ لگائیں کہ اگر کچھ ہوتا ہے تو آپ ان کے ساتھ کیا کریں گے۔ رسک مینجمنٹ پلان بنائیں۔ جب آپ خود کار طریقے سے یا دستی طور پر سب کچھ کرنے کے بارے میں سوچ رہے ہیں، تو خطرات کا اندازہ لگائیں: اگر آٹومیشن ہر چیز کو تبدیل کرنا شروع کر دے تو کیا ہوگا - کیا یہ حادثے کے مقابلے میں اور بھی خراب صورتحال کا باعث نہیں بنے گا؟ شاید کہیں یہ ضروری ہے کہ آٹومیشن کے استعمال اور ڈیوٹی پر موجود انجینئر کے رد عمل کے درمیان معقول سمجھوتہ کیا جائے، جو اصل تصویر کا جائزہ لے کر سمجھے کہ آیا کسی چیز کو موقع پر تبدیل کرنے کی ضرورت ہے یا "ہاں، لیکن ابھی نہیں۔"
کمال پسندی اور حقیقی کوشش، وقت، رقم کے درمیان ایک معقول سمجھوتہ جو آپ اس اسکیم پر خرچ کر سکتے ہیں جو آپ کے پاس آخرکار ہو گی۔
یہ متن کانفرنس میں الیگزینڈر ڈیمیدوف کی رپورٹ کا تازہ ترین اور توسیع شدہ ورژن ہے۔ .
ماخذ: www.habr.com