"Bitrix24": "দ্রুত উত্থিত হওয়াকে পতিত বলে মনে করা হয় না"

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

“SaaS আকারে, আমরা 24 বছর আগে Bitrix7 চালু করেছি। প্রধান অসুবিধা, সম্ভবত, নিম্নলিখিত ছিল: SaaS আকারে সর্বজনীন লঞ্চের আগে, এই পণ্যটি কেবল একটি বাক্সযুক্ত সমাধানের বিন্যাসে বিদ্যমান ছিল। ক্লায়েন্টরা এটি আমাদের কাছ থেকে কিনেছে, এটি তাদের সার্ভারে হোস্ট করেছে, একটি কর্পোরেট পোর্টাল শুরু করেছে - কর্মচারী যোগাযোগ, ফাইল স্টোরেজ, টাস্ক ম্যানেজমেন্ট, CRM এর জন্য একটি সাধারণ সমাধান। এবং আমরা 2012 সালের মধ্যে সিদ্ধান্ত নিয়েছিলাম যে আমরা এটিকে SaaS হিসাবে চালু করতে চাই, এটি নিজেরাই পরিচালনা করে, ত্রুটি সহনশীলতা এবং নির্ভরযোগ্যতা প্রদান করে। আমরা প্রক্রিয়াটিতে অভিজ্ঞতা অর্জন করেছি, কারণ ততক্ষণ পর্যন্ত আমাদের কাছে এটি ছিল না - আমরা কেবল সফ্টওয়্যার প্রস্তুতকারক ছিলাম, পরিষেবা প্রদানকারী নয়।

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

SaaS হিসাবে Bitrix.24

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

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

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

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

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

তারা যা চেয়েছিল, তারা পেয়েছে...

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

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

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

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

আমরা কি সবকিছু সংরক্ষণ করেছি?

আমাদের মার্কিন যুক্তরাষ্ট্র থেকে প্রচুর গ্রাহক রয়েছে, ইউরোপ থেকে প্রচুর গ্রাহক রয়েছে, প্রচুর গ্রাহক যারা পূর্বের কাছাকাছি - জাপান, সিঙ্গাপুর এবং আরও অনেক কিছু। অবশ্যই, রাশিয়ায় গ্রাহকদের একটি বিশাল অনুপাত। অর্থাৎ কাজ এক অঞ্চল থেকে অনেক দূরে। ব্যবহারকারীরা একটি দ্রুত প্রতিক্রিয়া চান, বিভিন্ন স্থানীয় আইন মেনে চলার প্রয়োজনীয়তা রয়েছে এবং প্রতিটি অঞ্চলের মধ্যে আমরা দুটি ডেটা সেন্টার সংরক্ষণ করি, এছাড়াও কিছু অতিরিক্ত পরিষেবা রয়েছে যেগুলি আবার, এই অঞ্চলে থাকা গ্রাহকদের জন্য সুবিধাজনকভাবে একটি অঞ্চলের মধ্যে স্থাপন করা হয়। কাজ করছে. REST হ্যান্ডলার, অনুমোদন সার্ভার, তারা সাধারণভাবে ক্লায়েন্টের কাজের জন্য কম সমালোচনামূলক, আপনি একটি ছোট গ্রহণযোগ্য বিলম্বের সাথে তাদের পরিবর্তন করতে পারেন, কিন্তু আপনি চাকাটি পুনরায় উদ্ভাবন করতে চান না, কীভাবে তাদের নিরীক্ষণ করবেন এবং তাদের সাথে কী করবেন। অতএব, আমরা বিদ্যমান সমাধানগুলি সর্বাধিক ব্যবহার করার চেষ্টা করি, এবং অতিরিক্ত পণ্যগুলিতে কিছু ধরণের দক্ষতা বিকাশ করি না। এবং কোথাও আমরা ট্রিটলি ডিএনএস স্তরে সুইচিং ব্যবহার করি এবং পরিষেবাটির প্রাণবন্ততা একই ডিএনএস দ্বারা নির্ধারিত হয়। আমাজনের একটি রুট 53 পরিষেবা রয়েছে, তবে এটি কেবল ডিএনএস নয়, যেখানে আপনি রেকর্ড করতে পারেন এবং এটিই - এটি অনেক বেশি নমনীয় এবং সুবিধাজনক। এটির মাধ্যমে, আপনি জিওলোকেশন সহ জিও-ডিস্ট্রিবিউটেড পরিষেবাগুলি তৈরি করতে পারেন, যখন আপনি এটি ব্যবহার করেন ক্লায়েন্ট কোথা থেকে এসেছেন তা নির্ধারণ করতে এবং তাকে নির্দিষ্ট রেকর্ডগুলি দিতে - আপনি এটিকে ব্যর্থ আর্কিটেকচার তৈরি করতে ব্যবহার করতে পারেন। একই স্বাস্থ্য-পরীক্ষাগুলি রুট 53-এ নিজেই কনফিগার করা হয়েছে, আপনি নিরীক্ষণ করা শেষ পয়েন্ট সেট করুন, মেট্রিক্স সেট করুন, পরিষেবাটির "জীবন্ত" নির্ধারণ করতে কোন প্রোটোকল সেট করুন - tcp, http, https; চেকের ফ্রিকোয়েন্সি সেট করুন যা নির্ধারণ করে যে পরিষেবাটি জীবিত আছে কি না। এবং dns নিজেই, আপনি নির্ধারণ করেন কোনটি প্রাথমিক হবে, কোনটি সেকেন্ডারি হবে, যদি স্বাস্থ্য-পরীক্ষা রুট 53-এর মধ্যে কাজ করে তাহলে কোথায় পরিবর্তন করতে হবে। এই সমস্ত কিছু অন্যান্য সরঞ্জাম দিয়ে করা যেতে পারে, তবে আরও সুবিধাজনক যা আমরা এটি সেট আপ করি। একবার এবং তারপরে আমরা কীভাবে চেক করি, কীভাবে আমরা সুইচ করি: সবকিছু নিজেই কাজ করে।

