Танин мэдэхүй

Сүүлийн хэдэн жил trend болж байгаа, Data Scientist болон BI(Business Intelligence) Analyst гэсэн 2 мэргэжлийн талаар хальт бичмээр санагдлаа. Би яг мэргэжлийн хүн биш болохоор андуурсан зүйл байвал залруулаарай.

Орчин үед технологийн компаниуд ямар нэгэн бүтээгдэхүүн гаргачихаад хаячихдаг цаг байхаа больсон. Өрсөлдөөн их тул ямагт сайжруулж, хэрэглэгчийн needs(хэрэгцээ, шаардлага) болон үйл хөдлөлд тааруулж байнга өөрчилж байхгүй бол, өрсөлдөөн ихтэй салбарт амьд гарах боломжгүй юм.

Хэрэглэгчийн юу хүсэж байгааг хэрхэн мэдэх вэ? Яахав анкет явуулаад асуултууд асууж болох юм. Тэгэхдээ 100 хүн рүү анкет бөглөх хүсэлт явуулахад хэд нь хариулдаг гэж бодож байна? 1-2 нь хариулбал их юм. Бас нэг өөр асуудал нь, хэрэглэгчид өөрсдөө ч юу хүсээд байгаагаа мэдэхгүй тохиолдлууд их юм. Бас яавал хэрэглэгчдийг өөрсдийнхөө бүтээгдхүүнд зарцуулах мөнгийг боломжит хамгийн ихээр өсгөх вэ? Эдгээр асуудлуудыг шийдхийн тулд, сүүлийн хэдэн жилүүдэд компаниуд бараг хэрэглэгчдийн бүх үйл хөдлөлүүдийг цуглуулж эхэлсэн юм. Жишээ нь хэрэглэгчид ямар хуудас руу орсоныхоо дараа, ямар хуудас руу шилжиж байна, эсвэл ямар хуудсан дээр илүү их цаг зарцуулж байна, эсвэл ямар хэрэглэгч нар ямар бүтээгдхүүнд илүү мөнгө зарцуулж байна гэх мэт. Таны үйлдэл бүр чинь бүртгэгдэж байгаа гэсэн үг. Эдгээрийг raw data гэх бөгөөд, хүн ойлгохын аргагүй асар их мэдээллүүд(big data) юм.

BI Analyst нь хэрэглэгчдээс цуглуулсан raw data-г хүн ойлгогдохоор болгож, түүн дээрээ суурилан, шинэ бүтээгдхүүнийг санаачлах болон, одоогийн бүтээгдхүүнийг сайжруулах тал дээр ажиллана.

Data Scientist нь мөн адил хэрэглэгчдээс цуглуулсан raw data-г хүн ойлгогдохоор болгох ба, түүн дээрээ суурилан ирээдүйн төлөвийн prediction(таамаглалт) хийнэ.

Өөрөөр хэлбэл энэ 2 мэргэжил 2-уулаа хэрэглэгчдээс цуглуулсан асар их мэдээлэл дээр ажиллана.

Жаахан тодорхой болгох үүднээс маш энгийн жишээ авъя. Нэг хэсэг бараг хүн болгон тоглож байсан Candy Crash гээд тоглоом байлаа гэж үзье. Тэр тоглоом чинь, таныг хэддүгээр үе дээр хэдэн минут зарцуулж, хэдэн удаа хожигдож, хэр их мөнгө зарцуулж ялсан бүх мэдээллийг тухайн компани руугаа дамжуулна. Эдгээр мэдээлэл дээр үндэслэн, BI Analyst нь game balance(хэтэрхий хүнд level-ын дараа хэтэрхий амархан level байхгүйгээр, бага багаар хэцүү болох)-ийг сайжруулах, эсвэл аль level дээр хүмүүс хэтэрхий их тоглосноосоо болж гэнэт уйдаж, тоглоомыг гэнэт дахин тоглохоо больж байгааг судалж, тэр level-ыг сайжруулах гэх мэт зүйлүүд хийнэ. Харин Data Scientist нь мөн л адилхан мэдээлэл дээр үндэслэн, дараагийн сард хэрэглэгчдийн тоо хэдэн хувиар нэмэгдэж, орлогод ямар өөрчлөлт орохыг таамаглах юм.

Яагаад энэ 2-ыг бичих болсон бэ гэхээр, их сургуулидаа математик болон статистикийн хичээл авч байсан, SQL(R мөн ашигладаг юм шиг байна лээ)-ын бага зэргийн мэдлэгтэй бол ямар ч хүн эдгээр 2 мэргэжил рүү төвөггүй хөрвөж чадах юм шиг санагдаад энэ 2-ын талаар бичлээ. Мөн цалингийн хувьд ч гайгүй тул, одоо хийж байгаа ажлаасаа уйдаж байгаа хүн байвал судлаж үзээрэй.

