আমরা যখন একচেটিয়া অ্যাপ্লিকেশন থেকে একটি মাইক্রোসার্ভিসেস আর্কিটেকচারে চলে যাই, তখন আমরা নতুন চ্যালেঞ্জের মুখোমুখি হই।

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

আমি এমন একটি সরঞ্জামের জন্য দীর্ঘ সময় ধরে খুঁজছি যা এই জাতীয় সমস্যাগুলি মোকাবেলায় সহায়তা করবে (আমি হ্যাব্রেতে এটি সম্পর্কে লিখেছিলাম: 1, 2), কিন্তু শেষ পর্যন্ত আমি আমার নিজের ওপেন সোর্স সমাধান তৈরি করেছি। এই নিবন্ধে আমি পরিষেবা জাল পদ্ধতির সুবিধা সম্পর্কে কথা বলি এবং এটির বাস্তবায়নের জন্য একটি নতুন টুল শেয়ার করি।

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

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

পরিষেবা জাল পদ্ধতি

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

সমাধান

ইতিমধ্যে এই পদ্ধতির বেশ কয়েকটি বাস্তবায়ন রয়েছে: ইসতিও и linkerd2. তারা বাক্সের বাইরে অনেক বৈশিষ্ট্য সরবরাহ করে। কিন্তু একই সময়ে, সম্পদের উপর একটি বড় ওভারহেড আসে। অধিকন্তু, যে ক্লাস্টারে এই ধরনের সিস্টেম কাজ করে, নতুন অবকাঠামো বজায় রাখার জন্য আরও সংস্থান প্রয়োজন হবে। আভিটোতে, আমরা কুবারনেটস ক্লাস্টারগুলি পরিচালনা করি যেগুলিতে হাজার হাজার পরিষেবার উদাহরণ রয়েছে (এবং তাদের সংখ্যা দ্রুত বাড়তে থাকে)। এর বর্তমান বাস্তবায়নে, Istio প্রতি পরিষেবা দৃষ্টান্তে ~300Mb RAM ব্যবহার করে। বিপুল সংখ্যক সম্ভাবনার কারণে, স্বচ্ছ ভারসাম্য পরিষেবার সামগ্রিক প্রতিক্রিয়া সময়কেও প্রভাবিত করে (10ms পর্যন্ত)।

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

ফলস্বরূপ, আমরা আমাদের সিদ্ধান্তে এসেছি:  নেত্রমেশ.

নেত্রমেশ

নেত্রমেশ সিস্টেমে পরিষেবার সংখ্যা নির্বিশেষে অসীমভাবে স্কেল করার ক্ষমতা সহ একটি হালকা ওজনের পরিষেবা জাল সমাধান।

নতুন সমাধানের প্রধান লক্ষ্য ছিল কম রিসোর্স ওভারহেড এবং উচ্চ কর্মক্ষমতা। প্রধান বৈশিষ্ট্যগুলির মধ্যে, আমরা অবিলম্বে আমাদের Jaeger সিস্টেমে স্বচ্ছভাবে ট্রেসিং স্প্যান পাঠাতে সক্ষম হতে চেয়েছিলাম।

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

উৎপাদনশীলতা

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

দেখা যাক আমরা কি ফলাফল পেয়েছি।

র্যাম

নেট্রামেশ ট্রাফিক ছাড়াই ~10Mb এবং প্রতি উদাহরণে 50 RPS পর্যন্ত লোড সহ সর্বাধিক 10000Mb খরচ করে।

Istio দূত প্রক্সি সবসময় হাজার হাজার উদাহরণ সহ আমাদের ক্লাস্টারে ~300Mb খরচ করে৷ এটি এটিকে পুরো ক্লাস্টারে স্কেল করার অনুমতি দেয় না।

নেত্রমেশের সাথে আমরা মেমরি খরচে ~10x হ্রাস পেয়েছি।

সিপিইউ

