کام کرنے والی ویڈیو سروس کی تیز رفتار ترقی کے لیے بے سرور اپروچ

میں آؤٹ سورسنگ میں کام کرتا ہوں، جہاں بنیادی اصول کو اس جملے سے بیان کیا جا سکتا ہے "بہت زیادہ فروخت کرو، جلدی کرو۔" جتنی تیزی سے ہم یہ کریں گے، اتنا ہی زیادہ کمائیں گے۔ اور، یہ ضروری ہے کہ ہر چیز بیساکھیوں اور چھینٹے پر نہیں بلکہ قابل قبول معیار کے ساتھ کام کرتی ہے۔ میں آپ کو اپنے تجربے کے بارے میں بتاؤں گا جب مختصر مدت میں پروموشنل سروس تیار کرنا ضروری تھا۔

دیئے گئے: AWS پر روٹ اکاؤنٹ، ٹیکنالوجی اسٹیک کے انتخاب پر کوئی پابندی نہیں، ایک بیک اینڈ، اور ترقی کے لیے ایک ماہ۔

ٹاسک: ایک پروموشنل سروس کو نافذ کریں جہاں صارف ایک سے چار ویڈیوز اپ لوڈ کرتے ہیں جو ایک سے چار سیکنڈ تک جاری رہتی ہے، جو پھر اصل ویڈیو سیریز میں سرایت کر جاتی ہیں۔

حل

اتنے کم وقت میں اپنی سائیکل سروس لکھنا اچھا خیال نہیں ہے۔ اس کے علاوہ، لوڈ سے نمٹنے کے لیے سروس کے لیے اور ہر ایک کو مطلوبہ ویڈیو حاصل کرنے کے لیے، انفراسٹرکچر کی ضرورت ہوگی۔ اور ترجیحی طور پر ہوائی جہاز سے قیمت کے ٹیگ کے ساتھ نہیں۔ لہذا، ہم فوری طور پر کم سے کم حسب ضرورت کے ساتھ تیار حل پر توجہ مرکوز کرتے ہیں۔

ویڈیو کے ساتھ کام کرنے کا معیاری حل FFmpeg ہے، ایک کراس پلیٹ فارم کنسول یوٹیلیٹی جو دلائل کے ذریعے آپ کو آڈیو کو کاٹنے اور اوورڈب کرنے کی اجازت دیتی ہے۔ بس ایک ریپر لکھنا اور اسے زندگی میں جاری کرنا باقی ہے۔ ہم ایک پروٹو ٹائپ لکھتے ہیں جو دو ویڈیوز کو ایک ساتھ سلائی کرتا ہے، اور... مزہ شروع ہوتا ہے۔ لائبریری .NET Core 2 پر مبنی ہے، اسے کسی بھی ورچوئل مشین پر چلنا چاہیے، اس لیے ہم AWS EC2 مثال لیتے ہیں اور سب کچھ کام کرے گا۔

پوشیدہ متننہیں، یہ کام نہیں کرے گا
.
اگرچہ FFmpeg کام کو آسان بناتا ہے، لیکن واقعی کام کرنے والے حل کے لیے آپ کو ایک EC2 مثال بنانے اور اس کے لیے ایک نیٹ ورک انفراسٹرکچر ڈیزائن کرنے کی ضرورت ہے، بشمول ایک لوڈ بیلنسر۔ شروع سے تعیناتی کا آسان کام "تھوڑا" زیادہ پیچیدہ ہو جاتا ہے، اور انفراسٹرکچر فوری طور پر رقم کا مطالبہ کرنا شروع کر دیتا ہے - ہر گھنٹے بعد کلائنٹ کے اکاؤنٹ سے رن ٹائم کی رقم نکال لی جاتی ہے۔

ہماری سروس میں طویل عرصے سے چلنے والے عمل شامل نہیں ہیں، اسے بڑے اور موٹے رشتہ دار ڈیٹا بیس کی ضرورت نہیں ہے، اور مائیکرو سروس کالز کے سلسلے کے ساتھ ایونٹ پر مبنی فن تعمیر میں بالکل فٹ بیٹھتی ہے۔ حل خود ہی تجویز کرتا ہے - ہم EC2 کو ترک کر سکتے ہیں اور AWS Lambda پر مبنی معیاری امیج ریسائزر کی طرح ایک حقیقی سرور لیس ایپلیکیشن نافذ کر سکتے ہیں۔

ویسے، .NET کے لیے AWS ڈویلپرز کی واضح ناپسندیدگی کے باوجود، وہ رن ٹائم کے طور پر .NET Core 2.1 کو سپورٹ کرتے ہیں، جو ترقی کے وسیع مواقع فراہم کرتا ہے۔

اور کیک پر چیری - AWS ویڈیو فائلوں کے ساتھ کام کرنے کے لیے ایک علیحدہ سروس فراہم کرتا ہے - AWS Elemental MediaConvert۔

کام کا نچوڑ ناقابل یقین حد تک آسان ہے: ہم باہر جانے والی ویڈیو کا S3 لنک لیتے ہیں، AWS Console، .NET SDK یا صرف JSON کے ذریعے لکھتے ہیں کہ ہم ویڈیو کے ساتھ کیا کرنا چاہتے ہیں اور سروس کو کال کرتے ہیں۔ یہ خود آنے والی درخواستوں پر کارروائی کے لیے قطاریں لگاتا ہے، نتیجہ خود S3 پر اپ لوڈ کرتا ہے اور سب سے اہم بات یہ ہے کہ ہر اسٹیٹس کی تبدیلی کے لیے ایک CloudWatch ایونٹ تیار کرتا ہے۔ یہ ہمیں ویڈیو پروسیسنگ مکمل کرنے کے لیے لیمبڈا ٹرگرز کو لاگو کرنے کی اجازت دیتا ہے۔

