Escalabilidade
Escalabilidade é a capacidade de a sua aplicação crescer (ou diminuir) para atender a demanda. Se hoje você tem 100 usuários e amanhã tem 100 mil, sua aplicação precisa aguentar.
Existem dois tipos de escalabilidade, e essa diferença cai em toda entrevista de cloud:
Escalabilidade vertical (Scale Up)
Você coloca uma máquina mais potente no lugar da que você já tem. Mais CPU, mais RAM, mais disco. É como trocar um Fusca por uma Ferrari.
- Vantagens: simples, não mexe na arquitetura.
- Desvantagens: tem um limite físico (a máquina mais potente do mundo ainda assim é finita), e geralmente exige downtime para trocar.
Escalabilidade horizontal (Scale Out)
Você adiciona mais máquinas iguais trabalhando em paralelo. Em vez de uma Ferrari, você tem 10 Fuscas dividindo a carga.
- Vantagens: praticamente infinita, sem downtime, mais resiliente (se um cair, os outros continuam).
- Desvantagens: sua aplicação precisa ser desenhada para isso (stateless, idempotente, etc).
Você tem uma padaria com uma fila de clientes: Vertical = contratar o atendente mais rápido do mundo. Funciona até certo ponto, mas ele é uma pessoa só. Horizontal = abrir mais 4 caixas com 4 atendentes em paralelo. A fila divide e anda muito mais rápido.
Cloud foi feita para escalabilidade horizontal. Os serviços da AWS são construídos para que você possa subir e descer máquinas à vontade.
Auto Scaling
Auto Scaling é o recurso que faz a AWS subir e descer máquinas automaticamente, baseado em regras que você define.
Exemplo: "Quando a CPU média ultrapassar 70%, suba uma nova EC2. Quando ficar abaixo de 30%, desligue uma". Pronto, sua aplicação se ajusta sozinha de madrugada e na hora do pico.
Alta disponibilidade (HA)
Alta disponibilidade significa que sua aplicação continua funcionando mesmo quando algo dá errado. É a famosa promessa de "99,99% uptime" (que dá cerca de 52 minutos de queda por ano — só isso).
Para ter alta disponibilidade, você precisa eliminar pontos únicos de falha (SPOF — Single Point of Failure). Se há apenas UMA máquina, UM banco, UM cabo, UM data center... é aí que mora o perigo.
Regiões e Availability Zones
A AWS divide o mundo em Regiões (ex: sa-east-1 em São Paulo, us-east-1 na Virgínia). Cada região tem múltiplas Availability Zones (AZs), que são data centers fisicamente separados, com energia, rede e refrigeração independentes, mas conectados por fibra de baixa latência.
Regra de ouro: para ter alta disponibilidade, distribua sua aplicação em pelo menos 2 AZs da mesma região. Se um data center inteiro pegar fogo (sim, já aconteceu), o outro assume.
Imagine uma loja com só um caixa, em apenas um shopping. Se o caixa adoecer ou o shopping fechar por reforma, sua loja morre. Agora imagine 3 caixas no mesmo shopping (resolve falha de funcionário), em 3 shoppings diferentes da cidade (resolve falha de shopping). Cliente sempre encontra um caixa aberto. Multi-AZ resolve falha de "shopping" (data center). Multi-região resolve falha de "cidade" (região geográfica inteira).
SLA — Service Level Agreement
Cada serviço AWS tem um SLA, que é o compromisso de disponibilidade. Veja alguns exemplos reais:
- EC2 (uma só AZ): 99,5% — cerca de 1 dia e 19h de queda permitida por ano
- EC2 multi-AZ: 99,99% — cerca de 52 minutos por ano
- S3: 99,99% de disponibilidade e 99,999999999% (11 noves) de durabilidade dos dados
- RDS Multi-AZ: 99,95%