حبر کانفرنس کوئی پہلی کہانی نہیں ہے۔ پہلے، ہم 300-400 لوگوں کے لیے کافی بڑے ٹوسٹر ایونٹس منعقد کرتے تھے، لیکن اب ہم نے فیصلہ کیا ہے کہ چھوٹی موضوعاتی میٹنگز متعلقہ ہوں گی، جس کی سمت آپ سیٹ کر سکتے ہیں، مثال کے طور پر، تبصرے میں۔ اس فارمیٹ کی پہلی کانفرنس جولائی میں منعقد ہوئی تھی اور بیک اینڈ ڈیولپمنٹ کے لیے وقف تھی۔ شرکاء نے بیک اینڈ سے ایم ایل میں منتقلی کی خصوصیات اور اسٹیٹ سروسز پورٹل پر کواڈروپل سروس کے ڈیزائن کے بارے میں رپورٹس سنیں، اور سرور لیس کے لیے وقف ایک گول میز میں بھی حصہ لیا۔ وہ لوگ جو اس تقریب میں ذاتی طور پر شرکت کرنے سے قاصر تھے، اس پوسٹ میں ہم آپ کو انتہائی دلچسپ باتیں بتاتے ہیں۔
بیک اینڈ ڈیولپمنٹ سے لے کر مشین لرننگ تک
ڈیٹا انجینئر ایم ایل میں کیا کرتے ہیں؟ بیک اینڈ ڈویلپر اور ایم ایل انجینئر کے کام کیسے ایک جیسے اور مختلف ہیں؟ اپنے پہلے پیشے کو دوسرے میں تبدیل کرنے کے لیے آپ کو کون سا راستہ اختیار کرنے کی ضرورت ہے؟ یہ بات الیگزینڈر پرینوف نے بتائی، جو 10 سال کے بیک اینڈ کام کے بعد مشین لرننگ میں گئے تھے۔
الیگزینڈر پارینوف
آج الیگزینڈر X5 ریٹیل گروپ میں کمپیوٹر ویژن سسٹمز آرکیٹیکٹ کے طور پر کام کرتا ہے اور کمپیوٹر ویژن اور ڈیپ لرننگ (github.com/creafz) سے متعلق اوپن سورس پروجیکٹس میں تعاون کرتا ہے۔ مشین لرننگ مقابلوں کا سب سے مقبول پلیٹ فارم، Kaggle Master (kaggle.com/creafz) کی عالمی درجہ بندی کے ٹاپ 100 میں اس کی شرکت سے اس کی مہارت کی تصدیق ہوتی ہے۔
مشین لرننگ پر کیوں سوئچ کریں۔
ڈیڑھ سال قبل، گوگل کے گہری سیکھنے پر مبنی مصنوعی ذہانت کے تحقیقی منصوبے، گوگل برین کے سربراہ جیف ڈین نے بتایا کہ کس طرح گوگل ٹرانسلیٹ میں کوڈ کی نصف ملین لائنوں کو صرف 500 لائنوں پر مشتمل ٹینسر فلو نیورل نیٹ ورک سے تبدیل کیا گیا۔ نیٹ ورک کی تربیت کے بعد ڈیٹا کا معیار بڑھ گیا اور انفراسٹرکچر آسان ہو گیا۔ ایسا لگتا ہے کہ یہ ہمارا روشن مستقبل ہے: ہمیں اب کوڈ لکھنے کی ضرورت نہیں ہے، یہ نیوران بنانے اور ڈیٹا سے بھرنے کے لیے کافی ہے۔ لیکن عملی طور پر سب کچھ زیادہ پیچیدہ ہے۔
گوگل پر ML انفراسٹرکچر
اعصابی نیٹ ورک بنیادی ڈھانچے کا صرف ایک چھوٹا سا حصہ ہیں (اوپر کی تصویر میں چھوٹا سیاہ مربع)۔ ڈیٹا حاصل کرنے، اس پر کارروائی کرنے، اسے ذخیرہ کرنے، معیار کی جانچ وغیرہ کے لیے بہت سے مزید معاون نظاموں کی ضرورت ہے، ہمیں تربیت کے لیے بنیادی ڈھانچے کی ضرورت ہے، مشین لرننگ کوڈ کو پروڈکشن میں تعینات کرنا، اور اس کوڈ کی جانچ کرنا ہے۔ یہ تمام کام بالکل اسی طرح کے ہیں جو بیک اینڈ ڈویلپرز کرتے ہیں۔
مشین سیکھنے کا عمل
ایم ایل اور بیک اینڈ میں کیا فرق ہے؟
کلاسیکی پروگرامنگ میں، ہم کوڈ لکھتے ہیں اور یہ پروگرام کے رویے کا حکم دیتا ہے۔ ایم ایل میں، ہمارے پاس ایک چھوٹا ماڈل کوڈ اور بہت سا ڈیٹا ہے جسے ہم ماڈل پر پھینک دیتے ہیں۔ ایم ایل میں ڈیٹا بہت اہم ہے: مختلف ڈیٹا پر تربیت یافتہ ایک ہی ماڈل بالکل مختلف نتائج دکھا سکتا ہے۔ مسئلہ یہ ہے کہ ڈیٹا تقریباً ہمیشہ بکھرا اور مختلف سسٹمز (ریلیشنل ڈیٹا بیس، NoSQL ڈیٹا بیس، لاگز، فائلز) میں محفوظ ہوتا ہے۔
ڈیٹا ورژننگ
ML کو کلاسیکی ترقی کی طرح نہ صرف کوڈ کی ورژن کی ضرورت ہوتی ہے، بلکہ ڈیٹا کی بھی: یہ واضح طور پر سمجھنا ضروری ہے کہ ماڈل کو کس چیز پر تربیت دی گئی تھی۔ ایسا کرنے کے لیے، آپ مقبول ڈیٹا سائنس ورژن کنٹرول لائبریری (dvc.org) استعمال کر سکتے ہیں۔
ڈیٹا مارک اپ
اگلا کام ڈیٹا لیبلنگ ہے۔ مثال کے طور پر، تصویر میں موجود تمام اشیاء کو نشان زد کریں یا بتائیں کہ یہ کس کلاس سے تعلق رکھتی ہے۔ یہ Yandex.Toloka جیسی خصوصی خدمات کے ذریعے کیا جاتا ہے، جس کے ساتھ کام API کی موجودگی سے بہت آسان ہوتا ہے۔ "انسانی عنصر" کی وجہ سے مشکلات پیدا ہوتی ہیں: آپ ڈیٹا کے معیار کو بہتر بنا سکتے ہیں اور ایک ہی کام کو متعدد اداکاروں کو سونپ کر غلطیوں کو کم سے کم کر سکتے ہیں۔
ٹینسر بورڈ میں تصور
نتائج کا موازنہ کرنے اور کچھ میٹرکس کی بنیاد پر بہترین ماڈل منتخب کرنے کے لیے تجربات کی لاگنگ ضروری ہے۔ ویژولائزیشن کے لیے ٹولز کا ایک بڑا سیٹ ہے - مثال کے طور پر، ٹینسر بورڈ۔ لیکن تجربات کو ذخیرہ کرنے کے کوئی مثالی طریقے نہیں ہیں۔ چھوٹی کمپنیاں اکثر ایکسل اسپریڈشیٹ کے ساتھ کام کرتی ہیں، جبکہ بڑی کمپنیاں ڈیٹا بیس میں نتائج کو ذخیرہ کرنے کے لیے خصوصی پلیٹ فارم استعمال کرتی ہیں۔
مشین لرننگ کے لیے بہت سے پلیٹ فارم ہیں، لیکن ان میں سے کوئی بھی 70% ضروریات کو پورا نہیں کرتا
تربیت یافتہ ماڈل کو پروڈکشن میں ڈالتے وقت سب سے پہلے جس مسئلے کا سامنا کرنا پڑتا ہے وہ ڈیٹا سائنسدانوں کے پسندیدہ ٹول - Jupyter Notebook سے متعلق ہے۔ اس میں کوئی ماڈیولریٹی نہیں ہے، یعنی آؤٹ پٹ کوڈ کا ایسا "فٹ کلاتھ" ہے جسے منطقی ٹکڑوں - ماڈیولز میں تقسیم نہیں کیا گیا ہے۔ سب کچھ ملایا گیا ہے: کلاسز، فنکشنز، کنفیگریشنز وغیرہ۔ اس کوڈ کو ورژن اور ٹیسٹ کرنا مشکل ہے۔
اس سے کیسے نمٹا جائے؟ آپ Netflix کی طرح خود سے استعفیٰ دے سکتے ہیں اور اپنا پلیٹ فارم بنا سکتے ہیں جو آپ کو ان لیپ ٹاپس کو براہ راست پروڈکشن میں لانچ کرنے، ان پٹ کے طور پر ڈیٹا منتقل کرنے اور نتائج حاصل کرنے کی اجازت دیتا ہے۔ آپ ان ڈویلپرز کو مجبور کر سکتے ہیں جو ماڈل کو پروڈکشن میں رول کر رہے ہیں کوڈ کو عام طور پر دوبارہ لکھیں، اسے ماڈیولز میں توڑ دیں۔ لیکن اس نقطہ نظر کے ساتھ غلطی کرنا آسان ہے، اور ماڈل ارادے کے مطابق کام نہیں کرے گا۔ لہذا، مثالی آپشن یہ ہے کہ ماڈل کوڈ کے لیے Jupyter Notebook کے استعمال پر پابندی لگائی جائے۔ اگر، یقینا، ڈیٹا سائنسدان اس سے اتفاق کرتے ہیں.
بلیک باکس کے طور پر ماڈل
ماڈل کو پروڈکشن میں لانے کا سب سے آسان طریقہ اسے بلیک باکس کے طور پر استعمال کرنا ہے۔ آپ کے پاس کسی قسم کی ماڈل کلاس ہے، آپ کو ماڈل کا وزن دیا گیا تھا (تربیت یافتہ نیٹ ورک کے نیوران کے پیرامیٹرز)، اور اگر آپ اس کلاس کو شروع کرتے ہیں (پیش گوئی کے طریقہ کار کو کال کریں، اسے ایک تصویر کھلائیں)، تو آپ کو ایک خاص رقم ملے گی۔ ایک آؤٹ پٹ کے طور پر پیشن گوئی. اندر کیا ہوتا ہے اس سے کوئی فرق نہیں پڑتا۔
ماڈل کے ساتھ سرور کا عمل الگ کریں۔
آپ ایک مخصوص الگ عمل بھی بڑھا سکتے ہیں اور اسے آر پی سی قطار کے ذریعے بھیج سکتے ہیں (تصاویر یا دیگر ماخذ ڈیٹا کے ساتھ۔ آؤٹ پٹ پر ہمیں پیشین گوئیاں موصول ہوں گی۔
فلاسک میں ماڈل استعمال کرنے کی ایک مثال:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
اس نقطہ نظر کے ساتھ مسئلہ کارکردگی کی حد ہے۔ ہم کہتے ہیں کہ ہمارے پاس ڈیٹا سائنسدانوں کا لکھا ہوا Phyton کوڈ ہے جو سست ہے، اور ہم زیادہ سے زیادہ کارکردگی کو نچوڑنا چاہتے ہیں۔ ایسا کرنے کے لیے، آپ ایسے ٹولز استعمال کر سکتے ہیں جو کوڈ کو مقامی میں تبدیل کرتے ہیں یا اسے پروڈکشن کے لیے تیار کردہ دوسرے فریم ورک میں تبدیل کرتے ہیں۔ ہر فریم ورک کے لیے ایسے ٹولز موجود ہیں، لیکن کوئی مثالی نہیں ہیں؛ آپ کو انہیں خود شامل کرنا پڑے گا۔
ML میں بنیادی ڈھانچہ وہی ہے جیسا کہ ایک باقاعدہ پس منظر میں ہوتا ہے۔ یہاں Docker اور Kubernetes ہیں، صرف Docker کے لیے آپ کو NVIDIA سے رن ٹائم انسٹال کرنے کی ضرورت ہے، جو کنٹینر کے اندر موجود عمل کو میزبان میں ویڈیو کارڈز تک رسائی کی اجازت دیتا ہے۔ Kubernetes کو ایک پلگ ان کی ضرورت ہے تاکہ یہ ویڈیو کارڈز کے ساتھ سرورز کا نظم کر سکے۔
کلاسیکی پروگرامنگ کے برعکس، ML کے معاملے میں انفراسٹرکچر میں بہت سے مختلف متحرک عناصر ہیں جن کی جانچ اور جانچ کی ضرورت ہے - مثال کے طور پر، ڈیٹا پروسیسنگ کوڈ، ماڈل ٹریننگ پائپ لائن اور پروڈکشن (اوپر کا خاکہ دیکھیں)۔ اس کوڈ کی جانچ کرنا ضروری ہے جو پائپ لائنوں کے مختلف ٹکڑوں کو جوڑتا ہے: بہت سے ٹکڑے ہیں، اور مسائل اکثر ماڈیول کی حدود میں پیدا ہوتے ہیں۔
آٹو ایم ایل کیسے کام کرتا ہے۔
AutoML سروسز آپ کے مقاصد کے لیے بہترین ماڈل منتخب کرنے اور اسے تربیت دینے کا وعدہ کرتی ہیں۔ لیکن آپ کو سمجھنے کی ضرورت ہے: ایم ایل میں ڈیٹا بہت اہم ہے، نتیجہ اس کی تیاری پر منحصر ہے۔ مارک اپ لوگوں کے ذریعہ کیا جاتا ہے، جو غلطیوں سے بھرا ہوتا ہے۔ سخت کنٹرول کے بغیر، نتیجہ ردی کی ٹوکری میں ہو سکتا ہے، اور اس عمل کو خودکار کرنا ابھی تک ممکن نہیں ہے؛ ماہرین - ڈیٹا سائنسدانوں کے ذریعہ تصدیق کی ضرورت ہے۔ یہ وہ جگہ ہے جہاں آٹو ایم ایل ٹوٹ جاتا ہے۔ لیکن یہ ایک فن تعمیر کو منتخب کرنے کے لیے مفید ہو سکتا ہے - جب آپ پہلے ہی ڈیٹا تیار کر چکے ہوں اور بہترین ماڈل تلاش کرنے کے لیے تجربات کا سلسلہ چلانا چاہتے ہوں۔
مشین لرننگ میں کیسے جانا ہے۔
ML میں جانے کا سب سے آسان طریقہ یہ ہے کہ اگر آپ Python میں ترقی کرتے ہیں، جو تمام ڈیپ لرننگ فریم ورک (اور باقاعدہ فریم ورک) میں استعمال ہوتا ہے۔ سرگرمی کے اس شعبے کے لیے یہ زبان عملی طور پر لازمی ہے۔ C++ کچھ کمپیوٹر وژن کے کاموں کے لیے استعمال ہوتا ہے، مثال کے طور پر، خود چلانے والی کاروں کے کنٹرول سسٹم میں۔ جاوا اسکرپٹ اور شیل - تصور اور براؤزر میں نیوران چلانے جیسی عجیب و غریب چیزوں کے لیے۔ بگ ڈیٹا کے ساتھ کام کرتے وقت اور مشین لرننگ کے لیے Java اور Scala کا استعمال کیا جاتا ہے۔ R اور جولیا ان لوگوں کو پسند کرتے ہیں جو ریاضی کے اعدادوشمار کا مطالعہ کرتے ہیں۔
شروع کرنے کے لیے عملی تجربہ حاصل کرنے کا سب سے آسان طریقہ Kaggle پر ہے؛ پلیٹ فارم کے مقابلوں میں سے ایک میں شرکت ایک سال سے زیادہ تھیوری کا مطالعہ کرتی ہے۔ اس پلیٹ فارم پر آپ کسی اور کا پوسٹ کردہ اور تبصرہ کردہ کوڈ لے سکتے ہیں اور اسے بہتر بنانے کی کوشش کر سکتے ہیں، اسے اپنے مقاصد کے لیے بہتر بنا سکتے ہیں۔ بونس - آپ کا کیگل رینک آپ کی تنخواہ کو متاثر کرتا ہے۔
دوسرا آپشن یہ ہے کہ ML ٹیم میں بطور بیک اینڈ ڈویلپر شامل ہوں۔ بہت سے مشین لرننگ اسٹارٹ اپس ہیں جہاں آپ اپنے ساتھیوں کے مسائل حل کرنے میں مدد کر کے تجربہ حاصل کر سکتے ہیں۔ آخر میں، آپ ڈیٹا سائنٹسٹ کمیونٹیز میں سے ایک میں شامل ہو سکتے ہیں - اوپن ڈیٹا سائنس (ods.ai) اور دیگر۔
سپیکر نے لنک پر موضوع پر اضافی معلومات پوسٹ کیں۔
"کواڈروپل" - پورٹل "اسٹیٹ سروسز" کے ٹارگٹڈ اطلاعات کی ایک خدمت
Evgeny Smirnov
اگلا مقرر ای-گورنمنٹ انفراسٹرکچر ڈویلپمنٹ ڈیپارٹمنٹ کے سربراہ ایوگینی سمرنوف تھے، جنہوں نے کواڈرپل کے بارے میں بات کی۔ یہ Gosuslugi پورٹل (gosuslugi.ru) کے لیے ایک ٹارگٹڈ نوٹیفکیشن سروس ہے، جو Runet پر سب سے زیادہ دیکھے جانے والے سرکاری وسائل ہیں۔ روزانہ سامعین کی تعداد 2,6 ملین ہے، مجموعی طور پر سائٹ پر 90 ملین رجسٹرڈ صارفین ہیں، جن میں سے 60 ملین تصدیق شدہ ہیں۔ پورٹل API پر لوڈ 30 ہزار RPS ہے۔
ریاستی خدمات کے پس منظر میں استعمال ہونے والی ٹیکنالوجیز
"کواڈروپل" ایک ٹارگٹڈ نوٹیفکیشن سروس ہے، جس کی مدد سے صارف کو خصوصی نوٹیفکیشن رولز ترتیب دے کر اپنے لیے موزوں ترین وقت پر کسی سروس کی پیشکش موصول ہوتی ہے۔ سروس کو تیار کرتے وقت اہم تقاضے لچکدار ترتیبات اور میلنگ کے لیے مناسب وقت تھے۔
Quadrupel کیسے کام کرتا ہے؟
مندرجہ بالا خاکہ Quadrupel کے آپریشن کے اصولوں میں سے ایک کو ایک ایسی صورتحال کی مثال کے ساتھ دکھاتا ہے جس میں ڈرائیور کا لائسنس تبدیل کرنے کی ضرورت ہے۔ سب سے پہلے، سروس ان صارفین کی تلاش کرتی ہے جن کی میعاد ختم ہونے کی تاریخ ایک ماہ میں ختم ہو جاتی ہے۔ انہیں مناسب سروس حاصل کرنے کی پیشکش کے ساتھ ایک بینر دکھایا جاتا ہے اور ای میل کے ذریعے ایک پیغام بھیجا جاتا ہے۔ ان صارفین کے لیے جن کی آخری تاریخ پہلے ہی ختم ہو چکی ہے، بینر اور ای میل میں تبدیلی۔ حقوق کے کامیاب تبادلے کے بعد، صارف کو دیگر اطلاعات موصول ہوتی ہیں - شناخت میں ڈیٹا کو اپ ڈیٹ کرنے کی تجویز کے ساتھ۔
تکنیکی نقطہ نظر سے، یہ گرووی اسکرپٹ ہیں جن میں کوڈ لکھا جاتا ہے۔ ان پٹ ڈیٹا ہے، آؤٹ پٹ صحیح/غلط، مماثل/مماثل نہیں ہے۔ مجموعی طور پر 50 سے زیادہ قواعد ہیں - صارف کی تاریخ پیدائش (موجودہ تاریخ صارف کی تاریخ پیدائش کے برابر ہے) کے تعین سے لے کر پیچیدہ حالات تک۔ ہر روز، یہ اصول تقریباً ایک ملین میچوں کی نشاندہی کرتے ہیں—جن لوگوں کو مطلع کرنے کی ضرورت ہے۔
کواڈروپل نوٹیفکیشن چینلز
کواڈروپل کے ہڈ کے نیچے ایک ڈیٹا بیس ہے جس میں صارف کا ڈیٹا محفوظ کیا جاتا ہے، اور تین ایپلیکیشنز:
- کارکن ڈیٹا کو اپ ڈیٹ کرنے کا مقصد۔
- باقی API۔ بینرز کو اٹھا کر خود پورٹل اور موبائل ایپلیکیشن پر پہنچاتا ہے۔
- شیڈولر بینرز یا ماس میلنگ کی دوبارہ گنتی پر کام شروع کرتا ہے۔
ڈیٹا کو اپ ڈیٹ کرنے کے لیے، بیک اینڈ ایونٹ پر مبنی ہے۔ دو انٹرفیس - آرام یا JMS. بہت سارے واقعات ہیں؛ محفوظ کرنے اور پروسیس کرنے سے پہلے، انہیں جمع کیا جاتا ہے تاکہ غیر ضروری درخواستیں نہ کی جائیں۔ خود ڈیٹا بیس، وہ جدول جس میں ڈیٹا ذخیرہ کیا جاتا ہے، ایک کلیدی ویلیو اسٹور کی طرح لگتا ہے - صارف کی کلید اور خود قدر: متعلقہ دستاویزات کی موجودگی یا عدم موجودگی کی نشاندہی کرنے والے جھنڈے، ان کی درستگی کی مدت، مجموعی اعدادوشمار یہ صارف، اور اسی طرح.
ڈیٹا کو محفوظ کرنے کے بعد، JMS میں ایک ٹاسک سیٹ کیا جاتا ہے تاکہ بینرز کی فوری طور پر دوبارہ گنتی کی جائے - یہ فوری طور پر ویب پر ظاہر ہونا چاہیے۔ نظام رات کو شروع ہوتا ہے: کاموں کو JMS میں صارف کے وقفوں پر ڈالا جاتا ہے، جس کے مطابق قواعد کی دوبارہ گنتی کی ضرورت ہوتی ہے۔ یہ دوبارہ گنتی میں شامل پروسیسرز کے ذریعہ اٹھایا جاتا ہے۔ اس کے بعد، پروسیسنگ کے نتائج اگلی قطار میں جاتے ہیں، جو یا تو ڈیٹا بیس میں بینرز کو محفوظ کرتی ہے یا صارف کی اطلاع کے کام کو سروس کو بھیجتی ہے۔ اس عمل میں 5-7 گھنٹے لگتے ہیں، یہ آسانی سے توسیع پذیر ہے اس حقیقت کی وجہ سے کہ آپ ہمیشہ ہینڈلرز کو شامل کر سکتے ہیں یا نئے ہینڈلرز کے ساتھ مثالیں بڑھا سکتے ہیں۔
سروس کافی اچھی طرح سے کام کرتی ہے۔ لیکن ڈیٹا کا حجم بڑھ رہا ہے کیونکہ زیادہ صارفین ہیں۔ اس سے ڈیٹا بیس پر بوجھ میں اضافہ ہوتا ہے - یہاں تک کہ اس حقیقت کو بھی مدنظر رکھتے ہوئے کہ Rest API نقل کو دیکھتا ہے۔ دوسرا نکتہ JMS ہے، جو جیسا کہ یہ نکلا، زیادہ میموری کی کھپت کی وجہ سے زیادہ موزوں نہیں ہے۔ قطار کے اوور فلو ہونے کا خطرہ بہت زیادہ ہے جس کی وجہ سے JMS کریش ہو جاتا ہے اور پروسیسنگ رک جاتی ہے۔ اس کے بعد نوشتہ جات کو صاف کیے بغیر JMS کو بڑھانا ناممکن ہے۔
شارڈنگ کا استعمال کرتے ہوئے مسائل کو حل کرنے کی منصوبہ بندی کی گئی ہے، جو ڈیٹا بیس پر بوجھ کو متوازن کرنے کی اجازت دے گی۔ ڈیٹا سٹوریج سکیم کو تبدیل کرنے، اور JMS کو کافکا میں تبدیل کرنے کے بھی منصوبے ہیں - ایک زیادہ غلطی برداشت کرنے والا حل جو میموری کے مسائل کو حل کرے گا۔
بیک اینڈ بطور سروس بمقابلہ بے سرور
بائیں سے دائیں: الیگزینڈر بورگارٹ، آندرے ٹومیلینکو، نکولے مارکوف، آرا اسرائیلی
بیک اینڈ بطور سروس یا سرور لیس حل؟ گول میز پر اس اہم مسئلے پر بحث کے شرکاء یہ تھے:
- آرا اسرائیلی، CTO CTO اور Scorocode کے بانی۔
- نیکولے مارکوف، الائنڈ ریسرچ گروپ میں سینئر ڈیٹا انجینئر۔
- آندرے ٹومیلینکو، RUVDS ڈیولپمنٹ ڈیپارٹمنٹ کے سربراہ۔
گفتگو کو سینئر ڈویلپر الیگزینڈر بورگارٹ نے ماڈریٹ کیا تھا۔ ہم وہ مباحث پیش کرتے ہیں جن میں سامعین نے بھی مختصراً حصہ لیا۔
- آپ کی سمجھ میں سرور لیس کیا ہے؟
اینڈریو: یہ ایک کمپیوٹنگ ماڈل ہے - ایک لیمبڈا فنکشن جس میں ڈیٹا کو پروسیس کرنا ضروری ہے تاکہ نتیجہ صرف ڈیٹا پر منحصر ہو۔ یہ اصطلاح یا تو گوگل سے آئی ہے یا ایمیزون اور اس کی AWS Lambda سروس سے۔ فراہم کنندہ کے لیے اس کے لیے گنجائش کا ایک تالاب مختص کرکے اس طرح کے فنکشن کو سنبھالنا آسان ہے۔ ایک ہی سرورز پر مختلف صارفین کا آزادانہ طور پر حساب کیا جا سکتا ہے۔
نیکولس: سیدھے الفاظ میں، ہم اپنے آئی ٹی انفراسٹرکچر اور کاروباری منطق کا کچھ حصہ کلاؤڈ، آؤٹ سورسنگ میں منتقل کر رہے ہیں۔
مکاؤ: ڈویلپرز کی طرف سے - وسائل کو بچانے کی ایک اچھی کوشش، مارکیٹرز کی طرف سے - زیادہ پیسہ کمانے کے لیے۔
- کیا سرور لیس مائیکرو سروسز جیسا ہے؟
نیکولس: نہیں، سرور لیس ایک فن تعمیر کی تنظیم ہے۔ ایک مائیکرو سروس کچھ منطق کی ایک جوہری اکائی ہے۔ سرور لیس ایک نقطہ نظر ہے، "علیحدہ ادارہ" نہیں۔
مکاؤ: سرور لیس فنکشن کو مائیکرو سروس میں پیک کیا جا سکتا ہے، لیکن یہ اب سرور لیس نہیں رہے گا، یہ لیمبڈا فنکشن نہیں رہے گا۔ سرور لیس میں، ایک فنکشن صرف اس وقت کام کرنا شروع کرتا ہے جب اس کی درخواست کی جاتی ہے۔
اینڈریو: وہ اپنی زندگی میں مختلف ہوتے ہیں۔ ہم نے لیمبڈا فنکشن لانچ کیا اور اسے بھول گئے۔ اس نے چند سیکنڈ تک کام کیا، اور اگلا کلائنٹ اس کی درخواست کو کسی اور فزیکل مشین پر پروسیس کر سکتا ہے۔
- کون سا ترازو بہتر ہے؟
مکاؤ: افقی طور پر اسکیلنگ کرتے وقت، لیمبڈا فنکشنز بالکل مائیکرو سروسز جیسا برتاؤ کرتے ہیں۔
نیکولس: آپ جتنی بھی نقلیں مرتب کریں گے، ان میں سے زیادہ ہوں گے؛ سرور لیس کو اسکیلنگ میں کوئی مسئلہ نہیں ہے۔ میں نے Kubernetes میں ایک ریپلیکا سیٹ بنایا، 20 مثالیں "کہیں" شروع کیں، اور 20 گمنام لنکس آپ کو واپس کر دیے گئے۔ آگے!
- کیا سرور لیس پر بیک اینڈ لکھنا ممکن ہے؟
اینڈریو: نظریاتی طور پر، لیکن اس کا کوئی مطلب نہیں ہے۔ لیمبڈا فنکشنز ایک ہی ذخیرہ پر انحصار کریں گے - ہمیں ضمانت کو یقینی بنانا ہوگا۔ مثال کے طور پر، اگر کسی صارف نے کوئی خاص لین دین کیا ہے، تو اگلی بار جب وہ رابطہ کرے تو اسے یہ دیکھنا چاہیے: لین دین مکمل ہو چکا ہے، فنڈز جمع ہو چکے ہیں۔ لیمبڈا کے تمام فنکشنز اس کال پر بلاک ہو جائیں گے۔ درحقیقت، سرور لیس فنکشنز کا ایک گروپ ڈیٹا بیس تک ایک رکاوٹ رسائی پوائنٹ کے ساتھ ایک ہی سروس میں بدل جائے گا۔
- کن حالات میں سرور لیس فن تعمیر کو استعمال کرنا معنی خیز ہے؟
اینڈریو: وہ کام جن کے لیے مشترکہ اسٹوریج کی ضرورت نہیں ہے - وہی کان کنی، بلاکچین۔ جہاں آپ کو بہت زیادہ گنتی کرنے کی ضرورت ہے۔ اگر آپ کے پاس کمپیوٹنگ کی بہت زیادہ طاقت ہے، تو آپ ایک فنکشن کی وضاحت کر سکتے ہیں جیسے "وہاں کسی چیز کی ہیش کا حساب لگائیں..." لیکن آپ ڈیٹا سٹوریج کے مسئلے کو حل کر سکتے ہیں، مثال کے طور پر، ایمیزون سے لیمبڈا فنکشنز اور ان کی تقسیم شدہ اسٹوریج۔ . اور پتہ چلا کہ آپ باقاعدہ خدمت لکھ رہے ہیں۔ لیمبڈا فنکشنز اسٹوریج تک رسائی حاصل کریں گے اور صارف کو کسی قسم کا جواب فراہم کریں گے۔
نیکولس: سرور لیس میں چلنے والے کنٹینرز وسائل میں انتہائی محدود ہیں۔ یادداشت کم ہے اور باقی سب کچھ۔ لیکن اگر آپ کا پورا انفراسٹرکچر مکمل طور پر کسی کلاؤڈ یعنی گوگل، ایمیزون پر تعینات ہے اور آپ کا ان کے ساتھ مستقل معاہدہ ہے، اس سب کے لیے ایک بجٹ ہے، تو کچھ کاموں کے لیے آپ سرور لیس کنٹینرز استعمال کر سکتے ہیں۔ اس بنیادی ڈھانچے کے اندر ہونا ضروری ہے، کیونکہ ہر چیز ایک مخصوص ماحول میں استعمال کے لیے تیار کی گئی ہے۔ یعنی، اگر آپ ہر چیز کو کلاؤڈ انفراسٹرکچر سے باندھنے کے لیے تیار ہیں، تو آپ تجربہ کر سکتے ہیں۔ فائدہ یہ ہے کہ آپ کو اس انفراسٹرکچر کو سنبھالنے کی ضرورت نہیں ہے۔
مکاؤ: حقیقت یہ ہے کہ سرور لیس آپ کو کبرنیٹس، ڈوکر، کافکا کو انسٹال کرنے، وغیرہ کا انتظام کرنے کی ضرورت نہیں ہے، خود فریبی ہے۔ وہی ایمیزون اور گوگل اسے انسٹال کر رہے ہیں۔ ایک اور چیز یہ ہے کہ آپ کے پاس SLA ہے۔ آپ خود کوڈ کرنے کے بجائے ہر چیز کو آؤٹ سورس کر سکتے ہیں۔
اینڈریو: سرور لیس خود سستا ہے، لیکن آپ کو ایمیزون کی دیگر خدمات کے لیے بہت زیادہ ادائیگی کرنی پڑتی ہے - مثال کے طور پر، ڈیٹا بیس۔ لوگ پہلے ہی ان پر مقدمہ کر چکے ہیں کیونکہ انہوں نے API گیٹ کے لیے پاگل رقم وصول کی تھی۔
مکاؤ: اگر ہم پیسے کے بارے میں بات کرتے ہیں، تو آپ کو اس نکتے کو مدنظر رکھنا ہوگا: آپ کو کمپنی میں تمام ترقیاتی طریقہ کار کو 180 ڈگری پر تبدیل کرنا پڑے گا تاکہ تمام کوڈ کو سرور لیس پر منتقل کیا جا سکے۔ اس میں بہت وقت اور پیسہ لگے گا۔
- کیا Amazon اور Google سے ادا شدہ Serverless کے لیے کوئی قابل متبادل متبادل ہیں؟
نیکولس: Kubernetes میں، آپ کسی قسم کا کام شروع کرتے ہیں، یہ چلتا ہے اور مر جاتا ہے - یہ تعمیراتی نقطہ نظر سے بالکل بے سرور ہے۔ اگر آپ قطاروں اور ڈیٹا بیس کے ساتھ واقعی دلچسپ کاروباری منطق بنانا چاہتے ہیں، تو آپ کو اس کے بارے میں کچھ اور سوچنے کی ضرورت ہے۔ یہ سب Kubernetes کو چھوڑے بغیر حل کیا جا سکتا ہے۔ میں اضافی نفاذ کو گھسیٹنے کی زحمت نہیں کروں گا۔
- سرور لیس میں کیا ہو رہا ہے اس کی نگرانی کرنا کتنا ضروری ہے؟
مکاؤ: نظام کے فن تعمیر اور کاروباری ضروریات پر منحصر ہے۔ بنیادی طور پر، فراہم کنندہ کو لازمی طور پر رپورٹنگ فراہم کرنی چاہیے جس سے ڈیوپس ٹیم کو ممکنہ مسائل کو سمجھنے میں مدد ملے گی۔
نیکولس: Amazon کے پاس CloudWatch ہے، جہاں تمام لاگز سٹریم کیے جاتے ہیں، بشمول Lambda کے۔ لاگ فارورڈنگ کو انٹیگریٹ کریں اور دیکھنے، الرٹ کرنے وغیرہ کے لیے ایک الگ ٹول استعمال کریں۔ آپ ایجنٹوں کو کنٹینرز میں بھر سکتے ہیں جو آپ شروع کرتے ہیں۔
- آئیے اس کا خلاصہ کرتے ہیں۔
اینڈریو: لیمبڈا کے افعال کے بارے میں سوچنا مفید ہے۔ اگر آپ خود ایک سروس بناتے ہیں - مائیکرو سروس نہیں، بلکہ وہ جو درخواست لکھتی ہے، ڈیٹا بیس تک رسائی حاصل کرتی ہے اور جواب بھیجتی ہے - لیمبڈا فنکشن کئی مسائل کو حل کرتا ہے: ملٹی تھریڈنگ، اسکیل ایبلٹی، وغیرہ کے ساتھ۔ اگر آپ کی منطق اس طرح بنتی ہے، تو مستقبل میں آپ ان Lambdas کو مائیکرو سروسز میں منتقل کر سکیں گے یا Amazon جیسی تھرڈ پارٹی سروسز استعمال کر سکیں گے۔ ٹیکنالوجی مفید ہے، خیال دلچسپ ہے۔ کاروبار کے لیے یہ کتنا جائز ہے اب بھی ایک کھلا سوال ہے۔
نکولے: سرور لیس کا استعمال کچھ کاروباری منطق کا حساب لگانے کے بجائے آپریشن کے کاموں کے لیے بہتر ہے۔ میں ہمیشہ اسے ایونٹ پروسیسنگ کے طور پر سوچتا ہوں۔ اگر آپ کے پاس ایمیزون میں ہے، اگر آپ کبرنیٹس میں ہیں، ہاں۔ بصورت دیگر، آپ کو سرور لیس حاصل کرنے اور اپنے طور پر چلانے کے لیے کافی محنت کرنی پڑے گی۔ یہ ایک مخصوص کاروباری کیس کو دیکھنے کے لئے ضروری ہے. مثال کے طور پر، اب میرے کاموں میں سے ایک یہ ہے: جب فائلیں کسی مخصوص فارمیٹ میں ڈسک پر ظاہر ہوتی ہیں، تو مجھے انہیں کافکا پر اپ لوڈ کرنے کی ضرورت ہوتی ہے۔ میں واچ ڈاگ یا لیمبڈا استعمال کر سکتا ہوں۔ منطقی نقطہ نظر سے، دونوں اختیارات موزوں ہیں، لیکن نفاذ کے لحاظ سے، سرور لیس زیادہ پیچیدہ ہے، اور میں لیمبڈا کے بغیر، آسان طریقہ کو ترجیح دیتا ہوں۔
مکاؤ: سرور لیس ایک دلچسپ، قابل اطلاق، اور تکنیکی لحاظ سے بہت خوبصورت خیال ہے۔ جلد یا بدیر، ٹیکنالوجی اس مقام تک پہنچ جائے گی جہاں کوئی بھی فنکشن 100 ملی سیکنڈ سے بھی کم وقت میں شروع کیا جائے گا۔ اس کے بعد، اصولی طور پر، اس بارے میں کوئی سوال نہیں ہوگا کہ آیا صارف کے لیے انتظار کا وقت اہم ہے۔ ایک ہی وقت میں، سرور لیس کا اطلاق، جیسا کہ ساتھیوں نے پہلے ہی کہا ہے، مکمل طور پر کاروباری مسئلے پر منحصر ہے۔
ہم اپنے سپانسرز کا شکریہ ادا کرتے ہیں جنہوں نے ہماری بہت مدد کی:
- آئی ٹی کانفرنس کی جگہ »»کانفرنس سائٹ کے لیے۔
- IT واقعات کا کیلنڈر اور اشاعت"»معلومات کی حمایت اور خبروں کے لیے۔
- «"تحائف کے لیے۔
- مشترکہ تخلیق کے لیے۔
- "ایسوسی ایشن برائے الیکٹرانک کمیونیکیشن" شمولیت اور تجربے کے لیے۔
- مین اسپانسر - سب کے لیے!
ماخذ: www.habr.com