I think ... - computing

সহজ বাংলায় Scalability এর একটা উদাহরণ

2024-01-22T00:00:00+06:00

সিঙ্গাপুরের Grab এ থাকতে আমার একবার বস ছিল অরুণ নামের এক ইন্ডিয়ান।

জয়েনের কিছুদিন পরে, বসের কাছে কমপ্লেন গেলো যে খালেদ এই কাজ টা এমনে করে না, অমনে করে। বস আমাকে উইকলি মিটিং এ জিজ্ঞেস করলো, অমনে করো কেনো? আমি বললাম, এই এই কারণে অমনে করি। সে আমাকে এক কথায় উত্তর দিলো যেটা আমার কানে এখনও বাজে। সে বলছিল, “তোমার উদ্দেশ্যটা ভালো, কিন্তু এটা scalable না”। বেশি ব্যাখ্যা করা লাগে নাই, কারণ হোল আমরা দুজনেই জানতাম যে আমার ২৫+ টা টীমের সাথে কাজ করা লাগে, আমি যেভাবে আগাচ্ছিলাম, সেভাবে পাঁচ সাতটা টীমের সাথে হয়তো কাজ ম্যানেজ করা যেতো, কিন্তু ২৫ টা না।

আমাদের দেশের আইটি সেক্টরের বিভিন্ন উদ্যোগেও আমি এই ব্যপারটা খেয়াল করি খুব বেশি রকম, “উদ্দেশ্যটা ভালো, কিন্তু scalable না” কি দেখে হঠাত এই কথা মনে আসলো সেইটা বলি।

ব্র্যাক ব্যাংক একটা মেইল পাঠিয়েছে, সিস্টেম মেইনটেনেন্সে সার্ভিস কিছুক্ষণ বন্ধ থাকবে এইটা হোল বিষয়। ইমেইলে বডিতে কোন টেক্সট নাই, খালি একটা ইমেজ। ভালো কথা। টেক্সট অনেকে পড়তে চায় না, ইমেজ দিলে খেয়াল করে পরবে। অনেকের মোবাইলে বাংলা ঠিকমতো দেখায় না, সেটাও একটা বিষয়। তো “উদ্দেশ্যটা ভালো”। কিন্তু সাধারণ এই ইমেজ এর সাইজ ৩ মেগাবাইট (ধরেন, ৩০০০ কিলোবাইট), যেই ইমেজটা ৫০ কিলোবাইট হলেও একই লেখা প্রায় একই রকম দেখা যেতো। পার্থক্যটা খালি চোখে ধরা কঠিন। মানে প্রয়োজনের তুলনায় ৬০ গুন বড়। এখন আসেন scalability বিবেচনা করি ।

ব্র্যাক ব্যাংক এর কাস্টমারের সংখ্যা যদি হয় ৫ লক্ষ, এই একটা মেইল পাঠাতে ব্যাংকের মেইল সার্ভার (edm. bracbank .com) থেকে “Data Out” ট্রাফিক জেনারেট হয়েছে (৩ মেগাবাইট x ৫,০০,০০০) = ১৫০০ গিগাবাইট। আর ইমেজটার সাইজ যদি হতো ৫০ কিলোবাইট, এই একই কাজটা হয়ে যেতো ২৬ গিগাবাইট মতো ডাটা ট্রাফিকে, মানে ৬০ ভাগের এক ভাগ, আর পুরো ব্যাচ ইমেইল পাঠানো শেষ হতো ৬০ গুন দ্রুত।

এখন বলতে পারেন, ব্যাংকের টাকা আছে খরচ করুক। সেটা এক কথা, কিন্তু আরেকটা সাইড ভাবেন।

বাংলাদেশের বেশির ভাগ মানুষ ইন্টারনেট চালায় মোবাইলে। অর্থাৎ, এই গুরুত্বপূর্ণ ইমেইল টা দেখতে যে ৩ মেগাবাইট বাড়তি খরচটা হোল, ধরেন ১০০০ গিগাবাইট, এর বড় একটা অংশ গেলো মোবাইল কোম্পানিগুলার পকেটে। আবার, বাংলাদেশের বেশির ভাগ জায়গাতে ইন্টারনেটের যে অবস্থা, এই মেইল লোড হতে সময় নিবে ১০ সেকেন্ড, যেটা কিনা এক সেকেন্ডএর ও কম সময়ে করা যেতো।

