Badoo-তে ফটো সংরক্ষণ এবং শেয়ার করার জন্য আর্কিটেকচার

আর্টেম ডেনিসভ ( bo0rsh201, badoo)

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

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

এখন শুরু করা যাক.

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

আমাদের একটি সাধারণ কাজ আছে, আমাদের ব্যবহারকারীর ছবি গ্রহণ, সংরক্ষণ এবং পাঠাতে হবে। এই ফর্মটিতে, কাজটি সাধারণ, আমরা যে কোনও কিছু ব্যবহার করতে পারি:

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

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

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

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

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

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

এভাবেই কিছু সময়ের জন্য আমাদের জন্য ছিল.

এটি ছিল 2009 সালের দিকে। তারা গাড়ি সরবরাহ করেছে, বিতরণ করেছে...

এবং কিছু সময়ে আমরা লক্ষ্য করতে শুরু করি যে এই স্কিমটির কিছু অসুবিধা রয়েছে। অসুবিধা কি?

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

এবং দ্বিতীয়। এটি মেশিনের একটি অ্যাটিপিকাল কনফিগারেশন, যেহেতু এই ধরনের মেশিনগুলি অন্য কিছু ক্লাস্টারে পুনরায় ব্যবহার করা কঠিন; তারা বেশ নির্দিষ্ট, যেমন তারা কর্মক্ষমতা দুর্বল হতে হবে, কিন্তু একই সময়ে একটি বড় হার্ড ড্রাইভ সঙ্গে.

এই সব ছিল 2009 এর জন্য, কিন্তু, নীতিগতভাবে, এই প্রয়োজনীয়তাগুলি আজও প্রাসঙ্গিক। আমাদের একটি রেট্রোস্পেক্টিভ আছে, তাই 2009 সালে এটির সাথে সবকিছু সম্পূর্ণ খারাপ ছিল।

এবং শেষ পয়েন্ট হল দাম।

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

এবং শেষ পর্যন্ত, আমরা তথাকথিত স্টোরেজ এরিয়া নেটওয়ার্ক ব্যবহার করে স্থির হয়েছি।

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

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

দ্বিতীয় প্লাস।

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

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

যেমনটি আমাদের ফটোগুলির ক্ষেত্রে, কারণ ফটোগুলি অসঙ্গতভাবে অনুরোধ করা হয়েছে এবং এটি তাদের কার্যকারিতাকে ব্যাপকভাবে প্রভাবিত করবে৷

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

অপ্টিমাইজ করার জন্য, আমরা সেই সময়ে সিদ্ধান্ত নিয়েছিলাম, স্পষ্টতই, লোড প্রোফাইলটি দেখার জন্য - কী, সাধারণভাবে, ঘটছে, কী অপ্টিমাইজ করা দরকার।

এবং এখানে সবকিছু আমাদের হাতে খেলা।

আমি ইতিমধ্যেই প্রথম স্লাইডে বলেছি: আমাদের প্রতি সেকেন্ডে 80 হাজার পড়ার অনুরোধ রয়েছে যেখানে প্রতিদিন মাত্র 3,5 মিলিয়ন আপলোড হয়। অর্থাৎ, এটি মাত্রার তিনটি আদেশের পার্থক্য। এটা স্পষ্ট যে পড়া অপ্টিমাইজ করা প্রয়োজন এবং এটা কার্যত স্পষ্ট কিভাবে কিভাবে.

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

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

LRU-এর সাথে একটি ক্যাশে আমাদের সমস্ত সমস্যার সমাধান করবে। আমরা কি করছি?

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

এটা ভিতর থেকে কিভাবে কাজ করে? এখানে আমাদের ব্যবহারকারী, এখানে স্টোরেজ. সবকিছু আগের মতই আছে। আমরা এর মধ্যে কি যোগ করব?

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

এটা কিসের মতো দেখতে? ব্যবহারকারী একটি ছবির জন্য একটি অনুরোধ পাঠায়. NGINX প্রথমে স্থানীয় ক্যাশে এটি সন্ধান করে। যদি না হয়, তাহলে আমাদের স্টোরেজে proxy_pass করুন, সেখান থেকে ফটো ডাউনলোড করুন এবং ব্যবহারকারীকে দিন।