Та нэг энгийн web server болон өгөгдлийн сангаас бүтэх систем хийлээ гэж үзье. Хэрвээ тэр систем чинь ачаалал даахгүй байвал яах вэ?
Хэрвээ web server чинь ачааллаа даахгүй байгаа бол шийдэхэд амархан Яг адилхан 1 instance үүсгэхэд л хангалттай.
Харин өгөгдлийн сан чинь ачааллаа дийлэхгүй бол шийдэхэд нэлээн яривигтай. Мэдээж эхний алхам бол бүх хандалт(query)-аа optimization хийх, хэд хэдэн давхар cache давхарга нэмэх.
Ихэнх системийн хувьд өгөгдөл унших тоо нь бичих тооноосоо хэд дахин, эсвэл хэдэн арав дахин их байдаг. Жишээ нь, хүмүүс Facebook-ын profile-аа сардаа эсвэл бараг жилдээ 1 л өөрчилдөг байх. Харин тэр хүний profile-ыг өдөрт хэдэн арваас, хэдэн зуун хүн харж байгаа. Тиймээс, таны хийж буй систем чинь, яг үүнтэй адил уншилтын тоо нь бичилтийн тооноосоо хамаагүй их бол, master-slave загвар луу шилжүүлж болох юм.

Master Толгой өгөгдлийн сан ба, бүх бичилтүүд ийшээ хийгдэнэ
Slave Дагавар өгөгдлийн сан ба, бүх уншилтууд эндээс хийгдэнэ

Ажиллах зарчим нь маш энгийн. Master луу бичилт хийх болгонд master нь slave-үүд рүүгээ давхар бичилт хийгээд шинэчлээд, бүх server дээрх мэдээлэл яг адил мэдээлэл агуулаад явах юм. Үүнийг replication гэж нэрлэдэг. Харин одоо их хэмжээний унших хүсэлт ирэхэд slave-үүд рүүгээ тэнцүү хуваагаад явуулчихна. Дараах зурганд дүрслэх гэж оролдлоо.

Ихэнх төрлийн өгөгдлийн сангууд replication хийх чадвартай бөгөөд, ихэнхдээ 2 төрөл байдаг. Sync болон async. Sync replication нь бичих хүсэлт авангуутаа slave-үүдээ шинэчлэх бөгөөд, шинэчилж дууссаны дараа, бичилт амжилттай боллоо гэсэн хариултыг буцаана. Харин async нь, master дээр бичилтээ хийсэний дараа бичилт амжилттай боллоо гэсэн хариуг буцаагаад, дараа нь slave-үүдээ шинэчилнэ.
2 арга нь 2-уулаа сайн ба муу талуудтай бөгөөд, хамгийн гол анхаарах ёстой зүйл гэвэл consistency юм. Async үед inconsistent буюу, нэг агшинд нэг өгөгдөл, 2 өөр утга агуулах боломж үүсч байгаа юм. Өөрөөр хэлбэл дөнгөж бичсэний дараа, уншилт хийвэл хуучин утга уншигдах магадлалтай гэсэн үг.

Харин одоо, бүүр их ачаалаллын талаар ярилцая. 100 сая хэрэглэгчийн мэдээлэл хадгалах ёстой гэж үзье. Урьдчилсан тооцооны дүнд 10 сая хэрэглэгчийн мэдээлэлийг 1 server-т хадгалахад ачаалал даана гэж үзье. Тэгвэл одоо бидэнд 1 биш 10 master хэрэг болно. Өөрөөр хэлбэл 1 том хүснэгтийг 10 жижиг хэсэг болгож хувааж байнаа гэсэн үг. Үүнийг sharding гэх бөгөөд, хуваагдсан хэсгүүдийг shard гэнэ. Дараах зурганд дүрслэв.

Янз бүрийн байдлаар хувааж болно. Жишээ нь 1-1000000 ID-тай хэрэглэгчийг Master 1-д, 10000001-20000000 ID-тай хэрэглэгчдийг Master 2-т гэх мэт. Эсвэл 10-т хуваагаад гарах үлдэгдлээр нь 10 master-руугаа хувааж болно. Эсвэл хэрэглэгчийн амьдарч буй улсаар нь гэх мэт, хамгийн гол нь системдээ тааруулаад, яаж хуваавал хамгийн хялбар аргаар хүссэн мэдээлллээ авч чадах вэ, мөн ачаалал болон, мэдээллийн хувьд тэнцвэртэй баланстай байж чадах уу гэдгийг бодох хэрэгтэй.
Жишээ нь Facebook дээрх post-ын comment-ыг хадгалах ёстой гэж үзье. Тэгвэл comment-ынх нь ID-аар биш, post-ынх нь ID-г ашиглан sharding хийвэл, адил post дээрх бүх comment-ууд нэг server дээр хадгалагдах тул, comment-уудыг уншихын тулд, олон server-рүү хандах шаардлагагүй болох юм.

Эцэст нь нэг юм хэлэхэд, энд нэг ч өгөгдлийн сангийн нэр(MySQL, MongoDB гэх мэт) дурдаагүй байгааг анзаарсан байх. Ямар ч өгөгдлийн сан дээр, автомат sharding байсан ч, ард нь нэг иймэрхүү л зүйл явагдаж байгаа гэдгийг ойлгуулах гэсэн юм. KVS төрлийн NoSQL-уудын хувьд, key-ийнхээ hash-аар хуваадаг ба ихэнх нь автоматаар, эсвэл хангалттай их library-ууд байдаг тул хөгжүүлэгч талаас нээх асуудал гараад байхгүй. Харин RDBMS-үүдийн хувьд, системийн шаардлага янз бүр тул, бараг өөрсдөө системдээ тохирсон sharder хөгжүүлж таарах байх.

Microservices нь нэгэн төрлийн архитектур загвар юм. Microservices-ын талаар ярихын өмнө, эхлээд дараах ойлголтуудыг тайлбарлъя.