এবার ধরেন, ইমেজটার সাইজ হোল ১০ মেগাবাইট, ৩ মেগাবাইটের বদলে। কি সমস্যা? “scalable না”, এই আরকি।

Create a free go-link server “on edge” using Cloudflare Worker KV

2021-06-06T00:00:00+06:00

Among quite a few ways to implement a go-link server (i.e., url-forwarder, short-url server, etc.), I’m going to show you how to use free-tier Cloudflare Worker (& KV) to create an in-house, on-edge, no-webserver go-link server.

For example, the short-link for this article is go.kmonsoor.com/golink-kv

/latest (by which I mean go.yourdomain.co/latest) may point to https://www.yourcompany.com/about/news which is a public page
/hr-help may point to https://www.company-internal.com/long-link/hr/contact.html, which is company’s internal human-resources help portal
/cnypromo may point to https://shop.yourcompany.com/sales/promotions/?marketing-promo=2021-cny which is a temporary sales promotions page targeting the shoppers during the Chinese new year of 2021.

Please note that using the setup and the code below, it’ll be possible to resolve short-links via a single sub-domain, e.g., go.your-domain.co. However, it’s possible (with some modification of the code) to resolve/redirect via any number of domains (your own, of course) towards any other public or private URL, and all sorts of novelties. However, for brevity’s sake, I will discuss the first one, a single sub-domain usecase.

To set up a go-link server or short-URL resolver via a proper KV+Worker combination, we’ll go through these steps:

Pre-requisites
Create the short-link map as a KV
Mapping a KV to a Worker variable
Handling a route with webworker
Create the Worker
Pointing a DNS record to the Worker
Next step
Related

Pre-requisites¶

The DNS resolver for the root domain (in the example below, kmonsoor.com) needs to be Cloudflare. Because the core of the solution, the “worker”, runs on the nearest (from the user) edge of Cloudflare using a standard KV (“key, value”) list.
Write permission to the DNS configuration as you’d need to add a new AAAA DNS record.
Some knowledge of Javascript(ES6), as we are going to write the “worker” in that language.

Create the short-link map as a KV¶

We’ll start the setup by creating the short-link map, the list between the short-link segments that you (or someone in your org) define, and the actual URLs they need to point to.

Find the KV stuff in the Workers section. From the screenshot, please ignore the “Route” section for now.

you’d need to create a Worker KV “Namespace”. Name the namespace as you seem fit. I named it REDIRECTS (in all caps just as a convention, not required).
List the short links & their respective target URLs. From the examples in the intro, the keys latest, hr-help, cnypromo etc. would be in as the “key”, and the target full links as the respective “value”.
Remember NOT to start the short part with ‘/’. It’ll be taken care of in the code.

Once you’ve listed all your desired (short-link, target-link) combinations, now we have a KV on Cloudflare. However, it’s not referencable from your Worker code, not yet. Hence the next step.

Mapping a KV to a Worker variable¶

Now, we will map the previously created KV to a variable that can be referenced from our Worker code. Please note that though I used different names, it can be the same as well. Also, note that multiple Workers can access a single KV, and vice versa is also true; a single Worker can reference multiple KVs.

Handling a route with webworker¶

Create the Worker¶

Now, we will write Worker-code that runs on V8 runtime on the nearest (from the requesting user) “edge” location of Cloudflare, to execute the code and deliver the result(s) to the user. In this case, that would be to redirect user-requested address to the mapped one (by you, in the KV namespace above).

The code editor looks like this:

If you rather prefer to copy-paste, please feel free to do it from the below GitHub Gist.

Once done, it should look like …

Pointing a DNS record to the Worker¶

Finally, we need to point a DNS record that’ll redirect all requests to your re-soutign sub-domain (e.g. go.your-domain.com) to the Cloudflare Worker that we just created.

According to the Cloudflare docs, the DNNS record must be an AAAA record, pointing to the IPv6 address 100::. The “Name” here is the “sub-domain” part of your choice, which is better be short, to rightfully serve our goal here.

