শেয়ার করা Storage আর দ্রুত Launch

এই লেসন শেষে তুমি পারবে

• বোঝাতে, কেন WordPress-এর মতো একটা app-এর state শুধু database আর session-এ না, তার file-এও (upload করা ছবি) থাকে, আর server বাড়ালেই কেন সেটা ভেঙে পড়ে।
• বলতে, কেন একটা EBS volume পুরো web fleet-এর shared uploads folder হতে পারে না (এক AZ, এক instance, Multi-Attach কোনো shared file system না), আর প্রতিটা AZ-এ mount target রেখে EFS কীভাবে সমস্যাটা মেটায়।
• User-এর upload রাখার জন্য EBS, EFS আর S3 (CloudFront সহ)-এর মধ্যে খরচ হিসাব করে বেছে নিতে।
• Database-কে RDS Multi-AZ থেকে reader সহ Aurora MySQL-এ নিয়ে যেতে, আর প্রতিটা ধাপে কী লাভ হয় সেটা বলতে।
• নতুন instance কাজের উপযুক্ত হতে যে সময় নেয় সেটা কমাতে: golden AMI, user data, দুটোর hybrid, warm pool, আর RDS ও EBS snapshot থেকে restore করা data, প্রথম read-এর ধীরগতি ছাড়াই।
• চিরচেনা 3-tier web architecture আঁকতে, আর তার প্রতিটা tier দিয়ে একটা request, একটা write আর একটা AZ failure কীভাবে যায় সেটা দেখাতে।

#যে blog শুধু row না, file-ও রাখে

#তিন রকমের state

লেসন ৯.১-এ আমরা একটা stateless app বড় করেছিলাম: যেকোনো server যেকোনো request-এর উত্তর দিতে পারত। লেসন ৯.২-এর দোকানের state ছিল একটা session (shopping cart) আর database-এর row, আর দুটোকেই web server থেকে সরিয়ে ElastiCache আর RDS-এ নিয়েছিলাম। এই লেসনের app-এ আছে তৃতীয় এক রকম state: file।

ধরো WordPress দিয়ে বানানো একটা blogging platform। WordPress হলো web-এর সবচেয়ে প্রচলিত content management system (CMS)। আমাদের platform-এর নাম দিলাম Kolom.example (হ্যাঁ, আমাদের “কলম”)। এর যা যা লাগবে:

• কয়েকটা Availability Zone জুড়ে, load balancer-এর পেছনে ইচ্ছামতো scale out আর scale in করতে পারা;
• post, comment আর user একটা MySQL database-এ রাখা;
• লেখকেরা ছবি upload করবে, আর প্রত্যেক পাঠক সেটা ঠিকঠাক দেখবে।

প্রথম দুটো WordPress রাখে MySQL-এ, কিন্তু upload করা ছবি (আর install করা theme ও plugin) হলো server-এর disk-এর একটা folder-এ রাখা সাধারণ file, wp-content/uploads। ওই folder-ও একটা state। দুই server-এ দুই রকম folder মানে দুই রকম website।

গল্পটা দুই ভাগে বলব। প্রথম ভাগে architecture: আগে database tier, তারপর file-এর সমস্যা আর তার সমাধান। দ্বিতীয় ভাগে একটা toolbox, এমন এক প্রশ্নের জন্য যেটার মুখোমুখি প্রতিটা scaling design-কেই হতে হয়: একটা নতুন instance আসলে কত তাড়াতাড়ি traffic সামলাতে পারে?

#Database tier: RDS Multi-AZ থেকে Aurora

Kolom-এর প্রথম version চলে Multi-AZ সহ RDS for MySQL-এ: এক AZ-এ primary, আরেক AZ-এ একটা synchronous standby (লেসন ৭.১)। এতে high availability পাওয়া যায়: primary নষ্ট হলে RDS মোটামুটি এক থেকে দুই মিনিটে standby-তে failover করে, endpoint-ও সাথে সাথে সরে যায়।

কিন্তু এতে read scaling হয় না। Blog যতবার লেখা হয় তার চেয়ে অনেক বেশিবার পড়া হয়, হয়তো প্রতি comment-এ একশোটা page view। Multi-AZ standby (সাধারণ এক-standby-র deployment) কোনো traffic-ই সামলায় না, তাই সব read গিয়ে পড়ে primary-র ঘাড়ে। কোনো post ভাইরাল হলে primary-র CPU চড়তে থাকে, প্রতিটা page ধীর হয়ে যায়, আর standby বসে বসে দেখে।

