Google Cloud руу хэрхэн зардал багатай, өндөр ашигтай шилжих вэ?

Шилжилтийн хүрээ ба удирдлагын түвшний шийдвэрүүд

Уламжлалт дата төвөөс Google Cloud Platform (GCP) руу шилжих нь байгууллагын хувьд зөвхөн серверийн байршлаа солих үйл явц биш бөгөөд энэ нь технологийн үйл ажиллагааны загвар, зардлын бүтэц, инженерийн багийн соёлд бүхэлд нь нөлөөлөх стратегийн шийдвэр юм. Технологийн удирдлагууд (CTO), үүсгэн байгуулагчид болон ахлах инженерүүдийн хувьд хамгийн том сорилт нь системийг ажиллагаатай байлгах бус, харин төсвийн хэтрэлт үүсгэхгүйгээр үүлэн технологийн жинхэнэ давуу талыг хэрхэн ашиглах вэ гэдэгт оршдог.

Энэхүү нийтлэл нь үүлэн дэд бүтцийн зардлын механизмуудыг хэрхэн зөв удирдах, хуучин архитектурыг шинэчлэхэд гарах эрсдэлүүдийг хэрхэн тооцоолох, мөн шилжилтийн үед ямар архитектурын загварууд хамгийн оновчтой байдгийг тайлбарлах болно. Уншсаны дараа та хөрөнгийн зардал (CAPEX)-аас үйл ажиллагааны зардал (OPEX) руу шилжих үеийн эрсдэлийг хэрхэн бууруулах, инженерүүд тань систем хөгжүүлэхдээ үнийн оновчтой шийдвэр хэрхэн гаргах ёстойг тодорхой ойлгох болно.

Үүлэн технологийн зардлын механизмууд

Google Cloud дээрх зардал нь уламжлалт дата төвөөс эрс ялгаатай механизмаар тооцогддог. Он-премис (on-premise) орчинд та хамгийн өндөр ачаалалд зориулж серверийн хүчин чадлыг урьдчилан худалдан авдаг бол үүлэн орчинд хэрэглэсэн хэмжээгээрээ (pay-as-you-go) төлдөг. Гэхдээ энэхүү уян хатан байдал нь хяналтгүй орхивол асар өндөр төлбөр болон хувирах эрсдэлтэй.

Зардлыг хянах үндсэн механизмууд нь дараах байдалтай байна:

• Тооцооллын нөөцийн хямдрал (Committed Use Discounts - CUD): Хэрэв та тодорхой хэмжээний тооцооллын нөөцийг (CPU, RAM) 1 эсвэл 3 жилийн хугацаанд тогтмол ашиглахаа амлавал төлбөрөө 50-70% хүртэл хэмнэх боломжтой. Энэ нь суурь ачааллыг даах виртуал машинуудад (VM) нэн тохиромжтой.
• Хугацаатай машинууд (Spot/Preemptible VMs): Google-ийн сул байгаа нөөцийг ашигладаг бөгөөд энгийн VM-ээс 60-91% хямд байдаг. Гэхдээ Google хэзээ ч хамаагүй 24 цагийн дотор эсвэл шууд унтраах эрхтэй байдаг тул зөвхөн төлөв хадгалдаггүй (stateless), тасалдлыг даах чадвартай өгөгдөл боловсруулах процессуудад ашиглах нь зүйтэй.
• Өгөгдөл хадгалах сангийн шатлал (Storage Tiers): Cloud Storage нь Standard, Nearline, Coldline, Archive гэсэн шатлалтай. Байнга ханддаг өгөгдлийг Standard дээр, харин жилд нэг л удаа ханддаг нөөцлөлт (backup) зэргийг Archive дээр байрлуулснаар хадгалалтын зардлыг арав дахин бууруулах боломжтой.
• Сүлжээний урсгал ба харьяалал: Үүлэн орчинд өгөгдөл оруулах (Ingress) үнэгүй боловч өгөгдөл гадагшлуулах эсвэл бүс нутаг хооронд дамжуулах (Egress) нь өндөр үнэтэй байдаг. Үүнийг тооцоолохгүй байх нь зардлын хамгийн том цоорхой үүсгэдэг.

Архитектурын сонголт ба шилжилтийн загварууд

Дэд бүтцийг шилжүүлэх үед архитектурын ямар шийдэл сонгохоос хамаарч үйл ажиллагааны зардал болон инженерийн хөдөлмөр ихээхэн ялгаатай байна. Google Cloud шилжилтийн архитектурын удирдамж-д эдгээр загваруудыг нарийвчлан тайлбарласан байдаг бөгөөд бодит байдал дээр дараах 3 үндсэн хандлага байна.