Voila ! Now, test some of the short-urls that you’ve mapped via the KV. Enjoy ! Watch out for the target usage though. Here’s the limit.

I think you’ll be fine, unless you’re some celebrity ;)

Next step¶

As the next step, I’m thinking to create a generic Go/Link resolver browser extension. Then, someone can set their own default domain or company domain of choice as short-domain host. In that case, entering just go/hr-help on the browser will take to https://www.company-internal.com/.../hr/contact.html that we have discussed at the beginning (remember the example case of an internal human resources help portal?).

If you want to do this url-direction on your server, but only using webserver, try this: Personal short-link server using only Caddyserver

If you find this post helpful, you can show your support through Patreon or by buying me a coffee. Thanks!

TL;DR what cloud provider to use in 2021

2021-05-22T00:00:00+06:00

The sheer number of combinations a company can choose from the cloud providers and their product suites is mind-boggling. Hence, I decided to break it down in a concise form for the busy C-suite executives.

According to my little experiences and humble opinion, I suggest …

➤ If your company is a small SaaS shop with 10-ish engineers, stick with DigitalOcean, Linode, OVH, etc., which are best known as cloud “instance” providers.
Think McDonald’s; reliable, cheapest, fast, but you won’t take your date there.
Budget: 💰

➤ If you want a whole cloud experience (e.g., VPC, firewall, WAF, etc., on the menu), start with Google Cloud, then try AWS later.
Google Cloud would be the quickest to grasp the cloud concepts and get going. The UI of the AWS console is a bit messy compared to GCP; it just takes more time to get a proper grip.
Imagine them as full-course, Michelin-star restaurants. However, the product names are so abstract that they need a full-sized chart for that. ;) Budget: 💰💰💰

➤ Are you planning to set up a million-dollar infra for a billion-dollar company? Go for some GCP+AWS multi-cloud setup. You gonna get rebates from both on the scale of hundreds of thousands of dollars. And Microsoft Azure gonna offer you some million-$ free-tier, hoping to get the company hooked on Azure. :D Budget: 💰💰

➤ On the other hand, if you run a govt agency or a company where wearing suits is the mainstream, Microsoft Azure is your best bet.
A bunch of consultancy companies to choose from; you need to just approve the budget, you get the things to get up & running but miss the deadline by months, if not years. But there’d be no need for hiring more smarter ppl than that you already have. Budget: 💰💰💸

Need an even more comprehensive guide? Gotcha, fam …

CTO: we're having hard time choosing a cloud provider
…
“say no more, fam, I gotcha …” pic.twitter.com/hR3rMruWWi
— Khaled Monsoor ✨ (@kmonsoor) May 22, 2021

PS This post is inspired by a LinkedIn post of mine where I shared about my short experience with the Microsoft Azure DevOps suite

HA(High-Availability) Setup for InfluxDB

2018-01-18T00:00:00+06:00

NOTE Since I have written this article, all the components used in this below architecture have gone through many updates and releases. While the general premise involving influxdb-relay and the multiplexing might still hold, please sync up with the latest release docs before jumping into some serious system design.

Currently, from version 0.9, you cannot create an InfluxDB cluster from the open-sourced free edition. Only commercially available InfluxDB Enterprise can do that for now. That stirred up the early-adopter enthusiast users, especially for their usage in professional setups. They complained that InfluxData, the company behind InfluxDB, is trying to milk the OSS solution for profit.

I can’t blame the InfluxData guys much, as they got to pay their bills too. So far, we — the users of open-source systems — couldn’t show much promise about the financial realities of the projects. Continuing development of OSS products, by only depending on donations, patrons, or enterprise sponsorship, is far too rare and unpredictable, even for the projects that many successful organizations heavily rely on.

Anyways, InfluxDB then promised and later introduced Influx Relay as a complimentary consolation for missing HA parts of InfluxDB. You can get the details here and here about that.

Premise¶

For my needs, I have to try to create a reliable HA(High-Availability) setup from available free options, hence InfluxDB and the relay. It’s quite a bit far from an InfluxDB-cluster in terms of robustness or ease of setup, but it’s got the job done, at least for me.

I needed a setup to receive system-stats from at least 500+ instances and to store them for a while, but without breaking the bank in bills from AWS. Meaning, I could ask for and could use only couple of instances for my solution.

