আমরা কীভাবে অনলাইন সাইটগুলি থেকে বিজ্ঞাপন প্রচারের ডেটা সংগ্রহ করেছি (পণ্যের কাঁটাযুক্ত পথ)

মনে হচ্ছে অনলাইন বিজ্ঞাপনের ক্ষেত্রটি যতটা সম্ভব প্রযুক্তিগতভাবে উন্নত এবং স্বয়ংক্রিয় হওয়া উচিত। অবশ্যই, কারণ এই ধরনের দৈত্য এবং Yandex, Mail.Ru, Google এবং Facebook হিসাবে তাদের ক্ষেত্রের বিশেষজ্ঞরা সেখানে কাজ করে। কিন্তু, এটি পরিণত হয়েছে, পরিপূর্ণতার কোন সীমা নেই এবং সবসময় স্বয়ংক্রিয়ভাবে কিছু আছে।

উৎস

যোগাযোগ গ্রুপ ডেন্টসু এজিস নেটওয়ার্ক রাশিয়া ডিজিটাল বিজ্ঞাপনের বাজারের বৃহত্তম খেলোয়াড় এবং সক্রিয়ভাবে প্রযুক্তিতে বিনিয়োগ করছে, এর ব্যবসায়িক প্রক্রিয়াগুলিকে অপ্টিমাইজ এবং স্বয়ংক্রিয় করার চেষ্টা করছে৷ অনলাইন বিজ্ঞাপন বাজারের অমীমাংসিত সমস্যাগুলির মধ্যে একটি হল বিভিন্ন ইন্টারনেট প্ল্যাটফর্ম থেকে বিজ্ঞাপন প্রচারের পরিসংখ্যান সংগ্রহ করা। এই সমস্যার সমাধান শেষ পর্যন্ত একটি পণ্য তৈরির ফলে D1.ডিজিটাল (ডিভান হিসাবে পড়ুন), যার উন্নয়ন সম্পর্কে আমরা কথা বলতে চাই।

কেন?

1. প্রকল্প শুরুর সময়, বাজারে এমন একটি প্রস্তুত পণ্য ছিল না যা বিজ্ঞাপন প্রচারের পরিসংখ্যান সংগ্রহের স্বয়ংক্রিয় সমস্যার সমাধান করেছিল। এর মানে হল আমরা ছাড়া কেউ আমাদের চাহিদা পূরণ করবে না।

ইম্প্রোভাডো, রোইস্ট্যাট, সুপারমেট্রিক্স, সেগমেন্টস্ট্রিমের মতো পরিষেবাগুলি প্ল্যাটফর্ম, সোশ্যাল নেটওয়ার্ক এবং Google অ্যানালিটিক্সের সাথে একীকরণের প্রস্তাব দেয় এবং বিজ্ঞাপন প্রচারের সুবিধাজনক বিশ্লেষণ এবং নিয়ন্ত্রণের জন্য বিশ্লেষণাত্মক ড্যাশবোর্ড তৈরি করা সম্ভব করে। আমরা আমাদের পণ্য বিকাশ শুরু করার আগে, আমরা সাইটগুলি থেকে ডেটা সংগ্রহ করার জন্য এই সিস্টেমগুলির কিছু ব্যবহার করার চেষ্টা করেছি, কিন্তু, দুর্ভাগ্যবশত, তারা আমাদের সমস্যার সমাধান করতে পারেনি৷

প্রধান সমস্যাটি ছিল যে পরীক্ষিত পণ্যগুলি ডেটা উত্সের উপর নির্ভর করে, সাইটের দ্বারা স্থান নির্ধারণের পরিসংখ্যান প্রদর্শন করে এবং বিজ্ঞাপন প্রচারাভিযানে পরিসংখ্যান একত্রিত করার ক্ষমতা প্রদান করে না। এই পদ্ধতিটি আমাদেরকে এক জায়গায় বিভিন্ন সাইট থেকে পরিসংখ্যান দেখতে এবং সামগ্রিকভাবে প্রচারের অবস্থা বিশ্লেষণ করতে দেয়নি।

আরেকটি কারণ ছিল যে প্রাথমিক পর্যায়ে পণ্যগুলি পশ্চিমা বাজারের লক্ষ্য ছিল এবং রাশিয়ান সাইটগুলির সাথে একীকরণ সমর্থন করে না। এবং সেই সাইটগুলির জন্য যেগুলির সাথে ইন্টিগ্রেশন প্রয়োগ করা হয়েছিল, সমস্ত প্রয়োজনীয় মেট্রিক্স সর্বদা পর্যাপ্ত বিশদ সহ ডাউনলোড করা হত না এবং ইন্টিগ্রেশন সর্বদা সুবিধাজনক এবং স্বচ্ছ ছিল না, বিশেষত যখন সিস্টেম ইন্টারফেসে নেই এমন কিছু পাওয়ার প্রয়োজন ছিল।
সাধারণভাবে, আমরা তৃতীয় পক্ষের পণ্যগুলির সাথে খাপ খাইয়ে না নেওয়ার সিদ্ধান্ত নিয়েছি, কিন্তু আমাদের নিজস্ব বিকাশ শুরু করেছি...

