Failure Domain: single point ও shared failure
Single Points of Failure and Failure Domains
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Single point of failure চিহ্নিত করা
- Correlated failure ও blast radius বোঝা
- Tenant ও dependency isolation পরিকল্পনা
সমস্যা দিয়ে শুরু
চারটি Laravel instance একই rack-এ, একই Redis cache এবং একই deployment script ব্যবহার করে। Rack power failure বা ভুল config push সব instance একসঙ্গে থামায়। Hardware redundancy থাকলেও shared control plane এবং operational action common failure তৈরি করতে পারে। Architecture review-এ কত server আছে নয়, কোন একটি ঘটনা কতগুলো component একসঙ্গে হারাতে পারে—এই প্রশ্ন গুরুত্বপূর্ণ।
সহজ করে বুঝি
Failure domain হলো এমন boundary যার ভেতরের component একই ঘটনার কারণে একসঙ্গে ক্ষতিগ্রস্ত হতে পারে। Process, host, rack, zone, region, cloud account এবং software release ভিন্ন domain। Single point of failure এমন dependency যার ব্যর্থতায় প্রয়োজনীয় service বন্ধ হয়। Blast radius সেই failure-এর প্রভাবের ব্যাপ্তি। Domain কম ভাগ করলে operational simplicity বাড়ে, বেশি ভাগ করলে cost ও coordination বাড়ে।
পরিচিত একটি উপমা
দুইটি পানির tank আছে, কিন্তু দুটোর outlet একই মরচেধরা pipe-এ। Tank redundancy pipe failure রক্ষা করে না। আবার এক control switch দিয়ে সব pump বন্ধ হলে power panel-ও common failure domain।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD U[Users] --> R[Router] R --> A[Cell A web queue cache] R --> B[Cell B web queue cache] A --> DA[(Cell A data)] B --> DB[(Cell B data)] C[Shared configuration] -.-> A C -.-> B
Router users-কে cell-এ ভাগ করে। প্রতিটি cell-এর workload ও কিছু dependency আলাদা হলে একটি cell failure পুরো platform থামায় না। নিচের data partition-এর ownership স্পষ্ট থাকতে হবে। Shared configuration dotted arrow দিয়ে দেখানো common risk; এক ভুল update দুই cell-ই নষ্ট করতে পারে। Isolation-এর সঙ্গে staged configuration rollout দরকার।
PHP ও Laravel-এ প্রয়োগ
Laravel config/services.php-এর cell identifier এবং job log fragment। Cell assignment server-controlled এবং routing/storage isolation বাইরে বাস্তবায়িত হবে। শুধু log field যোগ করলে isolation তৈরি হয় না; এটি incident impact আলাদা করে দেখার evidence দেয়।
use Illuminate\Support\Facades\Log;
Log::info('invoice_job_started', [
'cell' => config('app.cell', 'unassigned'),
'tenant_id' => $this->tenantId,
'invoice_id' => $this->invoiceId,
]);সুবিধা, সীমাবদ্ধতা ও trade-off
Cells বা bulkheads noisy tenant ও software failure-এর প্রভাব সীমিত করতে পারে। বিনিময়ে underused capacity, routing complexity ও cross-cell operations জটিল হয়। Zone spread physical correlation কমায় কিন্তু bad code rollout ঠেকায় না। Independent service account credential leak-এর blast radius কমাতে পারে; permissions একই admin হলে account নাম আলাদা রেখে লাভ কম।
সাধারণ ভুল
- Server-এর সংখ্যা দেখে independent failure domain ধরে নেওয়া।
- সব cell-এ একই সময়ে config ও code push করা।
- এক tenant-এর background কাজকে পুরো worker pool দখল করতে দেওয়া।
আরও একটু গভীরে
Dependency map-এ DNS, secrets, certificates, billing account এবং deployment pipeline অন্তর্ভুক্ত করুন। এগুলো runtime box-এর বাইরে থাকলেও outage ঘটাতে পারে। Common library bug shared fate তৈরি করতে পারে; gradual rollout early warning দেয়। Recovery drill-এ একটি domain বাদ দিয়েও required capacity ও correct routing আছে কি না পরীক্ষা করুন। Isolation boundary operational access-এর সঙ্গেও মিলতে হবে।
মনে রাখুন
আলাদা instance মানেই আলাদা ভাগ্য নয়; common dependency ও shared change-এর blast radius খুঁজে সীমিত করুন।
নিজে চেষ্টা করুন
নিজের architecture-এর dependency graph আঁকুন। যেকোনো একটি box সরিয়ে কোন user journey থামে লিখুন। একটি shared cache failure এবং একটি bad release-এর প্রভাব আলাদা করে কমানোর পরিকল্পনা দিন।
নিজের বোঝা যাচাই করুন
1. Failure domain শুধু region?
না। Process থেকে account বা deployment পর্যন্ত correlated failure-এর boundary হতে পারে। Context অনুযায়ী domain নির্ধারণ করুন।
2. Cells কি sharding?
কিছু data partitioning থাকতে পারে, কিন্তু cell লক্ষ্য workload/dependency isolation। Data placement ও routing আলাদা design লাগে।
3. দুটি cache cluster যথেষ্ট?
যদি একই credential, network বা bad config দুটিই নষ্ট করে, common risk থাকে। Independence যাচাই দরকার।
4. Blast radius কীভাবে মাপব?
কত tenant, request বা revenue path প্রভাবিত হয় নির্ধারণ করুন। শুধু component count user impact বোঝায় না।
5. Isolation-এর দাম কী?
Extra capacity, operational duplication ও cross-boundary coordination লাগে। Business risk দিয়ে trade-off বিচার করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।