Distributed System

Distributed System কী?

একাধিক স্বাধীন কম্পিউটার (node) নেটওয়ার্কের মাধ্যমে যোগাযোগ করে একটি অভিন্ন কাজ সম্পন্ন করলে এবং ব্যবহারকারীর কাছে সেটি একটি একক সিস্টেম বলে মনে হলে তাকে Distributed System বলে।

একটি মেশিনে হয় সবকিছু চলে, নয়তো সবকিছু বন্ধ হয়। কিন্তু distributed system এ একটি node ডাউন হয়ে যেতে পারে, নেটওয়ার্ক ধীর হতে পারে, একটি বার্তা হারিয়ে যেতে পারে, অথচ বাকিরা চলছে। এই অনিশ্চয়তাই সমস্ত জটিলতার উৎস।

কেন আমরা distributed system বানাই?

সতর্কতা: Distributed system কোনো লক্ষ্য নয়, এটি একটি প্রয়োজনীয় মূল্য। একটি মেশিনে কাজ চললে সেটিই সবচেয়ে সহজ ও নির্ভরযোগ্য। যখন একটি সার্ভার আর যথেষ্ট থাকে না, তখনই কেবল এই জটিলতা নিন।

Distributed System এর চ্যালেঞ্জ সমূহ

• Network Latency: বিভিন্ন নোডের মধ্যে ডেটা আদান-প্রদান সময়সাপেক্ষ।

• Data Consistency Issues: সব নোডে একই ডাটা রাখা কঠিন।

• Single Point of Failure: যদি Load Balancer নষ্ট হয়, তাহলে পুরো সিস্টেম ব্যর্থ হতে পারে।

distributed system এর প্রায় প্রতিটি সমস্যা এর কোনো একটি থেকে জন্মায়। তাই ডিজাইনের মূলমন্ত্র হলো: "যা ভুল হতে পারে, তা একদিন হবেই।"

Distributed System এর মূল বৈশিষ্ট্য

1. Scalability: বড় পরিসরে নতুন নোড যুক্ত করা সহজ হওয়া উচিত।

2. Fault Tolerance: যদি কোনো নোড ফেল করে, তাহলে পুরো সিস্টেম যেন Fail না হয়।

3. Consistency: সব নোডে একই ডেটা থাকাটা গুরুত্বপূর্ণ।

4. Availability: সার্ভিস সর্বদা Accessible হওয়া উচিত।

5. Concurrency: একাধিক রিকোয়েস্ট একসাথে প্রসেস করার ক্ষমতা থাকতে হবে।

CAP Theorem

CAP Theorem বলে যে একটি Distributed System সর্বদা নিম্নলিখিত তিনটি বৈশিষ্ট্যের মধ্যে মাত্র দুটি বজায় রাখতে পারে:

1. Consistency (C): সব নোডে একই ডেটা থাকবে।

2. Availability (A): সার্ভিস সর্বদা অ্যাক্সেসযোগ্য থাকবে।

3. Partition Tolerance (P): যদি কোনো নেটওয়ার্ক বিভাজন ঘটে, তাহলে সিস্টেম কাজ করতে সক্ষম হবে।

উদাহরণস্বরূপ, Amazon DynamoDB Availability এবং Partition Tolerance বজায় রাখে কিন্তু Consistency ত্যাগ করে। অন্যদিকে, Google Spanner Consistency এবং Partition Tolerance বজায় রাখে কিন্তু Availability কিছুটা কমিয়ে দেয়।

Distributed System এর কম্পোনেন্ট সমূহ

1. Load Balancer: সার্ভারগুলোর উপর লোড সমানভাবে ভাগ করে।

2. Database Replication: একই ডেটার একাধিক কপি রাখে, যাতে ডাটা লস না হয়।

3. Message Queue: সার্ভিসগুলোর মধ্যে অ্যাসিনক্রোনাস (Asynchronous) কমিউনিকেশন নিশ্চিত করে।

4. Caching: বারবার একই রিকোয়েস্ট হলে দ্রুত উত্তর দিতে পারে। যেমন, Redis, Memcached।

Distributed Transaction: একাধিক সার্ভিসে একটি কাজ

অর্ডার করলে Inventory কমবে, Payment কাটবে, Order তৈরি হবে, তিনটি ভিন্ন সার্ভিসে। কোনো একটি ফেল করলে?

Two-Phase Commit (2PC):
১. Prepare: coordinator সবাইকে জিজ্ঞেস করে "কমিট করতে পারবে?"
২. Commit/Abort: সবাই হ্যাঁ বললে কমিট, নইলে সবাই rollback।
সমস্যা: blocking। coordinator মরলে participant-রা lock ধরে আটকে থাকে। এটি ধীর ও availability কমায়, তাই microservices এ প্রায় এড়ানো হয়।

Saga Pattern: একটি বড় transaction কে ক্রমিক স্থানীয় transaction-এ ভাগ করা, প্রতিটির জন্য একটি compensating action সহ।

১. Order create → ২. Inventory reserve → ৩. Payment failed
                                            │ if failed
                         ◄──────────────────┘
   Inventory release → Order cancel

• Choreography: প্রতিটি সার্ভিস event শুনে নিজে সিদ্ধান্ত নেয়।

• Orchestration: একটি কেন্দ্রীয় orchestrator পরবর্তী কাজের ক্রম মেইনটেইন করে এবং নিজে সিদ্ধান্ত নেয়।

Distributed system-এর সারকথা: আপনি এমন একটি জগতে কাজ করছেন যেখানে নেটওয়ার্ক বিশ্বাসযোগ্য নয়, ঘড়ি মেলে না এবং যেকোনো অংশ যেকোনো সময় ব্যর্থ হতে পারে। সফল ডিজাইন এই বাস্তবতাকে অস্বীকার করে না, বরং ব্যর্থতাকে ধরে নিয়েই নকশা করে এবং প্রতিটি ক্ষেত্রে সচেতনভাবে trade-off বেছে নেয়: consistency বনাম availability, latency বনাম correctness, সরলতা বনাম ক্ষমতা।