মনোলিথিক এবং মাইক্রোসার্ভিস আর্কিটেকচার কি?

সফ্টওয়্যার বা ওয়েব এ্যাপ্লিকেশন ডেভেলপমেন্টের সবচেয়ে স্মার্ট আর্কিটেকচার, মাইক্রোসার্ভিস নিয়ে এই পোস্ট এ বিশদ আলোচনা করব । পাশাপাশি মনোলিথিক আর্কিটেকচারের সাথে এর মুল পার্থকগুলো তুলে ধরার চেষ্টা করব ।

মনোলিথিক আর্কিটেকচার

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

মাইক্রোসার্ভিস
মনোলিথ হলো সব মডিউল বা ফিচার সহ একটি বড় সিস্টেম

মনোলিথিক এ্যাপ্লিকেশন একটি মাত্র ইউনিট বা সার্ভিস হিসেবে ডেভেলপ করা হয় । এতে কোন প্রকার পরিবর্তন আনলে সিস্টেমে নতুন একটি ভার্সন ডেপ্লয় করার প্রয়োজন পড়ে।

মাইক্রোসার্ভিস আর্কিটেকচার

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

মাইক্রোসার্ভিস
মাইক্রোসার্ভিস হল একটি বড় ট্রাকের পরিবর্তে অনেকগুলো ছোট ছোট কার

মাইক্রোসার্ভিস নিয়ে বিখ্যাত লেখক Sam newman এর মতে মাইক্রোসার্ভিস হল: 

A small independently releasable services that work together, modelled around a business domain.

Martin Fowler এবং James Lewis একটি আর্টিকেলে মাইক্রোসার্ভিস নিয়ে বলেন :

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API […] There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

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

মনোলিথিক VS মাইক্রোসার্ভিস

একটি বড় সিস্টেম ডেভেলপের জন্য মনোলিথিক একটি ন্যাচারাল  মেথড । কিন্তু যখনই একটি বড় সিস্টেম মেইনটেইনের কথা আসে তখনই সবারই হতাশ হতে হয়। পুরো সিস্টেমের মাঝে কেবল ছোট একটু পরিবর্তন আনতে হলেও পুরো সিস্টেমটি আবার রি-বিল্ড করে ডেপ্লয় করতে হয়। শুধু তাই নয়, অনেক সময় সিস্টেমটি মডিউলারাইজ রাখতে যেমন সমস্যা হয় তেমনি এক মডিউলের কোন ক্ষুদ্র পরিবর্তন অন্য মডিউলে অনাকাংক্ষিত সমস্যা তৈরী করতে পারে। মনোলিথিকে কোন নির্দিষ্ট মডিউলের জন্য স্ক্যালিং সম্ভব হয় না, সম্পূর্ন সিস্টেমের জন্য একত্রে করতে হয়।

মনোলিথিক VS মাইক্রোসার্ভিস
মনোলিথের তিনটি সন্ত্রত্র মডিউলকে তিনটি ভিন্ন মাইক্রোসার্ভিস বা তিনটি ভিন্ন এ্যাপ এ বিভক্ত করা হয়েছে ।

মাইক্রো সার্ভিসগুলো আসলে কি করছে ? একটি বড় সমস্যাকে কিছু ছোট ছোট অংশে পরিনত করছে এবং সেগুলো সম্পূর্ন আলাদা একটি এ্যাপ এর মত করে বানানো হচ্ছে । একটি সার্ভিস আরেকটি সার্ভিসের ডেভেলপমেন্ট টিম, টেকনোলজি স্ট্যাক সম্পূর্ন ভিন্ন হলেও কোন সমস্যা নেই । একটি সার্ভিস পাইথন টিম বানালো, আরেকটি হয়তো নোড জেএস, অন্যটি পি.এইচ.পি । যদি পুরো ইকোসিস্টেমের কোন একটি ফেইল করে তবে অন্যটি বসে থাকেবে না।  এপিআই ম্যানেজমেন্ট কম্পানি Mashape এর CEO বলেন

Imagine you’re driving a car. Even if the brakes go out, which is really bad, it doesn’t break the whole car. At least your engine is still working, right?

অনেকটা প্লাগিন এর মত । কোর একটি মডিউলের সাথে শুধু প্লাগিনটি জুড়ে দিলেই কাজ হয়ে গেল।

মাইক্রোসার্ভিস কখন প্রয়োজন ?

একটি সিস্টেম বানানোর সময় যখন সিদ্ধান্ত নেয়া হয় তখন মাইক্রোসার্ভিসের কথা অনেকেই চিন্তা করে না। কারন ছোট সিস্টেমের জন্য মাইক্রোসার্ভিস আসলেই কোন সমস্যা সমাধান করে না, কারন তখন এধরনের কোন সমস্যাই থাকে না। কিন্তু যখন সিস্টেমটি অনেক বড় হয়ে যায় এবং হরিজনটাল স্কেলিং এর প্রয়োজন পড়ে তখন নতুন করে মাইক্রোসার্ভিস ডেভেলপ করা অনেক খরচের ব্যাপার হয়ে দাড়ায় । ভবিষ্যতের চ্যালেন্জ আচ করতে পেরে অনেকেই শুরু থেকেই মাইক্রোসার্ভিস ডেভেলপ করতে উৎসাহিত করেন। Netflix, eBay এবং Amazon তাদের কয়েকটি মডিউল মাইক্রোসার্ভিসে রূপান্তরিত করে ভবিষ্যতে এটির প্রয়োজন অনুধাবন করতে পারে এবং ধীরে ধীরে পুরো সিস্টেমটাকে মাইক্রো সার্ভিসের একটি ইকোসিস্টেম ডেভেলপ করে। এবার এই পোস্টটি একটু পড়ে দেখতে পারেন। : How to prepare next-generation cloud applications

মাইক্রোসার্ভিস কেন প্রয়োজন

বর্তমান এবং ভবিষ্যৎ প্রজন্মের প্রযুক্তির সাথে তাল মিলিয়ে চলার জন্য মাইক্রোসার্ভিস এর প্রয়োজনীয়তা তুলনাহীন । বর্তমান ডেভেলপমেন্ট চক্রের বিভিন্ন সমস্যা থেকেই আসলে এই ইকোসিস্টেমের আবির্ভাব।  চলুন দেখা যাক এতে আমরা কিভাবে উপকৃত হতে পারি :

ডেভেলপমেন্ট

মাইক্রোসার্ভিস একটি সফ্টওয়্যার আর্কিটেকচার স্টাইল যা ডিস্ট্রিবিউটেড এ্যাপ্লিকেশন ডেভেলপমেন্টে একটি নতুন ধারা যোগ করেছে। একটি বড় সিস্টেমকে ভেঙ্গে ছোট ছোট কম্পোনেন্ট হিসেবে তৈরী করা হলে এটি ডেভেলপ, আপডেট, মেইনটেইন করা অনেক সহজ হয়ে যায় ।

ক্লাউড আর্কিটেকচার বিশেষজ্ঞ এবং স্টর্ম ভেনচারের ম্যানেজিং ডাইরেক্টর রায়ান ফ্লয়েড এর মতে

“The more you break that down, the easier it is to build and modify an application.”

মাইক্রোসার্ভিসের সুবিধা নিয়ে পেপালের সি.টি.ও James Bareese বলেন

“The benefit is that PayPal is moving faster than ever”

পেপালের “make a payment” বাটনটির ফাংশনালিটি আসলে একটি আলাদা ছোট এ্যাপ এবং এটি মেইনটেইন কিংবা আপডেট করার জন্য ডেডিকেটেড টিম রয়েছে। এমাজনের add to cart থেকে ইউজার রিভিউ পর্যন্ত ফাংশনালিটিগুলো একটি সতন্ত্র সার্ভিস দ্বারা নিয়ন্ত্রিত হয়। অনুরূপ ভাবে তৈরী করা হয় সিস্টেমের অন্যান্য সার্ভিসগুলো এবং এগুলো প্লাগিনের মত করে জুড়ে দেয়া হয় মুল সিস্টেমের সাথে । এসব মাইক্রো সার্ভিসগুলো সাধারনত সম্পূর্ন ভিন্ন ভিন্ন প্রোগ্রামার টিম দ্বারা নিয়ন্ত্রিত হয়। ফলে ঐ টিমটি তাদের মডিউল নিয়ে ডেডিকেটেড ভাবে কাজ করতে পারে। ঐ টিমের যদি কেউ একজন জন নাও থাকে বাকিরা সেটা খুব সহজেই কভার করতে পারে।

স্কেলিং

মনোলিথিক সিস্টেমের তুলনায় মাইক্রোসার্ভিসের স্কেলিং অনেক সহজ । ধরুন কোন একটা মডিউল রান করাতে আপনার RAM বা CPU পাওয়ার বা স্টোরেজ বেশি প্রয়োজন । মনোলিথিক সিস্টেমের জন্য আপনি কোন একটা মডিউলের জন্য একটা নির্দিষ্ট হার্ডওয়্যার বরাদ্দ করতে পারবেন না। কিন্তু মাইক্রোসার্ভিসের ক্ষেত্রে আপনার মডিউলটি একটি ভিন্ন সার্ভারে তার প্রয়োজনীয় হার্ডওয়্যার দিয়ে সহজেই স্কেলিং করতে পারেন । আরো বেশি পাওয়ার দরকার হলে তার সাথে আরেকটি সার্ভার বা হার্ডওয়্যার কম্পোনেন্ট যোগ করে দিলেই হল।

চিন্তার স্বাধীনতা

মনোলিথিক সার্ভারের ক্ষেত্রে আপনার আর্কিটেকচার, প্রোগ্রামিং ল্যাঙ্গুয়েজ, টুলস্ সবই মোটামুটি ফিক্সড । এখানে ট্রায়ল এন্ড টেস্ট ডেভেলপমেন্ট অনেক বিপদজনক। প্রতিটি মাইক্রোসার্ভিস যেহেতু সতন্ত্র সেহেতু যে মডিউলের জন্য যেই টেকনোলজি বা প্রোগ্রামিং ল্যাঙ্গুয়েস্ট বেস্ট সেটাই আপনি ব্যবহার করতে পারেন। যেমন মেশিন লার্নিং বা সেন্টিমেন্ট এনালাইসিস কিংবা বিগ ডাটা হ্যান্ডেলিং এর জন্য পাইথন ব্যবহার করলেন আর রিয়েলটাইম মেজেজিং মডিউলের জন্য নোড + সকেট ব্যবহার করলেন, একটি সার্ভিসের জন্য হয়তো MySQL ব্যবহার করলেন, আরেকটির জন্য MongoDB। একটি মাইক্রোসার্ভিসে ডেভেলপমেন্ট টিম অনেক ধরনের এক্সপেরিমেন্ট চালাতে পারে যেটা মনোলিথিকে মোটামুটি অনেক জটিল ব্যাপার ।

সাইজ