Monolithic – Энэ нь, нэг бүхэл гэсэн утгатай бөгөөд, хийж байгаа систем чинь тэр чигээрээ ганцхан хэл дээр бичигдсэн нэг бүхэл код байхыг хэлнэ. Монголд хийгдэж байгаа вебүүдийн ихэнх нь ийм байх гэж бодож байна. Мөн олон startup компаниуд, анх гарч ирэхдээ ийм загвартай байдаг.

Microservices – Энэ нь, систем чинь олон жижиг системээс бүрэлдхийг хэлж байгаа юм. Жишээ нь онгоцны тийз захиалдаг систем байлаа гэж үзвэл, тооцоо хийдэг систем, хайлт хийдэг систем, худалдаж авсан тийзийг илгээдэг систем гэх мэт, бизнес логиктойгоо уялдуулан, хоорондоо харилцах чадвартай олон жижиг систем хөгжүүлэх юм.

Polyglot Microservices – Энэ зүгээр л microservices. Харин, бүх систем чинь адилхан хэл дээр хөгжүүлэлт хийгдсэн байх албагүй, системийн онцлогоос хамааран өөр өөр хэл дээр хөгжүүлэгдсэн байхыг ингэж нэрлэнэ.

Microservices-ын талаар бага зэрэг ойлголттой болсон байх. Хэрвээ жижиг систем хөгжүүлж байгаа бол, зүгээр monolithic-ээр явсан нь дээр байх. Нэг нийтлэл уншиж байхад, “систем хөгжүүлэлтийн сүүлийн шат нь microservices юм” гэсэн байна лээ. Тэгэхээр, системийн чинь хэрэглэгчийн тоо нь ихсээд, scaling шаардлагатай болж ирэх үед, нэгэн төрлийн сонголт болгон харахад гэмгүй болов уу.

Одоо microservices давуу талуудын талаар ярилцъя.

Хялбар код менежмент болон хөгжүүлэлт
Monolithic системийн хувьд, ямар нэгэн шинэ зүйл нэмэх болгонд кодын чинь хэмжээ ихсэнэ. Бүхэл нэг код тул, аль нэг газар алдаа гаргахад л бусад газарт нөлөөлөх болно. Мөн, хөгжүүлэгч бүр тэр код руу хандаж байгаа тул, явцын дунд, хэн нь аль хэсгийг хариуцаж байгаа нь харагдахаа больж эхлэнэ. Харин microservices-ын хувьд, систем тус бүр тус тусдаа кодтой байх тул, кодын хэмжээ замбараагүй өсөж хяналтаас гарахаас сэргийлж чадах юм. Мөн систем бүрийг тусгай багуудад хариуцуулснаар, тэр систем нь өөрийн гэсэн эзэнтэй болж, байнга арчилж, сайжруулахад амар болно. Мөн дараагийн хувилбарыг тэс өөрөөр хийхээр шийдсэн бол, зөвхөн тэр системээ л дахин бичихэд хангалттай. Харин monolithic системийн хувьд, аль хэдийн өөр зүйлүүдтэй хэт уялдаа хамааралтай болчихсон байх тул, өөрчлөлт хийхэд хэцүү байх болно.

Availability
Монгол хэл рүү юу гэж орчуулахаа мэдсэнгүй. Ер нь бол, систем чинь унахгүй, зогсолтгүй ажиллах чадвар л юм уу даа. Monolithic системийн хувьд, нэг газар л алдаа гарахад систем чинь тэр чигээрээ унах магадлалтай. Жишээ нь асар том PHP дээр бичигдсэн систем байлаа гэхэд, нэг semicolon мартахад л систем чинь тэр чигээрээ зогсоно.
Харин microservices-ын хувьд, ямар систем унаснаас хамаарч систем-ын зарим хэсгүүд ажиллах боломжтой юм.

Уян хатан scaling
Одоо бараг ихэнх газрууд auto-scaling хийдэг болсон байх. Серверийн ачааллаас хамаараад, шинэ instance үүсгэх эсвэл устгадаг. Microservices-ын хувьд систем тус бүр дээр scaling хийх боломжтой юм.

Гэх мэт олон давуу талтай юм. Өөр давуу талууд бас байгаа, тэгэхдээ яг одоо санаанд орж ирэхгүй байна.

Жишээ болгож миний блогоо бичиж байгаа WordPress-ыг monolithic болон microservices байдлаар дүрслэх гэж оролдъё.

Харж байгаачлан, microservices загвар нь жижиг систем болон, цөөн хүнтэй компанид тохиромжгүй байж мэдэх юм. Харин дээр дурьдсанчлан, хэрвээ хэрэгчлэгчийн тоо ихсээд scaling хийх шаардлагатай болсон үед хэрэгтэй загвар юм.
Миний мэдэхээр ямар ч байсан, Amazon, Netflix, LinkedIn гэх мэт бараг бүх их хэрэглэгчтэй компаниуд microservices загварыг ашигладаг. Миний хувьд, өөрөө ийм архитектур гаргаж байгаагүй ч, одоо ажиллаж байгаа прожект дээр, ирээдүйд ийм загвар луу шилжих талаар ярилцаж байгаа болохоор судалж байгаа юм.

За дараагийн бичлэгээр уулзах хүртэй баяртай!

