Managed database — replica, failover, backup আর connection

১ · Managed মানে কী — কে কী সামলায়

ধরুন আপনি নিজের বাড়িতে থাকেন। পানির পাম্প, জেনারেটর, লিফট, ছাদের ট্যাংক, সব আপনাকেই দেখতে হয়। এবার ধরুন একটি ভালো ফ্ল্যাটে উঠলেন, যেখানে মাসে সার্ভিস চার্জ দেন। কেয়ারটেকার পাম্প ঠিক করেন, জেনারেটর চালান। কিন্তু ঘরে কী রাখবেন, কতজন অতিথি ডাকবেন, সেটি তিনি ঠিক করেন না। আর আপনি নিজের ঘরের আলমারি ভেঙে ফেললে তিনি কিছুই করতে পারবেন না।

Managed database ঠিক এমন। একে DBaaS (Database as a Service) বলে। Provider একটি database engine, যেমন PostgreSQL বা MySQL, আপনার জন্য চালায়। আপনি VM, OS বা engine install নিয়ে ভাবেন না। আপনি পান একটি endpoint, মানে একটি ঠিকানা, যেখানে app সংযোগ করে।

দাম হিসেবে আপনি কিছু ক্ষমতা ছাড়েন। সাধারণত server-এ SSH করা যায় না, পূর্ণ superuser মেলে না, আর সব extension চলে না। ধীর query managed হলেই দ্রুত হয় না। Index না থাকলে সে আগের মতোই ধীর থাকবে। Query tuning-এর গভীর আলোচনা আছে DBMS কোর্সের performance tuning পর্বে.

তিন provider-এ একই ধারণা

নাম আর সুবিধা সময়ের সাথে বদলায়, তাই provider-এর বর্তমান নথি দেখে নিন। এই পর্বের ধারণা তিন জায়গাতেই খাটে।

Storage আলাদা করা নকশা (ধারণা হিসেবে)

সাধারণ নকশায় প্রতিটি কপির নিজের disk থাকে, আর ডেটা কপি থেকে কপিতে যায়। Aurora-ধরনের নকশায় compute আর storage ভাগ করা হয়। একটি shared storage layer কয়েকটি zone জুড়ে ডেটার কপি রাখে, আর primary ও replica সবাই সেখান থেকে পড়ে। ফলে নতুন replica দ্রুত যোগ হয়, lag সাধারণত কম থাকে, failover-ও প্রায়ই ছোট হয়। তবে এগুলো সব পণ্যে সমান নয়। I/O-এর বিল, engine-এর সামঞ্জস্য আর lock-in আলাদা করে যাচাই করতে হয়।

২ · Multi-AZ standby বনাম read replica

এই পর্বের সবচেয়ে সাধারণ ভুল ধারণা হলো, “আমার তো replica আছে, তাই HA হয়ে গেছে।” HA মানে high availability, অর্থাৎ বিকল হলেও সেবা চালু থাকা। দুটি জিনিসের চেহারা এক, কাজ আলাদা।

এখানে Multi-AZ মানে একই region-এর আলাদা availability zone-এ কপি রাখা। বড় বিপদের পর সেবা ফেরানোকে বলে DR (disaster recovery). এই কাজে ভিন্ন region-এ রাখা কপিকে বলে cross-region replica. সেটি প্রায় সবসময় asynchronous, কারণ দূরত্বের কারণে synchronous লেখা খুব ধীর হয়ে যায়।

কিছু পণ্যে দুটি ভূমিকা একসাথে মেলে। যেমন কোনো কোনো cluster ধরনে standby পড়ার কাজও নেয়। তবু প্রশ্ন একই থাকে: এই কপিটি কোন বিপদের জন্য? Replication-এর তত্ত্ব, মানে log, quorum আর semi-synchronous আচরণ, আছে System Design-এর replication পর্বে আর DBMS-এর backup ও replication পর্বে.

৩ · Failover — কী ঘটে, আর app কী দেখে

Failover শুধু “standby চালু হলো” নয়। এটি কয়েকটি ধাপের একটি ক্রম, আর প্রতিটি ধাপের সময় লাগে। প্রথমে একটি লেখা কীভাবে দুই zone-এ পৌঁছায় দেখুন, তারপর primary-র zone বিকল হলে কী ঘটে। WAL হলো write-ahead log, যেখানে প্রতিটি পরিবর্তন আগে লেখা হয়। LSN হলো সেই log-এর অবস্থানের নম্বর। এখানে LSN সহজ করে ছোট সংখ্যায় দেখানো হয়েছে, আর সব সময় ধরে নেওয়া।

