Google-ийн инженерчлэлийн архитектураас суралцъя

Програм хангамжийн хөгжүүлэлтийн багийг өргөжүүлэх нь зөвхөн олон инженер ажилд авах тухай асуудал биш юм. Багийн хэмжээ томрох тусам код бичих стандарт, алдааг илрүүлэх хурд, системийг хэрэглэгчдэд хүргэх (deployment) үйл явц улам бүр төвөгтэй болдог. Google компани хэдэн арван мянган инженерүүдтэйгээр өдөрт сая сая мөр код өөрчилж, тасралтгүй deployment хийж чаддаг нь тэдний инженерчлэлийн соёл, дотоод үйл ажиллагааны хатуу зарчмуудтай холбоотой.

Энэхүү нийтлэл нь технологийн удирдлагууд (CTO), үүсгэн байгуулагчид болон ахлах инженерүүдэд зориулагдсан бөгөөд Google-ийн код бичих хэв маяг, алдаа хайх (debugging) болон автомат deployment хийх процессуудын үндсэн механикуудыг тайлбарлах болно. Ингэснээр та өөрийн байгууллагад аль туршлагыг нь нэвтрүүлж, ямар алдаанаас зайлсхийх хэрэгтэйгээ шийдвэрлэхэд туслах суурь мэдлэгийг авах болно.

Код хөгжүүлэлт ба хамтын ажиллагааны загвар

Google-ийн код хөгжүүлэлтийн хамгийн том онцлог бол тэдний код хадгалах архитектур болон кодын чанарыг хянах процессууд юм.

Нэгдсэн репозитор (Monorepo)

Google нь дэлхийн хамгийн том monorepo (нэгдсэн код хадгалах сан) ашигладаг компаниудын нэг юм. Энэ нь компанийн бараг бүх төслийн код нэг дор, нэг системд (дотооддоо `Piper` гэж нэрлэдэг) хадгалагддаг гэсэн үг.

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

Trunk-based Development (Гол салбарт суурилсан хөгжүүлэлт)

Инженерүүд код бичихдээ урт хугацаанд үргэлжлэх feature branch (тусгаарласан салбар) үүсгэхээс татгалздаг. Үүний оронд кодоо байнга, жижиг хэсгүүдээр шууд үндсэн салбар (trunk/main) руу оруулдаг. Ингэснээр багууд хоорондын кодын асуудал (merge conflict) үүсэх эрсдэлийг эрс бууруулж, тасралтгүй интеграци (CI) хийх боломжийг бүрдүүлдэг.

Readability: Кодын стандарт ба хяналт

Google-д Code Review буюу код хянах үйл явц нь зөвхөн алдаа хайх биш, харин тухайн хэлний стандартыг мөрдүүлэхэд чиглэдэг. Үүнийг Readability үйл явц гэж нэрлэдэг. Инженер бүр тухайн програмчлалын хэл дээр (жишээ нь C++, Java, Go) код бичихдээ байгууллагын стандартыг хэрхэн дагаж байгаагаа батлан харуулж, тусгайлан баталгаажсан инженерүүдээс (Readability reviewers) зөвшөөрөл авах шаардлагатай.

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

Тест ба алдааг илрүүлэх механик

Алдааг илрүүлэх хамгийн сайн арга бол түүнийг хэрэглэгчдэд хүрэхээс нь өмнө зогсоох явдал юм. Google-ийн хувьд тест бол хөгжүүлэлтийн салшгүй нэг хэсэг.

Hermetic Builds (Тусгаарлагдсан тест болон угсралт)

Аливаа тест эсвэл кодын build хийх үйл явц нь гадны сүлжээ, өгөгдлийн сан, эсвэл тухайн инженерийн компьютер дээрх орчноос хамааралгүй байх ёстой. Үүний тулд Google Bazel build system-ийг (дотооддоо Blaze) ашигладаг.

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

Flaky Tests (Тогтворгүй тесттэй тэмцэх нь)

Заримдаа амжилттай болж, заримдаа алдаа заадаг тестүүдийг flaky tests гэдэг. Google-ийн хувьд тогтворгүй тест нь тестгүй байхаас ч дор гэж үздэг. Учир нь энэ нь хөгжүүлэгчдийн системд итгэх итгэлийг устгадаг. Ийм тест илэрвэл систем автоматаар тусгаарлаж гол хөгжүүлэлтийн процест саад учруулахгүйгээр алгасах бөгөөд хариуцсан багт нь засах даалгавар болгон очдог.