A/B Testing-ын талаар ярья. Энэ удаад, технологийн талаас нь биш, яг юу болох, яагаад хэрэгтэй вэ гэдэг талаас нь ярья.
Нэг жишээ авья. Counter Strike тоглоом анх эхлэхдээ 800$-тай эхэлдгийг бараг бүгд мэдэж байгаа байх. Мөн, нийт мөнгөний хэмжээ 16.000$-оос хэтэрдэггүй.
Тэгвэл эдгээр тоог яаж шийдэх вэ? Counter Strike-ыг бүтээгчид, A/B testing ашигласан үгүйг мэдэхгүй, тэгэхдээ ямар ч байсан нэг нөхөр дуртай тоогоо хэлээд 800$, 16.000$ гэсэн 2 тоог шийдээгүй нь ойлгомжтой. Тэгвэл яаж шийдэх вэ?
Мэдээж судалгаа хийнэ. Тоглоомоо release хийснийхээ дараа, хэрэглэгчдээ хэсэг бүлэг болгож хуваагаад, 400$, 500$, 600$, 700$, 800$, 900$ гэх мэт мөнгийг анх өгнө. Бас бүлэг тус бүрт 14.000$, 15.000$, 16.000$, 17.000$ гэх мөнгүүдийг дээд хязгаар болгон тогтоож өгнө.
Дараа нь тоглогчид 1 удаа тоглохдоо хэр удаан тоглож байна, өдөрт хэдэн удаа тоглож байна, амьдралынхаа турш хэр их тоглож байна, хэр их мөнгө энэ тоглоомонд зарцуулж байна, гээд янз бүрийн үзүүлэлтийг харна.
Үр дүн дээр нь үндэслэн эдгээр тоонуудыг шийднэ. Зөвхөн шинэ бүтээл гэлтгүй, шинэ feature-үүд дээр ч адил өргөн ашиглана.
Ер нь бол ийм л зүйл. Яаж хэрэгжүүлэх нь хөгжүүлэгчдийн сонголт. Жишээ нь user id-ын сүүлийн 2 орон 00-17 бол бүлэг 1, үлдсэн нь бүлэг 2 ч гэх юмуу ангилна гэсэн үг.
Авсан жишээ жаахан авцалдахгүй байсан бол, уучлаарай.
Have a good weekend!

AWS(Amazon Web Services) гэж мэдээж сонссон байх. Тэрний нэг үйлчилгээ нь DynamDB юм. NoSQL төрлийн database. Яагаад энэ талаар ярих болсон бэ гэхээр, миний ажиллаж байгаа тоглоом, infrastructure-аа аль болох AWS-руу шилжүүлэхээр ажиллаж байгаа юм. Яагаад гэхээр, өөрсдөө зөвхөн тоглоом хөгжүүлэх тал дээрээ төвлөрч ажиллаад, сервер талын асуудлуудаа автоматжуулах үүднээс. Мэдээж AWS ашигласанаар зардал гарах ч, dev ops-уудыг ажлуулах зардал болон, өөрсдөө бас хариуцаж байгаа серверүүдийн зардал багасах юм. Тэгэхдээ хамгийн гол зорилго нь найдвартай, high scaling болгох явдал юм.

DynamoDB
NoSQL database гэж дурьдсан. Маш энгийнээр хэлбэл, advanced KVS(Key/Value Store) юм.
Давуу талууд гэвэл
– Ямар ч их хэмжээний өгөгдөл байсан хамаагүй, auto-scaling.
– 10ms-ын дотор өгөгдлийг чинь буцаана. (Scan болон Query ашиглаагүй тохиолдолд)
– Document-тэй ажиллана. Өөрөөр хэлбэл MongoDB шиг JSON өгөгдлийг хадгалаад, тэрнийхээ нэг хэсгийг дуудах, эсвэл нэг хэсгийг өөрчлөх гэсэн үйлдлүүдийг хийх боломжтой.
– Ямар ч их хүсэлт ирсэн хүлээж авах боломжтой. Хүснэгтэндээ read/write throughput тохируулж өгнө. Мэдээж их тохируулах тусам ихийг төлнө. Тэгэхээр илүү уян хатан болж байгаа юм. Хэрвээ site руу чинь секунданд 10 хэрэглэгч ханддаг бол, throughput-ээ багаар тохируулаад, хэрвээ 10,000 хэрэглэгч ханддаг бол, 1000 дахин ихэсгэхэд л хангалттай.

Сул талууд
– MySQL гэх мэт RDBMS-үүд ACID(Atomicity, Consistency, Isolation, and Durability) гэсэн зүйлийг танд амлаж чаддаг. Харин DynamDB-ын хувьд зөвхөн CD(Consistency and Durability) амлаж чадна.
– DynamoDB-ын consistency нь тэгэхдээ eventually consistency юм. Тэр нь юу гэсэн үг вэ гэвэл, нэг өгөгдлийг database-рүү бичих үед, тэр өгөгдөл чинь яг тэр дороо database-д бичигдсэн гэсэн баталгаа байхгүй. Тэгэхдээ хэзээ нэгэн цагт бичигдэнэ гэсэн үг. Тэр нь тэгэхдээ сайндаа л хэдэн ms болохоор, санаа зовох зүйлгүй ч, тэрийг бодолцож системээ хөгжүүлэх хэрэгтэй. Бас eventually consistency ч гэсэн, өгөгдөл унших үед, consistent унших боломжтой, тэр нь inconsistent уншсанаас 2 дахин үнэтэй тул, аль болох шаардлагатай үед л consistent read-ыг ашиглавал зүгээр юм.
– Atomicity болон isolation байхгүй тул, transaction бичих боломжгүй. Системээ, transaction байхгүйгээр зохион байгуулах, эсвэл тэрийг орлох зүйл бодож олох хэрэгтэй.

