টিপস & কৌশল

এই ডকুমেন্টে Cloud Functions ডিজাইন, বাস্তবায়ন, পরীক্ষা এবং স্থাপন করার সর্বোত্তম পদ্ধতি বর্ণনা করা হয়েছে।

সঠিকতা

এই অংশে Cloud Functions ডিজাইন ও বাস্তবায়নের সাধারণ সর্বোত্তম অনুশীলনগুলো বর্ণনা করা হয়েছে।

আইডম্পোটেন্ট ফাংশন লিখুন

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

পটভূমির কার্যকলাপ শুরু করবেন না।

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

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

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

সর্বদা অস্থায়ী ফাইলগুলি মুছে ফেলুন

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

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

আপনার যদি দীর্ঘমেয়াদী স্টোরেজে অ্যাক্সেসের প্রয়োজন হয়, তাহলে Cloud Storage বা NFS ভলিউমের সাথে Cloud Run ভলিউম মাউন্ট ব্যবহার করার কথা বিবেচনা করতে পারেন।

পাইপলাইনিং ব্যবহার করে বড় ফাইল প্রসেস করার সময় আপনি মেমরির প্রয়োজনীয়তা কমাতে পারেন। উদাহরণস্বরূপ, আপনি একটি রিড স্ট্রিম তৈরি করে, সেটিকে একটি স্ট্রিম-ভিত্তিক প্রক্রিয়ার মধ্যে দিয়ে পাঠিয়ে এবং আউটপুট স্ট্রিমটি সরাসরি ক্লাউড স্টোরেজে লিখে ক্লাউড স্টোরেজের একটি ফাইল প্রসেস করতে পারেন।

ফাংশন ফ্রেমওয়ার্ক

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

এটি করার জন্য, প্রাসঙ্গিক লক ফাইলে আপনার পছন্দের সংস্করণটি অন্তর্ভুক্ত করুন (উদাহরণস্বরূপ, Node.js-এর জন্য package-lock.json , অথবা Python-এর জন্য requirements.txt )।

যদি ফাংশনস ফ্রেমওয়ার্ককে নির্ভরতা হিসেবে স্পষ্টভাবে তালিকাভুক্ত করা না থাকে, তবে বিল্ড প্রক্রিয়ার সময় সর্বশেষ উপলব্ধ সংস্করণটি ব্যবহার করে এটি স্বয়ংক্রিয়ভাবে যুক্ত হয়ে যাবে।

সরঞ্জাম

এই বিভাগে Cloud Functions বাস্তবায়ন, পরীক্ষা এবং এর সাথে মিথস্ক্রিয়া করার জন্য টুলগুলো কীভাবে ব্যবহার করতে হয়, সে সম্পর্কে নির্দেশিকা প্রদান করা হয়েছে।

স্থানীয় উন্নয়ন

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

প্রারম্ভিকীকরণের সময় ডেপ্লয়মেন্ট টাইমআউট এড়িয়ে চলুন

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

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

টাইমআউট এড়াতে নিচের কৌশলগুলোর মধ্যে যেকোনো একটি ব্যবহার করুন:

প্রারম্ভিকীকরণ স্থগিত করতে onInit() ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।

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

const { onInit } = require('firebase-functions/v2/core');
const { onRequest } = require('firebase-functions/v2/https');

// Example of a slow initialization task
function slowInitialization() {
  // Simulate a long-running operation (e.g., loading a large model, network request).
  return new Promise(resolve => {
      setTimeout(() => {
          console.log("Slow initialization complete");
          resolve("Initialized Value");
      }, 20000); // Simulate a 20-second delay
  });
}
let initializedValue;

onInit(async () => {
  initializedValue = await slowInitialization();
});

exports.myFunction = onRequest((req, res) => {
  // Access the initialized value. It will be ready after the first invocation.
  res.send(`Value: ${initializedValue}`);
});

from firebase_functions.core import init
from firebase_functions import https_fn
import time

# Example of a slow initialization task
def _slow_initialization():
  time.sleep(20)  # Simulate a 20-second delay
  print("Slow initialization complete")
  return "Initialized Value"

_initialized_value = None

@init
def initialize():
  global _initialized_value
  _initialized_value = _slow_initialization()

@https_fn.on_request()
def my_function(req: https_fn.Request) -> https_fn.Response:
  # Access the initialized value. It will be ready after the first invocation.
  return https_fn.Response(f"Value: {_initialized_value}")

