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

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

আসুন তথ্য ফিল্টার করার চেষ্টা করি এবং মৌলিক সূত্রটি লিখি। আমরা আমাদের নতুন ফটো শেয়ারিং সাইট Graminsta ধাপে ধাপে 1 থেকে 100 ব্যবহারকারীদের স্কেল করতে যাচ্ছি।

শ্রোতা 10, 100, 1000, 10 এবং 000 জনে বাড়লে কী কী নির্দিষ্ট পদক্ষেপ নেওয়া দরকার তা লিখুন।

1 ব্যবহারকারী: 1 মেশিন

প্রায় প্রতিটি অ্যাপ্লিকেশন, এটি একটি ওয়েবসাইট বা একটি মোবাইল অ্যাপ্লিকেশন, তিনটি মূল উপাদান আছে:

• এপিআই
• ডাটাবেসের
• ক্লায়েন্ট (মোবাইল অ্যাপ্লিকেশন নিজেই বা ওয়েবসাইট)

ডাটাবেস ক্রমাগত ডেটা সঞ্চয় করে। API এই ডেটাতে এবং তার আশেপাশে অনুরোধগুলি পরিবেশন করে৷ ক্লায়েন্ট ব্যবহারকারীর কাছে ডেটা প্রেরণ করে।

আমি উপসংহারে পৌঁছেছি যে একটি অ্যাপ্লিকেশন স্কেল করার বিষয়ে কথা বলা অনেক সহজ যদি, একটি আর্কিটেকচারাল দৃষ্টিকোণ থেকে, ক্লায়েন্ট এবং API সত্তা সম্পূর্ণরূপে আলাদা করা হয়।

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

তাত্ত্বিকভাবে, আমরা এটিকে একটি একক DigitalOcean Droplet বা AWS EC2 উদাহরণে ক্লাউডে স্থাপন করতে পারি, যেমনটি নীচে দেখানো হয়েছে:

এর সাথে বলা হয়েছে, যদি একটি সাইটে একাধিক ব্যবহারকারী থাকে, তবে এটি প্রায় সবসময়ই একটি ডাটাবেস স্তর উৎসর্গ করার অর্থ বহন করে।

10 ব্যবহারকারী: ডাটাবেস একটি পৃথক স্তরে সরানো

Amazon RDS বা Digital Ocean Managed Database-এর মতো পরিচালিত পরিষেবাগুলিতে ডাটাবেস বিভক্ত করা আমাদের দীর্ঘ সময়ের জন্য ভালভাবে পরিবেশন করবে। এটি একটি একক মেশিন বা EC2 উদাহরণে স্ব-হোস্টিংয়ের চেয়ে একটু বেশি ব্যয়বহুল, তবে এই পরিষেবাগুলির সাথে আপনি বাক্সের বাইরে অনেক দরকারী এক্সটেনশন পাবেন যা ভবিষ্যতে কাজে আসবে: বহু-অঞ্চল ব্যাকআপ, প্রতিলিপি পড়ুন, স্বয়ংক্রিয় ব্যাকআপ, এবং আরও অনেক কিছু।

এই সিস্টেমটি এখন কেমন দেখাচ্ছে:

100 ব্যবহারকারী: ক্লায়েন্টকে একটি পৃথক স্তরে নিয়ে যাওয়া

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

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

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

এই ধরনের একটি সিস্টেমের মত দেখায়:

1000 ব্যবহারকারী: লোড ব্যালেন্সার যোগ করুন

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

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

আমরা ওয়েব ক্লায়েন্টের সামনে এবং API এর সামনে আলাদা লোড ব্যালেন্সার স্থাপন করতে যাচ্ছি। এর মানে আপনি API কোড এবং ওয়েব ক্লায়েন্ট কোড চলমান একাধিক উদাহরণ চালাতে পারেন। লোড ব্যালেন্সার কম লোড করা সার্ভারের কাছে অনুরোধ পাঠাবে।

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

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

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

বিঃদ্রঃ. এই মুহুর্তে আমাদের সিস্টেমটি AWS-এ Heroku বা ইলাস্টিক Beanstalk-এর মতো PaaS কোম্পানিগুলি বাক্সের বাইরে যা অফার করে তার সাথে খুব মিল রয়েছে (যে কারণে তারা এত জনপ্রিয়)। Heroku ডাটাবেসটিকে একটি পৃথক হোস্টে রাখে, একটি স্বয়ংক্রিয়-স্কেলিং লোড ব্যালেন্সার পরিচালনা করে এবং আপনাকে API থেকে আলাদাভাবে ওয়েব ক্লায়েন্ট হোস্ট করার অনুমতি দেয়। এটি প্রাথমিক পর্যায়ের প্রকল্প বা স্টার্টআপের জন্য Heroku ব্যবহার করার একটি দুর্দান্ত কারণ - আপনি বাক্সের বাইরে সমস্ত মৌলিক পরিষেবা পাবেন।

10 ব্যবহারকারী: CDN

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

এই পর্যায়ে, আপনাকে স্ট্যাটিক সামগ্রী সংরক্ষণের জন্য একটি ক্লাউড পরিষেবা ব্যবহার করতে হবে - ছবি, ভিডিও এবং আরও অনেক কিছু (AWS S3 বা Digital Ocean Spaces)। সাধারণভাবে, আমাদের API-এর উচিত ছবি পরিবেশন করা এবং সার্ভারে ছবি আপলোড করার মতো জিনিসগুলি পরিচালনা করা এড়ানো উচিত।

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

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

100 ব্যবহারকারী: ডেটা স্তর স্কেলিং

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

মেট্রিক্সে একটু খনন করে, আমরা দেখতে পাই যে ডাটাবেস সার্ভারে CPU 80-90% লোড হয়েছে। আমরা সীমায় আছি।

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

ক্যাশিং

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

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

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

আমরা কী দ্বারা Redis-এ ডাটাবেস থেকে ফলাফল ক্যাশে করব user:id 30 সেকেন্ডের মেয়াদ সহ। এখন, যখন কেউ Mobrik-এর প্রোফাইলে যায়, আমরা প্রথমে Redis চেক করি, এবং যদি ডেটা থাকে, তাহলে আমরা সরাসরি Redis থেকে তা স্থানান্তর করি। এখন সাইটের সর্বাধিক জনপ্রিয় প্রোফাইলে অনুরোধগুলি কার্যত আমাদের ডাটাবেস লোড করে না।

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

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

প্রতিলিপি পড়ুন

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

এখানে এখন আমাদের সিস্টেম:

পরবর্তী পদক্ষেপ

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

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

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

সূত্র

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

পাদটীকা

1. যদিও একাধিক দৃষ্টান্ত জুড়ে লোড বিতরণের ক্ষেত্রে একই রকম, একটি Redis ক্লাস্টারের অন্তর্নিহিত বাস্তবায়ন একটি লোড ব্যালেন্সারের থেকে খুব আলাদা। [ফেরা]

উত্স: www.habr.com