৩০ আগ, ২০২৫·4 মিনিট
Nginx বনাম HAProxy: সঠিক রিভার্স প্রক্সি নির্বাচন
Nginx এবং HAProxy এর তুলনা: পারফরম্যান্স, লোড ব্যালান্সিং, TLS, অবজার্ভেবিলিটি, সিকিউরিটি এবং সাধারণ সেটআপ—কোনটি আপনার ব্যবহারের জন্য উপযুক্ত সে সম্পর্কে নির্দেশনা।
Nginx এবং HAProxy এর তুলনা: পারফরম্যান্স, লোড ব্যালান্সিং, TLS, অবজার্ভেবিলিটি, সিকিউরিটি এবং সাধারণ সেটআপ—কোনটি আপনার ব্যবহারের জন্য উপযুক্ত সে সম্পর্কে নির্দেশনা।
একটি রিভার্স প্রক্সি হচ্ছে একটি সার্ভার যা আপনার অ্যাপ্লিকেশনগুলোর সামনে বসে এবং প্রথমে ক্লায়েন্ট অনুরোধগুলো গ্রহণ করে। এটি প্রতিটি অনুরোধকে সঠিক ব্যাকএন্ড সার্ভিসে ফরওয়ার্ড করে (আপনার অ্যাপ সার্ভারগুলো) এবং প্রতিক্রিয়া ক্লায়েন্টকে ফেরত দেয়। ব্যবহারকারীরা প্রক্সির সাথে কথা বলে; প্রক্সি আপনার অ্যাপগুলোর সঙ্গে কথা বলে়।
একটি ফরোয়ার্ড প্রক্সি উল্টোভাবে কাজ করে: এটি ক্লায়েন্টদের সামনে বসে (উদাহরণস্বরূপ, কোম্পানির নেটওয়ার্কে) এবং তাদের আউটবাউন্ড অনুরোধগুলো ইন্টারনেটে ফরওয়ার্ড করে। এটি প্রধানত ক্লায়েন্ট ট্রাফিক নিয়ন্ত্রণ, ফিল্টারিং বা লুকাতে ব্যবহৃত হয়।
একটি লোড ব্যালান্সার সাধারণত একটি রিভার্স প্রক্সি হিসেবে ইমপ্লিমেন্ট করা হয়, কিন্তু একটি নির্দিষ্ট ফোকাস থাকে: ট্রাফিক একাধিক ব্যাকএন্ড ইনস্ট্যান্সের মধ্যে বিতরণ করা। অনেক প্রোডাক্ট (Nginx এবং HAProxy সহ) উভয়ই রিভার্স প্রক্সি এবং লোড ব্যালান্সিং করে, তাই টার্মগুলো কখনও একে অপরের পরিবর্তে ব্যবহৃত হয়।
অধিকাংশ ডেপলয়মেন্ট নিচের এক বা একাধিক কারণে শুরু হয়:
/api→API সার্ভিস, /→ওয়েব অ্যাপ)।রিভার্স প্রক্সি সাধারণত ওয়েবসাইট, API, এবং মাইক্রোসার্ভিস-এর সামনে থাকে — বা এজে (পাবলিক ইন্টারনেট) বা অভ্যন্তরীণভাবে সার্ভিসগুলোর মধ্যে। আধুনিক স্ট্যাকে এগুলো ইনগ্রেস গেটওয়ে, ব্লু/গ্রীন ডেপ্লয়মেন্ট এবং হাই-অ্যাভেলিবিলিটি সেটআপগুলোর বিল্ডিং ব্লক হিসেবেও ব্যবহৃত হয়।
Nginx এবং HAProxy ওভারল্যাপ করে, কিন্তু জোর এবং ব্যবহারভেদের দিকগুলো ভিন্ন। নিম্নলিখিত অংশগুলোতে আমরা তুলনা করব: অনেক সংযোগের অধীনে পারফর্ম্যান্স, লোড ব্যালান্সিং ও হেলথ চেক, প্রোটোকল সাপোর্ট (HTTP/2, TCP), TLS ফিচার, অবসার্ভেবিলিটি, এবং দিন-প্রতি-দিন কনফিগারেশন ও অপারেশন।
Nginx ব্যাপকভাবে ব্যবহৃত হয় উভয় ওয়েব সার্ভার এবং রিভার্স প্রক্সি হিসেবে। অনেক টিম প্রথমে এটিকে পাবলিক সাইট সার্ভ করার জন্য ব্যবহার করে এবং পরে এটা অ্যাপ সার্ভারগুলোর সামনে বসিয়ে TLS, রাউটিং, এবং ট্রাফিক স্পাইক সামলানোর কাজ দেয়।
যদি আপনার ট্রাফিক প্রধানত HTTP(S) এবং আপনি একটি একক “ফ্রন্ট ডোর” চান যে কিছু কিছু কাজ করতে পারে, তাহলে Nginx উজ্জ্বল করে উঠে। এটি বিশেষভাবে ভাল:
X-Forwarded-For, সিকিউরিটি হেডার)কারণ এটি কনটেন্ট সার্ভ এবং অ্যাপ proxy উভয়ই করতে পারে, Nginx ছোট থেকে মাঝারি সেটআপে কম কম্পোনেন্ট রেখে শুরু করার জন্য সাধারণ পছন্দ।
জনপ্রিয় সক্ষমতাগুলো:
Nginx প্রায়ই নির্বাচিত হয় যখন আপনি একটি এন্ট্রি পয়েন্ট চান যেটি:
আপনি যদি HTTP-হ্যান্ডলিং পছন্দ করেন এবং কনটেন্ট সার্ভিং ও রিভার্স প্রক্সিং একসাথে রাখতে চান, Nginx প্রায়ই ডিফল্ট শুরু পয়েন্ট।
HAProxy (High Availability Proxy) সাধারণত ব্যবহৃত হয় একটি রিভার্স প্রক্সি ও লোড ব্যালান্সার হিসেবে যা এক বা একাধিক অ্যাপ সার্ভারের সামনে বসে। এটি ইনকামিং ট্রাফিক গ্রহণ করে, রাউটিং এবং ট্রাফিক নিয়ম প্রয়োগ করে, এবং অনুরোধগুলো স্বাস্থ্যবান ব্যাকএন্ডে ফরওয়ার্ড করে—প্রায়ই ভারী কনকারেনসির অধীনে রেসপন্স টাইম স্টেবল রেখে।
টিমগুলো সাধারণত HAProxy ডেপ্লয় করে ট্রাফিক ম্যানেজমেন্ট-এর জন্য: অনুরোধগুলো একাধিক সার্ভারের মধ্যে ছড়িয়ে দেওয়া, ফেইলিউরের সময় সার্ভিস উপলব্ধ রাখা, এবং ট্রাফিক স্পাইকগুলো মসৃণ করা। এটি উত্তর–দক্ষিণ (edge) ট্রাফিক এবং অভ্যন্তরীণ (east–west) উভয় ক্ষেত্রে ব্যবহৃত হয়, বিশেষত যখন আপনি পূর্বানুমেয় আচরণ এবং কানেকশন-হ্যান্ডলিং-এর উপর শক্ত নিয়ন্ত্রণ চান।
HAProxy দীর্ঘসময় ধরে অনেক কনকারেন্ট কানেকশন দক্ষতার সঙ্গে হ্যান্ডল করার জন্য পরিচিত। যখন আপনার একসাথে অনেক ক্লায়েন্ট যুক্ত থাকে (ব্যস্ত API, লং-লিভড কানেকশন, চ্যাটি মাইক্রোসার্ভিস), তখন প্রক্সির রেসপন্সিভ থাকা গুরুত্বপূর্ণ হয়।
এর লোড ব্যালান্সিং সক্ষমতাই মানুষের HAProxy বেছে নেওয়ার প্রধান কারণ। সরল রাউন্ড-রবিন ছাড়াও এটি বিভিন্ন অ্যালগরিদম ও রাউটিং স্ট্র্যাটেজি সমর্থন করে, যা সাহায্য করে:
হেলথ চেকও একটি শক্ত পয়েন্ট: HAProxy অ্যাকটিভভাবে ব্যাকএন্ডগুলো যাচাই করতে পারে এবং অসুস্থ ইনস্ট্যান্সগুলোকে রোটেশন থেকে বাদ দিয়ে দেয়, পরে সেগুলো পুনরায় সুস্থ হলে যোগ করে। বাস্তবে, এটি ডাউনটাইম কমায় এবং “আধা-ভাঙা” ডেপ্লয়মেন্টের কারণে সকল ব্যবহারকারী প্রভাবিত হওয়া রোধ করে।
HAProxy Layer 4 (TCP) এবং Layer 7 (HTTP) উভয়েই অপারেট করতে পারে।
ব্যবহারিক পার্থক্য: L4 সাধারণত সহজতর এবং TCP ফরওয়ার্ডিংয়ে খুব দ্রুত, যখন L7 তখন আপনি আরও সমৃদ্ধ রাউটিং ও অনুরোধ লজিক পান যখন তা প্রয়োজন।
HAProxy প্রায়ই পছন্দ করা হয় যখন প্রধান লক্ষ্য হলো নির্ভরযোগ্য, উচ্চ-পারফর্ম্যান্স লোড ব্যালান্সিং এবং শক্তিশালী হেলথ চেক—উদাহরণ: API ট্রাফিককে একাধিক অ্যাপ সার্ভারে বিতরণ করা, অ্যাভেইলিবিলিটি জোনগুলোর মধ্যে ফেইলওভার, বা এমন সার্ভিসগুলোর সামনে দাঁড়ানো যেখানে কানেকশন ভলিউম এবং পূর্বানুমেয় ট্রাফিক আচরণ ওয়েব সার্ভার ফিচারের চেয়ে বেশি গুরুত্বপূর্ণ।
পারফরম্যান্স তুলনা প্রায়ই ভুল হয় কারণ মানুষ একটাই সংখ্যার (যেমন “ম্যাক্স RPS”) দিকে তাকায় এবং ব্যবহারকারীর অনুভূতিটি উপেক্ষা করে।
একটি প্রক্সি থ্রুপুট বাড়াতে পারে কিন্তু টেইল লেটেন্সি খারাপ করে যদি লোডের সময় অনেক কাজ কিউ করে।
আপনার অ্যাপের “আকৃতি” সম্পর্কে ভাবুন:
যদি আপনি এক প্যাটার্ন দিয়ে বেঞ্চমার্ক করেন কিন্তু অন্য প্যাটার্নে ডেপ্লয় করেন, ফলাফল ট্রান্সফার হবে না।
বাফারিং সাহায্য করতে পারে যখন ক্লায়েন্ট ধীর বা ট্র্যাফিক বিস্ফোরক, কারণ প্রক্সি পুরো রিকোয়েস্ট (বা রেসপন্স) পড়ে এবং আপনার অ্যাপকে স্থিতিশীল গতিতে খাওয়ায়।
বাফারিং ক্ষতিও করতে পারে যখন আপনার অ্যাপ স্ট্রিমিং থেকে উপকার পায় (SSE, বড় ডাউনলোড, রিয়েল-টাইম API)। অতিরিক্ত বাফারিং মেমোরি চাপ বাড়ায় এবং টেইল লেটেন্সি বাড়াতে পারে।
শুধু “ম্যাক্স RPS” মাপুন না:
যদি p95 দ্রুত বাড়ে ততক্ষণে এরর না দেখা দেয়, আপনি স্যাচুরেশনের প্রাথমিক সতর্কতা দেখছেন — এটা “ফ্রি হেডরুম” নয়।
Nginx ও HAProxy উভয়ই একাধিক অ্যাপ ইনস্ট্যান্সের সামনে বসে ট্রাফিক ছড়াতে পারে, কিন্তু তারা আউট-অফ-দ্যা-বক্স লোড-ব্যালান্সিং সেটের গভীরে ভিন্ন।
Round-robin ডিফল্ট “চমৎকার” পছন্দ যখন ব্যাকএন্ডগুলো অনুরূপ (একই CPU/মেমরি, একই অনুরোধ খরচ)। এটি সহজ, পূর্বানুমেয়, এবং স্টেটলেস অ্যাপের জন্য ভাল।
Least connections কাজ করে যখন অনুরোধের সময়কাল ভিন্ন (ফাইল ডাউনলোড, দীর্ঘ API কল, চ্যাট/ওয়েবসকেট)। এটি ধীর সার্ভারগুলোকে অতিরিক্ত লোড থেকে রক্ষা করে কারণ এটি কম অ্যাকটিভ অনুরোধ থাকা ব্যাকএন্ডকে প্রেফার করে।
Weighted balancing (ওয়েটেড রাউন্ড-রবিন বা ওয়েটেড least-connections) বাস্তবধর্মী বিকল্প যখন সার্ভারগুলো একই নয়—পুরনো ও নতুন নোড মিশে থাকা, বিভিন্ন ইনস্ট্যান্স সাইজ, বা ধীরে ধীরে ট্রাফিক শিফট ইত্যাদি।
সাধারণভাবে, HAProxy বেশি অ্যালগরিদম ও সূক্ষ্ম নিয়ন্ত্রণ অফার করে এবং লেয়ার 4/7-এ বিস্তৃত কনফিগারেশন দেয়, যখন Nginx সাধারণ ক্ষেত্রে পরিষ্কারভাবে কভার করে (আরও এক্সটেনশন সম্ভব এডিশন/মডিউল অনুযায়ী)।
স্টিকনেস ব্যবহারকারীর অনুরোধকে একই ব্যাকএন্ডে রাখে:
স্টিকনেস তখনই ব্যবহার করুন যখন তা আবশ্যক (লেজেসি সার্ভার-সাইড সেশন)। স্টেটলেস অ্যাপগুলো সাধারণত স্টিকনেস ছাড়া ভালো স্কেল ও রিকভার করে।
অ্যাকটিভ হেলথ চেক ব্যাকএন্ডগুলোকে পর্যায়ক্রমে প্রোব করে (HTTP এন্ডপয়েন্ট, TCP কানেক্ট, প্রত্যাশিত স্ট্যাটাস)। এগুলো কম ট্রাফিকে হলেও ব্যর্থতা ধরতে পারে।
প্যাসিভ হেলথ চেক বাস্তব ট্র্যাফিকের উপর প্রতিক্রিয়া করে: টাইমআউট, কানেকশন এরর, বা খারাপ রেসপন্স দেখলেই সার্ভারকে অসুস্থ বলে চিহ্নিত করে। এগুলো লাইটওয়েট কিন্তু সমস্যা সনাক্ত করতে সময় লাগতে পারে।
HAProxy সমৃদ্ধ হেলথ-চেক ও ফেইলিওর-হ্যান্ডলিং কন্ট্রোলের জন্য পরিচিত (থ্রেশহোল্ড, rise/fall কাউন্ট, ডিটেইল চেক)। Nginxও ভালো চেক সমর্থন করে, তবে ক্ষমতা বিল্ড ও এডিশনে নির্ভর করে।
রোলিং ডেপ্লয়ের জন্য দেখুন:
যা-ই বেছে নিন, ড্রেইনিংকে শর্ট, ভাল-সংজ্ঞায়িত টাইমআউট এবং একটি স্পষ্ট "ready/unready" হেলথ এন্ডপয়েন্টের সঙ্গে জোড়া দিন যেন ডেপ্লয়মেন্টের সময় ট্রাফিক স্মুথলি শিফট হয়।
রিভার্স প্রক্সিগুলো আপনার সিস্টেমের এজে বসে থাকে, তাই প্রোটোকল ও TLS বেছে নেওয়া ব্রাউজার পারফরম্যান্স থেকে সার্ভিস কমিউনিকেশন পর্যন্ত সবকিছুকে প্রভাবিত করে।
উভয় Nginx ও HAProxy TLS “টার্মিনেট” করতে পারে: তারা ক্লায়েন্ট থেক
একটি রিভার্স প্রক্সি আপনার অ্যাপ্লিকেশনগুলোর সামনে থাকে: ক্লায়েন্টরা প্রক্সি-র সঙ্গে সংযোগ করে, প্রক্সি সঠিক ব্যাকএন্ড সার্ভিসে অনুরোধ ফরওয়ার্ড করে এবং প্রতিক্রিয়া ক্লায়েন্টকে ফেরত দেয়।
একটি ফরোয়ার্ড প্রক্সি ক্লায়েন্টদের সামনে থাকে এবং তাদের আউটবাউন্ড ইন্টারনেট অ্যাক্সেস নিয়ন্ত্রণ করে (কোম্পানির নেটওয়ার্কে সাধারণ)।
একটি লোড ব্যালান্সার মূলত ট্রাফিক বিতরণে ফোকাস করে একাধিক ব্যাকএন্ড ইনস্ট্যান্সের মধ্যে। অনেক লোড ব্যালান্সারই রিভার্স প্রক্সি হিসেবে কাজ করে, তাই এই টার্মগুলো ওভারল্যাপ করে।
প্র্যাকটিক্যালি, আপনি প্রায়ই একটি টুল (যেমন Nginx বা HAProxy) ব্যবহার করবেন যা উভয়ই করে: রিভার্স প্রক্সি + লোড ব্যালান্সিং।
এটি সেই সীমান্তে রাখুন যেখানে আপনি একটি একক কন্ট্রোল পয়েন্ট চান:
কীটি হলো: ব্যাকএন্ডগুলিকে সরাসরি ক্লায়েন্টরা অ্যাক্সেস করতে দেবেন না যাতে প্রক্সি হলো নীতি ও ভিজিবিলিটির একমাত্র চোক পয়েন্ট।
TLS টার্মিনেশন মানে প্রক্সি HTTPS হ্যান্ডশেক এবং এনক্রিপশন প্রসেস হ্যান্ডেল করে: ক্লায়েন্ট এর কাছে এনক্রিপ্টেড কানেকশন গ্রহণ করে, ডিক্রিপ্ট করে, এবং আপনার আপস্ট্রিমে HTTP বা পুনঃ-এনক্রিপ্টেড TLS পাঠায়।
অপারেশনাল দিকগুলো পরিকল্পনা করতে হয়:
Nginx বেছে নিন যখন আপনার প্রক্সি একই সঙ্গে একটি ওয়েব “ফ্রন্ট ডোর” হিসেবেও কাজ করবে:
HAProxy বেছে নিন যখন ট্রাফিক ম্যানেজমেন্ট এবং লোডের সময় পূর্বানুমেয়তা প্রধান প্রয়োজন:
Round-robin ব্যবহার করুন যখন ব্যাকএন্ডগুলো অনুরূপ এবং অনুরোধের খরচ সাধারণত একই রকম।
Least connections ব্যবহার করুন যখন অনুরোধের সময়কাল ভিন্ন হয় (ডাউনলোড, দীর্ঘ API কল, লং-লিভড কানেকশন) যাতে ধীর ইনস্ট্যান্সগুলো অতিরিক্ত লোড না নেয়।
Weighted ব্যবহার করুন যখন ব্যাকএন্ডগুলো ভিন্ন (ভিন্ন ইনস্ট্যান্স সাইজ, মাইগ্রেশন ইত্যাদি) যাতে আপনি ইচ্ছাকৃতভাবে ট্রাফিক শিফট করতে পারেন।
স্টিকনেস একটি ব্যবহারকারীকে একটিই ব্যাকএন্ডে ধরে রাখে:
যখন সম্ভব স্টিকনেস এড়িয়ে চলুন: স্টেটলেস সার্ভিসগুলো সহজে স্কেল ও রিকভার করে।
বাফারিং ধীর বা উত্থিত ক্লায়েন্টদের ক্ষেত্রে সাহায্য করতে পারে যাতে অ্যাপকে গড়ের মতো ধারা দেয়।
কিন্তু স্ট্রিমিং-ওরিয়েন্টেড কাজ (SSE, WebSockets, বড় ডাউনলোড) থাকলে অতিরিক্ত বাফারিং ক্ষতিকর—মেমরি চাপ বাড়ে এবং টেইল লেটেন্সি খারাপ হতে পারে।
আপনার অ্যাপ যদি স্ট্রিম-ওরিয়েন্টেড হয়, ডিফল্টের উপর নির্ভর না করে বাফারিং স্পষ্টভাবে টেস্ট ও টিউন করুন।
প্রক্সি ডিলে এবং ব্যাকএন্ড ডিলে আলাদা করে দেখুন (লগ/মেট্রিক্স থেকে)।
সাধারণ তরজমা:
উপযোগী সংকেতগুলো তুলনা করুন:
সমাধান সাধারণত: টাইমআউট অ্যাডজাস্ট করা, ব্যাকএন্ড ক্যাপাসিটি বাড়ানো, বা হেলথ চেক/রেডিনেস এন্ডপয়েন্ট উন্নত করা।