DynamoDB-рүү хөрвүүлэх гэж байгаа тоглоом
Тоглоомын хувьд гар утасны тоглоом бөгөөд, тоглогч ихсэх тусам, шинээр нэг ертөнц(world) үүсгэн, тэрэн дээрээ шинэ тоглогчидоо хүлээж авдаг юм. Өөрөөр хэлбэл horizontal scaling.
Ертөнц бүр өөрийн world server(GoLang дээр бичигдсэн), тэрний failover, мөн хэд хэдэн ертөнцүүд дундаа 2-3 MySQL server-тэй.
Тэгэхээр 50 ертөнц байлаа гэхэд 50(master world server) + 50(standby world server) + 10(master MySQL server) + 10(standby MySQL server) = 120 орчим server юмуудаа. Эдгээрийг цөөхөн хүнтэй баг өөрсдөө арчлана гэдэг жаахан ядаргаатай юм. Энэ тоо нь зөвхөн нэг тоглоомны server-ын тоо бөгөөд, компаний хэмжээнд яривал 10,000-аад server юм. Өдөр болгон аль нэг серверийн hard disk шатна, ямар нэгэн юм болохоо болино. Тэгэхээр миний хувьд, үнэхээр л том компани биш бол, өөрсдөө арчлах гэж байхаар AWS-ыг ашиглавал их зүгээр санагдсан.
Энэ тоглоомын хувьд болохоор, MySQL server-тэй ерөөсөө харьцдаггүй, зөвхөн world server-тэйгээ харьцдаг. World server нь in-memory болохоор, асар хурдан хариу өгдөг. Бараг хүссэн өгөгдөл чинь 1ms-ээс бага хугацаанд ирнэ. Харин world server нь тогтмол давталттай, өөр дээрх өөрчлөлтөө, MySQL рүү бичнэ. In-memory тул ямар нэгэн асуудал гарвал, бүх өгөгдлөө алдах тул, MySQL-руу бичиж байгаа юм.
Аз болж, тоглоомын бүх код, world server-тэйгээ харьцахдаа, зөвхөн нэг гарцаар дамждаг байсан юм.
Тэгэхээр миний хувьд, тэр гарцийг world server-тэй биш DynamoDB-тэй харьцдаг болгож өөрчлөхөд л хангалттай.
Гарсан асуудлууд
– World server нь зөвхөн өгөгдөл хадгалахаас гадна, өөр дээрээ логик агуулдаг тул тэдгээр логикуудыг application layer-рүү зөөх
– DynamoDB-ын Query болон Scan нь 10ms-ээс бага хугацуунд ирнэ гэсэн баталгаа байхгүй тул бүх өгөгдлийг GetItem, болон BatchGetItem-аар авч болдог байхаар өгөгдлийн бүтцүүдээ өөрчлөх
– Consistent read гэж байгаа ч, зардал хэмнэх үүднээс ямар үед consistent read, ямар үед inconsistent read ашиглахыг шийдэх
– Манайх зарим хэсэг дээрээ, transaction(world server нь бас transaction-тай) ашигладаг тул тэдгээр хэсгийг DynamoDB дээр асуудалгүй ажилладаг болгох
Transaction-ын хувьд, яг одоогоор шийдээгүй байгаа бөгөөд, application layer дээр кодын логикийг өөрчлөх, эсвэл Redis ашиглан өөрчлөх гэж байгаа өгөгдлүүдээ lock хийж байгаад бичих гэсэн 2 санал дээр ярилцаж байгаа.
Бараг Redis л ашиглаж lock бичих аргаар л хийх байх.

Have a nice weekend!

Бараг бүх startup компаниуд энэ 2 tool-ыг ашигладаг байх. Startup гэлтгүй томууд нь ч бас ашигладаг байх л даа.
Ямар тохиолдолд ашиглавал зүгээр вэ гэдгийг хальт тайлбарлах гэж оролдъё.
Ямар нэгэн систем хөгжүүлээд дууссаныхаа дараа, бид нар серверрүүгээ кодоо deploy хийдэг. Тэр үед янз бүрийн л асуудалтай тулгарч байсан байлгүй.
Яагаад хөгжүүлж байхад асуудал гараагүй хэрнээ, яг production сервер рүүгээ deploy хийх үед асуудал гарав?
Яагаад гэвэл, хөгжүүлж байгаа орчин(development environment) чинь бүтээгдхүүн болж ажиллах орчин(production environment)-оос чинь өөр байгаа болохоор.
Ихэнх тохиолдолд, Vagrant болон Docker-ыг ашиглахгүйгээр, production-тай яг адилхан орчин үүсгэхэд хэцүү. Ихэнх сервер-үүд Linux based, харин хөгжүүлэгчид ихэвчлэн Mac OS X эсвэл Windows ашигладаг. Mac OS X-ын хувьд UNIX based болохоор, Windows-ыг бодвол арай дээр ч гэсэн, 100% ижилхэн орчин үүсгэхэд бас л хүндрэл гарна.
Ижилхэн орчин гэдгээр би, яг адилхан OS version, яг адилхан PHP version, яг адилхан Ruby version, яг адилхан MySQL version тэй байхыг илэрхийлж байгаа шүү.
MySQL-ын жижиг version-ын өөрчлөлт хүртэл, системээс чинь хамаараад, өөр ажиллах тохиолдол үүсч болно.