তবে এটি খুব সাধারণ এবং ভিতরে কী ঘটছে তা স্পষ্ট নয়। এটা এই মত কিছু কাজ করে.

ক্যাশে যৌক্তিকভাবে তিনটি স্তরে বিভক্ত। আমি যখন "তিন স্তর" বলি, এর অর্থ এই নয় যে কোনও ধরণের জটিল সিস্টেম রয়েছে। না, এগুলি শর্তসাপেক্ষে ফাইল সিস্টেমে মাত্র তিনটি ডিরেক্টরি:

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

এটি কাজ করার জন্য, আমাদের কোনওভাবে এই ক্যাশে পরিচালনা করতে হবে, আমাদের এতে ফটোগুলিকে পুনরায় সাজাতে হবে, ইত্যাদি। এটাও খুব আদিম প্রক্রিয়া।

Nginx প্রতিটি অনুরোধের জন্য সহজভাবে RAMDisk access.log-এ লেখে, যেখানে এটি বর্তমানে পরিবেশিত ছবির পথ নির্দেশ করে (অবশ্যই আপেক্ষিক পথ), এবং কোন পার্টিশনটি পরিবেশন করা হয়েছে। সেগুলো. এটি বলতে পারে "ফটো 1" এবং তারপর হয় একটি বাফার, বা একটি হট ক্যাশে, বা একটি ঠান্ডা ক্যাশে, বা একটি প্রক্সি৷

এর উপর নির্ভর করে, আমাদের ছবির সাথে কী করতে হবে তা একরকম সিদ্ধান্ত নিতে হবে।

আমাদের প্রতিটি মেশিনে একটি ছোট ডেমন চলছে যা ক্রমাগত এই লগটি পড়ে এবং এর মেমরিতে নির্দিষ্ট ফটোগ্রাফ ব্যবহারের পরিসংখ্যান সংরক্ষণ করে।

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

যে ফটোগুলি খুব কমই অনুরোধ করা হয় এবং কম ঘন ঘন অনুরোধ করা হয় সেগুলিকে ধীরে ধীরে গরম ক্যাশে থেকে ঠান্ডায় ঠেলে দেওয়া হয়৷

এবং যখন আমাদের ক্যাশে স্থান ফুরিয়ে যায়, তখন আমরা নির্বিচারে কোল্ড ক্যাশে থেকে সবকিছু মুছে ফেলতে শুরু করি। এবং উপায় দ্বারা, এই ভাল কাজ করে.

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

অবশিষ্ট প্রশ্ন হল কিভাবে এই সার্ভার জুড়ে অনুরোধ বিতরণ করা হয়।

ধরা যাক বিশটি স্টোরেজ মেশিন এবং তিনটি ক্যাশিং সার্ভারের একটি ক্লাস্টার রয়েছে (এটি কীভাবে ঘটেছিল)।

আমাদের কোনভাবে নির্ধারণ করতে হবে কোন অনুরোধ কোন ফটোগুলির জন্য এবং কোথায় সেগুলি ল্যান্ড করতে হবে৷

সবচেয়ে সাধারণ বিকল্প হল রাউন্ড রবিন। নাকি আকস্মিকভাবে এটা করবেন?

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

কোন সার্ভারে কোন অনুরোধে অবতরণ করতে হবে তা আমাদের একরকম দ্ব্যর্থহীনভাবে নির্ধারণ করতে হবে।

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

সেগুলো. আমাদের একটি 2% অনুরোধ রয়েছে, উদাহরণস্বরূপ, কিছু "example_url" এর জন্য এটি সর্বদা সূচী "XNUMX" সহ সার্ভারে অবতরণ করবে এবং ক্যাশে যথাসম্ভব সর্বোত্তমভাবে নিষ্পত্তি করা হবে৷

কিন্তু এই ধরনের স্কিমে রিশার্ডিংয়ে সমস্যা আছে। রিশার্ডিং - মানে সার্ভারের সংখ্যা পরিবর্তন করা।

