VKontakte এর আর্কিটেকচার এবং কাজের উপর প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

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

আলেক্সি আকুলোভিচ (AterCattus) VKontakte দলে ব্যাকএন্ড বিকাশকারী। এই প্রতিবেদনের প্রতিলিপিটি প্ল্যাটফর্ম, অবকাঠামো, সার্ভার এবং তাদের মধ্যে মিথস্ক্রিয়া সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্নের সম্মিলিত উত্তর, কিন্তু উন্নয়ন সম্পর্কে নয়, যথা লোহা সম্পর্কে. আলাদাভাবে, ডাটাবেস সম্পর্কে এবং এর পরিবর্তে VK-এর কাছে কী আছে, লগ সংগ্রহ করা এবং পুরো প্রকল্পটি সামগ্রিকভাবে পর্যবেক্ষণ করা। কাটা অধীনে বিস্তারিত.

চার বছরেরও বেশি সময় ধরে আমি ব্যাকএন্ড সম্পর্কিত সমস্ত ধরণের কাজ নিয়ে কাজ করছি।

• আপলোড, সংরক্ষণ, প্রক্রিয়াকরণ, মিডিয়া বিতরণ: ভিডিও, লাইভ স্ট্রিমিং, অডিও, ফটো, নথি।
• অবকাঠামো, প্ল্যাটফর্ম, বিকাশকারী পর্যবেক্ষণ, লগ, আঞ্চলিক ক্যাশে, CDN, মালিকানাধীন RPC প্রোটোকল।
• বাহ্যিক পরিষেবাগুলির সাথে একীকরণ: পুশ বিজ্ঞপ্তি, বাহ্যিক লিঙ্ক পার্সিং, RSS ফিড৷
• সহকর্মীদের বিভিন্ন প্রশ্নে সাহায্য করা, যার উত্তরের জন্য অজানা কোডে ডুব দিতে হবে।

এই সময়ে, সাইটের অনেক উপাদানে আমার হাত ছিল। আমি এই অভিজ্ঞতা শেয়ার করতে চাই.

সাধারণ স্থাপত্য

সবকিছু, যথারীতি, একটি সার্ভার বা সার্ভারের গ্রুপ দিয়ে শুরু হয় যা অনুরোধ গ্রহণ করে।

সামনে সার্ভার

সামনের সার্ভার HTTPS, RTMP এবং WSS এর মাধ্যমে অনুরোধ গ্রহণ করে।

HTTPS দ্বারা - এগুলি সাইটের প্রধান এবং মোবাইল ওয়েব সংস্করণগুলির জন্য অনুরোধগুলি: vk.com এবং m.vk.com, এবং আমাদের API-এর অন্যান্য অফিসিয়াল এবং অনানুষ্ঠানিক ক্লায়েন্ট: মোবাইল ক্লায়েন্ট, মেসেঞ্জার৷ আমরা একটি সংবর্ধনা আছে RTMP- আলাদা ফ্রন্ট সার্ভার সহ লাইভ সম্প্রচারের জন্য ট্রাফিক এবং ফলক- স্ট্রিমিং API এর জন্য সংযোগ।

সার্ভারে HTTPS এবং WSS এর জন্য এটি মূল্যবান nginx. RTMP সম্প্রচারের জন্য, আমরা সম্প্রতি আমাদের নিজস্ব সমাধানে স্যুইচ করেছি kive, কিন্তু এটা রিপোর্টের সুযোগের বাইরে। ত্রুটি সহনশীলতার জন্য, এই সার্ভারগুলি সাধারণ আইপি ঠিকানাগুলির বিজ্ঞাপন দেয় এবং গোষ্ঠীগুলিতে কাজ করে যাতে কোনও একটি সার্ভারে সমস্যা হলে, ব্যবহারকারীর অনুরোধগুলি হারিয়ে না যায়। HTTPS এবং WSS-এর জন্য, এই একই সার্ভারগুলি নিজেদের উপর CPU লোডের অংশ নেওয়ার জন্য ট্র্যাফিক এনক্রিপ্ট করে।

আমরা WSS এবং RTMP সম্পর্কে আরও কথা বলব না, তবে শুধুমাত্র স্ট্যান্ডার্ড HTTPS অনুরোধগুলি সম্পর্কে, যা সাধারণত একটি ওয়েব প্রকল্পের সাথে যুক্ত থাকে।

