এখনও "আওয়ার সিক্রেট ইউনিভার্স: দ্য হিডেন লাইফ অফ দ্য সেল" ফিল্ম থেকে

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

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

উপরন্তু, রাশিয়ান এবং বিদেশী উভয় নিয়ন্ত্রকদের চাহিদা বাড়ছে।

বর্তমান চাহিদা মেটাতে এবং ভবিষ্যৎ আপগ্রেডের ভিত্তি স্থাপন করতে, আমরা Tarantool-এর উপর ভিত্তি করে একটি বিনিয়োগ বিজনেস কোর তৈরি করেছি।

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

প্রাগঐতিহাসিক

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

উপরন্তু, সিস্টেমের কোড বেস ইতিমধ্যে বেশ পুরানো, কারণ কিছু পণ্য 1990-এর দশকের মাঝামাঝি সময়ে উদ্ভূত হয়েছিল। এবং কিছু এলাকায় এটি উন্নয়ন প্রক্রিয়াকে ধীর করে দেয় এবং কর্মক্ষমতার সমস্যা ছিল।

একটি নতুন সমাধান জন্য প্রয়োজনীয়তা

ব্যবসাগুলি বুঝতে পেরেছে যে প্রযুক্তিগত রূপান্তর আরও উন্নয়নের জন্য গুরুত্বপূর্ণ। আমাদের কাজ দেওয়া হয়েছিল:

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

উপরন্তু, আমাদের স্থপতিরা তাদের নিজস্ব শর্ত সেট করেছেন:

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

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

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

আমি আপনাকে বলব না কিভাবে আমরা সবকিছু পরীক্ষা করেছি এবং কতক্ষণ সময় লেগেছে, আমি শুধু সংক্ষিপ্ত করব: Mail.ru গ্রুপ ডেভেলপমেন্ট টিমের Tarantool-এর উপর ভিত্তি করে একটি প্রোটোটাইপ সমাধান দ্বারা লোড পরীক্ষায় সেরা পারফরম্যান্স দেখানো হয়েছে। আমরা একটি চুক্তি স্বাক্ষর করেছি এবং উন্নয়ন শুরু করেছি। Mail.ru গ্রুপ থেকে চারজন লোক ছিল, এবং Alfa-Bank থেকে তিনজন ডেভেলপার, তিনজন সিস্টেম বিশ্লেষক, একজন সমাধান আর্কিটেক্ট, একজন পণ্যের মালিক এবং একজন স্ক্রাম মাস্টার ছিলেন।

পরবর্তীতে আমি আপনাকে আমাদের সিস্টেম কীভাবে বেড়েছে, কীভাবে এটি বিবর্তিত হয়েছে, আমরা কী করেছি এবং কেন এটি ঠিক সে সম্পর্কে বলব।

নকশা

প্রথম প্রশ্ন আমরা নিজেদেরকে জিজ্ঞাসা করেছি কিভাবে আমাদের বর্তমান সিস্টেম থেকে ডেটা পেতে হয়। আমরা সিদ্ধান্ত নিয়েছি যে HTTP আমাদের জন্য বেশ উপযুক্ত, কারণ সমস্ত বর্তমান সিস্টেমগুলি HTTP-তে XML বা JSON পাঠিয়ে একে অপরের সাথে যোগাযোগ করে।

আমরা Tarantool-এ নির্মিত HTTP সার্ভার ব্যবহার করি কারণ আমাদের SSL সেশন বন্ধ করার দরকার নেই, এবং এর কার্যক্ষমতা আমাদের জন্য যথেষ্ট।

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

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

যাচাই করার পরে, ডেটা সংরক্ষণ করতে হবে। আমরা এটি vshard ব্যবহার করে করি (আমাদের কাছে শার্ডের ভূ-বিচ্ছুরিত প্রতিরূপ রয়েছে)।

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

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

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

একটি প্রমাণীকরণ সিস্টেম বাস্তবায়িত.

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

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