Here were my trade-offs.

Not too many instances for this purpose. Neither, any of the heavyweight lifters e.g. AWS’ m3-xlarge etc. To use only what’s necessary.
To satisfy the budget, hence avoiding pay-per-use solutions as far as it is possible.
Solutions must not be crazy complex, so that handover to the DevOps team be smooth.
Reading the data would be too rarely w.r.t. writing. The related Grafana dashboards will be only used to investigate issues by a handful of people.

Overall Design¶

Write¶

From a birds’ eye view, I decided to use two server instances to run parallelly, hosting InfluxDB on them independently and then sending the same data over to them for storing. This scheme mostly looks like RAID-1 systems.

That brings up a couple of challenges.

None of the agents I used on the sender side could multiplex output. That means, they were able to send data to a single destination, not multiple. On the Windows front, I’ve used Telegraf which is able randomly to switch between pre-listed destinations, but NOT multiple at-once.
In the case of Linux hosts, I used Netdata which is excellent in its own right, but unable to send stats to multiple destinations.
Here comes Influx-relay. It can receive time-series data-stream from hosts on a TCP or UDP port, buffer for a while, and then re-send those received and buffered data to multiple receive ends which can either be an InfluxDB instance or another listening Influx-relay instances.
This chaining can broaden the relaying scheme even further. However, for my purpose, this relay-chaining was not necessary. Rather, from the relay, I am sending data to the separate InfluxDB instances, running on two separate instances.
Now that I partially multiplexed the output, my hosts (senders) still are able to send to one destination. So, I need a proxy as well as a load-balancer. For a while, I was torn between NGINX and HAProxy. Both were new to me.

However, for a couple of reasons, I went for HAProxy. Firstly, I don’t need HTTP session management. Secondly, as I wanted to keep my UDP for later, HAProxy was perfectly capable of that.
NGINX has the support recently, but the maturity was a concern. Also, configuring NGINX seems a little intimidating (which I know might not be so true). Last but not least, and for what it’s worth, out-of-the-box, HAProxy’s stat page carries much more in-depth information than that of free-version of NGINX.
Upon receiving the stats stream, HAProxy was supposed to send that to different Influx-relays in a load-balanced fashion.

So, here’s my rough plan.

collector-agent → HAProxy → (50/50 load-balanced) → Influx-relay → (multiplexed) → 2 InfluxDB instances

Now, each one of the received data is to go to both of the InfluxDB instances, or at least to one in case of failure (or, overload per se) of any the relays or Influx instances. Also, I have chosen to keep Influx-relays deployed as Dockerized and kept HAProxy and InfluxDB instances running as native services. Of course, you can Dockerize HAProxy and InfluxDB, too.

Read¶

As I’ve already noted in the section that reading the data, meaning to fetch data to visualize on Grafana end, will happen rarely and sporadically; only to investigate alarms or any other client-side performance issues.

So, the read requests, reaching the HAProxy end, needed not much routing, other than directly to InfluxDB itself. Still, to better distribute the load I decided to load-balance it 50/50 basis.

Ports¶

As all the READ requests are routed through HAProxy running on each of the instances, to the external world only HAProxy’s port should be opened for this purpose.
On the other hand, for WRITE requests, InfluxDBs are receiving data from relays, one of its own instance and another one on other instance, so InfluxDB should listen on its own port for WRITE requests only. But, this must be accessible only from own VPS zone, but not open to the outside world.
In case of HAProxy as well as InfluxDB, you can use the default ports, obviously, which is 8086 & 8088 respectively. Or, you can choose to go for other ports (security through obfuscation). Your call. In this writing, I’ll go with the defaults.

Authentication, SSL¶

You can configure SSL with your own server certificates through the HAProxy configs. You can even go for SSL from the relays to InfluxDB writes. If your sender hosts are connecting to your HAProxy through public internet, you should at least go for password-based authentication, better to utilize SSL. However, for brevity’s sake, I’ll skip them in this post.

**Note: * Please bear in mind, this is an “in-progress” post; prematurely published to force me to work on it. I have the plan to add all the necessary configurations & commands, that I used, here.

Characters Efficient Flow in Designing Bangla Font

2013-08-22T00:00:00+06:00