ایسا لگتا ہے کہ آن لائن اشتہارات کا میدان تکنیکی طور پر زیادہ سے زیادہ ترقی یافتہ اور خودکار ہونا چاہیے۔ یقینا، کیونکہ اس طرح کے جنات اور ماہرین Yandex، Mail.Ru، گوگل اور فیس بک کے طور پر ان کے میدان میں کام کرتے ہیں. لیکن، جیسا کہ یہ نکلا، کمال کی کوئی حد نہیں ہے اور خودکار کرنے کے لیے ہمیشہ کچھ نہ کچھ ہوتا ہے۔
مواصلاتی گروپ Dentsu Aegis نیٹ ورک روس ڈیجیٹل ایڈورٹائزنگ مارکیٹ کا سب سے بڑا کھلاڑی ہے اور ٹیکنالوجی میں فعال طور پر سرمایہ کاری کر رہا ہے، اپنے کاروباری عمل کو بہتر اور خودکار بنانے کی کوشش کر رہا ہے۔ آن لائن ایڈورٹائزنگ مارکیٹ کے حل نہ ہونے والے مسائل میں سے ایک مختلف انٹرنیٹ پلیٹ فارمز سے اشتہاری مہمات کے اعدادوشمار جمع کرنے کا کام بن گیا ہے۔ اس مسئلے کا حل بالآخر ایک پروڈکٹ کی تخلیق میں نکلا۔ D1.Digital (دیوان کے طور پر پڑھیں)، جس ترقی کے بارے میں ہم بات کرنا چاہتے ہیں۔
کیوں؟
1. پراجیکٹ کے آغاز کے وقت، مارکیٹ میں ایک بھی تیار شدہ پروڈکٹ نہیں تھی جو اشتہاری مہمات کے اعدادوشمار کو خودکار بنانے کا مسئلہ حل کرتی ہو۔ اس کا مطلب یہ ہے کہ ہمارے سوا کوئی ہماری ضروریات پوری نہیں کرے گا۔
Improvado، Roistat، Supermetrics، SegmentStream جیسی خدمات پلیٹ فارمز، سوشل نیٹ ورکس اور گوگل اینالیٹیکس کے ساتھ انضمام کی پیشکش کرتی ہیں، اور تشہیری مہمات کے آسان تجزیہ اور کنٹرول کے لیے تجزیاتی ڈیش بورڈز بنانا بھی ممکن بناتی ہیں۔ اس سے پہلے کہ ہم نے اپنی مصنوعات تیار کرنا شروع کیں، ہم نے ان میں سے کچھ سسٹمز کو سائٹس سے ڈیٹا اکٹھا کرنے کے لیے استعمال کرنے کی کوشش کی، لیکن بدقسمتی سے، وہ ہمارے مسائل حل نہیں کر سکے۔
بنیادی مسئلہ یہ تھا کہ آزمائشی مصنوعات ڈیٹا کے ذرائع پر انحصار کرتی تھیں، سائٹ کے لحاظ سے پلیسمنٹ کے اعدادوشمار دکھاتی تھیں، اور اشتہاری مہمات پر اعداد و شمار کو جمع کرنے کی صلاحیت فراہم نہیں کرتی تھیں۔ اس نقطہ نظر نے ہمیں مختلف سائٹس کے اعدادوشمار کو ایک جگہ پر دیکھنے اور مجموعی طور پر مہم کی حالت کا تجزیہ کرنے کی اجازت نہیں دی۔
ایک اور عنصر یہ تھا کہ ابتدائی مراحل میں مصنوعات کا مقصد مغربی مارکیٹ تھا اور اس نے روسی سائٹس کے ساتھ انضمام کی حمایت نہیں کی۔ اور ان سائٹس کے لیے جن کے ساتھ انضمام نافذ کیا گیا تھا، تمام ضروری میٹرکس کو ہمیشہ کافی تفصیل کے ساتھ ڈاؤن لوڈ نہیں کیا جاتا تھا، اور انضمام ہمیشہ آسان اور شفاف نہیں ہوتا تھا، خاص طور پر جب کوئی ایسی چیز حاصل کرنا ضروری ہو جو سسٹم کے انٹرفیس میں نہ ہو۔
عام طور پر، ہم نے فریق ثالث کی مصنوعات کو اپنانے کا فیصلہ نہیں کیا، لیکن خود اپنی تیاری شروع کر دی...
2. آن لائن ایڈورٹائزنگ مارکیٹ ہر سال بڑھ رہی ہے، اور 2018 میں، اشتہاری بجٹ کے لحاظ سے، اس نے روایتی طور پر سب سے بڑی ٹی وی اشتہاری مارکیٹ کو پیچھے چھوڑ دیا۔ تو ایک پیمانہ ہے۔.
3. ٹی وی ایڈورٹائزنگ مارکیٹ کے برعکس، جہاں تجارتی اشتہارات کی فروخت پر اجارہ داری ہے، انٹرنیٹ پر مختلف سائز کی اشتہاری انوینٹری کے بہت سے انفرادی مالکان اپنے اشتہاری اکاؤنٹس کے ساتھ کام کر رہے ہیں۔ چونکہ ایک اشتہاری مہم، ایک اصول کے طور پر، ایک ہی وقت میں کئی سائٹوں پر چلتی ہے، اس لیے اشتہاری مہم کی حالت کو سمجھنے کے لیے ضروری ہے کہ تمام سائٹس سے رپورٹس اکٹھی کی جائیں اور انہیں ایک بڑی رپورٹ میں یکجا کیا جائے جو پوری تصویر دکھائے۔ اس کا مطلب ہے کہ اصلاح کے امکانات ہیں۔
4. ہمیں ایسا لگتا ہے کہ انٹرنیٹ پر اشتہاری انوینٹری کے مالکان کے پاس پہلے سے ہی اعداد و شمار جمع کرنے اور انہیں اشتہاری کھاتوں میں ظاہر کرنے کا بنیادی ڈھانچہ موجود ہے، اور وہ اس ڈیٹا کے لیے ایک API فراہم کر سکیں گے۔ اس کا مطلب یہ ہے کہ تکنیکی طور پر اسے نافذ کرنا ممکن ہے۔ چلو فوراً کہہ دیتے ہیں کہ یہ اتنا سادہ نہیں نکلا۔
عام طور پر، منصوبے کے نفاذ کے لیے تمام شرائط ہم پر واضح تھیں، اور ہم اس منصوبے کو زندہ کرنے کے لیے دوڑ پڑے...
عظیم منصوبہ
شروع کرنے کے لیے، ہم نے ایک مثالی نظام کا وژن تشکیل دیا:
- 1C کارپوریٹ سسٹم سے تشہیری مہمات خود بخود اس میں ان کے ناموں، ادوار، بجٹ اور مختلف پلیٹ فارمز پر تعیناتیوں کے ساتھ لوڈ ہو جائیں۔
- اشتہاری مہم کے اندر ہر جگہ کے تعین کے لیے، تمام ممکنہ اعدادوشمار خود بخود ان سائٹس سے ڈاؤن لوڈ کیے جائیں جہاں پلیسمنٹ ہو رہی ہے، جیسے نقوش، کلکس، ملاحظات وغیرہ۔
- کچھ تشہیری مہمات کو تھرڈ پارٹی مانیٹرنگ کا استعمال کرتے ہوئے نام نہاد ایڈسرونگ سسٹم جیسے Adriver، Weborama، DCM، وغیرہ کے ذریعے ٹریک کیا جاتا ہے۔ روس میں ایک صنعتی انٹرنیٹ میٹر بھی ہے - Mediascope کمپنی۔ ہمارے منصوبے کے مطابق، آزاد اور صنعتی نگرانی کا ڈیٹا خود بخود متعلقہ اشتہاری مہموں میں لوڈ ہونا چاہیے۔
- انٹرنیٹ پر زیادہ تر تشہیری مہمات کا مقصد مخصوص ٹارگٹ ایکشنز (خریداری، کال، ٹیسٹ ڈرائیو کے لیے سائن اپ وغیرہ) ہوتے ہیں، جنہیں گوگل اینالیٹکس کا استعمال کرتے ہوئے ٹریک کیا جاتا ہے، اور جن کے لیے اعدادوشمار بھی مہم کی حیثیت کو سمجھنے کے لیے اہم ہوتے ہیں اور ہمارے آلے میں لوڈ کیا جانا چاہئے.
پہلی لات گانٹھ ہے۔
سافٹ ویئر ڈویلپمنٹ کے لچکدار اصولوں (چست، تمام چیزوں) کے ساتھ ہماری وابستگی کو دیکھتے ہوئے، ہم نے پہلے ایک MVP تیار کرنے کا فیصلہ کیا اور پھر مطلوبہ ہدف کی طرف بار بار آگے بڑھنے کا فیصلہ کیا۔
ہم نے اپنی مصنوعات کی بنیاد پر MVP بنانے کا فیصلہ کیا۔ ڈینبو (ڈینسو ایجس نیٹ ورک بورڈ)جو کہ ہمارے کلائنٹس کی اشتہاری مہمات کے بارے میں عمومی معلومات کے ساتھ ایک ویب ایپلیکیشن ہے۔
MVP کے لیے، پراجیکٹ کو عملی جامہ پہنانے کے لحاظ سے زیادہ سے زیادہ آسان بنایا گیا۔ ہم نے انضمام کے لیے پلیٹ فارمز کی ایک محدود فہرست کا انتخاب کیا ہے۔ یہ اہم پلیٹ فارمز تھے، جیسے Yandex.Direct، Yandex.Display، RB.Mail، MyTarget، Adwords، DBM، VK، FB، اور ایڈور اور ویبورما کے اہم ایڈورنگ سسٹم۔
API کے ذریعے سائٹس پر اعداد و شمار تک رسائی کے لیے، ہم نے ایک اکائونٹ استعمال کیا۔ ایک کلائنٹ گروپ مینیجر جو اشتہاری مہم پر اعداد و شمار کا خودکار مجموعہ استعمال کرنا چاہتا تھا، اسے پہلے سائٹس پر ضروری اشتہاری مہمات تک رسائی پلیٹ فارم اکاؤنٹ کو سونپنی پڑتی تھی۔
اگلا سسٹم صارف ہے۔ ڈینبو ایک خاص فارمیٹ کی فائل کو ایکسل سسٹم میں اپ لوڈ کرنا پڑا، جس میں پلیسمنٹ (اشتہاری مہم، پلیٹ فارم، فارمیٹ، پلیسمنٹ کی مدت، منصوبہ بند اشارے، بجٹ، وغیرہ) اور متعلقہ اشتہاری مہموں کے شناخت کنندگان کے بارے میں تمام معلومات موجود تھیں۔ ایڈورنگ سسٹم میں سائٹس اور کاؤنٹرز۔
یہ واضح طور پر، خوفناک لگ رہا تھا:
ڈاؤن لوڈ کردہ ڈیٹا کو ایک ڈیٹا بیس میں محفوظ کیا گیا، اور پھر الگ الگ سروسز نے ان سے سائٹس پر مہم کے شناخت کنندگان کو اکٹھا کیا اور ان پر اعداد و شمار ڈاؤن لوڈ کیے ہیں۔
ہر سائٹ کے لیے، ایک علیحدہ ونڈوز سروس لکھی گئی تھی، جو دن میں ایک بار سائٹ کے API میں ایک سروس اکاؤنٹ کے تحت جاتی تھی اور مخصوص مہم آئی ڈیز کے اعداد و شمار ڈاؤن لوڈ کرتی تھی۔ اشتہاری نظام کے ساتھ بھی ایسا ہی ہوا۔
ڈاؤن لوڈ کردہ ڈیٹا انٹرفیس پر ایک چھوٹے سے کسٹم ڈیش بورڈ کی شکل میں ظاہر کیا گیا تھا۔
ہمارے لیے غیر متوقع طور پر، MVP نے کام کرنا شروع کر دیا اور انٹرنیٹ پر اشتہاری مہمات کے موجودہ اعدادوشمار کو ڈاؤن لوڈ کرنا شروع کر دیا۔ ہم نے کئی کلائنٹس پر سسٹم کو لاگو کیا، لیکن پیمانہ بنانے کی کوشش کرتے وقت ہمیں سنگین مسائل کا سامنا کرنا پڑا:
- بنیادی مسئلہ سسٹم میں لوڈ کرنے کے لیے ڈیٹا کی تیاری کی پیچیدگی تھی۔ نیز، پلیسمنٹ ڈیٹا کو لوڈ کرنے سے پہلے سختی سے طے شدہ فارمیٹ میں تبدیل کرنا تھا۔ ڈاؤن لوڈ فائل میں مختلف سائٹس سے ہستی کے شناخت کنندگان کو شامل کرنا ضروری تھا۔ ہمیں اس حقیقت کا سامنا ہے کہ تکنیکی طور پر غیر تربیت یافتہ صارفین کے لیے یہ بتانا بہت مشکل ہے کہ سائٹ پر ان شناخت کنندگان کو کہاں تلاش کرنا ہے اور فائل میں انہیں کہاں درج کرنے کی ضرورت ہے۔ سائٹس پر مہم چلانے والے محکموں میں ملازمین کی تعداد اور ٹرن اوور کو مدنظر رکھتے ہوئے، اس کے نتیجے میں ہماری جانب سے بہت زیادہ تعاون حاصل ہوا، جس سے ہم بالکل خوش نہیں تھے۔
- ایک اور مسئلہ یہ تھا کہ تمام اشتہاری پلیٹ فارمز میں دیگر اکاؤنٹس کو اشتہاری مہمات تک رسائی فراہم کرنے کا طریقہ کار نہیں تھا۔ لیکن یہاں تک کہ اگر ایک وفد کا طریقہ کار دستیاب تھا، تمام مشتہرین فریق ثالث کے اکاؤنٹس تک اپنی مہمات تک رسائی دینے کے لیے تیار نہیں تھے۔
- ایک اہم عنصر وہ غصہ تھا جو صارفین کے درمیان اس حقیقت سے پیدا ہوا کہ تمام منصوبہ بند اشارے اور پلیسمنٹ کی تفصیلات جو وہ پہلے ہی ہمارے 1C اکاؤنٹنگ سسٹم میں داخل کرتے ہیں، انہیں دوبارہ داخل ہونا چاہیے۔ ڈینبو.
اس سے ہمیں یہ خیال آیا کہ پلیسمنٹ کے بارے میں معلومات کا بنیادی ذریعہ ہمارا 1C سسٹم ہونا چاہیے، جس میں تمام ڈیٹا درست اور وقت پر درج کیا جاتا ہے (یہاں بات یہ ہے کہ انوائسز 1C ڈیٹا کی بنیاد پر تیار کی جاتی ہیں، لہذا 1C میں ڈیٹا کا درست اندراج ہر ایک کے پی آئی کی ترجیح ہے)۔ اس طرح نظام کا ایک نیا تصور سامنے آیا...
تصور
پہلا کام جو ہم نے کرنے کا فیصلہ کیا وہ یہ تھا کہ انٹرنیٹ پر اشتہاری مہمات کے اعدادوشمار جمع کرنے کے نظام کو ایک الگ پروڈکٹ میں الگ کرنا تھا۔ D1.Digital.
نئے تصور میں، ہم نے لوڈ کرنے کا فیصلہ کیا۔ D1.Digital 1C سے اشتہاری مہموں اور ان کے اندر جگہوں کے بارے میں معلومات، اور پھر سائٹس اور AdServing سسٹمز سے ان پلیسمنٹس کے اعدادوشمار حاصل کریں۔ اس سے صارفین کے لیے زندگی کو نمایاں طور پر آسان کرنا چاہیے تھا (اور ہمیشہ کی طرح، ڈویلپرز کے لیے مزید کام شامل کریں گے) اور سپورٹ کی مقدار کو کم کر دیں گے۔
پہلا مسئلہ جس کا ہمیں سامنا کرنا پڑا وہ ایک تنظیمی نوعیت کا تھا اور اس کا تعلق اس حقیقت سے تھا کہ ہمیں کوئی ایسی کلید یا نشان نہیں مل سکا جس کے ذریعے ہم مختلف نظاموں کی ہستیوں کا موازنہ 1C سے مہمات اور تقرریوں کے ساتھ کر سکیں۔ حقیقت یہ ہے کہ ہماری کمپنی میں عمل کو اس طرح سے ڈیزائن کیا گیا ہے کہ مختلف لوگوں (میڈیا پلانرز، خریداری وغیرہ) کے ذریعے اشتہاری مہمات مختلف نظاموں میں داخل کی جاتی ہیں۔
اس مسئلے کو حل کرنے کے لیے، ہمیں ایک انوکھی ہیشڈ کلید، DANBoID ایجاد کرنی پڑی، جو مختلف سسٹمز میں موجود اداروں کو آپس میں جوڑ دے گی، اور اسے ڈاؤن لوڈ کردہ ڈیٹا سیٹس میں کافی آسانی سے اور منفرد طریقے سے شناخت کیا جا سکتا ہے۔ یہ شناخت کنندہ ہر انفرادی جگہ کے لیے اندرونی 1C سسٹم میں تیار کیا جاتا ہے اور اسے تمام سائٹس اور تمام AdServing سسٹمز پر مہمات، پلیسمنٹ اور کاؤنٹرز میں منتقل کیا جاتا ہے۔ تمام جگہوں پر DANBoID ڈالنے کی مشق کو نافذ کرنے میں کچھ وقت لگا، لیکن ہم اسے کرنے میں کامیاب ہو گئے :)
پھر ہمیں پتہ چلا کہ تمام سائٹس کے پاس خود بخود اعدادوشمار جمع کرنے کے لیے API نہیں ہے، اور یہاں تک کہ جن کے پاس API ہے، وہ تمام ضروری ڈیٹا واپس نہیں کرتا ہے۔
اس مرحلے پر، ہم نے انضمام کے لیے پلیٹ فارمز کی فہرست کو نمایاں طور پر کم کرنے اور ان اہم پلیٹ فارمز پر توجہ مرکوز کرنے کا فیصلہ کیا جو زیادہ تر اشتہاری مہمات میں شامل ہیں۔ اس فہرست میں ایڈورٹائزنگ مارکیٹ کے تمام بڑے پلیئرز (Google, Yandex, Mail.ru)، سوشل نیٹ ورکس (VK، Facebook، Twitter)، بڑے AdServing اور تجزیاتی نظام (DCM، Adriver، Weborama، Google Analytics) اور دیگر پلیٹ فارمز شامل ہیں۔
ہم نے جو سائٹس منتخب کی ہیں ان میں سے زیادہ تر میں ایک API تھا جو ہمیں مطلوبہ میٹرکس فراہم کرتا ہے۔ ایسی صورتوں میں جہاں کوئی API نہیں تھا یا اس میں ضروری ڈیٹا نہیں تھا، ہم نے ڈیٹا لوڈ کرنے کے لیے روزانہ ہمارے دفتر کے ای میل پر بھیجی جانے والی رپورٹس کا استعمال کیا (کچھ سسٹمز میں اس طرح کی رپورٹس کو ترتیب دینا ممکن ہے، دوسروں میں ہم نے اس کی ترقی پر اتفاق کیا۔ ہمارے لیے ایسی رپورٹیں)۔
مختلف سائٹس سے ڈیٹا کا تجزیہ کرتے وقت، ہمیں پتہ چلا کہ اداروں کا درجہ بندی مختلف نظاموں میں یکساں نہیں ہے۔ مزید یہ کہ معلومات کو مختلف سسٹمز سے مختلف تفصیل سے ڈاؤن لوڈ کرنے کی ضرورت ہے۔
اس مسئلے کو حل کرنے کے لیے، SubDANBoID تصور تیار کیا گیا تھا۔ SubDANBoID کا آئیڈیا کافی آسان ہے، ہم سائٹ پر مہم کے مرکزی ادارے کو تیار کردہ DANBoID کے ساتھ نشان زد کرتے ہیں، اور ہم تمام نیسٹڈ اداروں کو منفرد سائٹ شناخت کنندگان کے ساتھ اپ لوڈ کرتے ہیں اور DANBoID اصول + پہلی سطح کے شناخت کنندہ کے مطابق SubDANBoID تشکیل دیتے ہیں۔ nested entity + دوسرے درجے کے nested entity کا شناخت کنندہ +... اس نقطہ نظر نے ہمیں مختلف سسٹمز میں اشتہاری مہموں کو جوڑنے اور ان پر تفصیلی اعدادوشمار ڈاؤن لوڈ کرنے کی اجازت دی۔
ہمیں مختلف پلیٹ فارمز پر مہمات تک رسائی کا مسئلہ بھی حل کرنا تھا۔ جیسا کہ ہم نے اوپر لکھا ہے، مہم تک رسائی کو ایک علیحدہ تکنیکی اکاؤنٹ تک سونپنے کا طریقہ کار ہمیشہ لاگو نہیں ہوتا ہے۔ لہذا، ہمیں ان ٹوکنز کو اپ ڈیٹ کرنے کے لیے ٹوکنز اور میکانزم کا استعمال کرتے ہوئے OAuth کے ذریعے خودکار اجازت کے لیے ایک بنیادی ڈھانچہ تیار کرنا تھا۔
بعد میں مضمون میں ہم حل کے فن تعمیر اور عمل درآمد کی تکنیکی تفصیلات کو مزید تفصیل سے بیان کرنے کی کوشش کریں گے۔
حل فن تعمیر 1.0
ایک نئی پروڈکٹ کا نفاذ شروع کرتے وقت، ہم نے سمجھا کہ ہمیں فوری طور پر نئی سائٹس کو جوڑنے کے امکانات فراہم کرنے کی ضرورت ہے، اس لیے ہم نے مائیکرو سروس آرکیٹیکچر کی راہ پر چلنے کا فیصلہ کیا۔
فن تعمیر کو ڈیزائن کرتے وقت، ہم نے تمام بیرونی سسٹمز - 1C، ایڈورٹائزنگ پلیٹ فارمز اور ایڈورٹائزنگ سسٹمز - کو الگ الگ سروسز میں الگ کیا۔
بنیادی خیال یہ ہے کہ سائٹس کے تمام کنیکٹرز ایک ہی API رکھتے ہیں اور وہ اڈاپٹر ہیں جو سائٹ API کو ایک ایسے انٹرفیس پر لاتے ہیں جو ہمارے لیے آسان ہو۔
ہماری پروڈکٹ کے مرکز میں ایک ویب ایپلیکیشن ہے، جو ایک یک سنگی ہے جسے اس طرح سے ڈیزائن کیا گیا ہے کہ اسے خدمات میں آسانی سے الگ کیا جا سکتا ہے۔ یہ ایپلیکیشن ڈاؤن لوڈ کیے گئے ڈیٹا پر کارروائی کرنے، مختلف سسٹمز سے اعدادوشمار جمع کرنے اور انہیں سسٹم کے صارفین کے سامنے پیش کرنے کے لیے ذمہ دار ہے۔
کنیکٹرز اور ویب ایپلیکیشن کے درمیان بات چیت کرنے کے لیے، ہمیں ایک اضافی سروس بنانا پڑی، جسے ہم کنیکٹر پراکسی کہتے ہیں۔ یہ سروس ڈسکوری اور ٹاسک شیڈیولر کے کام انجام دیتا ہے۔ یہ سروس ہر رات ہر کنیکٹر کے لیے ڈیٹا اکٹھا کرنے کے کام چلاتی ہے۔ سروس لیئر لکھنا میسج بروکر کو جوڑنے سے زیادہ آسان تھا، اور ہمارے لیے یہ ضروری تھا کہ نتیجہ جلد از جلد حاصل کیا جائے۔
سادگی اور ترقی کی رفتار کے لیے، ہم نے یہ بھی فیصلہ کیا کہ تمام سروسز ویب APIs ہوں گی۔ اس سے تصور کے ثبوت کو جلدی سے جمع کرنا اور اس بات کی تصدیق کرنا ممکن ہوا کہ پورا ڈیزائن کام کرتا ہے۔
ایک الگ، بلکہ پیچیدہ کام مختلف اکاؤنٹس سے ڈیٹا اکٹھا کرنے کے لیے رسائی کو ترتیب دینا تھا، جسے، جیسا کہ ہم نے فیصلہ کیا، صارفین کو ویب انٹرفیس کے ذریعے انجام دینا چاہیے۔ یہ دو الگ الگ مراحل پر مشتمل ہے: پہلے، صارف OAuth کے ذریعے اکاؤنٹ تک رسائی کے لیے ایک ٹوکن شامل کرتا ہے، اور پھر ایک مخصوص اکاؤنٹ سے کلائنٹ کے لیے ڈیٹا اکٹھا کرنے کو ترتیب دیتا ہے۔ OAuth کے ذریعے ایک ٹوکن حاصل کرنا ضروری ہے کیونکہ جیسا کہ ہم پہلے ہی لکھ چکے ہیں، سائٹ پر مطلوبہ اکاؤنٹ تک رسائی کو سونپنا ہمیشہ ممکن نہیں ہوتا ہے۔
سائٹس سے اکاؤنٹ منتخب کرنے کے لیے ایک عالمگیر طریقہ کار بنانے کے لیے، ہمیں کنیکٹرز API میں ایک طریقہ شامل کرنا تھا جو JSON اسکیما کو لوٹاتا ہے، جو کہ ایک ترمیم شدہ JSONEditor جزو کا استعمال کرتے ہوئے فارم میں پیش کیا جاتا ہے۔ اس طرح، صارفین ان اکاؤنٹس کو منتخب کرنے کے قابل تھے جہاں سے ڈیٹا ڈاؤن لوڈ کرنا ہے۔
سائٹس پر موجود درخواست کی حدود کی تعمیل کرنے کے لیے، ہم ترتیبات کے لیے درخواستوں کو ایک ٹوکن کے اندر جمع کرتے ہیں، لیکن ہم متوازی طور پر مختلف ٹوکن پر کارروائی کر سکتے ہیں۔
ہم نے MongoDB کو ویب ایپلیکیشن اور کنیکٹرز دونوں کے لیے بھرے ہوئے ڈیٹا کے لیے اسٹوریج کے طور پر منتخب کیا، جس نے ہمیں ترقی کے ابتدائی مراحل میں ڈیٹا ڈھانچے کے بارے میں زیادہ فکر نہ کرنے کی اجازت دی، جب ایپلیکیشن کا آبجیکٹ ماڈل ہر دوسرے دن تبدیل ہوتا ہے۔
ہمیں جلد ہی پتہ چلا کہ تمام ڈیٹا MongoDB میں ٹھیک نہیں بیٹھتا اور، مثال کے طور پر، روزانہ کے اعداد و شمار کو متعلقہ ڈیٹا بیس میں محفوظ کرنا زیادہ آسان ہے۔ لہذا، کنیکٹرز کے لیے جن کا ڈیٹا ڈھانچہ متعلقہ ڈیٹا بیس کے لیے زیادہ موزوں ہے، ہم نے PostgreSQL یا MS SQL سرور کو بطور اسٹوریج استعمال کرنا شروع کیا۔
منتخب فن تعمیر اور ٹیکنالوجیز نے ہمیں D1.Digital پروڈکٹ کو نسبتاً تیزی سے بنانے اور لانچ کرنے کی اجازت دی۔ پروڈکٹ ڈویلپمنٹ کے دو سالوں میں، ہم نے سائٹس سے 23 کنیکٹر تیار کیے، تھرڈ پارٹی APIs کے ساتھ کام کرنے کا انمول تجربہ حاصل کیا، مختلف سائٹس کے نقصانات سے بچنا سیکھا، جن میں سے ہر ایک کی اپنی تھی، کم از کم 3 کے API کی ترقی میں تعاون کیا۔ سائٹس، تقریباً 15 مہموں اور 000 سے زیادہ پلیسمنٹ کے لیے خود بخود ڈاؤن لوڈ ہونے والی معلومات، پروڈکٹ کے آپریشن پر صارفین سے بہت سارے فیڈ بیک اکٹھے کیے اور اس فیڈ بیک کی بنیاد پر پروڈکٹ کے مرکزی عمل کو کئی بار تبدیل کرنے میں کامیاب ہوئیں۔
حل فن تعمیر 2.0
ترقی کے آغاز کو دو سال گزر چکے ہیں۔ D1.Digital. سسٹم پر بوجھ میں مسلسل اضافہ اور زیادہ سے زیادہ نئے ڈیٹا ذرائع کے ظہور نے بتدریج موجودہ حل کے فن تعمیر میں مسائل کا انکشاف کیا۔
پہلا مسئلہ سائٹس سے ڈاؤن لوڈ کیے گئے ڈیٹا کی مقدار سے متعلق ہے۔ ہمیں اس حقیقت کا سامنا کرنا پڑا کہ سب سے بڑی سائٹس سے تمام ضروری ڈیٹا اکٹھا کرنے اور اپ ڈیٹ کرنے میں بہت زیادہ وقت لگنے لگا۔ مثال کے طور پر، AdRiver اشتہار دینے والے نظام سے ڈیٹا اکٹھا کرنے میں، جس کے ساتھ ہم زیادہ تر تقرریوں کے اعداد و شمار کو ٹریک کرتے ہیں، تقریباً 12 گھنٹے لگتے ہیں۔
اس مسئلے کو حل کرنے کے لیے، ہم نے سائٹس سے ڈیٹا ڈاؤن لوڈ کرنے کے لیے ہر قسم کی رپورٹس کا استعمال شروع کر دیا، ہم ان کے API کو سائٹس کے ساتھ مل کر تیار کرنے کی کوشش کر رہے ہیں تاکہ اس کے آپریشن کی رفتار ہماری ضروریات کو پورا کر سکے، اور جتنا ممکن ہو سکے ڈیٹا ڈاؤن لوڈ کو متوازی بنایا جائے۔
ایک اور مسئلہ ڈاؤن لوڈ کردہ ڈیٹا کی پروسیسنگ سے متعلق ہے۔ اب، جب تقرری کے نئے اعداد و شمار آتے ہیں، میٹرکس کی دوبارہ گنتی کا ایک کثیر مرحلہ عمل شروع کیا جاتا ہے، جس میں خام ڈیٹا لوڈ کرنا، ہر سائٹ کے لیے مجموعی میٹرکس کا حساب لگانا، مختلف ذرائع سے ڈیٹا کا ایک دوسرے سے موازنہ کرنا، اور مہم کے لیے سمری میٹرکس کا حساب لگانا شامل ہے۔ اس کی وجہ سے ویب ایپلیکیشن پر بہت زیادہ بوجھ پڑتا ہے جو تمام حساب کتاب کرتی ہے۔ کئی بار، دوبارہ گنتی کے عمل کے دوران، ایپلیکیشن نے سرور پر موجود تمام میموری استعمال کی، تقریباً 10-15 GB، جس نے سسٹم کے ساتھ صارفین کے کام پر سب سے زیادہ نقصان دہ اثر ڈالا۔
شناخت شدہ مسائل اور پروڈکٹ کی مزید ترقی کے لیے پرجوش منصوبوں نے ہمیں ایپلیکیشن کے فن تعمیر پر نظر ثانی کرنے کی ضرورت پیش کی۔
ہم نے کنیکٹر کے ساتھ شروع کیا۔
ہم نے دیکھا کہ تمام کنیکٹر ایک ہی ماڈل کے مطابق کام کرتے ہیں، اس لیے ہم نے ایک پائپ لائن فریم ورک بنایا جس میں کنیکٹر بنانے کے لیے آپ کو صرف مراحل کی منطق کو پروگرام کرنا تھا، باقی آفاقی تھا۔ اگر کچھ کنیکٹر کو بہتری کی ضرورت ہوتی ہے، تو ہم اسے فوری طور پر ایک نئے فریم ورک میں اسی وقت منتقل کرتے ہیں جب کنیکٹر کو بہتر کیا جا رہا ہو۔
اسی وقت، ہم نے Docker اور Kubernetes کے کنیکٹرز کو تعینات کرنا شروع کر دیا۔
ہم نے کافی عرصے تک کوبرنیٹس میں منتقل ہونے کا منصوبہ بنایا، CI/CD سیٹنگز کے ساتھ تجربہ کیا، لیکن حرکت صرف اس وقت شروع ہوئی جب ایک کنیکٹر، ایک خرابی کی وجہ سے، سرور پر 20 GB سے زیادہ میموری کو ختم کرنے لگا، جس سے عملی طور پر دوسرے عمل ختم ہو گئے۔ . تفتیش کے دوران، کنیکٹر کو کبرنیٹس کلسٹر میں منتقل کر دیا گیا، جہاں خرابی ٹھیک ہونے کے بعد بھی یہ بالآخر باقی رہا۔
بہت جلد ہم نے محسوس کیا کہ Kubernetes آسان تھا، اور چھ ماہ کے اندر ہم نے 7 کنیکٹرز اور کنیکٹر پراکسی، جو سب سے زیادہ وسائل استعمال کرتے ہیں، کو پروڈکشن کلسٹر میں منتقل کر دیا۔
کنیکٹرز کے بعد، ہم نے باقی ایپلیکیشن کے فن تعمیر کو تبدیل کرنے کا فیصلہ کیا۔
بنیادی مسئلہ یہ تھا کہ ڈیٹا کنیکٹرز سے پراکسیز میں بڑے بیچوں میں آتا ہے، اور پھر DANBoID کو مارتا ہے اور پروسیسنگ کے لیے مرکزی ویب ایپلیکیشن کو بھیجا جاتا ہے۔ میٹرکس کی دوبارہ گنتی کی بڑی تعداد کی وجہ سے، درخواست پر بہت زیادہ بوجھ ہے۔
یہ بھی کافی مشکل ثابت ہوا کہ انفرادی ڈیٹا اکٹھا کرنے والی ملازمتوں کی حالت کی نگرانی کرنا اور مرکزی ویب ایپلیکیشن کے کنیکٹرز کے اندر ہونے والی غلطیوں کی اطلاع دینا تاکہ صارفین دیکھ سکیں کہ کیا ہو رہا ہے اور کیوں ڈیٹا اکٹھا نہیں کیا جا رہا ہے۔
ان مسائل کو حل کرنے کے لیے، ہم نے فن تعمیر 2.0 تیار کیا۔
فن تعمیر کے نئے ورژن کے درمیان بنیادی فرق یہ ہے کہ ویب API کے بجائے، ہم خدمات کے درمیان پیغامات کا تبادلہ کرنے کے لیے RabbitMQ اور MassTransit لائبریری کا استعمال کرتے ہیں۔ ایسا کرنے کے لیے، ہمیں کنیکٹرز پراکسی کو تقریباً مکمل طور پر دوبارہ لکھنا پڑا، اسے کنیکٹرز ہب بنانا پڑا۔ نام تبدیل کر دیا گیا تھا کیونکہ سروس کا بنیادی کردار اب کنیکٹرز کو درخواستوں کو آگے بھیجنے اور پیچھے کرنے میں نہیں ہے، بلکہ کنیکٹرز سے میٹرکس کو جمع کرنے کا انتظام کرنا ہے۔
سنٹرل ویب ایپلیکیشن سے، ہم نے سائٹس سے پلیسمنٹ اور اعدادوشمار کے بارے میں معلومات کو الگ الگ سروسز میں الگ کیا، جس سے غیر ضروری دوبارہ گنتی سے چھٹکارا حاصل کرنا اور پلیسمنٹ کی سطح پر صرف پہلے سے حساب شدہ اور مجموعی اعدادوشمار کو اسٹور کرنا ممکن ہوا۔ ہم نے خام ڈیٹا کی بنیاد پر بنیادی اعدادوشمار کا حساب لگانے کے لیے منطق کو دوبارہ لکھا اور بہتر بنایا۔
ایک ہی وقت میں، ہم تمام سروسز اور ایپلیکیشنز کو Docker اور Kubernetes میں منتقل کر رہے ہیں تاکہ حل کو پیمانے پر آسان اور انتظام کرنے میں زیادہ آسان بنایا جا سکے۔
اب ہم کہاں ہیں
پروف آف تصور فن تعمیر 2.0 پروڈکٹ D1.Digital کنیکٹرز کے محدود سیٹ کے ساتھ آزمائشی ماحول میں تیار اور کام کرنا۔ بس یہ کرنا باقی رہ گیا ہے کہ ایک نئے پلیٹ فارم پر مزید 20 کنیکٹرز کو دوبارہ لکھیں، جانچ کریں کہ ڈیٹا صحیح طریقے سے لوڈ ہوا ہے اور تمام میٹرکس کا صحیح حساب لگایا گیا ہے، اور پورے ڈیزائن کو پروڈکشن میں رول آؤٹ کرنا ہے۔
درحقیقت، یہ عمل بتدریج ہوگا اور ہمیں ہر چیز کو کام کرنے کے لیے پرانے APIs کے ساتھ پسماندہ مطابقت چھوڑنی ہوگی۔
ہمارے فوری منصوبوں میں نئے کنیکٹرز کی ڈیولپمنٹ، نئے سسٹمز کے ساتھ انضمام اور منسلک سائٹس سے ڈاؤن لوڈ کردہ ڈیٹا کے سیٹ میں اضافی میٹرکس کا اضافہ اور ایڈورنگ سسٹم شامل ہیں۔
ہم مرکزی ویب ایپلیکیشن سمیت تمام ایپلیکیشنز کو Docker اور Kubernetes میں منتقل کرنے کا بھی ارادہ رکھتے ہیں۔ نئے فن تعمیر کے ساتھ مل کر، یہ استعمال شدہ وسائل کی تعیناتی، نگرانی اور کنٹرول کو نمایاں طور پر آسان بنائے گا۔
ایک اور خیال اعداد و شمار کو ذخیرہ کرنے کے لیے ڈیٹا بیس کے انتخاب کے ساتھ تجربہ کرنا ہے، جو فی الحال MongoDB میں محفوظ ہے۔ ہم نے پہلے ہی کئی نئے کنیکٹرز کو ایس کیو ایل ڈیٹا بیس میں منتقل کر دیا ہے، لیکن وہاں فرق تقریباً قابل توجہ نہیں ہے، اور دن کے حساب سے مجموعی اعدادوشمار کے لیے، جن کی من مانی مدت کے لیے درخواست کی جا سکتی ہے، فائدہ کافی سنگین ہو سکتا ہے۔
عام طور پر، منصوبے شاندار ہیں، آئیے آگے بڑھتے ہیں :)
آرٹیکل R&D Dentsu Aegis Network کے مصنفین روس: Georgy Ostapenko (میخائل کوٹسک ()
ماخذ: www.habr.com