CPU ব্যবহার লোডের অধীনে তুলনামূলকভাবে সমান। এটি সাইডকারের প্রতি ইউনিটের অনুরোধের সংখ্যার উপর নির্ভর করে। সর্বোচ্চ সময়ে প্রতি সেকেন্ডে 3000 অনুরোধে মান:

আরও একটি গুরুত্বপূর্ণ বিষয় রয়েছে: নেট্রামেশ - একটি নিয়ন্ত্রণ সমতল ছাড়া এবং লোড ছাড়াই একটি সমাধান CPU সময় ব্যয় করে না। ইস্টিওর সাথে, সাইডকাররা সর্বদা পরিষেবার শেষ পয়েন্ট আপডেট করে। ফলস্বরূপ, আমরা লোড ছাড়াই এই ছবিটি দেখতে পারি:

আমরা পরিষেবাগুলির মধ্যে যোগাযোগের জন্য HTTP/1 ব্যবহার করি। দূতের মাধ্যমে প্রক্সি করার সময় Istio-এর প্রতিক্রিয়া সময়ের বৃদ্ধি 5-10ms পর্যন্ত ছিল, যা মিলিসেকেন্ডে প্রতিক্রিয়া জানাতে প্রস্তুত পরিষেবাগুলির জন্য অনেক বেশি। নেত্রমেশের সাথে এই সময় কমেছে 0.5-2ms।

মাপযোগ্যতা

প্রতিটি প্রক্সি দ্বারা ব্যবহৃত স্বল্প পরিমাণ সম্পদ একে প্রতিটি পরিষেবার পাশে স্থাপন করা সম্ভব করে। নেট্রামেশ ইচ্ছাকৃতভাবে প্রতিটি সাইডকারকে হালকা রাখার জন্য একটি নিয়ন্ত্রণ প্লেন উপাদান ছাড়াই তৈরি করা হয়েছিল। প্রায়শই পরিষেবা জাল সমাধানে, নিয়ন্ত্রণ বিমান প্রতিটি সাইডকারে পরিষেবা আবিষ্কারের তথ্য বিতরণ করে। এর সাথে টাইমআউট এবং ব্যালেন্সিং সেটিংস সম্পর্কে তথ্য আসে। এই সব আপনি দরকারী জিনিস অনেক করতে পারবেন, কিন্তু, দুর্ভাগ্যবশত, এটি সাইডকার আকারে bloats.

পরিষেবা আবিষ্কার

Netramesh পরিষেবা আবিষ্কারের জন্য কোনো অতিরিক্ত প্রক্রিয়া যোগ করে না। নেত্র সাইডকারের মাধ্যমে সমস্ত ট্রাফিক স্বচ্ছভাবে প্রক্সি করা হয়।

Netramesh HTTP/1 অ্যাপ্লিকেশন প্রোটোকল সমর্থন করে। এটি সংজ্ঞায়িত করতে, পোর্টগুলির একটি কনফিগারযোগ্য তালিকা ব্যবহার করা হয়। সাধারণত, সিস্টেমে বেশ কয়েকটি পোর্ট রয়েছে যার মাধ্যমে HTTP যোগাযোগ ঘটে। উদাহরণস্বরূপ, আমরা পরিষেবা এবং বহিরাগত অনুরোধগুলির মধ্যে মিথস্ক্রিয়া করার জন্য 80, 8890, 8080 ব্যবহার করি৷ এই ক্ষেত্রে, সেগুলি একটি পরিবেশ পরিবর্তনশীল ব্যবহার করে সেট করা যেতে পারে৷ NETRA_HTTP_PORTS.