আসুন ধরে নিই যে আমাদের ক্যাশিং ক্লাস্টার আর মোকাবেলা করতে পারে না এবং আমরা অন্য মেশিন যুক্ত করার সিদ্ধান্ত নিই।

এর যোগ করা যাক.

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

এই বিকল্পটি আমাদের জন্য উপযুক্ত নয়।

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

দেখতে কেমন লাগে?

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

প্রতিটি সার্ভার একটি বিন্দু দ্বারা সংজ্ঞায়িত করা হয়, এবং যে সেক্টর এটি ঘড়ির কাঁটার দিকে যায়, সেই অনুযায়ী, এই হোস্ট দ্বারা পরিবেশিত হয়। যখন আমাদের কাছে অনুরোধ আসে, আমরা অবিলম্বে দেখতে পাই যে, উদাহরণস্বরূপ, অনুরোধ A - সেখানে একটি হ্যাশ আছে - এবং এটি সার্ভার 2 দ্বারা পরিবেশিত হয়। অনুরোধ B - সার্ভার 3 দ্বারা। এবং আরও অনেক কিছু।

রিশার্ডিংয়ের সময় এই পরিস্থিতিতে কী ঘটে?

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

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

শুধু প্রশ্ন থেকে যায় প্রত্যাখ্যান। আসুন ধরে নিই যে কোনও ধরণের গাড়ি অর্ডারের বাইরে।

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

এটি ক্যাশিং সিস্টেম সম্পর্কে। চলুন ফলাফল তাকান.

দেখে মনে হবে এখানে জটিল কিছু নেই। কিন্তু ক্যাশে পরিচালনার এই পদ্ধতিটি আমাদের প্রায় 98% একটি কৌশলের হার দিয়েছে। সেগুলো. প্রতি সেকেন্ডে এই 80 হাজার অনুরোধের মধ্যে, মাত্র 1600টি সঞ্চয়স্থানে পৌঁছায় এবং এটি একটি সম্পূর্ণ স্বাভাবিক লোড, তারা শান্তভাবে এটি সহ্য করে, আমাদের কাছে সর্বদা একটি রিজার্ভ থাকে।

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

যে. তারা কমবেশি স্থানীয়ভাবে আমাদের প্রতিটি টার্গেট মার্কেটে অবস্থিত।

এবং একটি চমৎকার বোনাস হিসাবে, আমরা এই ক্যাশিং প্রক্সি পেয়েছি, যার উপর CPU আসলে নিষ্ক্রিয়, কারণ বিষয়বস্তু পরিবেশনের জন্য এটির তেমন প্রয়োজন নেই। এবং সেখানে, NGINX+ Lua ব্যবহার করে, আমরা অনেক উপযোগী যুক্তি প্রয়োগ করেছি।

উদাহরণস্বরূপ, আমরা ওয়েবপি বা প্রগতিশীল জেপিইজি (এগুলি কার্যকর আধুনিক ফর্ম্যাট) নিয়ে পরীক্ষা করতে পারি, এটি কীভাবে ট্র্যাফিককে প্রভাবিত করে তা দেখতে পারি, কিছু সিদ্ধান্ত নিতে পারি, নির্দিষ্ট দেশের জন্য এটি সক্ষম করতে পারি ইত্যাদি; গতিশীল আকার পরিবর্তন করুন বা ফ্লাইতে ফটো ক্রপ করুন।

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

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

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

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

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

এবং, সম্ভবত, একজন পরিশীলিত শ্রোতার একটি প্রশ্ন থাকতে পারে: কেন শুধু সবকিছু CDN এ পরিবর্তন করবেন না? এটি প্রায় একই হবে; সমস্ত আধুনিক CDN এটি করতে পারে। এবং অনেক কারণ আছে.

প্রথমটি হল ফটোগ্রাফ।

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

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

দ্বিতীয় উপসংহারটিও বরং ঐতিহাসিক, কারণ সিস্টেমটি দীর্ঘকাল ধরে বিকাশ লাভ করছে, এবং বিভিন্ন পর্যায়ে বিভিন্ন ব্যবসায়ের প্রয়োজনীয়তা ছিল এবং সেগুলি সবসময় CDN ধারণার সাথে খাপ খায় না।