2. অনলাইন বিজ্ঞাপনের বাজার প্রতি বছর বৃদ্ধি পাচ্ছে, এবং 2018 সালে, বিজ্ঞাপনের বাজেটের ক্ষেত্রে, এটি ঐতিহ্যগতভাবে বৃহত্তম টিভি বিজ্ঞাপনের বাজারকে ছাড়িয়ে গেছে। তাই একটি স্কেল আছে.

3. টিভি বিজ্ঞাপনের বাজারের বিপরীতে, যেখানে বাণিজ্যিক বিজ্ঞাপনের বিক্রয় একচেটিয়া হয়, সেখানে অনেকগুলি স্বতন্ত্র মালিকের বিজ্ঞাপনের ইনভেন্টরি রয়েছে যা ইন্টারনেটে তাদের নিজস্ব বিজ্ঞাপন অ্যাকাউন্টের সাথে কাজ করে। যেহেতু একটি বিজ্ঞাপন প্রচারাভিযান, একটি নিয়ম হিসাবে, একযোগে বেশ কয়েকটি সাইটে চলে, বিজ্ঞাপন প্রচারের অবস্থা বোঝার জন্য, সমস্ত সাইট থেকে প্রতিবেদন সংগ্রহ করা এবং সেগুলিকে একটি বড় প্রতিবেদনে একত্রিত করা প্রয়োজন যা পুরো চিত্রটি দেখাবে। এর মানে অপ্টিমাইজেশনের সম্ভাবনা রয়েছে।

4. আমাদের কাছে মনে হয়েছে যে ইন্টারনেটে বিজ্ঞাপনের তালিকার মালিকদের ইতিমধ্যে পরিসংখ্যান সংগ্রহ এবং বিজ্ঞাপন অ্যাকাউন্টে প্রদর্শনের জন্য পরিকাঠামো রয়েছে এবং তারা এই ডেটার জন্য একটি API প্রদান করতে সক্ষম হবে। এর মানে হল যে এটি বাস্তবায়ন করা প্রযুক্তিগতভাবে সম্ভব। আসুন এখনই বলি যে এটি এত সহজ নয়।

সাধারণভাবে, প্রকল্প বাস্তবায়নের জন্য সমস্ত পূর্বশর্তগুলি আমাদের কাছে সুস্পষ্ট ছিল, এবং আমরা প্রকল্পটিকে প্রাণবন্ত করার জন্য দৌড়েছি...

গ্র্যান্ড প্ল্যান

শুরু করার জন্য, আমরা একটি আদর্শ ব্যবস্থার একটি দৃষ্টিভঙ্গি তৈরি করেছি:

• 1C কর্পোরেট সিস্টেম থেকে বিজ্ঞাপন প্রচারগুলি স্বয়ংক্রিয়ভাবে তাদের নাম, সময়কাল, বাজেট এবং বিভিন্ন প্ল্যাটফর্মে প্লেসমেন্ট সহ এটিতে লোড হওয়া উচিত।
• একটি বিজ্ঞাপন প্রচারাভিযানের মধ্যে প্রতিটি প্লেসমেন্টের জন্য, সমস্ত সম্ভাব্য পরিসংখ্যান স্বয়ংক্রিয়ভাবে ডাউনলোড করা উচিত সাইট থেকে যেখানে প্লেসমেন্ট হচ্ছে, যেমন ইম্প্রেশনের সংখ্যা, ক্লিক, ভিউ ইত্যাদি।
• কিছু বিজ্ঞাপন প্রচারাভিযান তথাকথিত অ্যাডজারভিং সিস্টেম যেমন Adriver, Weborama, DCM, ইত্যাদি দ্বারা তৃতীয়-পক্ষ পর্যবেক্ষণ ব্যবহার করে ট্র্যাক করা হয়। রাশিয়ায় একটি শিল্প ইন্টারনেট মিটারও রয়েছে - মিডিয়াস্কোপ কোম্পানি। আমাদের পরিকল্পনা অনুযায়ী, স্বতন্ত্র এবং শিল্প পর্যবেক্ষণ থেকে ডেটা স্বয়ংক্রিয়ভাবে সংশ্লিষ্ট বিজ্ঞাপন প্রচারে লোড করা উচিত।
• ইন্টারনেটে বেশিরভাগ বিজ্ঞাপন প্রচারের লক্ষ্য নির্দিষ্ট লক্ষ্য ক্রিয়াকলাপ (ক্রয়, কল, একটি টেস্ট ড্রাইভের জন্য সাইন আপ, ইত্যাদি), যা গুগল অ্যানালিটিক্স ব্যবহার করে ট্র্যাক করা হয় এবং পরিসংখ্যান যা প্রচারাভিযানের অবস্থা বোঝার জন্যও গুরুত্বপূর্ণ এবং আমাদের টুলে লোড করা উচিত।

প্রথম প্যানকেক অলস

