Observability (অবজারভেবিলিটি ডিপ-ডাইভ)
সিস্টেম ডিজাইন করার পর সেটি সঠিকভাবে চলছে কি না এবং কোনো সমস্যা হলে তা দ্রুত খুঁজে বের করার জন্য অবজারভেবিলিটি (Observability) প্রয়োজন। এটি মূলত সিস্টেমের অভ্যন্তরীণ অবস্থা (Internal State) বাইরে থেকে বোঝার একটি প্রক্রিয়া।
১. লগিং (Logging)
লগিং হলো সিস্টেমের প্রতিটি ইভেন্ট বা কাজের রেকর্ড রাখা। মাইক্রোসার্ভিসে লগিং করা কিছুটা চ্যালেঞ্জিং কারণ ডেটা অনেকগুলো সার্ভিসে ছড়ানো থাকে।
- Centralized Logging: সব সার্ভিসের লগ এক জায়গায় (উদা: ELK Stack - Elasticsearch, Logstash, Kibana) জমা করা উচিত।
- Structured Logging: লগগুলো নির্দিষ্ট ফরম্যাটে (উদা: JSON) হওয়া উচিত যাতে সহজে সার্চ করা যায়।
- Log Levels: ডিবাগিংয়ের জন্য
DEBUG, সাধারণ তথ্যের জন্যINFO, এবং সমস্যার জন্যERRORলেভেল ব্যবহার করা হয়।
২. মনিটরিং এবং অ্যালার্টিং (Monitoring & Alerting)
মনিটরিং (Monitoring)
সিস্টেমের 'স্বাস্থ্য' পরীক্ষা করার জন্য মনিটরিং করা হয়। এটি মূলত মেট্রিক্স (Metrics) সংগ্রহ করার প্রক্রিয়া।
- Key Metrics:
- Latency: একটি রিকোয়েস্ট প্রসেস হতে কত সময় লাগছে।
- Error Rate: কত শতাংশ রিকোয়েস্ট ফেইল করছে।
- Traffic: প্রতি সেকেন্ডে কতগুলো রিকোয়েস্ট (RPS) আসছে।
- Saturation: সিপিপিইউ বা মেমরি কতটুকু ব্যবহৃত হচ্ছে।
- টুলস: Prometheus, Grafana, Datadog.
অ্যালার্টিং (Alerting)
যখন কোনো মেট্রিক নির্দিষ্ট সীমা (Threshold) অতিক্রম করে, তখন ডেভেলপারদের নোটিফিকেশন পাঠানোই হলো অ্যালার্টিং।
- উদা: যদি এরর রেট ৫% এর বেশি হয়, তবে সাথে সাথে স্ল্যাক (Slack) বা ইমেইলে অ্যালার্ট পাঠানো।
৩. ক্যাওস ইঞ্জিনিয়ারিং (Chaos Engineering)
Chaos Engineering হলো একটি সিস্টেমের স্থিতিশীলতা যাচাই করার জন্য 'ইচ্ছাকৃতভাবে' সিস্টেমে সমস্যা বা ফেইলিওর তৈরি করা।
- উদ্দেশ্য: সিস্টেমটি অপ্রত্যাশিত কোনো ফাটল বা ডাউনটাইম হ্যান্ডেল করতে পারে কি না তা দেখা।
- কিভাবে করা হয়: র্যান্ডমলি কোনো সার্ভার শাটডাউন করে দেওয়া বা নেটওয়ার্ক ল্যাটেন্সি বাড়িয়ে দেওয়া।
- টুলস: Chaos Monkey (Netflix এর তৈরি), Gremlin.
৪. অবজারভেবিলিটির ৩টি স্তম্ভ (Three Pillars)
১. Metrics: সংখ্যার মাধ্যমে সিস্টেমের অবস্থা বোঝা (উদা: CPU 80%)। ২. Logs: নির্দিষ্ট সময়ে কী ঘটেছে তার বর্ণনা (উদা: User X failed to login)। ৩. Traces: একটি রিকোয়েস্ট সিস্টেমের কোন কোন সার্ভিসের মধ্য দিয়ে গেছে তার ম্যাপ (Distributed Tracing)।
৫. সাধারণ ইন্টারভিউ প্রশ্নোত্তর (General Q&A)
প্রশ্ন ১: অবজারভেবিলিটি এবং মনিটরিং এর মধ্যে পার্থক্য কী?উত্তর: মনিটরিং আপনাকে বলে যে সিস্টেমটি "কাজ করছে না" (উদা: সার্ভার ডাউন)। আর অবজারভেবিলিটি আপনাকে বুঝতে সাহায্য করে যে "কেন কাজ করছে না" এবং ভেতরে ঠিক কী ঘটছে।
প্রশ্ন ২: ডিস্ট্রিবিউটেড ট্রেসিং (Distributed Tracing) কেন প্রয়োজন?উত্তর: মাইক্রোসার্ভিসে একটি ইউজার রিকোয়েস্ট ১০টি সার্ভিসে যেতে পারে। যদি এরর হয়, তবে কোন সার্ভিসে সমস্যা হয়েছে তা বোঝার জন্য প্রতিটি রিকোয়েস্টের সাথে একটি ইউনিক Trace ID পাস করা হয়।
প্রশ্ন ৩: ক্যাওস ইঞ্জিনিয়ারিং কি প্রোডাকশন এনভায়রনমেন্টে করা নিরাপদ?উত্তর: এটি অত্যন্ত অ্যাডভান্সড পদ্ধতি। সাধারণত শুরুতে স্টেজিং এনভায়রনমেন্টে করা হয়। যখন সিস্টেমটি অনেক বেশি ম্যাচিউর হয়ে যায়, তখনই কন্ট্রোল্ড ওয়েতে প্রোডাকশনে টেস্ট করা হয়।
৬. সিনারিও ভিত্তিক প্রশ্ন (Scenario-based Questions)
সিনারিও ১: "আপনার সিস্টেমে হঠাৎ ল্যাটেন্সি বেড়ে গেছে, কিন্তু ডাটাবেস এবং কোড—সবকিছু ঠিক দেখাচ্ছে। আপনি কীভাবে সমস্যাটি খুঁজে বের করবেন?"
সমাধান: এখানে আমি Distributed Tracing (উদা: Jaeger বা Zipkin) ব্যবহার করব। রিকোয়েস্টগুলো কোন সার্ভিসে কত সময় ব্যয় করছে তা দেখলে বোঝা যাবে কোনো থার্ড-পার্টি এপিআই কল বা ইন্টারনাল নেটওয়ার্কের কারণে ল্যাটেন্সি বাড়ছে কি না।
সিনারিও ২: "একটি ফ্ল্যাশ সেলের সময় আপনি কীভাবে নিশ্চিত করবেন যে আপনার সিস্টেম ক্র্যাশ করবে না?"
সমাধান: ১. আগের বছরের ডেটা দেখে Load Testing করব। ২. মেট্রিক্স মনিটর করার জন্য Grafana Dashboard রেডি রাখব। ৩. অতিরিক্ত ট্রাফিকের সময় যেন অটোমেটিক স্কেল হয় তার জন্য Alerting সেটআপ করব। ৪. প্রয়োজনে ক্যাওস ইঞ্জিনিয়ারিং করে দেখব কোনো একটি কম্পোনেন্ট ফেইল করলে কী হয়।
IMPORTANT
অবজারভেবিলিটি ছাড়া সিস্টেম ডিজাইন করা মানে অন্ধকারে গাড়ি চালানোর মতো। আর্লি ডিটেকশন আপনার সিস্টেমের ডাউনটাইম অনেক কমিয়ে দেয়।