এবং আগের এক থেকে যে বিন্দু অনুসরণ করা হয়

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

এই উপসংহার কি প্রস্তাব করে? আমাদের ক্ষেত্রে, CDN খুব একটা ভালো বিকল্প নয়।

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

কিন্তু আপনার যদি কিছু সাধারণ সমাধান থাকে এবং কাজটি খুব নির্দিষ্ট না হয়, আপনি একেবারে নিরাপদে একটি CDN নিতে পারেন। অথবা যদি সময় এবং সম্পদ নিয়ন্ত্রণের চেয়ে আপনার কাছে বেশি গুরুত্বপূর্ণ হয়।

এবং আধুনিক CDN-এ প্রায় সবই আছে যা আমি আপনাকে এখন বলেছি। প্লাস বা মাইনাস বাদে কিছু ফিচার।

এই ছবি দূরে দেওয়া সম্পর্কে.

আসুন এখন আমাদের পূর্ববর্তী দৃষ্টিভঙ্গিতে একটু এগিয়ে যাই এবং স্টোরেজ সম্পর্কে কথা বলি।

2013 কেটে যাচ্ছিল।

ক্যাশিং সার্ভার যোগ করা হয়েছে, কর্মক্ষমতা সমস্যা চলে গেছে। সবকিছু ঠিক আছে. ডেটাসেট বাড়ছে। 2013 সাল পর্যন্ত, আমাদের কাছে স্টোরেজের সাথে প্রায় 80টি সার্ভার সংযুক্ত ছিল এবং প্রতিটি ডিসিতে প্রায় 40টি ক্যাশিং সার্ভার ছিল৷ এটি প্রতিটি DC-তে 560 টেরাবাইট ডেটা, অর্থাৎ মোট প্রায় একটি পেটাবাইট।

এবং ডেটাসেটের বৃদ্ধির সাথে, অপারেটিং খরচ উল্লেখযোগ্যভাবে বৃদ্ধি পেতে শুরু করে। এর মানে কি?

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

প্রথমত, স্টোরেজ এরিয়া নেটওয়ার্ক (SAN) নিজেই, যা ব্যর্থ হতে পারে।

দ্বিতীয়ত, এটি অপটিক্সের মাধ্যমে শেষ মেশিনের সাথে সংযুক্ত। অপটিক্যাল কার্ড এবং স্পার্ক প্লাগের সমস্যা হতে পারে।

অবশ্যই, SAN এর মতো তাদের মধ্যে অনেকগুলি নেই, তবে, তবুও, এগুলিও ব্যর্থতার পয়েন্ট।

এর পরে মেশিনটি নিজেই, যা স্টোরেজের সাথে সংযুক্ত। এটি ব্যর্থও হতে পারে।

মোট, আমাদের ব্যর্থতার তিনটি পয়েন্ট রয়েছে।

আরও, ব্যর্থতার পয়েন্টগুলি ছাড়াও, স্টোরেজেরই ভারী রক্ষণাবেক্ষণ রয়েছে।

এটি একটি জটিল মাল্টি-কম্পোনেন্ট সিস্টেম, এবং সিস্টেম ইঞ্জিনিয়ারদের এটির সাথে কাজ করা কঠিন সময় থাকতে পারে।

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

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

এ বিষয়ে কিছু করার দরকার ছিল। এবং আমরা সিদ্ধান্ত নিয়েছি যে আমাদের শুধু ডেটা ব্যাকআপ করতে হবে। এটি আসলে একটি সুস্পষ্ট সমাধান এবং একটি ভাল। আমরা কি করলাম?

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

আমরা শুধু একটি দ্বিতীয় বিভাগ যোগ করেছি।

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

এখানে আমরা কেবল কাছাকাছি একটি অ্যাসিঙ্ক্রোনাস সারি তৈরি করি।

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

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

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

এবং আমরা একটি তৃতীয় ডিস্ক যোগ করেছি, যা একটি ছোট SSD, এবং এটিকে একটি বাফার বলে।

এটা এখন কিভাবে কাজ করে.

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

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