সফ্টওয়্যার বিকাশের নমনীয় নীতিগুলির প্রতি আমাদের প্রতিশ্রুতি দেওয়া (চটপট, সমস্ত জিনিস), আমরা প্রথমে একটি MVP বিকাশ করার এবং তারপরে উদ্দেশ্যমূলক লক্ষ্যের দিকে বারবার এগিয়ে যাওয়ার সিদ্ধান্ত নিয়েছি।
আমরা আমাদের পণ্যের উপর ভিত্তি করে এমভিপি তৈরি করার সিদ্ধান্ত নিয়েছি ড্যানবো (ডেন্টসু এজিস নেটওয়ার্ক বোর্ড), যা আমাদের ক্লায়েন্টদের বিজ্ঞাপন প্রচারের সাধারণ তথ্য সহ একটি ওয়েব অ্যাপ্লিকেশন।

MVP-এর জন্য, প্রকল্পটি বাস্তবায়নের ক্ষেত্রে যতটা সম্ভব সরলীকৃত করা হয়েছিল। আমরা ইন্টিগ্রেশনের জন্য প্ল্যাটফর্মের একটি সীমিত তালিকা নির্বাচন করেছি। এগুলি ছিল প্রধান প্ল্যাটফর্ম, যেমন Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, এবং প্রধান অ্যাডজারভিং সিস্টেম অ্যাড্রাইভার এবং ওয়েবোরামা৷

API এর মাধ্যমে সাইটে পরিসংখ্যান অ্যাক্সেস করতে, আমরা একটি একক অ্যাকাউন্ট ব্যবহার করেছি। একজন ক্লায়েন্ট গ্রুপ ম্যানেজার যিনি একটি বিজ্ঞাপন প্রচারে পরিসংখ্যানের স্বয়ংক্রিয় সংগ্রহ ব্যবহার করতে চেয়েছিলেন তাকে প্রথমে প্ল্যাটফর্ম অ্যাকাউন্টে সাইটগুলিতে প্রয়োজনীয় বিজ্ঞাপন প্রচারের অ্যাক্সেস অর্পণ করতে হয়েছিল।

পরবর্তী সিস্টেম ব্যবহারকারী ড্যানবো এক্সেল সিস্টেমে একটি নির্দিষ্ট বিন্যাসের একটি ফাইল আপলোড করতে হয়েছিল, যেখানে স্থান নির্ধারণ (বিজ্ঞাপন প্রচার, প্ল্যাটফর্ম, বিন্যাস, স্থান নির্ধারণের সময়কাল, পরিকল্পিত সূচক, বাজেট ইত্যাদি) এবং সংশ্লিষ্ট বিজ্ঞাপন প্রচারের শনাক্তকারী সম্পর্কে সমস্ত তথ্য রয়েছে। বিজ্ঞাপন সিস্টেমে সাইট এবং কাউন্টার।

এটা, স্পষ্টভাবে, ভয়ঙ্কর লাগছিল:

ডাউনলোড করা ডেটা একটি ডাটাবেসে সংরক্ষণ করা হয়েছিল, এবং তারপরে পৃথক পরিষেবাগুলি তাদের থেকে সাইটে প্রচারাভিযান সনাক্তকারী সংগ্রহ করেছিল এবং সেগুলির পরিসংখ্যান ডাউনলোড করেছিল।

প্রতিটি সাইটের জন্য, একটি পৃথক উইন্ডোজ পরিষেবা লেখা হয়েছিল, যা দিনে একবার সাইটের API-এ একটি পরিষেবা অ্যাকাউন্টের অধীনে চলে যায় এবং নির্দিষ্ট প্রচারাভিযান আইডিগুলির জন্য পরিসংখ্যান ডাউনলোড করে। একই জিনিস adserving সিস্টেমের সঙ্গে ঘটেছে.

ডাউনলোড করা ডেটা একটি ছোট কাস্টম ড্যাশবোর্ড আকারে ইন্টারফেসে প্রদর্শিত হয়েছিল:

আমাদের জন্য অপ্রত্যাশিতভাবে, MVP কাজ শুরু করে এবং ইন্টারনেটে বিজ্ঞাপন প্রচারের বর্তমান পরিসংখ্যান ডাউনলোড করা শুরু করে। আমরা বেশ কয়েকটি ক্লায়েন্টে সিস্টেমটি প্রয়োগ করেছি, কিন্তু স্কেল করার চেষ্টা করার সময়, আমরা গুরুতর সমস্যার সম্মুখীন হয়েছি:

• প্রধান সমস্যাটি ছিল সিস্টেমে লোড করার জন্য ডেটা প্রস্তুত করার জটিলতা। এছাড়াও, প্লেসমেন্ট ডেটা লোড করার আগে একটি কঠোরভাবে স্থির বিন্যাসে রূপান্তর করতে হয়েছিল। ডাউনলোড ফাইলে বিভিন্ন সাইট থেকে সত্তা শনাক্তকারী অন্তর্ভুক্ত করা প্রয়োজন ছিল। আমরা এই সত্যটির মুখোমুখি হয়েছি যে প্রযুক্তিগতভাবে অপ্রশিক্ষিত ব্যবহারকারীদের জন্য সাইটে এই শনাক্তকারীগুলি কোথায় পাওয়া যাবে এবং ফাইলে কোথায় প্রবেশ করা দরকার তা ব্যাখ্যা করা খুব কঠিন। সাইটগুলিতে প্রচারাভিযান চালানো বিভাগের কর্মচারীর সংখ্যা এবং টার্নওভার বিবেচনা করে, এর ফলে আমাদের পক্ষে প্রচুর পরিমাণে সমর্থন এসেছে, যা আমরা একেবারেই খুশি ছিলাম না।
• আরেকটি সমস্যা ছিল যে সমস্ত বিজ্ঞাপন প্ল্যাটফর্মে অন্য অ্যাকাউন্টে বিজ্ঞাপন প্রচারের অ্যাক্সেস অর্পণ করার জন্য ব্যবস্থা ছিল না। কিন্তু একটি প্রতিনিধিত্ব ব্যবস্থা উপলব্ধ থাকলেও, সমস্ত বিজ্ঞাপনদাতা তৃতীয় পক্ষের অ্যাকাউন্টগুলিতে তাদের প্রচারাভিযানের অ্যাক্সেস দিতে ইচ্ছুক ছিল না।
• একটি গুরুত্বপূর্ণ ফ্যাক্টর ছিল ব্যবহারকারীদের মধ্যে এই ক্ষোভের সৃষ্টি করেছিল যে সমস্ত পরিকল্পিত সূচক এবং স্থান নির্ধারণের বিবরণ যা তারা ইতিমধ্যেই আমাদের 1C অ্যাকাউন্টিং সিস্টেমে প্রবেশ করেছে, তাদের অবশ্যই পুনরায় প্রবেশ করতে হবে ড্যানবো.

এটি আমাদের ধারণা দিয়েছে যে প্লেসমেন্ট সম্পর্কে তথ্যের প্রাথমিক উত্সটি আমাদের 1C সিস্টেম হওয়া উচিত, যাতে সমস্ত ডেটা সঠিকভাবে এবং সময়মতো প্রবেশ করানো হয় (এখানে পয়েন্টটি হল যে চালানগুলি 1C ডেটার উপর ভিত্তি করে তৈরি করা হয়, তাই 1C-তে ডেটার সঠিক প্রবেশ) প্রত্যেকের জন্য একটি অগ্রাধিকার KPI)। এইভাবে সিস্টেমের একটি নতুন ধারণা আবির্ভূত হয়েছে ...

ধারণা

প্রথম জিনিসটি আমরা করার সিদ্ধান্ত নিয়েছিলাম ইন্টারনেটে বিজ্ঞাপন প্রচারের পরিসংখ্যান সংগ্রহের জন্য সিস্টেমটিকে আলাদা পণ্যে আলাদা করা - D1.ডিজিটাল.

নতুন ধারণায়, আমরা লোড করার সিদ্ধান্ত নিয়েছি D1.ডিজিটাল 1C থেকে বিজ্ঞাপন প্রচারাভিযান এবং তাদের মধ্যে প্লেসমেন্টের তথ্য, এবং তারপর সাইট এবং অ্যাডসার্ভিং সিস্টেম থেকে এই প্লেসমেন্টে পরিসংখ্যান সংগ্রহ করুন। এটি ব্যবহারকারীদের জন্য জীবনকে উল্লেখযোগ্যভাবে সহজ করার কথা ছিল (এবং যথারীতি, ডেভেলপারদের আরও কাজ যোগ করুন) এবং সমর্থনের পরিমাণ কমাতে হবে।

আমরা যে প্রথম সমস্যাটির সম্মুখীন হয়েছিলাম তা ছিল একটি সাংগঠনিক প্রকৃতির এবং এটির সাথে সম্পর্কিত যে আমরা একটি কী বা চিহ্ন খুঁজে পাইনি যার দ্বারা আমরা 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 গঠন করি নেস্টেড সত্তা + দ্বিতীয় স্তরের নেস্টেড সত্তার শনাক্তকারী +... এই পদ্ধতিটি আমাদেরকে বিভিন্ন সিস্টেমে বিজ্ঞাপন প্রচারগুলিকে সংযুক্ত করতে এবং সেগুলির উপর বিস্তারিত পরিসংখ্যান ডাউনলোড করতে দেয়।

আমাদের বিভিন্ন প্ল্যাটফর্মে প্রচারাভিযানের অ্যাক্সেসের সমস্যাও সমাধান করতে হয়েছিল। যেমনটি আমরা উপরে লিখেছি, একটি পৃথক প্রযুক্তিগত অ্যাকাউন্টে একটি প্রচারাভিযানের অ্যাক্সেস অর্পণ করার পদ্ধতি সর্বদা প্রযোজ্য নয়। তাই, এই টোকেনগুলি আপডেট করার জন্য আমাদের টোকেন এবং প্রক্রিয়া ব্যবহার করে OAuth-এর মাধ্যমে স্বয়ংক্রিয় অনুমোদনের জন্য একটি পরিকাঠামো তৈরি করতে হয়েছিল।