ব্যাক-এন্ড

সামনের পিছনে সাধারণত ব্যাকএন্ড সার্ভার থাকে। তারা অনুরোধগুলি প্রক্রিয়া করে যা সামনের সার্ভার ক্লায়েন্টদের কাছ থেকে গ্রহণ করে।

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

লোড বিতরণ

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

মেট্রিক সংগ্রহ এবং পুনরায় ভারসাম্য

প্রতিটি গ্রুপে আমাদের কতগুলি গাড়ি থাকা দরকার তা বোঝার জন্য, আমরা QPS এর উপর নির্ভর করবেন না. ব্যাকএন্ডগুলি আলাদা, তাদের আলাদা অনুরোধ রয়েছে, প্রতিটি অনুরোধের QPS গণনা করার আলাদা জটিলতা রয়েছে। এজন্যই আমরা আমরা সার্ভারে সার্ভারে লোডের ধারণা নিয়ে কাজ করি - CPU এবং perf-এ.

আমাদের এরকম হাজার হাজার সার্ভার আছে। প্রতিটি ভৌত ​​সার্ভার সমস্ত কোর পুনর্ব্যবহার করার জন্য একটি kPHP গ্রুপ চালায় (কারণ kPHP একক থ্রেডেড)।

বিষয়বস্তু সার্ভার

সিএস বা কন্টেন্ট সার্ভার একটি স্টোরেজ. CS হল একটি সার্ভার যা ফাইল সংরক্ষণ করে এবং আপলোড করা ফাইলগুলি এবং সমস্ত ধরণের ব্যাকগ্রাউন্ড সিঙ্ক্রোনাস কাজগুলি প্রক্রিয়া করে যা প্রধান ওয়েব ফ্রন্টএন্ড এটিকে বরাদ্দ করে।

আমাদের কাছে হাজার হাজার ফিজিক্যাল সার্ভার রয়েছে যা ফাইল সংরক্ষণ করে। ব্যবহারকারীরা ফাইল আপলোড করতে পছন্দ করে, এবং আমরা সেগুলি সঞ্চয় করতে এবং ভাগ করতে পছন্দ করি। এই সার্ভারগুলির মধ্যে কিছু বিশেষ pu/pp সার্ভার দ্বারা বন্ধ করা হয়।

pu/pp

আপনি যদি VK-তে নেটওয়ার্ক ট্যাবটি খুলেন, আপনি pu/pp দেখেছেন।

pu/pp কি? যদি আমরা একের পর এক সার্ভার বন্ধ করি, তাহলে বন্ধ করা সার্ভারে একটি ফাইল আপলোড এবং ডাউনলোড করার জন্য দুটি বিকল্প রয়েছে: সরাসরি দ্বারা http://cs100500.userapi.com/path বা মধ্যবর্তী সার্ভারের মাধ্যমে - http://pu.vk.com/c100500/path.

পু হল ফটো আপলোডের ঐতিহাসিক নাম, এবং পিপি হল ফটো প্রক্সি৷. অর্থাৎ, একটি সার্ভার ফটো আপলোড করার জন্য, এবং অন্যটি আপলোড করার জন্য। এখন শুধু ছবি লোড করা হয় না, নামটিও সংরক্ষণ করা হয়েছে।

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

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

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

বিতর্কিত বিষয় হলো এ ক্ষেত্রে ড ক্লায়েন্ট কম সংযোগ রাখে. যদি একাধিক মেশিনের জন্য একই আইপি থাকে - একই হোস্ট সহ: pu.vk.com বা pp.vk.com, ক্লায়েন্ট ব্রাউজারে একটি হোস্টে একযোগে অনুরোধের সংখ্যার একটি সীমা থাকে৷ কিন্তু সর্বব্যাপী HTTP/2 এর সময়ে, আমি বিশ্বাস করি যে এটি আর তেমন প্রাসঙ্গিক নয়।

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

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

সূর্য

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

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

