আপনি কোনও নতুন অ্যাপের উন্নতি করছেন বা আগে থেকেই অনেক ট্রাফিক আছে এমন কোনও পরিষেবা চালাচ্ছেন, আপনি এই গাইডের ইনসাইট এবং FCM-এর মাধ্যমে কীভাবে মসৃণভাবে স্কেল করা যায় সে সম্পর্কে সাজেশন থেকে উপকৃত হতে পারেন। এইসব ধারণা ও পদ্ধতি আপনাকে অনেক বেশি পরিমাণে মেসেজ পাঠানোর সময় নেতিবাচক প্রভাব এড়াতে সাহায্য করতে পারে।
মূল শব্দ ও ধারণা
মেসেজ অনুরোধ: একটি FCM মেসেজ অনুরোধ; "অনুরোধ", "মেসেজ" বা "কোয়েরি"র সাথে অদলবদল করে ব্যবহার করা হয়।
প্রতি সেকেন্ডে অনুরোধ (RPS): FCM-এ আসা অনুরোধের হার বর্ণনা করার জন্য একটি মেট্রিক; প্রতি সেকেন্ডে কোয়েরি (QPS)-এর সাথে অদলবদল করে ব্যবহার করা হয়।
কোটা টোকেন, টোকেন বাকেট ও রিফিল: FCM HTTP v1 API-এর মাধ্যমে মেসেজ পাঠানোর সময়, প্রতিটি অনুরোধের জন্য নির্দিষ্ট সময়সীমার মধ্যে বরাদ্দ কোটা টোকেন ব্যবহার করা হয়। এই উইন্ডোকে "টোকেন বাকেট" বলা হয়, যা সময়সীমা শেষ হওয়ার পরে সম্পূর্ণভাবে রিফিল হয়ে যায়। যেমন: HTTP v1 API প্রতিটি ১-মিনিটের টোকেন বাকেটের জন্য ৬০০K কোটা টোকেন বরাদ্দ করে, যা প্রতিটি ১-মিনিটের উইন্ডোর শেষে সম্পূর্ণভাবে রিফিল হয়।
সার্ভার-সাইড থ্রটলিং: ট্রাফিকের পরিমাণ FCM পরিষেবার
ক্ষমতা ছাড়িয়ে গেলে, ইনগ্রেস ফ্লো রেট-লিমিট করতে, পরিষেবা দেওয়ার ক্ষমতার অতিরিক্ত অনুরোধ বাতিল করা হয়। retry-after হেডার সহ 429টি ত্রুটি সংক্রান্ত উত্তর ফেরত পাঠানো হতে পারে, যা থেকে বোঝা যায় যে
অনুরোধটি আবার করার আগে আপনাকে নির্দিষ্ট সময় পর্যন্ত অপেক্ষা করতে হবে।
ক্লায়েন্ট-সাইড থ্রটলিং: ক্লায়েন্টরা যখন অনুরোধের ব্যর্থতা, উচ্চ লেটেন্সি,
বা 429 ত্রুটি লক্ষ্য করেন, তখন তাদের স্বেচ্ছায় ইগ্রেস ফ্লো রেট-লিমিট করা উচিত যাতে
কনজেশন আরও খারাপ না হয়।
এক্সপোনেনশিয়াল ব্যাকঅফ: সমস্যার সমাধান করার জন্য আবার চেষ্টা করার সময়, এক্সপোনেনশিয়াল হারে সময় বাড়িয়ে দিন। যেমন: ১ সেকেন্ড, ২ সেকেন্ড, ৪ সেকেন্ড, ৮ সেকেন্ড, ১৬ সেকেন্ড, ৩২ সেকেন্ড ইত্যাদি।
জিটারিং: নির্দিষ্ট সময় অন্তর অনুরোধ আবার করার চেষ্টা এড়িয়ে যাওয়া। জিটারিংয়ের মাধ্যমে, আপনি একটি র্যান্ডম প্রসেসের মাধ্যমে আবার চেষ্টা করার বিলম্বের সময় পরিবর্তন করেন যাতে সেগুলি সময়ের সাথে সাথে সমানভাবে বিতরণ করা যায় (যেমন: ০.৯ সেকেন্ড, ২.৩ সেকেন্ড, ৪.১ সেকেন্ড, ৮.৫ সেকেন্ড, ১৭.৯ সেকেন্ড, ৩৪.৭ সেকেন্ড)।
অ্যাম্প্লিফিকেশন আবার চেষ্টা করা: যখন ব্যর্থ অনুরোধগুলি এক্সপোনেনশিয়াল ব্যাকঅফ/জিটারিং ছাড়াই আবার চেষ্টা করা হয়, তখন সেগুলি প্রায়শই জমা হয় এবং চলমান ট্রাফিক লোডে যোগ হয়, সম্ভাব্যভাবে ট্রাফিক কনজেশন সমস্যা "অ্যাম্প্লিফাই" এবং আরও খারাপ করে তোলে।
সমস্যা: ট্রাফিক স্পাইক
FCM প্রতি সেকেন্ডে লক্ষ লক্ষ অনুরোধ (RPS) প্রসেস করে। সিস্টেমিক কনজেশন, লেটেন্সি সমস্যা এবং আউটএজের সবচেয়ে বড় কারণ হল ট্রাফিক স্পাইক।
স্পাইকি ট্রাফিক কী?
ট্রাফিক স্পাইক বিভিন্ন ধরনের হয়।
প্রতি ঘণ্টায় ট্রাফিক বৃদ্ধি: FCM প্রতি ঘণ্টার প্রথম ৩০ সেকেন্ড থেকে ২ মিনিটের মধ্যে দ্বিগুণেরও বেশি ট্রাফিক পায়। একইভাবে, যদিও কম, স্পাইকও প্রতি আধ ঘণ্টা এবং পনেরো মিনিট অন্তর লক্ষ্য করা যায় (উদাহরণ: ০০:১৫, ০০:৩০, ০০:৪৫)
অ্যাম্প্লিফিকেশন আবার চেষ্টা করা: এক্সপোনেনশিয়াল ব্যাকঅফ ছাড়া ব্যর্থ বা টাইম-আউট হয়ে যাওয়া অনুরোধ আবার চেষ্টা করলে, বর্তমান ট্রাফিকের সর্বোচ্চ সীমার উপরে ট্রাফিকের পুনরাবৃত্তিমূলক তরঙ্গ জমা হতে পারে।
ট্রাফিক প্যাটার্নে আকস্মিক পরিবর্তন: FCM-এ নতুন ট্রাফিক পাঠানো বা বিভিন্ন অঞ্চল জুড়ে FCM-এ ট্রাফিক স্থানান্তর করার সময় ধীরে ধীরে ট্রাফিক বাড়ানোর মতো স্মুদিং ফ্যাক্টর ব্যবহার না করলে ট্রাফিকের পরিমাণ হঠাৎ বেড়ে যেতে পারে।
ফ্রন্ট-লোডিং কোটা টোকেন ব্যবহার: কোটা উইন্ডো জুড়ে সমানভাবে অনুরোধগুলি ছড়িয়ে দেওয়ার পরিবর্তে কোটা উইন্ডোর শুরুতে সমস্ত কোটা টোকেন শেষ করে দিলে অন-অফ অসিলেশন তৈরি হবে যা লোড-ব্যালেন্স করা কঠিন এবং ব্যয়বহুল।
বিশেষ ইভেন্ট: ছুটির দিনে (নতুন বছরের আগের দিন) বা স্পোর্টস ইভেন্টের সময় ট্রাফিক স্পাইক (FIFA World Cup)।
"কার্ভ ফ্ল্যাটেনিং" করে ট্রাফিক স্পাইক কমানো
এই বিভাগে ট্রাফিক স্পাইক কমানোর কৌশল বর্ণনা করা হয়েছে, যেখানে সম্ভব—"কার্ভ ফ্ল্যাটেন করার" কৌশল।
শুধুমাত্র উপযুক্ত ব্যবহারের ক্ষেত্রে FCM ব্যবহার করুন
এমন কিছু ব্যবহারের ক্ষেত্র আছে যেখানে বিজ্ঞপ্তি পাঠানোর জন্য FCM ব্যবহার করা প্রয়োজনীয় বা উপযুক্ত নয়।
যেমন, ক্যালেন্ডার ইভেন্ট বিজ্ঞপ্তির জন্য, আপনার অ্যাপ সার্ভার থেকে বিজ্ঞপ্তি পাঠানোর পরিবর্তে, উপযুক্ত সময়ে বিজ্ঞপ্তি দেখানোর জন্য আপনার অ্যাপে একটি লোকাল টাস্ক শিডিউল করতে পারেন। ক্যালেন্ডার সিঙ্ক করার জন্য FCM মেসেজ সীমিত করুন।
স্পাইক এড়িয়ে চলুন
সার্ভার-সাইড থ্রটলিং প্রয়োগ করার পরিবর্তে, সিস্টেম যত দ্রুত অনুমতি দেবে তত দ্রুত FCM বিজ্ঞপ্তি পাঠানো হল একটি স্কেলিং অ্যান্টি-প্যাটার্ন। নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:
- আপনার সব গ্রাহককে কি ১ মিনিটের মধ্যে একই বিজ্ঞপ্তি পেতে হবে? উদাহরণস্বরূপ, ৫ মিনিটের ডেলিভারি উইন্ডো কি এখনও আপনার ব্যবসার প্রয়োজন মেটাবে?
- আপনার গ্রাহকদের কি অগ্রাধিকারের ভিত্তিতে ভাগ করা যেতে পারে যাতে স্পাইকগুলি মসৃণ করা যায়?
- আপনার বিজ্ঞপ্তি কি সময়ের আগে শিডিউল করা যাবে?
যতটা সম্ভব: এমন কৌশল এড়িয়ে চলুন যার ফলে আপনার FCM পাঠানোর কোটা অবিলম্বে শেষ হয়ে যায় এবং আপনার টোকেন বাকেট রিফিল হওয়ার সাথে সাথেই প্যাটার্নটি পুনরাবৃত্তি হয়। এই অ্যাক্সেস প্যাটার্ন FCM এবং এর উপর নির্ভরশীল সিস্টেমের জন্য লোড-ব্যালেন্সিং সংক্রান্ত সমস্যা তৈরি করে। যতটা সম্ভব ধীরে ধীরে ট্রাফিক বাড়ান। কমপক্ষে, ৬০ সেকেন্ডের সময়-উইন্ডো জুড়ে ০ থেকে সর্বাধিক RPS-এ র্যাম্প করুন। আরও বেশি RPS-এর জন্য দীর্ঘতর উইন্ডো পছন্দ করুন।
"ঘণ্টা-প্রতি" ট্রাফিক এড়িয়ে চলুন
সম্ভব হলে: :০০, :১৫, :৩০ এবং :৪৫ মিনিট চিহ্নের প্রতিটির ২ মিনিটের উইন্ডোর মধ্যে মেসেজ পাঠানো এড়িয়ে চলুন।
সার্ভার-সাইড থ্রটলিং প্রয়োগ করা
FCM-এ ট্রাফিকের ফ্লো মনিটর ও ম্যানেজ করতে সার্ভার-সাইড থ্রটলিং প্রয়োগ করুন।
আবার চেষ্টা করা ম্যানেজ করা
FCM-এর লক্ষ্য হল সবসময় উপলভ্য থাকা, তবে কখনও কখনও কিছু অনুরোধের টাইম-আউট হয়ে যায় বা তা ব্যর্থ হয়। কারণগুলি আলাদা হলেও, নিম্নলিখিত পেশাদার পদ্ধতিগুলি ট্রাফিক কনজেশনকে কম করে যত তাড়াতাড়ি সম্ভব মেসেজ ডেলিভার করার জন্য আবার চেষ্টা করার প্রক্রিয়াকে অপ্টিমাইজ করে।
টাইমআউট
আবার চেষ্টা করার আগে, অনুরোধ পাঠানোর জন্য কমপক্ষে ১০ সেকেন্ডের টাইমআউট সেট করুন। FCM-এর বেশিরভাগ ইন্টার্নাল রিমোট প্রসিডিওর কল ১০ সেকেন্ডের টাইমআউট ব্যবহার করে।
সমস্যা
- 400, 401, 403, 404 সমস্যার জন্য: বাতিল করুন এবং আবার চেষ্টা করবেন না।
- ৪২৯ সমস্যার জন্য: retry-after হেডারে সেট করা সময়সীমা পর্যন্ত অপেক্ষা করার পরে আবার চেষ্টা করুন। retry-after হেডার সেট করা না থাকলে, ডিফল্ট হিসেবে ৬০ সেকেন্ড সেট করা হয়।
- ৫০০ নম্বর সমস্যার জন্য: এক্সপোনেনশিয়াল ব্যাক-অফ সহ আবার চেষ্টা করুন।
এক্সপোনেনশিয়াল ব্যাকঅফ
আবার চেষ্টা করার সময় যাতে সমস্যা না হয়, তাই অনুরোধের জন্য আবার চেষ্টা করার সময় জিটারিং সহ এক্সপোনেনশিয়াল ব্যাক-অফ প্রয়োগ করুন। যেমন, Firebase অ্যাডমিন SDK এক্সপোনেনশিয়াল ব্যাকঅফ প্রয়োগ করে।
এখানে আরও কিছু সাজেস্ট করা সেটিংস দেওয়া হল:
- ন্যূনতম বিরতি: FCM-এর মাধ্যমে কোনও অনুরোধ ব্যর্থ হলে অবিলম্বে আবার চেষ্টা করবেন না। ব্যর্থ অনুরোধ আবার করার আগে অন্তত ১০ সেকেন্ড অপেক্ষা করুন।
- সর্বাধিক ব্যবধান: অনির্দিষ্টকালের জন্য আবার চেষ্টা করার পরিবর্তে, আর সময়োপযোগী নয় এমন অনুরোধ ড্রপ করার জন্য একটি সর্বাধিক ব্যবধান সেট করুন।
যদি কোনও অনুরোধ এক্সপোনেনশিয়াল ব্যাকঅফের সাথে ক্রমাগত আবার চেষ্টা করা হয় এবং ৬০ মিনিট পরেও ব্যর্থ হয়, তাহলে এটি হয় আবার চেষ্টা করার মতো সমস্যা হিসাবে ভুলভাবে শ্রেণীবদ্ধ করা হয়েছে, অথবা FCM-এ কোনও বিভ্রাট হচ্ছে যেখানে আবার চেষ্টা করার ফলে পরিস্থিতি অনিচ্ছাকৃতভাবে আরও খারাপ হতে পারে।
রোল-আউট ও রোল-ব্যাক প্ল্যান তৈরি করুন এবং ধীরে ধীরে পরিবর্তন করুন
FCM-এ ট্রাফিক বাড়ানো বা বিভিন্ন অঞ্চল বা নেটওয়ার্ক জুড়ে ট্রাফিক শিফ্ট করার মতো বড় আকারের ট্রাফিক পরিবর্তন করার সময়, রোলআউট/রোলব্যাক প্ল্যান ডিজাইন করা এবং ধীরে ধীরে পরিবর্তনগুলি বাস্তবায়ন করা আপনার ব্যবহারকারী, আপনার পরিষেবা এবং FCM-কে সুরক্ষিত করবে।
- রোলআউট প্ল্যান স্টেকহোল্ডারদের প্রত্যাশা পূরণ করে। কিছু পরিস্থিতিতে (নিচে আলোচনা করা হয়েছে), আপনি হয়ত FCM টিমের সাথে আগে থেকেই আপনার রোলআউট প্ল্যান শেয়ার করতে চাইবেন যাতে কোনও সমস্যা না হয়।
- রোলব্যাক প্ল্যান আপনাকে আকস্মিক ঘটনার জন্য প্রস্তুত হতে এবং অপ্রত্যাশিত ব্যর্থতা থেকে দ্রুত এবং নিরাপদে ফিরে আসার জন্য মেকানিজম প্রস্তুত করতে সাহায্য করে।
- ধীরে ধীরে পরিবর্তন করার দুটি দিক আছে:
- "ধাপে ধাপে" র্যাম্প-আপ: ধাপগুলি ১% -> ৫% -> ১০% -> ২৫% -> ৫০% -> ৭৫% -> ১০০% বা আরও সূক্ষ্ম হতে হবে। প্রতিটি ধাপ ১ দিন থেকে ১ সপ্তাহ পর্যন্ত "সোক" (লোড থাকা অবস্থায় সিস্টেমের আচরণ পর্যবেক্ষণ) করুন। এটি আপনাকে পরবর্তী "স্টেপ-আপ" করার আগে সম্ভাব্য সমস্যাগুলি চিহ্নিত করতে দেয়
- ধীরে ধীরে ট্রাফিক বাড়ানো: ট্রাফিক বাড়ানোর জন্য প্রতিটি "ধাপ" নেওয়ার সময়, অন্তত এক ঘণ্টা ধরে ট্রাফিক মসৃণ করুন। এটি FCM-এর লোড-ব্যালেন্সিং ইনফ্রাস্ট্রাকচারকে আপনার নতুন ট্রাফিককে যথাযথভাবে স্কেল করার অনুমতি দেয় এবং একই সাথে হটস্পট এবং কনজেশনের সম্ভাবনা কমিয়ে দেয়।
FCM লিগ্যাসি HTTP API থেকে FCM HTTP v1 API-তে বিশ্বব্যাপী ৫০০,০০০ RPS মাইগ্রেট করার জন্য এখানে একটি কাল্পনিক দৃশ্যকল্প দেওয়া হল:
| সপ্তাহ | ধাপ | ধীরে ধীরে র্যাম্প-আপ করার স্ট্র্যাটেজি |
|---|---|---|
| 0 | ১% র্যাম্প-আপ | এক ঘণ্টার মধ্যে FCM HTTP v1-এ ০ থেকে ৫,০০০ RPS-এ মসৃণভাবে র্যাম্প-আপ করুন। |
| 1 | ৫% র্যাম্প-আপ | ২ ঘণ্টা ধরে ৫,০০০ থেকে ২৫,০০০ RPS পর্যন্ত মসৃণভাবে র্যাম্প-আপ করুন। |
| 2 | ১০% র্যাম্প-আপ | ২ ঘণ্টা ধরে ২৫,০০০ থেকে ৫০,০০০ RPS-এ মসৃণভাবে র্যাম্প-আপ করুন |
| 3 | ২৫% র্যাম্প-আপ | ৩ ঘণ্টা ধরে ৫০,০০০ থেকে ১২৫,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| 4 | ৫০% র্যাম্প-আপ | ৬ ঘণ্টা ধরে ১২৫,০০০ থেকে ২৫০,০০০ RPS পর্যন্ত র্যাম্প-আপ করুন |
| 5 | ৭৫% র্যাম্প-আপ | ৬ ঘণ্টার মধ্যে ২৫০,০০০ থেকে ৩৭৫,০০০ RPS-এ র্যাম্প-আপ করুন |
| 6 | ১০০% র্যাম্প-আপ | ৬ ঘণ্টা ধরে ৩৭৫,০০০ থেকে ৫০০,০০০ RPS পর্যন্ত র্যাম্প-আপ |
কাল্পনিক রোলব্যাক প্ল্যান:
- যদি ৯৫-পার্সেন্টাইল লেটেন্সি ৫০০ মিলিসেকেন্ডের বেশি হয়ে যায় অথবা কোনও ধাপে এক ঘণ্টার বেশি সময় ধরে ত্রুটির অনুপাত ১% ছাড়িয়ে যায়, তাহলে অবিলম্বে আগের ধাপে ফিরে যেতে ডায়নামিক কনফিগারেশন ব্যবহার করুন।
- লেটেন্সি ও সমস্যার অনুপাত স্বাভাবিক না হওয়া পর্যন্ত আগের ধাপে ফিরে যাওয়া চালিয়ে যান।
কখন FCM-এর সাথে যোগাযোগ করতে হবে
নিম্নলিখিত কোনও একটি প্রযোজ্য হলে Firebase সহায়তা-এর মাধ্যমে FCM-এর সাথে যোগাযোগ করুন:
- ডিফল্ট কোটা আপনার ব্যবহারের ক্ষেত্রে আর প্রযোজ্য নয়
- আপনি ৩ মাসের উইন্ডোর মধ্যে বিশ্বব্যাপী ১০০,০০০ RPS বা মহাদেশীয়ভাবে ৩০,০০০ RPS স্কেলে আপনার পাঠানোর প্যাটার্ন পরিবর্তন করছেন।