1. Шууд хуулах (Lift and Shift / Rehosting)

Байгууллагын одоогийн системүүдийг ямар ч өөрчлөлтгүйгээр Google Compute Engine (VM) дээр хуулж байрлуулах арга.

• Давуу тал: Хурдан хугацаанд, эрсдэл багатайгаар дата төвөөс гарах боломж олгоно.
• Сул тал: Үүлэн технологийн уян хатан байдлыг ашиглаж чадахгүй тул урт хугацаандаа хамгийн өндөр зардалтай сонголт болдог. Он-премис дээрх сул зогсолт (idle resources) үүлэн орчинд шууд мөнгө болон урсана.

2. Платформын шинэчлэл (Replatforming)

Програм хангамжийн үндсэн кодыг өөрчлөхгүйгээр, дэд бүтцийн зарим хэсгийг Google Cloud-ийн удирдлагатай үйлчилгээнүүд (Managed Services) рүү шилжүүлэх. Жишээлбэл, өөрсдөө виртуал машин дээр асаасан MySQL өгөгдлийн санг Cloud SQL руу шилжүүлэх.

• Давуу тал: Үйл ажиллагааны зардал (асаах, унтраах, нөөцлөх, шинэчлэх) эрс багасна. Хөрөнгө оруулалтын өгөөж (ROI) хамгийн хурдан гардаг загвар.
• Сул тал: Тохиргооны зарим хязгаарлалтууд гарч болзошгүй бөгөөд хуучин систем нь удирдлагатай үйлчилгээний шаардлагад нийцэхгүй байх тохиолдол гарна.

3. Үндсээр нь өөрчлөх (Refactoring / Cloud-Native)

Програм хангамжийн кодыг Microservices эсвэл Сервергүй (Serverless) архитектурт зориулан дахин бичих арга. Ачааллаас хамаарч өөрөө сунаж, агшдаг Google Kubernetes Engine (GKE) эсвэл Cloud Run зэрэг үйлчилгээнүүдийг ашиглана.

• Давуу тал: Урт хугацаандаа дэд бүтцийн зардал хамгийн оновчтой байна. Систем хэрэглээгүй үед зардал `тэг рүү буух` (scale to zero) боломжтой.
• Сул тал: Хөгжүүлэлтийн асар өндөр өртөг шаардах бөгөөд багийн ур чадвар шинэчлэгдэх шаардлагатай болно.

Бодит хэрэглээний орчин ба нөхцөл байдал

Технологийн шийдвэр нь ямар төрлийн ачаалалтай (workload) ажиллаж байгаагаас бүрэн хамаарна. Түгээмэл хэрэглэгддэг орчны жишээнүүдийг авч үзье.

Өгөгдлийн аналитик ба тайлангийн системүүд: Уламжлалт дата төвд байрлах Hadoop эсвэл том хэмжээний өгөгдлийн агуулахыг виртуал машин руу хуулах нь санхүүгийн хувьд маш үр ашиггүй. Үүний оронд Google BigQuery рүү шилжүүлэх нь хамгийн зөв сонголт байдаг. BigQuery-ийн салангид архитектур нь тооцоолол болон хадгалалтын нөөцийг салгасан байдаг тул та зөвхөн хадгалсан өгөгдлийнхөө хэмжээгээр, мөн ажиллуулсан query (хүсэлт)-ийн хэмжээгээр төлбөр төлнө. Олон сая бичлэгтэй өгөгдөл дээр өдөрт ганц удаа тайлан уншуулдаг бол байнга асаалттай сервер тэжээх шаардлагагүй болно.

Хэлбэлзэл ихтэй вэб хэрэглүүр ба API-ууд: Маркетингийн урамшуулал эсвэл баярын өдрүүдэд огцом ачаалал авдаг, бусад үед тайван байдаг цахим худалдааны сайтуудын хувьд Compute Engine ашиглах нь хэт их нөөц түгжих эрсдэлтэй. Ийм системүүдийг контайнер (Container) технологид суурилан савлаж, Cloud Run дээр байрлуулснаар хэрэглэгчийн хандалт орж ирэх үед л тооцоолол хийгдэж мөнгө тооцогдох, хандалтгүй үед систем автоматаар унтрах уян хатан нөхцөлийг бүрдүүлдэг.

