প্রোডাকশন CDN ও বড় আউটেজ

গল্পে বুঝি

খোয়ারিজমির একটা লজিস্টিকস কোম্পানি আছে, চট্টগ্রাম বন্দর থেকে কন্টেইনারের মাল ঢাকার কারখানাগুলোতে পৌঁছে দেয়। শুরুতে সে সব কাজ দিত একটাই ট্রাক কোম্পানিকে। ভাড়া কম, যোগাযোগ সহজ, একটাই হিসাবের খাতা। তারপর এক সোমবার সেই কোম্পানির ড্রাইভাররা ধর্মঘট ডাকল। তিন দিন একটা ট্রাকও চলল না, কারখানাগুলোর লাইন বন্ধ হয়ে গেল, আর খোয়ারিজমির কাছে কোনো বিকল্প ছিল না, কারণ অন্য কোম্পানির সাথে তার কোনো চুক্তিই নেই, তারা তার মালের ধরন চেনে না, গুদামের ঠিকানাও জানে না।

এরপর খোয়ারিজমি নিয়ম বদলাল। এখন দুইটা ট্রাক কোম্পানির সাথে চুক্তি, কাজ ভাগ করা হয় প্রায় সত্তর-ত্রিশ। দুই কোম্পানিকেই একই কাগজ দেওয়া হয়: কোন মাল কোন গুদামে যাবে, কোন গেটে কোন সময়, কী সাবধানতা। প্রতিদিন সকালে খোয়ারিজমির অফিসের ফাতিমা হাইওয়ের প্রতিটা অংশে ট্রাকগুলোর পৌঁছানোর সময় দেখে: কুমিল্লার কাছে কোন কোম্পানির ট্রাক দেরি করছে, ফেনীতে কার গাড়ি বেশি নষ্ট হচ্ছে। যে কোম্পানি যেদিন খারাপ করছে, সেদিন তাকে কম কাজ দেওয়া হয়।

কিন্তু খোয়ারিজমি দেখল, দুই কোম্পানি রাখার একটা খরচও আছে। একবার নতুন একটা কারখানার ঠিকানা শুধু বড় কোম্পানিকে জানানো হয়েছিল, ছোটটাকে নয়। যেদিন বড় কোম্পানির ট্রাক কম ছিল, ছোট কোম্পানির ট্রাক ঠিকানা না জেনে পুরনো গুদামে মাল নামিয়ে দিল। তাই এখন সব নির্দেশনা একটা মূল খাতায় লেখা হয়, আর সেখান থেকে দুই কোম্পানির কাছে একসাথে যায়। আর বছরে দুইবার খোয়ারিজমি ইচ্ছা করে একদিনের জন্য বড় কোম্পানিকে পুরো বিরতি দেয়, দেখার জন্য যে ছোটটা সত্যিই পুরো কাজ সামলাতে পারে কিনা।

মিলিয়ে নিই: একটাই ট্রাক কোম্পানি হলো একক CDN প্রোভাইডার, আর ধর্মঘট হলো CDN-এর বড় আউটেজ। দুই কোম্পানির মধ্যে কাজ ভাগ হলো মাল্টি-CDN, সত্তর-ত্রিশ ভাগ হলো weighted স্টিয়ারিং, আর ফাতিমার প্রতিদিনের সময় মাপা হলো RUM-ভিত্তিক স্টিয়ারিং, যেখানে আসল ইউজারের মাপ দেখে ট্রাফিক সরানো হয়। ভুল ঠিকানায় মাল নামানো হলো কনফিগ প্যারিটির সমস্যা, আর মূল খাতা থেকে দুই কোম্পানিকে একসাথে নির্দেশ পাঠানো হলো কনফিগ অ্যাজ কোড। বছরে দুইবারের ইচ্ছাকৃত বিরতি হলো ফেইলওভার ড্রিল। বড় ই-কমার্স, স্ট্রিমিং আর নিউজ সাইট ঠিক এভাবে একাধিক CDN চালায়, যাতে একটার খারাপ দিন পুরো ব্যবসার খারাপ দিন না হয়।

মাল্টি-CDN: কখন, কীভাবে