Vagrant
Веб хуудас: https://www.vagrantup.com/
Энэ tool нь VirtualBox ашиглан, virtual machine үүсгэн, тэрэн дээр өөрийн чинь хүссэн орчинг бүрдүүлдэг tool юм.
Ашиглахад их энгийн. Vagrantfile дотор, ямар virtual machine үүсгэмээр байгаа, ямар OS ашигламаар байгаа, OS-ээ initialize хийсний дараа юу юу суулгамаар байгаагаа бичиж өгөөд л болоо. Vagrantfile-аа үүсгэсэнийхээ дараа дараах 2 мөр коммандыг бичихэд л хангалттай.

vagrant up // Virtual Machine-ийг initialize хийх
vagrant ssh // SSH-ээр Virtual Machine-рүүгээ орох

Vagrant-ын веб хуудас руу нь ороод харвал, Vagrantfile хэрхэн үүсгэх талаар, их дэлгэрэнгүй тайлбарласан байгаа.
TIP: Synced Folders үүсгэхдээ NFS ашиглавал, мэдэгдэхүйцээр хурдан ажиллана.

Docker
Веб хуудас: https://www.docker.com/
Зорилгын хувьд бол Vagrant-тай бараг төстэй. Тэгэхдээ Docker нь олон Linux based VM үүсгэх үед kernel-ээ share хийдэг юм. Хэрвээ чи Linux ашигладаг бол, чиний ашиглаж байгаа Linux-ын kernel-ийг шинээр үүсгэх OS-ынхээ kernel-ын оронд ашиглана гэсэн үг. Mac OS X болон, Windows-ын хувьд kernel share хийх боломжгүй тул, эхлээд VirtualBox-оор Linux OS-тэй virtual machine үүсгээд, тэрэн дээрээ container үүсгээд явна. Kernel-ээ share хийж байгаа болохоор, Vagrant-ыг бодвол арай хөнгөхөн ажиллана. Тэгэхдээ Mac OS X болон Windows дээр ашиглах гэж байгаа бол, Vagrant-аас ямар ч ялгаагүй. Харин олон container үүсгэх гэж байгаа бол, Docker-нь хамаагүй илүү байх.

Эцэст нь
2-уулаа сурахад нээх хүнд зүйл биш болохоор, завтай үедээ 2-ууланг нь туршиж үзэж байгаад сурсан нь дээр. Манай компаний хувьд, Vagrant-уудаа Dockerize хийж байгаа. Тэгэхдээ “No Silver Bullet”. 2-ууланг нь сурч байгаад, хэрэгцээндээ тохируулж алийг нь ашиглахаа шийдвэл зүгээр.

Ойрд блог бичээгүй юм байна. Ажил гэр 2-ын хооронд өдөр өнгөрөөд байгаа болохоор бичих ч зүйл алга.
Сая сүүлийн хэд хоног router-тэй зууралдаад. Би Private Internet Access(цаашид PIA гэж товчлоно) гэдэг компаны Virtual Private Network(цаашид VPN гэж товчлоно) ашигладаг юм. Laptop дээрээ програмыг нь суулгаад нээх асуудалгүй ашиглаж байсан юм. Тэгээд, нэг өдөр VPN-ээ асаачихсан үедээ Chromecast руугаа видео шидэх гэтэл, Chromecast компьютер дээр гарч ирдэггүй. Харин VPN-ээ унтраахаар гарч ирээд байна. Уг нь IP-аар ping хийхээр хариу өгөөд байгаа юм. Харин hostname-ээр нь ping хийхээр хариу өгдөггүй. Тэгээд интернетээр хайж байтал, угаасаа VPN асаачихаар, Chromecast гарч ирэхээ больчихдог юм байна.
Тэгээд шийдэл хайж байтал, router дээрээ OpenVPN-ээ тохируулвал, Local Area Network(цаашид LAN гэж товчлоно) дахь бүх төхөөрөмжүүд интернет рүү гарахдаа VPN-ээр дамжиж гарах юм байна. Угаасаа, ойлгомжтой л доо, зүгээр router дээр OpenVPN тохируулж болдог гэж мэдээгүй байсан юм. Жишээ нь би гэрээсээ www.google.com-руу орлоо гэхэд доорхи зураг шиг мэдээлэл дамжина гэсэн үг.

OpenVPN нь өндөр нууцлалттай тул, намайг интернэтээр юу хийж байгааг мэдэх боломжгүй гэсэн үг. Дээрээс нь PIA нь дэлхийн нэлээн олон оронд сервер-үүдээ байрлуулсан тул, зарим нэг газар зүйн байрлалаар хязгаарлалт хийсэн веб сайт руу хандах боломжтой болж байгаа юм.
Янз бүрийн аргаар VPN үүсгэх боломжтой бөгөөд, миний мэдэхээр PPTP, L2TP/IPSec, OpenVPN. Энэ хуудсан дээр энэ 3 аргыг гоёоор харьцуулсан байна. Ер нь бол PPTP-г ерөөсөө битгий ашигла, болохгүй бол L2TP/IPSec-г ашигла, боломжтой бол OpenVPN-ыг ашигла гэсэн байгаа.
За тэгэхээр router дээрээ OpenVPN тохируулах ажилдаа оръё.

Continue reading…