Эрсдэл, хязгаарлалт ба анхаарах зүйлс

Зардал багатай шилжилт хийхээр төлөвлөхөд дараах технологийн эрсдэлүүд болон хязгаарлалтуудыг сайтар тооцоолох ёстой.

1. Сүлжээний гарах урсгалын (Egress) төлбөр: Олон компаниуд үүлэн орчин руу орох өгөгдөл үнэгүй байдгийг мэддэг ч, систем хооронд өгөгдөл солилцох үед үүсэх зардлыг дутуу үнэлдэг. Хэрэв таны өгөгдлийн сан Google Cloud дээр (Region A), харин аппликэйшн сервер тань өөр дата төвд эсвэл AWS дээр байгаа бол интернэтээр дамжих өгөгдлийн мегабайт бүрээр төлбөр бодогдоно. Системийн хамаарал бүхий бүрэлдэхүүн хэсгүүдийг нэг бүс дотор (Zone) байрлуулах нь энэ эрсдлээс сэргийлнэ.
2. Үүлэн системээс хэт хамааралтай болох (Vendor Lock-in): Google Cloud-ийн зөвхөн өөрсдөд нь байдаг онцгой үйлчилгээнүүдийг (жишээ нь Cloud Spanner, Datastore) ихээр ашиглах нь хөгжүүлэлтийн хурдыг нэмэх боловч ирээдүйд өөр үүлэн систем рүү шилжихэд ихээхэн саад болно. Хэрэв энэ эрсдэлээс сэргийлэхийг хүсвэл нээлттэй эхэд суурилсан, стандартын дагуу ажилладаг үйлчилгээнүүдийг (Cloud SQL, GKE) сонгох нь зүйтэй.
3. Програм хангамжийн лицензийн зардал: Хэрэв та Microsoft SQL Server эсвэл Oracle мэдээллийн сан ашигладаг бол лицензийн нөхцөлөө эргэн харах шаардлагатай. Үүлэн орчинд шилжих үед зарим лицензүүд виртуал CPU (vCPU)-ийн тооноос хамаарч огцом өсөх магадлалтай тул Bring Your Own License (BYOL) боломжийг судлах эсвэл нээлттэй эхийн шийдэл (PostgreSQL) рүү шилжих платформын шинэчлэл хийх шаардлагатай.

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

Инженерийн баг шинэ систем нэвтрүүлэх эсвэл хуучин системийг шилжүүлэхдээ тодорхой шалгуур үзүүлэлтүүд дээр үндэслэж архитектураа сонгох ёстой. Дараах харьцуулалт нь удирдлагын түвшинд шийдвэр гаргахад тусална.

• Виртуал машин (Compute Engine):
  • Тохиромжтой байдал: Хуучин (legacy) системүүд, яг одоогийн үйлдлийн системийн түвшний тохиргоо шаарддаг архитектурууд.
  • Зардлын онцлог: Байнга асаалттай байх тул сул зогсолтын зардал өндөр. CUD ашиглаж зардлаа хянах боломжтой.
  • Үйл ажиллагааны ачаалал: Хамгийн өндөр. Үйлдлийн системийн шинэчлэл, аюулгүй байдлын нөхөөс (patch)-ийг инженерүүд өөрсдөө хийнэ.
• Удирдлагатай үйлчилгээ (Managed Services - жишээ нь Cloud SQL, Memorystore):
  • Тохиромжтой байдал: Өгөгдлийн сангууд, кэш (cache) серверүүд.
  • Зардлын онцлог: Суурь VM-ээс арай өндөр үнэтэй ч, мэдээллийн сангийн админы (DBA) ажлын цагийг хэмнэх тул нийт зардал (TCO) багасдаг.
  • Үйл ажиллагааны ачаалал: Дунд зэрэг. Нөөцлөлт болон хувилбарын шинэчлэлийг Google хариуцна.
• Сервергүй тооцоолол (Serverless - Cloud Run, Cloud Functions):
  • Тохиромжтой байдал: Бичил үйлчилгээ, эвентэд суурилсан архитектур, вэб API.
  • Зардлын онцлог: Хэрэглээгүй үед 0₮ зардалтай. Зөвхөн ачааллын үед л төлбөр гарна.
  • Үйл ажиллагааны ачаалал: Хамгийн бага. Зөвхөн код болон бизнесийн логикдоо анхаарах боломжтой.

Нийтлэг алдаанууд болон тэдгээрээс сэргийлэх нь