একটা CDN-এর আউটেজ মানে আপনার পুরো সাইটের আউটেজ, যদি না বিকল্প প্রস্তুত থাকে। কিন্তু মাল্টি-CDN বিনামূল্যে আসে না: দুইটা কনফিগ, দুইটা বিল, দুইটা সার্টিফিকেট পাইপলাইন, দুইটা পার্জ API, আর প্রতিটা ফিচার দুই জায়গায় একভাবে চালানোর ঝামেলা।

প্রশ্ন	উত্তর “হ্যাঁ” হলে
এক ঘণ্টার আউটেজে কি বড় আর্থিক বা চুক্তিগত ক্ষতি?	মাল্টি-CDN ভাবুন
ট্রাফিক কি এত বেশি যে দুই ভেন্ডরের দামাদামিতে লাভ?	মাল্টি-CDN ভাবুন
কোনো অঞ্চলে এক CDN দুর্বল, আরেকটা শক্তিশালী?	মাল্টি-CDN ভাবুন
এজ কম্পিউট, WAF বা ভেন্ডর-নির্দিষ্ট ফিচারের ওপর গভীর নির্ভরতা?	কঠিন; আগে নির্ভরতা কমান
টিম ছোট, কনফিগ বদলায় প্রায়ই?	একটা CDN + জরুরি বাইপাস প্ল্যান

স্টিয়ারিংয়ের তিন পথ

• DNS-ভিত্তিক weighted: একটা DNS নাম দুই CDN-এর হোস্টনেমে weighted CNAME দেয় (যেমন ৭০/৩০)। সবচেয়ে সহজ। দুর্বলতা: ফেইলওভার TTL-এর গতিতে, আর resolver-এর ক্যাশের কারণে ভাগ কখনো নিখুঁত নয় (দেখুন DNS দিয়ে ট্রাফিক চালানো)।
• Health-checked ফেইলওভার: DNS প্রোভাইডার বা একটা আলাদা স্টিয়ারিং সার্ভিস প্রতিটা CDN-কে বাইরে থেকে চেক করে, একটা ব্যর্থ হলে সেটা উত্তর থেকে সরায়।
• RUM-ভিত্তিক: আসল ইউজারের ব্রাউজার থেকে মাপা লেটেন্সি আর এরর রেট (অঞ্চল আর ISP অনুযায়ী) দেখে স্টিয়ারিং সিদ্ধান্ত নেওয়া হয়। সবচেয়ে নির্ভুল, কিন্তু একটা কমার্শিয়াল স্টিয়ারিং সার্ভিস বা নিজের ডেটা পাইপলাইন লাগে।

সবচেয়ে বড় বিপদ: কনফিগ প্যারিটি

দুই CDN-এ ক্যাশ নিয়ম, রিডাইরেক্ট, হেডার, TLS সেটিং, WAF ব্যতিক্রম একরকম না থাকলে, ফেইলওভারের সময় সাইট হঠাৎ অন্যরকম আচরণ করে: যে পেজ ক্যাশ হওয়ার কথা নয় সেটা ক্যাশ হয়, একটা রিডাইরেক্ট লুপ শুরু হয়, একটা API কল WAF আটকে দেয়। আর এটা ধরা পড়ে ঠিক যখন আপনি সবচেয়ে চাপে থাকেন।

প্রতিরোধ:

• ক্যাশিংয়ের নিয়ম origin-এর হেডারে রাখুন, CDN-এর ড্যাশবোর্ডে নয়। origin যদি প্রতিটা রেসপন্সে সঠিক Cache-Control / CDN-Cache-Control পাঠায়, দুই CDN-ই একই আচরণ করবে। CDN-নির্দিষ্ট নিয়ম যত কম, প্যারিটি তত সহজ।
• প্রতিটা CDN-এর হোস্টনেম আলাদা করে টেস্ট করুন, শুধু মূল নাম নয়। CI-তে একটা স্ক্রিপ্ট দুই CDN-এর হোস্টনেমে একই URL তালিকা চালিয়ে স্ট্যাটাস, ক্যাশ হেডার আর রিডাইরেক্ট তুলনা করতে পারে।
• দ্বিতীয় CDN-কে সবসময় কিছু ট্রাফিক দিন। শূন্য ট্রাফিকের “ব্যাকআপ” CDN প্রায় নিশ্চিতভাবে কোথাও পিছিয়ে আছে, আর তার ক্যাশ খালি।