ভাল, এবং সবচেয়ে গুরুত্বপূর্ণ: আমরা ডেটা হারানো বন্ধ করে দিয়েছি।

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

প্রথমত, এটি ভৌত ​​হোস্টের আকারে ব্যর্থতার একটি বিন্দু যার উপর এই সমস্ত যন্ত্রপাতি চলে; এটি চলে যায় নি।

দ্বিতীয়ত, এখনও SAN-এর সমস্যা, তাদের ভারী রক্ষণাবেক্ষণ, ইত্যাদি রয়ে গেছে। এটা ছিল না যে এটি একটি সমালোচনামূলক ফ্যাক্টর ছিল, কিন্তু আমি এটি ছাড়া কোনোভাবে বেঁচে থাকার চেষ্টা করতে চেয়েছিলাম।

এবং আমরা তৃতীয় সংস্করণ তৈরি করেছি (আসলে, দ্বিতীয়টি আসলে) - সংরক্ষণ সংস্করণ। এটি দেখতে কেমন?

এটাই ছিল -

আমাদের প্রধান সমস্যা হল যে এটি একটি শারীরিক হোস্ট।

প্রথমত, আমরা SAN সরিয়ে দিচ্ছি কারণ আমরা পরীক্ষা করতে চাই, আমরা শুধু স্থানীয় হার্ড ড্রাইভ ব্যবহার করতে চাই।

এটি ইতিমধ্যে 2014-2015, এবং সেই সময়ে ডিস্কগুলির পরিস্থিতি এবং একটি হোস্টে তাদের ক্ষমতা আরও ভাল হয়ে উঠেছে। আমরা সিদ্ধান্ত নিয়েছি কেন এটি চেষ্টা করবেন না।

এবং তারপরে আমরা কেবল আমাদের ব্যাকআপ পার্টিশনটি গ্রহণ করি এবং শারীরিকভাবে এটি একটি পৃথক মেশিনে স্থানান্তর করি।

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

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

এটা কিভাবে কাজ করে, একটু বিস্তারিত দেখলে।

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

কাজটা একটু বেশি কঠিন।

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

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

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

আমাদের পরিস্থিতিতে, এটি ধীরে ধীরে কাজ করে না।

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

তাই আমরা আর কি আছে যে সত্যিই চমৎকার আছে?

পূর্বে, আমাদের প্রধান ব্যাকআপ পার্টিশন ছিল এবং আমরা সেগুলি থেকে ক্রমানুসারে পড়তাম। সেগুলো. আমরা সর্বদা প্রথমে প্রধানটিতে অনুসন্ধান করি এবং তারপরে ব্যাকআপে। এটা এক চাল ছিল.

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

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

একটি গাড়ি ভেঙে পড়ে।

সমস্যা নেই! একজন সিস্টেম ইঞ্জিনিয়ার হয়তো রাতেও জাগবেন না, তিনি সকাল পর্যন্ত অপেক্ষা করবেন, খারাপ কিছু হবে না।

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

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

এই অপ্রয়োজনীয় স্কিম থেকে কি উপসংহার টানা যেতে পারে?

আমরা দোষ সহনশীলতা পেয়েছি।

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

আমরা ডাবল রিডিং অ্যালাউন্স পেয়েছি।

এটি দোষ সহনশীলতা ছাড়াও একটি খুব ভাল বোনাস।

কিন্তু সমস্যাও আছে। এখন আমাদের এই সম্পর্কিত কিছু বৈশিষ্ট্যের আরও জটিল বিকাশ রয়েছে, কারণ সিস্টেমটি অবশেষে 100% সামঞ্জস্যপূর্ণ হয়ে উঠেছে।

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

এবং এখানে আবার কিছু দ্বন্দ্ব দেখা দেয়।

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

হ্যাঁ, প্রকৃতপক্ষে, সময়ের সাথে সাথে পরিস্থিতি অনেক পরিবর্তিত হয়েছে এবং এখন এই পদ্ধতির অনেক সুবিধা রয়েছে। প্রথমত, আমরা অনেক সহজ অপারেশন পেতে.

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

