কেন বড় কারিগরি কর্পোরেশন মালিকানা সমাধান তৈরিতে আচ্ছন্ন

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

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

উন্নয়ন চক্র সংগঠিত করার জন্য সরঞ্জামের উদাহরণ

একটি সমস্যা সমাধানের জন্য, আমরা প্রায়শই তৈরি জিনিসগুলি বাস্তবায়নের পরিবর্তে মালিকানাধীন সরঞ্জামগুলি বিকাশ করি। উদাহরণস্বরূপ, টিমের একজন প্রোগ্রামার থাকাকালীন, আমি C++ এবং পাইথনে একটি পরিমাণগত পর্যবেক্ষণ সিস্টেমে কাজ করেছি এবং এটিকে কয়েক বিলিয়ন প্রক্রিয়াকৃত মেট্রিক্সে স্কেল করতে সাহায্য করেছি। তাই, আমার নিজের অভিজ্ঞতার উপর ভিত্তি করে, আমি জানি কি অনুপ্রেরণা এবং বিকাশের পথগুলি অভ্যন্তরীণ সরঞ্জামগুলির উত্থানের দিকে পরিচালিত করে: নীচে, আমি উদাহরণ হিসাবে আমাদের সমাধানগুলি ব্যবহার করে তাদের সৃষ্টির মৌলিক কারণগুলি চিহ্নিত করার চেষ্টা করব৷

গল্প #1: ইয়ানডেক্স অভ্যন্তরীণ মেঘ

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

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

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

মূলত, আমাদের কুবারনেটসের প্রয়োজন ছিল (এবং সময়ের সাথে সাথে, আরটিসি খুব কাছাকাছি এসেছিল)। কিন্তু এখানে ধরা হল: k8s শুধুমাত্র 2014 সালে ঘোষণা করা হয়েছিল। Apache Mesos তখন বিদ্যমান ছিল, কিন্তু এটি তার শৈশবকালে ছিল।

মৌলিক ফাংশন বাস্তবায়ন। আমরা এক ধরণের এমভিপি দিয়ে সমস্যা সমাধান করা শুরু করেছি - একটি সাধারণ সরঞ্জামের সেট, যা ছিল বিল্ডিং ব্লকের একটি সেটের মতো যা রুটিন ক্রিয়াগুলি স্বয়ংক্রিয় করে, উদাহরণস্বরূপ:

• ক্লাস্টার সম্পদ বরাদ্দ;
• অ্যাপ্লিকেশনের প্রয়োজনীয় সংস্করণ এবং ক্লাস্টারে বিভিন্ন শিল্পকর্ম সরবরাহ করা;
• ক্লাস্টারে অ্যাপ্লিকেশনটির প্রয়োজনীয় সংস্করণ চালু করুন।

সময়ের সাথে সাথে, এই বিল্ডিং ব্লকগুলি (একটানা ডেলিভারির অনুরূপ) ব্যবহার করে একটি পূর্ণাঙ্গ পরিষেবা লেআউট গ্রাফ একত্রিত করা সম্ভব হয়েছে। নির্দিষ্ট সংখ্যক পুনরাবৃত্তির পরে, RTC-তে চলমান পরিষেবাগুলি পরিচালনা করার জন্য একটি সিস্টেম, 2013 সালে আবির্ভূত হয়েছিল।

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

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

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

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

নতুন ক্রমবর্ধমান যন্ত্রণা। একই সময়ের মধ্যে, k8s অনেক বেশি পরিপক্ক সমাধানে বিকশিত হয়েছে, 2017 সালে AWS পরিষেবাগুলির মধ্যে একটি হয়ে উঠেছে৷ কিন্তু এটি এখনও আমাদের সমস্ত প্রয়োজনীয়তা পূরণ করেনি:

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

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

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

বর্তমানে, RTC 100,000 সার্ভারে 5 মিলিয়নেরও বেশি কোর বরাদ্দ করে কয়েক হাজার পরিষেবা চালু করেছে। প্রতিদিন, সার্ভিস স্পেসিফিকেশনে 100,000-এর বেশি পরিবর্তন করা হয়।

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

মনে রাখার আরেকটি গুরুত্বপূর্ণ বিষয় হল মাইগ্রেশন সমস্যা। জুলাই 2018 অনুযায়ী প্রতিবেদনে বলা হয়েছে, 2025 সালের মধ্যে 90% আধুনিক অ্যাপ্লিকেশন এখনও ব্যবহার করা হবে এবং এই সিস্টেমগুলির বিকাশের জন্য প্রযুক্তিগত ঋণ আইটি বাজেটের 40% এরও বেশি হবে। ইয়ানডেক্স প্ল্যানারে ব্যবহারকারী পরিষেবাগুলি স্থানান্তরিত করার আমাদের অভিজ্ঞতার ভিত্তিতে এটি বাস্তবতার কাছাকাছি: 2023 সালে, প্রায় 100k কোর এখনও Yandex Planner-এ যাওয়ার জন্য তাদের পালা অপেক্ষা করছে৷