খরচের মডেল

CDN-এর বিল সাধারণত কয়েকটা জিনিস মিলিয়ে হয়। দাম ভেন্ডর, অঞ্চল আর চুক্তিভেদে অনেক আলাদা আর প্রায়ই বদলায়, তাই নিচে শুধু মেকানিজম; সংখ্যা নিজের ভেন্ডরের প্রাইসিং পেজ আর চুক্তি থেকে নিন।

খরচের উৎস	কী বাড়ায়	কমানোর উপায়
edge থেকে ইউজারে egress (GB)	বড় ফাইল, ইমেজ, ভিডিও; কিছু অঞ্চলে দাম বেশি	কমপ্রেশন, আধুনিক ইমেজ ফরম্যাট, সঠিক রেজোলিউশন (চ্যাপ্টার ১০)
রিকোয়েস্ট সংখ্যা	অনেক ছোট ফাইল, পোলিং, বট	বান্ডেলিং, বট ফিল্টার, ক্লায়েন্ট-সাইড ক্যাশ
origin থেকে egress (ক্লাউডে)	কম hit ratio, প্রতিটা PoP-এর আলাদা MISS	origin shield, লম্বা TTL, ভার্সনড URL
এজ কম্পিউট, WAF, লগ স্ট্রিমিং	প্রতি রিকোয়েস্টে ফাংশন, প্রতি নিয়ম, প্রতি GB লগ	যেখানে দরকার শুধু সেখানে; লগ স্যাম্পলিং

মনে রাখার মতো একটা মেকানিজম: origin-এর ক্লাউড egress প্রায়ই CDN-এর egress-এর চেয়ে দামি। তাই hit ratio এক-দুই শতাংশ বাড়ালেও origin-এর বিলে বড় পার্থক্য হয়। byte hit ratio (বাইটের হিসাবে কতটা ক্যাশ থেকে গেছে) আলাদা করে দেখুন: রিকোয়েস্টের হিসাবে ৯৫% HIT হতে পারে, কিন্তু বড় ভিডিও ফাইলগুলো MISS হলে বাইটের হিসাবে origin-এ অনেক বেশি যাচ্ছে।

কনফিগ অ্যাজ কোড আর ধাপে ধাপে রোলআউট

CDN-এর ড্যাশবোর্ডে হাতে বদলানো নিয়মের কোনো রিভিউ নেই, ইতিহাস নেই, রোলব্যাক নেই। সমাধান: CDN-এর কনফিগ git-এ রাখুন, আর একটা টুল দিয়ে প্রয়োগ করুন।

• বেশিরভাগ বড় CDN-এর Terraform প্রোভাইডার আছে; কিছুর নিজস্ব CLI বা কনফিগ ফাইল (যেমন এজ ফাংশনের প্রজেক্ট ফাইল)। নিজের ভেন্ডরের বর্তমান টুলিং তাদের ডকসে দেখে নিন।
• প্রতিটা বদল pull request হিসেবে, রিভিউ সহ। ক্যাশ নিয়মের বদলে রিভিউয়ার নিজেকে জিজ্ঞেস করবেন: “এই নিয়মে কি কোনো লগইন করা পেজ ধরা পড়তে পারে?”
• স্টেজিং আগে: একটা স্টেজিং হোস্টনেম (staging.baytalhikma.org) একই CDN কনফিগে, যেখানে প্রথমে প্রয়োগ আর টেস্ট।
• ধাপে ধাপে: যদি CDN সাপোর্ট করে, নতুন নিয়ম প্রথমে ট্রাফিকের ছোট অংশে বা কয়েকটা হোস্টনেমে, তারপর সব জায়গায়। নিচের আউটেজগুলোর প্রায় সবগুলোর মূল শিক্ষা এটাই।
• CI-তে স্মোক টেস্ট: প্রয়োগের পর একটা URL তালিকায় স্ট্যাটাস কোড, Cache-Control, ক্যাশ স্টেট আর রিডাইরেক্ট যাচাই। চ্যাপ্টার ১৪-এর cdn-check.sh এর ভিত্তি হতে পারে।