DNS endpoint কেন, আর app-এর দায় কী

অনেক সেবায়, যেমন RDS-এ, endpoint হলো একটি DNS নাম। Failover-এ নামটি নতুন IP দেখায়। কিছু সেবায় ঠিকানা একই থাকে, IP-টিই নতুন যন্ত্রে সরে যায় (Cloud SQL-এর HA এমন বলে নথিতে উল্লেখ আছে)। দুই ক্ষেত্রেই পুরোনো TCP connection মরে যায়, তাই reconnect app-কেই করতে হবে।

• DNS cache: App বা runtime যদি পুরোনো IP ধরে রাখে, database চালু হলেও app মরা ঠিকানায় যেতে থাকে। কোনো কোনো runtime-এর default cache TTL মানে না।
• Pool-এর মরা connection: Pool থেকে নেওয়ার আগে connection যাচাই করতে হবে, আর সর্বোচ্চ আয়ু বেঁধে দিতে হবে।
• Connect timeout: মরা host অনেক সময় উত্তরই দেয় না। ছোট timeout না থাকলে একেকটি চেষ্টায় অনেকক্ষণ আটকে থাকবেন।
• লেখার retry: উত্তর না পাওয়া লেখা হয়তো commit হয়েছে। তাই idempotency key ছাড়া লেখা retry করবেন না।

কত সময় লাগে? Instance-ধরনের Multi-AZ-এ provider-এর নথি সাধারণত এক-দুই মিনিটের কথা বলে। Cluster বা shared storage নকশায় আরও কম হতে পারে। আবার দীর্ঘ transaction চললে বা crash recovery-তে অনেক কাজ জমে থাকলে বেশি লাগতে পারে। নিজের workload-এ পরীক্ষা করে মাপুন। অনেক সেবায় “force failover” বা reboot-with-failover নামে পরীক্ষার সুযোগ আছে, যা staging-এ চালানো যায়।

Simulator — retry সেটিং কত অনুরোধ বাঁচায়

ধরে নিই টের পেতে ২০ সেকেন্ড, promote হতে ৩০ সেকেন্ড, DNS TTL ১০ সেকেন্ড, মোট ৬০ সেকেন্ড। প্রতি সেকেন্ডে ১০০ অনুরোধ আসে। মরা host-এ একটি চেষ্টা ৩ সেকেন্ড আটকে থাকে। budget হলো একটি অনুরোধের জন্য মোট সর্বোচ্চ অপেক্ষা। Exponential backoff মানে প্রতিবার বিরতি দ্বিগুণ করা, আর jitter মানে সেই বিরতিতে এলোমেলো অংশ মেশানো।

// Failover: how many requests fail under each client retry setting? All numbers ASSUMED.
function mulberry32(a){return()=>{a=a+0x6D2B79F5|0;let t=Math.imul(a^a>>>15,1|a);
  t=t+Math.imul(t^t>>>7,61|t)^t;return((t^t>>>14)>>>0)/4294967296}}
const DETECT = 20, PROMOTE = 30, DNS_TTL = 10;  // seconds of the failover
const RATE = 100, TIMEOUT = 3;                  // req/s; seconds one dead attempt hangs
function run(name, o) {
  const rnd = mulberry32(22);
  const up = DETECT + PROMOTE + (o.dns ?? DNS_TTL);  // this client reaches the new primary
  let failed = 0, worst = 0;
  const attempts = {};
  for (let i = 0; i < 120 * RATE; i++) {
    const born = i / RATE;
    let now = born, ok = false;
    for (let a = 0; a <= o.retries; a++) {
      const sec = Math.floor(now);
      attempts[sec] = (attempts[sec] || 0) + 1;
      if (now >= up) { ok = true; break; }
      let wait = Math.min(o.base * 2 ** a, o.cap);
      if (o.jitter) wait *= rnd();
      now += TIMEOUT + wait;
      if (now - born > o.budget) break;         // the caller gave up
    }
    if (ok) worst = Math.max(worst, now - born); else failed++;
  }
  const peak = Math.max(...Object.values(attempts));
  console.log(name.padEnd(26) + String(failed).padStart(6) +
    worst.toFixed(1).padStart(8) + String(peak).padStart(7));
}
console.log("policy".padEnd(26) + "failed maxWait peak/s");
run("no retry",               { retries: 0, base: 0, cap: 0, budget: 15 });
run("3 retries, fixed 1s",    { retries: 3, base: 1, cap: 1, budget: 15 });
run("5 retries, exp",         { retries: 5, base: 1, cap: 8, budget: 15 });
run("5 retries, exp+jitter",  { retries: 5, base: 1, cap: 8, jitter: true, budget: 15 });
run("job: 12 retries, 120s",  { retries: 12, base: 1, cap: 8, jitter: true, budget: 120 });
run("exp+jitter, DNS held 60", { retries: 5, base: 1, cap: 8, jitter: true, budget: 15, dns: 60 });

