S3 Performance

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

• S3-এর baseline request rate বলতে (প্রতি prefix-এ প্রতি সেকেন্ডে ৩,৫০০ PUT/COPY/POST/DELETE আর ৫,৫০০ GET/HEAD), আর একটা workload-এর জন্য কয়টা prefix লাগবে তা হিসাব করতে।
• 503 Slow Down মানে কী, নতুন request rate-এ S3 কেন ধীরে ধীরে মানিয়ে নেয়, আর backoff দিয়ে retry ও ভালো key নকশা কীভাবে সামলায়, তা ব্যাখ্যা করতে।
• কখন bottleneck S3 না হয়ে SSE-KMS, সেটা চিনতে আর সমাধানগুলো বলতে।
• Multipart upload-কে performance-এর হাতিয়ার হিসেবে ব্যবহার করতে: এর তিনটা ধাপ, সীমা (৫ MiB–৫ GiB part, ১০,০০০ part, ৫ GB single PUT), parallel part-এর গতির হিসাব, আর ফেলে রাখা upload পরিষ্কার করা।
• S3 Transfer Acceleration কীভাবে edge location দিয়ে data নেয়, কী লাগে, কত খরচ, আর কখন এতে লাভ নেই, তা বোঝাতে।
• Byte-range fetch দিয়ে download দ্রুত করতে, শুধু ব্যর্থ টুকরোটা আবার আনতে, download আবার চালু করতে, বা শুধু file-এর header পড়তে।

#S3-এর performance কেন নকশার বিষয়

S3 এমন কোনো disk না যেটা একদিন ছোট পড়ে যাবে। লেসন ৫.২-এ EBS-এর বেলায় যেমন capacity, throughput বা IOPS আগে থেকে ঠিক করতে হয়েছিল, S3-এ তেমন কিছুই করতে হয় না: সব customer মিলিয়ে service-টা নিজে থেকেই প্রতি সেকেন্ডে কোটি কোটি request সামলায়। তাহলে পরীক্ষা, আর বাস্তব কাজ, S3-এর performance নিয়ে মাথা ঘামায় কেন?

কারণ দুই রকমের সীমা এখনো আছে, আর দুটোই তুমি S3 কীভাবে ব্যবহার করছ তার ওপর নির্ভর করে:

1. Request rate। একটা bucket-এর প্রতিটা prefix প্রতি সেকেন্ডে নির্দিষ্ট সংখ্যক request সেবা দেয়। পুরো bucket যখন একদমই ব্যস্ত না, তখনো একটা “গরম” prefix throttle হতে পারে।

2. একটা transfer-এ প্রতি সেকেন্ডে কত byte। একটা HTTP request একটা TCP connection-এ data নেয়, আর লম্বা, packet হারানো internet পথে একটা connection ধীর। বড় file আর দূরের user-এর জন্য লাগে কয়েকটা connection, ভালো একটা পথ, অথবা দুটোই।

এই লেসনের প্রতিটা জিনিস এই দুই সীমার কোনো একটার হাতিয়ার। প্রত্যেকটা আলাদাভাবে সহজ; পরীক্ষা দেখে তুমি ঠিক হাতিয়ারটা বাছতে পারো কিনা।

একটা মাপকাঠি মনে রাখো: AWS-এর documentation বলে ছোট object (আর বড় object-এর প্রথম byte) সাধারণত মোটামুটি ১০০–২০০ millisecond-এ ফেরত আসে। S3 বানানো বিপুল throughput আর বিশাল scale-এর জন্য, এক অঙ্কের millisecond latency-র জন্য না; সেটা লাগলে cache বা অন্য storage class যোগ করতে হয় (নিচে “S3 আরও দ্রুত করার অন্য উপায়” দেখো)।

#Request rate: হিসাব হয় prefix ধরে

#Baseline সংখ্যাগুলো

তোমার application অন্তত এতটুকু পাবে:

• প্রতি prefix-এ প্রতি সেকেন্ডে ৩,৫০০ PUT/COPY/POST/DELETE request (লেখা), আর
• প্রতি prefix-এ প্রতি সেকেন্ডে ৫,৫০০ GET/HEAD request (পড়া)।

এই বাক্যের তিনটা শব্দ খুব জরুরি:

• “অন্তত”: এটা মেঝে, ছাদ না। Load লম্বা সময় বেশি থাকলে S3 এর ওপরেও বাড়ে; সংখ্যাগুলো হলো যতটুকুর ওপর তুমি ভরসা করতে পারো।
• “প্রতি prefix-এ”: হারটা prefix-এর, bucket বা account-এর না। যে bucket-এ prefix বেশি, সে মোট বেশি request নিতে পারে।
• “একটা bucket-এ prefix-এর সংখ্যার কোনো সীমা নেই”: তাই request ছড়ানো থাকলে মোট throughput কার্যত সীমাহীন।

#এখানে “prefix” মানে কী

লেসন ১০.১-এ দেখেছ S3-এ আসল folder বলে কিছু নেই: photos/2026/dhaka.jpg-এর মতো key একটা সমতল নাম, আর photos/2026/ হলো তার prefix, মানে শেষ / পর্যন্ত অংশটা। Slide-এ চারটা উদাহরণ আছে:

ভেতরে ভেতরে S3 key-এর নামের index-টা key range ধরে কয়েকটা partition-এ ভাগ করে রাখে, আর documentation-এর হুবহু কথাটা হলো “per partitioned prefix”। Partition তুমি বানাও না, দেখোও না; কোনো key range লম্বা সময় ব্যস্ত থাকলে S3 নিজেই সেটাকে আরও partition-এ ভাগ করে। নকশা আর পরীক্ষার জন্য নিয়মটা সোজা: প্রতিটা আলাদা prefix নিজের ৩,৫০০ write আর ৫,৫০০ read প্রতি সেকেন্ডে পায় ধরে নাও, আর ব্যস্ত key-গুলো কয়েকটা prefix-এ ছড়িয়ে দাও।

#Load ছড়ানো: হিসাবটা

হিসাব সবসময় একই: request rate-কে প্রতি prefix-এর সীমা দিয়ে ভাগ করো, তারপর ওপরের দিকে round করো। Read আর write আলাদা করে করো, তারপর বড় উত্তরটা নাও।

• Notes-এর পরীক্ষার উদাহরণ: একটা prefix-এ ১০,০০০ GET/s, ৫,৫০০-এর বেশি। দুটো prefix দেয় ২ × ৫,৫০০ = ১১,০০০, তাই কমপক্ষে দুটো (প্রত্যেকটা পায় প্রায় ৫,০০০)।
• Slide-এর উদাহরণ: চারটা prefix থেকে সমানভাবে পড়লে ৪ × ৫,৫০০ = ২২,০০০ GET/s।
• AWS-এর নিজের উদাহরণ: ১০টা prefix দেয় ১০ × ৫,৫০০ = ৫৫,০০০ GET/s।
• Write-ভারী উদাহরণ: সারা দেশের payment terminal প্রতি সেকেন্ডে ১২,০০০ log file upload করে। ১২,০০০ ÷ ৩,৫০০ = ৩.৪, তাই কমপক্ষে চারটা prefix।

Key ছড়াবে কীভাবে? Key-এর শুরুর দিকে ছোট একটা অংশ রাখো যেটা সমানভাবে ছড়ানো, আর যেটা পাঠক আবার হিসাব করে বের করতে পারে:

• ID থেকে একটা shard নম্বর: photos/<id mod 4>/<id>.jpg;
• ছোট একটা hash: logs/a3f9/2026-10-24-12-00-01.json;
• আগে থেকেই থাকা স্বাভাবিক ভাগ: প্রতি customer, প্রতি device বা প্রতি source system-এর জন্য একটা prefix।

পাঠক যা জানে (ছবির ID, device) তা থেকেই যেন key-টা আবার বানাতে পারে, নইলে object খুঁজতে তাকে prefix list করতে হবে।

#সীমা পেরোলে: 503 Slow Down

একটা prefix যতটা সামলাতে পারে তার চেয়ে বেশি request পেলে, বাড়তি অংশের উত্তরে S3 দেয় HTTP 503 Slow Down। তিনটা কথা জেনে রাখো:

• এটা throttling, outage না। Data নিরাপদ; S3 শুধু client-কে বলছে কম পাঠাও।
• মানিয়ে নেওয়া ধীরে ধীরে হয়। কোনো prefix লম্বা সময় ব্যস্ত থাকলে S3 তার key range-কে আরও partition-এ ভাগ করে, কিন্তু সাথে সাথে না। নতুন, উঁচু হারে মানিয়ে নেওয়ার সময়টায় কিছু request 503 পায়; মানিয়ে নেওয়া শেষ হলে বন্ধ হয়। যে launch শূন্য থেকে লাফিয়ে প্রতি সেকেন্ডে ২০,০০০ request-এ ওঠে, ভালো key নকশা থাকলেও কিছুক্ষণ error দেখতে পারে।
• AWS SDK আর CLI 503 পেলে নিজেই আবার চেষ্টা করে, exponential backoff দিয়ে (একটু অপেক্ষা, তারপর আরও বেশি, তারপর আরও)। তুমি নিজে REST API call করলে একই retry নিজে লিখতে হবে।

তাই উঁচু request rate-এর নিয়মগুলো হলো: যথেষ্ট prefix জুড়ে key নকশা করো, বড় launch-এ সম্ভব হলে traffic ধীরে ধীরে বাড়াও, backoff দিয়ে retry করো, আর 5xx metric চোখে রাখো। 503 কোথা থেকে আসছে দেখতে bucket-এর CloudWatch request metric ব্যবহার করো (এতে 5xx-এর গণনা থাকে; bucket ধরে চালু করতে হয়, আর custom metric হিসেবে বিল হয়), S3 Storage Lens advanced metric-এর 503 গণনা (লেসন ১০.৭), অথবা server access log (লেসন ১০.৯), যেটা ঠিক কোন key আর prefix throttle হচ্ছে তা নাম ধরে দেখায়।

#S3-এর বাইরের ছাদ: SSE-KMS