# .github/workflows/cdn-smoke.yml (sketch)
name: cdn-smoke
on: [workflow_dispatch, deployment_status]
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          set -e
          while read -r url want; do
            got=$(curl -s -o /dev/null -w '%{http_code}' "$url")
            echo "$got $url"
            [ "$got" = "$want" ]
          done < cdn-smoke-urls.txt

# cdn-smoke-urls.txt: url expected-status
https://baytalhikma.org/ 200
https://baytalhikma.org/app.3f9a.css 200
https://baytalhikma.org/old-page 301
https://baytalhikma.org/account 302

মনিটরিং আর SLO

CDN আপনার আর ইউজারের মাঝে দাঁড়িয়ে থাকে, তাই origin-এর মনিটরিং সবুজ থাকলেও ইউজার এরর পেতে পারে। দুই দিক থেকে মাপুন।

মেট্রিক	কোথা থেকে	কেন
hit ratio (রিকোয়েস্ট)	CDN লগ/অ্যানালিটিক্স	ক্যাশ নিয়ম ভাঙলে প্রথম সংকেত
byte hit ratio / origin offload	CDN লগ, origin-এর egress	খরচ আর origin-এর লোড
5xx রেট, PoP অনুযায়ী	CDN লগ	একটা PoP-এর সমস্যা গড়ে লুকিয়ে যায়
TTFB p95, অঞ্চল অনুযায়ী	RUM (ব্রাউজার থেকে)	ইউজার আসলে কী অনুভব করছে
সিনথেটিক চেক, কয়েক দেশ থেকে	বাইরের মনিটর	ট্রাফিক কম থাকলেও আউটেজ ধরা
সার্টিফিকেট এক্সপায়ারি	সিনথেটিক চেক	edge আর origin দুই জায়গার সার্টিফিকেট
origin-এর রিকোয়েস্ট রেট	origin	হঠাৎ লাফ মানে ক্যাশ খালি বা বাইপাস হচ্ছে

লগ স্ট্রিমিং: বেশিরভাগ CDN রিকোয়েস্ট লগ আপনার স্টোরেজ বা লগ সিস্টেমে পাঠাতে পারে (প্রায়ই আলাদা খরচে)। প্রতিটা লাইনে অন্তত থাকা দরকার: সময়, PoP, স্ট্যাটাস, ক্যাশ স্টেট, origin-এর রেসপন্স টাইম, বাইট, URL। এগুলো নিজের ClickHouse বা Loki-তে রাখলে “গত এক ঘণ্টায় কোন PoP-এ 5xx বেড়েছে” এক কুয়েরিতে বের হয়।

SLO উদাহরণ: “প্রতি ২৮ দিনে, সিনথেটিক চেকের ৯৯.৯% রিকোয়েস্ট ৫০০ ms-এর মধ্যে 2xx/3xx দেবে, প্রতিটা প্রধান অঞ্চল আলাদাভাবে।” অঞ্চল আলাদা না করলে একটা দেশের পুরো আউটেজ বৈশ্বিক গড়ে প্রায় অদৃশ্য থাকে। SLO আর error budget নিয়ে বিস্তারিত আছে SRE ট্র্যাকে।

রানবুক: CDN নিজেই ডাউন

বড় CDN-ও ডাউন হয় (নিচে দেখুন)। তখন দুইটা প্রশ্ন: সরাসরি origin-এ ট্রাফিক নেওয়া যাবে কি, আর গেলে origin টিকবে কি?

আগে থেকে প্রস্তুতি (না থাকলে আউটেজের সময় কিছুই করা যাবে না):

1. DNS আলাদা প্রোভাইডারে, বা অন্তত CDN ডাউন হলেও বদলানো যায় এমন জায়গায়। আপনার DNS যদি CDN-এর নিজেরই হয় আর CDN-এর ড্যাশবোর্ড বা API ডাউন থাকে, আপনি রেকর্ড বদলাতেই পারবেন না।
2. CDN-মুখী রেকর্ডের TTL ছোট (যেমন ৩০০ সেকেন্ড বা কম)। ২৪ ঘণ্টার TTL থাকলে রেকর্ড বদলালেও ইউজাররা ২৪ ঘণ্টা পুরনো উত্তর পাবে।
3. origin-এ সরাসরি ইউজার নেওয়ার ব্যবস্থা: একটা বৈধ পাবলিক সার্টিফিকেট, পাবলিক ফায়ারওয়াল নিয়ম যেটা এক কমান্ডে খোলা যায়, আর সামনে অন্তত একটা সাধারণ রেট লিমিট।
4. origin-এর ক্ষমতার হিসাব: CDN সাধারণত ৯০% বা তার বেশি ট্রাফিক শুষে নেয়। সব ট্রাফিক সরাসরি এলে origin কতক্ষণ টিকবে? না টিকলে শুধু সবচেয়ে জরুরি অংশ (চেকআউট, API) বাইপাস করুন, বাকিটা মেইনটেন্যান্স পেজ।
5. ড্রিল: বছরে অন্তত একবার স্টেজিং বা কম ট্রাফিকের সময়ে পুরো প্রক্রিয়া চালিয়ে দেখুন।