policy                    failed maxWait peak/s
no retry                    6000     0.0    100
3 retries, fixed 1s         4800    12.0    400
5 retries, exp              5100     9.0    300
5 retries, exp+jitter       4746    15.0    431
job: 12 retries, 120s          7    69.7   1068
exp+jitter, DNS held 60     9748    15.0    431

৪ · Replica lag আর “নিজের লেখা না দেখা”

আপনি profile-এর ছবি বদলালেন, পাতা reload করলেন, আগের ছবিই দেখলেন। আবার reload করলেন, এবার নতুন ছবি। কেউ কেউ ভাবেন bug. আসলে এটি replication lag: লেখা গেছে primary-তে, আর পড়া এসেছে একটু পিছিয়ে থাকা replica থেকে। এমন পুরোনো উত্তরকে বলে stale read.

যা নিজে লিখেছেন তা অবশ্যই দেখতে পাওয়ার নিশ্চয়তাকে বলে read-your-writes. নিচের simulator-এ ২০ সেকেন্ড ধরে লেখা ৩,০০০/s হয়, অথচ replica প্রতি সেকেন্ডে ২,০০০-এর বেশি প্রয়োগ করতে পারে না। ১০০ জন ব্যবহারকারী প্রতি সেকেন্ডে কিছু লেখেন, তারপর ০.২ আর ৬ সেকেন্ড পরে পড়েন।

// Replica lag during a write burst, and four ways to route reads. All numbers ASSUMED.
const APPLY = 2000, NET = 0.05;        // replica applies 2000 writes/s; 50 ms network
const lag = [];                        // lag[t] = seconds behind at second t
let backlog = 0;
console.log("  t  writes  backlog  lag(s)");
for (let t = 0; t < 70; t++) {
  const writes = (t >= 10 && t < 30) ? 3000 : 500;  // a 20-second burst
  backlog = Math.max(0, backlog + writes - APPLY);
  lag[t] = backlog / APPLY + NET;
  if (t % 10 === 9) {
    console.log(String(t).padStart(3) + String(writes).padStart(8) +
      String(backlog).padStart(9) + lag[t].toFixed(2).padStart(8));
  }
}
// 100 users each second save something, then read it twice: after 0.2 s and after 6 s.
const USERS = 100, READS = [0.2, 6], STICKY = 5;
function route(toPrimary) {
  let bad = 0, sent = 0;
  for (let t = 0; t < 60; t++) for (const d of READS) {
    const l = lag[Math.floor(t + d)];
    if (toPrimary(d, l)) sent += USERS;
    else if (l > d) bad += USERS;
  }
  return String(bad).padStart(6) + String(sent).padStart(10);
}
console.log("routing".padEnd(30) + " stale toPrimary");
console.log("all reads to replica".padEnd(30) + route(() => false));
console.log("primary for 5 s after write".padEnd(30) + route(d => d <= STICKY));
console.log("replica only if caught up".padEnd(30) + route((d, l) => l > d));
console.log("all reads to primary".padEnd(30) + route(() => true));

  t  writes  backlog  lag(s)
  9     500        0    0.05
 19    3000    10000    5.05
 29    3000    20000   10.05
 39     500     5000    2.55
 49     500        0    0.05
 59     500        0    0.05
 69     500        0    0.05
routing                        stale toPrimary
all reads to replica            4700         0
primary for 5 s after write     1400      6000
replica only if caught up          0      4700
all reads to primary               0     12000

• Lag-কে metric বানান: Replica-প্রতি lag দেখুন, গড় নয়, আর alarm বসান (পরের অংশে)।
• সব read সমান নয়: Dashboard-এর গ্রাফ কয়েক সেকেন্ড পুরোনো হলে চলে। পেমেন্টের ফল বা ব্যালান্স সাধারণত চলে না।
• Replica ছোট রাখবেন না: ছোট replica লেখা প্রয়োগে পিছিয়ে পড়ে। Primary-র সমান আকার দিয়ে শুরু করা নিরাপদ।
• দীর্ঘ report query: Replica-তে লম্বা query চললে replay আটকে lag বাড়তে পারে, বা query বাতিল হতে পারে। PostgreSQL-এ এটি একটি পরিচিত trade-off.

Monotonic read-এর মতো অন্য anomaly আর তাদের সমাধান আছে System Design-এর replication পর্বে.

৫ · Backup, PITR আর snapshot

Standby আর replica যন্ত্রের বিপদ থেকে বাঁচায়। মানুষের ভুল থেকে বাঁচায় না, কারণ ভুল DELETE-ও মুহূর্তে সব কপিতে পৌঁছে যায়। এখানেই backup-এর কাজ।

PITR-এর ধারণা সহজ: একটি পুরোনো ছবি থেকে শুরু করে log-এর প্রতিটি পরিবর্তন আবার চালানো, আর ঠিক কাঙ্ক্ষিত মুহূর্তে থামা। Log সাধারণত কয়েক মিনিট পরপর জমা হয়, তাই সর্বশেষ restorable সময় বর্তমানের কয়েক মিনিট পেছনে থাকতে পারে। আরও একটি গুরুত্বপূর্ণ কথা: অনেক সেবায় PITR পুরোনো database বদলায় না, একটি নতুন instance বানায়। তাই endpoint বদলাবে।

নিচের ঘটনাটি কাল্পনিক। একটি বাজার অ্যাপে ভোর ২টায় snapshot হয়, আর অর্ডার আসে মিনিটে ৩টি। দুপুরে একজন অপারেটর staging ভেবে production-এ query চালালেন।

৬ · Maintenance window আর major version upgrade

Patch provider লাগায়, কিন্তু কখন লাগাবে সেটি আপনি বলেন। সপ্তাহের যে সময়টি ঠিক করা থাকে, তাকে বলে maintenance window. বাংলাদেশি ব্যবহারকারীর জন্য রাত ৩টা-৪টার মতো শান্ত সময় সাধারণত ভালো। অনেক সেবায় window দিতে হয় UTC-তে, তাই বাংলাদেশ সময় থেকে ৬ ঘণ্টা বাদ দিন: রাত ৩টা মানে আগের দিনের 21:00 UTC.

OS-এর patch-এ Multi-AZ-এ provider সাধারণত আগে standby-কে patch করে, failover করে, তারপর পুরোনো primary-কে patch করে। তাই “maintenance” মানে প্রায়ই একটি ছোট failover. তবে engine version বদলালে অনেক সময় দুই কপি একসাথে upgrade হয়, যেমন RDS-এর instance-ধরনের Multi-AZ-এ। তখন কয়েক মিনিট বিভ্রাট হতে পারে, তাই নিজের সেবার নথি দেখে নিন। ওপরের সব retry-র হিসাব এখানেও খাটে।

Major upgrade-এর জন্য নিরাপদ ক্রম:

1. Snapshot থেকে একটি কপি বানিয়ে সেখানে upgrade করে সময় মাপা।
2. Extension আর driver-এর সামঞ্জস্য দেখা।
3. আসল query-গুলো চালিয়ে plan মেলানো, কারণ নতুন planner ভিন্ন পথ নিতে পারে।
4. Upgrade-এর পর statistics আবার তৈরি করা (PostgreSQL-এ ANALYZE).
5. সম্ভব হলে blue-green upgrade: নতুন version-এর একটি কপি replication দিয়ে সমান রাখা, তারপর অল্প সময়ে switch করা।

৭ · Connection — যে সীমা সবার আগে ফুরায়

প্রতিটি database connection-এর দাম আছে। PostgreSQL প্রতিটি connection-এর জন্য আলাদা OS process চালায়, তাই memory আর CPU দুটোই খরচ হয়। নতুন connection খুলতে TCP, TLS আর authentication লাগে, যা একটি সাধারণ query-র চেয়ে অনেক ব্যয়বহুল। তাই database-এ max_connections নামে একটি সীমা থাকে। সাধারণ PostgreSQL-এ default ১০০, আর managed সেবায় এটি সাধারণত instance-এর memory থেকে হিসাব হয়। কিছু slot admin, replication আর monitoring-এর জন্য সংরক্ষিত থাকে।

