Google Cloud (GCP)

01Մտածողության մոդելը՝ organization, project-ներ, region-ներ

GCP-ում ամեն ինչ պատկանում է որևէ project-ի։ Project-ը ռեսուրսների, billing-ի և թույլտվությունների «տարա» է․ պատկերացրու այն որպես շենքի մեկ բնակարան՝ իր բանալիներով և իր էլեկտրահաշվիչով։ Project-ները կարող են դրվել folder-ների մեջ organization-ի տակ, ինչը թույլ է տալիս ընկերությանը policy-ներ (օրինակ՝ «public bucket-ներ չլինեն») կիրառել բոլոր թիմերի վրա միանգամից։ Տարածված դասավորություն է՝ մեկ project յուրաքանչյուր միջավայրի համար՝ app-dev, app-staging, app-prod։ Դա staging-ի և production-ի միջև կոշտ պատ է տալիս, առանձին quota-ներ և հստակ հաշիվ յուրաքանչյուր միջավայրի համար։ Ռեսուրսները աշխատում են region-ում (europe-west1, us-central1) և երբեմն դրա ներսի zone-ում (europe-west1-b)։ Ընտրիր օգտատերերին մոտ region և հավելվածն ու նրա տվյալների բազան պահիր նույն region-ում, որովհետև region-ների միջև traffic-ը փող արժե և latency է ավելացնում։ AWS-ի համեմատ GCP project-ը մոտավորապես AWS account է, իսկ GCP organization-ը՝ մոտավորապես AWS Organizations։

• Organization → folder-ներ → project-ներ → ռեսուրսներ։
• Մեկ project յուրաքանչյուր միջավայրի համար ամենապարզ անվտանգ դասավորությունն է։
• Նույն region-ը հավելվածի և բազայի համար՝ ավելի ցածր latency, առանց inter-region egress-ի։

02Compute՝ Cloud Run, GKE թե Compute Engine

GCP-ն կոդ գործարկելու երեք հիմնական ձև է տալիս։ Compute Engine-ը սովորական վիրտուալ մեքենաներ են՝ VPS-ին ամենամոտ բանը․ OS-ը, patch-երը և process manager-ը կառավարում ես ինքդ։ GKE-ն managed Kubernetes է։ Standard ռեժիմում node-երի չափը որոշում և կառավարում ես դու, Autopilot ռեժիմում վճարում ես քո pod-երի պահանջած CPU-ի և հիշողության համար, իսկ node-երը Google-ն է կառավարում։ Cloud Run-ը դրանց վերևում է․ նրան տալիս ես container, որը լսում է PORT environment variable-ով, և ստանում ես HTTPS endpoint, autoscaling ըստ միաժամանակյա request-ների, revision-ներ և traffic splitting։ Cloud Run-ը գործարկում է նաև job-եր (batch task-եր, որոնք աշխատում են մինչև ավարտ), function-ներ (նախկինում Cloud Functions կոչվող արտադրանքն այժմ Cloud Run functions է) և worker pool-եր pull-based ֆոնային աշխատանքի համար։ Տիպիկ վեբ API-ի համար սկսիր Cloud Run-ից։ GKE-ին անցիր, երբ պետք են շատ service-ներ service mesh-ով, custom networking կամ երկարակյաց stateful workload-ներ, իսկ Compute Engine-ին՝ երբ պետք է մեքենայի լիարժեք վերահսկողություն։

03Container-ի deploy Cloud Run-ում

Ամենաարագ ճանապարհը թույլ տալն է, որ Cloud Run-ը source-ից build անի Cloud Build-ով և image-ը պահի Artifact Registry-ում (հին Container Registry-ն արդեն փակված է)։ Իրական project-ների համար image-ը build արա CI-ում, push արա Artifact Registry, ապա deploy արա հենց այդ image tag-ը։ Service-ին տուր իր սեփական service account-ը՝ միայն անհրաժեշտ role-երով, secret-ները պահիր Secret Manager-ում, իսկ Cloud SQL-ին միացիր ներկառուցված connector-ով։ Հիմնական flag-երը որոշում են արժեքն ու վարքը․ --min-instances-ը տաք instance-ներ է պահում (cold start-եր չկան, բայց դրանց համար վճարում ես), --max-instances-ը սահմանափակում է և՛ scale-ը, և՛ հաշիվը, իսկ --concurrency-ն որոշում է, թե մեկ instance-ը քանի request է միաժամանակ սպասարկում։ Node և PHP հավելվածները սովորաբար լավ են տանում շատ միաժամանակյա request-ներ, ուստի 80-ի default-ը խելամիտ սկիզբ է։

1gcloud config set project app-prod
2gcloud services enable run.googleapis.com artifactregistry.googleapis.com
3 
4gcloud run deploy api \
5  --image=europe-west1-docker.pkg.dev/app-prod/apps/api:1.4.2 \
6  --region=europe-west1 \
7  [email protected] \
8  --set-secrets=DATABASE_URL=database-url:latest \
9  --add-cloudsql-instances=app-prod:europe-west1:main-db \
10  --min-instances=0 --max-instances=10 \
11  --concurrency=80 --cpu=1 --memory=512Mi \
12  --allow-unauthenticated