আউটেজের সময়:

# 1. Confirm it is the CDN, not you: origin direct is fine, CDN is not
curl -s -o /dev/null -w '%{http_code}\n' https://baytalhikma.org/
curl -s -o /dev/null -w '%{http_code}\n' --connect-to baytalhikma.org:443:198.51.100.10:443 https://baytalhikma.org/

# 2. Open the origin firewall to the public (prepared rule)
ssh origin 'sudo nft -f /etc/nftables.d/public-open.nft'

# 3. Point DNS at origin (or at the second CDN) via the DNS provider API, then watch
dig +short baytalhikma.org @ns1.your-dns-provider.example

আর ফেরার সময় উল্টো ক্রমে: আগে DNS আবার CDN-এ, TTL পার হওয়া পর্যন্ত অপেক্ষা, তারপর origin-এর পাবলিক নিয়ম বন্ধ।

ভেন্ডর লক-ইন

যত বেশি ভেন্ডর-নির্দিষ্ট ফিচার (এজ ফাংশন, KV স্টোর, ইমেজ ট্রান্সফর্ম URL, WAF নিয়মের ভাষা), তত কঠিন অন্য CDN-এ যাওয়া বা দ্বিতীয়টা যোগ করা। এটা খারাপ নয়, একটা দাম। সচেতনভাবে দিন:

• ক্যাশিং স্ট্যান্ডার্ড HTTP হেডারে (Cache-Control, CDN-Cache-Control, Vary, Surrogate-Key যেখানে সমর্থিত)।
• এজ কম্পিউট পাতলা রাখুন: ব্যবসার লজিক origin-এ, এজে শুধু রাউটিং, হেডার আর ছোট রূপান্তর (চ্যাপ্টার ১১)।
• ইমেজ ট্রান্সফর্ম একটা নিজের URL স্কিমের পেছনে, যাতে পরে ভেন্ডর বদলালে শুধু একটা রিরাইট নিয়ম বদলাতে হয়।
• সার্টিফিকেট নিজের নিয়ন্ত্রণে, বা অন্তত জানুন অন্য CDN-এ সার্টিফিকেট কত দ্রুত ইস্যু করা যাবে।

ইতিহাসের বড় CDN আউটেজ

প্রতিটা ঘটনা অপারেটরের নিজের প্রকাশিত পোস্টমর্টেম থেকে (২০২৬ সালের অক্টোবর পর্যন্ত যাচাই করা)। বিস্তারিত মূল লেখায় পড়ুন।

Fastly, ৮ জুন ২০২১

কী ঘটেছিল: UTC ০৯:৪৭-এ Fastly-র নেটওয়ার্কের প্রায় ৮৫% এরর দিতে শুরু করল। কারণ: ১২ মে শুরু হওয়া একটা সফটওয়্যার ডিপ্লয়ে একটা অনাবিষ্কৃত বাগ ছিল, যেটা নির্দিষ্ট পরিস্থিতিতে একজন গ্রাহকের একটা বৈধ কনফিগ বদলে জেগে উঠল। Fastly এক মিনিটের মধ্যে ধরল, আর ৪৯ মিনিটে নেটওয়ার্কের ৯৫% স্বাভাবিক হলো। স্থায়ী ফিক্স সেদিনই পরে ডিপ্লয় হলো। (Fastly)

CDN কেন বড় করে দিল: হাজারো গ্রাহক একই শেয়ার্ড প্ল্যাটফর্মে। একজনের কনফিগ বদল সবার জন্য ট্রিগার হলো। একটা ভুল সেকেন্ডে বৈশ্বিক।