মূল হিসাব একটিই:

আর সত্যিই কতটি connection ব্যস্ত, সেটি বলে Little's law: ব্যস্ত connection = প্রতি সেকেন্ডে query × একটি query-র সময়। প্রতি instance সেকেন্ডে ১০০ অনুরোধ, প্রতি অনুরোধে ৩টি query, প্রতিটি ১০ ms হলে গড়ে ১০০ × ৩ × ০.০১ = ৩টি connection ব্যস্ত। Pool ২০ হলে বাকি ১৭টি শুধু বসে থেকে memory খায়।

// Connections: app instances x pool size against max_connections. All numbers ASSUMED.
const MAX_CONN = 500, RESERVED = 20;      // slots kept for admin, replication, monitoring
const USABLE = MAX_CONN - RESERVED;
const INST_RPS = 100, QUERIES = 3, QUERY_S = 0.01;  // per instance, per request
const FN_RPS = 10;                        // one function copy: 10 requests per second
const verdict = n => n <= USABLE ? "ok" : "REJECT " + (n - USABLE);

// Little's law: connections truly busy = arrival rate x time held
const busy = INST_RPS * QUERIES * QUERY_S;
console.log("usable slots =", USABLE, "| busy per instance =", busy);

console.log("instances  pool  wanted  verdict");
for (const [inst, pool] of [[10, 20], [20, 20], [30, 20], [40, 20], [40, 12]]) {
  console.log(String(inst).padStart(9) + String(pool).padStart(6) +
    String(inst * pool).padStart(8) + "  " + verdict(inst * pool));
}
console.log("largest safe pool at 40 instances =", Math.floor(USABLE / 40));

// A proxy: many client connections share a few server connections.
const SERVER_CONN = 150;
console.log("proxy: 800 client conns ->", SERVER_CONN, "server conns; busy", 40 * busy);

// Serverless: every running copy wants its own connection when there is no proxy.
const fnBusy = FN_RPS * QUERIES * QUERY_S;
console.log("functions  direct      busy  via proxy");
for (const fn of [100, 480, 1000, 3000]) {
  const b = Math.round(fn * fnBusy);
  console.log(String(fn).padStart(9) + "  " + verdict(fn).padEnd(11) +
    String(b).padStart(4) + "  " + (b <= SERVER_CONN ? "ok" : "queues"));
}

usable slots = 480 | busy per instance = 3
instances  pool  wanted  verdict
       10    20     200  ok
       20    20     400  ok
       30    20     600  REJECT 120
       40    20     800  REJECT 320
       40    12     480  ok
largest safe pool at 40 instances = 12
proxy: 800 client conns -> 150 server conns; busy 120
functions  direct      busy  via proxy
      100  ok           30  ok
      480  ok          144  ok
     1000  REJECT 520  300  queues
     3000  REJECT 2520 900  queues

Pool তিন জায়গায় থাকতে পারে

• App-এর ভেতরে: যেমন HikariCP, SQLAlchemy-র pool. সহজ, কিন্তু প্রতিটি instance-এর নিজের pool, তাই মোট সংখ্যা instance-এর সাথে বাড়ে।
• মাঝখানের proxy: PgBouncer বা database proxy, যেমন RDS Proxy. অনেক client, অল্প server connection.
• দুটোই: App-এ ছোট pool, মাঝে proxy. বড় সিস্টেমে এটি সাধারণ।

[databases]
appdb = host=db.internal.example port=5432 dbname=appdb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
default_pool_size = 150
max_client_conn = 2000
server_idle_timeout = 300

এখানে pool_mode = transaction মানে transaction pooling: একটি server connection শুধু এক transaction-এর জন্য ধার দেওয়া হয়। এতে সবচেয়ে বেশি ভাগাভাগি হয়, তবে session-এর স্মৃতি থাকে না। SET, session-এর advisory lock আর LISTEN ঠিকমতো চলে না, আর prepared statement version-ভেদে সমস্যা করে। RDS Proxy-তে একই ধরনের session-অবস্থা দেখলে connection আটকে যায়, যাকে বলে pinning. তখন ভাগাভাগির লাভ কমে। উদাহরণের listen_addr চলবে শুধু private network-এ, আর সামনে firewall থাকতে হবে।

Connection storm