Олон байгууллагууд үүлэн технологи руу шилжих эхний жилдээ төсвөө 30-40%-иар хэтрүүлэх алдаа гаргадаг. Туршлагатай багууд дараах нийтлэг алдаануудаас зайлсхийдэг:

1. Хуучин дата төвийн сэтгэлгээгээр хандах: Он-премис орчинд сервер худалдан авахдаа ирээдүйн 5 жилийн хамгийн өндөр ачааллыг (peak capacity) тооцож авдаг. Энэ сэтгэлгээгээр үүлэн орчинд VM үүсгэвэл асар их нөөц хий дэмий унана. Үүний оронд Google Cloud-ийн санал болгодог `Хүчин чадлыг оновчлох (Right-sizing)` зөвлөмжүүдийг анхааралтай дагаж, зөвхөн яг одоо хэрэгтэй байгаа CPU/RAM-тай машин үүсгээд, хэрэгцээ гарах үед автоматаар өсгөх (autoscaling) тохиргоо хийх ёстой.
2. Эзэнгүй үлдсэн нөөцүүд буюу "Зомби" дэд бүтэц: Хөгжүүлэгчид туршилт хийхээр сервер асаагаад унтраахаа мартах, эсвэл серверийг унтраасан ч түүнд холбоотой байсан хатуу диск (Persistent Disk) болон гадаад IP хаягийг салгаж устгахгүй орхих нь байнга зардлын урсгал үүсгэдэг. Энэхүү эрсдэлээс сэргийлэхийн тулд байгууллагын түвшинд нөөцийн шошгололт (Resource Labeling) стандартыг хэрэгжүүлж, хэний, ямар төслийн сервер болохыг тодорхой зааж өгөх хэрэгтэй.
3. Буруу бүс нутаг (Region) сонгох: Google Cloud-ийн байршлаас хамаарч үйлчилгээнүүдийн үнэ харилцан адилгүй байдаг. Жишээ нь `us-central1` (АНУ) бүс нь `europe-west4` (Европ) эсвэл `asia-northeast1` (Япон) бүсээс харьцангуй хямд үнэтэй байдаг. Өгөгдөл хамгааллын хуулийн хатуу зохицуулалтгүй, хоцрогдлын (latency) хувьд мэдрэг бус системүүдийг хямд бүсэд байрлуулснаар зардлыг шууд хэмнэх боломжтой.
4. Төсвийн дохиолол (Billing Alert) тохируулахгүй байх: Инженерүүд шинэ технологи турших эсвэл кодны алдаанаас (жишээ нь төгсгөлгүй давталт Cloud Function дээр үүсэх) болж хэдхэн цагийн дотор мянга мянган долларын төлбөр үүсэх эрсдэлтэй байдаг. Үүлэн орчны архитектурын хамгийн эхний алхам бол төслийн түвшинд зардлын хязгаар болон дохиолол тохируулах явдал юм.

Үндсэн дүгнэлт ба дараагийн алхмууд

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

• FinOps соёлыг төлөвшүүлэх: Зардал гэдэг нь зөвхөн санхүүгийн хэлтсийн асуудал биш, хөгжүүлэгч болон DevOps инженер бүрийн хариуцлага байх ёстой. Архитектурын шийдвэр бүр зардлын үнэлгээтэй хамт хийгдэх ёстой.
• Шилжилтийг үе шаттайгаар төлөвлөх: Шууд 100% шинэчлэл (refactoring) хийх гэж оролдох нь төслийг зогсооход хүргэдэг. Эхний ээлжинд эрсдэл багатай бүрэлдэхүүнүүдийг удирдлагатай үйлчилгээ (Managed service) рүү шилжүүлж, аажмаар цөм системүүдээ үүлэн орчинд зориулан хөгжүүлэх (cloud-native) стратегийг баримтлах.
• Зардлын аналитикийг автоматжуулах: Google Cloud-ийн төлбөрийн дэлгэрэнгүй мэдээллийг BigQuery рүү автоматаар экспортлох тохиргоог хийж, үйлчилгээ тус бүрээр нь хяналтын самбар (Dashboard) үүсгэн тогтмол хянах.
• Автоматжуулалтад хөрөнгө оруулах: Infrastructure as Code (IaC) буюу Terraform зэрэг хэрэгслийг ашиглан дэд бүтцээ удирдах нь алдааг бууруулж, илүүдэл нөөц үүсэхээс сэргийлэн, системийг устгаж дахин асаах үйл явцыг хурдасгаснаар зардлыг үлэмж хэмжээгээр хэмнэнэ.