Google Cloud дээр энгийн бөгөөд алдаа багатай системийн архитектур зохиох нь

Архитектурын энгийн байдал яагаад чухал вэ?

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

Энэхүү нийтлэлээр бид Google Cloud Platform (GCP) дээр хэрхэн нарийн төвөгтэй байдлаас зайлсхийж, энгийн боловч өндөр найдвартай ажиллагаатай систем зохиох талаар авч үзэх болно. Та энэхүү нийтлэлийг уншсанаар удирдлагатай үйлчилгээнүүдийг (managed services) хэрхэн зөв уялдуулах, хэзээ ямар технологийн сонголт хийх, мөн өөрийн орчинд гарч болох эрсдэлүүдийг хэрхэн үнэлэх талаар тодорхой ойлголттой болох болно.

Найдвартай системийн суурь механик

GCP дээр алдаа багатай архитектур бүтээх гол нууц нь дэд бүтцийн удирдлагыг Google-д даатгаж, инженерийн баг зөвхөн бизнесийн логикт төвлөрөх боломжийг бүрдүүлэхэд оршино. Үүнийг амжилттай хэрэгжүүлэхийн тулд дараах хэд хэдэн үндсэн механикийг ойлгох шаардлагатай.

1. Төлөв хадгалдаггүй (Stateless) дизайн: Аппликэйшн нь хэрэглэгчийн session буюу түр зуурын мэдээллийг өөрийн санах ойд биш, харин гадны өгөгдлийн сан (жишээ нь Cloud SQL эсвэл Redis) дээр хадгалах ёстой. Энэ нь серверийг ямар ч үед унтрааж асаах, эсвэл ачаалал нэмэгдэхэд автоматаар хувилах (scale out) боломжийг олгодог.
2. Удирдлагатай үйлчилгээний давуу тал: Серверээ өөрөө тохируулах (Compute Engine) эсвэл Kubernetes кластер өөрөө удирдахын оронд Cloud Run, Cloud Functions, App Engine зэрэг Serverless үйлчилгээнүүдийг ашиглах нь үйлдлийн системийн шинэчлэл, сүлжээний тохиргооноос үүдэлтэй алдааг тэг хүртэл бууруулдаг.
3. Бие даасан архитектур (Decoupling): Системийн нэг хэсэг унахад нөгөө хэсэг нь дагаж унадаггүй байх ёстой. Үүний тулд шууд API дуудлага хийхийн оронд Pub/Sub гэх мэт мессеж дамжуулах үйлчилгээг ашиглаж, үйл явдалд суурилсан байдлаар мэдээлэл солилцох нь найдвартай байдлыг эрс нэмэгдүүлдэг.

Шалгарсан архитектурын загварууд

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

Загвар 1: Serverless Монолит (Cloud Run + Cloud SQL)

Шинээр эхэлж буй төслүүд болон дунд зэргийн ачаалалтай B2B системүүдэд хамгийн тохиромжтой загвар. Microservices рүү эрт үсрэх нь системийн төвөгтэй байдлыг нэмэгдүүлдэг тул эхний ээлжинд бүх логикоо нэг контейнэрт багтааж Cloud Run дээр байрлуулах нь ухаалаг сонголт юм.

• Хэрхэн ажилладаг вэ: Хэрэглэгчийн хүсэлт Cloud Load Balancing-ээр дамжин Cloud Run дээрх контейнэр руу орно. Өгөгдлийг Cloud SQL (PostgreSQL эсвэл MySQL) дээр хадгална.
• Давуу тал: Дэд бүтцийн удирдлага бараг шаардахгүй. Ачаалалгүй үед Cloud Run нь 0 хүртэл хумигдах тул зардал хэмнэнэ. Cloud Run-ийн архитектурын удирдамж нь энэхүү хандлагыг хэрхэн аюулгүй хэрэгжүүлэхийг дэлгэрэнгүй харуулдаг.

Загвар 2: Эвэнтд суурилсан систем (Pub/Sub + Cloud Run)

Системийн нэг хэсэгт үүссэн ачаалал эсвэл алдаа нь бүхэл системд нөлөөлөхөөс сэргийлэх үед энэ загварыг ашиглана.

• Хэрхэн ажилладаг вэ: Жишээлбэл, хэрэглэгч бүртгүүлэх үед үндсэн аппликэйшн нь бүртгэлийг баталгаажуулж, Pub/Sub руу "Хэрэглэгч бүртгүүлсэн" гэсэн мессеж илгээнэ. Цахим шуудан илгээх, аналитик хийх зэрэг бусад үйлдлүүд нь уг мессежийг хүлээн авч, тус тусдаа ажилладаг Cloud Functions эсвэл Cloud Run сервисүүдээр хийгдэнэ.
• Давуу тал: Хэрэв имэйл илгээх сервис түр унасан байсан ч, хэрэглэгч бүртгүүлэх үйлдэл хэвийн ажилласаар байх болно. Pub/Sub нь алдаа гарсан мессежийг дахин оролдох (retry) эсвэл `Dead-letter queue` рүү шилжүүлэх боломжтой бөгөөд энэ нь өгөгдөл алдагдахаас сэргийлдэг.