অতএব - আমরা বিষয়বস্তু ভাগ করতে পারি না, কারণ আমরা এই গ্রুপের জন্য একটি নির্দিষ্ট সার্ভার নির্বাচন করতে পারি না - তাদের একটি সাধারণ আইপি আছে। এছাড়াও কিছু অভ্যন্তরীণ কারণে আমাদের আছে অঞ্চলে এই ধরনের সার্ভার ইনস্টল করা সম্ভব ছিল না. তারা কেবল সেন্ট পিটার্সবার্গে দাঁড়িয়েছিল।

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

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

বিষয়বস্তু আইডি দ্বারা ভাগ করা. শার্ডিং সম্বন্ধে একটি মজার বিষয়: আমরা সাধারণত বিষয়বস্তু শাড়ি করি যাতে বিভিন্ন ব্যবহারকারী একই ফাইলে একই "সান" এর মাধ্যমে যান যাতে তাদের একটি সাধারণ ক্যাশে থাকে।

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

একই ফাইলের জন্য অনুরোধের বিস্ফোরণ সহ্য করার জন্য, এটি একটি নির্দিষ্ট ধরণের সামগ্রীর জন্য যা আমরা একটি বোকা স্কিম চালু করি যা এই অঞ্চলের সমস্ত উপলব্ধ "সূর্য" জুড়ে ফাইলগুলি ছড়িয়ে দেয়।

ভেতর থেকে সূর্য

এনজিনেক্সে রিভার্স প্রক্সি, হয় র‌্যামে বা ফাস্ট অপটেন/এনভিএম ডিস্কে ক্যাশে। উদাহরণ: http://sun4-2.userapi.com/c100500/path — একটি লিঙ্ক “সূর্য”, যা চতুর্থ অঞ্চলে অবস্থিত, দ্বিতীয় সার্ভার গ্রুপ। এটি পাথ ফাইলটি বন্ধ করে দেয়, যা শারীরিকভাবে সার্ভার 100500 এ রয়েছে।

আচ্ছাদন

আমরা আমাদের আর্কিটেকচারাল স্কিমে আরও একটি নোড যোগ করি - ক্যাশিং পরিবেশ।

নিচে লেআউট ডায়াগ্রাম দেওয়া হল আঞ্চলিক ক্যাশে, তাদের মধ্যে প্রায় 20 টি আছে। এই স্থানগুলি যেখানে ক্যাশে এবং "সূর্য" অবস্থিত, যা নিজেদের মাধ্যমে ট্র্যাফিক ক্যাশে করতে পারে।

এটি মাল্টিমিডিয়া সামগ্রীর ক্যাশিং; এখানে কোনও ব্যবহারকারীর ডেটা সংরক্ষণ করা হয় না - শুধু সঙ্গীত, ভিডিও, ফটো৷

ব্যবহারকারীর অঞ্চল নির্ধারণ করতে, আমরা আমরা অঞ্চলগুলিতে ঘোষিত BGP নেটওয়ার্ক উপসর্গ সংগ্রহ করি. ফলব্যাকের ক্ষেত্রে, যদি আমরা উপসর্গ দ্বারা IP খুঁজে না পাই তাহলে আমাদের জিওআইপি ডাটাবেস পার্স করতে হবে। আমরা ব্যবহারকারীর আইপি দ্বারা অঞ্চল নির্ধারণ করি. কোডে, আমরা ব্যবহারকারীর এক বা একাধিক অঞ্চল দেখতে পারি - সেই পয়েন্টগুলির যেখানে তিনি ভৌগোলিকভাবে সবচেয়ে কাছাকাছি।

এটা কিভাবে কাজ করে?

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

একই সময়ে, রাক্ষস - অঞ্চলগুলিতে পরিষেবাগুলি - সময়ে সময়ে API এ আসে এবং বলে: "আমি এমন এবং এইরকম একটি ক্যাশে, আমাকে আমার অঞ্চলের সবচেয়ে জনপ্রিয় ফাইলগুলির একটি তালিকা দিন যা এখনও আমার কাছে নেই৷ " API রেটিং অনুসারে বাছাই করা একগুচ্ছ ফাইল সরবরাহ করে, ডেমন সেগুলি ডাউনলোড করে, অঞ্চলগুলিতে নিয়ে যায় এবং সেখান থেকে ফাইলগুলি সরবরাহ করে। এটি ক্যাশে থেকে pu/pp এবং সূর্যের মধ্যে মৌলিক পার্থক্য: তারা অবিলম্বে নিজের মাধ্যমে ফাইলটি দেয়, এমনকি এই ফাইলটি ক্যাশে না থাকলেও, এবং ক্যাশে প্রথমে ফাইলটিকে ডাউনলোড করে এবং তারপরে এটি ফেরত দিতে শুরু করে।