শিক্ষা: একটা বাগ সপ্তাহের পর সপ্তাহ চুপচাপ থাকতে পারে, তাই “ডিপ্লয়ের পর সব ঠিক ছিল” নিরাপত্তার প্রমাণ নয়। আপনার দিকে: একটা CDN-এর ওপর পুরো নির্ভরতা মানে তার প্রতিটা বাগ আপনার আউটেজ। জরুরি বাইপাস প্ল্যান বা দ্বিতীয় CDN।

Cloudflare, ২ জুলাই ২০১৯

কী ঘটেছিল: UTC ১৩:৪২-এ একটা নতুন WAF managed rule প্রয়োগ হলো। নিয়মের একটা regular expression অতিরিক্ত backtracking করত, আর সারা বিশ্বে HTTP/HTTPS সামলানো প্রতিটা CPU কোর প্রায় ১০০%-এ উঠে গেল। গ্রাহকরা 502 পেলেন। নিয়মটা “simulate” মোডে ছিল, মানে কিছু ব্লক করত না, কিন্তু চালাতে তো হতো, তাই CPU খরচ ঠিকই হলো। প্রায় ২৭ মিনিটের ব্যাপক বিঘ্ন; ১৪:০৭-এ WAF বিশ্বব্যাপী বন্ধ করা হলো। (Cloudflare)

CDN কেন বড় করে দিল: WAF নিয়ম নতুন হুমকিতে দ্রুত সাড়া দেওয়ার জন্য কয়েক সেকেন্ডে সারা বিশ্বে পৌঁছে যায়, সফটওয়্যারের মতো ধাপে ধাপে রোলআউট ছিল না। “দ্রুত সুরক্ষা” চ্যানেলটাই “দ্রুত আউটেজ” চ্যানেল হয়ে গেল।

শিক্ষা: কনফিগ আর ডেটাও কোড; সেটাও ধাপে ধাপে রোলআউট আর পারফরম্যান্স টেস্ট চায়। Cloudflare-এর তালিকায় ছিল: নিয়মগুলোর পারফরম্যান্স প্রোফাইলিং, রানটাইম গ্যারান্টি দেওয়া regex ইঞ্জিনে যাওয়া, আর জরুরি অবস্থা ছাড়া নিয়মের ধাপে ধাপে রোলআউট।

Akamai, ২২ জুলাই ২০২১

কী ঘটেছিল: UTC ১৫:৪৫-এর আশেপাশে একটা সফটওয়্যার কনফিগারেশন আপডেট Akamai-এর Secure Edge CDN-এর একটা DNS কম্পোনেন্টে বাগ জাগিয়ে দিল। ফলে অনেক বড় গ্রাহকের সাইট এক ঘণ্টা পর্যন্ত পৌঁছানো যাচ্ছিল না। আপডেট রোলব্যাক করে সেবা ফিরল; Akamai জানিয়েছে এটা সাইবার আক্রমণ ছিল না। পরের রিভিউতে তারা বলেছে, আপডেট-সংক্রান্ত সমস্যা ঠেকানোর সুরক্ষা ব্যবস্থাগুলো প্রয়োজনমতো কাজ করেনি। (Akamai, Akamai)

CDN কেন বড় করে দিল: CDN নিজের DNS দিয়ে ইউজারকে edge-এ পাঠায়। সেই DNS অংশ ভাঙলে edge সার্ভারগুলো সুস্থ থাকলেও কেউ সেখানে পৌঁছাতে পারে না। একটা ছোট কম্পোনেন্ট পুরো ডেলিভারির সামনের দরজা।

শিক্ষা: CDN-এর পথে প্রতিটা লেয়ার (DNS, রাউটিং, TLS, ক্যাশ) একটা আলাদা ব্যর্থতার বিন্দু। সিনথেটিক মনিটরিং পুরো পথ পরীক্ষা করুক, শুধু edge-এর IP-তে HTTP নয়।

Cloudflare, ১৮ নভেম্বর ২০২৫