পরের ধাপ Amazon Aurora MySQL (লেসন ৭.৩):

• এটা MySQL-compatible, তাই WordPress কোনো code না বদলেই এতে connect করে।
• সর্বোচ্চ ১৫টা Aurora Replica (reader) মিলে একটাই storage volume শেয়ার করে, যেটা তিন AZ জুড়ে ছয়টা কপি রাখে। Replica lag সাধারণত কয়েক millisecond, কারণ reader-রা data-র আলাদা কপি replay করে না; একই storage পড়ে।
• Cluster endpoint সবসময় writer-কে দেখায়; reader endpoint connection-গুলো reader-দের মধ্যে ভাগ করে দেয়। Reader-দের CPU বাড়লে replica auto scaling নিজেই reader যোগ করতে পারে।
• Writer নষ্ট হলে Aurora একটা reader-কে promote করে, সাধারণত ৩০ সেকেন্ডের কম সময়ে, আর cluster endpoint সরিয়ে নেয়।

তাই “সবচেয়ে কম ঝামেলায় Multi-AZ আর read replica” হলো Aurora-র জোরের জায়গা। সাধারণ RDS-ও এটা পারে, প্রত্যেকটার আলাদা endpoint সহ read replica দিয়ে, বা দুটো readable standby সহ Multi-AZ DB cluster দিয়ে; Aurora পুরো ব্যাপারটা সবচেয়ে গুছিয়ে দেয়। সামনে একটা cache (ElastiCache, লেসন ৭.৫) বসালে read আরও কমে; শেষের 3-tier ছবিতে সেটা দেখবে।

#ধাপ ১: এক server, upload তার EBS volume-এ

Web server একটা হলে upload রাখার সবচেয়ে সহজ জায়গা server-এর নিজের disk: একটা EBS volume। লেখক ছবি upload করে, server সেটা wp-content/uploads-এ লিখে রাখে, পরে প্রত্যেক পাঠকের request একই server-এ আসে, আর সে একই disk পড়ে। কাজ করে, খরচ কম, আর single-instance application-এর জন্য এটাই ঠিক উত্তর।

EBS কী, মনে করো (লেসন ৫.১): একটা network disk, যেটা থাকে একটা Availability Zone-এ, আর লাগানো থাকে একটা instance-এ। Instance একটা থাকা পর্যন্ত এই দুটো কথার কোনো গুরুত্ব নেই। দুটো হওয়ামাত্র পুরো সমস্যাটাই এই দুটো কথা।

#ধাপ ২: দুই server, আর ছবি উধাও

Kolom জনপ্রিয় হলো, আর এখন একটা Auto Scaling group দুই AZ-এ Application Load Balancer-এর পেছনে instance চালায়। প্রতিটা instance একই AMI থেকে launch হয়েছে, আর প্রত্যেকে পেয়েছে তার নিজের EBS volume।

1. একজন লেখক sunset.jpg upload করল। Load balancer সেই request পাঠাল web-a-তে, সে file-টা সেভ করল AZ a-তে তার নিজের volume-এ।
2. একজন পাঠক post-টা খুলল। Load balancer এই request পাঠাল web-b-তে, সে খুঁজল তার নিজের uploads folder-এ।
3. File সেখানে নেই। পাঠক দেখল ভাঙা ছবি। কার request কোন server-এ পড়ল তার ওপর নির্ভর করে অর্ধেক পাঠক ছবি দেখে, অর্ধেক দেখে না।

#Volume-টা ভাগ করে নিলেই হয় না কেন

• এক AZ। EBS volume শুধু নিজের Availability Zone-এর instance-এ লাগানো যায়। AZ b-র web-b, AZ a-র volume লাগাতেই পারে না।
• এক instance। সাধারণ volume একসাথে একটা instance-এই লাগে।
• Multi-Attach কোনো shared folder না। EBS Multi-Attach দিয়ে একটা io1 বা io2 (Provisioned IOPS) volume একই AZ-এর সর্বোচ্চ ১৬টা Nitro instance-এ লাগানো যায়। কিন্তু ext4 বা XFS-এর মতো সাধারণ file system একসাথে কয়েকটা server লিখবে, এমনভাবে বানানোই হয়নি; Multi-Attach-এর জন্য লাগে cluster-aware file system, অথবা এমন application যে নিজেই write-গুলো সমন্বয় করে। এটা AZ পার হতে পারে না, boot volume-ও হতে পারে না। এটা clustered database-এর মতো software-এর জন্য, WordPress fleet-এর জন্য না।

