Skip to content

Latest commit

 

History

History
110 lines (63 loc) · 19 KB

SystemDesign.md

File metadata and controls

110 lines (63 loc) · 19 KB

সিস্টেম ডিজাইন

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

Horizontal and vertical scaling

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

Vertical Scaling যখন আমরা আমাদের ওয়েব সার্ভারের মেশিনের সক্ষমতা বৃদ্ধি করি অর্থাৎ র‍্যাম লাগাই অথবা বড় হার্ডডিস্ক যোগ করি সেটাই হল Vertical Scaling। কিন্তু একটা মেশিনে আমরা যতই কিছু যোগ করি কেন তার একটা লিমিটেশন থাকবে।

Horizontal Scaling এই ক্ষেত্রে আমরা আমাদের একটা সার্ভারের সাথে আমরা একাধিক মেশিন যুক্ত করি। যখন কোন রিকুয়েস্ট আসবে তখন লোড ব্যালান্সার বলে দিবে কোন মেশিন আমাদেরকে রেসপন্স দিবে।

Vertical Scaling Horizontal Scaling
It is easy to implement It is difficult to implement
Maintenance is cheaper and it is less complex because of the number of nodes you will need to manage. Maintainance is complex as you will need to manage a lot of machines.
Adding a new machine is far more expensive than upgrading old ones. Initial costs are high but buying a new machine with low processing power is more affordable.
Failures will lead to loss of service. In case of failure in a machine, others can still provide the service.
Data exchange becomes relatively straightforward as we only have one machine. Having multiple machines requires complex protocols for exchanging data between them.
Since we have one device, tasks can't be spread. Some level of parallel processing is achievable using a multi-threading programming model, but it's limited to the machine's capacity. Traffic/programming tasks can be distributed between the machines.

Trade offs

CAP theorem

Distributed System এর ক্ষেত্রে আমরা চাই সিস্টেমটা সব সময় ঠিক ভাবে কাজ করুক কোন ধরনের কোন সমস্যা ছাড়াই। একটা বড় সিস্টেম চালানোর সময় আপনি অনেক ধরনের সমস্যার সম্মুখীন হতে পারেন। যেমন ধরুন আপনার যেকোন একটা সার্ভার বন্ধ হয়ে যেতে পারে অথবা একটি কাজ একি সাথে ২ জন ইউজার করতে গিয়ে সমস্যায় পড়তে পারে। এসব কিছু সত্ত্বেও আপানকে সিস্টেমটা চলমান রাখতে হবে। এ জন্য ৩ টা জিনিস অনেক গুরুত্বপূর্ণ - consistency, availability এবং partition tolerance। কিন্তু এখানে সমস্যা হচ্ছে আপনি কখনোই এই ৩ টা জিনিস এক সাথে পাবেন না আপনাকে যে কোন ২ টা নিতে হবে। আগে আমরা এই ৩ টা কি ওয়ার্ড বোঝার চেষ্টা করি। তারপর আমাদের ক্যাপ থেওরেম বুঝতে সুবিধা হবে।

CAP Theorem

Consistency

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

Availability

Availability হল আপ্লিকেশন সব সময় যেন request নিতে পারে এবং response দিতে পারে। একটা বড় সিস্টেমে অনেকগুলো সার্ভিস চালু থাকে কিন্তু এর কয়েকটা সার্ভিস বন্ধ হলেও যেন সিস্টেমে ইউজার ভাল মত ব্যবহার করতে পারে অর্থাৎ request পাঠাতে পারে এবং response পায়। যদি ইউজার সার্ভিস না পায় তাহলে সিস্টেম তার Availability হারাবে।

Partition Tolerance

Partition Tolerance হল খুব সাধারণ একটা বিষয় Distributed System এর ক্ষেত্রে। অনেক সময় ২ টা সার্ভিস পরস্পর তথ্য আদান প্রদান করে এইটা নেটওয়ার্কের সমস্যার কারনে কানেকশান চলে যেতে পারে। কিন্তু তারপর ও আপনার আপ্লিকেশনকে কাজ করতে হবে। এইটাই হল Partition Tolerance যাতে একাধিক সার্ভিস নিজেরা কানেকশান হারালে ও আপ্লিকেশন ঠিকঠাক ভাবে কাজ করে।

