Зуны улиралд худалдан авалтын идэвхжил, вэб төслийн дэд бүтцийн өөрчлөлтийн эрч хүч хоёулаа уламжлал ёсоор буурдаг гэж ахмад Обвиус бидэнд хэлэв. Зүгээр л МТ-ийн мэргэжилтнүүд хүртэл заримдаа амралтаараа явдаг. Мөн CTO. Албан тушаалдаа үлдсэн хүмүүсийн хувьд энэ нь илүү хэцүү байдаг, гэхдээ энэ нь тийм ч чухал биш юм: магадгүй зун бол одоо байгаа захиалгын схемийн талаар аажмаар бодож, түүнийг сайжруулах төлөвлөгөө гаргахад хамгийн тохиромжтой үе юм. Егор Андреевын туршлагаас , тэр тухай чуулган дээр хэлсэн .
Нөөцлөх сайтуудыг бий болгоход танд тохиолдож болох хэд хэдэн бэрхшээл байдаг. Мөн тэдэнд баригдах нь туйлын боломжгүй юм. Энэ бүх зүйлд биднийг сүйтгэж байгаа зүйл бол бусад олон зүйлийн нэгэн адил төгс төгөлдөр байдал ба ... залхуурал юм. Бид бүх зүйлийг, бүх зүйлийг, бүгдийг төгс хийхийг хичээдэг, гэхдээ бид үүнийг төгс хийх шаардлагагүй! Та зөвхөн тодорхой зүйлийг хийх хэрэгтэй, гэхдээ тэдгээрийг зөв хийж, дуусгахын тулд зөв ажиллах хэрэгтэй.
Failover нь ямар нэгэн хөгжилтэй, хөгжилтэй зүйл биш юм; Энэ бол яг нэг зүйлийг хийх ёстой зүйл юм - сул зогсолтыг багасгахын тулд үйлчилгээ, компани нь бага мөнгө алдах болно. Захиалгын бүх аргуудын хувьд би дараахь нөхцөл байдалд бодохыг санал болгож байна: мөнгө хаана байна?
Эхний хавх: Бид том, найдвартай систем бүтээж, орон тооны цомхотгол хийх үед ослын тоог бууруулдаг. Энэ бол аймшигтай буруу ойлголт юм. Бид орон тооны цомхотголд орсноор ослын тоо нэмэгдэх магадлалтай. Хэрэв бид бүх зүйлийг зөв хийвэл хамтдаа зогсолтыг багасгах болно. Илүү олон осол гарах боловч бага зардлаар гарах болно. Захиалга гэж юу вэ? - энэ бол системийн хүндрэл юм. Аливаа хүндрэл нь муу: бидэнд илүү олон араа, илүү олон араа, нэг үгээр хэлбэл, илүү олон элемент байдаг - тиймээс эвдрэх магадлал өндөр байдаг. Тэгээд тэд үнэхээр эвдэрнэ. Мөн тэд илүү олон удаа эвдрэх болно. Энгийн жишээ: PHP болон MySQL-тэй вэбсайттай гэж бодъё. Мөн яаралтай нөөцлөх шаардлагатай байна.
Shtosh (c) Бид хоёр дахь сайтыг авч, ижил системийг бий болгодог ... Нарийн төвөгтэй байдал нь хоёр дахин их болж байна - бидэнд хоёр субъект бий. Бид мөн нэг сайтаас нөгөө сайт руу өгөгдөл дамжуулах тодорхой логикийг гаргадаг, өөрөөр хэлбэл өгөгдлийг хуулбарлах, статик өгөгдлийг хуулах гэх мэт. Тиймээс хуулбарлах логик нь ихэвчлэн маш нарийн төвөгтэй байдаг тул системийн нийт нарийн төвөгтэй байдал нь 2 биш, харин 3, 5, 10 дахин их байж болно.
Хоёр дахь хавх: Бид үнэхээр том цогц системийг бүтээхдээ эцэст нь юу авахыг хүсч байгаагаа төсөөлдөг. Voila: Бид ямар ч зогсолтгүй ажилладаг, хагас секундын дотор (эсвэл илүү сайн, тэр даруй) сэлгэн ажилладаг, мөрөөдлөө биелүүлж эхэлдэг маш найдвартай системийг авахыг хүсч байна. Гэхдээ энд бас нэг нюанс бий: хүссэн шилжих хугацаа богино байх тусам системийн логик илүү төвөгтэй болно. Бид энэ логикийг илүү төвөгтэй болгох тусам систем илүү олон удаа эвдрэх болно. Мөн та маш тааламжгүй нөхцөл байдалд орж болно: бид сул зогсолтыг багасгахын тулд бүх хүчээ дайчлан хичээж байгаа боловч үнэн хэрэгтээ бид бүх зүйлийг улам төвөгтэй болгож байгаа бөгөөд ямар нэг зүйл буруу болвол сул зогсолт дуусах болно. Энд та ихэвчлэн: за ... захиалга хийхгүй байсан нь дээр байх гэж бодож байна. Энэ нь дангаараа, ойлгомжтой сул зогсолттой ажилласан бол илүү дээр байх болно.
Та үүнтэй хэрхэн тэмцэж чадах вэ? Бид өөрсдөдөө худлаа ярихаа больж, одоо энд сансрын хөлөг бүтээх гэж байна гэж өөрсдийгөө магтахаа болих хэрэгтэй, гэхдээ энэ төсөл хэр удаан худлаа болохыг хангалттай ойлгох хэрэгтэй. Энэ хугацаанд бид системийнхээ найдвартай байдлыг нэмэгдүүлэхийн тулд ямар арга хэрэглэхээ сонгох болно.
Мэдээжийн хэрэг, амьдралаас "бүү өгүүллэгүүд"-ийн цаг болжээ.
Нэгдүгээр жишээ
Н хотын 1-р хоолой цувих үйлдвэрийн нэрийн хуудасны вэб сайтыг төсөөлөөд үз дээ.Түүнд ТОНОГ ЦЭВЭРЛЭГИЙН 1-р үйлдвэр гэж асар том үсгээр бичсэн байна. Яг доор нь: "Манай хоолойнууд бол N-д хамгийн бөөрөнхий хоолой юм." Мөн доор гүйцэтгэх захирлын утасны дугаар болон түүний нэр байна. Та захиалга хийх хэрэгтэй гэдгийг бид ойлгож байна - энэ бол маш чухал зүйл! Энэ нь юунаас бүрдэхийг олж мэдье. Html-статик - өөрөөр хэлбэл ерөнхий менежер нь хамтрагчтайгаа халуун усны газар ширээний ард дараагийн хэлэлцээрийн талаар ярилцаж байгаа хэд хэдэн зураг юм. Бид сул зогсолтын талаар бодож эхэлдэг. Энэ нь санаанд орж байна: чи тэнд таван минут хэвтэх хэрэгтэй, үүнээс илүүгүй. Тэгээд асуулт гарч ирнэ: ерөнхийдөө манай энэ сайтаас хэр их борлуулалт хийсэн бэ? Хэр их - хэд вэ? "Тэг" гэж юу гэсэн үг вэ? Энэ нь генерал өнгөрсөн жил бүх дөрвөн гүйлгээг нэг ширээн дээр, халуун усны газар очиж, ширээнд суудаг хүмүүстэй хийсэн гэсэн үг юм. Сайт нэг өдөр суусан ч аймшигтай зүйл тохиолдохгүй гэдгийг бид ойлгож байна.
Танилцуулга мэдээлэлд үндэслэн энэ түүхийг сөхөх өдөр бий. Орон тооны цомхотголын схемийн талаар бодож эхэлцгээе. Мөн бид энэ жишээний хувьд хамгийн тохиромжтой илүүдлийн схемийг сонгодог: бид илүүдэл ашиглахгүй. Энэ бүх зүйлийг ямар ч админ утааны завсарлагатайгаар хагас цагийн дотор босгож чадна. Вэб сервер суулгаж, файл нэмнэ үү. Энэ нь ажиллах болно. Та ямар нэгэн зүйлийг ажиглах шаардлагагүй, ямар нэгэн зүйлд онцгой анхаарал хандуулах шаардлагагүй. Өөрөөр хэлбэл, №XNUMX жишээний дүгнэлт нь маш тодорхой байна: нөөцлөх шаардлагагүй үйлчилгээг захиалах шаардлагагүй.
Хоёр дахь жишээ
Компанийн блог: тусгайлан бэлтгэгдсэн хүмүүс тэнд мэдээ бичдэг, бид ийм ийм үзэсгэлэнд оролцсон, гэхдээ бид өөр шинэ бүтээгдэхүүн гаргасан гэх мэт. Энэ бол WordPress-тэй стандарт PHP, жижиг мэдээллийн сан, бага зэрэг статик юм гэж бодъё. Мэдээжийн хэрэг, та ямар ч тохиолдолд хэвтэх ёсгүй - "таван минутаас илүүгүй!" Энэ бүгд л бодогддог. Гэхдээ цааш нь бодъё. Энэ блог юу хийдэг вэ? Хүмүүс тэнд Yandex-ээс, Google-ээс зарим асуулгад үндэслэн органик байдлаар ирдэг. Агуу их. Борлуулалт үүнтэй холбоотой юу? Epiphany: үнэхээр биш. Зар сурталчилгааны урсгал нь өөр машин дээр байрладаг үндсэн сайт руу ордог. Захиалгын схемийн талаар бодож эхэлцгээе. Сайн утгаараа, үүнийг хоёр цагийн дотор босгох хэрэгтэй, үүнд бэлтгэх нь сайхан байх болно. Өөр дата төвөөс машин аваад орчинг нь, өөрөөр хэлбэл вэб сервер, PHP, WordPress, MySQL-г оруулаад тэндээ үлдээх нь зүйд нийцнэ. Бүх зүйл эвдэрсэн гэдгийг ойлгож байгаа энэ мөчид бид хоёр зүйлийг хийх хэрэгтэй - mysql хогийн цэгийг 50 метрийн зайд өнхрүүлээрэй, тэр минутын дотор тэнд нисч, нөөцөөс тодорхой тооны зургийг гаргах болно. Энэ нь бас байхгүй, учир нь Бурхан хэр удаан мэдэх юм. Ийнхүү хагас цагийн дотор бүх зүйл дээшилнэ. Ямар ч хуулбар, эсвэл бурхан намайг өршөөг, автоматаар бүтэлгүйтэх. Дүгнэлт: Нөөцлөлтөөс хурдан гаргах боломжтой зүйлийг нөөцлөх шаардлагагүй.
Гуравдугаар жишээ, илүү төвөгтэй
Онлайн дэлгүүр. Нээлттэй зүрхтэй PhP нь бага зэрэг өөрчлөгдсөн, хатуу суурьтай mysql юм. Маш их статик (эцэст нь, онлайн дэлгүүрт сайхан HD зураг болон бусад зүйлс байдаг), сессэд зориулсан Redis болон хайлт хийхэд зориулсан Elasticsearch. Бид сул зогсолтын талаар бодож эхэлдэг. Мэдээжийн хэрэг, онлайн дэлгүүр нэг өдрийн турш өвдөлтгүй хэвтэж чадахгүй нь ойлгомжтой. Эцсийн эцэст, энэ нь удаан байх тусам бид илүү их мөнгө алддаг. Үүнийг хурдасгах нь зүйтэй. Хэр их вэ? Нэг цаг хэвтвэл хэн ч галзуурахгүй гэж бодож байна. Тийм ээ, бид ямар нэг зүйлийг алдах болно, гэхдээ бид шаргуу ажиллаж эхэлбэл энэ нь улам дордох болно. Бид нэг цагт зөвшөөрөгдсөн сул зогсолтын схемийг тодорхойлдог.
Энэ бүгдийг яаж хадгалах вэ? Ямар ч тохиолдолд танд машин хэрэгтэй: нэг цаг бол маш бага. Mysql: Энд бид аль хэдийн хуулбарлах, шууд хуулбарлах шаардлагатай байна, учир нь нэг цагийн дараа 100 ГБ хогийн цэгт нэмэгдэхгүй байх магадлалтай. Статик, зураг: дахиад нэг цагийн дараа 500 ГБ нэмж оруулах цаг гарахгүй байж магадгүй юм. Тиймээс зургийг даруй хуулбарлах нь дээр. Редис: Энд л юм сонирхолтой болдог. Redis-д сессүүд хадгалагддаг - бид үүнийг зүгээр л авч булшлах боломжгүй. Учир нь энэ нь тийм ч сайн биш байх болно: бүх хэрэглэгчид гарах болно, тэдний сагс хоосорно гэх мэт. Хүмүүс хэрэглэгчийн нэр, нууц үгээ дахин оруулахаас өөр аргагүй болох бөгөөд олон хүн салж, худалдан авалтаа дуусгахгүй байж магадгүй юм. Дахин хэлэхэд хөрвүүлэлт буурах болно. Нөгөөтэйгүүр, Redis нь шууд шинэчлэгдсэн бөгөөд хамгийн сүүлд нэвтэрсэн хэрэглэгчид ч шаардлагагүй байж магадгүй юм. Сайн буулт бол Редисийг аваад өчигдрийн нөөцөөс, эсвэл цаг тутамд хийвэл нэг цагийн өмнөхөөс сэргээх явдал юм. Аз болоход үүнийг нөөцлөлтөөс сэргээх нь нэг файлыг хуулах гэсэн үг юм. Мөн хамгийн сонирхолтой түүх бол Elasticsearch юм. Хэн MySQL хуулбарыг сонгож авсан бэ? Хэн Elasticsearch хуулбарыг сонгож авсан бэ? Тэгээд хэний дараа энэ нь хэвийн ажилласан бэ? Би юу хэлэх гээд байна вэ гэхээр бид системдээ тодорхой нэг аж ахуйн нэгжийг олж хардаг. Энэ нь ашигтай юм шиг санагдаж байна - гэхдээ энэ нь төвөгтэй юм.
Манай инженер нөхдүүд түүнтэй ажиллаж байсан туршлагагүй гэдэг утгаараа цогцолбор. Эсвэл сөрөг туршлага бий. Эсвэл энэ нь нюанс эсвэл түүхий эдтэй нэлээд шинэ технологи хэвээр байгааг бид ойлгож байна. Бид бодож байна ... Хараал ид, уян харимхай бас эрүүл, үүнийг нөөцөөс сэргээхэд бас их хугацаа шаардагддаг, би яах ёстой вэ? Манай тохиолдолд уян хатан нь хайлт хийхэд ашиглагддаг гэдгийг бид ойлгож байна. Манай онлайн дэлгүүр хэрхэн зарагддаг вэ? Бид маркетерууд дээр очиж хүмүүс хаанаас ирснийг асуудаг. Тэд "Yandex Market-ийн 90% нь бүтээгдэхүүний карт руу шууд ирдэг" гэж хариулдаг. Мөн тэд үүнийг худалдаж авдаг, эсвэл авдаггүй. Тиймээс хэрэглэгчдийн 10% нь хайлт хийх шаардлагатай байдаг. Мөн уян хатан хуулбарыг, ялангуяа өөр өөр бүс дэх өөр өөр мэдээллийн төвүүдийн хооронд байлгах нь үнэхээр маш олон нюанстай байдаг. Аль гарц вэ? Бид нөөцлөгдсөн сайтаас уян харимхайг авч, үүнтэй юу ч хийхгүй. Хэрэв хэрэг сунжирч байвал бид хэзээ нэгэн цагт үүнийг сөхөж магадгүй, гэхдээ энэ нь тодорхойгүй байна. Үнэн хэрэгтээ, дүгнэлт нь адилхан, нэмэх эсвэл хасах: бид дахин мөнгөд нөлөөлдөггүй үйлчилгээг нөөцлөхгүй. Диаграмыг илүү хялбар болгохын тулд.
Дөрөвдүгээр жишээ, бүр ч хэцүү
Интегратор: цэцэг зарах, такси дуудах, бараа зарах, ерөнхийдөө бүх зүйл. Олон тооны хэрэглэгчдэд 24/7 ажилладаг ноцтой зүйл. Бүрэн хэмжээний сонирхолтой стектэй, сонирхолтой суурь, шийдэл, өндөр ачаалалтай, хамгийн чухал нь 5 минутаас дээш хугацаагаар хэвтэх нь өвддөг. Хүмүүс худалдаж авахгүй учраас биш, харин хүмүүс энэ зүйл болохгүй байгааг хараад бухимдаж, эргэж ирэхгүй байх болно.
БОЛЖ БАЙНА УУ. Таван минут. Энэ талаар бид юу хийх гэж байна вэ? Энэ тохиолдолд бид насанд хүрэгчдийн нэгэн адил бүх мөнгөө хуулбарлан, жинхэнэ нөөц сайтыг бий болгоход зарцуулдаг, магадгүй энэ сайт руу шилжих ажлыг аль болох автоматжуулдаг. Үүнээс гадна та нэг чухал зүйлийг хийхээ санах хэрэгтэй: үнэндээ шилжих дүрмийг бичих. Бүх зүйл автоматжуулсан байсан ч зохицуулалт нь маш энгийн байж болно. "Тийм, ийм скрипт ажиллуулах", "53-р зам дээрх ийм ийм нүдийг дарна уу" гэх мэт цувралуудаас - гэхдээ энэ нь тодорхой үйлдлийн жагсаалт байх ёстой.
Тэгээд бүх зүйл тодорхой харагдаж байна. Хуулбарыг солих нь өчүүхэн ажил юм, эсвэл өөрөө солигдоно. DNS дээр домэйн нэрийг дахин бичих нь ижил цувралаас хамаарна. Асуудал нь ийм төсөл бүтэлгүйтвэл үймээн самуун эхэлдэг бөгөөд хамгийн хүчтэй сахалтай админууд хүртэл үүнд өртөмтгий байдаг. "Терминал нээ, наашаа ир, манай серверийн хаяг ийм хэвээр байна" гэсэн тодорхой зааваргүй бол сэхээн амьдруулах 5 минутын хязгаарыг биелүүлэхэд хэцүү. Дээрээс нь бид эдгээр журмыг ашиглахдаа дэд бүтцэд гарсан зарим өөрчлөлтийг бүртгэх, тэр дагуу зохицуулалтыг өөрчлөхөд хялбар байдаг.
За, захиалгын систем нь маш нарийн төвөгтэй бөгөөд хэзээ нэгэн цагт бид алдаа гаргасан бол бид нөөц сайтаа устгаж, үүнээс гадна хоёр сайт дээрх өгөгдлийг хулуу болгон хувиргаж чадна - энэ нь бүрэн гунигтай байх болно.
Тавдугаар жишээ, бүрэн хардкор
Дэлхий даяар хэдэн зуун сая хэрэглэгчтэй олон улсын үйлчилгээ. Бүх цагийн бүсүүд байдаг, хамгийн их хурдтай ачаалал ихтэй тул та огт хэвтэж чадахгүй. Нэг минут - энэ нь гунигтай байх болно. Юу хийх вэ? Бүрэн хөтөлбөрийн дагуу дахин нөөцөл. Өмнөх жишээн дээр миний ярьсан бүх зүйлийг бид хийсэн, мөн бага зэрэг. Хамгийн тохиромжтой ертөнц бөгөөд манай дэд бүтэц нь IaaC devops-ийн бүх үзэл баримтлалын дагуу байдаг. Энэ нь бүх зүйл git дээр байгаа бөгөөд та зүгээр л товчлуур дээр дарна уу.
Юу дутагдаж байна вэ? Нэг - дасгалууд. Тэдэнгүйгээр энэ нь боломжгүй юм. Бидэнд бүх зүйл төгс төгөлдөр юм шиг санагддаг, бид ерөнхийдөө бүх зүйлийг хяналтандаа байлгадаг. Бид товчлуурыг дарахад бүх зүйл тохиолддог. Энэ нь тийм байсан ч гэсэн - энэ нь ийм байдлаар болохгүй гэдгийг бид ойлгож байна - манай систем бусад системүүдтэй харьцдаг. Жишээлбэл, энэ нь 53-р маршрутын dns, s3 хадгалах, зарим api-тай нэгтгэх явдал юм. Энэхүү таамаглалын туршилтаар бид бүгдийг урьдчилан харж чадахгүй. Бид үнэхээр унтраалга татах хүртэл энэ нь ажиллах эсэхийг мэдэхгүй.
Энэ л байх. Залхуу байж, хэтрүүлж болохгүй. Ажиллах цаг тантай хамт байх болтугай!
Эх сурвалж: www.habr.com