পরবর্তীতে নিবন্ধে আমরা সমাধানের আর্কিটেকচার এবং বাস্তবায়নের প্রযুক্তিগত বিবরণ আরও বিশদে বর্ণনা করার চেষ্টা করব।

সমাধান আর্কিটেকচার 1.0

একটি নতুন পণ্যের বাস্তবায়ন শুরু করার সময়, আমরা বুঝতে পেরেছিলাম যে আমাদের অবিলম্বে নতুন সাইটগুলিকে সংযুক্ত করার সম্ভাবনা সরবরাহ করতে হবে, তাই আমরা মাইক্রোসার্ভিস আর্কিটেকচারের পথ অনুসরণ করার সিদ্ধান্ত নিয়েছি।

আর্কিটেকচার ডিজাইন করার সময়, আমরা সমস্ত বাহ্যিক সিস্টেম - 1C, বিজ্ঞাপন প্ল্যাটফর্ম এবং অ্যাডজারভিং সিস্টেম - আলাদা পরিষেবাগুলিতে সংযোগকারীগুলিকে আলাদা করেছি৷
মূল ধারণা হল যে সাইটগুলির সমস্ত সংযোগকারীর একই API রয়েছে এবং সেগুলি অ্যাডাপ্টার যা আমাদের জন্য সুবিধাজনক একটি ইন্টারফেসে সাইট API নিয়ে আসে৷

আমাদের পণ্যের কেন্দ্রে একটি ওয়েব অ্যাপ্লিকেশন রয়েছে, যা একটি মনোলিথ যা এমনভাবে ডিজাইন করা হয়েছে যাতে এটি সহজেই পরিষেবাগুলিতে বিচ্ছিন্ন করা যায়। এই অ্যাপ্লিকেশনটি ডাউনলোড করা ডেটা প্রক্রিয়াকরণ, বিভিন্ন সিস্টেম থেকে পরিসংখ্যান সংগ্রহ এবং সিস্টেম ব্যবহারকারীদের কাছে উপস্থাপন করার জন্য দায়ী৷

সংযোগকারী এবং ওয়েব অ্যাপ্লিকেশনের মধ্যে যোগাযোগ করার জন্য, আমাদের একটি অতিরিক্ত পরিষেবা তৈরি করতে হয়েছিল, যাকে আমরা সংযোগকারী প্রক্সি বলে থাকি। এটি সার্ভিস ডিসকভারি এবং টাস্ক শিডিউলারের কার্য সম্পাদন করে। এই পরিষেবাটি প্রতি রাতে প্রতিটি সংযোগকারীর জন্য ডেটা সংগ্রহের কাজ চালায়। একটি পরিষেবা স্তর লেখা একটি বার্তা ব্রোকার সংযোগ করার চেয়ে সহজ ছিল, এবং আমাদের জন্য এটি যত তাড়াতাড়ি সম্ভব ফলাফল পাওয়া গুরুত্বপূর্ণ ছিল.

সরলতা এবং বিকাশের গতির জন্য, আমরা সিদ্ধান্ত নিয়েছি যে সমস্ত পরিষেবা ওয়েব API হবে৷ এটি দ্রুত একটি প্রুফ-অফ-কনসেপ্ট একত্রিত করা এবং সম্পূর্ণ ডিজাইন কাজ করে কিনা তা যাচাই করা সম্ভব করেছে।

একটি পৃথক, বরং জটিল কাজটি ছিল বিভিন্ন অ্যাকাউন্ট থেকে ডেটা সংগ্রহের অ্যাক্সেস সেট আপ করা, যা আমরা সিদ্ধান্ত নিয়েছি, ওয়েব ইন্টারফেসের মাধ্যমে ব্যবহারকারীদের দ্বারা সম্পন্ন করা উচিত। এটি দুটি পৃথক পদক্ষেপ নিয়ে গঠিত: প্রথমত, ব্যবহারকারী OAuth এর মাধ্যমে অ্যাকাউন্ট অ্যাক্সেস করার জন্য একটি টোকেন যোগ করে এবং তারপর একটি নির্দিষ্ট অ্যাকাউন্ট থেকে ক্লায়েন্টের জন্য ডেটা সংগ্রহ কনফিগার করে। OAuth এর মাধ্যমে একটি টোকেন প্রাপ্ত করা প্রয়োজন কারণ, আমরা ইতিমধ্যেই লিখেছি, সাইটে পছন্দসই অ্যাকাউন্টে অ্যাক্সেস অর্পণ করা সবসময় সম্ভব নয়।

সাইটগুলি থেকে একটি অ্যাকাউন্ট নির্বাচন করার জন্য একটি সর্বজনীন প্রক্রিয়া তৈরি করতে, আমাদের সংযোগকারী API-এ একটি পদ্ধতি যুক্ত করতে হয়েছিল যা JSON স্কিমা প্রদান করে, যা একটি পরিবর্তিত JSONEditor উপাদান ব্যবহার করে একটি ফর্মে রেন্ডার করা হয়৷ এইভাবে, ব্যবহারকারীরা যে অ্যাকাউন্টগুলি থেকে ডেটা ডাউনলোড করতে চান তা নির্বাচন করতে সক্ষম হয়েছিল৷

সাইটগুলিতে বিদ্যমান অনুরোধ সীমা মেনে চলার জন্য, আমরা একটি টোকেনের মধ্যে সেটিংসের জন্য অনুরোধগুলিকে একত্রিত করি, তবে আমরা সমান্তরালভাবে বিভিন্ন টোকেন প্রক্রিয়া করতে পারি।

আমরা ওয়েব অ্যাপ্লিকেশন এবং সংযোগকারী উভয়ের জন্য লোড করা ডেটার স্টোরেজ হিসাবে MongoDB বেছে নিয়েছি, যা আমাদের ডেভেলপমেন্টের প্রাথমিক পর্যায়ে ডেটা স্ট্রাকচার সম্পর্কে খুব বেশি চিন্তা করতে দেয় না, যখন অ্যাপ্লিকেশনটির অবজেক্ট মডেল প্রতি দিন পরিবর্তন হয়।

আমরা শীঘ্রই জানতে পেরেছি যে সমস্ত ডেটা MongoDB-তে ভালভাবে খাপ খায় না এবং উদাহরণস্বরূপ, একটি রিলেশনাল ডাটাবেসে দৈনিক পরিসংখ্যান সংরক্ষণ করা আরও সুবিধাজনক। অতএব, সংযোগকারীর জন্য যাদের ডেটা স্ট্রাকচার রিলেশনাল ডাটাবেসের জন্য বেশি উপযুক্ত, আমরা PostgreSQL বা MS SQL সার্ভার স্টোরেজ হিসেবে ব্যবহার করা শুরু করেছি।

বাছাই করা স্থাপত্য এবং প্রযুক্তি আমাদেরকে D1.Digital পণ্যটি তুলনামূলকভাবে দ্রুত নির্মাণ ও চালু করার অনুমতি দিয়েছে। প্রোডাক্ট ডেভেলপমেন্টের দুই বছর ধরে, আমরা সাইটে 23টি কানেক্টর ডেভেলপ করেছি, থার্ড-পার্টি API-এর সাথে কাজ করার অমূল্য অভিজ্ঞতা অর্জন করেছি, বিভিন্ন সাইটের সমস্যাগুলি এড়াতে শিখেছি, যার প্রতিটির নিজস্ব ছিল, অন্তত 3টির API-এর বিকাশে অবদান রেখেছি। সাইটগুলি, প্রায় 15 প্রচারাভিযানের এবং 000 টিরও বেশি প্লেসমেন্টের জন্য স্বয়ংক্রিয়ভাবে তথ্য ডাউনলোড করেছে, পণ্যটির অপারেশনে ব্যবহারকারীদের কাছ থেকে প্রচুর প্রতিক্রিয়া সংগ্রহ করেছে এবং এই প্রতিক্রিয়ার ভিত্তিতে পণ্যটির মূল প্রক্রিয়াটি বেশ কয়েকবার পরিবর্তন করতে পরিচালিত হয়েছে।

সমাধান আর্কিটেকচার 2.0

উন্নয়ন শুরুর পর দুই বছর কেটে গেছে D1.ডিজিটাল. সিস্টেমে লোডের ক্রমাগত বৃদ্ধি এবং আরও নতুন ডেটা উত্সের উত্থান ধীরে ধীরে বিদ্যমান সমাধান আর্কিটেকচারে সমস্যাগুলি প্রকাশ করে।

প্রথম সমস্যাটি সাইটগুলি থেকে ডাউনলোড করা ডেটার পরিমাণের সাথে সম্পর্কিত। আমরা এই সত্যটির মুখোমুখি হয়েছিলাম যে বৃহত্তম সাইটগুলি থেকে সমস্ত প্রয়োজনীয় ডেটা সংগ্রহ এবং আপডেট করতে খুব বেশি সময় লাগতে শুরু করে। উদাহরণস্বরূপ, AdRiver অ্যাডজারভিং সিস্টেম থেকে ডেটা সংগ্রহ করতে, যার সাহায্যে আমরা বেশিরভাগ প্লেসমেন্টের পরিসংখ্যান ট্র্যাক করি, প্রায় 12 ঘন্টা সময় নেয়৷

এই সমস্যাটি সমাধানের জন্য, আমরা সাইটগুলি থেকে ডেটা ডাউনলোড করার জন্য সমস্ত ধরণের রিপোর্ট ব্যবহার শুরু করেছি, আমরা সাইটগুলির সাথে তাদের API তৈরি করার চেষ্টা করছি যাতে এটির অপারেশনের গতি আমাদের চাহিদা পূরণ করে এবং যতটা সম্ভব ডেটা ডাউনলোডকে সমান্তরাল করে।

আরেকটি সমস্যা ডাউনলোড করা ডেটা প্রক্রিয়াকরণের সাথে সম্পর্কিত। এখন, যখন নতুন প্লেসমেন্ট পরিসংখ্যান আসে, মেট্রিক্সের পুনঃগণনা করার একটি বহু-পর্যায়ের প্রক্রিয়া চালু করা হয়, যার মধ্যে রয়েছে কাঁচা ডেটা লোড করা, প্রতিটি সাইটের জন্য একত্রিত মেট্রিক গণনা করা, একে অপরের সাথে বিভিন্ন উত্স থেকে ডেটা তুলনা করা এবং প্রচারের জন্য সারাংশ মেট্রিক্স গণনা করা। এটি ওয়েব অ্যাপ্লিকেশনে প্রচুর লোড সৃষ্টি করে যা সমস্ত গণনা করে। বেশ কয়েকবার, পুনঃগণনা প্রক্রিয়া চলাকালীন, অ্যাপ্লিকেশনটি সার্ভারের সমস্ত মেমরি গ্রাস করেছে, প্রায় 10-15 জিবি, যা সিস্টেমের সাথে ব্যবহারকারীদের কাজের উপর সবচেয়ে ক্ষতিকর প্রভাব ফেলেছিল।

পণ্যের আরও উন্নয়নের জন্য চিহ্নিত সমস্যা এবং উচ্চাভিলাষী পরিকল্পনা আমাদের অ্যাপ্লিকেশন আর্কিটেকচার পুনর্বিবেচনার প্রয়োজনের দিকে নিয়ে গেছে।

আমরা সংযোগকারী দিয়ে শুরু.
আমরা লক্ষ্য করেছি যে সমস্ত সংযোগকারী একই মডেল অনুযায়ী কাজ করে, তাই আমরা একটি পাইপলাইন ফ্রেমওয়ার্ক তৈরি করেছি যাতে একটি সংযোগকারী তৈরি করার জন্য আপনাকে শুধুমাত্র পদক্ষেপগুলির যুক্তি প্রোগ্রাম করতে হবে, বাকিটি ছিল সর্বজনীন৷ যদি একটি সংযোগকারীর উন্নতির প্রয়োজন হয়, তাহলে আমরা অবিলম্বে এটিকে একটি নতুন ফ্রেমওয়ার্কে স্থানান্তর করি যখন কানেক্টরটি উন্নত করা হচ্ছে।

একই সময়ে, আমরা ডকার এবং কুবারনেটসে সংযোগকারী স্থাপন করা শুরু করেছি।
আমরা বেশ দীর্ঘ সময় ধরে Kubernetes-এ সরানোর পরিকল্পনা করেছি, CI/CD সেটিংস নিয়ে পরীক্ষা-নিরীক্ষা করেছি, কিন্তু শুধুমাত্র তখনই সরানো শুরু করেছি যখন একটি সংযোগকারী, একটি ত্রুটির কারণে, সার্ভারে 20 গিগাবাইটের বেশি মেমরি খাওয়া শুরু করে, কার্যত অন্যান্য প্রক্রিয়াগুলিকে মেরে ফেলে। . তদন্তের সময়, সংযোগকারীটিকে একটি Kubernetes ক্লাস্টারে স্থানান্তরিত করা হয়েছিল, যেখানে ত্রুটি সংশোধন করার পরেও এটি শেষ পর্যন্ত রয়ে গেছে।

খুব দ্রুত আমরা বুঝতে পেরেছিলাম যে কুবারনেটস সুবিধাজনক ছিল, এবং ছয় মাসের মধ্যে আমরা 7টি সংযোগকারী এবং সংযোগকারী প্রক্সি, যা সর্বাধিক সম্পদ ব্যবহার করে, উত্পাদন ক্লাস্টারে স্থানান্তরিত করেছি।

সংযোগকারীগুলি অনুসরণ করে, আমরা বাকি অ্যাপ্লিকেশনটির আর্কিটেকচার পরিবর্তন করার সিদ্ধান্ত নিয়েছি।
প্রধান সমস্যা ছিল যে ডেটা বড় ব্যাচগুলিতে সংযোগকারী থেকে প্রক্সিগুলিতে আসে এবং তারপরে DANBoID-তে আঘাত করে এবং প্রক্রিয়াকরণের জন্য কেন্দ্রীয় ওয়েব অ্যাপ্লিকেশনে পাঠানো হয়। বিপুল সংখ্যক মেট্রিক্স পুনঃগণনার কারণে, আবেদনের উপর একটি বড় লোড রয়েছে।

এটি পৃথক ডেটা সংগ্রহের কাজের স্থিতি নিরীক্ষণ করা এবং একটি কেন্দ্রীয় ওয়েব অ্যাপ্লিকেশনের সংযোগকারীগুলির মধ্যে ঘটে যাওয়া ত্রুটিগুলি রিপোর্ট করাও বেশ কঠিন প্রমাণিত হয়েছে যাতে ব্যবহারকারীরা দেখতে পারে কী ঘটছে এবং কেন ডেটা সংগ্রহ করা হচ্ছে না।

এই সমস্যাগুলি সমাধান করার জন্য, আমরা স্থাপত্য 2.0 তৈরি করেছি।

আর্কিটেকচারের নতুন সংস্করণের মধ্যে প্রধান পার্থক্য হল যে ওয়েব API-এর পরিবর্তে, আমরা পরিষেবাগুলির মধ্যে বার্তা বিনিময় করতে RabbitMQ এবং MassTransit লাইব্রেরি ব্যবহার করি। এটি করার জন্য, আমাদের প্রায় সম্পূর্ণভাবে সংযোগকারী প্রক্সি পুনর্লিখন করতে হয়েছিল, এটিকে সংযোগকারী হাব তৈরি করে। নামটি পরিবর্তিত হয়েছে কারণ পরিষেবার প্রধান ভূমিকা আর সংযোগকারীর কাছে অনুরোধ ফরোয়ার্ড করা এবং পিছনে নয়, কিন্তু সংযোগকারীদের থেকে মেট্রিক্স সংগ্রহ পরিচালনা করা।

কেন্দ্রীয় ওয়েব অ্যাপ্লিকেশান থেকে, আমরা সাইটগুলি থেকে স্থান নির্ধারণ এবং পরিসংখ্যান সম্পর্কিত তথ্য পৃথক পরিষেবাগুলিতে আলাদা করেছি, যা অপ্রয়োজনীয় পুনঃগণনার পরিত্রাণ পেতে এবং প্লেসমেন্ট স্তরে শুধুমাত্র ইতিমধ্যে গণনা করা এবং একত্রিত পরিসংখ্যান সংরক্ষণ করা সম্ভব করেছে৷ আমরা কাঁচা ডেটার উপর ভিত্তি করে মৌলিক পরিসংখ্যান গণনা করার জন্য যুক্তিটিকে পুনরায় লিখেছি এবং অপ্টিমাইজ করেছি।

একই সময়ে, সমাধানটি সহজে স্কেল করা এবং পরিচালনা করা আরও সুবিধাজনক করতে আমরা সমস্ত পরিষেবা এবং অ্যাপ্লিকেশনগুলিকে ডকার এবং কুবারনেটে স্থানান্তরিত করছি।

যেখানে আমরা এখন

প্রুফ-অফ-কনসেপ্ট আর্কিটেকচার 2.0 পণ্য D1.ডিজিটাল একটি সীমিত সংযোজক সেট সহ একটি পরীক্ষার পরিবেশে প্রস্তুত এবং কাজ করা। যা করা বাকি আছে তা হল একটি নতুন প্ল্যাটফর্মে আরও 20টি সংযোগকারীকে পুনরায় লেখা, পরীক্ষা করা যে ডেটা সঠিকভাবে লোড হয়েছে এবং সমস্ত মেট্রিক্স সঠিকভাবে গণনা করা হয়েছে এবং পুরো নকশাটিকে উৎপাদনে নিয়ে আসা।

প্রকৃতপক্ষে, এই প্রক্রিয়াটি ধীরে ধীরে ঘটবে এবং আমাদের সবকিছু কাজ করে রাখার জন্য পুরানো APIগুলির সাথে পিছনের সামঞ্জস্য রেখে যেতে হবে।

আমাদের তাত্ক্ষণিক পরিকল্পনার মধ্যে রয়েছে নতুন সংযোগকারীর বিকাশ, নতুন সিস্টেমের সাথে একীকরণ এবং সংযুক্ত সাইটগুলি থেকে ডাউনলোড করা ডেটার সেটে অতিরিক্ত মেট্রিক্স যুক্ত করা এবং সিস্টেমগুলিকে বিজ্ঞাপন দেওয়া৷

আমরা কেন্দ্রীয় ওয়েব অ্যাপ্লিকেশন সহ সমস্ত অ্যাপ্লিকেশন ডকার এবং কুবারনেটে স্থানান্তর করার পরিকল্পনা করছি। নতুন আর্কিটেকচারের সাথে একত্রিত হয়ে, এটি ব্যবহার করা সম্পদের স্থাপনা, পর্যবেক্ষণ এবং নিয়ন্ত্রণকে উল্লেখযোগ্যভাবে সহজ করবে।

আরেকটি ধারণা হল পরিসংখ্যান সংরক্ষণের জন্য ডাটাবেসের পছন্দ নিয়ে পরীক্ষা করা, যা বর্তমানে MongoDB-তে সংরক্ষিত আছে। আমরা ইতিমধ্যেই এসকিউএল ডাটাবেসে বেশ কয়েকটি নতুন সংযোগকারী স্থানান্তর করেছি, কিন্তু সেখানে পার্থক্যটি প্রায় অলক্ষিত, এবং দিনে একত্রিত পরিসংখ্যানের জন্য, যা একটি নির্বিচারে সময়ের জন্য অনুরোধ করা যেতে পারে, লাভটি বেশ গুরুতর হতে পারে।

সাধারণভাবে, পরিকল্পনাগুলি দুর্দান্ত, আসুন এগিয়ে যাই :)

নিবন্ধটির লেখক R&D ডেন্টসু এজিস নেটওয়ার্ক রাশিয়া: জর্জি ওস্তাপেনকো (shmiigaa), মিখাইল কোটসিক (hitexx)

উত্স: www.habr.com