আপনি যদি কুবারনেটসকে অর্কেস্ট্রেটর হিসাবে ব্যবহার করেন এবং পরিষেবাগুলির মধ্যে আন্তঃ-ক্লাস্টার যোগাযোগের জন্য এর পরিষেবা সত্তা পদ্ধতি ব্যবহার করেন, তবে প্রক্রিয়াটি ঠিক একই থাকে। প্রথমে, মাইক্রোসার্ভিস kube-dns ব্যবহার করে একটি পরিষেবা আইপি ঠিকানা পায় এবং এটিতে একটি নতুন সংযোগ খোলে। এই সংযোগটি প্রথমে স্থানীয় নেট্রা-সাইডকারের সাথে স্থাপিত হয় এবং সমস্ত টিসিপি প্যাকেট প্রাথমিকভাবে নেত্রায় পৌঁছায়। পরবর্তীতে, নেট্রা-সাইডকার মূল গন্তব্যের সাথে একটি সংযোগ স্থাপন করে। নোডের পড আইপিতে NAT নেট্রা ছাড়াই ঠিক একই রকম থাকে।

বিতরণ ট্রেসিং এবং প্রসঙ্গ ফরওয়ার্ডিং

Netramesh HTTP মিথস্ক্রিয়া সম্পর্কে ট্রেসিং স্প্যান পাঠাতে প্রয়োজনীয় কার্যকারিতা প্রদান করে। Netra-sidecar HTTP প্রোটোকল পার্স করে, অনুরোধ বিলম্ব পরিমাপ করে এবং HTTP হেডার থেকে প্রয়োজনীয় তথ্য বের করে। শেষ পর্যন্ত, আমরা একটি একক Jaeger সিস্টেমে সমস্ত ট্রেস পাই। সূক্ষ্ম কনফিগারেশনের জন্য, আপনি অফিসিয়াল লাইব্রেরি দ্বারা প্রদত্ত পরিবেশ ভেরিয়েবলগুলিও ব্যবহার করতে পারেন jaeger যান লাইব্রেরী.

কিন্তু একটি সমস্যা আছে. যতক্ষণ না পরিষেবাগুলি একটি বিশেষ উবার হেডার তৈরি করে এবং পাঠায়, আমরা সিস্টেমে সংযুক্ত ট্রেসিং স্প্যান দেখতে পাব না। এবং এটিই আমাদের দ্রুত সমস্যার কারণ খুঁজে বের করতে হবে। এখানে আবার নেত্রমেশের একটি সমাধান আছে। প্রক্সিগুলি HTTP শিরোনামগুলি পড়ে এবং, যদি সেগুলিতে উবার ট্রেস আইডি না থাকে তবে একটি তৈরি করে৷ নেত্রমেশ একটি সাইডকারে ইনকামিং এবং আউটগোয়িং রিকোয়েস্টের তথ্যও সঞ্চয় করে এবং প্রয়োজনীয় আউটগোয়িং রিকোয়েস্ট হেডার দিয়ে সমৃদ্ধ করে সেগুলিকে মেলে। পরিষেবাগুলিতে আপনাকে যা করতে হবে তা হল শুধুমাত্র একটি শিরোনাম পাঠাতে X-Request-Id, যা একটি পরিবেশ পরিবর্তনশীল ব্যবহার করে কনফিগার করা যেতে পারে NETRA_HTTP_REQUEST_ID_HEADER_NAME. নেট্রামেশে প্রেক্ষাপটের আকার নিয়ন্ত্রণ করতে, আপনি নিম্নলিখিত পরিবেশ ভেরিয়েবল সেট করতে পারেন: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (যে সময়টির জন্য প্রসঙ্গ সংরক্ষণ করা হবে) এবং NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (প্রসঙ্গ পরিষ্কারের ফ্রিকোয়েন্সি)।

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

অনুরোধ উত্স নির্ধারণ

অনুরোধটি কোথা থেকে এসেছে তা নির্ধারণ করতে, আপনি উত্সের সাথে স্বয়ংক্রিয়ভাবে একটি শিরোনাম যুক্ত করার কার্যকারিতা ব্যবহার করতে পারেন। একটি পরিবেশ পরিবর্তনশীল ব্যবহার করে NETRA_HTTP_X_SOURCE_HEADER_NAME আপনি একটি হেডার নাম নির্দিষ্ট করতে পারেন যা স্বয়ংক্রিয়ভাবে ইনস্টল হবে। ব্যবহার করে NETRA_HTTP_X_SOURCE_VALUE আপনি সমস্ত বহির্গামী অনুরোধের জন্য X-উৎস শিরোনাম সেট করা হবে এমন মান সেট করতে পারেন।

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