সমগ্র সিস্টেমের তুলনায় সার্ভিস গুলো অনেক ছোট হওয়া পুরো সিস্টেমটা বুঝা তুলনামুলক অনেক সহজ। কোড অনেক কম থাকায় একজন ডেভেলপারের পুরো সিস্টেমের আংশিক ধারনা নিয়ে সে তার নিজের সার্ভিসে পুরোপুরি দক্ষতার সাথে কাজ করে যেতে পারে। প্রজেক্ট ফাস্ট এক্সিকিউট হবে, IDEগুলো দ্রুত লোড নিবে, ডিপেন্ডেবল লাইব্রেরী কম থাকবে, সার্ভার সহজে মেইনটেইন করা যাবে।

ডেপ্লয়মেন্ট

ছোট প্রজেক্ট ডেপ্লয় করা তুলনামুলক অনেক সহজ হয়। ডেভেলপমেন্ট একটি চলমান প্রসেস আর ছোট বড় আপডেট ডেপ্লয় করার ক্ষেত্রে বিপদাশংকা অনকে কম থাকে । আপনার নতুন ডেপ্লয় অন্য কোন সার্ভিস শাট ডাউন করে দিবে, এটা আপনি শতভাগ নিশ্চিত থাকতে পারেন। ডেপ্লয়মেন্ট এ কোন দুর্ঘটনা ঘটলেও সেটা সহজেই রোলব্যাক করে নিতে পারবেন।

আরেকটু গভীরভাবে বুঝার জন্য nginx এর অফিশিয়াল সাইট থেকে দুটি পোস্ট পড়ে আসতে পারেন :

  1. Introduction to Microservices
  2. Building Microservices

ইন্টারেসটিং মনে হচ্ছে ? চাঁদ দেখার চিন্তা করার আগে রোজা রাখাটা জরুরী । পরবর্তী পোষ্টে আমরা দেখব মাইক্রোসার্ভিসের জটিলতাগুলো কি কি।


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

Microservice না, Monkey Service

মাইক্রোসার্ভিস সিরিজটি শুরু করার আগে নিচের দুইটি পোস্টপড়ে আসা বাধ্যতামূলক :

১) স্কেলিং ওয়েব সার্ভার এবং গেদু ভাইয়ের আদি ফ্যামিলি

২) ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং

মানকি সার্ভিস

আপনার এপ্লিকেশনের একটি মডিউল কে একটি বানর হিসেবে কল্পনা করুন । বানরটিকে এমনভাবে প্রশিক্ষন দিলেন যে এটি একটি নোট ইনপুট হিসেবে নিবে তারপর সে ঐ নোট টি নিয়ে কিছুকক্ষন নাচানাচি করবে। নাচানাচি শেষে দেখাগেল যে আপনার নোট টি আর আগের মত নেই । সে তখন আপনাকে এটি রিটার্ন করল যেটা আপনি আউটপুট হিসেবে পেলেন, আপনি আপনার কাঙ্খিত রেজাল্ট নিয়ে বাড়ি ফিরে আসলেন ।

মাইক্রোসার্ভিস

বানরীয় জটিলতা

মজার ব্যাপার হল যে সবসময় বিষয়টা এমন নাও হতে পারে। দেখা গেল যে নাচানাচি করার সময় সে তাল হারিয়ে কোথাও ছিটকে পড়ে যেতে পারে, এতে তার পা ভেঙ্গে যেতে পারে, কপাল খারাপ হলে আরো অনেক বড় অঘটন ঘটে যেতে পারে ।

এরপরও একই ফ্যাক্টরীতে (এ্যাপ্লিকেশনে) আপনি একসাথে একাধিক বানর (মডিউল) রাখার কথা ভাবতে পারেন, শুধু আপনাকে খেয়াল রাখতে হবে:

১) এক বানর যাতে অন্য বানরের সাথে ঝগড়া না লাগে

২) এক জনের ফাইল নিয়ে অন্য জন যেন লাফালাফি না করে

৩) একজন মরে গেলে যেন বাকিরা ভয় পেয়ে কাজ বন্ধ না করে।

বাস্তবতায় চোখ রাখলে দেখবেন যে এসব খুবই কমন ঘটনা । সেক্ষেত্রে আপনি কি করবেন?

সমাধান

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

আপনি মনে করতে পারেন যে আপনার প্রশিক্ষিত বানরটি অনেক চালাক এবং অনেব কাজের। তবুও আপনার মনে রাখা উচিত যে এটা একটা বানর । আপনি যত ভালো ড্রেস পড়ান না কেন এটা বানর ছিল এবং বারনই থাকবে (বাগ থাকবেই, ইরর ঘটবেই) । একটি বানর কখনই তার প্রশিক্ষকের চেয়ে বেশি চালাক হতে পারবে না। ঘরে আগুন লেগে গেলে কিংবা কোন দুর্ঘটনা ঘটলে হলে তাকে কি করতে হবে সেটা যদি আপনি তাকে বলে না দেন তবে সেটা আপনারই ভুল ।

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

মাইক্রোসার্ভিস

মাইক্রোসার্ভিস শব্দটি তুলনামূলক অনেক নতুন একটি শব্দ । একটি বড় এ্যাপ্লিকেশন সিস্টেমকে ভেঙ্গে ডিস্ট্রিবিউট আর্কিটেকচারে ডিজাইন করার একটি চমৎকার কৌশল হল মাইক্রোসার্ভিস।

গামলা ভর্তি সারকাজমে ভার এই পোস্টের আগা-মাথা এখন পুরোটা মাথায় না আসলেও কোন সমস্যা নেই। পরবর্তী কয়েকটা পোস্টে সব পানির মত স্বচ্ছ হয়ে যাবে। চলুন আগে মাইক্রো-বাস আর মাইক্রোসার্ভিসের গুষ্টি উদ্ধার করি:  মনোলিথিক এবং মাইক্রোসার্ভিস আর্কিটেকচার কি?


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

সাধু বাবার লোড ব্যালেন্সিং

ওয়েব সার্ভার স্কেলিং-এ লোড ব্যালেন্সিং এর ভুমিকা কি তা নিয়ে আজকের এই পোস্ট । তবে ট্যাকনিক্যাল ব্যাখ্যার পূর্বে আগে সাধু বাবার একটি কাহিনী বুঝে নেই।

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

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

প্রত্যেকটি দরজার সামনে একজন দোকানদার থাকবেন যিনি প্রয়োজনীয় জিনিস বিক্রি করবেন।  বিভিন্ন সমস্যা সমাধানের জন্য বিভিন্ন জিনিস নিয়ে সাধু বাবার কাছে যেতে হবে যা এরা সাপ্লাই দিবে। যেমন:

১। ব্যাবসায়ীক উন্নতি, কিংবা পারিবারিক সমস্যার জন্য তাবিজ, মোমবাতি, আগরবাতি নিয়ে যেতে হবে।

২।  মানসিক সমস্যা (যেমন পাগল, ভুতে ধরা, মন বসেনা পড়ার টেবিলে, সেলফি রোগ ইত্যাদি) কিংবা শারীরিক (অসুখ-বিসুখ, কিংবা সন্তান না হওয়া) সমস্যার জন্য তেল অথবা পবিত্র পানি নিয়ে যেতে হবে।

৩। অন্যান্য সমস্যা এবং মান্নতের জন্য হাস-মুরগি কিংবা ছাগল

 

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

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

লোড ব্যালেন্সিং কি ?

একটি ওয়েবসাইট বা ওয়েব সার্ভিসকে প্রোডাকশন লেভেলে নিয়ে যাওয়ার জন্য এর নিজেরই হাজারটা চ্যালেন্জ রয়েছে। সেগুলো পার করে যখন একটা ভাল মার্কেট পেয়ে যান তখন সেটা আপনার জন্য একটা বড় পাওয়া। আপনার সিস্টেমের ব্যবহারকারী দিন দিন বাড়ছে এবং এটা দেখে আপনার খুব আনন্দ হচ্ছে, তাই না ? কিন্তু একদিন আপনার সার্ভার আর লোড নিতে পারল না, হঠাৎ করে আপনার ছোট্ট সেই LAMP সার্ভারটি ক্রাশ করল, তখন কি হবে? এটা আসলে ম্যাটার করে না যে কোন দিন কখন সার্ভার ক্রাশ করল, আপনার সার্ভার যে অফলাইন হয়ে গেল এটার ক্ষতি অপূরনীয় ।

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

লোড ব্যালেন্সিং

লোড ব্যালেন্সিং মেথড

বহুল ব্যবহৃত তিনটি লোড ব্যালেন্সিং মেথড হল :

  • Round Robin: এ মেথডে লোড ব্যালেন্সার সব সার্ভারে সমান ভাবে ট্রাফিক সেন্ড করে। অর্থাৎ তিনটি সার্ভার থাকলে, প্রথম রিকোয়েস্ট টি যাবে প্রথম সার্ভারে, দ্বিতীয়টি যাবে দ্বিতীয় সার্ভারে, তৃতীয়টি যাবে তৃতীয় সার্ভারে, চতুর্থটি যাবে প্রথম সার্ভারে…..।
  • Least Connect: এই মেথডের কাহিনী হল, সবচেয়ে কম একটিভ কানেকশন যে সার্ভারে আছে সে সার্ভারে ট্রাফিক সেন্ড করবে। অর্থাৎ ১নং এ ১০ জন, ২নং এ ১২জন এবং ৩ নং সার্ভারে ৮জন কানেক্টেড থাকলে পরবর্তী রিকোয়েস্ট টি ৩ নং সার্ভারকে সেন্ড করা হবে।
  • Historical Intelligence:এই মেথড টি পূর্বের দুটি মেথডকে কাজে লাগিয়ে সিদ্ধান্ত নেয় যে পরবর্তী রিকোয়েস্টটি কাকে সেন্ড করবে।

লোড ব্যালেন্সিং এর প্রকারভেদ

ওয়েব ট্রাফিক হ্যন্ডেল করার জন্য দুইধরনের লোড ব্যালেন্সার আছে:

১। সফ্টওয়্যার লোড ব্যালেন্সার
২। হার্ডওয়্যার লোডব্যালেন্সার।

সফ্টওয়্যার লোড ব্যালেন্সার আপনার সার্ভারে ইন্সটল করা অন্যান্য সফ্টওয়্যারের মতই যা ওয়েবের সব ট্রাফিক এক্সেপ্ট করে এবং বিভিন্ন সার্ভারে সেটা ডিস্ট্রিবিউট করে দেয়। জনপ্রিয় দুটি সফ্টওয়্যার লোড ব্যালেন্সার হল:Nginx এবং Squid

হার্ডওয়্যার লোড ব্যালেন্সার গুলো ওয়েব ট্রাফিক ডিস্ট্রিবিউট করার জন্য ডেডিকেটেড সিঙ্গেল মেশিন যার সাধারনত অন্য কোন ধরনের সফ্টওয়্যারের প্রয়োজন পড়ে না। সবচেয়ে জনপ্রিয় কিছু লোড ব্যালেন্সারের একটি লিস্ট পাবেন এখানে।

গুরুত্বপূর্ন প্রশ্ন

