Capacity Estimation လေ့ကျင့်ခန်း

နားလည်ထားရမယ့် အချက်

Back-of-envelope capacity estimation ဆိုတာက requirement တစ်ခုကို order-of-magnitude number အဖြစ် ပြောင်းပေးပြီး ဒီဇိုင်းအတွက် အခြေခံအဖြစ်သုံးနိုင်တဲ့ discipline တစ်ခုပါ။ အဆင့်လေးဆင့်နဲ့ လုပ်ဆောင်ပါတယ်။ ပထမဆုံး assumption တစ်ခုတည်းကို anchor အဖြစ်ယူပါ — DAU ကိန်းဂဏန်း၊ average payload size လိုမျိုးပေါ့ — unknown အများကြီးကို တစ်ပြိုင်နက် မတီထွင်ဘဲနဲ့။ ဒုတိယအနေနဲ့ request rate ကို daily volume ကို တစ်ရက်ရှိ seconds အရေအတွက် (~86,400) နဲ့စားပြီး peak factor နဲ့ မြှောက်ပါ၊ traffic ဟာ study hours တွေအနီးမှာ စုစည်းနေတတ်ပြီး တစ်နေ့တာလျှင် တန်းညီစွာ ဖြန့်ကျက်နေတာမဟုတ်လို့ပါ — peak QPS ဟာ daily average ရဲ့ 2-3 ဆလောက် ဖြစ်လေ့ရှိပြီး၊ average value တစ်ခုတည်းအတွက်ပဲ provision လုပ်ရင် peak-hour outage တွေဖြစ်နိုင်ပါတယ်။ တတိယအနေနဲ့ storage ကို row count ကို average row size နဲ့မြှောက်ပြီး၊ ပစ္စည်းအမှန်တကယ်လိုအပ်တဲ့ retention period အတိုင်း project လုပ်ပါ၊ ကြုံရာကြုံကြေး ရွေးလိုက်တဲ့ period မဟုတ်ဘဲ။ စတုတ္ထအနေနဲ့ ဂဏန်းတွေကို power of 10 တွေ (ဒါမှမဟုတ် 600၊ 2,000 လိုမျိုး clean number တွေ) အဖြစ် ရဲရဲကြီး round ချပါ — အကြောင်းက ဒီ exercise တစ်ခုလုံးဟာ 100x လွဲနေတဲ့ design ကို ဖမ်းမိဖို့ ရည်ရွယ်တာဖြစ်ပြီး byte နဲ့ တိတိကျကျ ဂဏန်းထုတ်ဖို့ မဟုတ်လို့ပါ။ output တိုင်းကို sanity check တစ်ခုအနေနဲ့ပဲ သတ်မှတ်ပါ၊ capacity-planning contract အနေနဲ့ လုံးဝ မယူပါနဲ့။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ရဲ့ analytics pipeline ကို audit လုပ်နေတယ်လို့ ယူဆပါ — engineer တစ်ယောက်က lesson-view event database ကို 'တစ်ရက်ကို event တစ်သန်းလောက်' ဆိုပြီး work ကို မပြသဘဲ size ချထားခဲ့ပါတယ်။ design ကို review လုပ်တယ်ဆိုတာ ဖော်ပြထားတဲ့ assumption တွေ — DAU, learner တစ်ယောက်ချင်းရဲ့ views, event size — ကနေ ဂဏန်းကို ပြန်ဆင်း derive လုပ်ရမှာဖြစ်ပြီး၊ engineer ရဲ့ provisioned QPS က peak traffic ကို ထည့်တွက်ထားလား ဒါမှမဟုတ် flat daily average ကိုပဲ ထည့်တွက်ထားလား၊ storage sizing အတွက်သုံးထားတဲ့ retention period က product က တကယ်လိုအပ်တာနဲ့ ကိုက်ညီလား (raw event ကို 3 နှစ်ထားမလား၊ ဒါမှမဟုတ် 90 ရက်ကျော်ရင် aggregated summary လုပ်မလား) စစ်ဆေးရမှာဖြစ်ပါတယ်။ input တွေကနေ ပြန် reconstruct မလုပ်နိုင်တဲ့ capacity estimate ဟာ design decision မဟုတ်ပါဘူး — design decision ရဲ့ အဝတ်ဝတ်ထားတဲ့ guess တစ်ခုသာ ဖြစ်ပါတယ်။

• assumption တစ်ခုတည်းကို anchor အဖြစ်ယူပြီး ကျန်တာကို derive လုပ်ပါ — unknown အများကြီးကို တစ်ပြိုင်နက် မတီထွင်ပါနဲ့။
• traffic ဟာ peak hours တွေအနီးမှာ စုစည်းတတ်လို့ peak QPS ဟာ daily average ရဲ့ 2-3 ဆ ဖြစ်လေ့ရှိတယ်။
• power of 10 (သို့) clean number တွေအဖြစ် ရဲရဲကြီး round ချပါ — ရည်ရွယ်ချက်က 100x design error ကို ဖမ်းမိဖို့ဖြစ်ပြီး byte level precision မဟုတ်ဘူး။

အတူတူ စမ်းရေးကြည့်မယ်

Assumption: 10,000,000 daily active learners (DAU)
Each learner views ~5 lessons/day
Each "lesson view" event ~200 bytes (event id, user id, lesson id, timestamp, metadata)

Step 1 - Daily event volume
10,000,000 DAU x 5 views/day = 50,000,000 events/day  (~5 x 10^7)

Step 2 - Average requests per second
50,000,000 events / 86,400 seconds/day ~= 578 events/sec
Round to a clean number: ~600 QPS average

Step 3 - Peak QPS
Traffic isn't flat across 24 hours - assume peak is 3x average (evening study rush)
600 QPS x 3 ~= 1,800 QPS peak
Round: ~2,000 QPS peak - this is the number the ingestion service must be provisioned for

Step 4 - Daily storage volume
50,000,000 events/day x 200 bytes/event = 10,000,000,000 bytes/day
= 10 GB/day

Step 5 - Storage projected over 1 year retention
10 GB/day x 365 days ~= 3,650 GB ~= ~3.65 TB/year
Round: ~4 TB/year - plan capacity around this order of magnitude, not the exact figure

မှန်ကန်တဲ့ order-of-magnitude အဖြေက event ၅၀ သန်း/တစ်ရက်၊ average QPS ~600 လောက်၊ peak QPS ~1,800-2,000 လောက်နဲ့ တစ်နှစ် retention အတွက် raw event storage ~3.65TB (~4TB) လောက် ဖြစ်ပါတယ်။

Wikipedia — Fermi problem — System Design