এই ক্ষেত্রে আমরা পেতে ব্যবহারকারীদের কাছাকাছি বিষয়বস্তু এবং নেটওয়ার্ক লোড ছড়িয়ে দেওয়া। উদাহরণস্বরূপ, শুধুমাত্র মস্কো ক্যাশে থেকে আমরা পিক আওয়ারে 1 টিবিট/সেকেন্ডের বেশি বিতরণ করি।

কিন্তু সমস্যা আছে - ক্যাশে সার্ভার রাবার নয়. সুপার জনপ্রিয় সামগ্রীর জন্য, কখনও কখনও একটি পৃথক সার্ভারের জন্য পর্যাপ্ত নেটওয়ার্ক থাকে না। আমাদের ক্যাশে সার্ভারগুলি 40-50 Gbit/s, কিন্তু এমন সামগ্রী রয়েছে যা এই জাতীয় চ্যানেলকে সম্পূর্ণরূপে আটকে রাখে৷ আমরা এই অঞ্চলে জনপ্রিয় ফাইলের একাধিক কপি স্টোরেজ বাস্তবায়নের দিকে এগিয়ে যাচ্ছি। আশা করছি বছরের শেষ নাগাদ আমরা তা বাস্তবায়ন করব।

আমরা সাধারণ স্থাপত্য দেখেছি।

• ফ্রন্ট সার্ভার যা অনুরোধ গ্রহণ করে।
• ব্যাকএন্ড যে প্রক্রিয়া অনুরোধ.
• দুই ধরনের প্রক্সি দ্বারা বন্ধ করা স্টোরেজ।
• আঞ্চলিক ক্যাশে।

এই ডায়াগ্রাম থেকে কি অনুপস্থিত? অবশ্যই, আমরা যে ডাটাবেসগুলিতে ডেটা সংরক্ষণ করি।

ডাটাবেস বা ইঞ্জিন

আমরা তাদের ডেটাবেস নয়, কিন্তু ইঞ্জিন - ইঞ্জিন বলি, কারণ আমাদের কাছে সাধারণভাবে গৃহীত অর্থে কার্যত ডেটাবেস নেই।

এটি একটি প্রয়োজনীয় পরিমাপ।. এটি ঘটেছে কারণ 2008-2009 সালে, যখন VK-এর জনপ্রিয়তা একটি বিস্ফোরক বৃদ্ধি পেয়েছিল, প্রকল্পটি সম্পূর্ণরূপে MySQL এবং Memcache-তে কাজ করেছিল এবং সমস্যা ছিল। MySQL ফাইলগুলি ক্র্যাশ করতে এবং দূষিত করতে পছন্দ করত, যার পরে এটি পুনরুদ্ধার হবে না, এবং মেমক্যাশে ধীরে ধীরে কর্মক্ষমতা হ্রাস পায় এবং পুনরায় চালু করতে হয়েছিল।

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

সমাধান সফল হয়েছে. এটি করার একটি সুযোগ ছিল, পাশাপাশি একটি চরম প্রয়োজনীয়তা ছিল, কারণ সেই সময়ে স্কেলিং করার অন্যান্য উপায় বিদ্যমান ছিল না। একগুচ্ছ ডাটাবেস ছিল না, NoSQL এখনও বিদ্যমান ছিল না, শুধুমাত্র MySQL, Memcache, PostrgreSQL ছিল - এবং এটিই।

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

ইঞ্জিনের প্রকারভেদ

দলটি বেশ কয়েকটি ইঞ্জিন লিখেছেন। এখানে তাদের মধ্যে কয়েকটি রয়েছে: বন্ধু, ইঙ্গিত, চিত্র, ipdb, অক্ষর, তালিকা, লগ, memcached, meowdb, খবর, nostradamus, ফটো, প্লেলিস্ট, pmemcached, স্যান্ডবক্স, অনুসন্ধান, সঞ্চয়স্থান, পছন্দ, কাজ, …