আপনার সার্ভার ক্রাশ করলে সেটা লোড ব্যালেন্সার হ্যান্ড্যেল করবে, বুঝলাম। শেষ করার আগে আমি যে প্রশ্ন রেখে যাচ্ছি সেটা হল : আপনার লোড ব্যালেন্সার ক্রাশ করলে কি করবেন? Who watches the watchmen?


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং

ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং নিয়ে আমার আগের পোস্ট “স্কেলিং ওয়েব সার্ভার এবং গেদু ভাইয়ের আদি ফ্যামিলি” এর ট্যাকনিক্যাল ব্যাখ্যা নিয়ে আজকের এই পর্ব । একটা ফরমাল সঙ্গা দিয়ে শুরু করা যাক :

আপনার সিস্টেমের বর্তমান ইউজার এক্সপেরিয়েন্স অক্ষুন্ন রেখে,  এ্যাপ্লিকেশন কোডে পরিবর্তন না এনে;  হার্ডওয়্যার, ওএস বা সফ্টওয়্যার কম্পোনেন্টে পরিবর্তনের মাধ্যমে সিস্টেমের নতুন ট্রাফিক লোড হ্যান্ডেল করাকে সার্ভার স্কেলিং বলে। স্কেলিং সাধারনত দুই প্রকার : ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং ।

ভার্টিক্যাল স্কেলিং বা Scale Up

আগের তুলনায় হাই পারফরমেন্সের কম্পোনেন্ট সার্ভারে  ডেপ্লয় করে স্কেলিং করার পদ্ধতিকে ভার্টিক্যাল স্কেলিং বলে। যেমন : নতুন প্রসেসর, র‍্যাম, হার্ড ডিস্ক ইত্যাদি ।

ভার্টিক্যাল স্কেলিং

ভার্টিক্যাল স্কেলিং এর সুবিধা

  • ঝামেলা কম ! সহজেই শুরু করা যায়।
  • ট্রাফিক লোড খুব বেশি না হলে এবং মোটামুটি একটি ভাল মানের সার্ভার হ্যান্ডেল করতে পারলে ম্যানেজমেন্ট এবং মেইন্টেনেন্স খরচ কম।

হরিজন্টাল স্কেলিং বা Scale Out

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

হরিজন্টাল স্কেলিং

হরিজন্টাল স্কেলিং এর সুবিধা

  • High availability (HA) : সিস্টেমের ডাউন টাইম কমিয়ে সেটা সার্বাধিক বেশি সময়ের জন্য লাইভ রাখা । একটি ক্লাস্টার কোন কারনে ক্রাশ করলে আরেকটি সার্ভার ব্যাকআপ দিতে পারে ।
  • Capacity বা ধারন ক্ষমতা : হরিজন্টাল স্কেলিং এর একটি গুরুত্বপূর্ন সুবিধা হল সিস্টেম ডাউন না করে, মেশিন যোগ করে রান টাইম আপনার সিস্টেমের ক্যাপাসিটি বাড়াতে পারবেন ।
  • Performance: একটি মেশিনের উপর চাপ কম থাকায় সিস্টেমের পারফরমেন্স ভাল থাকে । তাছাড়া আপনার ডাটা সেন্টার অনেক হলে আপনি রিজিওনাল ডাটা সেন্টার থেকে ডাটা প্রোভাইড করতে পারেন, এতে পারফরমেন্স অনেক ভাল হয় । যেমন: বাংলাদেশে বসে CDN নেটওয়ার্ক থেকে কোন ডাটা ডাউনলোড করলে CDN প্রোভাইডার আপনার অবস্থান থেকে সবচেয়ে কাছের ডাটা সেন্টার থেকে ডাটা প্রোভাইড করবে ।

ডেভেলপারা কোনটা কিভাবে দেখেন

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

হরিজন্টাল স্কেলিং ডেভেলপারদের জন্য অনেকটা মরুভূমি পাড়ি দেয়ার মত । একাধিক পিসি বা নোড থেকে প্রসেসিং পাওয়ার পেতে আপনার সিস্টেমটিকে প্যারালাল কাজ হ্যান্ডেল করা জানতে হবে। ক্লাস্টার সেটাপ , টেস্টিং এবং মেইনটেনইন করা অনেক ঝামেলা ।তবে হ্যা ! জটিলতা বাড়লেও লং-রান এ  সিস্টেম ডাউন টাইম এবং খরচ অনেক কমবে;  রিলায়েবিলিটি এবং এভেইলেবেলিটি বাড়বে।

কিভাবে সিদ্ধান্ত নিবেন ?

ওয়ের সার্ভার স্কেলিং কিভাবে করা উচিত তা সিদ্ধান্ত নেয়ার আগে সবচেয়ে গুরুত্বপূর্ন বিষয় হল এই দুই মেথডের মাঝে পার্থক্যটা ভালো ভাবে খেয়াল করা । তারপর চিন্তা করে দেখুন যে কোন মেথড আপনার সিস্টেমের জন্য সবচেয়ে উপযোগী।

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

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

আপনার সিস্টেমটি কেমন ?

আপনি যে সিস্টেমের স্ক্যালিবিলির কথা ভাবছেন সেটা আসলে কোন ধরনের কাজ বেশি করে থাকে? আপনার সাইট টি কি read-heavy? write-heavy? নাকি মোটামুটি দুইটাই?  read-heavy ওয়েব সাইটের উদাহরন হিসেবে একটি অনলাইন শপিং সাইটকে ধরে নেয়া যেতে পারে , যেখানে ব্যবহারকারী বেশিরভাগ সময় ব্রাউজ [ read ] করে কাটায়, শুধু মাত্র কিছু সংখ্যক পরিমানে অর্ডার চেকআউট [ writes ] করা হয়। কিংবা আমার এই ব্লগটি ও একটি read-heavy এর উদাহরন হতে পারে, এখানে একজন পাঠক ১ ঘন্টায় হয়তো ১০টি পোস্ট পড়বে [reads] এবং একটা বা দুইটাতে কমেন্ট [writes] করবে। কিন্তু গুগল এনালিটিক্স এর যে ট্রাফিক লোড থাকে, হয়ত তার ৯০ ভাগের উপরই writes অর্থাৎ ওয়েব সাইটের ভিজিটের তথ্য ডাটাবেজে স্টোর করে । মাঝে মাঝে ঐ সাইটের এডমিন তার সাইটের গ্রাফ দেখতে চায় [reads] ।

আপনি কোন ধরনের সিস্টেম ডেভেলপ করতে চাচ্ছেন এবং তার ট্রাফিক লোড এনালাইসিস করে আপনাকে সিদ্ধান্ত নিতে হবে আপনি কোন আর্কিটেকচার/টেকনোলজি ব্যবহার করবেন।

স্কেলিং read-heavy সিস্টেম

যদি আপনার সিস্টেমটি মুলত একটি read-heavy সিস্টেম হয় তবে আপনার ডাটাস্টোরটি রিলেশনাল ডাটাবেজে ভার্টিক্যাল স্কেলিং করাই ভাল। RDBMS এর সাথে একটি ফাস্ট ক্যাশিং মেথড যোগ করে দিয়ে সহজেই ভার্টিক্যাল স্কেলিং করতে পারেন। ডাটাবেজ যদি ক্যাপাসিটির বাইরে চলে যায় তবে ক্যাশ-এ আরো বেশি পরিমান ডাটা রাখার চেষ্টা করুন । আর তাতেও না হলে হার্ডওয়্যার আপগ্রেড করুন ।

স্কেলিং write-heavy সিস্টেম

সিস্টেমে প্রচুর পরিমান রাইট হলে ভার্টিক্যাল স্কেলিং যথেষ্ট রিস্ক, কারন এতে ক্যাশিং লেয়ার আপনাকে তেমন কোন সুবিধা দিতে পারবে না । অনেক write-heavy সিস্টেম ভার্টিক্যাল স্কেলিং এ শুরু করলেও খুব বেশি দিন তারা টিকে থাকতে পারে নি।  কেন ? কারন হার্ড ডিস্ক কিংবা একটি প্রসেসর স্পিডের আধিপত্য একটি নির্দিষ্ট সীমার ভিতর  এবং একটু সামান্য I/O অপারেশন পার সেকেন্ড সমৃদ্ধ হার্ডওয়্যার, পাওয়ার এবং ম্যানেজমেন্ট খরচ যথেষ্ট বেশি ।

অন্যান্য বিবেচ্য বিষয়

আরেকটা বিষয় আপনার মাথায় থাকা উচিত, যে কোন সময় আপনার স্কেলিং স্ট্র্যাটেজিতে কিছু অচেনা খরচ যোগ হতে পারে। ভার্টিক্যাল স্কেলিং এ, বেশিকার্য ক্ষমতাধর কম্পোনেন্ট যোগ করে দিলে আপনার একদিকের সমস্যার আপাত সমাধান হলেও অন্য দিকে নতুন সমস্যার সৃষ্টি করতে পারে।

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

এক্ষেত্রে আপনি যদি হরিজন্টাল স্কেলিং মেথড ফলো করে দুইটি ট্রাকে করে কাঠ ডেলিভারি দিতেন তবে এ সমস্যায় পড়তে হতো না।

শেষ কথা

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


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

স্কেলিং ওয়েব সার্ভার এবং গেদু ভাইয়ের আদি ফ্যামিলি

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

গেদু ভাইয়ের সংসার

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

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

ভার্টিক্যাল স্কেলিং
চিত্র ১ । ভার্টিক্যাল স্কেলিং

গেদু ভাইয়ের ঝামেলা :

১। নাতি-নাতনীরা একেক স্কুলে পড়ে তাই তাদের গন্ত্যব্যও একেক দিকে । এক জনকে পৌছে দেয়ার জন্য অঝথাই বাকিদের বসিয়ে রাখতে হয় । একইভাবে তার নিজের ছেলেদেরও অফিসে পৌছে দিতে অনেক সময় লাগে ।

২। একেক জনের প্রয়োজন একেক সময় হওয়া সত্বেও সবাইকে এক সাথে বাসা থেকে বের হতে হয় এবং তারা কেউই এত সময় গাড়িতে বসে থাকতে চায় না ।

৩। সবাইকে পৌছে দিয়ে আসতে তার নিজেরই অনেক সময় চলে যায় । আবার যেহেতু একেকজনের ছুটি একেক সময় তাই নিজের কাজ ফেলে ওদের প্রত্যেককে আলাদা আলাদা সময়ে বাসায় নিয়ে আসতে হয়।

৪। রাস্তায় অনেক জ্যাম থাকায় নির্দিষ্ট সময়ে নির্দিষ্ট গন্তব্যে পৌছানো সম্ভব হয় না, আবার বাস থেকে যাত্রী নামিয়ে দিয়ে তার পরিবারের সদস্যদের সময় মত আনতে যাওয়া সব সময় সম্ভব হয় না।

৫। মাঝে মাঝে কোন কোন সদস্যদের নির্দিষ্ট সময়ের আগেই ছুটি হয়ে যায়, তখন তাদেরকে অযথাই অপেক্ষা করতে হয় ।

গেদু ভাইয়ের আইডিয়া :

