Бүгдээрээ сайн уу, намайг Александр гэдэг, би CIAN-д инженерээр ажилладаг бөгөөд системийн удирдлага, дэд бүтцийн үйл явцыг автоматжуулах ажилд оролцдог. Өмнөх нийтлэлүүдийн нэгний тайлбар дээр бид өдөрт 4 TB лог хаанаас авдаг, тэдэнтэй юу хийдэг талаар хэлэхийг хүссэн. Тийм ээ, бидэнд маш олон лог байдаг бөгөөд тэдгээрийг боловсруулахын тулд тусдаа дэд бүтцийн кластер бий болсон нь асуудлыг хурдан шийдвэрлэх боломжийг олгодог. Энэ нийтлэлд би үүнийг нэг жилийн хугацаанд байнга өсөн нэмэгдэж буй мэдээллийн урсгалтай ажиллахын тулд хэрхэн тохируулсан тухай ярих болно.
Бид хаанаас эхэлсэн бэ?
Сүүлийн хэдэн жилийн хугацаанд cian.ru сайтын ачаалал маш хурдан өсч, 2018 оны 11.2-р улирал гэхэд нөөцийн урсгал сар бүр 40 сая өвөрмөц хэрэглэгчдэд хүрчээ. Тухайн үед бид эгзэгтэй мөчид гуалингийн XNUMX хүртэлх хувийг алддаг байсан тул зөрчилдөөнийг хурдан шийдэж чадахгүй, шийдвэрлэхэд маш их цаг хугацаа, хүчин чармайлт гаргасан. Мөн бид асуудлын шалтгааныг олж чадаагүй, хэсэг хугацааны дараа дахин давтагддаг. Энэ бол там байсан бөгөөд энэ талаар ямар нэг зүйл хийх хэрэгтэй байв.
Тэр үед бид бүртгэлийг хадгалахын тулд стандарт индекс тохиргоотой ElasticSearch 10 хувилбар бүхий 5.5.2 өгөгдлийн зангилаа бүхий кластер ашигласан. Энэ нь нэг жил гаруйн өмнө алдартай бөгөөд боломжийн шийдэл болгон танилцуулагдсан: дараа нь логоны урсгал тийм ч том биш байсан тул стандарт бус тохиргоог хийх нь утгагүй байв.
Ирж буй логуудын боловсруулалтыг Logstash өөр өөр портууд дээр ElasticSearch-ийн таван зохицуулагчаар хангасан. Нэг индекс нь хэмжээнээс үл хамааран таван хэлтэрхийгээс бүрддэг. Цагийн болон өдөр тутмын эргэлтийг зохион байгуулсны үр дүнд кластерт цаг тутамд 100 орчим шинэ хэлтэрхий гарч ирэв. Маш олон лог байхгүй байсан ч кластер сайн ажиллаж, түүний тохиргоонд хэн ч анхаарал хандуулаагүй.
Хурдан өсөлтийн сорилтууд
Хоёр процесс нь хоорондоо давхцсан тул үүсгэсэн логуудын хэмжээ маш хурдан өссөн. Нэг талаас энэ үйлчилгээг хэрэглэгчдийн тоо өссөн. Нөгөөтэйгүүр, бид C# болон Python хэл дээрх хуучин монолитуудаа хөрөөдөж, бичил үйлчилгээний архитектур руу идэвхтэй шилжиж эхэлсэн. Цулын хэсгүүдийг сольсон хэдэн арван шинэ бичил үйлчилгээ нь дэд бүтцийн кластерт илүү их бүртгэлийг үүсгэсэн.
Энэ нь биднийг кластерыг удирдах боломжгүй болсон цэг рүү хөтөлсөн юм. Бүртгэлүүд секундэд 20 мянган мэдээ ирж эхлэх үед байнга ашиггүй эргүүлэх нь хэлтэрхийний тоог 6 мянга хүртэл нэмэгдүүлж, нэг зангилаа 600 гаруй хэлтэрхий байсан.
Энэ нь RAM-ийн хуваарилалтад асуудал үүсгэж, зангилаа эвдэрсэн үед бүх хэлтэрхийнүүд нэгэн зэрэг хөдөлж, урсгалыг үржүүлж, бусад зангилааг ачаалж эхэлсэн нь кластерт өгөгдөл бичих бараг боломжгүй болсон. Тэгээд энэ хугацаанд бид модгүй хоцорсон. Хэрэв серверт асуудал гарсан бол бид үндсэндээ кластерын 1/10-ийг алдсан. Олон тооны жижиг индексүүд нь нарийн төвөгтэй байдлыг нэмсэн.
Бүртгэлгүйгээр бид ослын шалтгааныг ойлгоогүй бөгөөд эрт орой хэзээ нэгэн цагт дахин нэг тармуур дээр гишгэх боломжтой байсан бөгөөд манай багийн үзэл суртлын хувьд энэ нь хүлээн зөвшөөрөгдөхгүй байсан, учир нь бидний бүх ажлын механизм яг эсрэгээр хийгдсэн байдаг - хэзээ ч бүү давт. ижил асуудлууд. Үүнийг хийхийн тулд жижүүрийн инженерүүдийн баг зөвхөн хэмжүүрээс гадна бүртгэлээс дохиололыг хянадаг байсан тул бид бүртгэлийн бүрэн хэмжээгээр, тэдгээрийг бараг бодит цаг хугацаанд хүргэх шаардлагатай байсан. Асуудлын цар хүрээг ойлгохын тулд тухайн үед бүртгэлийн нийт хэмжээ өдөрт 2 TB орчим байсан.
Бид бүртгэлийн алдагдлыг бүрэн арилгах, давагдашгүй хүчин зүйлийн үед ELK кластерт хүргэх хугацааг хамгийн ихдээ 15 минут болгон багасгах зорилт тавьсан (бид хожим энэ үзүүлэлтийг дотоод KPI болгон ашигласан).
Шинэ эргэлтийн механизм ба халуун дулаан зангилаа
Бид ElasticSearch хувилбарыг 5.5.2-оос 6.4.3 болгон шинэчилснээр кластер хөрвүүлэлтийг эхлүүлсэн. Дахин нэг удаа бидний 5-р хувилбарын кластер үхсэн бөгөөд бид үүнийг унтрааж, бүрэн шинэчлэхээр шийдсэн - одоо ч бүртгэл байхгүй байна. Тиймээс бид энэ шилжилтийг хэдхэн цагийн дотор хийсэн.
Энэ үе шатанд хийсэн хамгийн том өөрчлөлт бол Apache Kafka-г гурван зангилаа дээр зохицуулагчаар завсрын буфер болгон хэрэгжүүлсэн явдал юм. Мессеж брокер нь ElasticSearch-тэй холбоотой асуудлуудын үед бүртгэлээ алдахаас биднийг аварсан. Үүний зэрэгцээ бид кластерт 2 зангилаа нэмж, мэдээллийн төвд өөр өөр тавиур дээр байрлах гурван "халуун" зангилаа бүхий халуун дулаан архитектурт шилжсэн. Бид ямар ч нөхцөлд алдагдах ёсгүй маск - nginx, мөн програмын алдааны бүртгэлийг ашиглан тэдгээрт бүртгэлийг дахин чиглүүлэв. Үлдсэн зангилаа руу жижиг бүртгэлүүдийг илгээсэн - дибаг хийх, анхааруулах гэх мэт, 24 цагийн дараа "халуун" зангилааны "чухал" бүртгэлийг шилжүүлсэн.
Жижиг индексүүдийн тоог нэмэгдүүлэхгүйн тулд бид цагийн эргэлтээс эргүүлэх механизм руу шилжсэн. Форумд индексийн хэмжээгээр эргүүлэх нь маш найдваргүй гэсэн мэдээлэл маш их байсан тул бид индекс дэх баримт бичгийн тоогоор эргүүлэх аргыг ашиглахаар шийдсэн. Бид индекс бүрт дүн шинжилгээ хийж, дараа нь сэлгэн ажиллах ёстой баримт бичгийн тоог бүртгэсэн. Тиймээс бид 50 ГБ-аас ихгүй хэмжээтэй хэлтэрхийний оновчтой хэмжээнд хүрсэн.
Кластерын оновчлол
Гэсэн хэдий ч бид асуудлаас бүрэн ангижирч чадаагүй байна. Харамсалтай нь жижиг индексүүд гарч ирсэн хэвээр байна: тэдгээр нь заасан хэмжээнд хүрээгүй, эргэлдүүлээгүй бөгөөд бид огноогоор эргэлтийг хассан тул гурван хоногоос дээш настай индексүүдийг дэлхийн хэмжээнд цэвэрлэх замаар устгасан. Энэ нь кластерын индекс бүрмөсөн алга болж, байхгүй индекс рүү бичих оролдлого нь бидний удирдлагад ашигладаг кураторын логикийг эвдсэний улмаас өгөгдөл алдагдахад хүргэсэн. Бичгийн алиа нэрийг индекс болгон хувиргаж, эргүүлэх логикийг эвдэж, зарим индексийн хяналтгүй өсөлтийг 600 ГБ хүртэл үүсгэсэн.
Жишээлбэл, эргэлтийн тохиргооны хувьд:
с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-ийн татах логик руу шилжсэн. Бид үүнийг docker-compose-ээр ажиллуулдаг docker-д байрлуулсан бөгөөд мөн тэнд logstash-exporter-ийг байрлуулсан бөгөөд энэ нь лог урсгалыг хянах зорилгоор Prometheus руу хэмжигдэхүүнийг илгээдэг. Ингэснээр бид бүртгэлийн төрөл бүрийг боловсруулах үүрэгтэй logstash тохиолдлын тоог жигд өөрчлөх боломжийг бидэнд олгосон.
Бид кластерыг сайжруулж байх хооронд cian.ru-ийн траффик сар бүр 12,8 сая өвөрмөц хэрэглэгч болж өссөн. Үүний үр дүнд бидний өөрчлөлтүүд үйлдвэрлэлийн өөрчлөлтөөс бага зэрэг хоцорч, "дулаан" зангилаанууд ачааллыг даван туулж, гуалин нийлүүлэлтийг бүхэлд нь удаашруулсан гэсэн асуудалтай тулгарсан. Бид "халуун" өгөгдлийг ямар ч алдаагүйгээр хүлээн авсан боловч индексийг жигд хуваарилахын тулд үлдсэнийг нь хүргэхэд хөндлөнгөөс оролцож, гараар эргүүлэх шаардлагатай болсон.
Үүний зэрэгцээ, кластер дахь logstash тохиолдлуудын тохиргоог масштаблах, өөрчлөх нь энэ нь локал docker-compose байсан тул бүх үйлдлүүдийг гараар гүйцэтгэдэг (шинэ төгсгөл нэмэхийн тулд бүх үйлдлийг гараар хийх шаардлагатай байсан) төвөгтэй байсан. серверүүд болон docker-compose up -d хаа сайгүй).
Лог дахин хуваарилалт
Энэ оны есдүгээр сард бид цул чулууг огтолж, кластерын ачаалал нэмэгдэж, гуалинуудын урсгал секундэд 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.
Энэ давталтаар бид урд талын nginx бүртгэлтэй ижил зай эзэлдэг микро үйлчилгээний хандалтын бүртгэлтэй индексийг гурван "халуун" зангилааны хоёрдугаар бүлэгт шилжүүлсэн. Одоо бид "халуун" зангилаанууд дээр өгөгдлийг 20 цагийн турш хадгалж, дараа нь тэдгээрийг "дулаан" зангилаа руу бусад бүртгэл рүү шилжүүлдэг.
Бид эргэлтийг нь дахин тохируулах замаар жижиг индексүүд алга болох асуудлыг шийдсэн. Одоо индексүүд бага зэрэг өгөгдөлтэй байсан ч ямар ч тохиолдолд 23 цаг тутамд эргэлддэг. Энэ нь хэлтэрхийнүүдийн тоог бага зэрэг нэмэгдүүлсэн (тэдгээрийн 800 орчим нь байсан), гэхдээ кластерийн гүйцэтгэлийн үүднээс авч үзвэл үүнийг тэсвэрлэх боломжтой.
Үүний үр дүнд кластерт зургаан "халуун", дөрөвхөн "дулаан" зангилаа байсан. Энэ нь урт хугацааны интервалаар хүсэлт гаргахад бага зэрэг саатал үүсгэдэг боловч ирээдүйд зангилааны тоог нэмэгдүүлэх нь энэ асуудлыг шийдэх болно.
Энэ давталт нь хагас автомат масштабын дутагдалтай холбоотой асуудлыг зассан. Үүнийг хийхийн тулд бид үйлдвэрлэлд нэвтрүүлсэнтэй адил дэд бүтцийн Nomad кластерыг байршуулсан. Одоогийн байдлаар Logstash-ийн хэмжээ нь ачааллаас хамааран автоматаар өөрчлөгддөггүй, гэхдээ бид үүнд хүрэх болно.
РџР »Р ° РЅС <РЅР ° Р ± САРРґЭсарС ‰ РμРμ
Хэрэгжүүлсэн тохиргоо нь төгс хэмжигддэг бөгөөд одоо бид 13,3 TB өгөгдлийг - бүх бүртгэлийг 4 өдрийн турш хадгалдаг бөгөөд энэ нь сэрэмжлүүлгийн яаралтай шинжилгээ хийхэд шаардлагатай байдаг. Бид зарим логуудыг хэмжигдэхүүн болгон хувиргадаг бөгөөд үүнийгээ Графит дээр нэмдэг. Инженерүүдийн ажлыг хөнгөвчлөхийн тулд бид дэд бүтцийн кластерын хэмжүүр, нийтлэг асуудлыг хагас автоматаар засах скриптүүдтэй. Ирэх онд хийхээр төлөвлөж буй өгөгдлийн зангилааны тоог нэмэгдүүлсний дараа бид 4-ээс 7 хоног хүртэл өгөгдөл хадгалах горимд шилжих болно. Энэ нь үйл ажиллагааны ажилд хангалттай байх болно, учир нь бид тохиолдлыг аль болох хурдан шалгахыг хичээдэг бөгөөд урт хугацааны судалгаанд телеметрийн өгөгдөл байдаг.
2019 оны 15,3-р сард cian.ru сайтын хандалт хэдийнэ өсч, сард XNUMX сая өвөрмөц хэрэглэгч болжээ. Энэ нь гуалин хүргэх архитектурын шийдлийн ноцтой сорилт болсон юм.
Одоо бид ElasticSearch-ийг 7-р хувилбар руу шинэчлэхээр бэлтгэж байна. Гэхдээ үүний тулд бид ElasticSearch дээрх олон индексийн зураглалыг шинэчлэх шаардлагатай болно, учир нь тэдгээр нь 5.5 хувилбараас шилжсэн бөгөөд 6-р хувилбарт хуучирсан гэж зарласан (энэ нь хувилбарт байхгүй. 7). Энэ нь шинэчлэлтийн явцад ямар нэгэн давагдашгүй хүчин зүйл тохиолдох нь гарцаагүй бөгөөд энэ нь асуудал шийдэгдэх үед биднийг бүртгэлгүй үлдээх болно гэсэн үг юм. 7-р хувилбараас бид сайжруулсан интерфейс, шинэ шүүлтүүр бүхий Кибана-г тэсэн ядан хүлээж байна.
Бид үндсэн зорилгодоо хүрсэн: бид логоо алдахаа больж, дэд бүтцийн кластерын сул зогсолтыг долоо хоногт 2-3 удаа гацдаг байсныг сард хэдэн цаг засварын ажил болгон бууруулсан. Үйлдвэрлэлийн энэ бүх ажил бараг харагдахгүй байна. Гэсэн хэдий ч одоо бид үйлчилгээтэйгээ яг юу болж байгааг тодорхойлж чадна, бид үүнийг чимээгүй горимд хурдан хийж, бүртгэлүүд алдагдах болно гэж санаа зовох хэрэггүй. Ерөнхийдөө бид сэтгэл хангалуун, аз жаргалтай, дараа нь ярих шинэ мөлжлөгт бэлдэж байна.
Эх сурвалж: www.habr.com