অর্থাৎ, ভূমিকা ব্যবহার করে, আমরা একে অপরের থেকে ক্লাস্টারের বিভিন্ন অংশকে ডিকপল করেছি, যা একে অপরের থেকে স্বাধীনভাবে স্কেল করা যেতে পারে।

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

পরীক্ষামূলক

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

আমরা কিভাবে পরীক্ষা চালিত উন্নয়ন ব্যবহার করব?

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

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

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

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

আমরা খুব দু: খিত ছিল. আমরা সার্ভার লোড তাকান, কিন্তু দেখা যাচ্ছে তারা নিষ্ক্রিয়।

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

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

এই ক্ষেত্রে, মেমরি শুধুমাত্র আগত সংযোগ এবং অস্থায়ী বস্তু প্রক্রিয়াকরণের জন্য ব্যবহার করা হয়েছিল।

বিপরীতে, স্টোরেজ সার্ভারে, প্রসেসরের লোড বেড়েছে, কিন্তু সংযোগ প্রক্রিয়াকারী সার্ভারের তুলনায় অনেক ধীর।

এবং মেমরি খরচ লোড করা ডেটার পরিমাণের সরাসরি অনুপাতে বেড়েছে।

সার্ভিস

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

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

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

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

পুরানো সিস্টেম

আমাদের সমস্ত লিগ্যাসি সিস্টেম HTTP এর মাধ্যমে আমাদের কল করতে এবং GraphQL ব্যবহার করতে পারে না, যদিও তারা প্রোটোকল সমর্থন করে। অতএব, আমরা একটি প্রক্রিয়া তৈরি করেছি যা এই সিস্টেমগুলিতে ডেটা প্রতিলিপি করার অনুমতি দেয়।

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

নতুন উন্নতি

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

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

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

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

আমরা আরও বুঝি যে শীঘ্র বা পরে এমন একটি পরিস্থিতি আসবে যখন মেমরিতে ডেটা সংরক্ষণ করার জন্য পর্যাপ্ত জায়গা থাকবে না, তবে তবুও ডেটা সংরক্ষণ করতে হবে। এই উদ্দেশ্যে, আমরা শীঘ্রই ডিস্ক স্টোরেজ তৈরি করব।

উপসংহার

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

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

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

উন্নয়নের সব পর্যায়ে লোড পরীক্ষা পরিচালনা করা অত্যন্ত গুরুত্বপূর্ণ। যত তাড়াতাড়ি আপনি আর্কিটেকচারে কিছু ত্রুটি লক্ষ্য করবেন, এটি ঠিক করা তত সহজ হবে, যা ভবিষ্যতে আপনার অনেক সময় বাঁচাবে।

লুয়ার কিছু ভুল নেই। যে কেউ এতে লিখতে শিখতে পারে: জাভা ডেভেলপার, জাভাস্ক্রিপ্ট ডেভেলপার, পাইথন ডেভেলপার, ফ্রন্ট-এন্ড বা ব্যাক-এন্ড। এমনকি আমাদের বিশ্লেষকরাও এটা নিয়ে লেখেন।

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

আপনি যদি বুঝতে পারেন যে আপনাকে স্কেল করতে হবে, তাহলে আপনার সমাধানটি Tarantool-এ এমনভাবে ডিজাইন করুন যাতে এটি কয়েক ডজন ট্যারান্টুল উদাহরণে সমান্তরালভাবে চলতে পারে। আপনি যদি এটি না করেন তবে এটি পরে কঠিন এবং বেদনাদায়ক হবে, যেহেতু Tarantool কার্যকরভাবে শুধুমাত্র একটি প্রসেসর কোর ব্যবহার করতে পারে।

উত্স: www.habr.com

ট্যারান্টুলের উপর ভিত্তি করে আমরা আলফা-ব্যাঙ্কের বিনিয়োগ ব্যবসার মূল অংশকে কীভাবে তৈরি করেছি