প্রতিটি কাজের জন্য যার জন্য একটি নির্দিষ্ট ডেটা স্ট্রাকচার প্রয়োজন বা অ্যাটিপিকাল অনুরোধগুলি প্রক্রিয়া করে, সি টিম একটি নতুন ইঞ্জিন লেখে। কেন না.

আমাদের আলাদা ইঞ্জিন আছে memcached, যা একটি নিয়মিত এক অনুরূপ, কিন্তু গুড গুচ্ছ সঙ্গে, এবং যা ধীর হয় না. ক্লিকহাউস নয়, তবে এটিও কাজ করে। আলাদাভাবে পাওয়া যায় pmemcached - এটা ক্রমাগত memcached, যা ডিস্কে ডেটা সঞ্চয় করতে পারে, উপরন্তু, RAM-তে ফিট না করে, যাতে পুনরায় চালু করার সময় ডেটা হারাতে না পারে। পৃথক কাজের জন্য বিভিন্ন ইঞ্জিন রয়েছে: সারি, তালিকা, সেট - আমাদের প্রকল্পের জন্য প্রয়োজনীয় সবকিছু।

ক্লাস্টার

কোডের দৃষ্টিকোণ থেকে, ইঞ্জিন বা ডাটাবেসকে প্রক্রিয়া, সত্তা বা দৃষ্টান্ত হিসাবে ভাবার দরকার নেই। কোডটি বিশেষভাবে ক্লাস্টারগুলির সাথে কাজ করে, ইঞ্জিনগুলির গ্রুপগুলির সাথে - ক্লাস্টার প্রতি এক প্রকার. ধরা যাক একটি মেমক্যাশেড ক্লাস্টার রয়েছে - এটি কেবলমাত্র মেশিনের একটি গ্রুপ।

কোডটির প্রকৃত অবস্থান, আকার বা সার্ভারের সংখ্যা মোটেই জানার প্রয়োজন নেই। তিনি একটি নির্দিষ্ট শনাক্তকারী ব্যবহার করে ক্লাস্টারে যান।

এটি কাজ করার জন্য, আপনাকে আরও একটি সত্তা যোগ করতে হবে যা কোড এবং ইঞ্জিনগুলির মধ্যে অবস্থিত - প্রক্সি.

RPC প্রক্সি

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

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

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

সুনির্দিষ্ট বাস্তবায়ন

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

MySQL-এর জন্য, যা আমাদের এখনও এখানে এবং সেখানে আছে, আমরা db-proxy ব্যবহার করি, এবং ClickHouse-এর জন্য - Kittenhouse.

এটি সাধারণত এই মত কাজ করে। একটি নির্দিষ্ট সার্ভার আছে, এটি kPHP, Go, Python চালায় - সাধারণভাবে, আমাদের RPC প্রোটোকল ব্যবহার করতে পারে এমন যেকোনো কোড। কোডটি স্থানীয়ভাবে একটি RPC প্রক্সিতে চলে - প্রতিটি সার্ভার যেখানে কোডটি অবস্থিত তার নিজস্ব স্থানীয় প্রক্সি চালায়। অনুরোধ করার পর, প্রক্সি বুঝতে পারে কোথায় যেতে হবে।

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

একটি টিএল-স্কিমের একটি উদাহরণ যা অনুসারে সমস্ত ইঞ্জিন কাজ করে।

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

এটি একটি বাইনারি প্রোটোকল, যার সবচেয়ে কাছের অ্যানালগ প্রোটোবাফ স্কিমা ঐচ্ছিক ক্ষেত্রগুলি, জটিল প্রকারগুলি - অন্তর্নির্মিত স্কেলারগুলির এক্সটেনশন এবং প্রশ্নগুলির পূর্বনির্ধারণ করে৷ এই প্রোটোকল অনুযায়ী সবকিছু কাজ করে।

TCP/UDP-এর উপর TL-এর উপর RPC... UDP?

আমাদের কাছে ইঞ্জিন অনুরোধগুলি কার্যকর করার জন্য একটি RPC প্রোটোকল রয়েছে যা TL স্কিমের উপরে চলে। এই সব একটি TCP/UDP সংযোগের মাধ্যমে কাজ করে। TCP বোধগম্য, কিন্তু কেন আমরা প্রায়ই UDP প্রয়োজন?