এ সমস্যাগুলো সমাধানের জন্য তিনি আইন্সটাইনের মত করে অনেক গভেষনা করেন এবং একদিন হঠাৎ করে আমাদের হাবলু মার্কা গেদু ভাইয়ের মাথায় একটা আইডিয়া আসে । উনি একটু হিসাব নিকাশ করে দেখেন যে একটি বাসে সবাইকে না নিয়ে বরং প্রত্যেকটি গন্তব্যের জন্য আলাদা আলাদা প্রাইভেট কারের ব্যবস্থা করতে পারলেই তার সব সমস্যার সমাধান হয়ে যায় । গেদু ভাইয়ের হিসেবটা ছিল অনেকটা এরকম :

vertical-scaling-cost-calculation
চিত্র ২। ভার্টিক্যাল স্কেলিং

একটি বাসে করে চারটি গন্তব্যে মেম্বারদেরকে নামিয়ে দিতে তার সর্বমোট ২৮ কিলোমিটার রাস্তা পাড়ি দিতে হয় । যেহেতু ২নং  থেকে ৩নং গন্ত্যব্যে ১৫ মিনিটে এবং ৩নং থেকে ৪নং গন্ত্যব্যে ৩০ মিনিটে পৌছাতে পারবে না, সেজন্য অনেক সময় হাতে নিয়েই প্রথম গন্তব্যের জন্য রওনা দিতে হয় । তাই ১ নং গন্তব্যে যে যায় সে নির্দিষ্ট সময়ের অনেক আগেই চলে যায় এবং সে আগে যেয়ে একা একা বসে থাকতেও চায় না।

এবার  চারটি ভিন্ন গাড়ির ক্যালকুলেশন দেখা যাক :

সার্ভার হরিজন্টাল স্কেলিং
চিত্র ৩ । হরিজন্টাল স্কেলিং

এক্ষেত্রে দেখা যায়, ভিজিট পাথ প্রায় অর্ধেক । তদুপরি প্রত্যেকের আলাদা গাড়ি থাকায় কারো জন্য কাউকে অপেক্ষা করার দরকার পড়ছেনা । যে যার যার সময় মত গন্তব্যের দিকে রওনা হয় এবং ফিরে আসে ।

গেদু ভাইয়ের দু:খ

সবাইকে এক সাথে নিয়ে চলার সখ থাকলেও গেদু ভাই বুকে চাপা কষ্ট নিয়ে শেষ পর্যন্ত সবার জন্য আলাদা গাড়ি রাখার সিদ্ধান্ত নিলেন এবং ভার্টিক্যাল স্কেলিং থেকে হরিজন্টাল স্কেলিং এ শিফ্ট করলেন

ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং কি ?

এক কথায়, সার্ভারে যদি বেশি র‍্যাম এর প্রয়োজন হয় এবং আপনি যদি VPS সার্ভারকে Dedicated সার্ভারে আপগ্রেড করে অর্থাৎ একটি বড় সিস্টেম নেন তাহলে সেটা হল ভার্টিক্যাল স্কেলিং । ফ্যামিলিতে মেম্বার বাড়লে প্রাইভেট কার বেচে বাস কিনা আর পুরোনো সার্ভার ফেলে নতুন সার্ভারে আপগ্রেড হওয়া দুইটাই ভার্টিক্যাল স্কেলিং। আর আপনি যদি শুধু মাত্র প্রয়োজনীয় কম্পোনেন্ট যুক্ত করেন তবে সেটা হরিজন্টাল স্কেলিং। Scalability in Wikipedia

গেদু ভাইয়ের বকবকের কি দরকার ছিল ?

গতানুগতিক সার্ভাররে জন্য আমরা সাধারনত ভার্টিক্যাল স্কেলিং নিয়েই ব্যাস্ত । সার্ভার লোড নিচ্ছে না? ও ! তাহলে একটা VPS বা ডেডিকেটেড সার্ভার নাও । তাও হচ্ছে না ? সবচেয়ে প্রিমিয়ামটা নাও । অনেকটা গেদু ভাইয়ের মত। আমরা কেউই রিয়েল লাইফে গেদু ভাইয়ের মত বাস কিনে ফ্যামিলি নিয়ে ঘুরে বেড়াই না কিন্তু সার্ভার স্কেলিং এর বেলায় আমরা এ জিনিস টা খেয়ালই করিনা । আমার সার্ভারে যদি কেবল একটি নির্দিষ্ট মডিউলের জন্য স্টোরেজ বাড়ানোর দরকার পড়ে তাহলে আমাকে কেন পুরো সিস্টেমটা Dedicated সার্ভারে আপগ্রেড করতে হবে ? সার্ভার নিজের বানানো হলে, কেন আমাকে পুরোনো পিসি ফেলে দিয়ে নতুন মাদারবোর্ড, নতুন প্রসেসর, নতুন ডিস্ক নিয়ে আরেকটি বড় নতুন সার্ভার সেটাপ করতে হবে?

প্রশ্নোত্তর

১) অনেকের হয়তো প্রশ্ন আসতে পারে যে গেদু ভাইয়ের ফ্যামিলি মেম্বার-রা অন্য কোন পরিবহনে গেলেই তো পারে । হ্যা তা পারে ! তবে আপনি নিশ্চই চাইবেন না যে আপনার কাস্টমার আপনার সার্ভিসে অসন্তুষ্ট হয়ে কিংবা আপনার ব্যর্থতার কারনে অন্য কারো সার্ভিস ব্যবহার করুক । আপনার সিস্টেমের ব্যবহারকারী আপনার পরিবার এবং তাদের কে তাদের সময়ে প্রয়োজন অনুযায়ী সার্ভিস দিতে পারলেই কেবল আপনি সাকসেস হতে পারবেন । তবে হ্যা ! আপনি নিজে যদি অন্য কোন পরিবহন সার্ভিস ভাড়া করে আপনার ফ্যামিলিকে বা ব্যবহারকারীকে সার্ভিসটি দেন তবে সেটা হরিজন্টাল স্কেলিং । যেমন ফাইল স্টোরেজের জন্য Azure Storage বা Amazon S3 ব্যবহার করা ।

২) কিংবা কেউ ভাবতে পারে চারটি গাড়ির জন্য তো চারটি আলাদা ড্রাইভার লাগবে এবং প্রতেকটি গাড়ির আলাদা মেইন্টেইনার এবং কিছু বাড়তি খরচও থাকতে পারে ।  উত্তর হল : Time is money ! সবাই বাসে বসে, কিংবা বাসের জন্য অপেক্ষা করে অঝথাই সময় করছে । সময় মত পৌছাতে না পারলে হয়তে ছেলের চাকরি থাকবে না, কিংবা নাতি-নাতনির পরীক্ষা দেয়া হবে না । আপনার প্রশ্নের উত্তরে আমি বলব : The faster you deliver you service with efficiency the faster you earn money. আপনিই চিন্তা করে বলুন গুগলে সার্চ দেয়ার ১ঘন্টা পর যদি রেজাল্ট আসত এবং অন্য সার্চ এন্জিন যদি তা ১ মিনিটে করতে পারত তবে আপনি কোনটা ব্যবহার করতেন ? আসলে মুল বিষয়টা টাকার নয়, সার্ভিস ইফিসিয়েন্সির উপর ।

সার্ভার স্কেলিং এর শুরুতে আপনাকে স্বাগতম

এবার সার্ভার স্কেলিং এর মুল পর্বে  আসা যাক। পরবর্তী পোস্ট এ ভার্টিক্যাল স্কেলিং এবং হরিজন্টাল স্কেলিং নিয়ে বিস্তারিত আলোচনা করব । ভালো লাগলে শেয়ার করতে কিংবা আপনার মন্তব্য জানাতে ভুলবে না !


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ডিজাইনিং রেস্ট এপিআই [৬] : এপিআই ডকুমেন্টেশন

বেশিরভাগ ডেভেলপাররা এপিআই ইম্পিলিমেন্ট করে তাদের শ্রম নষ্ট করার আগে এপিআই ডকুমেন্টেশন পড়ে বুঝতে চেষ্টা করে যে এপিআই টা তাকে কি দিতে পারে এবং কত সহজে দিতে পারে । তাই একটি ভাল ডকুমেন্টেশন এপিআই সাক্সেস এর জন্য অনেক গুরুত্বপূর্ন । শুধুমাত্র এপিআই ফাংশনালিটি সুন্দরভাবে প্রেজেন্ট করলেই সেটি একটি ভালো ডকুমেন্টেশন হয়ে যায় না । ডকুমেন্টেশনের পাশাপাশি ইম্পলিমেন্টেশনের কিছু উদাহরন এবং লাইভ এক্সপ্লোরার ডেভেলপারদের মনোযোগ বেশি আকৃষ্ট করে । তাই শুধু এপিআই ডেভেলপমেন্ট না, একটি ভালো ডকুমেন্টেশনের জন্যেও আপনাকে অনেক শ্রম ব্যয় করতে হবে।

 

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state.

— Roy Fielding, REST APIs must be hypertext driven

 

রেস্ট এপিআই ডকুমেন্টেশন

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

অটোমেটেড এপিআই ডকুমেন্টেশন

এমন যদি হত যে, আমি কোড করব সাথে সাথে এপিআই কনজিমারদের জন্য একটি ডকুমেন্টেশন অটোমেটিক তৈরী হয়ে যাবে ! পুরোপুরি এমন না হলেও জনপ্রিয় প্রোগ্রামিং ল্যাঙ্গুয়েজ যেমন সি++ , জাভা ইত্যাদির জন্য ডক্সিজেন, জাভাডক্স এর মত অনকে অটোমেটেড টুল আছে যা ডকুমেন্টেশন অনেক সহজ করে দিয়েছে । রেস্ট আর্কিটেকচারের জন্য অটোমেটেড কিছু টুল থাকলেও সেগুলো ব্যবহারের পূর্বে আপনাকে ভালোভাবে বুঝে শুনে করা উচিত । কারন রেস্ট এপিআই এর ডকুমেন্টেশন অন্যন্য প্রোগ্রামিং ল্যাঙ্গুয়েজ এর একটু ভিন্ন । রেস্ট এপিআই ডকুমেন্টেশন হল, রিকোয়েস্ট কোন URI তে কোন ফরম্যাটে কি প্যারামিটার দিয়ে সেন্ড করতে হবে তার একটি রিপ্রেজেন্টশন । যেহেতু রেস্ট এপিআই এর রিকোয়েস্ট ম্যাপিং এর জন্য নির্দিষ্ট কোন স্ট্যান্ডার্ড নেই সেহেতু আপনার কোড থেকে অটোমেটেড ডকুমেন্টেশন তৈরী করা অনেকটা অসম্ভব। এক্ষেত্রে দুটি সম্ভাব্য সমাধানের কথা ভেবে দেখা যেতে পারে

১। কোড থেকে ডকুমেন্টেশন জেনারেট

কোডের পাশাপাশি রেস্ট এপিআই ডকুমেন্টেশন জেনারেট করার জন্য  ভালো ফ্রেমওয়ার্ক খুব কমই আছে ।জাভাবেজড এপিআই এর জন্য Enunciate একটি ভাল উদাহরন হতে পারে।

কোড থেকে এপিআই ডকুমেন্টেশন জেনারেট করার আরেকটি সহজ উপায় হল কোডের কমেন্ট ।