Shift-Left хандлага

Алдааг хөгжүүлэлтийн үе шатны аль болох эхэнд илрүүлэх стратегийг баримталдаг. Code review хийгдэхээс өмнө автомат статик анализууд болон unit тестүүд ажиллаж, кодын чанар, аюулгүй байдлын эмзэг байдлуудыг автоматаар шалгадаг.

Автоматжуулсан production deployment процесс

Код бичигдэж, шалгагдаж дууссаны дараа хэрэглэгчдэд хүргэх процесс нь хүний оролцоогүйгээр, аюулгүй явагдах ёстой.

Release Engineering: Бие даасан сахилга бат

Google-д Release Engineering бол зүгээр нэг үйлдэл биш, тусдаа мэргэшсэн инженерийн салбар юм. Програм хангамжийг хэрхэн угсрах, хэрхэн багцлах, хэрхэн production орчинд нэвтрүүлэх нь нарийн тодорхойлогдсон кодоор (Infrastructure as Code) хийгддэг. Энэ талаарх дэлгэрэнгүй зарчмуудыг Google SRE practices сангаас судлах боломжтой.

Progressive Rollouts ба Canary Deployments

Шинэ хувилбарыг бүх хэрэглэгчдэд нэгэн зэрэг хүргэх нь дэндүү өндөр эрсдэлтэй. Иймд Canary deployment буюу дэс дараатай нэвтрүүлэлт хийдэг:

1. Эхний үе шат: Шинэ хувилбарыг зөвхөн дотоод ажилчид эсвэл нийт хэрэглэгчдийн 1%-д харуулна.
2. Хяналт ба баталгаажуулалт: Тодорхой хугацаанд (жишээ нь 1 цаг) шинэ хувилбар дээр алдааны хувь (error rate), хариу өгөх хурд (latency) зэрэг хэмжүүрүүдийг (SLIs) ажиглана.
3. Өргөжүүлэх: Хэрэв бүх зүйл хэвийн бол 10%, 50%, эцэст нь 100% руу шилжүүлнэ.

Энэхүү процесс нь бүрэн автоматжсан байх бөгөөд хэрэв аль нэг шатанд алдаа гарвал систем автоматаар өмнөх хувилбар руу буцдаг.

Алдааны төсөв (Error Budgets) ба Deployment хурд

Deployment хурдыг хэзээ нэмэгдүүлж, хэзээ царцаах вэ гэдгийг Site Reliability Engineering (SRE) зарчмын дагуу Алдааны төсөв-өөр шийддэг. Тухайн үйлчилгээ хэрэглэгчдэд амласан найдвартай байдлын зорилтоо (SLO) хангаж байвал хөгжүүлэлтийн баг дуртай үедээ шинэ боломжуудыг нэвтрүүлж (deploy хийж) болно. Харин алдаа их гарч төсвөө барвал, системийг тогтворжуулах хүртэл бүх deployment-ийг автоматаар царцаадаг.

Архитектурын сонголт ба эрсдэлүүд

Google-ийн энэхүү арга барил нь бүх байгууллагад шууд тохирохгүй. Технологийн удирдагчид дараах давуу тал болон хязгаарлалтуудыг харгалзан үзэх хэрэгтэй.

• Monorepo vs Polyrepo (Олон салангид репозитор): Monorepo нь кодын хамаарлыг шийддэг ч маш сайн автоматжуулсан тест болон build систем шаарддаг. Тусгай зориулалтын хэрэгсэлгүйгээр (жишээ нь Bazel-ийг зөв тохируулахгүйгээр) monorepo руу шилжих нь хөгжүүлэлтийн хурдыг эрс удаашруулж, `git clone` хийх хугацааг утгагүй урт болгох эрсдэлтэй.
• Хэрэгсэл хөгжүүлэлтийн зардал: Google өөрийн дотоод системүүдийг хөгжүүлэхэд мянга мянган инженерүүдийг зориулдаг. Дунд хэмжээний компаниуд энэ замаар явахын оронд GitHub Actions, GitLab CI зэрэг бэлэн үүлэн шийдлүүдийг ашиглаж, өөрийн орчинд тохируулах нь илүү прагматик алхам юм.
• Төвөгтэй дэд бүтэц: Canary deployment хийхийн тулд систем тань микросервис архитектуртай байх эсвэл load balancer түвшинд урсгалыг нарийн хуваарилах боломжтой байх шаардлагатай (жишээ нь Kubernetes + Istio эсвэл үүнтэй төстэй технологи).