একটা bottleneck আছে যেটা prefix বাড়িয়ে সারানো যায় না। Object SSE-KMS দিয়ে encrypt করা থাকলে (লেসন ১০.৮), S3 তোমার হয়ে AWS KMS-কে call করে:

• প্রতিটা upload-এ S3 KMS-এর কাছে নতুন একটা data key চায় (GenerateDataKey);
• প্রতিটা download-এ S3 KMS-কে দিয়ে object-এর data key decrypt করায় (Decrypt)।

এই call-গুলো গোনা হয় তোমার account-এর cryptographic operation-এর KMS request quota-র মধ্যে, যে একটাই quota account আর Region-এর সবকিছু মিলে ভাগ করে। আজকের default প্রতি সেকেন্ডে ১০,০০০ request, কিছু Region-এ ২০,০০০, আর সবচেয়ে বড়গুলোতে ১,০০,০০০ (US East (N. Virginia), US West (Oregon), Europe (Ireland))। পুরনো material-এ, অনেক course-এর slide-সহ, পাবে ৫,৫০০, ১০,০০০ আর ৩০,০০০। সবগুলোই বাড়ানো যায়।

তাই যে workload প্রতি সেকেন্ডে ১২,০০০ SSE-KMS object পড়ে, চারটা prefix-এ নিখুঁতভাবে ছড়ানো থাকলেও, ১০,০০০ quota-র Region-এ fail করতে পারে, কারণ throttle করছে KMS। সমাধান:

• S3 Bucket Key: S3 তোমার KMS key থেকে স্বল্পমেয়াদি একটা bucket-স্তরের key বানায় আর তা দিয়ে data key encrypt করে, ফলে KMS-কে অনেক কম ডাকে (AWS বলে ৯৯% পর্যন্ত কম request, তাতে KMS-এর বিলও কমে)। সাধারণত এটাই প্রথম উত্তর।
• Service Quotas console থেকে quota বাড়ানোর অনুরোধ।
• KMS-এর key policy আর audit trail না লাগলে SSE-S3 ব্যবহার।

SSE-KMS, Bucket Key আর quota নিয়ে বিস্তারিত লেসন ১০.৮-এ। এই লেসনের জন্য পরীক্ষার ধাঁচটা মনে রাখো: “SSE-KMS চালুর পর S3-এর throughput কমে গেছে” → সমস্যা KMS quota, S3 না।

KMS-এর ছাদসহ হিসাবটা নিজে করে দেখো:

#Multipart upload: বড় upload-এ গতি আর টেকসই ভাব

#কীভাবে কাজ করে

লেসন ১০.১-এ multipart upload এসেছিল বড় object upload করার উপায় হিসেবে। এখানে এটা performance-এর হাতিয়ার। একটা multipart upload-এর তিনটা ধাপ:

1. শুরু (CreateMultipartUpload): তুমি bucket আর key-এর নাম দাও, সাথে storage class, encryption আর metadata ঠিক করো। S3 একটা upload ID ফেরত দেয়।

2. Part upload (UploadPart): তুমি object-টা নম্বর দেওয়া part হিসেবে পাঠাও, প্রতিটার সাথে upload ID আর ১ থেকে ১০,০০০-এর মধ্যে একটা part number। Part পাঠানো যায় একসাথে আর যেকোনো ক্রমে, আর কোনো part আবারও পাঠানো যায়। প্রতিটা part-এর জন্য S3 একটা ETag ফেরত দেয়।

3. শেষ করা (CompleteMultipartUpload): তুমি part number আর ETag-এর তালিকা পাঠাও। S3 part number-এর ক্রমে part-গুলো জুড়ে একটা object বানায়। এই call-এর আগে পাঠকের কাছে object-টার অস্তিত্বই নেই, আর পরে আলাদা part-গুলো আর থাকে না।

যেকোনো সময় abort করা যায় (AbortMultipartUpload), তাতে part-গুলো মুছে যায়; আর কী কী চলছে তা list করা যায় (ListMultipartUploads, ListParts)।

#সীমাগুলো

১০,০০০ part-এর সীমা file-এর size আর part-এর size-কে বেঁধে দেয়: part-এর size ≥ file-এর size ÷ ১০,০০০। ১ TB-এর file-এ part লাগবে অন্তত ১০০ MB; CLI-এর default ৮ MB part দিয়ে লাগত ১,২৫,০০০ part, তাই CLI নিজেই part-এর size বাড়িয়ে নেয়।

#গতির হিসাব

Multipart upload-কে শুধু সম্ভব না, দ্রুতও করে কেন? কারণ প্রতিটা part আলাদা request, নিজের connection-এ।

একটা TCP connection একটা নির্দিষ্ট গতি পর্যন্তই ওঠে, যেটা তার পথের round-trip time আর packet হারানোর ওপর নির্ভর করে, প্রায়ই তোমার line যতটা বইতে পারে তার অনেক নিচে। Single PUT মানে একটা connection, তাই অফিসের link যত দ্রুতই হোক, এটা চলে একটা connection-এর গতিতে। Multipart-এ N টা connection মোটামুটি N গুণ data নেয়, যতক্ষণ না অন্য কিছু bottleneck হয়ে দাঁড়ায়: তোমার uplink, client-এর CPU বা disk, বা network।

