ہر AWS ورک لوڈ (workload) کے لیے صارفین، ڈیٹا اور خرابی کی حدود (failure boundaries) کے حوالے سے تعینِ مقام (placement) کا فیصلہ درکار ہوتا ہے۔
اس کورس میں، ہم سیکھیں گے کہ AWS کے مقامات کس طرح لیٹنسی (latency)، لچک (resilience)، تعمیل (compliance) اور ہائبرڈ کنیکٹیویٹی پر اثر انداز ہوتے ہیں۔
ہم ایک ایسا ذہنی خاکہ (mental model) تشکیل دیں گے جو سب سے بڑی حد سے شروع ہو کر چھوٹی حدود کی طرف بڑھتا ہے۔
ہم ایک چھوٹے ورک لوڈ کا سلسلہ بھی ساتھ رکھیں گے تاکہ تعینِ مقام کے حوالے سے کیے جانے والے سمجھوتوں (tradeoffs) کو عملی اور واضح طور پر سمجھا جا سکے۔
تعینِ مقام (Placement) سے مراد یہ فیصلہ کرنا ہے کہ AWS کے مقام کی کون سی حد (boundary) کسی ورک لوڈ کے جزو یا اس کے ڈیٹا کی میزبانی کرے گی۔
یہ فیصلہ نیٹ ورک کے فاصلے، دائرہ اختیار (jurisdiction) اور خرابیوں کے اثرات کے دائرہ کار (blast radius) کو تبدیل کرتا ہے۔
لیٹنسی کا انحصار صارفین اور ورک لوڈ کے درمیان طبعی فاصلے اور نیٹ ورک ہاپس (network hops) پر ہوتا ہے۔
فالٹ آئسولیشن (fault isolation) کا انحصار اس بات پر ہے کہ کون سے اجزاء ایک ہی طبعی اور آپریشنل حد میں موجود ہیں۔
ڈیٹا کی رہائش یا مقام سے متعلق حدود (residency constraints) اس بات کو محدود کرتی ہیں کہ ڈیٹا کہاں ذخیرہ اور پروسیس کیا جائے گا، جس سے ‘ریجن’ (Region) کے انتخاب کا دائرہ کار محدود ہو سکتا ہے۔
ہائبرڈ حدود کے تحت مقامی سطح پر (یعنی اپنے احاطے کے قریب) پروسیسنگ یا AWS کے ساتھ قابلِ پیش گوئی کنیکٹیویٹی کی ضرورت پڑ سکتی ہے۔
آئیے ان اہم مقامی تہوں (location layers) کا جائزہ لیں جنہیں ہم اس پورے کورس کے دوران استعمال کریں گے۔
AWS اکاؤنٹ ایک سیکیورٹی اور بلنگ کی حد (boundary) ہے جو وسائل (resources) اور شناختوں (identities) کی ملکیت رکھتی ہے۔
اکاؤنٹ کی حدود اس لیے اہم ہیں کیونکہ رسائی کے کنٹرولز اور آڈٹ کے شواہد کا جائزہ فی اکاؤنٹ لیا جاتا ہے۔
AWS ریجن ایک الگ جغرافیائی علاقہ ہے جہاں AWS اپنے انفراسٹرکچر کو یکجا (cluster) کرتا ہے۔
ریجنز کو اس طرح ڈیزائن کیا گیا ہے کہ وہ ‘فالٹ ٹالرنس’ (نقص یا خرابی کی صورت میں نظام کی فعالیت برقرار رکھنے کی صلاحیت) کے لیے دیگر ریجنز سے الگ تھلگ رہیں۔
زیادہ تر AWS سروسز ریجنل وسائل (Regional resources) تخلیق کرتی ہیں جو صرف منتخب کردہ ریجن میں ہی موجود ہوتے ہیں۔
مختلف ریجنز کے درمیان ڈیٹا کی نقل (replication) سروس کے لحاظ سے مخصوص ہوتی ہے، اور AWS ہر چیز کو خود بخود نقل نہیں کرتا۔
اویلیبلٹی زون (Availability Zone) ایک ریجن کے اندر واقع ایک الگ تھلگ مقام ہے۔
ہر اویلیبلٹی زون الگ عمارتوں یا تنصیبات میں موجود ایک یا زیادہ علیحدہ ڈیٹا سینٹرز پر مشتمل ہوتا ہے۔
ایک ریجن میں موجود اویلیبلٹی زونز کم لیٹنسی (low-latency)، ہائی بینڈ وڈتھ اور ریڈنڈنٹ (متبادل/اضافی) نیٹ ورکنگ کے ذریعے آپس میں جڑے ہوتے ہیں۔
بہترین طریقہ کار یہ ہے کہ زیادہ دستیابی (availability) کو یقینی بنانے کے لیے پروڈکشن ورک لوڈز کو متعدد اویلیبلٹی زونز میں چلایا جائے۔
اینڈ پوائنٹ (endpoint) نیٹ ورک کا وہ داخلی مقام ہے جہاں ہم کسی مخصوص دائرہ کار (scope) میں موجود سروس کے لیے API کی درخواستیں بھیجتے ہیں۔
ٹولز میں کسی ریجن کا انتخاب اکثر اس سروس کی API کے لیے ریجنل اینڈ پوائنٹ کا انتخاب کر لیتا ہے۔
کنٹرول پلین (control plane) کسی سروس کا وہ حصہ ہے جو وسائل (resources) کو تخلیق اور کنفیگر کرتا ہے۔ ڈیٹا پلین (Data plane) سروس کا وہ حصہ ہے جو رن ٹائم ٹریفک اور ڈیٹا آپریشنز کو سنبھالتا ہے۔ ان پلینز (planes) میں خرابی کے مختلف انداز (failure modes) ہو سکتے ہیں، لہذا ہمیں مناسب شواہد کے ساتھ ہر ایک کی تصدیق کرنی چاہیے۔
کام کا مفروضہ جب تک بصورت دیگر وضاحت نہ کی جائے، ہم ‘ریجن’ (Region) اور ‘اویلیبلٹی زون’ (Availability Zone) کو فالٹ آئسولیشن (خرابی کو محدود کرنے) کی بنیادی حدود کے طور پر لیں گے۔
فیصلوں کی بنیاد رکھنے کے لیے ہم ایک سادہ عالمی ویب ایپ کا استعمال کریں گے۔ اس ایپ میں صارفین کے پروفائلز موجود ہیں جنہیں انفراسٹرکچر کی خرابی کے دوران بھی دستیاب رہنا چاہیے۔ یہ ایپ میڈیا بھی فراہم کرتی ہے جسے صارفین (end users) کے قریب ہونے سے فائدہ پہنچتا ہے۔
یہ سلسلہ ہمیں ہر حد (boundary) کو سمجھتے ہوئے ایک ہی مستقل سوال پوچھنے کے قابل بنائے گا۔ لیٹنسی (latency) اور فالٹ آئسولیشن کی ضروریات کو مدنظر رکھتے ہوئے، صارف تک رسائی فراہم کرنے والا نظام (user-facing delivery) کہاں ہونا چاہیے، اور پروفائل کا پائیدار ڈیٹا کہاں ہونا چاہیے؟ آئیے ورک لوڈ کے اجزاء کا ان لوکیشن لیئرز (مقام کی تہوں) کے تناظر میں جائزہ لیں جن کی ہم نے ابھی وضاحت کی ہے۔