1 of 23

Sr. Specialist Solutions Architect - AWS

Leo Ciccone

Arquiteturas de alta performance para bancos de dados na

AWS

2 of 23

Leo Ciccone é especialista em bancos de dados na AWS com mais de 20 anos de experiência. Atua com clientes de todas as verticais na construção e otimização de soluções, na criação de arquiteturas eficientes, resilientes e seguras e nas suas jornadas de migração e modernização de bancos de dados.

Quem é

Leo Ciccone?

3 of 23

Agenda

01

Como medir performance?

02

Entendendo os fundamentos da performance

03

Como alcançar�performance

4 of 23

O telefone toca…

5 of 23

Médias são ruins!

Percentis são seus amigos e uma representação estatística muito mais fidedigna.

6 of 23

Latência e Long-tail

Performance deve ter como foco a experiência do cliente

7 of 23

Observabilidade

Tenha uma stack de Observabilidade e saiba operá-la

8 of 23

Funcionalidades CloudWatch - RDS

Instância

Sistema Operacional

Banco de dados

Amazon CloudWatch

Amazon RDS �Enhanced Monitoring

Amazon CloudWatch �Database Insights

Processos / Threads e métricas avançados do SO
Granularidade de 1–60 segundos
Comece com 15s e altere para 1 Segundo durante troubleshooting

CPU/ Memória / IOPS / Rede – métricas do host
Alarmes e notificações
Métricas por minuto
Logs do banco de dados no CloudWatch Logs

Load do banco de dados, average active sessions
Granularidade por segundo
Suporta todos os engines de RDS
Identificação de anomalias com DevOps Guru for RDS

9 of 23

Funcionalidades CloudWatch - DynamoDB

Conta

Amazon CloudWatch

Métricas de consumo agregando por conta
Alarmes e notificações
Métricas por minuto
Interessante para identificar soft limits sendo atingidos

Tabela

Amazon CloudWatch

Métricas de consumo específicas para cada tabela
Alarmes e notificações
Métricas por minuto
Interessante para identificar otimizações e throttling.

Tabela

Amazon CloudWatch�Contributor Insights

Identificar itens mais acessados (caching)
Identificar chaves mais acessadas (hot partition)

10 of 23

Conceitos base da performance

Load

Saturação

Threads

Throughput

11 of 23

Conceitos base da performance

Parse

Execute

Fetch

12 of 23

Well Architected Framework

13 of 23

Well Architected Framework - Lentes

14 of 23

Well Architected

Framework�Pilar Eficiência de Performance

Seleção da Arquitetura

Hardware e Computação

Gestão dos Dados

Processos e Cultura

Take a data-driven approach to building a high-performance architecture.

There are 5 best practice area topics:

Architecture selection: The optimal solution for a particular workload varies, and solutions often combine multiple approaches. Well-Architected workloads use multiple solutions and allow different features to improve performance.�AWS resources are available in many types and configurations, which makes it easier to find an approach that closely matches your needs. You can also find options that are not easily achievable with on-premises infrastructure. For example, a managed service such as Amazon DynamoDB provides a fully managed NoSQL database with single-digit millisecond latency at any scale.�This focus area shares guidance and best practices on how to select efficient, high-performing cloud resources and architecture patterns.

Compute and hardware: The optimal compute choice for a particular workload can vary based on application design, usage patterns, and configuration settings. Architectures may use different compute choices for various components and allow different features to improve performance. Selecting the wrong compute choice for an architecture can lead to lower performance efficiency.�This focus area shares guidance and best practices on how to identify and optimize compute options for performance efficiency in the cloud.

Data management: The optimal data management solution for a particular system varies based on the kind of data type (block, file, or object), access patterns (random or sequential), required throughput, frequency of access (online, offline, archival), frequency of update (WORM, dynamic), and availability and durability constraints. Well-Architected workloads use purpose-built data stores which allow different features to improve performance.�This focus area shares guidance and best practices for optimizing data storage, movement and access patterns, and performance efficiency of data stores.�
Networking and content delivery: The optimal networking solution for a workload varies based on latency, throughput requirements, jitter, and bandwidth. Physical constraints, such as user or on-premises resources, determine location options. These constraints can be offset with edge locations or resource placement.�On AWS, networking is virtualized and is available in a number of different types and configurations. This makes it easier to match your networking needs. AWS offers product features (for example, Enhanced Networking, Amazon EC2 networking optimized instances, Amazon S3 transfer acceleration, and dynamic Amazon CloudFront) to optimize network traffic. AWS also offers networking features (for example, Amazon Route 53 latency routing, Amazon VPC endpoints, AWS Direct Connect, and AWS Global Accelerator) to reduce network distance or jitter.�This focus area shares guidance and best practices to design, configure, and operate efficient networking and content delivery solutions in the cloud.�
Process and culture: When architecting workloads, there are principles and practices that you can adopt to help you better run efficient high-performing cloud workloads. This focus area offers best practices to help adopt a culture that fosters performance efficiency of cloud workloads.

Consider these key principles to build this culture:

Infrastructure as code: Define your infrastructure as code using approaches such as AWS CloudFormation templates. The use of templates allows you to place your infrastructure into source control alongside your application code and configurations. This allows you to apply the same practices you use to develop software in your infrastructure so you can iterate rapidly.
Deployment pipeline: Use a continuous integration/continuous deployment (CI/CD) pipeline (for example, source code repository, build systems, deployment, and testing automation) to deploy your infrastructure. This allows you to deploy in a repeatable, consistent, and low-cost fashion as you iterate.
Well-defined metrics: Set up and monitor metrics to capture key performance indicators (KPIs). We recommend that you use both technical and business metrics. For websites or mobile apps, key metrics are capturing time-to-first-byte or rendering. Other generally applicable metrics include thread count, garbage collection rate, and wait states. Business metrics, such as the aggregate cumulative cost per request, can alert you to ways to drive down costs. Carefully consider how you plan to interpret metrics. For example, you could choose the maximum or 99th percentile instead of the average.
Performance test automatically: As part of your deployment process, automatically start performance tests after the quicker running tests have passed successfully. The automation should create a new environment, set up initial conditions such as test data, and then run a series of benchmarks and load tests. Results from these tests should be tied back to the build so you can track performance changes over time. For long-running tests, you can make this part of the pipeline asynchronous from the rest of the build. Alternatively, you could run performance tests overnight using Amazon EC2 Spot Instances.
Load generation: You should create a series of test scripts that replicate synthetic or prerecorded user journeys. These scripts should be idempotent and not coupled, and you might need to include pre-warming scripts to yield valid results. As much as possible, your test scripts should replicate the behavior of usage in production. You can use software or software-as-a-service (SaaS) solutions to generate the load. Consider using AWS Marketplace solutions and Spot Instances — they can be cost-effective ways to generate the load.
Performance visibility: Key metrics should be visible to your team, especially metrics against each build version. This allows you to see any significant positive or negative trend over time. You should also display metrics on the number of errors or exceptions to make sure you are testing a working system.
Visualization: Use visualization techniques that make it clear where performance issues, hot spots, wait states, or low utilization is occurring. Overlay performance metrics over architecture diagrams — call graphs or code can help identify issues quickly.
Regular review process: Architectures performing poorly is usually the result of a non-existent or broken performance review process. If your architecture is performing poorly, implementing a performance review process allows you to drive iterative improvement.
Continual optimization: Adopt a culture to continually optimize the performance efficiency of your cloud workload.

15 of 23

Well Architected

Framework�Pilar Excelência

Operacional

Implemente Observabilidade

Faça mudanças frequentes, pequenas e reversíveis

Aprenda com todos os eventos operacionais e métricas

Use serviços gerenciados

Most changes were made by human beings following runbooks that were often out of date

It was easy to become very focused on the technology metrics rather than business outcomes

Because making change was difficult and risky, we tended not to want to do it often and therefore tended to batch changes into large releases

We rarely simulated failures or events as we were too busy fighting fires from real failures

We were so busy reacting to situations it was hard to take the time to extract learnings

It was hard to keep information current as we were making changes to everything to fight fires, every server was a snowflake.

Organize teams around business outcomes: The ability of a team to achieve business outcomes comes from leadership vision, effective operations, and a business-aligned operating model. Leadership should be fully invested and committed to a CloudOps transformation with a suitable cloud operating model that incentivizes teams to operate in the most efficient way and meet business outcomes. The right operating model uses people, process, and technology capabilities to scale, optimize for productivity, and differentiate through agility, responsiveness, and adaptation. The organization's long-term vision is translated into goals that are communicated across the enterprise to stakeholders and consumers of your cloud services. Goals and operational KPIs are aligned at all levels. This practice sustains the long-term value derived from implementing the following design principles.
Implement observability for actionable insights: Gain a comprehensive understanding of workload behavior, performance, reliability, cost, and health. Establish key performance indicators (KPIs) and leverage observability telemetry to make informed decisions and take prompt action when business outcomes are at risk. Proactively improve performance, reliability, and cost based on actionable observability data.
Safely automate where possible: In the cloud, you can apply the same engineering discipline that you use for application code to your entire environment. You can define your entire workload and its operations (applications, infrastructure, configuration, and procedures) as code, and update it. You can then automate your workload’s operations by initiating them in response to events. In the cloud, you can employ automation safety by configuring guardrails, including rate control, error thresholds, and approvals. Through effective automation, you can achieve consistent responses to events, limit human error, and reduce operator toil.
Make frequent, small, reversible changes: Design workloads that are scalable and loosely coupled to permit components to be updated regularly. Automated deployment techniques together with smaller, incremental changes reduces the blast radius and allows for faster reversal when failures occur. This increases confidence to deliver beneficial changes to your workload while maintaining quality and adapting quickly to changes in market conditions.
Refine operations procedures frequently: As you evolve your workloads, evolve your operations appropriately. As you use operations procedures, look for opportunities to improve them. Hold regular reviews and validate that all procedures are effective and that teams are familiar with them. Where gaps are identified, update procedures accordingly. Communicate procedural updates to all stakeholders and teams. Gamify your operations to share best practices and educate teams.
Anticipate failure: Maximize operational success by driving failure scenarios to understand the workload’s risk profile and its impact on your business outcomes. Test the effectiveness of your procedures and your team’s response against these simulated failures. Make informed decisions to manage open risks that are identified by your testing.
Learn from all operational events and metrics: Drive improvement through lessons learned from all operational events and failures. Share what is learned across teams and through the entire organization. Learnings should highlight data and anecdotes on how operations contribute to business outcomes.
Use managed services: Reduce operational burden by using AWS managed services where possible. Build operational procedures around interactions with those services.

16 of 23

Aumentando o Throughput - RDS

Leitura

Escrita

Index consciente

Buffer pool

Paralelismo consciente

Escrever em batches

Sharding

Réplicas de leitura

Sharding

Otimizador

Parâmetros

Rotinas de�Manutenção

Minimizar constraints

Particionamento

Pooling

Carga em lote

Particionamento

Parâmetros

17 of 23

Aumentando o Throughput - DynamoDB

Leitura

Escrita

Menor item possível

DynamoDB Accelerator (DAX)

Artifical Sharding

Particionamento Vertical

Modelagem

Modo de capacidade

Paginação

TTL

Modelagem

GSIs

18 of 23

Caching

19 of 23

Padrões de Persistência distribuída

API Composition

20 of 23

Padrões de Persistência distribuída

CQRS�(Command Query Responsibility Segregation)

21 of 23

Padrões de Persistência distribuída

Saga Pattern

22 of 23

Padrões de Persistência distribuída

Event Sourcing

23 of 23

Linkedin:

linkedin.com/in/leonardo-ciccone

Youtube:

youtube.com/c/CafécomCloud

Instagram:

@cafecomcloud

Obrigado!

Conecte-se comigo!