আপনি একটি নবজাতক অ্যাপ তৈরি করছেন বা ইতিমধ্যেই একটি উচ্চ-ট্রাফিক পরিষেবা চালাচ্ছেন, আপনি এই গাইডের অন্তর্দৃষ্টি এবং FCM এর সাথে কীভাবে মসৃণভাবে স্কেল করবেন সে সম্পর্কে সুপারিশগুলি থেকে উপকৃত হতে পারেন৷ এই ধারণাগুলি এবং অনুশীলনগুলি আপনাকে নেতিবাচক প্রভাব এড়াতে সাহায্য করতে পারে যখন আপনাকে প্রচুর পরিমাণে বার্তা পাঠাতে হবে।
মূল শর্তাবলী এবং ধারণা
বার্তা অনুরোধ : একটি FCM বার্তা অনুরোধ; "অনুরোধ", "বার্তা" বা "কোয়েরি" এর সাথে বিনিময়যোগ্যভাবে ব্যবহৃত হয়।
অনুরোধ-প্রতি-সেকেন্ড (RPS) : FCM-তে আগত অনুরোধের হার বর্ণনা করার জন্য একটি মেট্রিক; Query-per-second (QPS) এর সাথে বিনিময়যোগ্যভাবে ব্যবহৃত হয়।
কোটা টোকেন, টোকেন বাকেট এবং রিফিল : FCM HTTP v1 API এর বিরুদ্ধে বার্তা পাঠানোর সময়, প্রতিটি অনুরোধ একটি নির্দিষ্ট সময় উইন্ডোতে একটি বরাদ্দ করা কোটা টোকেন গ্রহণ করে। এই উইন্ডোটিকে " টোকেন বাকেট " বলা হয়, টাইম উইন্ডোর শেষে পূর্ণ হয়ে যায় । উদাহরণস্বরূপ: HTTP v1 API প্রতিটি 1-মিনিটের টোকেন বাকেটের জন্য 600K কোটা টোকেন বরাদ্দ করে, যা প্রতিটি 1-মিনিটের উইন্ডোর শেষে পূর্ণ হয়ে যায়।
সার্ভার-সাইড থ্রোটলিং : যখন ট্র্যাফিকের পরিমাণ FCM পরিষেবার ধারণক্ষমতাকে ছাড়িয়ে যায়, তখন পরিবেশন ক্ষমতার বাইরের অনুরোধগুলি রেট-সীমা প্রবেশের প্রবাহে প্রত্যাখ্যান করা হয়। retry-after শিরোনাম সহ 429 ত্রুটির প্রতিক্রিয়াগুলি ফেরত দেওয়া হতে পারে নির্দেশ করে যে অনুরোধটি পুনরায় চেষ্টা করার আগে আপনাকে একটি নির্দিষ্ট সময়কাল অপেক্ষা করা উচিত।
ক্লায়েন্ট-সাইড থ্রটলিং : যখন ক্লায়েন্টরা অনুরোধের ব্যর্থতা, উচ্চ বিলম্বিতা, বা 429 ত্রুটিগুলি দেখেন, তখন তাদের স্বেচ্ছায় প্রবাহের প্রবাহকে রেট-সীমিত করা উচিত যাতে অতিরিক্ত যানজট এড়ানো যায়।
সূচকীয় ব্যাকঅফ : ত্রুটিগুলি পুনরায় চেষ্টা করার সময়, দ্রুতগতিতে ক্রমবর্ধমান সময় বিলম্ব যোগ করুন। উদাহরণস্বরূপ: 1s, 2s, 4s, 8s, 16s, 32s, এবং আরও অনেক কিছু।
জিটারিং : সঠিক বিরতিতে পুনরায় চেষ্টা করার অনুরোধ এড়ানো। ঝাঁকুনি দিয়ে, আপনি সময়ের সাথে সমানভাবে বিতরণ করার জন্য একটি এলোমেলো প্রক্রিয়ার মাধ্যমে পুনরায় চেষ্টা করার বিলম্বের পরিবর্তন করেন (উদাহরণস্বরূপ: 0.9s, 2.3s, 4.1s, 8.5s, 17.9s, 34.7s)।
পরিবর্ধনের পুনরায় চেষ্টা করুন : যখন ব্যর্থ অনুরোধগুলি সূচকীয় ব্যাকঅফ/জিটারিং ছাড়াই পুনরায় চেষ্টা করা হয়, তখন সেগুলি প্রায়শই সঞ্চিত হয় এবং চলমান ট্র্যাফিক লোড যোগ করে, সম্ভাব্য "বিবর্ধন" করে এবং ট্র্যাফিক জ্যাম সমস্যাকে আরও বাড়িয়ে দেয়।
সমস্যা: ট্রাফিক স্পাইক
FCM প্রতি সেকেন্ডে লক্ষ লক্ষ অনুরোধ প্রক্রিয়া করে (RPS)। সিস্টেমিক যানজট, লেটেন্সি সমস্যা এবং বিভ্রাটের সবচেয়ে বড় অবদান হল ট্রাফিক স্পাইক।
স্পাইকি ট্রাফিক কি?
ট্রাফিক স্পাইক বিভিন্ন ধরনের আছে.
অন-দ্য-আওয়ার স্পাইকস: FCM প্রতি ঘন্টার প্রথম 30 সেকেন্ড থেকে 2 মিনিটের মধ্যে দ্বিগুণেরও বেশি ট্রাফিক পায়। অনুরূপ, যদিও কম, স্পাইকগুলি আধা-ঘণ্টা এবং ত্রৈমাসিক-ঘণ্টার চিহ্নগুলিতেও পরিলক্ষিত হয় (উদাহরণ: 00:15, 00:30, 00:45)
পরিবর্ধনের পুনরায় চেষ্টা করুন : এক্সপোনেনশিয়াল ব্যাকঅফ ছাড়া ব্যর্থ বা টাইম-আউট অনুরোধগুলি পুনরায় চেষ্টা করা বিদ্যমান ট্র্যাফিক ক্রেস্টের উপরে ট্র্যাফিকের পুনরাবৃত্তি তরঙ্গে জমা হতে পারে।
আকস্মিক ট্র্যাফিক প্যাটার্ন পরিবর্তন: নতুন ট্র্যাফিককে FCM-এ নির্দেশিত করা বা ধীরে ধীরে র্যাম্প-আপের মতো মসৃণ কারণগুলি ছাড়াই সমস্ত অঞ্চলে FCM-এ ট্র্যাফিক সরানো স্পাইকের কারণ হতে পারে।
ফ্রন্ট-লোডিং কোটা টোকেন ব্যবহার: কোটা উইন্ডো জুড়ে অনুরোধগুলিকে সমানভাবে ছড়িয়ে দেওয়ার পরিবর্তে কোটা উইন্ডোর শুরুতে সমস্ত কোটা টোকেন নিঃশেষ করা হলে তা অন-অফ দোলন তৈরি করবে যা লোড-ব্যালেন্স করা কঠিন এবং ব্যয়বহুল।
বিশেষ ইভেন্ট: ছুটির দিন (নববর্ষের আগের দিন) বা ক্রীড়া ইভেন্ট ( ফিফা বিশ্বকাপ ) চলাকালীন ট্রাফিক স্পাইক।
"বক্ররেখা সমতল করে" ট্রাফিক স্পাইক প্রতিকার করুন
এই বিভাগটি যেখানে সম্ভব ট্রাফিক স্পাইকগুলিকে মসৃণ করার কৌশলগুলি বর্ণনা করে — "বক্ররেখা সমতল" করার কৌশলগুলি৷
শুধুমাত্র উপযুক্ত ব্যবহারের ক্ষেত্রে FCM ব্যবহার করুন
কিছু ব্যবহারের ক্ষেত্রে রয়েছে যেখানে একটি বিজ্ঞপ্তি প্রদানের জন্য FCM ব্যবহার করা প্রয়োজন বা উপযুক্ত নয়।
উদাহরণস্বরূপ, ক্যালেন্ডার ইভেন্ট বিজ্ঞপ্তিগুলির জন্য, আপনি আপনার অ্যাপ সার্ভার থেকে এটি পাঠানোর পরিবর্তে উপযুক্ত সময়ে একটি বিজ্ঞপ্তি প্রদর্শন করার জন্য আপনার অ্যাপে একটি স্থানীয় কাজ নির্ধারণ করতে পারেন। ক্যালেন্ডার সিঙ্কে FCM বার্তা সীমাবদ্ধ করুন।
স্পাইক এড়িয়ে চলুন
একটি স্কেলিং অ্যান্টি-প্যাটার্ন হল সার্ভার-সাইড থ্রটলিং প্রয়োগ করার পরিবর্তে সিস্টেমগুলি যত তাড়াতাড়ি অনুমতি দেবে FCM বিজ্ঞপ্তিগুলি প্রেরণ করা। নিম্নলিখিত বিবেচনা করুন:
- আপনার সমস্ত গ্রাহকদের কি 1 মিনিটের উইন্ডোর মধ্যে একই বিজ্ঞপ্তি পেতে হবে? উদাহরণস্বরূপ, একটি 5 মিনিটের ডেলিভারি উইন্ডো কি এখনও আপনার ব্যবসার চাহিদা পূরণ করবে?
- স্পাইক ওভার মসৃণ করার জন্য আপনার গ্রাহকদের অগ্রাধিকারের ভিত্তিতে ভাগ করা যেতে পারে?
- আপনার বিজ্ঞপ্তিগুলি কি সময়ের আগে নির্ধারিত হতে পারে?
যেখানেই সম্ভব : কৌশলগুলি এড়িয়ে চলুন যার ফলে আপনার FCM পাঠানো কোটা অবিলম্বে শেষ হয়ে যায়, শুধুমাত্র আপনার টোকেন বালতি রিফিল করার সাথে সাথে প্যাটার্নটি পুনরাবৃত্তি করতে। এই অ্যাক্সেস প্যাটার্ন FCM এবং এর নির্ভরশীল সিস্টেমের জন্য লোড-ব্যালেন্সিং সমস্যা তৈরি করে। যতটা সম্ভব ধীরে ধীরে ট্রাফিক বাড়ান। সর্বনিম্ন, একটি 60 সেকেন্ডের টাইম-উইন্ডো জুড়ে 0 থেকে সর্বোচ্চ RPS পর্যন্ত র্যাম্প। উচ্চতর RPS এর জন্য লম্বা উইন্ডো পছন্দ করুন।
"অন-দ্য-আওয়ার" ট্রাফিক এড়িয়ে চলুন
যেখানে সম্ভব : :00, :15, :30, এবং :45 মিনিটের প্রতিটির 2 মিনিটের মধ্যে বার্তা পাঠানো এড়িয়ে চলুন।
সার্ভার-সাইড থ্রোটলিং প্রয়োগ করুন
FCM-এ ট্রাফিকের প্রবাহ নিরীক্ষণ এবং পরিচালনা করতে সার্ভার-সাইড থ্রোটলিং প্রয়োগ করুন।
পুনরায় চেষ্টা পরিচালনা করা
যদিও FCM অত্যন্ত উপলভ্য হওয়ার চেষ্টা করে, মাঝে মাঝে কিছু অনুরোধের সময় শেষ বা ব্যর্থ হয়। যদিও কারণগুলি পরিবর্তিত হয়, নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি যানজটের প্রভাব কমিয়ে যত তাড়াতাড়ি সম্ভব বার্তাগুলি সরবরাহ করার জন্য পুনরায় চেষ্টা করার আচরণকে অপ্টিমাইজ করে৷
টাইমআউট
পুনরায় চেষ্টা করার আগে অনুরোধ পাঠাতে কমপক্ষে 10 সেকেন্ডের সময়সীমা সেট করুন। FCM-এর অভ্যন্তরীণ রিমোট প্রসিডিউর কলগুলির বেশিরভাগই 10 সেকেন্ডের টাইমআউট ব্যবহার করে।
ত্রুটি
- 400, 401, 403, 404 ত্রুটির জন্য: বাতিল করুন এবং পুনরায় চেষ্টা করবেন না।
- 429 ত্রুটির জন্য: পুনরায় চেষ্টা-পরবর্তী হেডারে নির্ধারিত সময়কালের জন্য অপেক্ষা করার পরে পুনরায় চেষ্টা করুন। যদি কোনো পুনরায় চেষ্টা-পরবর্তী শিরোনাম সেট করা না থাকে, ডিফল্ট 60 সেকেন্ড।
- 500টি ত্রুটির জন্য: সূচকীয় ব্যাকঅফের সাথে পুনরায় চেষ্টা করুন।
সূচকীয় ব্যাকঅফ
পুনরায় চেষ্টা পরিবর্ধন এড়াতে, পুনরায় চেষ্টা করার অনুরোধের জন্য জিটারিং সহ সূচকীয় ব্যাক-অফ প্রয়োগ করুন। ফায়ারবেস অ্যাডমিন SDK, উদাহরণস্বরূপ, সূচকীয় ব্যাকঅফ প্রয়োগ করে।
এখানে আরো কিছু প্রস্তাবিত সেটিংস রয়েছে:
- ন্যূনতম ব্যবধান: FCM এর সাথে একটি ব্যর্থ অনুরোধ অবিলম্বে পুনরায় চেষ্টা করবেন না। একটি ব্যর্থ অনুরোধ পুনরায় চেষ্টা করার আগে কমপক্ষে 10 সেকেন্ড অপেক্ষা করুন।
- সর্বাধিক ব্যবধান: অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করার পরিবর্তে, আর সময়োপযোগী নয় এমন অনুরোধগুলি বাদ দেওয়ার জন্য একটি সর্বোচ্চ ব্যবধান সেট করুন।
যদি একটি অনুরোধ ক্রমাগত সূচকীয় ব্যাকঅফের সাথে পুনঃচেষ্টা করা হয় এবং 60 মিনিট পরেও ব্যর্থ হয়, তবে এটি হয় একটি পুনরায় চেষ্টাযোগ্য ত্রুটি হিসাবে ভুল শ্রেণিবদ্ধ করা হয়েছে, অথবা FCM একটি বিভ্রাটের সম্মুখীন হচ্ছে যেখানে পুনঃপ্রয়াস অসাবধানতাবশত পরিস্থিতিকে আরও বাড়িয়ে তুলতে পারে।
রোলআউট এবং রোলব্যাক পরিকল্পনা তৈরি করুন এবং ধীরে ধীরে পরিবর্তন করুন
বড় আকারের ট্রাফিক পরিবর্তনগুলি করার সময়, যেমন FCM-এ ট্র্যাফিক বাড়ানো বা অঞ্চল বা নেটওয়ার্ক জুড়ে ট্র্যাফিক স্থানান্তর করা, একটি রোলআউট/রোলব্যাক প্ল্যান ডিজাইন করা এবং ধীরে ধীরে পরিবর্তনগুলি বাস্তবায়ন করা আপনার ব্যবহারকারী, আপনার পরিষেবা এবং FCMকে রক্ষা করবে৷
- একটি রোলআউট পরিকল্পনা স্টেকহোল্ডারদের জন্য প্রত্যাশাগুলিকে সারিবদ্ধ করে৷ কিছু নির্দিষ্ট পরিস্থিতিতে (নীচে আলোচনা করা হয়েছে), আপনি চমক এড়াতে আপনার রোলআউট পরিকল্পনাটি FCM টিমের সাথে শেয়ার করতে চাইতে পারেন।
- একটি রোলব্যাক প্ল্যান আপনাকে অপ্রত্যাশিত ব্যর্থতা থেকে দ্রুত এবং নিরাপদে পুনরুদ্ধার করার জন্য অপ্রত্যাশিত পরিস্থিতিগুলির জন্য অ্যাকাউন্ট এবং প্রক্রিয়া প্রস্তুত করার অনুমতি দেয়।
- ধীরে ধীরে পরিবর্তন করার দুটি দিক রয়েছে:
- "ধাপ অনুসারে" র্যাম্প-আপ: ধাপগুলি 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% বা আরও সূক্ষ্ম হওয়া উচিত৷ 1 দিন থেকে 1 সপ্তাহের জন্য প্রতিটি ধাপে " ভেজান " (লোডের অধীনে সিস্টেমের আচরণ পর্যবেক্ষণ করুন)। এটি আপনাকে পরবর্তী "স্টেপ-আপ" এর আগে সম্ভাব্য সমস্যাগুলি চিহ্নিত করতে দেয়
- ধীরে ধীরে ট্র্যাফিক র্যাম্প-আপ: ট্র্যাফিক বাড়াতে প্রতিটি "পদক্ষেপ" নেওয়ার সময়, কমপক্ষে এক ঘন্টার ব্যবধানে ট্র্যাফিককে মসৃণ করুন। এটি এফসিএম-এর লোড-ব্যালেন্সিং অবকাঠামোকে আপনার নতুন ট্র্যাফিককে যথাযথভাবে স্কেল করার অনুমতি দেয় যখন হটস্পট এবং যানজটের সম্ভাবনা কমিয়ে দেয়।
FCM লিগ্যাসি HTTP API থেকে FCM HTTP v1 API-তে বিশ্বব্যাপী 500,000 RPS স্থানান্তর করার জন্য এখানে একটি অনুমানমূলক দৃশ্য রয়েছে:
| সপ্তাহ | ধাপ | ধীরে ধীরে র্যাম্প-আপ কৌশল |
|---|---|---|
| 0 | 1% র্যাম্প-আপ | এক ঘণ্টার মধ্যে 0 থেকে 5,000 RPS থেকে FCM HTTP v1 পর্যন্ত মসৃণভাবে র্যাম্প-আপ করুন। |
| 1 | 5% র্যাম্প-আপ | 2 ঘন্টার মধ্যে 5,000 থেকে 25,000 RPS পর্যন্ত মসৃণভাবে র্যাম্প-আপ করুন। |
| 2 | 10% র্যাম্প-আপ | 2 ঘন্টার মধ্যে 25,000 থেকে 50,000 RPS পর্যন্ত মসৃণভাবে র্যাম্প আপ করুন |
| 3 | 25% র্যাম্প-আপ | 3 ঘন্টার মধ্যে 50,000 থেকে 125,000 RPS পর্যন্ত র্যাম্প-আপ |
| 4 | 50% র্যাম্প-আপ | 6 ঘন্টার মধ্যে 125,000 থেকে 250,000 RPS পর্যন্ত র্যাম্প-আপ |
| 5 | 75% র্যাম্প-আপ | 6 ঘন্টার মধ্যে 250,000 থেকে 375,000 RPS পর্যন্ত র্যাম্প-আপ |
| 6 | 100% র্যাম্প-আপ | 6 ঘন্টার মধ্যে 375,000 থেকে 500,000 RPS পর্যন্ত র্যাম্প-আপ |
অনুমানমূলক রোলব্যাক পরিকল্পনা:
- যদি 95-শতাংশ লেটেন্সি 500 ms-এর বেশি বাড়ে বা ত্রুটির অনুপাত 1% অতিক্রম করে যে কোনও ধাপে এক ঘন্টার বেশি হলে, অবিলম্বে পূর্ববর্তী ধাপে ফিরে যেতে গতিশীল কনফিগারেশন ব্যবহার করুন।
- লেটেন্সি এবং ত্রুটির অনুপাত নামমাত্র স্তরে ফিরে না আসা পর্যন্ত আগের ধাপগুলিতে রোলব্যাকগুলি চালিয়ে যান৷
কখন FCM এর সাথে যোগাযোগ করতে হবে
Firebase সহায়তার মাধ্যমে FCM-এর সাথে যোগাযোগ করুন যদি নিচের কোনটি প্রযোজ্য হয়:
- ডিফল্ট কোটা আর আপনার ব্যবহারের ক্ষেত্রে পূরণ করে না
- আপনি বিশ্বব্যাপী 100,000 RPS বা মহাদেশীয়ভাবে 30,000 RPS স্কেলে 3 মাসের উইন্ডোর মধ্যে আপনার পাঠানোর ধরণ পরিবর্তন করছেন।