কী ঘটেছিল: UTC ১১:০৫-এ একটা ClickHouse ডেটাবেসে পারমিশন বদল হলো। এতে Bot Management-এর “feature file” বানানোর একটা কুয়েরি, যেটা ডেটাবেসের নাম দিয়ে ফিল্টার করত না, ডুপ্লিকেট সারি ফেরত দিতে লাগল, আর ফাইলের আকার প্রায় দ্বিগুণ হলো। প্রক্সি সফটওয়্যারে ফিচারের সংখ্যার একটা হার্ড লিমিট ছিল (২০০; স্বাভাবিকভাবে লাগে প্রায় ৬০)। বড় ফাইল সেই লিমিট পার করল, প্রক্সি প্যানিক করল, আর ১১:২০ থেকে ব্যাপক 5xx। ফাইলটা প্রতি পাঁচ মিনিটে নতুন করে বানিয়ে পুরো নেটওয়ার্কে পাঠানো হতো, আর ClickHouse ক্লাস্টার ধীরে ধীরে আপডেট হচ্ছিল, তাই কখনো ভালো ফাইল যেত, কখনো খারাপ: নেটওয়ার্ক সেরে উঠত, আবার পড়ত। এই ওঠানামা প্রথমে ইঞ্জিনিয়ারদের DDoS সন্দেহ করিয়েছিল। ভালো ফাইল বসিয়ে প্রক্সি রিস্টার্টে ~১৪:৩০-এ মূল ট্রাফিক ফিরল, ১৭:০৬-এ সব স্বাভাবিক। (Cloudflare)

CDN কেন বড় করে দিল: একটা অভ্যন্তরীণ, স্বয়ংক্রিয়ভাবে বানানো কনফিগ ফাইলকে “নিজেদের জিনিস, নিরাপদ” ধরা হয়েছিল, তাই ইউজারের ইনপুটের মতো যাচাই হতো না। আর সেটা পাঁচ মিনিট পরপর পুরো নেটওয়ার্কে যেত।

শিক্ষা: অভ্যন্তরীণ জেনারেট করা কনফিগকেও বাইরের ইনপুটের মতো যাচাই করুন; লিমিট পার হলে প্যানিক না করে আগের ভালো কপিতে থাকুন; প্রতিটা ফিচারের বিশ্বব্যাপী “kill switch” রাখুন। Cloudflare-এর নিজের প্রতিকারের তালিকাও এগুলোই।

মাস্টারি চেকলিস্ট

ক্যাশিং

• স্ট্যাটিক ফাইল হ্যাশসহ নামে, max-age=31536000, immutable
• HTML আর API-এর ক্যাশিং নিয়ম স্পষ্ট, origin-এর হেডারে লেখা
• প্রতিটা ব্যক্তিগত রেসপন্সে private বা no-store, আর এর একটা স্বয়ংক্রিয় টেস্ট
• ক্যাশ কী থেকে ট্র্যাকিং প্যারামিটার বাদ; Vary শুধু যা সত্যিই দরকার
• stale-while-revalidate / stale-if-error যেখানে যুক্তিসঙ্গত
• origin shield চালু; hit ratio আর byte hit ratio দুইটাই মাপা হয়

পরিবর্তন

• CDN কনফিগ git-এ, PR রিভিউ সহ
• স্টেজিং হোস্টনেম, প্রয়োগের পর স্মোক টেস্ট
• পার্জ ডিপ্লয় পাইপলাইনে স্বয়ংক্রিয়; purge-all শুধু জরুরি অবস্থায়

সিকিউরিটি

• origin শুধু CDN-এর IP বা authenticated origin pull থেকে রিকোয়েস্ট নেয়
• edge থেকে origin-এ TLS যাচাই সহ (“strict”)
• WAF নিয়ম প্রথমে log মোডে, তারপর block
• web cache poisoning আর cache deception নিয়ে একবার রিভিউ (চ্যাপ্টার ১২)

অবজারভেবিলিটি

• কয়েক দেশ থেকে সিনথেটিক চেক, অঞ্চল অনুযায়ী আলাদা SLO
• RUM দিয়ে আসল ইউজারের TTFB
• CDN লগ নিজের স্টোরেজে, PoP অনুযায়ী 5xx অ্যালার্ট
• edge আর origin দুই জায়গার সার্টিফিকেট এক্সপায়ারি মনিটর

টিকে থাকা