Загвар 3: Дэлхий даяарх өндөр хүртээмжтэй архитектур (Multi-region GKE/Cloud Run + Cloud Spanner)

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

• Хэрхэн ажилладаг вэ: Аппликэйшний контейнэрүүд нь дэлхийн олон өөр дата төвүүдэд (regions) байрлах ба дэлхий даяар түгээгдсэн Cloud Spanner өгөгдлийн санг ашиглана.
• Давуу тал: Бүхэл бүтэн нэг дата төв унасан ч систем хэвийн ажилласаар байна. Гэвч энэ загвар нь өртөг өндөртэй бөгөөд хөгжүүлэлтийн нарийн төвөгтэй байдлыг эрс нэмэгдүүлдэг.

Бодит хэрэглээний тохиолдлууд

Технологийн сонголтууд нь бодит бизнесийн шаардлагатай хэрхэн уялдахыг дараах тохиолдлуудаар тайлбарлая.

1. B2B SaaS платформ хөгжүүлэлт:
   
   Жижиг дунд байгууллагуудад зориулсан ERP эсвэл HR систем хөгжүүлж буй компаниуд эхний ээлжинд Cloud Run болон Cloud SQL ашиглан Serverless Monolith загварыг сонгох нь зүйтэй. Энэ нь шинэ функцүүдийг хурдан гаргах, турших боломжийг олгохоос гадна багийн инженерүүд Kubernetes зэрэг дэд бүтцийн хэрэгслүүдийг сурах гэж цаг алдахгүй байх давуу талтай.
2. Өгөгдөл боловсруулах автоматжуулалт:
   
   Санхүүгийн гүйлгээний тайлан эсвэл их хэмжээний лог мэдээлэл боловсруулдаг системийн хувьд Pub/Sub болон Dataflow эсвэл Cloud Run Job ашигласан загвар илүү тохиромжтой. Хэдэн сая бичлэг нэгэн зэрэг орж ирсэн ч Pub/Sub нь ачааллыг зөөлрүүлж (buffer хийх), систем хэт ачааллаас болж унахаас бүрэн сэргийлдэг.

Сул тал, эрсдэл болон хязгаарлалтууд

Ямар ч систем төгс биш байдаг. Удирдлагатай үйлчилгээнүүдийг ашиглахад үүсдэг эрсдэлүүд, тэдгээрийг хэрхэн хянах талаарх үнэлгээ:

• Cold Start: Cloud Run зэрэг Serverless үйлчилгээнүүд нь ачаалалгүй үед унтдаг бөгөөд шинэ хүсэлт ирэхэд контейнэрийг асаах хүртэл хэдэн секунд шаардагдах магадлалтай байдаг.

Шийдэл: Үүнээс сэргийлэхийн тулд `min-instances` тохиргоог ашиглан дор хаяж 1 эсвэл түүнээс дээш контейнэрийг үргэлж бэлэн байлгах шаардлагатай.

• Өгөгдлийн сангийн холболтын хязгаар (Connection limits): Cloud Run нь автоматаар маш олон хувилагдсан тохиолдолд Cloud SQL рүү хэт олон холболт үүсгэж, өгөгдлийн санг унагаах эрсдэлтэй.

Шийдэл: Connection pooling ашиглах, эсвэл Cloud SQL Auth Proxy зэргийг зөв тохируулах нь нэн чухал байдаг.

• Зардлын урьдчилан таамаглашгүй байдал: Хэрэглэсэн хэмжээгээрээ төлдөг (Pay-as-you-go) загвар нь эхэндээ хямд боловч, системд хязгааргүй давталт (infinite loop) үүсэх эсвэл гэнэтийн их хандалт ирэх үед зардлын огцом өсөлт үүсгэх эрсдэлтэй. Иймд зардлын хязгаарлалт (Budget alerts) болон ачааллын дээд хязгаар (Max instances) тогтоох нь зайлшгүй шаардлагатай алхам юм.

Шийдвэр гаргах шалгуурууд

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

Тооцоолох хүчин чадлын сонголт (Compute):