UDP সাহায্য করে সার্ভারের মধ্যে বিপুল সংখ্যক সংযোগের সমস্যা এড়ান. যদি প্রতিটি সার্ভারে একটি RPC প্রক্সি থাকে এবং সাধারণভাবে, এটি যেকোনো ইঞ্জিনে যেতে পারে, তাহলে প্রতি সার্ভারে কয়েক হাজার TCP সংযোগ রয়েছে। একটি লোড আছে, কিন্তু এটা অকেজো. UDP এর ক্ষেত্রে এই সমস্যা নেই।

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

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

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

অবিরাম ডেটা স্টোরেজ

ইঞ্জিন বিনলগ লেখে. একটি বিনলগ হল একটি ফাইল যার শেষে রাষ্ট্র বা ডেটাতে পরিবর্তনের জন্য একটি ইভেন্ট যোগ করা হয়। বিভিন্ন সমাধানে একে ভিন্নভাবে বলা হয়: বাইনারি লগ, ওয়াল, এওএফ, কিন্তু নীতি একই.

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

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

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

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

স্ন্যাপশট তৈরি করার সময় যে অবস্থানটি ছিল এবং বিনলগের আকার পড়ে তা পড়ে।

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

ডেটা প্রতিলিপি

ফলস্বরূপ, আমাদের তথ্য প্রতিলিপি বিবৃতি ভিত্তিক — আমরা বিনলগে লিখি কোনো পৃষ্ঠা পরিবর্তন নয়, কিন্তু যথা অনুরোধগুলো পরিবর্তন করো. নেটওয়ার্কে যা আসে তার সাথে খুব মিল, শুধুমাত্র সামান্য পরিবর্তিত।

একই স্কিম শুধুমাত্র প্রতিলিপি জন্য ব্যবহার করা হয়, কিন্তু ব্যাকআপ তৈরি করতে. আমাদের একটি ইঞ্জিন আছে - একটি লেখার মাস্টার যেটি বিনলগে লেখে। অন্য যেকোন জায়গায় যেখানে প্রশাসকরা এটি সেট আপ করেছেন, এই বিনলগটি অনুলিপি করা হয়েছে, এবং এটিই - আমাদের একটি ব্যাকআপ আছে৷

প্রয়োজন হলে পড়ার প্রতিরূপসিপিইউ রিডিং লোড কমাতে, রিডিং ইঞ্জিনটি সহজভাবে চালু করা হয়, যা বিনলগের শেষে পড়ে এবং স্থানীয়ভাবে এই কমান্ডগুলি চালায়।

এখানে ল্যাগ খুব ছোট, এবং রেপ্লিকাটি মাস্টারের পিছনে কতটা পিছিয়ে আছে তা খুঁজে বের করা সম্ভব।

RPC প্রক্সিতে ডেটা শার্ডিং

শার্ডিং কিভাবে কাজ করে? প্রক্সি কিভাবে বুঝতে পারে কোন ক্লাস্টার শার্ড পাঠাতে হবে? কোডটি বলে না: "15 টি শার্ডের জন্য পাঠান!" - না, এটা প্রক্সি দ্বারা করা হয়.

সবচেয়ে সহজ স্কিম হল firstint - অনুরোধের প্রথম সংখ্যা।

get(photo100_500) => 100 % N.

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

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

অনুরোধগুলি কীভাবে ক্লাস্টার জুড়ে ছড়িয়ে পড়ে তা যদি আমরা চিন্তা না করি তবে আরেকটি বিকল্প রয়েছে - পুরো শার্ড হ্যাশ করা.

hash(photo100_500) => 3539886280 % N

আমরা হ্যাশ, বিভাগের অবশিষ্টাংশ এবং শার্ড সংখ্যাও পাই।

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

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

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

লগ

আমরা বিভিন্ন উপায়ে লগ লিখি। সবচেয়ে সুস্পষ্ট এবং সহজ এক মেমক্যাশে লগ লিখুন.

ring-buffer: prefix.idx = line