(বিকল্প) ডিসকভারি টাইমআউট বাড়ান

যদি আপনি onInit() ব্যবহার করার জন্য আপনার কোড রিফ্যাক্টর করতে না পারেন, তাহলে আপনি FUNCTIONS_DISCOVERY_TIMEOUT এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করে CLI-এর ডিপ্লয়মেন্ট টাইমআউট বাড়াতে পারেন:

$ export FUNCTIONS_DISCOVERY_TIMEOUT=30
$ firebase deploy --only functions

ইমেল পাঠাতে সেন্ডগ্রিড ব্যবহার করুন

Cloud Functions পোর্ট ২৫-এ আউটবাউন্ড সংযোগের অনুমতি দেয় না, তাই আপনি কোনো SMTP সার্ভারে অসুরক্ষিত সংযোগ স্থাপন করতে পারবেন না। ইমেল পাঠানোর জন্য সেন্ডগ্রিড (SendGrid)- এর মতো কোনো থার্ড-পার্টি পরিষেবা ব্যবহার করার পরামর্শ দেওয়া হয়। গুগল কম্পিউট ইঞ্জিনের জন্য তৈরি 'সেন্ডিং ইমেল ফ্রম অ্যান ইনস্ট্যান্স' টিউটোরিয়ালে আপনি ইমেল পাঠানোর অন্যান্য বিকল্প খুঁজে পেতে পারেন।

কর্মক্ষমতা

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

কম সমকালীনতা এড়িয়ে চলুন

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

নির্ভরতাগুলি বিজ্ঞতার সাথে ব্যবহার করুন

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

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

ভবিষ্যতে অবজেক্ট পুনরায় ব্যবহার করার জন্য গ্লোবাল ভেরিয়েবল ব্যবহার করুন।

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

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

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

গ্লোবাল স্কোপে নেটওয়ার্ক সংযোগ, লাইব্রেরি রেফারেন্স এবং এপিআই ক্লায়েন্ট অবজেক্ট ক্যাশ করা বিশেষভাবে গুরুত্বপূর্ণ। উদাহরণের জন্য ‘নেটওয়ার্কিং অপ্টিমাইজ করা’ দেখুন।

ন্যূনতম সংখ্যক ইনস্ট্যান্স সেট করে কোল্ড স্টার্ট হ্রাস করুন।

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

কোল্ড স্টার্ট এবং ইনিশিয়ালাইজেশন সম্পর্কে নোট

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

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

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

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

একটি অ্যাসিঙ্ক নোড.জেএস লাইব্রেরি প্রি-ওয়ার্মিং করার উদাহরণ

ফায়ারস্টোর সহ নোড.জেএস হলো একটি অ্যাসিঙ্ক নোড.জেএস লাইব্রেরির উদাহরণ। min_instances-এর সুবিধা নেওয়ার জন্য, নিম্নলিখিত কোডটি মডিউল লোডিং-এর সময় ব্লক হয়ে লোড হওয়ার মুহূর্তেই লোডিং এবং ইনিশিয়ালাইজেশন সম্পন্ন করে।

TLA ব্যবহৃত হয়, যার অর্থ ES6 আবশ্যক। এর জন্য node.js কোডের জন্য .mjs এক্সটেনশন ব্যবহার করতে হবে অথবা package.json ফাইলে type: module যোগ করতে হবে।

{
  "main": "main.js",
  "type": "module",
  "dependencies": {
    "@google-cloud/firestore": "^7.10.0",
    "@google-cloud/functions-framework": "^3.4.5"
  }
}

import Firestore from '@google-cloud/firestore';
import * as functions from '@google-cloud/functions-framework';

const firestore = new Firestore({preferRest: true});

// Pre-warm firestore connection pool, and preload our global config
// document in cache. In order to ensure no other request comes in,
// block the module loading with a synchronous global request:
const config = await firestore.collection('collection').doc('config').get();

functions.http('fetch', (req, res) => {

// Do something with config and firestore client, which are now preloaded
// and will execute at lower latency.
});

গ্লোবাল প্রারম্ভিকীকরণের উদাহরণ

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

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

অতিরিক্ত সম্পদ

পারফরম্যান্স অপ্টিমাইজ করার বিষয়ে আরও জানতে 'গুগল ক্লাউড পারফরম্যান্স অ্যাটলাস'-এর Cloud Functions কোল্ড বুট টাইম ' ভিডিওটি দেখুন।