Өнөөдөр, Franklin Covey Japan-ээс зохион байгуулдаг нэг сургалтанд суусан юм. Ер нь бол 2 өдрийн сургалт, дараа нь 2 дахь өдрийнхт нь сууна. Энэ сургалт нь “The Seven Habits of Highly Effective People” гэдэг номны дагуу явж байгаа юм. Дажгүй санагдсан болохоор сургалтан дээр ярьсан зүйлүүдийг жаахан сийрүүлье.

Эхлээд ямар хүн бусдын хүндлэлийг хүлээдэг талаар бичье. Ер нь хүн дараах 2 зүйлээс бүрднэ. Чадвар болон зан чанар. 2-уулаа сайн байхгүй бол, өөртэй чинь хамт ажиллах хүсэлтэй хүн төдий л олдохгүй л болов уу. Хичнээн чадвартай байлаа гээд, бусадтай аятайхан харьцаж чадахгүй бол, бусад хүмүүс аяндаа өөрөөс чинь зай бариад эхлэх болно.

За тэгээд тийм мундаг хүн болохын тулд юу хийх ёстой вэ?
Энгийн зүйлээс эхэлцгээе.

Өөрийн сонголтондоо хариуцлагатай байцгаая. Яг одоо өөрийн тань хийж байгаа зүйлүүд бол, ердөө л таны л сонголтын үр дүнгүүд юм. Та ажилдаа, эсвэл хамт ажилдаг хүмүүс, эсвэл үргэлж бүтэшгүй зүйлс өөрөөс чинь шаардах үйлчлүүлэгч нарт дургүй байлаа гэж бодъё. Энд нэг асуулт гарч ирнэ. “Ийм их дургүйг чинь хүргэх зүйлүүд байгаад байхад, яагаад одоогийн ажилтайгаа л зууралдаад байгаа юм бэ? Дургүй л юм бол, больчихож яагаад болохгүй гэж?” Энэ асуултын дараа, ихэнх хүмүүс, “цалингүй бол амьдарч чадахгүй”, “өөр ажил олдохгүй” гэх мэт шалтгаанууд хэлцгээнэ. “За тэгвэл, эцсийн эцэст, чи л өөрийнхөө асуудлаас болж, чи л ийм ажил хийх сонголтыг хийсэн бус уу?” гэсэн асуулт дахиад гарч ирнэ.

Өөрөөр хэлбэл, эцсийн эцэст та өөрөө л энэ замыг сонгосон болж таарна. Тийм болохоор, гомдоллох зүйлгүй өөрийнхөө сонголтонд хариуцлагатай бай.

Дараагийн зүйл бол, өөрийнхөө ертөнцийг харах нүдээ нээ. Мэдээж хүн бүрт ямарваа нэгэн зүйлийг харах өнцөг гэж бий. Харин амжилттай яваа хүмүүс, юмыг олон талаас нь харж сурсан байдаг байна. Хэн нэгэнтэй харьцахад хүндрэлтэй байсан бол, аливаа зүйлийг өөр өнцгөөс харж эхэлсэнээр, арай дээр харьцаж эхлэх ч юм билүү. Юмыг буруу зөв гэж тунгаахаасаа өмнө, өөр өнцгөөс харах гэж оролдож үзэж байсан уу?

Миний бодлоор, Монголд юмыг олон талаас нь хардаггүй хүмүүс их юм шиг санагддаг. Улс төрчид байна. Эсрэг намынх нь хийсэн бүх зүйл буруу, өөрсдийнх нь хийсэн бүх зүйл зөв гэсэн сонин бодолтой хүмүүс. Бас ижил хүйстэн болон, трансжендер хүмүүсийг учир зүггүй ам уралдан муулж суух хүмүүс. 21-р зуун болчихоод байна. 21-р зуун болсон болохоор, гэнэт энэ хүмүүсийн тоо нь ихсээд байгаа зүйл биш. 21-р зуун болоод, эдгээр хүмүүс нуугдах шаардлагагүй болж, дэлхийн олон улс эдгээр хүмүүст, бусадтай адил амьдрах эрхийг нь өгч эхэлж байна. Энэ хорвоо ертөнц зөвхөн таны сайн сайхны төлөө бүрэлдэн бий болоогүй гэдгийг санах ёстой байх. Бас гадаад иргэдийг зодоод яваад байдаг нөхдүүд байна. Юутай яаж тэмцэхээ мэддэггүй ч юм шиг санагддаг. Барилгийн Хятадуудыг оруулж ирдэг гол хүмүүстэй нь тэмцэхгүй байж, бас л нэг гэр орноо тэжээх гэж ирсэн хэдэн Хятадуудыг дарамталцгаана.

Дараагийн нэг зүйл бол амьдралын зорилготой байх. Та өөрийнхөө оршуулган дээр байна гэж төсөөлдөө. Таныг таниж мэдэх хүмүүс, урд гаран нэг нэгээрээ таны тухай дурсамжуудыг ярьж байна гэж төсөөл. Та тэр үед, хэн хэнийг урд гарч яриасай гэж хүсч байна? Тэдгээр хүмүүс юу яриасай гэж хүсч байна. Яг л тэдгээр хүмүүс, таны төсөөлсөн шиг зүйл ярихаар, амьдрахыг хичээгээрэй.

Өөр олон зүйл ярьсан ч, яг одоо толгой дотор хөвөрч байгаа нь энэ л байна. Чадвал, дараагийн өдрийн сургалтанд ярьсан зүйлийн талаар бас бичих болноо.