2021 সালে, আমরা আমাদের ডেভেলপমেন্ট কৌশল বেছে নেওয়ার সময় একটি স্থাপনার সিস্টেম থেকে অন্যটিতে যেতে কত খরচ হবে তা অনুমান করেছি। ভ্যানিলা k8s-এ ইয়ানডেক্সের স্থানান্তর একটি অত্যন্ত ব্যয়বহুল কাজ হবে, যার জন্য শত শত মানব-বছর ব্যয় হবে।

এই সহজ পদ্ধতিতে, আমরা আমাদের অভ্যন্তরীণ মেঘের সাথে শেষ করেছি, যা আমরা এমন একটি লক্ষ্য নির্ধারণ করলেও আগামী 5 বছরে পরিত্যাগ করতে পারব না।

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

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

• অন্যদের সম্পর্কে কি? যেহেতু আমরা এই নিবন্ধে সাধারণভাবে বড় প্রযুক্তি নিয়ে আলোচনা করছি, তাই আমাদের কেসটি অনন্য নয় তা লক্ষণীয়। চেক আউট বা উদাহরণের জন্য কেস।

গল্প #2: মনোরপোজিটরি

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

• সংস্করণ নিয়ন্ত্রণ ব্যবস্থা (আর্ক),
• ইন্টারফেস (আর্কানাম),
• সিস্টেম তৈরি করুন (আপনি তৈরি করুন),
• CI/CD (NewCI)।

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

একটি ইউনিফাইড বিল্ড সিস্টেম বাস্তবায়ন। আমাদের মালিকানাধীন ইয়া মেক বিল্ড সিস্টেমটি 2013 সালে আত্মপ্রকাশ করেছিল, যখন এটি শুধুমাত্র C++ কোডের জন্য ছিল। আপনি তৈরি করার আগে, আমরা CMake ব্যবহার করতাম, কিন্তু এর গতি এটিকে একটি মনোরপোজিটরির স্কেলে স্কেল করা থেকে বাধা দেয়। মালিকানাধীন ya make Arcadia-এর সাথে আরও দ্রুত কাজ করেছে৷ আমাদের সমস্যার সমাধান করতে পারে এমন অন্য কোনও ওপেন সোর্স বিকল্প ছিল না: উদাহরণস্বরূপ, Bazel অনেক পরে, 2015 সালে মুক্তি পেয়েছিল৷

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

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

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

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

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

স্কেলের পরিপ্রেক্ষিতে, ট্রাঙ্কে বর্তমানে 10 মিলিয়ন ফাইল রয়েছে, সামগ্রিকভাবে সংগ্রহস্থলটি 2 টিআইবি ছাড়িয়েছে এবং প্রতি সপ্তাহে 30 হাজারের বেশি কমিট করা হয়।

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

• অন্যদের সম্পর্কে কি? আবার, আপনি যদি সাধারণভাবে বড় প্রযুক্তির দিকে তাকান, তবে উদাহরণ হিসাবে আপনার মনোযোগ দেওয়া উচিত এবং .

এই গল্পে কি মিল আছে

তাহলে কেন বড় প্রযুক্তি সংস্থাগুলিকে তাদের নিজস্ব সমাধানগুলি আবিষ্কার করতে হবে এবং কেন তাদের একটি সাধারণভাবে গৃহীত মান মেনে চলে এমনগুলির সাথে প্রতিস্থাপিত করা যাবে না?

1. উদ্ভাবন। বড় কর্পোরেশনগুলিকে প্রায়শই এমন সমস্যার সমাধান করতে হয় যা ভবিষ্যতে সাধারণ হয়ে উঠবে। এইভাবে বাজারের মান হওয়ার সম্ভাবনা সহ উদ্ভাবনী সমাধানগুলি আবির্ভূত হতে পারে।

   
   

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

   
   

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

   
   

2. স্কেল. এই পয়েন্টটি কিছু উপায়ে আগেরটির মতোই, কারণ প্রতিটি কোম্পানি স্কেলেবিলিটি সমস্যার মুখোমুখি হয় না। একটা সময় ছিল যখন 640 kbytes সবার জন্য যথেষ্ট ছিল, তাই না?

   
   

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

   
   

   পাবলিক টুলগুলিতে স্কেলিং সমস্যা অব্যাহত রয়েছে (সর্বশেষে, এটি একটি অপেক্ষাকৃত বিরল দৃশ্য, এবং এতে বিনিয়োগ করা প্রায়শই অলাভজনক)।

   
   

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

   
   

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

   
   

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

   
   

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

   
   

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

   
   

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

   
   

   একই সময়ে, ইস্যুটির আইনি দিকটি ওপেন সোর্সকে প্রভাবিত করে: উদাহরণস্বরূপ, গোলাঙ্গে কমিট বা k8s একটি CLA স্বাক্ষরের প্রয়োজন হয়। এই একটি সমস্যা হতে থাকবে?

   
   

6. NIH. হ্যাঁ, উদ্দেশ্যমূলক কারণ ছাড়াও, এটা সম্ভব যে নেওয়া সিদ্ধান্তগুলি বাস্তবসম্মত নয়। এটি তার সেরা এনআইএইচ সিন্ড্রোম।

   
   

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

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