یہ حتمی فن تعمیر کی طرح دکھتا ہے:

پورا پسدید دو لیمبڈا میں رکھا ہوا ہے۔ دوسرا عمودی ویڈیوز کو گھمانے کے لیے ہے، کیونکہ ایسا کام ایک پاس میں نہیں کیا جا سکتا۔

ہم سامنے کو ایک SPA ایپلیکیشن کی شکل میں رکھیں گے جو JS میں لکھی گئی ہے اور ایک عوامی S3 بالٹی میں pug کے ذریعے مرتب کی گئی ہے۔ خود ویڈیوز ڈاؤن لوڈ کرنے کے لیے، ہمیں کسی سرور کوڈ کی ضرورت نہیں ہے - ہمیں صرف REST اینڈ پوائنٹس کو کھولنے کی ضرورت ہے جو S3 ہمیں فراہم کرتا ہے۔ صرف ایک چیز یہ ہے کہ پالیسیوں اور CORS کو ترتیب دینا نہ بھولیں۔

نقصانات

• AWS MediaConvert، کسی نامعلوم وجہ سے، صرف ہر ویڈیو کے ٹکڑے پر الگ الگ آواز کا اطلاق ہوتا ہے، لیکن ہمیں پورے اسکرین سیور سے ایک خوشگوار گانا چاہیے۔
• عمودی ویڈیوز کو الگ سے پروسیس کرنے کی ضرورت ہے۔ AWS سیاہ سلاخوں کو پسند نہیں کرتا اور رولرس کو 90° پر رکھتا ہے۔

آسان سکیٹنگ رنک

سٹیٹ لیس کی تمام خوبصورتی کے باوجود، آپ کو ویڈیو کے ساتھ کیا کرنے کی ضرورت ہے اس پر نظر رکھنے کی ضرورت ہے: تیار شدہ ویڈیو کی ترتیب میں گلو یا آڈیو شامل کریں۔ خوش قسمتی سے، MediaConvert اپنے جابز کے ذریعے میٹا ڈیٹا کو منتقل کرنے کی حمایت کرتا ہے، اور ہم کسی بھی مرحلے پر اس میٹا ڈیٹا کو پارس کرتے ہوئے، "isMasterSoundJob" فارم کا ایک سادہ پرچم استعمال کر سکتے ہیں۔

سرور لیس بالکل NoOps کے ساتھ کام کرنے کی اجازت دیتا ہے - ایک ایسا طریقہ جو پراجیکٹ کے بنیادی ڈھانچے کے لیے ذمہ دار ایک علیحدہ ٹیم کی غیرضرورییت کو فرض کرتا ہے۔ لہذا، یہ ایک چھوٹا سا معاملہ تھا - ہم سسٹم ایڈمنسٹریٹرز کی شرکت کے بغیر AWS پر حل تعینات کرتے ہیں، جن کے پاس ہمیشہ کچھ نہ کچھ ہوتا ہے۔
اور اس سب کو تیز کرنے کے لیے، ہم AWS CloudFormation پر تعیناتی اسکرپٹ کو زیادہ سے زیادہ خودکار بناتے ہیں، جو آپ کو VS سے براہ راست ایک بٹن کے ساتھ تعینات کرنے کی اجازت دیتا ہے۔ نتیجے کے طور پر، کوڈ کی 200 لائنوں کی فائل آپ کو ایک تیار حل تیار کرنے کی اجازت دیتی ہے، حالانکہ CloudFormation کا نحو حیران کن ہو سکتا ہے اگر آپ اس کے عادی نہیں ہیں۔

مجموعی طور پر

بے سرور کوئی علاج نہیں ہے۔ لیکن یہ تین حدود کے ساتھ حالات میں زندگی کو بہت آسان بنا دے گا: "محدود وسائل — مختصر مدت — تھوڑی رقم۔"

بغیر سرور کے لیے موزوں ایپلی کیشنز کی خصوصیات

• طویل عرصے سے چلنے والے عمل کے بغیر۔ API گیٹ وے کی سخت حد 29 سیکنڈ ہے، لیمبڈا سخت حد 5 منٹ ہے۔
• واقعہ سے چلنے والے فن تعمیر کے ذریعہ بیان کیا گیا ہے۔
• SOA جیسے ڈھیلے جوڑے اجزاء میں ٹوٹ جاتا ہے۔
• آپ کی حالت کے ساتھ زیادہ کام کی ضرورت نہیں ہے؛
• .NET کور میں لکھا ہوا ہے۔ .NET فریم ورک کے ساتھ کام کرنے کے لیے، آپ کو اب بھی مناسب رن ٹائم کے ساتھ کم از کم Docker کی ضرورت ہوگی۔

سرور لیس اپروچ کے فوائد

• بنیادی ڈھانچے کے اخراجات کو کم کرتا ہے؛
• حل کی فراہمی کی لاگت کو کم کرتا ہے؛
• خودکار توسیع پذیری؛
• تکنیکی ترقی کے آخری کنارے پر ترقی۔

نقصانات، ایک مخصوص مثال کے ساتھ

• تقسیم شدہ ٹریسنگ اور لاگنگ - جزوی طور پر AWS X-Ray اور AWS CloudWatch کے ذریعے حل کیا گیا ہے۔
• تکلیف دہ ڈیبگنگ؛
• لوڈ نہ ہونے پر کولڈ سٹارٹ؛
• AWS صارف دشمن انٹرفیس ایک عالمگیر مسئلہ ہے :)

ماخذ: www.habr.com