Тэгэхдээ эдгээр зүйлүүд нь, бид бүгд мэддэг ч, амьдралдаа төдийлөн хэрэгжүүлээд байдаггүй, энгийн зүйлүүд юм.

Эцэст нь дараах видеог зориулья.

If life were a painting, and you were the artist
What would you paint?
Which colors would you use?
Grey? Electric blue? Candy-apple red?
Is it a landscape? Is it a still life? A portrait of yourself? Your true love? Your most passionate hopes?
Would you hang it at the center of your home? Or at the center of your office?  Or at the center of your heart?
When others see it…
What will they remember?
Just lines on a canvas? Or a work of art?
This is your life.
Paint a bold picture.
Make it a masterpiece.
Sign your name.

Юуны өмнө, би мэргэжлийн хүн биш тул алдсан, эсвэл буруу ойлгосон зүйл байж магадгүй тул, засч залруулах зүйл байвал хэлж өгөөрэй.

Өчигдөр DNA-ын тухай нэвтрүүлэг үзлээ. DNA-д ойролцоогоор 3 тэрбум орчим base pair байдаг ба, тэдгээр нь бидний тухай бүх мэдээллийг агуулдаг юм байна. Сүүлийн үед тэдгээрийг уншиж тайлах туршилтууд маш ихээр явагдаж байгаа бөгөөд, ойрын ирээдүйд 1000$ төлөөд л DNA-ээ тэр чигээр нь бүрэн уншуулдаг цаг ирэх юм шиг байна. Эрүүл мэндийн салбарт ч бас DNA-г өргөнөөр ашиглаж байгаа юм байна. Тэгээд жишээ болгож 2 өвчтөний тухай гаргаж байна.

Эхнийх нь уушигны хорт хавдартай өвчтөн. Хавдар нь нэлээн хүнд шатандаа ороод зогсоо зайгүй ханиалгадаг болсон. Тэгээд эмч нь DNA-ын шинжилгээ хийж хавдар үүсгэж байгаа шалтгааныг нь тодруулаад, тэр шалтгааныг нь эмчлэх гэж оролдтол сарын дараа, ханиалгахаа больж, бас хавдар нь бараг байхгүй болсон байна.

2 дахь нь нэг жаахан хүүхэд. Хоол идэж чаддаггүй. Гэдэс нь цоорхой ч гэлүү дээ. Тэгээд эмч нар яаж ч судлаад ямар өвчин гэдгийг нь оношилж чадахгүй. Тэгээд тэр хүүхдийн DNA-г эрүүл хүний DNA-тэй харьцуулж үзсэн юм байна. Эрүүл хүнийхээс өөр байгаа цуваануудыг судлаад үзтэл XPC гэдэг gene нь тэр өвчнийг гол шалтгаан байж. Тэгээд тэр XPC рүү нь хандсан эмчилгээ хийтэл, хүүхэд эв эрүүл болсон байна.

Саяхан л гэхэд, алдар жүжигчин  Angelina Jolie, хөхний хорт хавдар тусах магадлалтай гээд хөхөө тайруулсан. Тэр магадлалыг тогтоохдоо BRCA гэдэг gene-ы тусламжтайгаар тогтоодог юм байна.

Тэгээд тэр нэвтрүүлгийн хөтлөгч залуу нь өөрийнхөө DNA-г https://www.23andme.com/ гэдэг site-аар шинжлүүлж байна. Энэ site-нь шүлснээс хүний DNA-г уншаад, 250 гаруй өвчний тусах магадлалыг гаргадаг юм байна. Дэлхийн хаанаас ч, нэг тусгай саванд шүлсээ хийгээд явуулахад л хангалттай. Оношилж байгаа арга нь, ямар нэгэн өвчтэй хүмүүсийн DNA-г цуглуулаад, тэдгээр хүмүүсийн DNA дахь хоорондоо төстэй, гэхдээ эрүүл хүнийхээс ялгаатай хэсгийг цуглуулж архив үүсгээд, тэгээд тэрэнтэйгээ харьцуулж магадлалыг гаргадаг юм байна.

Мэдээж хүмүүсийн дунд тусаагүй өвчнийхөө тусах магадлалыг мэдэж, сэтгэл санаагаар унаад яахав гэх хүмүүс олон байх. Харин эсрэгээрээ, тусах магадлалаа мэдээд, эртхэн амьдралынхаа хэмнэлийг өөрчлөөд, тусах магадлалаа багасгах нь бас нэгэн сонголт ч байж мэдэх юм.

Бас нээрээ Хятад-д DNA-ын шинжилгээгээр хүүхдүүдийн далд авъяасыг хэлж өгдөг үйлчилгээ нээгдсэн гэсэн.

Монголчууд бид, лам бөө нтр-ээс ирээдүйгээ асуух дуртай хүмүүс. DNA-ын шинжилгээ нь лам, бөө-ийн таамаглалаас арай дээр ч байж болох юм.

Ажил дээр жаахан завтай байсан болохоор, FQL(Facebook Query Language) ашиглан Facebook-ын өгөгдлийн сангаас найзуудынхаа мэдээлэлийг хайх талаар видео хичээл хийлээ.

720p(HD)-ээр үзэхгүй бол бичигнүүд нь харагдахгүй, бас анхан шатны хүмүүст зориулсан хичээл шүү, аймар аймар hacker-ууд нь орж ирээд муулаад байв.