প্রথম "কিন্তু": কিভাবে এবং কিভাবে রুট 53 নিজেই রিজার্ভ? আপনি জানেন না, হঠাৎ তার কিছু হয়? সৌভাগ্যবশত, আমরা কখনই এই রেকে পা রাখিনি, কিন্তু আবারও, আমার সামনে একটি গল্প থাকবে কেন আমরা ভেবেছিলাম যে আমাদের এখনও রিজার্ভ করা দরকার। এখানে আমরা নিজেদের জন্য আগে থেকেই খড় তৈরি করি। দিনে বেশ কয়েকবার, আমরা 53 রুটে থাকা সমস্ত জোন সম্পূর্ণ আনলোড করি। Amazon এর API আপনাকে সহজেই JSON-এ সেগুলি পাঠাতে দেয় এবং আমাদের কাছে বেশ কয়েকটি ব্যাকআপ সার্ভার রয়েছে যেখানে আমরা এটি রূপান্তর করি, এটি কনফিগার আকারে আপলোড করি এবং মোটামুটিভাবে বলতে গেলে, একটি ব্যাকআপ কনফিগারেশন রয়েছে৷ এই ক্ষেত্রে আমরা ডিএনএস সেটিংস ডেটা না হারিয়ে দ্রুত এটিকে ম্যানুয়ালি স্থাপন করতে পারি।

দ্বিতীয় "কিন্তু": এই ছবিতে এখনও কী সংরক্ষিত হয়নি? ব্যালান্সার ! অঞ্চল অনুসারে আমাদের গ্রাহকদের বিতরণ খুব সহজ। আমাদের bitrix24.ru, bitrix24.com, .de ডোমেইন আছে - এখন 13টি আলাদা আলাদা আছে, যেগুলো বিভিন্ন অঞ্চলে কাজ করে। আমরা নিম্নলিখিতটিতে এসেছি: প্রতিটি অঞ্চলের নিজস্ব ব্যালেন্সার রয়েছে। সুতরাং নেটওয়ার্কের সর্বোচ্চ লোড কোথায় তার উপর নির্ভর করে অঞ্চল অনুসারে বিতরণ করা আরও সুবিধাজনক। যদি এটি কোনও একটি ব্যালেন্সারের স্তরে ব্যর্থ হয়, তবে এটি কেবল ডিকমিশন করা হয় এবং ডিএনএস থেকে সরানো হয়। যদি ব্যালেন্সারের একটি গ্রুপের সাথে কিছু সমস্যা হয়, তবে সেগুলি অন্যান্য সাইটে সংরক্ষিত থাকে এবং তাদের মধ্যে স্যুইচিং একই রুট53 ব্যবহার করে করা হয়, কারণ একটি ছোট ttl এর কারণে, সর্বাধিক 2, 3, 5 মিনিটের মধ্যে স্যুইচিং ঘটে।