#যে বুদ্ধিগুলো দেখতে সমাধান, আসলে না

• Sticky session (লেসন ৬.৪) একজন user-কে একটা server-এ আটকে রাখে। এখানে যে upload করল আর যারা পড়ছে তারা আলাদা মানুষ, তাই তারা আলাদা server-এই যায়। আর scale-in-এ web-a terminate হলে তার volume, ছবিগুলো সহ, তার সাথেই মুছে যেতে পারে।
• Server থেকে server-এ file কপি করা, cron job বা sync tool দিয়ে: সবসময় একটু পিছিয়ে থাকে, চুপচাপ ভেঙে যায়, আর প্রতিটা নতুন instance খালি হাতে শুরু করে।
• এক EC2 instance-এ নিজের NFS server: এখন ওই instance, তার disk আর তার AZ-ই single point of failure, আর patch ও scale সব তোমাকেই করতে হবে।

Fleet-এর আসলে দরকার একটা file system, যেটা প্রতিটা AZ-এর প্রতিটা instance একসাথে mount করতে পারবে।

#ধাপ ৩: EFS, সব AZ-এর জন্য একটাই file system

Amazon EFS (লেসন ৫.৪) হলো একটা managed NFS file system। wp-content/uploads (বা পুরো wp-content folder) এতে সরিয়ে দাও, তাহলে প্রতিটা server একই file দেখবে:

• Regional। Regional file system তার data অন্তত তিনটা AZ-এ একাধিক কপিতে রাখে, আর Region-এর যেকোনো AZ-এর instance একসাথে এটা mount করতে পারে।
• Mount target। File system তোমার VPC-তে পৌঁছায় প্রতি AZ-এ একটা mount target দিয়ে: ওই AZ-এর একটা subnet-এ private IP সহ একটা ENI। প্রতিটা instance file system-এর DNS নাম mount করে, যেটা resolve হয় তার নিজের AZ-এর mount target-এ, তাই traffic AZ-এর ভেতরেই থাকে, AZ পার হওয়ার খরচও লাগে না।
• Mount target-এ security group। প্রতিটা mount target-এর একটা security group থাকে, যেটাকে web server-দের security group থেকে inbound TCP 2049 (NFS) ঢুকতে দিতে হবে। Rule না থাকলে পরিষ্কার কোনো error আসে না: mount আটকে থাকে, তারপর timeout হয়।
• যত GB ব্যবহার, তত খরচ। কোনো size ঠিক করে দিতে হয় না; file-এর সাথে বাড়ে-কমে। us-east-1-এ EFS Standard-এর দাম মোটামুটি প্রতি GB-month $০.৩০, gp3-এর $০.০৮-এর প্রায় চার গুণ; কিন্তু খরচ দাও শুধু যা জমা আছে তার জন্য, একবারই, প্রতিটা instance-এর জন্য পুরো size-এর আলাদা volume-এর বদলে। Lifecycle management পুরনো, কেউ পড়ে না এমন file-কে Infrequent Access বা Archive-এ সরিয়ে আরও অনেক সস্তা করে দেয়।
• শুধু Linux, POSIX permission, হাজার হাজার client। Windows fleet হলে উত্তর FSx for Windows File Server।

নতুন instance boot-এর সময় EFS mount করে, user data বা /etc/fstab-এর একটা লাইন দিয়ে, আর সাথে সাথে সব file দেখে। Scale out, scale in, এমনকি একটা AZ হারালেও একটা ছবিও হারায় না।

#Upload করা file-এর জন্য EBS, EFS না S3?

এই architecture-এ slide আর exam দুজনেরই উত্তর EFS, কারণ এতে application-এ কোনো বদল লাগে না: WordPress আগের মতোই একটা folder-এ লেখে। আধুনিক design প্রায়ই আরও এক ধাপ এগিয়ে upload রাখে Amazon S3-এ, আর দেখায় Amazon CloudFront দিয়ে, যেটা AWS-এর content delivery network। S3 আর CloudFront-এর আলাদা অধ্যায় এই course-এ পরে আসছে; এখন যতটুকু তুলনা দরকার:

একটা হিসাব করে দেখি: Kolom-এর ১২০ GB ছবি, চারটা instance চলে।

• EBS: প্রতিটা instance-এর নিজের কপি লাগবে, ধরো ২০০ GB-র gp3 volume-এ: ৪ × ২০০ × $০.০৮ = মাসে $৬৪, আর কপিগুলো তবুও shared না।
• EFS Standard: ১২০ × $০.৩০ = মাসে $৩৬, একটাই shared কপি। Lifecycle management পুরনো ছবি IA-তে সরালে আরও অনেক কম।
• S3 Standard: ১২০ × $০.০২৩ ≈ storage-এর জন্য মাসে $২.৭৬, সাথে request আর data transfer; CloudFront থাকলে web server-কে আর ছবি serve করতেই হয় না।

#WordPress-এর পুরো যাত্রা এক নজরে

Slide-এর মূল কথাটা এক লাইনে: এক instance-এর data-র জন্য EBS, distributed application যে data ভাগ করে তার জন্য EFS, সহজ Multi-AZ আর read replica-র জন্য Aurora।

#দ্রুত launch: মিনিটগুলো যায় কোথায়

লেসনের দ্বিতীয় ভাগটা একটা toolbox। এই অধ্যায়ের প্রতিটা design নির্ভর করে load বাড়লে Auto Scaling instance যোগ করবে, তার ওপর (লেসন ৬.৫)। Spike-এর সময় যোগ হওয়া instance কাজে লাগে কেবল যখন সে traffic serve করতে শুরু করে, আর তার আগের পুরো সময়টা জুড়ে user পায় ধীর page বা error। পুরো একটা stack (EC2, EBS, RDS) launch করতে অনেক সময় লাগতে পারে, চার রকম কাজের জন্য:

1. Install করা: operating system-এর package, runtime, application আর agent।
2. Data ঢোকানো: শুরুর data, বা recovery-র জন্য যে data লাগবে।
3. Configure করা: এই environment-এর জন্য সবকিছু, যেমন endpoint, file system, feature flag, secret।
4. চালু করা: application চালু করে health check পার হওয়া।

Cloud-এ এর বেশিরভাগ কাজ একবার, আগেভাগে করে ফলাফলটা বারবার ব্যবহার করা যায়। EC2-র বেলায় এর মানে একটা golden AMI আর একটা ছোট user data script; data-র বেলায় মানে snapshot থেকে restore।

#Golden AMI: ধীর কাজটা একবারই সেরে রাখো

Golden AMI হলো তোমার নিজের image, যেটাতে ধীর আর সব জায়গায় একই এমন সবকিছু আগে থেকেই install করা: OS patch, web server, PHP, application-এর code, plugin, monitoring আর security agent (লেসন ৪.৩)। এ থেকে launch হওয়া instance install-এর ধাপটা পুরোপুরি এড়িয়ে যায়।

এর দাম হলো একটা প্রক্রিয়া। Golden AMI একটা মুহূর্তের ছবি, সময়ের সাথে পুরনো হয়: security patch বা application-এর নতুন version এলে AMI আবার build করো, test করো, launch template-কে নতুন version-এর দিকে ঘোরাও, আর instance-গুলো বদলে দাও (instance refresh)। চালু server-এ হাতে হাতে patch দিয়ো না। EC2 Image Builder এই pipeline-টা automate করে: একটা recipe (base image আর build ও test component), একটা schedule বা base image বদলালে trigger, আর অন্য Region ও account-এ বিতরণ। মনে রেখো, একটা AMI থাকে একটা Region-এ; যত Region-এ launch করবে, প্রতিটাতে কপি করতে হবে।

#User data: শুধু যা প্রতি launch-এ আলাদা

User data হলো সেই script, যেটা cloud-init প্রথম boot-এ একবার root হিসেবে চালায় (লেসন ৪.৩)। এটা dynamic configuration-এর ঠিক জায়গা, মানে এমন জিনিস যা একটা AMI আগে থেকে জানতে পারে না:

• এটা কোন environment (dev, staging না production), আর তাই কোন database endpoint, কোন EFS file system, কোন cache;
• instance-এর IAM role দিয়ে Systems Manager Parameter Store থেকে setting আর Secrets Manager থেকে secret আনা, password কখনোই user data-তে লিখে না রেখে;
• EFS mount করা, monitoring-এ নাম লেখানো, কোনো cluster-এ যোগ দেওয়া।

ভারী কাজের জন্য user data খারাপ জায়গা। যে script dnf update চালিয়ে পুরো একটা stack install করে, সে প্রতিটা instance-কে serve করার আগে কয়েক মিনিট বসিয়ে রাখে, প্রতিবার launch-এ internet-এর ওপর নির্ভর করে, আর মাঝপথে fail করলেও instance EC2 status check দিব্যি পার হয়ে যায়। ছোট রাখো; তাছাড়া raw size-এর সীমাই ১৬ KB।

#Hybrid: golden AMI আর ছোট একটা user data script

সাধারণ উত্তর হলো দুটোই:

• ধীর, বদলায় না এমন অংশ golden AMI-তে bake করো;
• environment ভেদে আলাদা অংশ একটা ছোট user data script দিয়ে bootstrap করো।

তখন একটাই AMI সব environment-এ চলে, আর প্রতিটা instance মোটামুটি boot হতে যতক্ষণ লাগে ততক্ষণেই তৈরি। AWS Elastic Beanstalk ঠিক এভাবেই কাজ করে: তার platform-গুলো হলো runtime আগে থেকে install করা AMI, আর launch-এর সময় সে তোমার application version আর configuration যোগ করে (Beanstalk দেখবে লেসন ৯.৪-এ)।

#পাশের কথা: warm pool

Golden AMI-ও যখন যথেষ্ট দ্রুত না (ধরো এমন application যেটা চালু হতেই কয়েক GB memory-তে বা disk-এ load করে), তখন Auto Scaling group একটা warm pool রাখতে পারে: আগেভাগে launch আর initialise করা instance, তারপর রেখে দেওয়া Stopped অবস্থায় (সবচেয়ে সস্তা: খরচ শুধু তাদের EBS volume আর Elastic IP), Hibernated অবস্থায় (memory সেভ থাকে EBS root volume-এ), বা Running অবস্থায় (দামি, কদাচিৎ পোষায়)। Scale-out হলে group নতুন launch না করে pool-এর একটা instance চালু করে।

• Default-এ pool-এর size হয় maximum capacity − desired capacity; চাইলে নিজের maximum prepared capacity আর pool-এর minimum size দিতে পারো।
• একটা lifecycle hook রাখো, যাতে প্রথমবারের initialisation শেষ হওয়ার আগেই instance stop হয়ে না যায়।
• Stopped instance চালু করা প্রথম boot না, তাই user data আবার চলে না, যদি না প্রতি boot-এ চালানোর ব্যবস্থা করো।
• সীমা: warm pool থাকলে mixed instances group-এ Spot Instance বা instance weighting চলে না; root device হতে হবে EBS।

Exam-এ “instance তৈরি হতে অনেক সময় নিচ্ছে”-র প্রথম উত্তর golden AMI; warm pool তখনই উত্তর, যখন প্রশ্নে জোর দেওয়া থাকে এমন অস্বাভাবিক লম্বা initialisation-এর ওপর, যেটা bake করে সরানো যায় না।

#Launch-এর কৌশলগুলো নিজে চালিয়ে দেখো

Traffic সেকেন্ডে ১৫০ থেকে লাফিয়ে ৫৪০ request হয়; দুটো instance পারে ২০০। ২:০০-তে group আরও চারটা launch করে। Instance কীভাবে বানানো সেটা বদলাও, একটা warm pool যোগ করো, snapshot থেকে একটা data volume restore করো, বা package repository বন্ধ করে দাও, আর দেখো নতুন capacity আসার আগে কতগুলো request fail করে:

এই model-এর সময় ধরে (বোঝানোর জন্য, মাপা না), নতুন চারটা instance launch-এর এতক্ষণ পরে পুরো গতিতে পৌঁছায়:

প্রথম দুই সারির পার্থক্যটা নিছক পাটিগণিত: বাড়তি ৮ মিনিট × সেকেন্ডে ৩৪০টা ঘাটতির request = আরও ১,৬৩,২০০টা fail, পুরোটাই কারণ install হচ্ছে launch-এর সময়, আগে না।

#তৈরি data: snapshot থেকে restore

Data-র বেলাতেও একই চিন্তা খাটে। একটা database বা disk বানিয়ে তারপর তাতে data ঢোকানোর বদলে শুরু করো এমন একটা snapshot থেকে, যেটাতে data আগেই আছে।

#RDS: snapshot থেকে database restore

একটা RDS snapshot restore করলে এমন database পাও, যার schema আর data আগে থেকেই জায়গামতো: MySQL install করতে হয় না, dump import করতে হয় না, যেটা বড় database-এ ঘণ্টার পর ঘণ্টা নিতে পারে। আসল data সহ staging কপি বানাতে, ভুলের পর recover করতে, বা নতুন environment শুরু করতে এটা কাজে লাগে। লেসন ৭.২ থেকে মনে রাখো:

• Restore সবসময় বানায় নতুন endpoint সহ একটা নতুন DB instance। Application-কে সেদিকে নাও তোমার নিজের একটা Route 53 CNAME দিয়ে (যেমন db.staging.example.com) বা Parameter Store-এর একটা value দিয়ে, তাহলে কোনো server-এ হাত দিতে হয় না।
• অন্য কিছু না বললে restore করা instance পায় default parameter আর option group; security group-টাও দেখে নিয়ো।
• এর storage S3 থেকে lazy loading হয়, তাই data একবার পড়া না হওয়া পর্যন্ত প্রথম দিকের query ধীর। মাপজোখের আগে গরম করে নাও।

#EBS: snapshot থেকে volume restore

EBS snapshot থেকে বানানো volume আগে থেকেই format করা আর data-তে ভরা: attach করো, mount করো, ব্যবহার করো। (প্রতিটা AMI তার root volume-এর জন্য ঠিক এটাই করে।) কিন্তু এটাও lazy loading: volume কয়েক সেকেন্ডেই available, আর প্রতিটা block প্রথমবার পড়ার সময় S3 থেকে আনা হয়, তাই প্রথম read ধীর (লেসন ৫.১)। যে server-কে শুরু থেকেই দ্রুত হতে হবে, তার জন্য:

৬০ GiB data-র একটা snapshot ৩০০ MiB/s provisioned rate-এ পুরো initialise হয় মোটামুটি ৬১,৪৪০ ÷ ৩০০ ≈ ২০৫ সেকেন্ডে, চার মিনিটের কম। FSR আরও দ্রুত, কিন্তু চালু রাখা প্রতিটা ঘণ্টার জন্য, প্রতিটা AZ-এ, ব্যবহার হোক বা না হোক, বিল হয়, আর volume creation credit দিয়ে সীমিত (লেসন ৫.১)। FSR চালু থাকা snapshot-এ provisioned rate দিলে rate-টাই খাটে।

#চিরচেনা 3-tier web application

এই অধ্যায়ের টুকরোগুলো জুড়ে দিলে পাও সেই architecture, যেটা exam-এ বারবার ফিরে আসে:

• প্রতিটা tier থাকে অন্তত দুটো AZ-এ, যাতে একটা AZ নষ্ট হলেও site বন্ধ না হয়।
• Security group শিকলের মতো tier থেকে tier-এ জোড়া: ALB internet থেকে 443 নেয়, web server traffic নেয় শুধু ALB-র security group থেকে, cache আর database শুধু web server-দের group থেকে (লেসন ৯.২)।
• Application tier stateless: session ElastiCache-এ, row Aurora-তে, file EFS-এ। এ কারণেই নির্ভয়ে instance যোগ-বিয়োগ করা যায়, আর golden AMI-র কারণে যোগ করাটা দ্রুত।

#কোথায় গোলমাল হয়