একটা উদাহরণ: ৪ GB-এর file, একটা connection ১০ MB/s পর্যন্ত ওঠে, অফিসের uplink ১ Gbps (প্রায় ১২৫ MB/s)।

• একটা PUT: ৪,০০০ MB ÷ ১০ MB/s = ৪০০ সেকেন্ড।
• একসাথে ১০টা part দিয়ে multipart: ১০ × ১০ = ১০০ MB/s → ৪০ সেকেন্ড।
• একসাথে ২০টা দিলে: ২০০ MB/s link-এর চেয়ে বেশি, তাই link আটকে দেয় ১২৫ MB/s-এ → ৩২ সেকেন্ড। এরপর আর parallel বাড়িয়ে লাভ নেই; লাগবে দ্রুত link।

Parallel থাকলে একটা ব্যর্থতার দাম-ও বদলায়। ৯০%-এ গিয়ে fail করা single PUT আবার শূন্য থেকে শুরু করতে হয়। ১০০ MB-এর একটা part হারানো multipart upload আবার পাঠায় ১০০ MB। এটাই notes-এর পরীক্ষার কৌশল: network-এর সমস্যায় upload fail করলে multipart upload দেয় resume করার ক্ষমতা, কারণ শুধু ব্যর্থ part-টাই আবার upload হয়।

#ব্যর্থতা, retry আর ভুলে যাওয়া part

• পুরো file না, part আবার পাঠাও। ব্যর্থ part-টা একই upload ID আর part number দিয়ে আবার পাঠাও; নতুন কপি পুরনোটার জায়গা নেয়। SDK আর CLI এটা নিজেরাই করে।
• Part অদৃশ্য, কিন্তু বিল হয়। যে upload কখনো complete বা abort হয়নি, তার part-গুলো bucket-এ থেকে যায়, সাধারণ listing-এ object হিসেবে দেখা যায় না, আর storage হিসেবে টাকা কাটে। Crash করা একটা script বছরের পর বছর gigabyte-এর পর gigabyte ফেলে রাখতে পারে।
• Lifecycle rule দিয়ে পরিষ্কার করো। বড় upload আসে এমন প্রতিটা bucket-এ একটা rule রাখো: শুরু হওয়ার কিছুদিন পর, ধরো ৭ দিন, “অসম্পূর্ণ multipart upload মুছে দাও” (AbortIncompleteMultipartUpload)। Lifecycle rule নিয়ে লেসন ১০.৫; “ব্যর্থ বা অসম্পূর্ণ multipart upload-এর খরচ বাঁচাও” প্রশ্নের পরীক্ষার উত্তর এটাই।

#কাজটা tool-কে দিয়ে করাও

Multipart API হাতে খুব কমই call করতে হয়। উঁচু-স্তরের aws s3 cp আর aws s3 sync command, আর AWS SDK-এর Transfer Manager, ভাগ করা, একসাথে পাঠানো, retry আর complete করা সব নিজেরাই করে। CLI-এর default:

• multipart_threshold ৮ MB: এর বড় file part-এ upload হয়;
• multipart_chunksize ৮ MB: part-এর size (খুব বড় file-এ নিজে থেকে বাড়ে);
• max_concurrent_requests ১০: একসাথে কয়টা part পথে থাকবে।

দ্রুত link-এ concurrency আর part-এর size বাড়াও। নতুন AWS Common Runtime (CRT) transfer client, C-তে লেখা, আরও এক ধাপ এগিয়ে: তোমার network মেপে নিজেই ঠিক করে কতটা parallel চলবে। AWS CLI v2-এ preferred_transfer_client setting এটা ঠিক করে; crt দিলে জোর করে এটা চলে, আর default auto অনেক system-এ বেশিরভাগ transfer-এ এটাই ব্যবহার করে। নতুন ৫০ TB-এর object-এর জন্য AWS CRT-ভিত্তিক client-ই সুপারিশ করে।

Download চলে উল্টো দিকে একই নিয়মে: এই tool-গুলো বড় object নামায় একসাথে কয়েকটা byte range দিয়ে (নিচে byte-range fetch অংশ দেখো)।

এটা লেসনের দ্বিতীয় calculator। Part-এর size আর parallel সংখ্যা বদলাও, আর সীমা ও গতি কীভাবে বদলায় দেখো:

Multipart upload লেসন ১০.১২-এ জড়ো করা S3-এ data পৌঁছানোর তেরোটা “পথ”-এরও একটা, সেখানে এর পাশে আছে pre-signed URL (pre-signed part-সহ, যাতে browser বড় file সরাসরি S3-এ upload করতে পারে) আর Batch Operations।

#S3 Transfer Acceleration

#Edge দিয়ে পথ

Multipart সারায় “একটা connection ধীর” সমস্যা। “পুরো পথটাই লম্বা আর packet হারায়” সমস্যা এটা সারায় না। Client যখন bucket থেকে অন্য মহাদেশে, প্রতিটা connection এমন অনেক network পার হয় যেগুলো কেউ তোমার জন্য সাজিয়ে রাখেনি, আর লম্বা round trip-এ packet হারালে TCP খুব ধীর হয়ে যায়।