তৃতীয় "কিন্তু": কি এখনো সংরক্ষিত হয়নি? S3 সঠিক। আমরা, s3 তে ব্যবহারকারীদের কাছে যে ফাইলগুলি সঞ্চয় করি তা স্থাপন করে, আন্তরিকভাবে বিশ্বাস করেছিলাম যে এটি বর্ম-বিদ্ধ ছিল এবং সেখানে কিছু সংরক্ষণ করার প্রয়োজন নেই। কিন্তু ইতিহাস দেখায় যে জিনিসগুলি ভিন্ন। সাধারণভাবে, অ্যামাজন S3 কে একটি মৌলিক পরিষেবা হিসাবে বর্ণনা করে, কারণ অ্যামাজন নিজেই S3 ব্যবহার করে মেশিনের ছবি, কনফিগারেশন, AMI ইমেজ, স্ন্যাপশটগুলি সংরক্ষণ করতে ... এবং যদি s3 পড়ে যায়, যেমনটি এই 7 বছরে একবার হয়েছিল, আমরা কতটা bitrix24 হয়েছি? অপারেটিং, এটি ফ্যান আউট করবে সবকিছুর একটি গুচ্ছ টান - ভার্চুয়াল মেশিনের শুরুর দুর্গমতা, এপিআই-এর ব্যর্থতা ইত্যাদি।

এবং S3 পড়ে যেতে পারে - এটি একবার হয়েছিল। অতএব, আমরা নিম্নলিখিত স্কিমটি নিয়ে এসেছি: কয়েক বছর আগে রাশিয়ায় কোনও গুরুতর বস্তুর পাবলিক রিপোজিটরি ছিল না, এবং আমরা আমাদের নিজস্ব কিছু করার বিকল্প বিবেচনা করেছি ... ভাগ্যক্রমে, আমরা এটি করা শুরু করিনি, কারণ আমরা আমাদের কাছে নেই এমন দক্ষতার মধ্যে খনন করেছি, এবং সম্ভবত তা বিশৃঙ্খল হতে পারে। এখন Mail.ru এর s3-সামঞ্জস্যপূর্ণ স্টোরেজ রয়েছে, ইয়ানডেক্সে এটি রয়েছে এবং অন্যান্য অনেক প্রদানকারীর কাছে এটি রয়েছে। আমরা অবশেষে এই সিদ্ধান্তে পৌঁছেছি যে আমরা প্রথমত, অপ্রয়োজনীয়তা এবং দ্বিতীয়ত, স্থানীয় কপিগুলির সাথে কাজ করার ক্ষমতা রাখতে চাই৷ একটি নির্দিষ্ট রাশিয়ান অঞ্চলের জন্য, আমরা Mail.ru Hotbox পরিষেবা ব্যবহার করি, যেটি API s3 এর সাথে সামঞ্জস্যপূর্ণ। আমাদের অ্যাপ্লিকেশনের ভিতরে কোডে কোন গুরুতর উন্নতির প্রয়োজন ছিল না, এবং আমরা নিম্নলিখিত পদ্ধতি তৈরি করেছি: s3 তে ট্রিগার রয়েছে যা বস্তু তৈরি/মুছে ফেলার জন্য কাজ করে, অ্যামাজনে ল্যাম্বডার মতো একটি পরিষেবা রয়েছে - এটি একটি সার্ভারহীন কোড লঞ্চ যা কার্যকর করা হবে ঠিক যখন নির্দিষ্ট ট্রিগার ট্রিগার হয়।

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

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