একটি কী উপসর্গ আছে - লগের নাম, একটি লাইন, এবং এই লগের আকার আছে - লাইনের সংখ্যা। আমরা 0 থেকে লাইনের সংখ্যা বিয়োগ 1 পর্যন্ত একটি এলোমেলো সংখ্যা নিই। মেমক্যাশে কীটি এই র্যান্ডম সংখ্যার সাথে সংযুক্ত একটি উপসর্গ। আমরা লগ লাইন এবং বর্তমান সময়ের মান সংরক্ষণ করি।

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

লগের নির্ভরযোগ্য সঞ্চয়ের জন্য আমাদের একটি ইঞ্জিন আছে লগ-ইঞ্জিন. এই কারণেই এটি তৈরি করা হয়েছিল এবং বিপুল সংখ্যক ক্লাস্টারে ব্যাপকভাবে ব্যবহৃত হয়। আমার জানা সবচেয়ে বড় ক্লাস্টারে 600 TB প্যাক করা লগ রয়েছে।

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

ক্লিক হাউসে লগ সংগ্রহ করা হচ্ছে

এই চিত্রটি দেখায় কিভাবে আমরা আমাদের ইঞ্জিনের মধ্যে চলে যাই।

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

• ক্লিকহাউস দিয়ে কিছু ইঞ্জিন প্রতিস্থাপন করুন;
• RPC প্রক্সি প্রতিস্থাপন করুন, যা ClickHouse অ্যাক্সেস করতে পারে না, কিছু সমাধান দিয়ে যা করতে পারে, এবং RPC এর মাধ্যমে।

ইঞ্জিনটি সহজ - আমরা এটিকে একটি সার্ভার বা ক্লিকহাউসের সাথে সার্ভারের একটি ক্লাস্টার দিয়ে প্রতিস্থাপন করি।

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

কখনও কখনও আমরা অ-মানক সমাধানগুলিতে RPC স্কিম বাস্তবায়ন করতে চাই না, উদাহরণস্বরূপ, nginx-এ। অতএব, KittenHouse UDP এর মাধ্যমে লগ গ্রহণ করার ক্ষমতা রাখে।

লগের প্রেরক এবং প্রাপক যদি একই মেশিনে কাজ করে, তাহলে স্থানীয় হোস্টের মধ্যে একটি UDP প্যাকেট হারানোর সম্ভাবনা বেশ কম। তৃতীয় পক্ষের সমাধান এবং নির্ভরযোগ্যতার মধ্যে RPC বাস্তবায়নের প্রয়োজনীয়তার মধ্যে একটি আপস হিসাবে, আমরা কেবল UDP প্রেরণ ব্যবহার করি। আমরা পরে এই স্কিমে ফিরে আসব।

পর্যবেক্ষণ

আমাদের কাছে দুই ধরনের লগ রয়েছে: যেগুলি অ্যাডমিনিস্ট্রেটরদের দ্বারা তাদের সার্ভারে সংগৃহীত এবং কোডগুলি থেকে বিকাশকারীদের দ্বারা লেখা৷ তারা দুই ধরনের মেট্রিক্সের সাথে মিলে যায়: সিস্টেম এবং পণ্য.

সিস্টেম মেট্রিক্স

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

পণ্যের পরিমাপ

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

পরবর্তীকালে, আমরা বাছাই এবং গ্রুপিং ফিল্টার ব্যবহার করতে পারি এবং পরিসংখ্যান থেকে আমরা যা চাই তা করতে পারি - গ্রাফ তৈরি করুন, ওয়াচডগ কনফিগার করুন।

আমরা খুব লিখি অনেক মেট্রিক্স ইভেন্টের সংখ্যা প্রতিদিন 600 বিলিয়ন থেকে 1 ট্রিলিয়ন পর্যন্ত। তবে আমরা তাদের রাখতে চাই অন্তত বছর দুয়েকমেট্রিক্সের প্রবণতা বুঝতে। এটিকে একসাথে রাখা একটি বড় সমস্যা যা আমরা এখনও সমাধান করতে পারিনি। আমি আপনাকে বলব যে এটি গত কয়েক বছর ধরে কীভাবে কাজ করছে।

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

প্রয়োজনে আমরা লগ-সংগ্রাহকদের কাছে সরাসরি লিখতে পারি।

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

এর পরে, লগ-সংগ্রাহকরা পরিসংখ্যানকে এর মধ্যে একত্রিত করে meowDB - এটি আমাদের ডাটাবেস, যা মেট্রিক্সও সঞ্চয় করতে পারে।