সেখানে প্রচুর পরিমাণে যন্ত্রপাতি রয়েছে এবং এগুলি মাত্র কয়েকটি ডিস্ক যা এখানে মেশিনে একটি অভিযানে একত্রিত হয়।

কিন্তু অসুবিধাও আছে।

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

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

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

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

ফলাফল

আমাদের ব্যবহারকারী আছে - 33 মিলিয়নের মতো।

আমাদের উপস্থিতির তিনটি পয়েন্ট রয়েছে - প্রাগ, মিয়ামি, হংকং।

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

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

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

তদুপরি, এই মেশিনগুলির মধ্যে কিছু স্থানীয় হার্ড ড্রাইভের সাথে কাজ করে।

এই মেশিনগুলির মধ্যে কিছু SAN এর সাথে সংযুক্ত।

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

আমরা কী পেয়েছি এবং কীভাবে এটি সব বিকশিত হয়েছে তার স্থাপত্যের এটি একটি সংক্ষিপ্ত বিবরণ।

অধিনায়কের কাছ থেকে আরও কয়েকটি টিপস, খুব সহজ।

প্রথমত, আপনি যদি হঠাৎ সিদ্ধান্ত নেন যে আপনার ছবির পরিকাঠামোর সবকিছুকে জরুরিভাবে উন্নত করতে হবে, প্রথমে পরিমাপ করুন, কারণ সম্ভবত কিছুই উন্নত করার দরকার নেই।

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

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

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

প্রথমে আমরা এটি পরিমাপ করেছি, তারপরে আমরা এটি উন্নত করেছি।

আরও আমরা ক্যাশে দিয়ে পড়াকে অপ্টিমাইজ করি, শার্ডিং দিয়ে লেখা, কিন্তু এটি একটি সুস্পষ্ট বিষয়।

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

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

পরবর্তী পয়েন্ট. ফ্লাই উপর আকার পরিবর্তন সম্পর্কে.

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

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

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

এবং ইনক্রিমেন্টাল অ্যাসিঙ্ক্রোনাস ব্যাকআপ ভাল।

যেমন আমাদের অনুশীলন দেখিয়েছে, এই স্কিমটি পরিবর্তিত ফাইলগুলির বিলম্বিত অনুলিপির সাথে দুর্দান্ত কাজ করে।

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

যোগাযোগ

» bo0rsh201
» বাদু ব্লগ

এই প্রতিবেদনটি হাই-লোড সিস্টেমের বিকাশকারীদের সম্মেলনের সেরা বক্তৃতার একটি প্রতিলিপি হাইলোড++. HighLoad++ 2017 সম্মেলন হতে এক মাসেরও কম বাকি আছে।

আমরা ইতিমধ্যে এটি প্রস্তুত আছে সম্মেলন প্রোগ্রাম, তফসিল এখন সক্রিয়ভাবে গঠিত হচ্ছে.

এই বছর আমরা স্থাপত্য এবং স্কেলিং বিষয় অন্বেষণ অবিরত:

• কিভাবে এক বিলিয়ন ব্যবহারকারীদের পরিবেশন করা যায় এবং একটি টেরাবিট ট্রাফিক প্রদান করা যায় / ইগর ভাসিলিভ
• কীভাবে ভিকন্টাক্টে ব্যক্তিগত বার্তা ডাটাবেস স্ক্র্যাচ থেকে পুনরায় লিখবেন এবং ডাউনটাইম ছাড়াই এটিতে স্থানান্তর করবেন / দিমিত্রি এগোরভ
• বিক্রয় দ্বারা মৃত্যু: কিভাবে Yandex.Money ব্ল্যাক ফ্রাইডে ত্বরান্বিত করার এবং বেঁচে থাকার চেষ্টা করেছিল / আনাতোলি প্লাসকোভস্কি
• ব্যাংকের ফ্রন্ট-এন্ড সিস্টেমের ত্রুটি-সহনশীল আর্কিটেকচার / রোমান শেখভতসভ, আলেক্সি গ্রোমাচিকভ
• পেমেন্ট সিস্টেম আর্কিটেকচার: প্রায় এন্টারপ্রাইজ / ফিলিপ ডেলগাডো

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

উত্স: www.habr.com