/**
* @api {put} /user/:id Change a User
* @apiVersion 0.3.0
* @apiName PutUser
* @apiGroup User
* @apiPermission none
*
* @apiDescription This function has same errors like POST /user, but errors not defined again, they were included with "apiErrorStructure"
*
* @apiParam {String} name Name of the User.
*
* @apiUse CreateUserError
*/
function putUser() {
.....your api code ...
return;
}

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

২। ওয়ান-টু-ওয়ান ম্যাপিং এর একটি ফরম্যাটেড ডাটা স্ট্রাকচার

এক্ষেত্রে আপনার রিকোয়েস্ট ম্যাপিংগুলোকে একটি নির্দিষ্ট ডাটা ফরম্যাটে সাজিয়ে একটি টুল দ্বারা প্রেজেন্ট করা হয় ।

Swagger – রেস্টফুল এপিআইকে সম্পূর্ন এবং স্মার্ট ভাবে রিপ্রেজেন্ট করার জন্য এটি একটি অসাধারন টুল । এই টুলটির আরো দুটি জনপ্রিয়ে অলটারনেট হল RAML এবং Api BluePrint

jsondoc: একটি জেসন ডকুমেন্ট থেকে এপিআই ডকুমেন্টেশন জেনারেট করতে এর জুড়ি নেই।


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ডিজাইনিং রেস্ট এপিআই [৫] : এপিআই ভার্সনিং

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

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

এপিআই ভার্সনিং

এপিআই ভার্সনিং হল আপনার র্বতমান সার্ভিসটি ঠিক রেখে নতুন কোন পরিবর্তন আনার একটি সহজ উপায় । আপনার যখনই কোন পরিবর্তন আনতে চান তখনই আপনাকে মাথায় রাখতে হবে যে আপনি আগের ভার্সনে কোন পরিবর্তন আনতে পারবেন না। ছোট পরিকর্তন হলেও সেটিকে আরেকটি ভার্সনে [ v1.06 অথবা v2.0 ] পাবলিশ করতে হবে। তবে ছোট ছোট পরিবর্তন কমিয়ে একটি মুখ্য [v1 » v2 » v3] স্ট্যাবল রিলিজ দেয়াই ভাল। এতে যেমন ইনভ্যালিড রিকোয়েস্ট কমে যায় তেমনি কনজিমারদের মধ্যে দ্বিধা সৃষ্টি হয় না ।
‌এপিআই ভার্সনিং এবং ভার্সন ম্যানেজমেন্ট

উপরের চিত্রের মত প্রতিটি নতুন ভার্সন আপনার সার্ভিসকে আগের চেয়ে ভালো এবং একটু আলাদা ভাবে প্রেজেন্ট করবে। তাই এপিআই এর প্রথম ভার্সনের জন্যেও আপনাকে এপিআই ভার্সনিং ফলো করতে হবে । কখনই প্রথম ভার্সনটি ভার্সন আডেন্টিফায়ার ছাড়া পাবলিশ করা উচিত না। ভার্সনিং রেস্ট এপিআই ডিজাইনের একটি বাধ্যতামূলক কম্পোনেন্ট এবং প্রথম ভার্সনটির ক্ষেত্রে host.com/api/user এর পরিবর্তে host.com/api/v1/user v+ভার্সন কোড দিয়ে প্রকাশ করতে হবে।

Versioning an interface is just a “polite” way to kill deployed clients.

— Roy Fielding.

ভার্সন ম্যানেজ করবেন কিভাবে?

কখন কেন নতুন ভার্সন আনবেন সেটা নিয়ে আপনাকে অবশ্যই বিশদ বিশ্লেষন করে একটি উপযুক্ত সিদ্ধান্তে আসতে হবে। কখন সিদ্ধান্ত নিবেন যে আরকটি নতুন ভার্সন আনবেন? আপনি যদি এপিআই এর সম্পূর্ন কোড ফেলে দিয়ে নতুন করে আবার আরেকটি এপিআই বানান এবং ফাংশনালিটি অর্থাৎ ইনপুট আউটপুটে কোন পরিবর্তন না আসে তাহলে আপনার নতুন ভার্সনের কোন প্রয়োজন নেই । ব্যাক-এন্ড এ আপনি হয়তো আগে MySQL ডাটাবেজ ব্যবহার করছেন, কিন্তু এখন MongoDB ব্যবহার করবেন তাতে কি এপিআই কনজিউমারের কিছু যায় আসে? সুতরাং কেবল মাত্র যখনই নতুন কোন ফিচার বা ফাংশনালিটি যোগ বা পরিবর্তন করবেন কেবল তখনই আপনার আরেকটি ভার্সনের প্রয়োজন পড়বে।

কতগুলো ভার্সন ম্যানেজ করবেন ?

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

প্রশ্ন: কতগুলো পুরোনো ভার্সন আপনাকে সাপোর্ট দিতে হবে ?

যদি আপনি একবছর পর পর একটি নতুন ভার্সন আনেন তাহলে ২টি পুরোনো ভার্সন, আর ২ বছরে একটি ভার্সন আনলে ১টি বা ২টি পুরোনো ভার্সন রাখতে পারেন । তবে যদি এমন হয় যে আপনার পুরোনো এপিআইটি কেউ ব্যবহার করছে না তাহলে আপনি সাথে সাথে ডকুমেন্টেশন সহ পুরোনো এপিআই  বাতিল করে দিতে পারেন । মনে রাখতে হবে, এপিআই আপডেট নিউজ ব্যবহারকারীকে ইমেইলে নোটিফাই করতে হবে এবং নতুন ভার্সন রিলিজের পর ব্যবহারকারীকে তাদেরকে সিস্টেম আপগ্রেড করার জন্য কমপক্ষে ৬ মাস সময় দিতে হবে।

এপিআই ভার্সনিং কিভাবে করবেন?

এপিআই ভার্সনিং দুইভাবে করা যায় ।  ভার্সন ইনফরমেশন আপনি নিচের মত করে হেডারে যোগ করে রিকোয়েস্ট করতে পারেন। আপনি যদি স্ট্যান্ডার্ড হাইপারমিডিয়া ব্যবহার করতে চান তবে এটাই সবচেয়ে ভাল উপায় ।

GET /customer/123 HTTP/1.1
Accept: application/vnd.company.myapp.customer-v3+json

অথবা ভার্সন কোড সরাসরি লিংক এ জুড়ে দিতে পারেন ।

http://example.com/api/v3/posts/56

তবে কোনটা সঠিক এটা নিয়ে অনেক ভিন্ন মত আছে । ব্যাক্তিগত ভাবে আমি গুগলের এপিআই ভার্সনিং স্টাইলটাই পছন্দ করি । লিংক এ ভার্সন কোড থাকাটাই আমার কাছে বেশি ইউজার ফ্রেন্ডলি মনে হয় ।

https://www.googleapis.com/apiName/apiVersion/resourcePath?parameters

https://www.googleapis.com/blogger/v2/blogs/blogId/posts/postId
https://www.googleapis.com/blogger/v2/blogs/blogId/posts/postId/comments

ভার্সনিং বিতর্ক

এপিআই ভার্সনিং স্টাইল নিয়ে বিতর্কের শেষ নেই । কারো মতে হাইপারমিডিয়া বা কন্টেন্ট টাইপ হেডারে যুক্ত করে রিকোয়েস্ট করাটা অধিকতর যুক্তি সম্মত আবার কারো কাছে লিংক বা URI তে থাকাই ভাল । কেউ কেউ আবার দুইটা মেথড রাখা ভাল মনে করেন।

বিতর্ক মেথড
Stack Overflow 1 লিংক
Stack Overflow 2 হাইপারমিডিয়া
Stack Overflow 3 হাইপারমিডিয়া
Stack Overflow 4 হাইপারমিডিয়া
Nick Berardi on REST versioning লিংক

লিংক দিয়ে ভার্সনিং কারা করছে?

স্ট্যান্ডার্ড হিসেবে আমি যাদের কাজ কে ফলো করি তাদের বেশির ভাগই তাদের এপিআই ভার্সন কোড URI বা লংক-এ ব্যবহার করেছেন।

এপিআই উদাহরন
Twitter https://api.twitter.com/1.1/statuses/user_timeline.json
Atlassian http://host:port/context/rest/upm/1/…
Google Search https://www.googleapis.com/customsearch/v1?parameters
Facebook http://graph.facebook.com/v1.0/me
Bing Maps http://dev.virtualearth.net/REST/v1/Locations/UK/postalCode?
Delicious https://api.del.icio.us/v1/posts/update
Last FM http://ws.audioscrobbler.com/2.0/
LinkedIn http://api.linkedin.com/v1/people/~/connections
paypal https://api.paypal.com/v1/payments/orders/<Order-Id>
Tumblr api.tumblr.com/v2/user/
openstreetmap http://server/api/0.6/changeset/create
Groupon http://api.groupon.com/v2/channels//deals{.json|.xml}
Disqus https://disqus.com/api/3.0/forums/listPosts.json?forum=disqus
Drop Box https://api.dropbox.com/1/oauth/request_token
Youtube https://www.googleapis.com/youtube/v3

এপিআই ভার্সনিং নিয়ে বিতর্ক এবং রকমারি ব্যবহাররের পুরো লিস্টটি পাবেন এখানে ।


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ডিজাইনিং রেস্ট এপিআই [৪] : ইরর ডিজাইন

আমরা অনেক ধৈর্য আর যত্ন সহকারে কোড করি কিন্তু দুর্ভাগ্যবশত সবসময় কিছু না কিছু ভুল থেকেই যায় । সিস্টেমটির যেভাবে কাজ করার কথা ছিল সেভাবে কেন কাজ করছে না এর উত্তর তখন আমাদের কাছে অনেক মূল্যবান । আর রেস্ট এর ক্লায়েন্ট এ্যাপ্লিকেশন ডেভেলপারদের কাছে এই উত্তর টা বের করা মোটামুটি এভারেস্ট জয়ের মত। কারন তারা শুধুমাত্র আপনার এপিআই কিভাবে ব্যবহার করতে হবে তার একটি নিয়মকানুন ব্যতিত এপিআই এর ভিতরকার আচরনবিধি কিছুই জানে না। উদাহরন হিসেবে ধরুন আপনি ফেসবুক এপিআই তে একটি জটিল কোয়েরী রিকোয়েস্ট করলেন আর ফেসবুক রেসপন্স করল:

"error" : "An error occurred"

এই একটি লাইন মেসেজ থেকে আপনি কিভাবে বুঝবেন আপনার ভুলটা কোথায়? যদি ফেসবুকের অফিশিয়াল সাইটে যদি আপনি এর কারন খুজে নাও পান তবে একটু খোজাখুজি করলে বিভিন্ন ফোরাম বা স্ট্যাকওভারফ্লোতে এর উত্তর পাবেনই । কিন্তু এটা যদি ফেসবুক না হয়ে নতুন একটি এপিআই হত তাহলে এর উত্তর খুজতে আপনার হয়ত কয়েক দিন লেগে যেত । কিন্তু এপিআই যদি আরেকটু সুন্দর ভাবে ইররটি রিটার্ন করত :