S3 Transfer Acceleration পথটাই বদলে দেয়:

1. Client data পাঠায় একটা বিশেষ endpoint-এ: bucketname.s3-accelerate.amazonaws.com।

2. DNS এটাকে মেলায় সবচেয়ে কাছের CloudFront edge location-এর সাথে, যেটা সাধারণত client থেকে অল্প দূরে।

3. Edge থেকে data bucket-এর Region পর্যন্ত যায় AWS global network দিয়ে, public internet-এর বদলে সাজানো, যথেষ্ট ক্ষমতার একটা পথে।

Slide-এর ছবিটা ঠিক এটাই: আমেরিকার একটা file public internet দিয়ে যায় শুধু আমেরিকারই একটা edge location পর্যন্ত, তারপর AWS-এর private network দিয়ে অস্ট্রেলিয়ার একটা bucket-এ। এটা upload আর download দুটোতেই কাজ করে, আর multipart upload-এর সাথে চলে: প্রতিটা part দ্রুত পথটা নেয়, তাই দুটো উন্নতি গুণ হয়ে যায়।

#চালু করা

• চালু করতে হয় bucket ধরে (console, PutBucketAccelerateConfiguration, বা CLI)। পারে শুধু bucket-এর মালিক, অথবা যার s3:PutAccelerateConfiguration permission আছে।
• Bucket-এর নাম DNS-এর নিয়ম মানতে হবে, আর তাতে dot (.) থাকা চলবে না। tv.footage.example নামের bucket এটা ব্যবহার করতে পারবে না; dot ছাড়া নতুন bucket বানাও।
• Client-কে accelerate endpoint (IPv6-এর জন্য bucketname.s3-accelerate.dualstack.amazonaws.com) আর virtual-hosted ধাঁচের request ব্যবহার করতে হবে। সাধারণ endpoint সাধারণ গতিতে চলতেই থাকে, তাই প্রতি request-এ বেছে নেওয়া যায়। SDK আর CLI-তে এর জন্য একটা flag আছে (use_accelerate_endpoint)।
• চালু করার পর আসলেই গতি বাড়তে ২০ মিনিট পর্যন্ত লাগতে পারে, যদিও endpoint সাথে সাথেই কাজ করে।
• ListBuckets, CreateBucket আর DeleteBucket ছাড়া সবই endpoint দিয়ে চলে, আর CopyObject দিয়ে Region-পার copy চলে না: এটা client আর bucket-এর মধ্যে data আনা-নেওয়ার জন্য।
• General purpose bucket-এর জন্য এটা চলে পনেরোটা Region-এর একটা তালিকায় (অক্টোবর ২০২৬), যার মধ্যে আছে US East আর West, ইউরোপের কয়েকটা Region, Tokyo, Seoul, Mumbai, Singapore, Sydney, Canada (Central) আর São Paulo। এর ওপর ভর করে নকশা করার আগে তালিকাটা মিলিয়ে নাও।

#খরচ, আর কখন লাভ নেই

Transfer Acceleration-এর নিজের প্রতি-GB দাম আছে, স্বাভাবিক data transfer দামের ওপরে: কাজটা আমেরিকা, ইউরোপ বা জাপানের edge location করলে প্রতি GB $0.04, অন্য সব edge location-এ প্রতি GB $0.08 (internet থেকে data ঢোকার বেলায়)। ঢাকা থেকে এশিয়ার কোনো edge হয়ে ২০ GB পাঠালে বাড়তি লাগে প্রায় $1.60।

সবচেয়ে বেশি কাজে দেয় যখন client Region থেকে অনেক দূরে, তার connection দ্রুত, আর সে নিয়মিত বড় object বা অনেক data পাঠায়, মহাদেশ পেরিয়ে। সামান্য বা কোনো লাভই নেই যখন:

• client আগে থেকেই Region-এর কাছে (Sydney-র অফিস Sydney-র bucket-এ upload করছে);
• object ছোট, তাই transfer-এর চেয়ে connection বানাতেই বেশি সময় যায়;
• bottleneck client-এর নিজের ধীর শেষ-মাইল (দুর্বল mobile connection দুর্বলই থাকবে);
• client AWS-এর ভেতরেই, একই Region-এ (bucket-এর পাশের একটা EC2 instance)।

AWS যখন দেখে কোনো transfer-এ acceleration দ্রুত হওয়ার সম্ভাবনা ছিল না, তখন ওই transfer-এর acceleration fee নেয় না। চালু করার আগে তোমার user-রা যেখানে আছে সেখান থেকে browser-এ Transfer Acceleration Speed Comparison tool চালাও; এটা কয়েকটা Region-এ acceleration দিয়ে আর ছাড়া upload করে পার্থক্যটা দেখায়।

#Transfer Acceleration, নাকি অন্য কিছু?

লেসন ১০.১১ Transfer Acceleration-কে S3-এ বড় পরিমাণ data পৌঁছানোর “পথ”-গুলোর মাঝে রেখে এই বিকল্পগুলোর সাথে বিস্তারিত তুলনা করেছে।

#Byte-range fetch

#একসাথে কয়েক টুকরো download

সাধারণ GET পুরো object ফেরত দেয়। HTTP Range header দিলে GET ফেরত দেয় শুধু যে byte-গুলো চেয়েছ: Range: bytes=0-8388607 দেয় প্রথম ৮ MiB, আর S3 উত্তর দেয় 206 Partial Content। এটাই byte-range fetch, আর এটা multipart upload-এর download-দিকের জমজ ভাই:

• গতি: বড় একটা object-কে কয়েকটা range-এ ভাগ করে কয়েকটা connection-এ একসাথে চাও। ১ GB-এর একটা video-র চারটা range মোটামুটি চার ভাগের এক ভাগ সময়ে শেষ হয়, যদি client-এর network তা বইতে পারে। AWS ৮ MB বা ১৬ MB-এর মতো range-এর কথা বলে; object multipart দিয়ে upload হয়ে থাকলে range মেলাও আসল part-সীমা ধরে, অথবা partNumber দিয়ে সরাসরি একটা part চাও।
• টেকসই ভাব: একটা range fail করলে শুধু সেটাই আবার চাও। AWS বলে ধীর request আবার চাইতে নতুন connection আর নতুন DNS lookup নিতে, কারণ তাহলে retry সম্ভবত অন্য, দ্রুত পথে যাবে।
• আবার চালু করা: ৬০০ MB-তে কেটে যাওয়া download শূন্য থেকে না শুরু করে খোলা-শেষ range দিয়ে চালিয়ে নাও, Range: bytes=600000000-। আসল ETag দিয়ে If-Match পাঠাও, যাতে মাঝে object বদলে গেলে resume পরিষ্কারভাবে fail করে।

প্রতিটা range একটা সাধারণ GET request, তাই prefix-এর ৫,৫০০ GET/s-এর হিসাবে পড়ে। ১ GB-এর object ৮ MB-এর ১২৮টা range-এ আনলে সেটা ১২৮টা request।

#শুধু যতটুকু দরকার

দ্বিতীয় ব্যবহার: file-এর শুধু একটা অংশ নামানো, আর কিছু না। অনেক format দরকারি তথ্যটা রাখে শুরুতে (বা শেষে): video-র header-এ তার format আর দৈর্ঘ্য, ছবির মাপ, Parquet file-এর footer-এ তার schema। প্রথম (বা শেষ) কয়েকটা byte-এর byte-range fetch পুরো object না নামিয়েই সেটা পড়ে ফেলে, আর data transfer-এর টাকা লাগে শুধু ওই byte-গুলোর।

Notes-এর দুটো পরীক্ষার ইঙ্গিতই এদিকে: “বড় video file-এর download দ্রুত করো” আর “file-এর header পড়তে শুধু প্রথম ৫০ byte নামাও” → byte-range fetch। HEAD request একটা লোভনীয় ভুল উত্তর: এটা object-এর metadata দেয় (size, ETag, content type, user metadata), content-এর একটা byte-ও না।

#S3 আরও দ্রুত করার অন্য উপায়

Notes আর slide ওপরের চারটা হাতিয়ার নিয়ে। আসল নকশায় আর পরীক্ষার উত্তরে আরও কয়েকটা আসে:

• Compute রাখো bucket-এর একই Region-এ। Bucket-এর Region-এ থাকা EC2 instance latency কম পায়, আর Region-পার data transfer-এর খরচ লাগে না। যথেষ্ট parallel request দিলে একটা EC2 instance S3-এর সাথে ১০০ Gbps পর্যন্ত পৌঁছাতে পারে; data-lake-এর কাজে আরও instance যোগ করে প্রতি সেকেন্ডে terabit-এ ওঠা যায়।
• গরম object cache করো। একই object বারবার পড়া হলে internet-এর user-দের জন্য bucket-এর সামনে CloudFront (অধ্যায় ১১), আর যে application-এর millisecond-এর নিচে read লাগে তার জন্য ElastiCache (লেসন ৭.৫)। S3-এ request কম পৌঁছায়, তাতে request-এর বিলও কমে।
• এক অঙ্কের millisecond latency লাগবে? S3 Express One Zone (লেসন ১০.৫) data রাখে একটা Availability Zone-এ, একটা directory bucket-এ, এক অঙ্কের millisecond access আর প্রতি সেকেন্ডে লাখ লাখ request নিয়ে। Compute রাখো একই AZ-তে।
• শুধু ব্যর্থ না, ধীর request-ও আবার চাও। Latency-সংবেদনশীল app-এর জন্য AWS বলে ছোট request প্রায় ২ সেকেন্ডে শেষ না হলে আবার চাইতে, তারপর back off করতে; আর বড় request-এর বেলায় সবচেয়ে ধীর কয়েক শতাংশ আবার চাইতে। Retry সাধারণত অন্য পথে যায় আর দ্রুত সফল হয়।
• Connection আবার ব্যবহার করো। প্রতিটা request-এ নতুন TCP আর TLS session না খুলে HTTP connection-এর একটা pool রাখো, আর S3-এর একটাই IP address আঁকড়ে থেকো না: S3-এর DNS অনেকগুলো address দেয় কারণ আছে বলেই।
• হালনাগাদ SDK ব্যবহার করো। এটা আগে থেকেই backoff দিয়ে 503 retry করে, আর এতে Transfer Manager আছে।