ওহ, এবং আপনার অ্যামাজন পালিয়ে গেছে ...

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

যদি কোম্পানিটি বিশ্বব্যাপী হয় এবং রাশিয়া এটির জন্য একটি খুব ছোট অংশ, 3-5% - ভাল, এক উপায় বা অন্য, আপনি তাদের দান করতে পারেন।

যদি এটি একটি সম্পূর্ণরূপে রাশিয়ান কোম্পানি হয় - আমি নিশ্চিত যে এটি স্থানীয়ভাবে হোস্ট করা প্রয়োজন - ভাল, এটি কেবল ব্যবহারকারীদের নিজেদের জন্য সুবিধাজনক হবে, কম ঝুঁকি থাকবে।

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

মার্চ 2018 এর শেষে, Roskomnadzor বৃহত্তম অপারেটরদের কাছে একটি চিঠি পাঠিয়েছে যে তারা ব্লক করার জন্য কয়েক মিলিয়ন Amazon ips ব্লক করার পরিকল্পনা করেছে ... জেলো মেসেঞ্জার। এই অত্যন্ত প্রদানকারীদের ধন্যবাদ - তারা সফলভাবে সবার কাছে চিঠিটি ফাঁস করেছে, এবং একটি বোঝাপড়া ছিল যে অ্যামাজনের সাথে সংযোগ বিচ্ছিন্ন হতে পারে। এটি শুক্রবার ছিল, আমরা আতঙ্কের মধ্যে servers.ru থেকে সহকর্মীদের কাছে ছুটে গিয়েছিলাম, বলেছিলাম: "বন্ধুরা, আমাদের এমন বেশ কয়েকটি সার্ভার দরকার যা রাশিয়ায় হবে না, অ্যামাজনে নয়, উদাহরণস্বরূপ, আমস্টারডামের কোথাও", অন্তত কোনোভাবে আমাদের নিজস্ব vpn এবং প্রক্সি সেখানে কিছু এন্ডপয়েন্টের জন্য রাখতে সক্ষম হওয়ার জন্য যা আমরা কোনোভাবেই প্রভাবিত করতে পারি না, উদাহরণস্বরূপ একই s3-এর এন্ডপন্ট - আপনি একটি নতুন পরিষেবা বাড়ানোর চেষ্টা করতে পারবেন না এবং একটি ভিন্ন পেতে পারেন ip, আমাদের এখনও সেখানে যেতে হবে। কিছু দিনের মধ্যে, আমরা এই সার্ভারগুলি সেট আপ করেছি, সেগুলিকে উত্থাপন করেছি এবং সাধারণভাবে, ব্লক করা শুরু হওয়ার সময় আমরা প্রস্তুত ছিলাম। এটা কৌতূহলী যে RKN, উত্থাপিত হাইপ এবং আতঙ্কের দিকে তাকিয়ে বলেছিল: "না, আমরা এখন কিছু ব্লক করতে যাচ্ছি না।" (তবে এটি ঠিক সেই মুহূর্ত পর্যন্ত যখন তারা টেলিগ্রাম ব্লক করা শুরু করেছিল।) বাইপাস বিকল্পগুলি সেট আপ করার পরে এবং বুঝতে পেরে যে ব্লকিং চালু করা হয়নি, আমরা, তবুও, পুরো জিনিসটি বিশ্লেষণ করতে শুরু করিনি। হ্যাঁ, শুধু ক্ষেত্রে.

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

এবং কিভাবে রিজার্ভ ... একটি সম্পূর্ণ প্রদানকারী?

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

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

অটোমেশন সম্পর্কে কয়েকটি শব্দ

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

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

উপসংহার

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

পরিপূর্ণতাবাদ এবং বাস্তব শক্তি, সময়, অর্থের মধ্যে একটি যুক্তিসঙ্গত সমঝোতা যা আপনি শেষ পর্যন্ত যে পরিকল্পনায় ব্যয় করতে পারেন।

এই পাঠ্যটি সম্মেলনে আলেকজান্ডার ডেমিডভের প্রতিবেদনের একটি সম্পূরক এবং সম্প্রসারিত সংস্করণ আপটাইম দিন 4.

উত্স: www.habr.com