• Cloud Run сонгох: Баг хурдан ажиллах шаардлагатай, HTTP хүсэлтэд суурилсан (эсвэл Event-driven) систем хийх гэж байгаа бол. Үйлчилгээний 80% нь энд багтана.
• Google Kubernetes Engine (GKE) сонгох: Бусад үүлэн системүүд (AWS, Azure) эсвэл дотоод сервер (on-premise) рүү зөөх магадлалтай, эсвэл тусгай сүлжээний протоколууд ашигладаг, маш нарийн хяналт шаардлагатай үед.

Өгөгдлийн сангийн сонголт (Database):

• Cloud SQL: Уламжлалт SQL өгөгдлийн сан хэрэгтэй үед (ACID compliance шаарддаг санхүү, бүртгэлийн системүүд).
• Firestore: Бүтэц нь байнга өөрчлөгддөг, өндөр хурдтай унших шаардлагатай баримт бичигт суурилсан (Document-based) мэдээллийн санд тохиромжтой.
• Cloud Spanner: Хэрэглэгчийн тоо хэдэн саяар хэмжигдэж, мэдээллийн санг хуваах (sharding) шаардлага тулгарсан, гэхдээ харилцан хамааралтай (relational) мэдээллийн бүрэн бүтэн байдлыг хадгалах үед.

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

Найдвартай байдалд хүрэх замд инженерийн багуудын гаргадаг нийтлэг эрсдэлүүдээс хэрхэн хамгаалах вэ:

1. Дэд бүтцийг гараар тохируулах (ClickOps): Системийн архитектурыг GCP консол дээр хулганаар товшиж үүсгэх нь хүний алдаа гарах гол үндэс болдог. Үүний оронд Terraform гэх мэт Infrastructure as Code (IaC) хэрэгслийг ашиглаж, бүх тохиргоог код хэлбэрээр хадгалж, хувилбар хяналтанд (version control) оруулах нь найдвартай байдлын суурь юм.
2. Идемпотент бус (Non-idempotent) боловсруулалт: Түгээгдсэн системд нэг мессеж эсвэл хүсэлт хоёр ба түүнээс дээш удаа илгээгдэх тохиолдол гардаг (At-least-once delivery). Хэрэв таны систем нэг хүсэлтийг дахин боловсруулахдаа алдаа гаргадаг эсвэл өгөгдлийг давхар бичдэг бол ноцтой асуудал үүснэ. Код нь `Idempotent` шинж чанартай буюу нэг үйлдлийг хэдэн ч удаа давтан хийсэн үр дүн нь өөрчлөгддөггүй байх ёстой.
3. IAM (Identity and Access Management) зөвшөөрлийг хэт задгай өгөх: Сервисүүдэд шаардлагатайгаас илүү эрх олгох (жишээ нь, Editor эрхтэй Service Account ашиглах) нь аюулгүй байдлын цоорхой үүсгэдэг. Cloud Run сервис бүр өөрийн гэсэн, зөвхөн хэрэгцээт дата бааз руугаа л хандах хязгаарлагдмал эрх бүхий Service Account-тай байх ёстой.
4. Хяналт болон анхааруулгыг (Observability) орхигдуулах: Хэрэглэгчид алдааг олж харахаас өмнө танай баг мэдэх ёстой. GCP-ийн Cloud Logging болон Cloud Monitoring үйлчилгээг ашиглан зөвхөн серверийн CPU биш, харин хэрэглэгч рүү буцаж буй 500 зэрэглэлийн алдааны хувь хэмжээнд дохиолол (alert) тохируулах нь зүйтэй. Системийн найдвартай байдлын илүү дэлгэрэнгүй туршлагыг GCP-ийн найдвартай байдлын хүрээ гэсэн баримт бичгээс харж болно.

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

• Удирдлагатай үйлчилгээг (Managed Services) нэн тэргүүнд тавих: Дэд бүтцийн засвар үйлчилгээний ачааллыг үүлэн үйлчилгээ үзүүлэгч рүү шилжүүлэх нь танай багт бизнесийн үнэ цэнэ бүтээхэд анхаарах боломжийг олгоно.
• Энгийн байдлаас эхлэх: Ихэнх байгууллагуудад микросервисүүдийн нарийн төвөгтэй сүлжээ шаардлагагүй. Cloud Run болон Cloud SQL-ийн хослол нь төслийн 80-90 хувьд хангалттай бөгөөд алдаа гарах магадлалыг эрс бууруулна.
• Алдааг төлөвлөх: Сервер унана, холболт тасарна гэж тооцоолон архитектураа салгагдсан байдлаар (decoupled), мессежийн дараалал ашиглан зохион байгуулах.
• Дэд бүтцийг код хэлбэрээр удирдах: Гараар хийгдэх өөрчлөлтүүдийг зогсоож, Terraform гэх мэт хэрэгслүүдээр дамжуулан системийн өөрчлөлтийг урьдчилан таамаглах боломжтой, шалгах боломжтой болгох хэрэгтэй.