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