• Fleet-এ upload রাখা instance-এর disk-এ। কোন server-এ পড়ল তার ওপর ছবি আসে-যায়; scale-in সেগুলো মুছে দেয়। EFS-এ (বা S3-তে) সরাও।
• এক AZ-এ EFS mount fail। ওই AZ-এ mount target নেই, বা তার security group-এ web server থেকে inbound TCP 2049 নেই; বা কোনো NACL 2049 কিংবা ফিরতি port আটকে রেখেছে। লক্ষণ হলো timeout, কোনো error message না।
• Mount ছাড়াই app চালু। Web server mount point-এর নিচের খালি local folder-এ লিখতে থাকে, আর ওই একটা server-এ পুরনো bug ফিরে আসে। /etc/fstab-এ _netdev দিয়ে boot-এর সময় mount করো, আর mount না থাকলে health check যেন fail করে।
• Read-এর চাপে database হাঁসফাঁস, আর Multi-AZ standby বসে আছে। Reader (Aurora) আর একটা cache যোগ করো।
• পুরনো golden AMI। নতুন instance জন্ম নেয় সর্বশেষ patch ছাড়া। Image Builder দিয়ে schedule ধরে আবার build করো, instance refresh দিয়ে ছড়িয়ে দাও।
• Boot-এ বড় user data। ধীর scale-out, version সরে যাওয়া, আর repository না পেলেই launch fail, অথচ EC2 status check দেখায় সব ঠিক।
• User data-তে secret। Instance থেকে আর API দিয়ে পড়া যায়। Instance role দিয়ে Secrets Manager বা Parameter Store ব্যবহার করো।
• Restore করা data ধীর। Restore করা EBS volume আর RDS storage-এ lazy loading। FSR, provisioned initialisation rate, বা আগে গরম করে নাও।
• Database restore হলো, endpoint রয়ে গেল পুরনো। Application তখনো পুরনো instance-এর দিকে তাকিয়ে। Hard-code করা endpoint না, CNAME বা parameter ব্যবহার করো।

#System design-এ shared storage আর দ্রুত launch

• Web tier-কে ফেলে দেওয়ার যোগ্য বানাও। যেকোনো instance মেরে ফেললেও যদি কিছু না হারায় (session, row আর file সব অন্য জায়গায়), তাহলে Auto Scaling, Spot Instance, AZ failure আর deployment সবই নিত্যদিনের ব্যাপার হয়ে যায়।
• কে ভাগ করবে, সেটা দেখে storage বাছো: এক instance-এর জন্য EBS, file system লাগে এমন fleet-এর জন্য EFS, অনেকে মিলে পড়বে বিশেষ করে অনেক জায়গা থেকে, এমন object-এর জন্য S3।
• আগে bake, তারপর bootstrap। Pipeline থেকে golden AMI, environment-এর setting-এর জন্য user data, configuration Parameter Store-এ, secret Secrets Manager-এ।
• “কাজের উপযুক্ত হতে” কত সময় লাগে সেটা মাপো, “running” হতে না: boot, user data, app চালু, health check, cache আর disk গরম হওয়া। এই সংখ্যাটাই ঠিক করে কতটা বাড়তি capacity রাখতে হবে, আর scaling কতটা আগ্রাসী হতে হবে।
• Data-র বেলায় নতুন করে না বানিয়ে restore করো: staging কপি আর recovery-র জন্য snapshot, আর প্রথম মিনিট থেকেই performance লাগলে FSR বা initialisation।

#নিজে করে দেখো

Command-গুলোতে বানানো ID ব্যবহার করা হয়েছে; নিজেরগুলো বসিয়ে নিয়ো।

# 1. EFS for the uploads folder: a file system and one mount target per AZ
aws efs create-file-system --performance-mode generalPurpose --throughput-mode elastic \
  --encrypted --tags Key=Name,Value=kolom-uploads
aws efs create-mount-target --file-system-id fs-0abc1234 \
  --subnet-id subnet-0aaa1111 --security-groups sg-0efs0001       # AZ a
aws efs create-mount-target --file-system-id fs-0abc1234 \
  --subnet-id subnet-0bbb2222 --security-groups sg-0efs0001       # AZ b

# The mount targets' security group: NFS only from the web servers' security group
aws ec2 authorize-security-group-ingress --group-id sg-0efs0001 \
  --protocol tcp --port 2049 --source-group sg-0web0001