এবার আসল বিপদ। Connection storm মানে অল্প সময়ে একঝাঁক নতুন connection-এর চেষ্টা। সাধারণত autoscaling, deployment, failover বা serverless function-এর ঝড়ে এটি ঘটে। ধরি max_connections ৫০০, সংরক্ষিত ২০, প্রতিটি instance চালু হয়েই ২০টি connection খোলে। সংখ্যাগুলো ধরে নেওয়া।

একই নিয়ম আরও দুই জায়গায় খাটে। Rolling deployment-এ পুরোনো আর নতুন instance একসাথে থাকে, তাই max-এর সাথে surge যোগ করে হিসাব করবেন। আর serverless function-এ প্রতিটি চলমান কপি আলাদা, তাই ভিড়ে কয়েকশো কপি একসাথে connection চাইতে পারে। সেখানে proxy আর function-এর concurrency সীমা, দুটোই লাগে। Function-এর দিকটি থাকছে পর্ব ৬৯ · Serverless function-এ।

৮ · Sizing, storage আর monitoring

Instance বাছার সময় CPU-র আগে memory দেখুন। Database-এর গতি অনেকটাই নির্ভর করে ব্যবহৃত ডেটা memory-তে থাকে কি না, তার ওপর। Disk থেকে পড়া memory-র চেয়ে অনেক ধীর। শুরুতে অনুমান করে ছোট আকার নিন, এক-দুই সপ্তাহ মাপুন, তারপর rightsizing করুন। Burstable ধরনের instance production-এ সতর্কভাবে ব্যবহার করুন, কারণ credit ফুরালে হঠাৎ ধীর হয়ে যায় (পর্ব ১৫)।

Storage autoscaling: Disk প্রায় ভরে গেলে storage নিজে থেকে বাড়ে। Disk ভরে যাওয়া database-এর জন্য ভয়ংকর, কারণ লেখা থেমে যেতে পারে। তাই এটি চালু রাখা ভালো, তবে সর্বোচ্চ সীমা দিন। অনেক সেবায় storage কমানো যায় না, আর দুটি বৃদ্ধির মাঝে নির্দিষ্ট বিরতি থাকে। তাই হঠাৎ চাপে এটি একা যথেষ্ট নয়। ৮০% ভরলে alarm বসান। একটি ছোট হিসাব: ৫০০ GB-র ৪০০ GB ভরা, দিনে ৫ GB বাড়ছে। তাহলে খালি ১০০ GB চলবে ১০০ ÷ ৫ = ২০ দিন।

মনে রাখবেন, CPU বেশি মানেই বড় instance নয়। প্রায়ই একটি অনুপস্থিত index-ই আসল কারণ। Metric-এর মধ্যে সম্পর্ক দেখুন: connection বাড়ল, তারপর CPU, তারপর latency, এই ক্রম storm-এর চিহ্ন।

-- how many connections, and what are they doing?
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- on the primary: how far behind is each replica?
SELECT application_name, state, replay_lag FROM pg_stat_replication;

SHOW max_connections;

৯ · Private network আর self-managed বনাম managed খরচ

Internet-এ database নয়

Database-এর সরাসরি internet ঠিকানা থাকা উচিত নয়। Public endpoint বন্ধ রাখুন, আর instance রাখুন VPC-র private subnet-এ। Security group-এ শুধু app-এর security group থেকে database port খুলুন, কখনোই 0.0.0.0/0 নয়। Admin কাজের জন্য bastion বা session manager ব্যবহার করুন (পর্ব ১২)। সংযোগে TLS, disk-এ encryption, আর password কোডে নয়, secret manager-এ (পর্ব ৩৩)। Subnet-এর নকশা থাকছে পর্ব ২৫ · VPC আর subnet-এ, আর security group-এর গভীর আলোচনা পর্ব ২৭-এ।

নিচের কমান্ডটি একটি AWS উদাহরণ, যেখানে এই পর্বের সিদ্ধান্তগুলো একসাথে দেখা যায়। অন্য provider-এ flag-এর নাম আলাদা, ধারণা একই। এটি চালানো জরুরি নয়। চালালে টাকা লাগতে পারে।

aws rds create-db-instance \
  --db-instance-identifier example-orders-db \
  --engine postgres \
  --db-instance-class db.m6g.large \
  --allocated-storage 100 \
  --max-allocated-storage 500 \
  --multi-az \
  --no-publicly-accessible \
  --storage-encrypted \
  --backup-retention-period 7 \
  --deletion-protection \
  --master-username appadmin \
  --manage-master-user-password \
  --db-subnet-group-name example-private-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0