তারপর আমরা কোড থেকে বাইনারি "নিকট-এসকিউএল" নির্বাচন করতে পারি।

পরীক্ষা

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

আমাদের একটি স্কিম ছিল যা KittenHouse এর মাধ্যমে লগ লিখেছিল।

আমরা সিদ্ধান্ত নিলাম ডায়াগ্রামে আরেকটি "*হাউস" যোগ করুন, যা আমাদের কোড UDP এর মাধ্যমে লেখার মতো বিন্যাসে ঠিক মেট্রিকগুলি পাবে৷ তারপর এই *হাউস এগুলিকে লগের মতো সন্নিবেশে পরিণত করে, যা KittenHouse বুঝতে পারে। তিনি নিখুঁতভাবে ক্লিকহাউসে এই লগগুলি সরবরাহ করতে পারেন, যা সেগুলি পড়তে সক্ষম হওয়া উচিত।

মেমক্যাশ, স্ট্যাটাস-ডেমন এবং লগ-সংগ্রাহক ডাটাবেসের সাথে এই স্কিমটি প্রতিস্থাপন করা হয়েছে।

মেমক্যাশ, স্ট্যাটাস-ডেমন এবং লগ-সংগ্রাহক ডাটাবেসের সাথে এই স্কিমটি প্রতিস্থাপন করা হয়েছে।

• এখানে কোড থেকে একটি প্রেরণ আছে, যা স্থানীয়ভাবে স্ট্যাটহাউসে লেখা আছে।
• StatsHouse ইউডিপি মেট্রিক্স লিখে, যা ইতিমধ্যেই এসকিউএল ইনসার্টে রূপান্তরিত, ব্যাচে KittenHouse-এ।
• KittenHouse তাদের ClickHouse এ পাঠায়।
• আমরা যদি সেগুলি পড়তে চাই, তাহলে আমরা স্ট্যাটহাউসকে বাইপাস করে পড়ি - সরাসরি ক্লিকহাউস থেকে নিয়মিত এসকিউএল ব্যবহার করে।

এটা কি এখনও আছে পরীক্ষা, কিন্তু আমরা এটা কিভাবে সক্রিয় পছন্দ. আমরা যদি স্কিমটির সাথে সমস্যাগুলি ঠিক করি, তবে সম্ভবত আমরা এটিতে পুরোপুরি স্যুইচ করব। ব্যক্তিগতভাবে, আমি তাই আশা করি.

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

স্থাপন করুন

প্রথমে, আসুন পিএইচপি স্থাপনার দিকে তাকাই। আমরা মধ্যে উন্নয়নশীল হয় ফালতু বা এলেবেলে লোক: ব্যবহার GitLab и TeamCity স্থাপনার জন্য। উন্নয়ন শাখাগুলিকে মাস্টার শাখায় একীভূত করা হয়, পরীক্ষার জন্য মাস্টার থেকে তারা স্টেজিংয়ে এবং মঞ্চ থেকে উৎপাদনে একত্রিত হয়।

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

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

আমাদের ইঞ্জিনগুলির জন্য, যা মূলত বাইনারি, স্কিমটি খুব অনুরূপ:

• git মাস্টার শাখা;
• মধ্যে বাইনারি .deb;
• সংস্করণটি বিনলগ কপিফাস্টে লেখা হয়েছে;
• সার্ভারে প্রতিলিপি করা হয়েছে;
• সার্ভার একটি তাজা .dep বের করে;
• dpkg - i;
• নতুন সংস্করণে সুস্বাদু পুনঃলঞ্চ।

পার্থক্য হল আমাদের বাইনারি সংরক্ষণাগারে প্যাকেজ করা হয় .deb, এবং যখন তারা পাম্প আউট dpkg - i সিস্টেমে স্থাপন করা হয়। কেন kPHP একটি বাইনারি হিসাবে স্থাপন করা হয়, এবং ইঞ্জিনগুলি dpkg হিসাবে স্থাপন করা হয়? এটা সেভাবেই ঘটেছে। এটি কাজ করে - এটি স্পর্শ করবেন না।

দরকারী লিঙ্কগুলি:

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

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

উত্স: www.habr.com