কিভাবে আমরা CIAN এ লগের টেরাবাইট নিয়ন্ত্রণ করেছি

সবাইকে হ্যালো, আমার নাম আলেকজান্ডার, আমি একজন প্রকৌশলী হিসাবে CIAN এ কাজ করি এবং সিস্টেম প্রশাসন এবং অবকাঠামো প্রক্রিয়াগুলির স্বয়ংক্রিয়তার সাথে জড়িত। পূর্ববর্তী নিবন্ধগুলির একটিতে মন্তব্যে, আমাদের জানাতে বলা হয়েছিল যে আমরা প্রতিদিন 4 টিবি লগ কোথায় পাই এবং আমরা সেগুলি দিয়ে কী করি। হ্যাঁ, আমাদের অনেকগুলি লগ রয়েছে এবং সেগুলি প্রক্রিয়া করার জন্য একটি পৃথক অবকাঠামো ক্লাস্টার তৈরি করা হয়েছে, যা আমাদের দ্রুত সমস্যার সমাধান করতে দেয়৷ এই নিবন্ধে আমি কথা বলবো কিভাবে আমরা এক বছরের মধ্যে ডেটার ক্রমবর্ধমান প্রবাহের সাথে কাজ করার জন্য এটিকে অভিযোজিত করেছি।

আমরা কোথা থেকে শুরু করলাম

গত কয়েক বছরে, cian.ru-এর লোড খুব দ্রুত বেড়েছে, এবং 2018 সালের তৃতীয় ত্রৈমাসিকে, রিসোর্স ট্র্যাফিক প্রতি মাসে 11.2 মিলিয়ন অনন্য ব্যবহারকারীদের কাছে পৌঁছেছে। সেই সময়ে, জটিল মুহুর্তে আমরা 40% পর্যন্ত লগ হারিয়েছি, যে কারণে আমরা দ্রুত ঘটনাগুলি মোকাবেলা করতে পারিনি এবং তাদের সমাধান করতে অনেক সময় এবং প্রচেষ্টা ব্যয় করেছি। আমরা প্রায়শই সমস্যার কারণ খুঁজে পাই না, এবং এটি কিছু সময়ের পরে পুনরাবৃত্তি হয়। এটি নরক ছিল এবং এটি সম্পর্কে কিছু করতে হবে।

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

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

দ্রুত বৃদ্ধির চ্যালেঞ্জ

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

এটি স্কেলিং ছিল যা আমাদেরকে এমন বিন্দুতে নিয়ে গিয়েছিল যেখানে ক্লাস্টারটি কার্যত নিয়ন্ত্রণহীন হয়ে পড়েছিল। লগগুলি প্রতি সেকেন্ডে 20 হাজার বার্তার হারে আসতে শুরু করলে, ঘন ঘন অকেজো ঘূর্ণন শার্ডের সংখ্যা 6 হাজারে বাড়িয়ে দেয় এবং প্রতি নোডে 600 টিরও বেশি শার্ড ছিল৷ 

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

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

আমরা লগের ক্ষতি সম্পূর্ণরূপে দূর করার লক্ষ্য স্থির করেছি এবং জোরপূর্বক ঘটনা চলাকালীন ELK ক্লাস্টারে তাদের সরবরাহের সময়কে সর্বোচ্চ 15 মিনিটে কমিয়েছি (আমরা পরে একটি অভ্যন্তরীণ KPI হিসাবে এই চিত্রটির উপর নির্ভর করেছি)।

নতুন ঘূর্ণন প্রক্রিয়া এবং গরম-উষ্ণ নোড

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

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

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

ক্লাস্টার অপ্টিমাইজেশান

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

উদাহরণস্বরূপ, ঘূর্ণন কনফিগারেশনের জন্য:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

কোন রোলওভার উপনাম না থাকলে, একটি ত্রুটি ঘটেছে:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

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

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

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

লগ পুনঃবন্টন

এই বছরের সেপ্টেম্বরে, আমরা এখনও মনোলিথ কাটছিলাম, ক্লাস্টারের লোড বাড়ছে, এবং লগের প্রবাহ প্রতি সেকেন্ডে 30 হাজার বার্তার কাছে পৌঁছেছিল। 

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

• "হট" নোডের জন্য: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 এর জন্য 1 এবং Hot3 এর জন্য 2)।
• "উষ্ণ" নোডের জন্য: E3-1230 v6 / 4Tb SSD / 32 Gb x 4।

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

আমরা তাদের ঘূর্ণন পুনরায় কনফিগার করে ছোট সূচকগুলি অদৃশ্য হওয়ার সমস্যা সমাধান করেছি। এখন সূচীগুলি প্রতি 23 ঘন্টা পরপর ঘোরানো হয়, যদিও সেখানে সামান্য ডেটা থাকে। এটি শার্ডের সংখ্যা কিছুটা বাড়িয়েছে (তাদের মধ্যে প্রায় 800টি ছিল), তবে ক্লাস্টার পারফরম্যান্সের দৃষ্টিকোণ থেকে এটি সহনীয়। 

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

এই পুনরাবৃত্তিটি আধা-স্বয়ংক্রিয় স্কেলিং এর অভাবের সমস্যাও স্থির করেছে। এটি করার জন্য, আমরা একটি পরিকাঠামো নোম্যাড ক্লাস্টার স্থাপন করেছি - যা আমরা ইতিমধ্যে উত্পাদনে স্থাপন করেছি। আপাতত, Logstash এর পরিমাণ স্বয়ংক্রিয়ভাবে লোডের উপর নির্ভর করে পরিবর্তিত হয় না, তবে আমরা এটিতে আসব।

ভবিষ্যতের জন্য পরিকল্পনা

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

অক্টোবর 2019-এ, cian.ru-এ ট্রাফিক ইতিমধ্যে প্রতি মাসে 15,3 মিলিয়ন অনন্য ব্যবহারকারী হয়েছে। এটি লগ প্রদানের জন্য স্থাপত্য সমাধানের একটি গুরুতর পরীক্ষা হয়ে উঠেছে। 

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

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

উত্স: www.habr.com