Шийдвэр гаргах шалгуур ба харьцуулалт

Та өөрийн багийн хэмжээ болон системийн шаардлагад тулгуурлан дараах байдлаар технологийн сонголтоо хийх боломжтой:

Эхлэлтийн шат (Startups, 1-15 инженер):

• Код: Энгийн GitHub/GitLab орчин. Гол салбар руу хурдан нийлүүлэх.
• Тест: Стандарт Unit test болон энгийн CI/CD pipeline.
• Deployment: Шууд deployment эсвэл энгийн Blue/Green солилт. Canary rollout хийх нь хэтэрхий их инженерийн цаг үрнэ.

Өсөлтийн шат (Scale-ups, 20-100 инженер):

• Код: Кодын стандарт, Readability зарчмуудыг багийн соёлд нэвтрүүлж эхлэх.
• Тест: Тестийн хамралтыг нэмэгдүүлж, тусгаарлагдсан орчинд (container) тестлэх.
• Deployment: Автоматжуулсан rollback, энгийн canary rollout.

Томоохон байгууллагууд (Enterprises, 100+ инженер):

• Код: Шаардлагатай бол Monorepo архитектур луу шилжих, Bazel мэт ухаалаг build system ашиглах.
• Тест: Тогтворгүй тестийг (flaky tests) автоматаар удирдах систем хэрэгжүүлэх.
• Deployment: SRE зарчмаар SLO-д тулгуурласан бүрэн автомат прогрессив deployment хийх.

Нийтлэг алдаанууд ба түүнээс зайлсхийх нь

Ахлах инженерүүд болон CTO нар Google-ийн туршлагыг хуулбарлах гэж оролдохдоо зарим нийтлэг алдаануудыг гаргадаг:

• Cargo-culting буюу сохроор хуулбарлах: "Google ингэж хийдэг юм чинь бид ч бас ингэх ёстой" гэх хандлага. Байгууллагынхаа хэрэгцээнд нийцээгүй хэт нүсэр систем нэвтрүүлэх нь зардлыг нэмэгдүүлнэ.
• Тестийн хурдыг үл тоомсорлох: CI процесс 10 минутаас дээш хугацаа шаардаж эхэлбэл хөгжүүлэгчид кодоо тогтмол нийлүүлэхээс төвөгшөөж эхэлдэг. Тест хурдан байх ёстой.
• Хагас автоматжуулсан deployment: Процессын дунд хүний баталгаажуулалт шаардах нь автоматжуулалтын гол давуу талыг устгадаг. Үүний оронд тестийн хамралт болон хяналтын системдээ итгэх хэрэгтэй.

Гол дүгнэлтүүд

Google-ийн дотоод туршлага нь асар том хэмжээнд ажиллахаар загварчлагдсан байдаг хэдий ч, тэдний баримталдаг суурь зарчмуудыг ямар ч хэмжээний багт тохируулан хэрэглэх боломжтой.

• Хуваалцах соёлыг бий болгох: Код бол хувь хүний өмч биш, компанийн өмч. Нэгдсэн стандарттай (Readability) байх нь урт хугацааны засвар үйлчилгээний зардлыг бууруулдаг.
• Хурд бол итгэлцлийн үр дүн: Тусгаарлагдсан (hermetic) бөгөөд хурдан ажилладаг тестийн орчин нь багт өөрчлөлтөө айдасгүйгээр хийх итгэлийг өгдөг.
• Алдааг хүлээн зөвшөөрч, автоматжуул: Програм хангамж хэзээ нэгэн цагт алдаа гаргана. Хамгийн чухал нь алдааг гарахаас 100% сэргийлэх биш, алдаа гарсан үед систем автоматаар зогсоож, буцааж (automated rollback) чаддаг байх явдал юм.
• Багаж хэрэгсэлд хөрөнгө оруул: Багийн хэмжээ өсөхийн хэрээр дотоод хөгжүүлэгчдийн туршлагад (Developer Experience) анхаарч, CI/CD болон автоматжуулалтын дэд бүтцийг сайжруулахад тусгайлан цаг, нөөц хуваарилах нь зайлшгүй шаардлагатай.