ট্রাফিক রাউটিং এবং নেট্রামেশ ইন্টারনাল

নেত্রমেশ দুটি প্রধান উপাদান নিয়ে গঠিত। প্রথম, নেট্রা-ইনিট, ট্র্যাফিক বাধা দেওয়ার জন্য নেটওয়ার্ক নিয়ম সেট করে। সে ব্যবহার করে iptables নিয়ম পুনর্নির্দেশ সাইডকারের সমস্ত বা আংশিক ট্রাফিককে আটকাতে, যা নেত্রমেশের দ্বিতীয় প্রধান উপাদান। ইনকামিং এবং আউটগোয়িং TCP সেশনের জন্য কোন পোর্টগুলিকে আটকাতে হবে তা আপনি কনফিগার করতে পারেন: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

টুলটির একটি আকর্ষণীয় বৈশিষ্ট্যও রয়েছে - সম্ভাব্য রাউটিং। আপনি যদি ট্রেসিং স্প্যান সংগ্রহের জন্য একচেটিয়াভাবে নেট্রামেশ ব্যবহার করেন, তাহলে একটি উত্পাদন পরিবেশে আপনি সম্পদ সংরক্ষণ করতে পারেন এবং ভেরিয়েবল ব্যবহার করে সম্ভাব্য রাউটিং সক্ষম করতে পারেন NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 থেকে 1 পর্যন্ত)। ডিফল্ট মান হল 1 (সমস্ত ট্রাফিক আটকানো হয়েছে)।

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

একটি নির্ভরতা গ্রাফ নির্মাণ

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

আপনি যদি ট্রেসিং স্প্যানগুলি সংরক্ষণ করতে ইলাস্টিকসার্চ ব্যবহার করেন তবে আপনি ব্যবহার করতে পারেন একটি সাধারণ গোলং ইউটিলিটি, যা ইলাস্টিকসার্চের বৈশিষ্ট্য এবং ক্ষমতা ব্যবহার করে মিনিটের মধ্যে একই গ্রাফ তৈরি করবে।

নেত্রমেশ কিভাবে ব্যবহার করবেন

নেত্রা যেকোন অর্কেস্ট্রেটর চালিত যে কোনও পরিষেবাতে সহজেই যুক্ত করা যেতে পারে। আপনি একটি উদাহরণ দেখতে পারেন এখানে.

এই মুহুর্তে, নেত্রার স্বয়ংক্রিয়ভাবে পরিষেবাগুলিতে সাইডকারগুলি প্রয়োগ করার ক্ষমতা নেই, তবে বাস্তবায়নের পরিকল্পনা রয়েছে।

নেত্রমেশের ভবিষ্যৎ

প্রধান লক্ষ্য নেত্রমেশ ন্যূনতম সম্পদ খরচ এবং উচ্চ কর্মক্ষমতা অর্জন, পর্যবেক্ষণযোগ্যতা এবং আন্তঃ-পরিষেবা যোগাযোগের নিয়ন্ত্রণের জন্য মৌলিক ক্ষমতা প্রদান করে।

ভবিষ্যতে, Netramesh HTTP ছাড়াও অন্যান্য অ্যাপ্লিকেশন লেয়ার প্রোটোকল সমর্থন করবে। L7 রাউটিং অদূর ভবিষ্যতে উপলব্ধ হবে।

আপনি যদি একই ধরনের সমস্যার সম্মুখীন হন এবং প্রশ্ন ও পরামর্শ সহ আমাদের কাছে লিখুন তাহলে Netramesh ব্যবহার করুন।

উত্স: www.habr.com