• DNS CDN থেকে আলাদা, বা CDN ডাউন হলেও বদলানো যায়
• CDN-মুখী রেকর্ডের TTL ছোট
• লিখিত বাইপাস রানবুক, বছরে অন্তত একবার ড্রিল
• মাল্টি-CDN হলে: দুটোতেই সবসময় কিছু ট্রাফিক, আর প্যারিটি টেস্ট CI-তে

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত করুন	সমাধান
ফেইলওভারের পর সাইট অন্যরকম আচরণ করছে	দুই CDN-এর হোস্টনেমে একই URL চালিয়ে হেডার তুলনা	ক্যাশ নিয়ম origin-এর হেডারে আনুন; CI-তে প্যারিটি টেস্ট
দ্বিতীয় CDN-এ সুইচ করতেই origin চাপে	origin-এর রিকোয়েস্ট রেট, দ্বিতীয় CDN-এর hit ratio	দ্বিতীয় CDN-কে সবসময় কিছু ট্রাফিক দিয়ে গরম রাখুন; shield
weighted ভাগ ৭০/৩০ নয়, অনেক বেঁকে আছে	CDN অনুযায়ী রিকোয়েস্ট সংখ্যা	বড় resolver-এর ক্যাশের কারণে স্বাভাবিক; নিখুঁত ভাগ চাইলে RUM বা HTTP-স্তরের স্টিয়ারিং
CDN ডাউন, কিন্তু DNS বদলানো যাচ্ছে না	DNS কোথায় হোস্ট করা	DNS আলাদা প্রোভাইডারে সরান (শান্ত সময়ে)
DNS বদলেছি, কিন্তু ইউজার এখনো ডাউন CDN-এ	রেকর্ডের পুরনো TTL কত ছিল	ছোট TTL আগে থেকে রাখুন; এখন অপেক্ষা ছাড়া উপায় নেই
বিল হঠাৎ বেড়েছে	CDN অ্যানালিটিক্সে শীর্ষ URL, দেশ, ব্যবহারকারী এজেন্ট	বট/হটলিংক আটকান; বড় ফাইল অপ্টিমাইজ; hit ratio কমেছে কিনা দেখুন
hit ratio ভালো, কিন্তু origin egress বেশি	byte hit ratio	বড় ফাইলের ক্যাশিং (slice/range), লম্বা TTL
গড় এরর রেট কম, কিন্তু এক দেশের ইউজার অভিযোগ করছে	PoP বা অঞ্চল অনুযায়ী 5xx আর TTFB	অঞ্চলভিত্তিক SLO আর অ্যালার্ট
কনফিগ বদলের পর হঠাৎ এরর	CDN-এর অডিট লগ, git-এর সর্বশেষ PR	রোলব্যাক আগে, তদন্ত পরে; ধাপে ধাপে রোলআউট চালু করুন

মূল শিক্ষা

1. একক CDN মানে তার প্রতিটা আউটেজ আপনার আউটেজ। অন্তত একটা লিখিত, পরীক্ষিত বাইপাস প্ল্যান রাখুন; দাম আর ঝুঁকি বেশি হলে মাল্টি-CDN।
2. মাল্টি-CDN-এর আসল খরচ কনফিগ প্যারিটি। ক্যাশিং নিয়ম যত বেশি origin-এর স্ট্যান্ডার্ড হেডারে, প্যারিটি তত সহজ।
3. খরচের বড় চালক origin-এর egress আর byte hit ratio, শুধু CDN-এর প্রতি GB দাম নয়।
4. CDN কনফিগ কোড: git, রিভিউ, স্টেজিং, ধাপে ধাপে রোলআউট, প্রয়োগের পর স্মোক টেস্ট।
5. অঞ্চল আর PoP অনুযায়ী মাপুন। বৈশ্বিক গড় একটা দেশের আউটেজ লুকিয়ে রাখে।
6. বাইপাসের পূর্বশর্ত আউটেজের আগেই তৈরি করতে হয়: আলাদা DNS, ছোট TTL, origin-এর পাবলিক প্রস্তুতি, ক্ষমতার হিসাব।
7. বড় আউটেজের প্রায় সবগুলোর মূলে একটা দ্রুত, বিশ্বব্যাপী বদল। নিজের কনফিগেও ধাপে ধাপে রোলআউট আর এক ক্লিকের রোলব্যাক রাখুন।