ক্যাপ থিওরেম

Distributed System এর ক্ষেত্রে আপনাকে সিদ্ধান্ত নিতে হবে আপনার চাওয়া অনুযায়ী আপনি কোন দুইটা চান। এই Trade Off আপনার বিজনেস রিকয়ারমেন্টের উপর ভিত্তি করে নিতে হবে। ধরুন আপনার আপনার Consistency আর Availability এক সাথে দরকার তাহলে আপনার দরকার এমন ডাটাবেজ যেটা CA মডেল অনুযায়ী। আবার যদি আপনার এমন প্রয়োজন হয় আপনার দরকার Availability আর Partition Tolerance তাহলে আপনার দরকার AP সিস্টেম। এইটা তিন ধরনের কম্বিনেশন হয়ে থাকে - CP, AP এবং CA।

CA ডেটাবেজ

CA ডেটাবেজ একই সাথে Consistency এবং Availability দেয়। এই ক্ষেত্রে Partition Tolerance এর সাপোর্ট পাওয়া যাবে না। এইটা সাধারণত আপনি মনোলিথ আপ্লিকেশনে ব্যবহার করতে পারবেন কারণ সেখানে একটাই ডেটাবেজ চলবে। সুতরাং নোড বিচ্ছিন্ন হওয়ার প্রশ্নই ওঠে না। PostgreSQL এমন একটা ডেটাবেজেের উদাহরন।

CP ডেটাবেজ

CP ডেটাবেজ আপনাকে Consistency এবং Partition Tolerance দিবে। এখানে আপনি Availability পাবেন না। যখন ২ টা নোড বিচ্ছিন্ন হবে তখন এইটা অটোমেটিকালি Inconsistent নোড গুলো অফ করে দিবে এবং পুনরায় কানেকশান পেলে তখন আপনার ডেটাবেজ Availabile হবে। MongoDB হল CP ডেটাবেজ।

AP ডেটাবেজ

AP ডেটাবেজ Availability এবং Partition Tolerance এক সাথে পাওয়ার জন্য। কিন্তু এইখানে আপনি Consistency পাবেন না। কারণ আপনার সিস্টেম সব সময় Availabile থাকবে একাধিক নোড বিচ্ছিন্ন হওয়ার সত্ত্বেও। সেই ক্ষেত্রে Inconsistent নোড গুলোতে পূর্বের ভার্সনের ডাটাই দেখাবে, তখন আপনার সিস্টেম Consistency হারাবে। Apache Cassandra এই ধরনের একটা ডেটাবেজ।

উপরোক্ত ৩ টা অপশন থেকে আপনার প্রয়োজন অনুযায়ী যে কোন একটা বেছে নিতে হবে। এইটাই ক্যাপ থিওরেম এর মূল কথা।

Redundancy and Replication

Load Balancer

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

Caching

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

Content Delivery Network

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

CDN সাধারণত দুই ধরনের হয়। পুশ CDN আর পুল CDN।

CDN

Database

Relational database management system (RDBMS) হল ডেটা সাজিয়ে রাখা নির্দিষ্ট একটি টেবিলে। ACID হল রিলেশনাল ডেটাবেজের কিছু গুরুত্বপূর্ণ বৈশিষ্ট্য।

Atomicity

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

Consistency

কন্সিস্টেন্সি হল ডেটাবেজে সবসময় সঠিক ডেটা দেখাবে। ডেটাবেজে যদি কোন ভ্যালু যোগ হয় অথবা মুছে দেওয়া হয় তাহলে যেন এটা ঠিক ঠাক দেখায়।

Isolation

যদি একাধিক ট্রান্সাকশন এক সাথে চলে তাহলে একটা ট্রান্সাকাশন অন্যটাকে প্রভাব ফেলবে না।

Durability

ডেটাবেজের যে কোন সেভ অপারেশন অবশ্যই সম্পূর্ণ হতে হবে সিস্টেম ফেইল হওয়ার সত্ত্বেও।

Database Scaling

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

ডেটাবেজ স্কেলিং এর বিভিন্ন ধরনের পদ্ধতি আছে। যেমনঃ

master-slave replication

master-master replication

federation

sharding

denormalization

SQL tuning