# 2. Small user data for the hybrid approach (the AMI already has httpd, PHP and the app)
cat > user-data.sh <<'EOF'
#!/bin/bash
set -euo pipefail
ENV=prod
DB=$(aws ssm get-parameter --name /$ENV/blog/db-endpoint --query Parameter.Value --output text)
FS=$(aws ssm get-parameter --name /$ENV/blog/efs-id --query Parameter.Value --output text)
echo "$FS:/ /var/www/html/wp-content/uploads efs _netdev,tls 0 0" >> /etc/fstab
mount -a
sed -i "s/DB_HOST_PLACEHOLDER/$DB/" /var/www/html/wp-config.php
systemctl enable --now httpd
EOF

# 3. Bake: create an AMI from a configured instance, or run an Image Builder pipeline
aws ec2 create-image --instance-id i-0123456789abcdef0 --name blog-v12
aws imagebuilder start-image-pipeline-execution \
  --image-pipeline-arn arn:aws:imagebuilder:us-east-1:111122223333:image-pipeline/blog

# 4. A warm pool of stopped instances for the Auto Scaling group
aws autoscaling put-warm-pool --auto-scaling-group-name blog-asg \
  --pool-state Stopped --min-size 2

# 5. Data that is ready: a database and a volume from snapshots
aws rds restore-db-instance-from-db-snapshot --db-instance-identifier blog-staging \
  --db-snapshot-identifier blog-prod-2026-10-24 --db-subnet-group-name blog-data
aws ec2 create-volume --snapshot-id snap-0123456789abcdef0 \
  --availability-zone us-east-1a --volume-type gp3 --volume-initialization-rate 300
aws ec2 enable-fast-snapshot-restores --availability-zones us-east-1a \
  --source-snapshot-ids snap-0123456789abcdef0

চালু একটা instance-এ mount আর boot log দেখে নাও:

df -h /var/www/html/wp-content/uploads     # should show the EFS file system, not the root disk
sudo tail -n 50 /var/log/cloud-init-output.log

#সারসংক্ষেপ

মূল কথাগুলো

• WordPress-এর মতো app-এর state তিন রকম: session, row আর file (upload)। Web tier ইচ্ছামতো scale করার আগে তিনটাকেই web server থেকে সরাতে হবে।
• Database: RDS Multi-AZ availability দেয়, কিন্তু তার standby কোনো read সামলায় না; Aurora MySQL ছয় কপির shared storage-এর ওপর সর্বোচ্চ ১৫টা reader, একটা reader endpoint আর ৩০ সেকেন্ডের কম সময়ের failover যোগ করে।
• EBS এক AZ-এ আর সাধারণত এক instance-এ: single-instance app-এর জন্য ঠিক, fleet-এর shared folder হিসেবে ভুল। Multi-Attach মানে io1/io2, একই AZ, সর্বোচ্চ ১৬টা Nitro instance, শুধু cluster-aware software।
• EFS হলো Regional NFS: প্রতি AZ-এ একটা mount target (ENI), instance থেকে TCP 2049 ঢুকতে দেওয়া security group, সব instance mount করে, যত GB ব্যবহার তত খরচ, শুধু Linux। Shared WordPress upload-এর exam উত্তর।
• বড় পরিসরে upload-এর জন্য আধুনিক design S3 + CloudFront (পরের অধ্যায়ে); EFS-এ application বদলাতে হয় না।
• দ্রুত launch: ধীর, বদলায় না এমন অংশের জন্য golden AMI (Image Builder আর instance refresh দিয়ে আবার build ও rollout); environment ভেদে config-এর জন্য user data, প্রথম boot-এ একবার; দুটোর hybrid-ই সাধারণ উত্তর, আর Beanstalk এভাবেই চলে। খুব লম্বা initialisation-এর জন্য warm pool আগে থেকে প্রস্তুত stopped instance রাখে।
• তৈরি data: snapshot থেকে RDS restore (schema আর data জায়গামতো; নতুন instance, নতুন endpoint) আর snapshot থেকে EBS restore (format করা, data সহ); দুটোই lazy loading, যার সমাধান FSR, provisioned initialisation rate, বা সব block একবার পড়ে নেওয়া।
• 3-tier web app: Route 53 → public subnet-এ ALB → private subnet-এ Auto Scaling group → data subnet-এ ElastiCache আর RDS/Aurora, storage-এর জন্য EBS/EFS, প্রতিটা tier অন্তত দুই AZ-এ, security group tier থেকে tier-এ শিকলের মতো।

নিজেকে যাচাই করো: Shared storage আর দ্রুত launch৩০টি প্রশ্ন