# clean up after practice, or the bill keeps running
aws rds modify-db-instance --db-instance-identifier example-orders-db \
  --no-deletion-protection --apply-immediately
aws rds delete-db-instance --db-instance-identifier example-orders-db \
  --final-db-snapshot-identifier example-orders-final

Self-managed বনাম managed — হিসাব

একই কাজ নিজে দুটি VM-এ চালালে বিল কম দেখায়। তবে সেখানে backup script, patch, failover tool আর রাতের on-call-ও আপনার। তাই শুধু infrastructure নয়, মানুষের সময়ও ধরে TCO হিসাব করতে হয়। নিচের সব দাম ধরে নেওয়া। আসল দামের জন্য provider-এর pricing পাতা দেখুন।

// Self-managed vs managed, per 30-day month. Every price is ASSUMED, none is real.
const HOURS = 720;
// two nodes (primary + standby), two copies of disk, one copy of backup
const bill = (perHour, gb, premium, diskPerGb) =>
  2 * perHour * premium * HOURS + 2 * gb * diskPerGb + gb * 0.05;

console.log("size    self$  mgd$  extra$  breakeven h @ $10  @ $40");
for (const [name, perHour, gb, mgdOps] of [
  ["small", 0.10, 100, 8], ["medium", 0.40, 500, 10], ["large", 3.20, 4000, 15],
]) {
  const self = bill(perHour, gb, 1.0, 0.10);
  const mgd  = bill(perHour, gb, 1.7, 0.12);      // assume a 70% compute premium
  const extra = mgd - self;
  const hours = rate => (extra / rate + mgdOps).toFixed(0);
  console.log(name.padEnd(6) + self.toFixed(0).padStart(6) + mgd.toFixed(0).padStart(6) +
    extra.toFixed(0).padStart(8) + hours(10).padStart(19) + hours(40).padStart(7));
}
// Ops time for the self-managed side if we assume 40 hours a month at $10:
console.log("medium self total =", (bill(0.40, 500, 1, 0.10) + 40 * 10).toFixed(0),
  "| medium managed total =", (bill(0.40, 500, 1.7, 0.12) + 10 * 10).toFixed(0));

size    self$  mgd$  extra$  breakeven h @ $10  @ $40
small    169   274     105                 18     11
medium   701  1124     423                 52     21
large   5608  8994    3386                354    100
medium self total = 1101 | medium managed total = 1224

Managed-এর বিলে লুকানো দিকগুলোও দেখুন: IOPS, retention-এর বাইরের backup, cross-region কপি, আর পুরোনো version-এর বর্ধিত support ফি, যদি provider নেয়। অন্যদিকে self-managed-এ zone পেরোনো replication traffic-এর খরচ আলাদা আসতে পারে। বিলের বিস্তারিত থাকছে পর্ব ৭২ · Cloud-এর বিল-এ।

১০ · AI-এর যুগে managed database যাচাই

AI কয়েক সেকেন্ডে পুরো database-এর Terraform বা কমান্ড লিখে দেয়, আর সেগুলো দেখতে ঠিকঠাকই লাগে। কিন্তু তার উদাহরণগুলো প্রায়ই tutorial-এর জন্য লেখা, production-এর জন্য নয়। আর database-এ ভুলের দাম সবচেয়ে বেশি, কারণ ডেটা ফেরত আনা কঠিন।

চালুর আগের চেকলিস্ট

• Public endpoint বন্ধ, security group শুধু app থেকে, 0.0.0.0/0 নেই
• Multi-AZ চালু, আর staging-এ failover চালিয়ে ব্যর্থ অনুরোধ গুনেছি
• Retention ঠিক, restore করে row count মিলিয়েছি, সময় মেপেছি
• Instance × pool (surge সহ) ব্যবহারযোগ্য slot-এর নিচে
• লেখার retry-তে idempotency key আছে, client-এর timeout আর DNS আচরণ জানি
• Lag, connection, IOPS, free storage আর slow query-তে alarm আছে
• Deletion protection চালু, secret কোডে নেই, budget alert বসানো
• AI-এর কমান্ড আগে plan বা --dry-run-এ দেখেছি, diff পড়েছি, throwaway পরিবেশে চালিয়েছি