"error" : "Invalid Access Token"
"details": "The token is not valid or expired.Also check the timestamp"
"link" : "http://host.com/api/documentation/invalid-access-token.html"

উপরের রেসপন্সটি দেখে আমি সহজেই বুঝতে পারি ভুলটি কোথায় । আর তাতেও যদি সমস্যা সমাধান না হয় তাহলে লিংকটি থেকে বিস্তারিত কারন দেখে সমস্যা সমাধান কোন ব্যাপার না।

সুতরাং এপিআই কনজিউমারদের ইরর হ্যান্ডলিং এর জন্য আপনাকে বলে দিতে হবে কোথায় কেন ইরর ঘটল। তাহলে এখন আমরা দেখব আমাদের ইরর ডিজাইন কেমন হওয়া উচিত।

HTTP স্ট্যাটাস কোডের সঠিক ব্যবহার

HTTP স্ট্যাটাস কোড একটি স্ট্যান্ডার্ড মডেল এবং ক্লায়েন্ট এ্যাপ্লিকেশন এটি খুব সহজেই হ্যান্ডেল করতে পারে। সকল রিকোয়েস্ট এর জন্য ঢালাওভাবে 200 [OK] রিটার্ন না করে প্রতিটি রিকোয়েস্ট এর জন্য সামঞ্জস্যপূর্ন কোড ব্যবহার করতে হবে ।  সফলভাবে রিকোয়েস্ট এক্সিকিউট হলে 2xx স্ট্যাটাস কোড রিটার্ন করবেন । আর তা না কোন কারনে রিকোয়েস্ট ফেইল করল তা যতটা সঠিক এবং  স্পষ্ট করে রিটার্ন করতে হবে। এক্ষেত্রে মনে রাখতে হবে যে ইরর দুটি কারনে হয় :

১। 4xx ক্লায়েন্ট ইরর – এপিআই ক্লায়েন্ট ভুল ভাবে রিকোয়েস্ট সেন্ড করেছে। ক্লায়েন্ট এর রিকোয়েস্ট এ কোন ভুল থাকলে 4xx ইরর কোড ব্যবহার করা হয় । অর্থাৎ একই রিকোয়েস্ট বারবার  না করে বরং ভুলটি সুধরে পুনরায় রিকোয়েষ্ট করতে হবে।

২। 5xx সার্ভার ইরর – রিকোয়েস্ট হ্যান্ডেল করতে সার্ভার ব্যার্থ হয়েছে । সার্ভার ইন্টারনাল কোন কারনে রিকোয়েস্ট প্রসেস করতে ব্যর্থ হলে 5xx ইরর কোড ব্যবহার করা হয়। অর্থাৎ রিকোয়েস্ট এ কোন প্রকার পরিবর্তন না এনে ক্লায়েন্ট পুনরায় চেষ্টা করতে পারবে।

নিচে রেস্ট এপিআই এর সবচেয়ে কমন ১০টি স্ট্যাটাস কোড দেয়া হল, সম্পূর্ন লিস্ট দেখতে উইকিপিডায়া দেখুন-

200 সব ঠিকঠাক আছে
201 সব ঠিক আছে এবং রিসোর্স তৈরী করা হয়েছে
304 ক্যাশ এ রাখা ডাটা এখনও অপরিবর্তিত আছে
400 রিকোয়েস্ট ডাটা বা ফরম্যাট ঠিক না
যেমন প্যারামিটার মিসিং, প্যারামিটার এর টাইপ ভুল দেয়া, ভুল এক্সেস টোকেন ইত্যাদি
401 অপারেশনটি করার জন্য আপনার অনুমতি নেই
403 কোন প্রকার অনুমতি কাজে দিবে না। আপনি রাস্তা মাপেন !
404 রিসোর্স খুজে পাওয়া যায়নি
405 মেথড গ্রহনযোগ্য নয়
500 ইন্টারনাল সার্ভার ইরর
503 এই মুহুর্তে সাভার রিকোয়েস্ট টি হ্যান্ড্যেল করতে পারছে না ।
সার্ভার ক্রাশ, মেইনটেনেন্স, ওভারলোড, ব্যাডন্ডওইথ সীমবদ্ধতা ইত্যাদি কারনে সার্ভিসটি একটিভ না

বর্ননামূলক ইরর মেজেস

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

ইরর ডিজাইন   Invalid Request
ইরর ডিজাইন   An error occurred
ইরর ডিজাইন   Access token is required to complete this operation

একাধিক ইরর মেসেজ

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

ইরর কোড

এটি HTTP স্ট্যাটাস কোড নয় বরং এই কোড একটি ইররকে আইডেন্টিফাই করে। এই কোড একটি ইররকে আরো বিস্তারিত ভাবে ডেভেলপারদের কাছে তুলে ধররা জন্য ব্যবহার করা হয় । রেসপন্স এ ইরর কোড ইম্প্লিমেন্ট করার আগে অবশ্যই এগুলোর ডকুমেন্টেশন নিশ্চিত করতে হবে। HTTP স্ট্যাটাস কোড আর ইরর কোডের একটি চমৎকার উদাহরন পাবেন টুইটার এপিআ্ই ডকুমেন্টেশনে

ইরর লিংক

 ইরর এর কারন সম্পর্কে বিস্তারিত জানার জন্য  ডকুমেন্টেশন লিংক প্রতিটি রেসপন্সের সাথে যুক্ত করে দিতে হবে। তবে ডকুমেন্টেশন না থাকলে এমন কোন সাপোর্ট লিংক দিন যেখানে ডেভেলপার এই ইররের সমাধান পাবে ।

একটি আদর্শ ইরর ডিজাইন

{
"status":400,
 "error" : 
   {
    "code" : "E9081",
    "message" : "Access token required",
    "description":"Access token is required to complete this operation.",
    "link" : "http://host.com/docs/errors/e9081/"
   }
}

উদহরনে একটি ছোট ইররকে প্রেজেন্ট করা হয়েছে এভাবে:

  • status: 400 অর্থাৎ ক্লায়েন্ট এর কোন ভুলের কারনে রিকোয়েস্ট সফল হয়নি ।
  • message: সেই ভুলটি টি ছোট করে বলা হয়েছে । এই ধরনের মেসেজ সাধারনত পপআপ বা ডায়ালগে বেশি ব্যবহৃত হয় ।
  • description: এখানে ভুলের কারন এক বা একধিক লাইনে ডেভেলপারদের জন্য বর্ননা করা হয়।
  • code: উক্ত ইররকে আলাদাভাবে চিহ্নিত করার জন্য একটি কাস্টম কোড E9081 দেয়া হয়েছে ।
  • link: ইরর E9081 এর কারন এবং সমাধানের জন্য ডকুমেন্টেশন লিংক দেয়া আছে।
 শেষ করার পূর্বে গুগলের একটি ইরর রেসপন্স দেখে নেই
{"error": 
    {"errors": 
      [
        {
          "domain": "global",
          "reason": "invalidParameter",
          "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000],
          "locationType": "parameter","location": "max-results"
        }
      ],

    "code": 400,
    "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
    }
}

মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ডিজাইনিং রেস্ট এপিআই [৩] : এপিআই অথেনটিকেশন

এপিআই অথেনটিকেশন রেস্ট ডেভেলপারদের কাছে একটি চ্যালেন্জ । রেস্ট এর একটি কম্পোনেন্ট হল এপিআই অবশ্যই স্টেটলেস হতে হবে যেটি client-stateless-server (CSS) এ সঙ্গায়িত করা হয়েছে । রেস্ট এর স্ট্রাকচার সবাই মানলেও অথেন্টিকেশনের সময় বেশিরভাগ ডেভেলপারই এই দিকটা এড়িয়ে চলে । এই পর্বে রেস্টফুল এপিআই অথেনটিকেশন নিয়ে আলোচনা করব ।

এপিআই অথেনটিকেশন

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

আমাদের পরিচিত ওয়েব অথেনটিকেশন

স্ট্যান্ডার্ড HTTP সেশন বেজ অথেনটিকেশনের কিছু কমন স্টেপ হল

১। ক্লায়েন্ট ব্যবহারকারীর লগিন তথ্য সার্ভারে সেন্ড করে ।
২। সার্ভার সেই তথ্য ভেরিফাই করে একটি টোকেন জেনারেট করে ।
৩। এই টোকেন সার্ভার এবং ক্লায়েন্ট কুকিতে [sessionid=random-token] স্টোর থাকে।
৪। এখন ক্লায়েন্ট প্রতিটি রিকোয়েস্ট এর সাথে কুকি হেডারটি যুক্ত করে রিকোয়েস্ট সেন্ড করে।
৫। সার্ভার সেই টোকেনটি দিয়ে ডাটাবেজে কোয়েরী করে ব্যবহারকারীকে সনাক্ত করে।

Oauth2 অথেনটিকেশন

১। ক্লায়েন্ট ব্যবহারকারীর লগিন তথ্য সার্ভারে সেন্ড করে ।
২। সার্ভার সেই তথ্য ভেরিফাই করে একটি টোকেন জেনারেট করে ।
৩। এই টোকেন সার্ভারে স্টোর থাকে এবং টোকেনটি রেসপন্স বডিতে রিটার্ন করে।
৪। এখন ক্লায়েন্ট প্রতিটি রিকোয়েস্টের “Authorization” হেডারে ঐ টোকেনটি যুক্ত করে রিকোয়েস্ট সেন্ড করে।
৫। সার্ভার সেই টোকেনটি দিয়ে ডাটাবেজে কোয়েরী করে ব্যবহারকারীকে সনাক্ত করে।

কোনটি স্টেটলেস?

দুইটির মধ্যে পার্থক্য করে সহজেই বুঝতে পারি যে স্ট্যান্ডার্ড HTTP  সেশন অথেনটিকেশনের সাথে ওঅথ২ এর তেমন কোন পার্থক্য নেই । শুধু পার্থক্যটা হল রিকোয়েস্ট করার সময় দুটি মেথড দুটি ভিন্ন হেডার ব্যবহার করে। শুধু মাত্র হেডারের পার্থক্য থাকলেই তাকে আমারা স্টেটলেস বলতে পারি না । আমরা চাইলে টোকেন হেডারটি Authorization ফিল্ড এ না রেখে আমাদের মন মত একটি কাস্টম হেডারে সেন্ড করলেও কিছু যায় আসে না। স্টেটলেস আমরা তখনই বলতে পারি যখন অথোরাইজেশন টোকেনটি স্ট্যাটিক হবে অর্থাৎ এর কোন সেশন বা মেয়াদকাল থাকবে না । যেহেতু মেথড দুটি দ্বারা যে টোকেন জেনারেট হয় তা একটি সময় পর আর ভ্যালিড থাকে না তাই এই মেথডগুলো স্টেটলেস হতে পারে না ।

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

Like most real-world systems, not all components of the deployed Web architecture obey every constraint present in its architectural design. REST has been used both as a means to define architectural improvements and to identify architectural mismatches. Mismatches occur when, due to ignorance or oversight, a software implementation is deployed that violates the architectural constraints. While mismatches cannot be avoided in general, it is possible to identify them before they become standardized.

স্টেটলেস অথেনটিকেশন কি ?