#এক নজরে পরীক্ষার ধাঁচ

#System design-এ S3 performance

• যে হার আশা করছ, সেই মাপে key নকশা করো। ছড়ানোর অংশটা key-এর সামনের দিকে রাখো (একটা shard, hash, tenant বা device ID), আর নিশ্চিত করো প্রত্যেক পাঠক key-টা হিসাব করে বের করতে পারে। হিসাব করো সর্বোচ্চ চাপের সময়ের জন্য: নির্বাচনের রাত, sale, মাস-শেষের batch; সাধারণ একটা দিনের জন্য না।
• গরম key-এর একদম সামনে সময় বসিয়ো না। 2026-10-24-12-00-01.json-এর মতো key আজকের সব write একটাই সরে-যাওয়া range-এ ফেলে। logs/<device-shard>/2026/10/24/… write ছড়িয়ে দেয়, আবার shard-এর ভেতরে দিন ধরে list-ও করা যায়।
• Capacity-র হিসাবে KMS-কে ধরো। প্রতিটা SSE-KMS request একটা KMS request-ও। ব্যস্ত bucket-এ শুরু থেকেই S3 Bucket Key চালু রাখো।
• বড় object: দুই দিকেই parallel। ওঠার পথে multipart, নামার পথে byte range; কাজটা করুক SDK-এর Transfer Manager বা CRT client। Part-এর size এমন রাখো যাতে তোমার সবচেয়ে বড় object-ও ১০,০০০ part-এ ধরে।
• দূরের লেখক: Transfer Acceleration; দূরের পাঠক: CloudFront। Acceleration-এর টাকা দেওয়ার আগে Speed Comparison tool দিয়ে মেপে নাও।
• 503 আশা করো, চোখেও রাখো। Backoff দিয়ে retry স্বাভাবিক ব্যাপার; কিন্তু একটা prefix-এ টানা 503 মানে key নকশায় সমস্যা। 5xx metric দেখো, আর বড় launch-কে ধীরে ধীরে বাড়তে দাও।
• ব্যর্থতার পর পরিষ্কার করো। অসম্পূর্ণ multipart upload-এর lifecycle rule প্রতিটা bucket template-এ থাকা উচিত।

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

একটা bucket-এর request rate আর 503 দেখো (CloudWatch request metric ঐচ্ছিক, আর এর বিল হয়):

# পুরো bucket-এর জন্য request metric চালু করো (EntireBucket নামের একটা filter)
aws s3api put-bucket-metrics-configuration --bucket news-photos-example \
  --id EntireBucket --metrics-configuration Id=EntireBucket

# Traffic চলার পর: গত এক ঘণ্টায় প্রতি মিনিটে 5xx error
aws cloudwatch get-metric-statistics --namespace AWS/S3 --metric-name 5xxErrors \
  --dimensions Name=BucketName,Value=news-photos-example Name=FilterId,Value=EntireBucket \
  --start-time 2026-10-24T18:00:00Z --end-time 2026-10-24T19:00:00Z \
  --period 60 --statistics Sum

হাতে, ধাপে ধাপে একটা multipart upload:

# ১. শুরু: S3 একটা UploadId ফেরত দেয়
aws s3api create-multipart-upload --bucket tv-archive-example --key shows/2026-10-24.mp4

# ২. File-কে ১০০ MB-এর part-এ ভাগ করে upload করো (এগুলো একসাথে চলতে পারে)
split -b 100M talkshow.mp4 part-
aws s3api upload-part --bucket tv-archive-example --key shows/2026-10-24.mp4 \
  --part-number 1 --body part-aa --upload-id "$UPLOAD_ID"     # একটা ETag ফেরত দেয়
aws s3api upload-part --bucket tv-archive-example --key shows/2026-10-24.mp4 \
  --part-number 2 --body part-ab --upload-id "$UPLOAD_ID"
# ... প্রতি part-এ একটা call

# ৩. S3-এ কী আছে দেখো, তারপর part number আর ETag-এর তালিকা দিয়ে শেষ করো
aws s3api list-parts --bucket tv-archive-example --key shows/2026-10-24.mp4 --upload-id "$UPLOAD_ID"
aws s3api complete-multipart-upload --bucket tv-archive-example --key shows/2026-10-24.mp4 \
  --upload-id "$UPLOAD_ID" --multipart-upload file://parts.json
# parts.json: {"Parts":[{"PartNumber":1,"ETag":"\"etag-1\""},{"PartNumber":2,"ETag":"\"etag-2\""}]}

# ভুলে যাওয়া upload খুঁজে বের করো আর সরাও
aws s3api list-multipart-uploads --bucket tv-archive-example
aws s3api abort-multipart-upload --bucket tv-archive-example --key shows/2026-10-24.mp4 \
  --upload-id "$UPLOAD_ID"