04Տվյալներ՝ Cloud SQL, Firestore, Cloud Storage և BigQuery

Cloud SQL-ը managed PostgreSQL, MySQL կամ SQL Server է․ Google-ն է հոգում patch-երը, ավտոմատ backup-ները, point-in-time recovery-ն և ըստ ցանկության high availability՝ standby-ով այլ zone-ում։ Այն լինում է Enterprise և Enterprise Plus edition-ներով․ Plus-ը ավելի արագ failover և ավելի մեծ արտադրողականություն է տալիս՝ ավելի բարձր գնով։ AlloyDB-ն Google-ի Postgres-համատեղելի engine-ն է ավելի ծանր workload-ների համար։ Firestore-ը serverless document database է, որը հայտնի է mobile հավելվածներում։ Cloud Storage-ը ֆայլեր է պահում (upload-ներ, backup-ներ, static asset-ներ) bucket-ներում՝ storage class-ներով Standard-ից մինչև Archive։ BigQuery-ն տարբերվում է այս բոլորից․ այն columnar warehouse է analytics-ի համար, ոչ թե քո հավելվածի transaction-ների։ Event-ները բեռնում կամ stream ես անում դրա մեջ և SQL ես գործարկում հսկայական աղյուսակների վրա։ On-demand գնագոյացումը գանձում է ըստ scan արված terabyte-ի, ուստի լայն աղյուսակի վրա SELECT *-ը բառացիորեն թանկ է․ ընտրիր միայն անհրաժեշտ սյունակները և աղյուսակները partition արա ըստ ամսաթվի։

• Հավելվածի տվյալներ → Cloud SQL (կամ AlloyDB)։ Ֆայլեր → Cloud Storage։
• Analytics և հաշվետվություններ → BigQuery, որը սնվում է հավելվածից կամ export-ներով։
• Cloud SQL-ը free tier չունի․ նույնիսկ ամենափոքր instance-ը գանձվում է ամեն ժամ, քանի դեռ գոյություն ունի։

05IAM՝ ով ինչ կարող է անել

IAM-ը պատասխանում է մեկ հարցի․ որ principal-ը (օգտատեր, խումբ կամ service account) որ role-ն ունի որ ռեսուրսի վրա։ Role-երը թույլտվությունների փաթեթներ են, օրինակ՝ roles/run.invoker կամ roles/cloudsql.client։ Owner, Editor և Viewer basic role-երից խուսափիր ամեն ինչի համար, բացի փոքր փորձերից․ դրանք չափազանց լայն են։ Յուրաքանչյուր workload-ի տուր իր service account-ը և նրան predefined role-եր տուր հնարավոր ամենանեղ scope-ով՝ մեկ bucket կամ secret, ոչ թե ամբողջ project-ը։ GCP-ի անվտանգության ամենակարևոր կանոնը՝ մի ստեղծիր download արվող service account key-եր։ JSON key ֆայլը երկարակյաց գաղտնաբառ է, որը հայտնվում է repo-ներում և laptop-ներում։ Google Cloud-ում աշխատող կոդը credential-ները ավտոմատ ստանում է կցված service account-ից, իսկ CI համակարգերը, օրինակ GitHub Actions-ը, պետք է օգտագործեն Workload Identity Federation, որը կարճակյաց OIDC token-ը փոխանակում է Google credential-ների հետ։ Հենց այս պատճառով նոր organization-ներում key-երի ստեղծումը default-ով արգելված է policy-ով։

06Production խորհուրդներ և գնային թակարդներ

GCP-ն շատ բաների համար գանձում է վայրկյանով, ինչը հրաշալի է, մինչև որ աշխատում է մի բան, որի մասին մոռացել ես։ Առաջին իսկ օրը budget դիր alert-ներով (budget-ները զգուշացնում են, ծախսը չեն կանգնեցնում)։ Տարածված անակնկալները՝ Cloud SQL instance-ները գանձվում են շուրջօրյա, նույնիսկ երբ հավելվածը պարապ է, Cloud Run-ի min-instances-ը գանձվում է պարապ ժամանակ, Cloud NAT-ը և load balancer-ները ժամավճար ունեն, ինտերնետ egress-ը գանձվում է ըստ GB-ի, իսկ BigQuery on-demand query-ները՝ ըստ scan արված byte-երի, ուստի dashboard-ը, որը ամեն րոպե SELECT * է թարմացնում, կարող է ամբողջ հավելվածից թանկ արժենալ։ Logging-ը ևս մեկ թակարդ է․ Cloud Logging-ը գանձում է ingestion-ի համար անվճար սահմանից վեր, ուստի production-ում debug level-ով ամբողջական request body-ներ մի log արա։ Always-free tier-ը ծածկում է Cloud Run-ի, Cloud Storage-ի, BigQuery-ի և մեկ փոքր VM-ի փոքր օգտագործումը, իսկ նոր account-ները trial credit են ստանում, բայց կարդա սահմանները, նախքան դրանց վրա հույս դնելը։

07Cloud Run-ի ներսը՝ concurrency, CPU allocation և cold start-եր

Cloud Run-ը scale է լինում ըստ միաժամանակյա request-ների, ոչ միայն ըստ CPU-ի։ Եթե concurrency-ն 80 է, և 400 request ընթացքի մեջ է, այն ձգտում է մոտ հինգ instance-ի։ Յուրաքանչյուր instance աշխատում է gVisor-ի վրա հիմնված sandbox-ում (երկրորդ սերնդի execution environment-ը լիարժեք Linux համատեղելիություն և ավելի արագ CPU ու ցանց է տալիս)։ Billing-ը երկու ռեժիմ ունի։ Request-based billing-ը CPU-ի և հիշողության համար գանձում է միայն այն ժամանակ, երբ instance-ը request է սպասարկում, իսկ request-ների միջև CPU-ն throttle է արվում գրեթե մինչև զրո, ուստի timer-ները, queue consumer-ները և response-ից հետո «կրակիր ու մոռացիր» աշխատանքը կարող են պարզապես կանգ առնել։ Instance-based billing-ը (նախկինում «CPU always allocated») գանձում է instance-ի ամբողջ կյանքի համար՝ ավելի ցածր միավորի գնով, և թույլ է տալիս ֆոնային աշխատանք։ Cold start-երը գալիս են image-ը pull անելուց և runtime-ը բեռնելուց․ նվազեցրու դրանք փոքր image-ներով, lazy initialization-ով, startup CPU boost-ով և, որտեղ latency-ն կարևոր է, մեկ կամ երկու instance-ի նվազագույն քանակով։

1# Background-friendly service: instance billing + warm instance
2gcloud run services update worker-api \
3  --region=europe-west1 \
4  --no-cpu-throttling \
5  --cpu-boost \
6  --min-instances=1 \
7  --execution-environment=gen2

08Networking՝ VPC-ներ, private access և egress

GCP VPC-ն գլոբալ է․ մեկ ցանցը կարող է subnet-ներ ունենալ շատ region-ներում, ի տարբերություն AWS-ի, որտեղ VPC-ն region-ային է։ Cloud Run-ը default-ով քո VPC-ի ներսում չէ․ private ռեսուրսների (Cloud SQL private IP, Memorystore Redis, ներքին VM-ներ) հասնելու համար օգտագործիր Direct VPC egress, որը service-ը կցում է subnet-ին՝ առանց հին Serverless VPC Access connector VM-ների։ Դեպի ինտերնետ ելքային կանչերը, որոնք պետք է գան ֆիքսված IP-ից (partner allowlist-ներ), անցնում են Cloud NAT-ով՝ reserved հասցեով։ Private Service Connect-ը և Private Google Access-ը թույլ են տալիս workload-ներին հասնել Google API-ներին առանց public IP-ների։ Մուտքային traffic-ի համար գլոբալ external Application Load Balancer-ը տալիս է մեկ anycast IP, managed certificate-ներ, Cloud CDN և Cloud Armor (WAF և rate limiting)՝ Cloud Run-ի, GKE-ի կամ bucket-ների առջևում։ Այս մասերից յուրաքանչյուրն ունի իր ժամավճարը և GB-ի վճարը, ուստի traffic-ի ճանապարհը նկարիր, նախքան կառուցելը։

09Organization policy-ներ, audit log-եր և պաշտպանիչ սահմաններ

Ընկերության մասշտաբով կարևոր վերահսկողությունները project-ներից վեր են։ Organization policy constraint-ները կարող են արգելել service account key-երի ստեղծումը, ռեսուրսների տեղակայումը սահմանափակել որոշ region-ներով, արգելել public IP-ները VM-ների վրա, պարտադրել uniform bucket-level access և կանգնեցնել public sharing-ը։ Cloud Audit Logs-ը անվճար գրանցում է admin activity-ն և կարող է գրանցել data access-ը (լրացուցիչ վճարով) compliance-ի համար։ Զգայուն project-ները դիր VPC Service Controls-ի հետևում՝ տվյալների արտահոսքի ռիսկը նվազեցնելու համար․ նույնիսկ գողացված credential-ը չի կարող BigQuery dataset-ը պատճենել perimeter-ից դուրս project։ IAM binding-ներում օգտագործիր խմբեր, ոչ թե առանձին օգտատերեր, և grant-ները վերանայիր IAM Recommender-ով, որն առաջարկում է հեռացնել երբեք չօգտագործված թույլտվությունները։ Ենթակառուցվածքը պետք է լինի Terraform-ում՝ remote state-ով bucket-ում, որպեսզի ամեն փոփոխություն review արվի, ոչ թե console-ում click-ով արվի։