আবারো বলতে হয়, স্টেটলেস মানে হল রিকোয়েস্ট এর কোন সময় সাপেক্ষিক ভ্যালিডিটি থাকবে না । তাহলে শুধু মাত্র টোকেন দিয়ে স্টেটলেস রিকোয়েস্ট করা কি সম্ভব ? উত্তর হ্যা ! খুব সহজেই আপনি তা করতে পারেন । নিচের ছবিটির দিকে খেয়াল করুন

এপিআই অথেনটিকেশন

ফেসবুক এবং টুইটার অথেনটিকেশনের জন্য দুইটি ভিন্ন টোকেন প্রোভাইড করে থাকে । এগুলোর মধ্যে একটি পাবলিক আরেকটি প্রাইভেট বা সিক্রেট  টোকেন [KEY]

পাবলিক এপিআই টোকেন

উপরের চিত্রে AppID/API key/Consumer key হল পাবলিক টোকেন যা আপনি প্রতিটি রিকোয়েস্ট এর সাথে সার্ভারে সেন্ড করবেন । এই টোকেনটি যদি অন্য কেউ জেনে যায় তাহলে আপনার তেমন কিছু যায় আসে না । বুঝার জন্য ধরে নিতে পারেন এটি আপনার লগিন ইউজার নেম ।

https://maps.googleapis.com/maps/api/geocode/json?address=abc&key=API_KEY

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

প্রাইভেট এপিআই টোকেন

প্রাইভেট বা সিক্রেট এপিআই টোকেন ব্যবহারের ক্ষেত্র আপনাকে অনেক সতর্ক থাকতে হবে । পাবলিক এপিআই টোকেন আপনি রিকোয়েস্ট এর প্যারমিটার হিসেবে ব্যবহার করতে পারবেন, কিন্তু সিক্রেট টোকেন কখনই কোন রিকোয়েস্ট বা রেসপন্স হিসেবে আদানপ্রদান করতে পারবেন না । এই টোকেনটির মাধ্যমে রিকোয়েস্ট এর সিগনেচার কোড জেনারেট করা হবে এবং এই কোড আপনি আর সার্ভার ব্যাতিত অন্য কেউ জেনারেট করতে পারবে না ।  প্রাইভেট এপিআই টোকেন এর মাধ্যমে রিকোয়েস্টের ডাটা HMAC এলগরিদমে এনক্রিপ্ট করে সেটি হেডার এর Authorization যোগ করে দিতে হবে। এখন সার্ভার যথন রিকোয়েস্ট পাবে সেও একইভাবে ডাটাগুলোকে এনক্রিপ্ট করে একটি হ্যাশ জেনারেট করবে । যদি আপনার দেয়া হ্যাশকোড আর সার্ভারের হ্যাশ কোড মিলে যায় তাহলে রিকোয়েস্ট এক্সেপ্ট করবে নতুবা ইনভ্যালিড অথেনটিকেশন রিটার্ন করবে । হ্যাশ কোড জেনারেট করার জন্য খুবই ছোট PHP কোড:

$data = $request_uri . $content_type. $content_body;
$hash =  hash_hmac ( "sha1", $data, PRIVATE_KEY );
PUT /accounts/12 HTTP/1.1
 Host: localhost
 Authorization: 8458fh9385793fheoiw9375398450394oniu
 Cache-Control: no-cache
 Content-Type: application/x-www-form-urlencoded

 param=this-is-the-request-body

আমাজন এস৩ রেস্ট অথেনটিকেশন যেভাবে হ্যাশ কোড জেনারেট করে তার একটি উদাহরন:

h = hmac.new("OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV",
    "PUT\nc8fdb181845a4ca6b8fec737b3581d76\ntext/html\nThu, 17 Nov 2005 18:49:58 GMT\nx-amz-magic:ab
     racadabra\nx-amz-meta-author:foo@bar.com\n/quotes/nelson",sha)
base64.encodestring(h.digest()).strip()

এভাবে রিকোয়েস্ট করার কিছু সুবিধা হল :

  • যেহেতু সেশন স্টোরেজ এর প্রয়োজন পড়ছে না তাই বাড়তি সার্ভার স্পেস এর প্রয়োজন হচ্ছে না ।
  • মাল্টিসার্ভার সিস্টেমের জন্য ইউজার ভ্যালিডেশনের জন্য আলাদা কোন প্রসেসের প্রয়োজর পড়ছে না ।
  • হাই পারফরমেন্স ! সার্ভার টু সার্ভার কমিউনিকেশনের জন্য অসাধারন মেথড ।

টাইম স্ট্যাম্প কেন দরকার ?

রিকোয়েস্ট করার সময় একটি বাড়তি টাইমস্ট্যাম্প প্যারামিটার দেয়া উচিত যা রিকোয়েস্ট টাইম বা রিকোয়েস্ট  এক্সপায়ার টাইম হিসেবে ধরা হবে। টাইম স্ট্যাম্প যুক্ত করলে স্টেটলেস এর সূত্র ক্ষুন্ন হয় না, কারন এটি একটি ভ্যালিডেশন প্যারামিটার মাত্র এবং এটি কোন ইউজারের সেশন কে প্রকাশ করে না । বরং এটি ঐ রিকোয়েস্ট এর সময়কালকে প্রকাশ করে । ধরুন পুরো রিকোয়েস্ট টি প্রাইভেট টোকেন দিয়ে এনক্রিপ্ট করার পর হ্যাশ কোডটি যদি vjbyPxybdZaNmGa%2ByT272YEAiv4%3Dহয় তাহলে সম্পূর্ন রিকোয়েস্টি হবে এমন :

http://s3.amazonaws.com/quotes/nelson?AWSAccessKeyId=44CF9590006BF252F707&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D&data=some-data

এখন এই লিংকটি অন্যকেউ ক্লায়েন্ট বা ব্রাউজার হিস্টোরি থেকে কিংবা স্নাইফিং করে আবার রিকোয়েস্ট করলে সার্ভাস বুঝতে পারবে যে রিকোয়েস্ট টি ইনভ্যালিড । কেউ যদি Expires=1141889120 এর মান পরিবর্তন করে দেয় তাহলে রিকোয়েস্ট টি এনক্রিপ্ট করলে হ্যাশ কোড আর  vjbyPxybdZaNmGa%2ByT272YEAiv4%3D থাকবে না সুতরাং রিকোয়েস্ট টি ইনভ্যালিড হিসেবে গন্য হবে।

বেসিক HTTP অথেনটিকেশন

এই দুটি পদ্ধতি ছাড়াও অথেনটিকেশনের জন্য অনেকেই বেসিক HTTP অথেনটিকেশন ব্যবহার করেন এবং এটি সম্ভবত সবচেয়ে সহজ অথেনটিকেশন মেথড। আপনি যদি অথেনটিকেশন এর জন্য বেসিক HTTP অথোরাইজেশন চিন্তা করে থাকেন তাহলে আপনাকে অবশ্যই SSL বা HTTPS প্রোটেকলের মাধ্যমে রিকোয়েস্ট করতে হবে । কারন বেসিক HTTP অথোরাইজেশন ব্যবহৃত Base64 এনক্রিপশন যে কেউ সহজেই ডিকোড করতে পারবে ।

Authorization: Basic aWtydW06bG92ZQ==

SSL আবশ্যক :

নেটওয়ার্ক  স্নাইফিং করা আজকাল ছেলেখেলা হয়ে গেছে । তাই রিকোয়েস্ট ডাটার সুরক্ষায় একটি ভাল SSL ব্যবহার করা উচিত । আর বেসিক HTTP অথেনটিকেশন SSL ব্যতিত চিন্তাও করা ঠিক হবে না। মনে রাখবেন Self-signed SSL ব্যবহার করা আর না করা একই কথা।


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!

ডিজাইনিং রেস্ট এপিআই [২] : রিকোয়েস্ট এবং রেসপন্স

এপিআই ডেভেলপের ক্ষেত্রে আমাদের অবশ্যই মাথায় রাখতে হবে যেন এপিআই টি কনজিউমারদের কাছে অনেক ফ্লেক্সিবল হয়। বিভিন্ন প্লাটফর্মে রেস্ট এপিআইতে রিকোয়েস্ট করতে গিয়ে নতুনদের অনেক হিমশিম খেতে হয় । যারা কখনও PUT এবং DELETE ব্যবহার করেননি তারা হয়তো অনেকেই ভাবছেন এইচ.টি.এম.এল ফরম কিংবা প্রোগ্রামিং ল্যাংগুয়েজে যেভাবে GET, POST রিকোয়েস্ট করেন সেভাবে করলেই হয়ে যাবে।

<form method="DELETE" action="update.php"> .... </from>

না বিষয়টা মোটেই তেমন না । বেশিরভাগ ব্রাউজার, ফ্রেমওয়ার্ক,সার্ভিস এবং ফায়ারওয়াল GET, POST ছাড়া অন্যন্য মেথড যেমন HEAD, PUT, DELETE, OPTION, PATCH ইত্যাদি সাপোর্ট করে না । সেক্ষেত্রে এপিআই কনজিউমার-রা কি করবে?

রিকোয়েস্ট মেথড ওভাররাইড

POST মেথডের হেডারে একটি বাড়তি মেথড প্যারামিটার যোগে রিকোয়েস্ট করে মেথড ওভাররাইড করতে পারেন । বস পাবলিকরা যেভাবে কাস্টম হেডার প্রস্তাব করেন:

উল্ল্যেখ্য বেশিরভাগ এপিআই এবং ওয়েব সার্ভিস X-HTTP-Method-Override ব্যবহার করে  । আরো কিছু কমন ওভাররাইড হেডার সম্পর্কে জানতে উইকিপেডিয়া দেখুন । POSTMAN এক্সেটনশন ব্যবহার করে একটি PUT রিকোয়েস্ট এবং তার প্রিভিউ দেখা যাক:

পোস্টম্যান পুট রিকোয়েস্ট

PUT HTTP/1.1
Host: localhost
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

name=newName&address=newAddress

এখন কনজিউমার যেহেতু PUT করতে অক্ষম সেহেতু আমাদেরকে কিছু বিকল্প সামাধানের কথা চিন্তা করতে হবে। আমরা যদি সরাসরি এইচ.টি.এম থেকে রিকোয়েস্ট এর সুবিধা দিতে চাই তবে POST রিকোয়েস্ট এ একটি হিডেন ইনপুট যোগ করে দিলেই ঝামেলা শেষ। এক্ষেত্রে GET মেথড ব্যবহার করা মোটেই উচিত না কারন PUT এর ইনপুট, পার্সওয়ার্ড এর মত গুরুত্বপূর্ন ডাটা হতে পারে যেটা URL এ দেয়াটা বুদ্ধিমানের কাজ হবে না।

<from method="POST" action="http://localhost/api/book/55"> 
<input name="X-HTTP-Method-Override" type="hidden" value="PUT" />
<input name="description" type="text" />
....
</from>

সম্পূর্ন ব্যাপারটি হ্যান্ডেল করার জন্য একটি পি.এইচ.পি কোডটি খেয়াল করুন :

function getMethod(){
	// Handling HTML method override
	if ( isset( $_POST['X-HTTP-Method-Override'] ) ) {
		return strtoupper( $_POST['X-HTTP-Method-Override'] );
	}
	// Handling header override
	elseif ( isset( $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'] ) ) {
		return strtoupper( $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'] );
	}
	//Handling Regular request
	else{
		return $_SERVER['REQUEST_METHOD'];
	}
}

 

আপনি যদি এপিআই ডেভেলপমেন্টের জন্য স্লিম ফ্রেমওয়ার্ক ব্যবহার করে থাকেন তবে জেনে রাখুন স্লিম এ  X-HTTP-Method-Override পাশাপাশি নিচের মত করেও রিকোয়েস্ট করতে পারেন ।

<input type="hidden" name="_METHOD" value="PUT"/>

তবে রিকোয়েস্ট হ্যান্ডেলিং নিয়ে স্লিম ডেভেলপারদের ভাবতে হবে না । রেস্টফুল সার্ভিস ডেভেলপমেন্টের জন্য স্লিম অনেj স্মার্ট এবং লাইট ওয়েট মাইক্রোফ্রেমওয়ার্ক ।

GET vs Post vs PUT ?

নতুনদের কাছে আরেকটা চ্যালেন্জ হল মেথড নির্নয় করা । এপিআই ডেভেলপের সময় কোন রিসোর্সে কোন মেথড এপ্লাই করবে তা নিয়ে অনেকেই দ্বিধা-দ্বন্দতায় ভুগে । লগিন এর জন্য কি GET ব্যবহার করব নাকি POST ? PUT আর POST এর মধ্যে পার্থক্য কি?

এরকম প্রশ্নে জাগলে নিজেদের কয়েকটা প্রশ্ন করেই আমরা এর উত্তর পেয়ে যাব ।

প্রশ্ন ১: লগিন করার জন্য কি আমাকে ডাটাবেজে কিছু এন্ট্রি করা লাগছে ?

SELECT * from Users WHERE username='ikrum'&'password=12345'

এখানে লগিন করার জন্য আমি শুধু ডাটাবেজ রিড করে দেখছি যে এই নাম এবং পাসওয়ার্ডে কোন রেকর্ড আছে কি না, থাকলে বলব লগিন সাক্সেস না হলে ফেইল । যেহেতু এই অপারেশনে আমরা নতুন কোন রিসোর্স তৈরী, আপডেট কিংবা ডিলেট করছি না সেহেতু এটা GET মেথড ।

এবার হয়তো অনেকেই টাস্কি খেয়ে বসে আছেন, লগিনের ডাটা GET মেথডে পাঠাবেন?

না ! আসলে রেস্ট এপিআই তে লগিন বলে কিছু নেই । হতাশ হওয়ার কিছু নেই এপিআই অথেনটিকেশন নিয়ে আমরা পরবর্তীতে আলোচনা করব । এখানে লগিন একটি উদাহরন মাত্র। আপনি কিভাবে নিজেকে প্রশ্ন করে বের করবেন যে রিকোয়েস্টটি কোন মেথডের হবে । তবে হ্যা অন ডিমান্ড আপনি চাইলে কিছুটা ব্যতিক্রম করতে পারেন, তবে সেটা করতে নিরুৎসাহিত করা হয়।

প্রশ্ন ২: প্রতিবার রিকোয়েস্টে কি কোন নতুন রিসোর্স [লিংক] তৈরী হচ্ছে ?

রিসোর্স তৈরীর কিংবা আপডেটের জন্য PUT ব্যবহার করা যায়। তবে PUT এর ব্যবহার হয় যখন আপনার একটি রিসোর্স লিংক আছে । আর POST ব্যবহার করা হয় কালেকশনে নতুন রিসোর্স তৈরী করার জন্য তথা রিসোর্স লিংক পাওয়ার জন্য।

রেজিস্ট্রেশন করার জন্য ব্যবহারকারী তথ্য, ডাটাবেজে একটি রো তে যোগ করতে হচ্ছে এবং এটি একটি ইউনিক আইডি তৈরী করছে এবং সেই আইডি দিয়ে উক্ত ব্যবহারকারীকে এক্সেস করতে পারছি । অর্থাৎ আমাদের একটি রিসোর্স তৈরী করতে হচ্ছে, তাহলে POST মেথড ।

POST /users HTTP/1.1
.....
name=user_full_name&info=other_info

রেজিস্ট্রেশন সফল হওয়ার পর এখন ঐ ব্যবহারকারীর একটি ইউনিক আইডি পেলাম । এখন আমি ঐ ব্যবহারকারীর তথ্য রিড করতে চাইলে আমাকে GET রিকোয়েস্ট করতে হবে। যদি আইডি 87 হয় তাহলে:

GET /users/87 HTTP/1.1

যেহেতু আমার কাছে রিসোর্স এর লিংক আছে সেহেতু এখন আমি ঐ রিসোস আপডেট করতে পারব । আর সেটা করব PUT এর মাধ্যমে।

PUT /users/87 HTTP/1.1
......
info=new_info

আপনি যদি ১০০ বার PUT রিকোয়েস্ট করেন তবে কালেকশনের স্টেট এর কোন পরিবর্তন হবে না, শুধু নির্দিষ্ট রিসোর্স পরিবর্তন হচ্ছে । আর POST এর ক্ষেত্রে কালেকশনে ১০০টি নতুন রিসোর্স তৈরী হবে।

প্রশ্ন ৩: নতুন লাইক যোগ করতে POST নাকি PUT

কারো স্ট্যাটসে আমি যদি নতুন একটা কমেন্ট করি তবে সেটা comments টেবিলে নতুন একটা রেকর্ড যোগ করবে এবং এই কমেন্টটিরও একটা ইউনিক আইডি থাকবে । সুতরাং এটা POST মেথড । এখন কমেন্টে যখন প্রথম লাইক এড  করব তখন তো POST ই হবে ! আপনার মনে যদি একটুও সন্দেহ না লাগে তবে আরেকটু মনোযোগ দিয়ে দেখুন লাইকের জন্য আমি  কি নতুন কোন রেকড যোগ করছি ?

status_id comment_id comment likes
21 231 Mathoscope is the best book I have ever seen #mathmatics!

এখন কদম আলীর রেস্ট এপিআই এর মত করে যদি  231 নাম্বার কমেন্টের স্টেট জানতে চাই তবে এপিআই উত্তর দিবে: বইএর আইডি এত, কমেন্ট আইডি এত, কমেন্ট হল কখগ…অ অা, লাইক সংখ্যা শুন্য [যেহেতু কোন লাইক নেই ]

GET /users/87/status/comments/231 HTTP/1.1

খেয়াল করুন কমেন্ট করার সাথে সাথে আমরা নতুন একটি লিংক পাচ্ছি তাকে এক্সেস করার জন্য ।

প্রশ্ন ৪: আমি যদি লাইকের জন্য একটি লিংক দেই?

GET /users/87/status/comments/231/likes HTTP/1.1

যেহেতু এটি রিসোর্স না বরং রিসোর্সের একটি ফিল্ড সেহেতু এটা এভাবে এক্সেস করা যাবে না । এটাকে কোয়েরী প্যারামিটার হিসেবে এক্সেস করতে পারেন। পুনরায় নিচের উদাহরনগুলো বোঝার চেষ্টা করি:

GET /users/87/status/comments?fields=likes HTTP/1.1

http://graph.facebook.com/youtube
http://graph.facebook.com/youtube?fields=name,id,likes

এবার স্ট্যাটসে একটি লাইক যোগ করলাম !

status_id comment_id comment likes
21 231 Mathoscope is the best book I have ever seen #mathmatics! 1

আরেকটা লাইক দিলাম !

status_id comment_id comment likes
21 231 Mathoscope is the best book I have ever seen #mathmatics! 2

আমি যেহেতু রেকর্ড আপডেট করছি সেহেতু PUT মেথড ।

রেজাল্ট ফিল্টারিং এবং সার্চিং

রেজাল্ট ফিল্টারিং এর প্যারামিটারগুলো কোয়েরী প্যারামিটার হিসেবে যোগ করে দিতে হবে । যদি কোয়েরী প্যারামিটার ব্যবহার না করে পুরোটা URI তে রাখি তাহলে কেমন হবে ?

Query Parameter: http://graph.facebook.com/youtube?fields=name,id,likes
URI:             http://graph.facebook.com/youtube?fields/name/id/likes

ফিল্টারিং প্যারামিটারগুলো URI হিসেবে রাখলে প্রত্যেকটি ফিল্ড আলাদা আলাদি রিসোর্স হিসেবে গন্য হবে । আর কোনটা আগে দিবেন, কোনটা পরে দিবেন, কিংবা শুধু মাত্র একটা প্যারামিটার দিবেন, এসব কিভাবে হ্যান্ডেল করবে সেটা নিয়ে অনেক ঝামেলায় পড়বেন । বড় কথা তাহলে আপনার আর রেস্ট ফলো করা হল না । এখন কোয়েরী প্যারমিটারও বিভিন্ন ভাবে প্রোভাইড করা যায় যেমন:

/cars?color=blue&doors=4&type=sedan
/cars?color=blue;type=sedan 
/cars?color=black,blue,red;doors=3,5;type=sedan

 

প্যারমিটার আলাদা করার জন্য আপনি এন্ড সেমিকোলন কিংবা কমা ব্যবহার করতে পারেন তাতে কোন অসুবিধা নেই । তবে কোন ভাবেই আপনার Base URL  এর প্যাটার্ন এর মত কোয়েরী প্যারামিটার ব্যবহার করতে পারবেন না । একটি সঠিক এবং সর্ম্পূর্ন উদাহরন দেখি:

Base URL : http://host.com/books
Query : ?author=jhon&type=fiction&orderby=rating

Full: http://host.com/books?author=jhon&type=fiction&orderby=rating

অনুরুপ ভাবে সার্চিং এর জন্য কিওয়ার্ডটি আরেকটি প্যারামিটার আকারে নিতে পারি ।

http://host.com/books?query=REST Api

এপিআইকে আরেকটু সুন্দর ভাবে ব্যবহারকারীর কাছে তুলে ধরার জন্য সবচেয়ে কমন কুয়েরি গুলোকে আরকেটি রেস্ট লিংক দিয়ে প্রকাশ করতে পারি ।

http://host.com/books/best_seller
http://host.com/books/top_ten
http://host.com/books/recenty_popular

 

জেসন রেসপন্স

XML ডকুমেন্ট একপলক দেখেই ডকুমেন্ট বিষয়গুলো বুঝা যায় না, তাছাড়া অনেক প্রোগ্রামিং ল্যাঙ্গুয়েজেই XML পার্স এবং এটা নিয়ে কাজ করতে অনেক ঝামেলা পোহাতে হয় । সময় হয়েছে XML কে বিদায় জানানোর। গুগল ট্রেন্ডস চার্ট দেখে আপনিই বলুন XML এর ভবিষ্যৎ কি ?

Google Trends chart XML API vs JSON API , XML vs JSON

জেসন রেসপন্স

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


মুক্ত জ্ঞান ছড়িয়ে দিন সবার মাঝে!