দ্রুত link-এর মাপে CLI-কে দিয়ে করাও, আর পরিষ্কারের rule যোগ করো:

aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 20
aws configure set default.s3.preferred_transfer_client crt   # C-তে লেখা CRT client
aws s3 cp talkshow.mp4 s3://tv-archive-example/shows/2026-10-24.mp4

# Lifecycle: ৭ দিনের মধ্যে শেষ না হওয়া multipart upload abort করো
aws s3api put-bucket-lifecycle-configuration --bucket tv-archive-example \
  --lifecycle-configuration '{"Rules":[{"ID":"abort-incomplete-mpu","Status":"Enabled",
    "Filter":{},"AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}'

Transfer Acceleration:

# চালু করো (dot ছাড়া bucket-এর নাম), তারপর অবস্থা দেখো
aws s3api put-bucket-accelerate-configuration --bucket tv-footage-example \
  --accelerate-configuration Status=Enabled
aws s3api get-bucket-accelerate-configuration --bucket tv-footage-example

# একটা command-এর জন্য accelerate endpoint...
aws s3 cp footage.mov s3://tv-footage-example/2026/ --endpoint-url https://s3-accelerate.amazonaws.com
# ...অথবা সব s3 command-এর জন্য
aws configure set default.s3.use_accelerate_endpoint true

Byte-range fetch:

# শুধু প্রথম ৫০ byte (header)
aws s3api get-object --bucket movies-example --key films/river.mp4 --range bytes=0-49 header.bin

# বড় object-এর একটা range, আর আসল multipart-এর একটা part
aws s3api get-object --bucket movies-example --key films/river.mp4 \
  --range bytes=8388608-16777215 piece-2.bin
aws s3api get-object --bucket movies-example --key films/river.mp4 --part-number 3 part-3.bin

আর যে Bucket Key SSE-KMS-কে KMS quota-য় ধাক্কা খেতে দেয় না:

aws s3api put-bucket-encryption --bucket news-photos-example --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms",
    "KMSMasterKeyID":"arn:aws:kms:ap-southeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"},
    "BucketKeyEnabled":true}]}'

#সারসংক্ষেপ

মূল কথাগুলো

• S3 নিজে থেকেই scale করে; প্রথম byte-এর latency মোটামুটি ১০০–২০০ ms। Performance নকশা মানে প্রতি prefix-এ request rate আর প্রতি transfer-এ প্রতি সেকেন্ডে byte।
• প্রতি prefix-এ প্রতি সেকেন্ডে অন্তত ৩,৫০০ PUT/COPY/POST/DELETE আর ৫,৫০০ GET/HEAD; prefix-এর সংখ্যায় সীমা নেই। লাগবে কয়টা prefix = হার ÷ সীমা, ওপরের দিকে round, read আর write আলাদা করে। ৪টা prefix → ২২,০০০ GET/s; ১০টা → ৫৫,০০০।
• সীমা পেরোলে → 503 Slow Down: throttling, SDK exponential backoff দিয়ে retry করে। নতুন হারে S3 মানিয়ে নেয় ধীরে ধীরে। শুধু গতির জন্য random key prefix আর লাগে না (২০১৮ থেকে)।
• SSE-KMS প্রতিটা upload (GenerateDataKey) আর download-এ (Decrypt) একটা KMS call যোগ করে, যার সীমা Region-ভিত্তিক একটা shared KMS quota (আজকের default প্রতি সেকেন্ডে ১০,০০০, ২০,০০০ বা ১,০০,০০০)। সমাধান: S3 Bucket Key, quota বাড়ানো, বা SSE-S3।
• Multipart upload: শুরু → part একসাথে (যেকোনো ক্রমে) upload → শেষ করা। ১০০ MB থেকে পরামর্শ, ৫ GB-এর বেশি হলে বাধ্যতামূলক। Part ৫ MiB–৫ GiB (শেষটা ছোট হতে পারে), সর্বোচ্চ ১০,০০০। Object সর্বোচ্চ পরীক্ষায় ৫ TB, ডিসেম্বর ২০২৫ থেকে ৫০ TB।
• Multipart দ্রুত কারণ N connection ≈ N × একটা connection, তোমার link পর্যন্ত; আর একটা ব্যর্থতার দাম একটা part, পুরো file না। ফেলে রাখা part সরাও lifecycle rule দিয়ে।
• Transfer Acceleration: bucket.s3-accelerate.amazonaws.com → সবচেয়ে কাছের edge location → AWS network → bucket। Multipart-এর সাথে চলে, upload আর download দুটোতেই। লাগে dot ছাড়া DNS-মানা নাম, বাড়তি $0.04–$0.08/GB, দ্রুত না হলে fee নেই। Region-এর কাছে বা ছোট file-এ লাভ নেই।
• Byte-range fetch (Range header, 206): একসাথে download, একটা range আবার আনা বা resume, শুধু header পড়া। HEAD দেয় metadata, content না।

নিজেকে যাচাই করো: S3 performance৩১টি প্রশ্ন