14 KiB
14 KiB
☁️ Cloud architektura
Poskytovatelé
- AWS — největší tržní podíl, nejširší portfolio
- Azure — silná integrace s Microsoft ekosystémem
- GCP — Kubernetes (GKE), data & ML, síťová konektivita
Modely nasazení
| Model | Popis |
|---|---|
| Public cloud | Sdílená infrastruktura poskytovatele |
| Private cloud | Vyhrazená infrastruktura (on-prem nebo hosted) |
| Hybrid cloud | Propojení public + private |
| Multi-cloud | Více veřejných poskytovatelů |
Multi-cloud strategie
Důvody pro multi-cloud
- Vendor lock-in prevence — diverzifikace rizika
- Regulatorní požadavky — data residency v konkrétních regionech
- Best-of-breed — každý provider má silné stránky (AWS networking, Azure enterprise, GCP data/ML)
- Akviziční scénáře — merge & acquisition sjednocení
Multi-cloud connectivity
| Metoda | Latence | Propustnost | Náklady |
|---|---|---|---|
| Site-to-Site VPN | Střední | Omezená | Nízké |
| Private interconnect (Direct Connect / ExpressRoute / Dedicated Interconnect) | Nízká | Vysoká | Vysoké |
| Cloud-to-cloud VPN | Střední | Střední | Střední |
| SD-WAN | Nízká | Vysoká | Střední |
Výzvy
- Síťová komplexita — rozdílné VPC/VNet koncepty, security modely
- IAM federace — jednotné identity napříč cloudy (SSO, SAML, OIDC)
- Data gravitace — pohyb dat mezi cloudy je drahý a pomalý
- Monitoring — jeden pane of glass napříč cloudy (Grafana, Datadog)
Migrační strategie — 6 Rs
| Strategie | Popis | Náročnost | Typický scénář |
|---|---|---|---|
| Rehost (Lift & Shift) | Přesun VM/as-is bez změn | Nízká | Rychlá migrace, datacentrum exit, minimální riziko |
| Replatform (Lift & Reshape) | Migrace s drobnými úpravami (např. RDS místo self-managed DB) | Střední | Optimalizace bez přepisování aplikace |
| Refactor (Re-architect) | Přepis aplikace na cloud-native (microservices, serverless) | Vysoká | Maximalizace cloudu, dlouhodobá strategie |
| Repurchase | Přechod na SaaS (např. Salesforce, Workday) | Nízká | Aplikace je zastaralá, existuje SaaS alternativa |
| Retire | Vypnutí nepotřebných aplikací | Nízká | Aplikace již není používaná, decommission |
| Retain | Ponechání on-prem | Žádná | Regulatorní důvody, příliš vysoké riziko migrace |
Decision framework pro 6 Rs
Start: Je aplikace potřebná?
├── Ne → Retire
└── Ano → Existuje SaaS alternativa?
├── Ano → Repurchase
└── Ne → Vyplatí se refactoring?
├── Ano → Refactor
└── Ne → Stačí změna platformy?
├── Ano → Replatform
└── Ne → Rehost
Well-Architected Framework (AWS)
- Operational Excellence — automace, monitoring, dokumentace
- Security — IAM, encryption, compliance
- Reliability — recovery, škálování, záložní plány
- Performance Efficiency — right-sizing, výběr správných služeb
- Cost Optimization — FinOps, reserved instances, spot instances
- Sustainability (od 2022) — carbon footprint, energy efficiency
Obdoby: Azure Well-Architected Framework, GCP Architecture Framework
Klíčové otázky z Well-Architected Review (~60 otázek)
Operational Excellence (12 otázek)
- Jak jsou změny řízeny a automatizovány?
- Jak jsou operace dokumentovány a sdíleny v týmu?
- Jak jsou očekávané a neočekávané události reflektovány v operacích?
- Jaké runbooky existují pro běžné provozní scénáře?
- Jak probíhá incident management a postmortem proces?
Security (12 otázek)
- Jak je implementováno identity & access management?
- Jak jsou chráněna data v klidu a při přenosu?
- Jak je zajištěna detekce bezpečnostních incidentů?
- Jaké jsou postupy pro patch management a vulnerability remediation?
- Jak jsou řízeny infrastrukturní kredenciály a secrets?
Reliability (12 otázek)
- Jak je zajištěna dostupnost služby při výpadku komponenty?
- Jak je implementováno backup a disaster recovery?
- Jak service limity (quotas, throttling) ovlivňují spolehlivost?
- Jak probíhá automatické škálování při změně zátěže?
- Jaké jsou SLI/SLO metriky a jak jsou monitorovány?
Performance Efficiency (12 otázek)
- Jak je vybrán správný typ a velikost compute/ storage?
- Jak je optimalizována databázová vrstva (indexy, dotazy, caching)?
- Jak je monitoring využit k identifikaci úzkých hrdel?
- Jak je implementováno škálování (vertikální vs horizontální)?
Cost Optimization (12 otázek)
- Jak jsou náklady alokovány na týmy/projekty (chargeback/showback)?
- Jaké nástroje se používají pro analýzu nákladů?
- Jak jsou identifikovány a eliminovány nevyužité zdroje?
- Jak je optimalizováno licencování (BYOL, hybrid benefit)?
Klíčové komponenty
Výpočetní vrstva
- VM / instance — EC2, Azure VMs, GCE
- Container orchestrace — EKS, AKS, GKE
- Serverless — Lambda, Azure Functions, Cloud Functions
- PaaS — App Engine, Elastic Beanstalk, Azure App Service
Compute comparison matrix (AWS EC2)
| Rodina | Typ | vCPU:Memory | Use case | Příklady cen (on-demand, us-east-1) |
|---|---|---|---|---|
| General purpose | M7g, m7i | 1:4 | Web servery, microservices, dev/test | m7i.large ~$0.088/h |
| Compute optimized | C7g, c7i | 1:2 | HPC, batch processing, CI/CD, gaming | c7i.large ~$0.078/h |
| Memory optimized | R7g, r7i, x2idn | 1:8 až 1:32 | In-memory DB (Redis), SAP HANA, real-time analytics | r7i.large ~$0.118/h |
| Storage optimized | I4i, im4gn | 1:4 + NVMe | Transactional DB, data warehousing, Kafka | i4i.large ~$0.138/h |
| GPU / ML | P5, g5, trn1 | GPU attach | AI training (P5), inference (g5), ML (trn1) | g5.xlarge ~$1.006/h |
Viz HARDWARE.md pro detail GPU modelů a konfigurací.
Úložiště
- Object storage — S3, Blob Storage, Cloud Storage
- Block storage — EBS, managed disks, persistent disks
- File storage — EFS, Azure Files, Filestore
- CDN — CloudFront, Azure CDN, Cloud CDN
S3 Storage Classes
| Třída | Dostupnost | Retrieval time | Cena / GB / měsíc | Use case |
|---|---|---|---|---|
| S3 Standard | 99.99 % | milisekundy | ~$0.023 | Aktivní data, častý přístup |
| S3 Intelligent-Tiering | 99.9 % | milisekundy | ~$0.023 + monitoring fee | Neznámý / proměnlivý přístup |
| S3 Standard-IA | 99.9 % | milisekundy | ~$0.0125 | Méně častý přístup, ale rychlý |
| S3 One Zone-IA | 99.5 % | milisekundy | ~$0.01 | Znovu vytvořitelná data |
| S3 Glacier Instant | 99.9 % | milisekundy | ~$0.004 | Archiv s občasným přístupem |
| S3 Glacier Flexible | 99.99 % | 1-5 min (expedite) / 3-5 h (standard) | ~$0.0036 | Dlouhodobý archiv |
| S3 Glacier Deep Archive | 99.99 % | 12 h (standard) / 48 h (bulk) | ~$0.00099 | Nejlevnější, compliance archívy |
Multi-AZ a Multi-Region architektura
Region ┌──────────────────────────────┐
│ AZ-1 AZ-2 AZ-3 │
│ ┌───┐ ┌───┐ ┌───┐ │
│ │APP│──────│APP│──────│APP│ │
│ └─┬─┘ └─┬─┘ └─┬─┘ │
│ │ │ │ │
│ ┌─▼──────────▼──────────▼─┐ │
│ │ Load Balancer │ │
│ └────────────┬────────────┘ │
│ │ │
│ ┌────────────▼────────────┐ │
│ │ Database (Primary) │ │
│ │ + Read Replica │ │
│ └─────────────────────────┘ │
└──────────────────────────────┘
Cloud design patterns
Strangler Fig
Postupné nahrazování částí monolitické aplikace microservices.
- Legacy funkcionalita se postupně přesměrovává na nové služby
- Strangler Fig proxy (route hlavičky, feature flagy) řídí přesun trafficu
- Výhoda: průběžné dodávání hodnoty bez big-bang přepisu
Circuit Breaker
Zabránění kaskádovým selháním při výpadku závislé služby.
- Tři stavy: Closed (normální provoz), Open (requesty okamžitě failují), Half-Open (testovací request po timeoutu)
- Parametry: failure threshold, timeout (reset timeout), half-open max requests
- Implementace: resilience4j, Hystrix (legacy), Istio (envoy), AWS App Mesh
Saga
Distribuovaná transakce napříč microservices — řada lokálních transakcí s kompenzačními akcemi.
- Choreography — každá služba publikuje událost, další služba reaguje (Kafka, EventBridge)
- Orchestration — centrální orchestrátor řídí kroky (Step Functions, Temporal, Camunda)
CQRS (Command Query Responsibility Segregation)
Oddělení zápisových (Command) a čtecích (Query) modelů.
- Command model: optimalizovaný pro zápis (normalizovaný, transactionální)
- Query model: optimalizovaný pro čtení (denormalizovaný, read-optimized views)
- Eventual consistency mezi modely (event bus propaguje změny)
- Use case: reporting, audit logy, high-throughput systémy
Event Sourcing
Ukládání stavu jako sekvence událostí (eventů), ne aktuálního stavu.
- Každá změna je append-only event v event store
- Současný stav = fold všech událostí
- Výhody: audit trail, time travel, CQRS kompatibilita
- Implementace: EventStoreDB, Kafka (log), DynamoDB + CDC
Hybrid cloud konektivita
Viz také: NETWORKING.md — síťová architektura (VPN, BGP, VPC design).
- Site-to-Site VPN — IPSec tunel přes internet
- Direct Connect / ExpressRoute / Dedicated Interconnect — privátní fyzické propojení
- Cloud VPN / Transit Gateway — hub-and-spoke topologie
Cost optimization detail
Savings Plans vs Reserved Instances
| Vlastnost | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|---|---|---|---|
| Flexibilita | Instance family, region, OS | Instance family + region | Specifická instance |
| Termín | 1 nebo 3 roky | 1 nebo 3 roky | 1 nebo 3 roky |
| Sleva (typicky) | ~30-50 % | ~40-60 % | ~40-60 % |
| Změna instance | Ano (libovolná) | Ano (v rámci rodiny) | Ne |
| Změna regionu | Ano | Ne | Ne |
| Payment options | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront |
Spot instance best practices
- Diverzifikace — používejte mix instance typů (spot fleet) pro vyšší dostupnost
- Graceful handling — aplikace musí zvládnout termination notice (2 minuty varování)
- Checkpointing — pravidelné ukládání stavu pro restart po spot přerušení
- Spot block (AWS) — ochrana na 1-6 h (omezená dostupnost)
- Použití: batch processing, CI/CD runners, stateless microservices, ML training
- Vyhnout se: stateful workloads, databáze (bez speciálního designu)
Organizace a governance
AWS Organizations
Root OU
├── Security OU
│ ├── Audit Account (CloudTrail, Config)
│ └── Security Tooling Account (GuardDuty, Security Hub)
├── Infrastructure OU
│ ├── Network Account (Transit Gateway, VPN)
│ ├── Shared Services Account (AD, SSO)
│ └── Log Archive Account
├── Workloads OU
│ ├── Dev OU → jednotlivé dev accounts
│ ├── Staging OU → staging accounts
│ └── Prod OU → production accounts
└── Sandbox OU → izolované experimentální účty
- SCP (Service Control Policies) — whitelist/blacklist služeb na OU úrovni
- Tag policies — enforcement tagování napříč účty
- AI services opt-out — kontrola použití dat v AWS AI službách
Azure Management Groups
Tenant Root Group
├── Platform MG
│ ├── Connectivity (hub VNet, ExpressRoute)
│ ├── Management (Log Analytics, Automation)
│ └── Identity (AD DS, PIM)
├── Application MG
│ ├── DEV (dev subscriptions)
│ ├── TEST (test subscriptions)
│ └── PROD (production subscriptions)
└── Sandbox MG
- Azure Policy — built-in a custom policies (podobné SCP)
- Management Group hierarchy — až 6 úrovní hloubky
- Subscription limits — max 10 000 subscriptions na tenant
GCP Projects
Organization Node
├── Folder: Platform
│ ├── Project: Shared Networking (VPC, Cloud NAT, VPN)
│ ├── Project: Security (Cloud KMS, Secret Manager, Chronicle)
│ └── Project: Monitoring (Cloud Monitoring, Logging)
├── Folder: Workloads
│ ├── Folder: Dev
│ │ └── Project: [aplikace]-dev
│ ├── Folder: Staging
│ │ └── Project: [aplikace]-staging
│ └── Folder: Prod
│ └── Project: [aplikace]-prod
└── Folder: Sandbox
└── Project: [user]-sandbox
- Organization policies — constrainty na úrovni organizace/folderu
- Resource Manager — hierarchie: Organization → Folder → Project → Resources
- Project limits — max 30 projektů (lze navýšit), resources per project 10k
Best practices
- Používejte infrastructure as code (Terraform, Pulumi, CDK)
- Designujte pro failure — každá komponenta může spadnout
- Implementujte defense in depth — security na každé vrstvě
- Monitorujte náklady — taggování, budget alerts, anomaly detection
- Používejte managed services kde to dává smysl (méně operací)
- Least privilege pro všechny IAM role a politiky
Zdroje
Odkazy, knihy a standardy: sources/cloud/sources.md
- Cost tagging — assign tags pro chargeback/showback (Environment, Team, Cost Center, Application)
- Automated compliance — AWS Config, Azure Policy, GCP Org Policies pro guardrails
- Multi-account strategie — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy