Amazon EC2 oferece uma ampla seleção de tipos de instâncias para suportar diversos casos de uso. Nesta sessão, entregaremos uma visão geral da plataforma de instâncias do Amazon EC2, das características mais importantes da plataforma e do conceito de gerações de instâncias. Nos aprofundamos nas escolhas da geração atual para as diferentes famílias de instâncias, incluindo as famílias de Propósito Geral (General Purpose), as otimizadas para Computação, Otimizadas para Armazenamento, Otimizadas para Memória e as familias com Computação Acelerada (GPU e FPGA). Também detalharemos as melhores práticas e compartilhamos dicas de desempenho para obter o máximo de suas instâncias do Amazon EC2. https://aws.amazon.com/pt/ec2/

1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Damian Traverso, Solutions Architect
Junho, 2017
Amazon EC2: Boas práticas e
Otimizações de desempenho

2. O que esperar dessa sessão
 Compreendendo os fatores envolvidos na hora de escolher uma
instância EC2
 Definindo o desempenho de sistema e como caracterizar as
diferentes tarefas (workloads)
 Como as instâncias Amazon EC2 entregam desempenho com
flexibilidade e agilidade
 Como extrair o máximo das instâncias Amazon EC2 considerando
os diferentes tipos disponíveis

3. APIs
EC2
EC2
Amazon Elastic Compute Cloud é Abrangente
Instâncias
Rede
Opções de compra

4. Host Server
Hypervisor
Guest 1 Guest 2 Guest n
Instâncias Amazon EC2

5. No passado
 Primeiro lançamento em Agosto 2006
 Instância M1
 “Um tamanho serve para tudo” M1

6. Histórico das Instâncias Amazon EC2
2006 2008 2010 2012 2014
2016
m1.small
m1.large
m1.xlarge
c1.medium
c1.xlarge
m2.xlarge
m2.4xlarge
m2.2xlarge
cc1.4xlarge
t1.micro
cg1.4xlarge
cc2.8xlarge
m1.medium
hi1.4xlarge
m3.xlarge
m3.2xlarge
hs1.8xlarge
cr1.8xlarge
c3.large
c3.xlarge
c3.2xlarge
c3.4xlarge
c3.8xlarge
g2.2xlarge
i2.xlarge
i2.2xlarge
i2.4xlarge
i2.4xlarge
m3.medium
m3.large
r3.large
r3.xlarge
r3.2xlarge
r3.4xlarge
r3.8xlarge
t2.micro
t2.small
t2.med
c4.large
c4.xlarge
c4.2xlarge
c4.4xlarge
c4.8xlarge
d2.xlarge
d2.2xlarge
d2.4xlarge
d2.8xlarge
g2.8xlarge
t2.large
m4.large
m4.xlarge
m4.2xlarge
m4.4xlarge
m4.10xlarge
x1.32xlarge
t2.nano
m4.16xlarge
p2.xlarge
p2.8xlarge
p2.16xlarge

7. Geração da Instância
c4.xlarge
Família da
Instância
Tamanho da
Instância

8. Famílias de Instâncias EC2
Uso
geral
Otimizadas
para
computação
C3
Otimizadas para
armazenamento
I3 P2
Computação
acelerada
Otimizadas
para memória
R4C4
M4
D2
X1
G2
F1

9. O que é uma Virtual CPU? (vCPU)
 Uma vCPU es tipicamente um core físico com hyper-threading*
 No Linux, os threads “A” são enumerados antes dos threads “B”
 No Windows, os threads são entrelaçados
 Divida a quantidade de vCPUs por dois para obter a quantidade de
cores
 Cores por tipo de Instância EC2 & RDS DB:
https://aws.amazon.com/ec2/virtualcores/
* A família “T” é especial

11. Desative o Hyper-Threading se precisar
 Útil para aplicações intensivas em FPU
 Utilize ‘lscpu’ para validar o layout
 Deixe offline os threads “B” em quente
for cpunum in $(cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
| cut -s -d, -f2- | tr ',' 'n' | sort -un); do
echo 0 | sudo tee /sys/devices/system/cpu/cpu${cpunum}/online
done
 Configure grub para unicamente inicializar a primeira metade dos
threads
maxcpus=64

13. Tamanho da Instância
c4.8xlarge 2 - c4.4xlarge
≈
4 - c4.2xlarge
≈
8 - c4.xlarge
≈

14. Alocação de recursos
 Todos os recursos assinados a você são dedicados à sua instância,
sem sobre-subscripção*
 Todas as vCPUs são dedicados para você
 A memória alocada é assinada unicamente à sua instância
 Os recursos de rede são particionados para evitar “noisy
neighbors”
 Tem curiosidade sobre o número de instâncias por host? utilize
“Dedicated Hosts” como uma guia.
*Novamente, a família “T” é especial

15. “Lançar novas instâncias e executar os testes
em paralelo é simples...[na hora de escolher
uma instância] não há melhor substituto para
medir o desempenho que a sua própria
aplicação.”
- Documentação do EC2

16. Infraestrutura escalável para atender
picos de audiência em rede nacional
O ZAP, uma empresa do Grupo Globo,
é o mais completo, moderno e eficiente
portal do mercado imobiliário no Brasil.
Conectamos as pessoas interessadas
em imóveis numa plataforma de
negócios com as melhores
informações, análises e tecnologias
para o mercado
“A AWS permitiu que
novos requisitos de
negócio fossem atendidos
com agilidade, oferecendo
serviços inovadores,
escaláveis e com alta
disponibilidade”
Adriano Aguiar,
Gerente de
Infraestrutura

17. O Desafio
Capacidade de suportar alto volume
de acessos com baixo custo
Ser escalável em curto espaço de
tempo.
Usar eficientemente o amplo portfolio
de serviços da AWS: Cloudformation,
Beanstalk, Elastic Cache, Instâncias
Reservadas e Spot, Auto Scaling,
apoiados pelo Enterprise Support

18. Solução escalável e de baixo custo
Auto Scaling group
On Demand/Reserved
Auto Scaling group
Spot
Availability Zone
Elastic Load
Balancing
Amazon
CloudWatch
AWS
CloudFormation
User data
Custom AMI
AWS Elastic
Beanstalk
.ebextensions
+

19. Manipulação do horário – Explicação
 A obtenção do horário numa instância é enganosamente
difícil
 gettimeofday(), clock_gettime(), QueryPerformanceCounter()
 O registro TSC
 Contador do CPU, acessível desde userspace
 Requer calibração, vDSO
 Invariante nos processadores Sandy Bridge
 Xen pvclock; não suporta vDSO
 Nas instâncias de geração atual, utilize TSC como fonte

20. Benchmarking – Aplicação Intensiva no uso do tempo
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <time.h>
#define BILLION 1E9
int main(){
float diff_ns;
struct timespec start, end;
int x;
clock_gettime(CLOCK_MONOTONIC, &start);
for ( x = 0; x < 100000000; x++ ) {
struct timeval tv;
gettimeofday(&tv, NULL);
}
clock_gettime(CLOCK_MONOTONIC, &end);
diff_ns = (BILLION * (end.tv_sec - start.tv_sec)) + (end.tv_nsec - start.tv_nsec);
printf ("Elapsed time is %.4f secondsn", diff_ns / BILLION );
return 0;
}

21. Usando o Xen Clock Source
[centos@ip-192-168-1-77 testbench]$ strace -c ./test
Elapsed time is 10.0336 seconds
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.99 3.322956 2 2001862 gettimeofday
0.00 0.000096 6 16 mmap
0.00 0.000050 5 10 mprotect
0.00 0.000038 8 5 open
0.00 0.000026 5 5 fstat
0.00 0.000025 5 5 close
0.00 0.000023 6 4 read
0.00 0.000008 8 1 1 access
0.00 0.000006 6 1 brk
0.00 0.000006 6 1 execve
0.00 0.000005 5 1 arch_prctl
0.00 0.000000 0 1 munmap
------ ----------- ----------- --------- --------- ----------------
100.00 3.323239 2001912 1 total

22. Usando o TSC Clock Source
[centos@ip-192-168-1-77 testbench]$ strace -c ./test
Elapsed time is 2.0787 seconds
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
32.97 0.000121 7 17 mmap
20.98 0.000077 8 10 mprotect
11.72 0.000043 9 5 open
10.08 0.000037 7 5 close
7.36 0.000027 5 6 fstat
6.81 0.000025 6 4 read
2.72 0.000010 10 1 munmap
2.18 0.000008 8 1 1 access
1.91 0.000007 7 1 execve
1.63 0.000006 6 1 brk
1.63 0.000006 6 1 arch_prctl
0.00 0.000000 0 1 write
------ ----------- ----------- --------- --------- ----------------
100.00 0.000367 53 1 total

23. Ou adicione no grub:
Mudar com:
Dica: utilize o TSC como clocksource
No Windows 2008 R2 e seguintes versões:
Não é necessário, ele escolhe o melhor clocksource automaticamente
No Linux:

24. Controle do P-state e C-state
 c4.8xlarge, d2.8xlarge, m4.10xlarge,
m4.16xlarge, p2.16xlarge, x1.16xlarge,
x1.32xlarge
 Ao entrar em estados ociosos mais
profundos, os núcleos não ociosos podem
atingir frequências mais altas de até 300MHz
 Mas…os estados ociosos mais profundos
requerem mais tempo para sair, então pode
não ser apropriado para cargas sensíveis à
latência
 Linux: limite o c-state adicionando
“intel_idle.max_cstate=1” no grub
 Windows: não tem opções para controlar o c-
state

25. Dica: Controle do P-state para AVX2
 Se uma aplicação faz uso constante do AVX2 de todos os processadores,
o processador pode tentar extrair mais potência do que precisa
 O processador irá reduzir a frequência de maneira transparente
 Alterações excessivas na frequência da CPU podem deixar sua aplicação
lenta
sudo sh -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo"
Consulte também: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html

26. Revisão: Instâncias T2
 Instâncias EC2 de baixo custo começando em $0.0065 por hora
 Desempenho com capacidade de Burst
 Alocação da variação da CPU baseada em créditos
Modelo vCPU Linha de
base
Créditos de
CPU / Hora
Memoria
(GiB)
Armazenamento
t2.nano 1 5% 3 .5 Somente EBS
t2.micro 1 10% 6 1 Somente EBS
t2.small 1 20% 12 2 Somente EBS
t2.medium 2 40%** 24 4 Somente EBS
t2.large 2 60%** 36 8 Somente EBS
Uso geral, servidores web, ambientes de desenvolvimento, pequenos BDs

27. Como os créditos funcionam
 Um crédito de CPU fornece o desempenho de
um núcleo de CPU completo por um minuto
 A instância ganha créditos de CPU
constantemente
 A instância consome os créditos quando
solicitado
 Os créditos expiram depois de 24 horas
Taxa de Referência
(Baseline)
Saldo
de
crédito
Taxa de
Burst

28. Dica: Monitore a utilização de créditos de CPU

29. Revisão: Instâncias X1
 Maior instância de memória com 2 TB de DRAM
 Quad-socket, Intel E7 processors com 128 vCPUs
Modelo vCPU Memória (GiB) Armazenamento
Local
Rede
x1.16xlarge 64 976 1x 1920GB SSD 10Gbps
x1.32xlarge 128 1952 2x 1920GB SSD 20Gbps
Bancos de dados em memória, processamento de Big Data, HPC

30. NUMA
 Non-uniform memory access
 Cada processador em um sistema multi-
CPU possui memória local acessível através
de uma conexão rápida
 Cada processador também pode acessar a
memória de outras CPUs, mas o acesso à
memória local é muito mais rápido do que a
memória remota
 O desempenho está relacionado ao número
de sockets de CPU e como eles estão
conectados - Intel QuickPath Interconnect
(QPI)

31. QPI
122GB 122GB
16 vCPU’s 16 vCPU’s
r3.8xlarge

32. QPI
QPI
QPIQPI
QPI
488GB
488GB
488GB
488GB
32 vCPU’s 32 vCPU’s
32 vCPU’s 32 vCPU’s
x1.32xlarge

33. Dica: Suporte do Kernel para balanceamento NUMA
 Uma aplicação vai ter melhor desempenho quando todos os threads de
seus processos estejam acessando o mesmo nó de NUMA.
 O balanceamento NUMA move tarefas mais próximas da memória a que
acessam.
 Isso é feito automaticamente pelo kernel do Linux quando o
balanceamento automático NUMA está ativo: versão 3.8+ do Kernel do
Linux.
 O suporte do Windows para o NUMA apareceu pela primeira vez nas
SKUs Enterprise e Data Center do Windows Server 2003.
 Defina "numa=off" ou use numact para reduzir a paginação NUMA, se
sua aplicação usar mais memória do que caberá em um único socket ou
tiver threads que se movam entre sockets.

34.  Kernel do Linux 3.8+ e Windows Datacenter 2003+ suportam o
balanceamento NUMA
 Nem sempre é o mais eficiente
 Sobrecarga do gerenciamento de memória pode diminuir a velocidade do seu aplicativo
 O seu aplicativo possui mais memória que se encaixa em um único socket?
 Linux: Defina "numa = off" no grub para desabilitar a consciência NUMA
 Você tem muitos processos ou footprint inferior a um único socket?
 Linux: use "numactl" para restringir isso a núcleos ou nós específicos
 Exemplo: numactl --cpunodebind=0 --membind=0 ./myapp.run
 Windows: use a afinidade do processador para bloquear aplicativos em núcleos
específicos.
Dica: Suporte do Kernel para balanceamento NUMA

35. Hugepages no Linux
 Desative Transparent Hugepages
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
 Use Explicit Huge Pages
$ sudo mkdir /dev/hugetlbfs
$ sudo mount -t hugetlbfs none /dev/hugetlbfs
$ sudo sysctl -w vm.nr_hugepages=10000
$ HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so numactl --cpunodebind=0
--membind=0 /path/to/application
Consulte também: https://lwn.net/Articles/375096/

36. Sistemas Operacionais impactam o desempenho
 Aplicação intensiva em memória
 Criava uma grande quantidade de threads
 Rapidamente alocava/deslocava memória
 Se comparou desempenho do RHEL6 vs RHEL7
 Se observou grande quantidade de tempo de “system” no top
 Se encontrou uma ferramenta de benchmark (ebizzy) com um perfil de
desempenho semelhante
 Se traçou o desempenho com “perf”

37. No RHEL6
[ec2-user@ip-172-31-12-150-RHEL6 ebizzy-0.3]$ sudo perf stat ./ebizzy -S 10
12,409 records/s
real 10.00 s
user 7.37 s
sys 341.22 s
Performance counter stats for './ebizzy -S 10':
361458.371052 task-clock (msec) # 35.880 CPUs utilized
10,343 context-switches # 0.029 K/sec
2,582 cpu-migrations # 0.007 K/sec
1,418,204 page-faults # 0.004 M/sec
10.074085097 seconds time elapsed

38. RHEL6 Flame Graph
www.brendangregg.com/flamegraphs.html

39. No RHEL7
[ec2-user@ip-172-31-7-22-RHEL7 ~]$ sudo perf stat ./ebizzy-0.3/ebizzy -S 10
425,143 records/s
real 10.00 s
user 397.28 s
sys 0.18 s
Performance counter stats for './ebizzy-0.3/ebizzy -S 10':
397515.862535 task-clock (msec) # 39.681 CPUs utilized
25,256 context-switches # 0.064 K/sec
2,201 cpu-migrations # 0.006 K/sec
14,109 page-faults # 0.035 K/sec
10.017856000 seconds time elapsed
De 12,400 records/s!
De 1,418,204!

40. RHEL7 Flame Graph

41. Hardware
Modelo de I/O: Split Driver
Driver Domain Guest Domain Guest Domain
VMM
Frontend
driver
Frontend
driver
Backend
driver
Device
Driver
CPU Física
Memória
Física
Dispositivo de
armazenamento
CPU Virtual
Memória
Virtual
CPU
Scheduling
Sockets
Aplicação
1
23
4
5

42. Validando os Persistent Grants
[ec2-user@ip-172-31-4-129 ~]$ dmesg | egrep -i 'blkfront'
Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated
disks.
blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdb: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdc: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdd: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvde: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdf: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdg: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdh: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
blkfront: xvdi: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;

43. Device Pass Through: Enhanced Networking
 SR-IOV elimina a necessidade do Driver Domain
 A placa de rede física é exposta para a instância Amazon EC2
 Requer um driver especial, isso quer dizer:
 O sistema operacional de sua instância precisa saber disso
 A instância EC2 precisa suportar essa funcionalidade

44. Hardware
Depois do Enhanced Networking
Driver Domain Guest Domain Guest Domain
VMM
NIC
Driver
Physical
CPU
Physical
Memory
SR-IOV Network
Device
Virtual CPU
Virtual
Memory
CPU
Scheduling
Sockets
Aplicação
1
2
3
NIC
Driver

45. Elastic Network Adapter
 Seguinte geração do Enhanced
Networking
 Hardware Checksums
 Multi-Queue Support
 Receive Side Steering
 20Gbps em Placement Groups
 Novo controlador de rede Open
Source desenvolvido pela Amazon

46. Desempenho de rede
 20 Gigabit & 10 Gigabit
 Medido de sentido único, o dobro para bidirecional (full duplex)
 Alto, Moderado, Baixo – Em função do tamanho da instância e
otimização EBS
 Nem todos criados iguais - Teste com iperf se é importante!
 Use Placement Groups quando você precisa largura de banda alta
e consistente entre instâncias
 Todo o tráfego é limitado a 5 Gb / s ao sair do EC2

47. ENA em Instâncias R4
 r4.8xlarge fornece 10Gbps consistentes
r4.16xlarge fornece 20Gbps consistentes
 Instâncias menores
 Até 10 Gbps com uma linha de base
 Acumule créditos quando o uso da rede
esteja abaixo da linha de base
 A largura total também pode ser atingida
sem utilizar Placement Groups, mas
precisa de múltiplos streams
 Um único stream é limitado a 10Gbps
em um Placement Group
 5 Gbps por stream entre AZ’s, mas ainda
consegue 20Gbps no total

48. Desempenho do EBS
 O tamanho da instância afeta a
taxa de transferência
 Equipare o tamanho e tipo do
volume com o tipo da instância
 utilize EBS Optimization se o
desempenho do EBS for
importante

49. “AWS nos ajudou a aumentar nosso
SLA e focar em E-Commerce”
A iSET é uma das principais
plataformas de e-commerce em
nuvem no Brasil, com mais de 8 mil
clientes atendidos.
Nossos sistemas e infraestrutura
são totalmente desenvolvidos
internamente.
“A AWS trouxe
redução de custos
operacionais e de infra
e permitiu um aumento
do SLA para 99,9%”
- Paulo Pina, CEO

50. O Desafio
Simplificar gestão dos quase 50
servidores dedicados;
Resolver em definitivo problemas de
disponibilidade;
Ter uma nova infraestrutura que
permitisse escalabilidade de forma
eficiente;
Reduzir e monitorar os custos por
serviço ativo.

51. Solução

52.  Escolha HVM AMIs
 Timekeeping: use TSC
 Controle do C-state and P-state
 Monitore os créditos de CPU das instâncias T2
 Use Sistemas Operacionais modernos
 Balanceamento NUMA
 Grants persistentes para melhor desempenho de I/O
 Enhanced Networking
 Entenda o perfil da sua aplicação
Resumo: Obtendo mais de sua instância EC2

53.  A meta é obter o desempenho do Bare Metal, e em muitos casos já
foi conseguido
 Histórico de eliminação da intermediação do Hypervisor e domínios
dos controladores
 Hardware assisted virtualization
 Scheduling and granting efficiencies
 Device pass through
Temas de Virtualização

54. Próximos Passos
 Acesse nossa documentação de instâncias Amazon EC2
 Inicie uma instância e teste o sua aplicação!

55. Obrigado!

56. Ainda não tem o App oficial do
AWS Summit São Paulo?
http://amzn.to/2rOcsVy
Não deixe de avaliar as sessões no app!