AWS Migration - Uma visão além de bits and bytes
•Transferir como ODP, PDF•
1 gostou•148 visualizações
O documento discute a migração para a AWS, incluindo decisões difíceis de mudança de cultura, os desafios de gerenciamento de autenticação, autorização e contabilidade, a importância da localização de recursos, o uso de tags e subnets, os benefícios e desafios de instâncias reservadas e spot, a necessidade de automação, o armazenamento em S3 e uso do RDS em vez de instâncias EC2, e a importância de métricas e otimização de recursos após a migração.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (12)
Semelhante a AWS Migration - Uma visão além de bits and bytes
Semelhante a AWS Migration - Uma visão além de bits and bytes (11)
AWS Migration - Uma visão além de bits and bytes
- 1. AWS Migration Uma visão além de bits and bytes Giovani Dardani 20/08/2016
- 2. Antes de qualquer coisa ... Sem “jabá” Sem pretensões Compartilhar experiência
- 3. To the cloud! Decisão difícil Mudança de cultura
- 4. Authentication, Authorization and Accounting (Access|Secret Access) Key Dificuldade de gerenciamento Alternativa
- 7. NAT Default GW – private networks NAT gateway X NAT instance Ponto único de falha
- 8. Subnets Reside em apenas uma AZ Especialização de subnets Acls
- 9. AMI/Snapshot Recurso bastente útil “There's no such thing as a free lunch” Dados sensíveis
- 10. Reserved Instances Reserved Instances <> Dedicated Instances Ideal para recursos 24x7 Diversos planos Exige planejamento
- 11. Spot Instances Mais economia Preço oscila de acordo com oferta/demanda Exige “flexibilidade” do seu serviço
- 12. Instâncias Time-based Desligue recursos não necessários Ambientes de DEV/QA
- 13. Automação Recurso mandatório “Treat Your Servers Like Cattle, Not Like Pets”
- 14. S3 Big data sets “Cold files” Bucket policy
- 15. RDS RDS > EC2 + SGBD MultiAZ Snapshots
- 16. Cloudformation KISS – Keep it simples, stupid Acesso restrito Version Control
- 17. Métricas Mudança drástica Tenha métricas! Reclamações VÂO acontecer Antes vs Depois
- 18. Otimização de Recursos Passada a tormenta CPU, IO, Network e etc Containers, Orchestration, Microservices e Configuration management
Notas do Editor
- &quot;(Access|Secret Access) Key&quot; Esse é o metodo mais comum utilizado para fornecer acessos a pessoas e aplicacoes &quot;Dificuldade de gerenciamento&quot; Ressaltar dificuldade de auditoria e gerenciamento Tenha cuidado, principalmente aplicacoes que se utilizam desse tipo de acesso Resaltar a importancia de nao commitar ker/secret_key com codigo &quot;Alternativas&quot; Mostrar IAM role como substituto para keys/secret_keys Polycies IAM são bastante flexívies e são bastante úteis para controles de acess
- Existem várias &quot;Regions&quot; disponiveis e basicamente todas disponibilizam os mesmos servicos Preços mudam muito de uma region para outra, sa-east-1 (Sao Paulo) e a mais cara delas Serviços que nao sofrem impactos com alta-latencia devem rodar em regioes mais baratas, isso reduz bastante o custo operacional de um ambiente Servicos que demandam baixo tempo de resposta podem se valer de servicos de CDNs ou mesmo ter uma arquitetura que permita a execucao em multiplas regioes (Front-end mais proximo do cliente e back-end em uma regiao com custo mais baixo)
- Tags são amigas e devem sem utilizadas sem moderação Organização e acima de tudo facilita a estimativa de custos por produtos/celulas/departamentos e etc Clen up de recursos nao taggeados pode ser agressivo mas pode apresentar uma economia considerável
- &quot;Default GW – private networks&quot; GW ou Nat possibilitam que instancias contidas em redes privadas possam se conectar com a internet sem a necessidade de um EIP &quot;NAT gateway X NAT instance&quot; NAT gateway é um servico oferecido pela AWS enquanto um &quot;NAT Instance&quot; nada mais do é do que uma instancia EC2 com regras de firewall para o roteamento adequado das conexoes Preferencia pelo NAT Gateway, o mesmo é gerenciado pela AWS e já oferece HA por definição e demanda pouca ou nenhuma manutencao &quot;Ponto único de falha&quot; Serviço muito critico, tem capacidade de tirar seu ambiente fora do ar (lembrar que tds as máquinas em redes privadas usam esse NAT) Lembrar do incidente onde uma inst. NAT falhou e forçou o autoscale a instalar máquinas por conta da falha no health-check das instancias
- &quot;Reside em apenas uma AZ&quot; Uma subnet existe dentro de uma AZ apenas, subnets que residem em AZs diferentes dependem de roteamento para se falarem &quot;Especialização de subnets&quot; Especialize as subnets de uma forma que cada uma delas tenham &quot;papeis&quot; específicos. Diferenciar subnets que irão conter bancos de dados e aplicacoes facilita a administracao &quot;Acls&quot; Promovem mais uma nível de controle de acessos além do tradicional security group. Feche completamente os acessos e libere estritamente necessárias. Acls de subnet são stateless, sendo assim, temos que gerenciar regras de entrada e saida Tome cuidado com acls muito específicas pelo fato de o número total de acls por subnet ser limi
- &quot;Recurso bastente útil&quot; Bastante empregado para &quot;backups&quot; e ponto de partida com AMIs customizadas &quot;There&apos;s no such thing as a free lunch” Assim como qq outro serviço, AMIs e Snapshots sao cobrados. Implementar politica de remoção de recursos nao mais utilizados. Manter somente o necessário ajuda a manter os custos dentro de um range aceitável &quot;Dados sensíveis&quot; Geralmente criamos AMIs/Snapshots a partir de instancias que já estão rodando. Essas intancias possuem dados sensiveis como senhas de banco de dados configurados em aplicacoes, Certificados e chaves SSL, chaves SSH e até msm chaves AWS Se por acidente tornarmos uma dessas AMIs publicas, podemos ter graves incidentes de seguranca
- &quot;Reserved Instances &lt;&gt; Dedicated Instances&quot; A reserva de instancias se relaciona ao custo de uma instancia EC2 ou RDS e nada tem á ver com hardware/recurso dedicado &quot;Ideal para recursos 24x7&quot; Reserved instances é muito indicado para recursos que irão ficar online em regime 24x7, exemplos disso são instancias RDSs e EC2 &quot;Diversos planos&quot; Existem alguns planos disponiveis e os mais agressivos sao os que apresentam maior grau de economia. PLanos de longo prazo (3 anos) podem prover até 75% de economia &quot;Exige planejamento&quot; è necessário ter certeza da utilizacao do recurso antes de realizar a aquisição. Msm existindo a possibilidade de venda de uma Reserved Instance é muito importante termos garantia de que iremos utilizar o recurso pelo tempo contratado
- &quot;Mais economia&quot; Outro recursos muito que gera muita economia com instancias EC2 &quot;Preço oscila de acordo com oferta/demanda&quot; O valor/hora varia de acordo com o tipo de instancia e também a AZ. Esse valor é definido pela EC2 e muda de acordo com oferta e demanda &quot;Exige “flexibilidade” do seu serviço&quot; Uma Spot instance pode nao ser iniciada imediatamente, sendo assim noa deve ser aplicadas à serviço que possuem picos de consumo ou que devam escalar de forma ágil. Muito bom para ser usada com instancias empregadas em ambiens de DEV/QA, batch Jobs, workers ou servicos que toleram algum dowmtime. o &quot;problema&quot; é que instancia Spot nao podem ser instaladas dentro de stacks Opswors
- &quot;Desligue recursos não necessários&quot; Recursos que nao são utilizados em regime 24x7 podem ser desligados quando necessário. Para facilitar essa tarefa podemos configurar instancias Time Based que ser]ao ligadas e desligados em intervalos específicos de tempo &quot;Ambientes de DEV/QA&quot; Ambientes dessa natureza geralmente devem funcionar em horario comercial salvo algumas exceções. Sendo assim eles são exemplos perfeitos de ambientes que podem e devem se utilizar desse recurso
- Sei que pode-se &quot;sobreviver sem automação mas em um ambiente tão volátil automação é uma obrigação e não um &quot;sonho&quot;. Treat Your Servers Like Cattle, Not Like Pets Lambrar da apresent. de Chef do Du! Dizer que chef é minha opçao também e mensionar o OPsWo
- A facilidade de utilização do serviço pode nos colocar em uma situação complicada. Analisar td a massa de dados antes de empurrar esse conteúdo para um bucket S3!! POrque? Inbound traffic de uma region nao é tarifada, td o trafico de saida custa $$ Requests para as APis tb custam $$ &quot;Cold files&quot; (arquivos que nao serão utilizados dentro de um curto perído de tempo) devem utilizar outros tipos de serviços de storages. Infrequent Access Storage e Glacier são bons condidatos tem um alto tempo para restore!!! Bucket Policy Facilita a autorização de acessos à buckets
- De preferência ao serviços de RDS ao invés de SGBD instalado em instancia EC2 MultiAZ é mais do que recomendado. Lembrar dificuldade por conta da nao possibilidade de acesso SSH para manutenção de bancos Snapshots periódicos (tomar cuidado porque isso tb custa $$ e pode &quot;sair de controle&quot;)
- &quot;KISS&quot; Keep it simples stupid! Recurso muito valioso mas que tem uma enorme capacidade para se tornor complexo caso utilizado de forma equivocada &quot;Acesso restrito&quot; Restrinja o acesso à apenas algumas pessoas e tenha certeza que elas e somente elas possam atualizar suas stacks. IAM policies podem fazer esse controle de forma bastante satisfatória &quot;Version Control&quot; Versione seus template CFN em um repositório onde seja fácil o tracking de modificações e que facilite o rollback caso necessario ** Lembrar do problema que tivemos com CFN - OpsWorks
- A migração para um serviço de cloud é bastante significativa e com ctz vai trazer muitas mudanças para o seu ambiente. Métricas pré e pós migração serão extremamente úteis/necessárias uma vez que o seus serviços irão se comportar de maneira diferente após a migração e inevitavelmente reclamacoes do tipo &quot;o site está lento&quot; ou &quot;funcionava bem antes de vcs mecherem&quot; vão acontecer com ctz.
- Passada a tormenta da migracao iremos notar certa &quot;ociosidade&quot; de recursos, isso acontece e é natural. Otimizacao de recursos (CPU, IO, NetWork e etc) deve estar no nosso radar.Ttecnologias como containers, Orchestration e micro-services devem ser analisados.