diff --git a/docs/arquitetura-cloud/arquitetura-cloud.drawio b/docs/arquitetura-cloud/arquitetura-cloud.drawio index fafe1c1..114fb71 100644 --- a/docs/arquitetura-cloud/arquitetura-cloud.drawio +++ b/docs/arquitetura-cloud/arquitetura-cloud.drawio @@ -1,6 +1,6 @@ - + @@ -316,7 +316,7 @@ - + @@ -445,7 +445,7 @@ - + @@ -466,7 +466,7 @@ - + @@ -497,7 +497,7 @@ - + @@ -509,8 +509,8 @@ - - + + @@ -560,8 +560,8 @@ - - + + @@ -587,7 +587,7 @@ - + @@ -645,14 +645,14 @@ - + - - + + diff --git a/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.png b/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.png index 047a673..8a6edb6 100644 Binary files a/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.png and b/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.png differ diff --git a/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.svg b/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.svg index 2c92f60..ce84faa 100644 --- a/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.svg +++ b/docs/arquitetura-cloud/dark/arquitetura-cloud.drawio.svg @@ -1,4 +1,4 @@ -
AWS Cloud
AWS Edge Services
Security group
Amazon Elastic Kubernetes Service (EKS)
controlplane
Control plane
Node
Region | US East (Virginia) | us-east-1
AWS Account
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
Node
kubeletk-proxy
containerd
kubeletk-proxy
containerd
etcd
etcd
Node Group
Auto Scaling group
c-c-m
Cloud controller manager
api
API server
sched
Scheduler
c-m
Controller manager
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
kubeletk-proxy
containerd
Cloud provider API
🛈 Em produção, estamos utilizando o plug-in de CNI padrão da AWS: O Amazon VPC CNI plugin for Kubernetes.

🛈 Optamos por um Node Group no EC2 devido ao custo mais baixo quando comparado a opção serverless fornecida pelo AWS Fargate.

🛈 Nosso Node Group do EKS é composto por 3 instâncias EC2 do tipo t2.medium

🛈 Cada instância t2.medium é capaz de executar 3 Pod da nossa aplicação, que requer 250m de CPU e 512Mi de memória. Mais instâncias t2.medium serão provisionadas pelo EC2 Auto Scalling quando, e se necessário. 

🛈 Estamos utilizando o Amazon Elastic Container Registry (ECR) como container Registry para armazenar e gerenciar as nossas imagens OCI do Docker.

🛈 A versão do Kubernetes em produção é a v1.28
Amazon Elastic Container Registry
VPC
Availability Zone
Availability Zone
Availability Zone
AWS API Gateway
Elastic Load Balancer
Cognito
Amazon RDS para PostgreSQL
Master
Route 53
WAF
CloudFront
Secrets Manager
Secrets Manager
RDS Multi-AZ DB Cluster
Amazon RDS para PostgreSQL
Read replica
Amazon RDS para PostgreSQL
Read replica
RDS Proxy
🛈 O banco de dados está provisionado em 3 Availability Zones diferentes, com replicas read-only, a fim de garantir a alta disponibilidade.

🛈 O RDS Proxy faz o reaproveitamento de conexões com o banco de dados, contribuindo para a escalabilidade da aplicação.

🛈 O ElastiCache for Redis será configurado com a eviction policy LFU - Least Frequently Used a fim de manter em cache os dados dos profissionais mais procurados.

🛈 O KMS armazena a chave de criptografia do Banco de Dados RDS, gerenciada pela AWS.

🛈 O AWS Secrets Manager armazena a senha do usuário master do banco de dados, com rotação automática de 7 em 7 dias.

🛈 O Architecture Decision Records (ADR) disponível na documentação no GitHub Wiki detalha as motivações por trás da escolha do modelo relacional.

🛈 Optamos também por provisionar um DynamoDB para armazenar metadados dos arquivos armazenados no bucket do S3, com schema flexível.

🛈 O AWS Backup armazena backups do banco de dados RDS e das tabelas do DynamoDB.
ElastiCache for Redis
Certificate Manager
Shield
S3
🛈 O WAF ajuda a manter a aplicação segura e, em conjunto com o AWS Shield, também protege a aplicação conta ataques DDoS.
DynamoDB
KMS
AWS CloudWatch
AWS Config
🛈 O API Gateway fará a autenticação dos Médicos e Pacientes em conjunto com o Cognito como authorizer.
🛈 O Amazon GuardDuty monitora a conta e os workloads para detectar atividades mal-intencionadas em tempo real.
SNS
🛈 O Amazon SNS - Simple Notification Service dispara e-mails de notificação para os Pacientes, informando quando a consulta é aceita ou recusada pelo Médico.
SQS
KMS
🛈 O monitoramento do cluster K8s e da aplicação será feito no Amazon CloudWatch Logs.
Lambda
SNS
🛈 A geração do link da teleconsulta será feita através da Google Meet REST API, um fornecedor externo, que pode não ser capaz de lidar com picos de usuários simultâneos quando o HPA do K8s escalar a aplicação.

🛈 Optamos então por tornar o processo de geração do link da teleconsulta assíncrono para que seja possível lidar com picos de acessos sem indisponibilizar ou prejudicar a performance da aplicação em cenários de carga alta.

🛈 Uma mensagem será publicada pela aplicação na fila "consulta-marcada" no SQS sempre que uma consulta for marcada.

🛈 A Lambda function de nome "health-med-teleconsulta" fará a geração do link de forma assíncrona e irá envia-lo para o paciente por e-mail e/ou SMS, usando o Amazon SNS.

🛈 Após gerar o link da teleconsulta com sucesso, uma menagem será publicada pela Lambda function na fila "link-teleconsulta-gerado" no SQS, que posteriormente será consumida pela aplicação.

🛈 Caso acorra alguma falha ao gerar o link da teleconsulta, uma mensagem será publicada na fila "falha-geracao-teleconsulta" de ação compensatória.

🛈 O monitoramento da Lambda function é feito no CloudWatch.
IAM
AWS GuardDuty
AWS Backup
🛈 O IAM é peça fundamental na implementação da estratégia de segurança Zero Trust na nuvem, restringindo o acesso aos recursos.
AWS CloudWatch
Médicos e Pacientes
DIAGRAMA DE ARQUITETURA CLOUD
Cliente: Health&Med
Versão: v0.1
GitHub
Public Internet
🛈 A infraestrutura será provisionada e versionada pelo Terraform Cloud.

🛈 A AWS provê todos os recursos para que possamos adequar a solução a Lei Geral de Proteção de Dados Pessoais (LGPD) e também a HIPAA – Lei de portabilidade e responsabilidade de provedores de saúde de 1996 dos EUA.
hpa
HorizontalPodAutoscaler
(name: health-med-api)
minReplicas: 1
maxReplicas: 100
ConfigMap
(name: health-med-api-config)
ns
Namespace
(name: rms)
rs
ReplicaSet
replicas: 3
🛈 O ReplicaSet de nome health-med-api é gerenciado pelo Deployment de mesmo nome logo acima.

🛈 O ConfigMap de nome health-med-api-config armazena variáveis de ambiente da aplicação.

🛈 O Deployment pode ser escalado horizontalmente, automaticamente, para até 100 Pods pelo HorizontalPodAutoscaler com base nas métricas fornecidas internamente pelo Metrics Server quando os Pods atingirem 50% de uso de CPU, em média.

🛈 Optamos por utilizar o Amazon RDS como banco de dados no ambiente de produção, na AWS. Em nosso ambiente de desenvolvimento optamos por manter o banco de dados no cluster Kubernetes, no mesmo namespace da aplicação. Em nosso ambiente de desenvolvimento local, um Deployment adicional
para o banco de dados foi criado, além de um PersistentVolume e um PersistentVolumeClaim do tipo hostPath. No ambiente de desenvolvimento adicionamos também um ConfigMap contendo variáveis de ambiente do SGBD e um Service do tipo NodePort para permitir a conexão da aplicação com o banco de dados.
🛈 Os manifestos yaml do Kubernetes estão localizados na pasta /k8s no GitHub.
svc
Service
(name: health-med-api)
type: LoadBalancer
deploy
Deployment
(name: rms-api-monolito)
health-med-api:latest
pod
health-med-api:latest
pod
health-med-api:latest
pod
KUBERNETES LOGICAL ARCHITECTURE
kubectl
🛈 O bucket no S3 será configurado com a classe de armazenamento S3 Glacier Instant Retrieval (GLACIER_IR), recomendada pela AWS para arquivamento de imagens médicas e arquivos que precisam de acesso imediato.

🛈 O KMS irá armazenar a chave de criptografia do Bucket (SSE-KMS).

🛈 O Bucket S3 é privado e o controle de acesso ao bucket será feito pela aplicação, em conjunto com o AWS Cognito.

🛈 O compartilhamento seguro de arquivos será feito através de URLs pré-assinados do Amazon S3.
Google Meet REST API
🛈 A imagem de container é gerada pelo workflow de CI/CD no GitHub Actions.

🛈 O workflow de CI/CD só executa o deploy da aplicação após a execução bem sucedida de todos os testes.

🛈 A análise estática do código-fonte é feita pelo SonarCloud.
\ No newline at end of file +
AWS Cloud
AWS Edge Services
Security group
Amazon Elastic Kubernetes Service (EKS)
controlplane
Control plane
Node
Region | US East (Virginia) | us-east-1
AWS Account
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
Node
kubeletk-proxy
containerd
kubeletk-proxy
containerd
etcd
etcd
Node Group
Auto Scaling group
c-c-m
Cloud controller manager
api
API server
sched
Scheduler
c-m
Controller manager
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
kubeletk-proxy
containerd
Cloud provider API
🛈 Em produção, estamos utilizando o plug-in de CNI padrão da AWS: O Amazon VPC CNI plugin for Kubernetes.

🛈 Optamos por um Node Group no EC2 devido ao custo mais baixo quando comparado a opção serverless fornecida pelo AWS Fargate.

🛈 Nosso Node Group do EKS é composto por 3 instâncias EC2 do tipo t2.medium

🛈 Cada instância t2.medium é capaz de executar 3 Pod da nossa aplicação, que requer 250m de CPU e 512Mi de memória. Mais instâncias t2.medium serão provisionadas pelo EC2 Auto Scalling quando, e se necessário. 

🛈 Estamos utilizando o Amazon ECR como container Registry para armazenar e gerenciar as nossas imagens OCI do Docker.

🛈 Estamos utilizando o plug-in de CSI do AWS Secrets Manager no K8s para acessar credenciais sensíveis através de uma ServiceAccount, assumindo uma role do IAM.

🛈 A versão do Kubernetes em produção é a v1.28
Amazon Elastic Container Registry
VPC
Availability Zone
Availability Zone
Availability Zone
AWS API Gateway
Elastic Load Balancer
Cognito
Amazon RDS para PostgreSQL
Master
Route 53
WAF
CloudFront
Secrets Manager
Secrets Manager
RDS Multi-AZ DB Cluster
Amazon RDS para PostgreSQL
Read replica
Amazon RDS para PostgreSQL
Read replica
RDS Proxy
🛈 O banco de dados está provisionado em 3 Availability Zones diferentes, com replicas read-only, a fim de garantir a alta disponibilidade.

🛈 O RDS Proxy faz o reaproveitamento de conexões com o banco de dados, contribuindo para a escalabilidade da aplicação.

🛈 O ElastiCache for Redis será configurado com a eviction policy LFU - Least Frequently Used a fim de manter em cache os dados dos profissionais mais procurados.

🛈 O KMS armazena a chave de criptografia do Banco de Dados RDS, gerenciada pela AWS.

🛈 O AWS Secrets Manager armazena a senha do usuário master do banco de dados, com rotação automática de 7 em 7 dias.

🛈 O Architecture Decision Records (ADR) disponível na documentação no GitHub Wiki detalha as motivações por trás da escolha do modelo relacional.

🛈 Optamos também por provisionar um DynamoDB para armazenar metadados dos arquivos armazenados no bucket do S3, com schema flexível.

🛈 O AWS Backup armazena backups do banco de dados RDS e das tabelas do DynamoDB.
ElastiCache for Redis
Certificate Manager
Shield
S3
🛈 O WAF ajuda a manter a aplicação segura e, em conjunto com o AWS Shield, também protege a aplicação conta ataques DDoS.
DynamoDB
KMS
AWS CloudWatch
AWS Config
🛈 O API Gateway faz a autenticação dos Médicos e Pacientes em conjunto com o Cognito como authorizer.
🛈 O Amazon GuardDuty monitora a conta e os workloads para detectar atividades mal-intencionadas em tempo real.
SNS
🛈 O Amazon SNS - Simple Notification Service dispara e-mails de notificação para os Pacientes, informando quando a consulta é aceita ou recusada pelo Médico.
SQS
KMS
🛈 O monitoramento do cluster K8s e também da aplicação será feito no Amazon CloudWatch Logs.
Lambda
SNS
🛈 A geração do link da teleconsulta será feita através da Google Meet REST API, um fornecedor externo, que pode não ser capaz de lidar com picos de usuários simultâneos quando o HPA do K8s escalar a aplicação.

🛈 Optamos então por tornar o processo de geração do link da teleconsulta assíncrono para que seja possível lidar com picos de acessos sem indisponibilizar ou prejudicar a performance da aplicação em cenários de carga alta.

🛈 Uma mensagem será publicada pela aplicação na fila "consulta-marcada" no SQS sempre que uma consulta for marcada.

🛈 A Lambda function de nome health-med-teleconsulta fará a geração do link de forma assíncrona e irá envia-lo para o paciente por e-mail e/ou SMS, usando o Amazon SNS.

🛈 Após gerar o link da teleconsulta com sucesso, uma menagem será publicada pela Lambda function na fila "link-teleconsulta-gerado" no SQS, que posteriormente será consumida pela aplicação.

🛈 Caso acorra alguma falha ao gerar o link da teleconsulta, uma mensagem será publicada na fila "falha-geracao-teleconsulta" de ação compensatória.

🛈 O monitoramento da Lambda function é feito no CloudWatch.
IAM
AWS GuardDuty
AWS Backup
🛈 O IAM é peça fundamental na implementação da estratégia de segurança Zero Trust na nuvem, restringindo o acesso aos recursos.

🛈 Todas as policies do IAM são gerenciadas pelo Terrador e versionadas no GitHub.
AWS CloudWatch
Médicos e Pacientes
DIAGRAMA DE ARQUITETURA CLOUD
Cliente: Health&Med
Versão: v0.1
GitHub
Public Internet
🛈 O workflow de CI/CD no GitHub Actions faz apply do plano de execução do Terraform após aprovação da PR e análise estática no SonarCloud.

🛈 O state do Terraform é armazenado e gerenciado pelo Terraform Cloud.

🛈 A AWS provê todos os recursos para que possamos adequar a solução a Lei Geral de Proteção de Dados Pessoais (LGPD) e também a HIPAA – Lei de portabilidade e responsabilidade de provedores de saúde de 1996 dos EUA.
hpa
HorizontalPodAutoscaler
(name: health-med-api)
minReplicas: 1
maxReplicas: 100
ConfigMap
(name: health-med-api-config)
ns
Namespace
(name: rms)
rs
ReplicaSet
replicas: 3
🛈 O ReplicaSet de nome health-med-api é gerenciado pelo Deployment de mesmo nome logo acima.

🛈 O ConfigMap de nome health-med-api-config armazena variáveis de ambiente não sensíveis da aplicação.

🛈 O Deployment pode ser escalado horizontalmente, automaticamente, para até 100 Pods pelo HorizontalPodAutoscaler com base nas métricas fornecidas internamente pelo Metrics Server quando os Pods atingirem 50% de uso de CPU, em média.
🛈 Os manifestos yaml do Kubernetes estão localizados na pasta /k8s no GitHub.
svc
Service
(name: health-med-api)
type: LoadBalancer
deploy
Deployment
(name: rms-api-monolito)
health-med-api:latest
pod
health-med-api:latest
pod
health-med-api:latest
pod
KUBERNETES LOGICAL ARCHITECTURE
kubectl
🛈 O bucket no S3 será configurado com a classe de armazenamento S3 Glacier Instant Retrieval (GLACIER_IR), recomendada pela AWS para arquivamento de imagens médicas e arquivos que precisam de acesso imediato.

🛈 O KMS armazena a chave de criptografia do Bucket (SSE-KMS).

🛈 O Bucket S3 é privado e o controle de acesso ao bucket é feito pela aplicação, em conjunto com o AWS Cognito através de JSON Web Tokens (JWT).

🛈 O compartilhamento seguro de arquivos é feito através de URLs pré-assinadas.
Google Meet REST API
🛈 A imagem de container é gerada pelo workflow de CI/CD no GitHub Actions.

🛈 O workflow de CI/CD só executa o deploy da aplicação após a execução bem sucedida de todos os testes.

🛈 A análise estática do código-fonte é feita pelo SonarCloud.
\ No newline at end of file diff --git a/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.png b/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.png index 4f30548..b7c098d 100644 Binary files a/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.png and b/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.png differ diff --git a/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.svg b/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.svg index fc5a848..2f5a3fb 100644 --- a/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.svg +++ b/docs/arquitetura-cloud/light/arquitetura-cloud.drawio.svg @@ -1,4 +1,4 @@ -
AWS Cloud
AWS Edge Services
Security group
Amazon Elastic Kubernetes Service (EKS)
controlplane
Control plane
Node
Region | US East (Virginia) | us-east-1
AWS Account
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
Node
kubeletk-proxy
containerd
kubeletk-proxy
containerd
etcd
etcd
Node Group
Auto Scaling group
c-c-m
Cloud controller manager
api
API server
sched
Scheduler
c-m
Controller manager
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
kubeletk-proxy
containerd
Cloud provider API
🛈 Em produção, estamos utilizando o plug-in de CNI padrão da AWS: O Amazon VPC CNI plugin for Kubernetes.

🛈 Optamos por um Node Group no EC2 devido ao custo mais baixo quando comparado a opção serverless fornecida pelo AWS Fargate.

🛈 Nosso Node Group do EKS é composto por 3 instâncias EC2 do tipo t2.medium

🛈 Cada instância t2.medium é capaz de executar 3 Pod da nossa aplicação, que requer 250m de CPU e 512Mi de memória. Mais instâncias t2.medium serão provisionadas pelo EC2 Auto Scalling quando, e se necessário. 

🛈 Estamos utilizando o Amazon Elastic Container Registry (ECR) como container Registry para armazenar e gerenciar as nossas imagens OCI do Docker.

🛈 A versão do Kubernetes em produção é a v1.28
Amazon Elastic Container Registry
VPC
Availability Zone
Availability Zone
Availability Zone
AWS API Gateway
Elastic Load Balancer
Cognito
Amazon RDS para PostgreSQL
Master
Route 53
WAF
CloudFront
Secrets Manager
Secrets Manager
RDS Multi-AZ DB Cluster
Amazon RDS para PostgreSQL
Read replica
Amazon RDS para PostgreSQL
Read replica
RDS Proxy
🛈 O banco de dados está provisionado em 3 Availability Zones diferentes, com replicas read-only, a fim de garantir a alta disponibilidade.

🛈 O RDS Proxy faz o reaproveitamento de conexões com o banco de dados, contribuindo para a escalabilidade da aplicação.

🛈 O ElastiCache for Redis será configurado com a eviction policy LFU - Least Frequently Used a fim de manter em cache os dados dos profissionais mais procurados.

🛈 O KMS armazena a chave de criptografia do Banco de Dados RDS, gerenciada pela AWS.

🛈 O AWS Secrets Manager armazena a senha do usuário master do banco de dados, com rotação automática de 7 em 7 dias.

🛈 O Architecture Decision Records (ADR) disponível na documentação no GitHub Wiki detalha as motivações por trás da escolha do modelo relacional.

🛈 Optamos também por provisionar um DynamoDB para armazenar metadados dos arquivos armazenados no bucket do S3, com schema flexível.

🛈 O AWS Backup armazena backups do banco de dados RDS e das tabelas do DynamoDB.
ElastiCache for Redis
Certificate Manager
Shield
S3
🛈 O WAF ajuda a manter a aplicação segura e, em conjunto com o AWS Shield, também protege a aplicação conta ataques DDoS.
DynamoDB
KMS
AWS CloudWatch
AWS Config
🛈 O API Gateway fará a autenticação dos Médicos e Pacientes em conjunto com o Cognito como authorizer.
🛈 O Amazon GuardDuty monitora a conta e os workloads para detectar atividades mal-intencionadas em tempo real.
SNS
🛈 O Amazon SNS - Simple Notification Service dispara e-mails de notificação para os Pacientes, informando quando a consulta é aceita ou recusada pelo Médico.
SQS
KMS
🛈 O monitoramento do cluster K8s e da aplicação será feito no Amazon CloudWatch Logs.
Lambda
SNS
🛈 A geração do link da teleconsulta será feita através da Google Meet REST API, um fornecedor externo, que pode não ser capaz de lidar com picos de usuários simultâneos quando o HPA do K8s escalar a aplicação.

🛈 Optamos então por tornar o processo de geração do link da teleconsulta assíncrono para que seja possível lidar com picos de acessos sem indisponibilizar ou prejudicar a performance da aplicação em cenários de carga alta.

🛈 Uma mensagem será publicada pela aplicação na fila "consulta-marcada" no SQS sempre que uma consulta for marcada.

🛈 A Lambda function de nome "health-med-teleconsulta" fará a geração do link de forma assíncrona e irá envia-lo para o paciente por e-mail e/ou SMS, usando o Amazon SNS.

🛈 Após gerar o link da teleconsulta com sucesso, uma menagem será publicada pela Lambda function na fila "link-teleconsulta-gerado" no SQS, que posteriormente será consumida pela aplicação.

🛈 Caso acorra alguma falha ao gerar o link da teleconsulta, uma mensagem será publicada na fila "falha-geracao-teleconsulta" de ação compensatória.

🛈 O monitoramento da Lambda function é feito no CloudWatch.
IAM
AWS GuardDuty
AWS Backup
🛈 O IAM é peça fundamental na implementação da estratégia de segurança Zero Trust na nuvem, restringindo o acesso aos recursos.
AWS CloudWatch
Médicos e Pacientes
DIAGRAMA DE ARQUITETURA CLOUD
Cliente: Health&Med
Versão: v0.1
GitHub
Public Internet
🛈 A infraestrutura será provisionada e versionada pelo Terraform Cloud.

🛈 A AWS provê todos os recursos para que possamos adequar a solução a Lei Geral de Proteção de Dados Pessoais (LGPD) e também a HIPAA – Lei de portabilidade e responsabilidade de provedores de saúde de 1996 dos EUA.
hpa
HorizontalPodAutoscaler
(name: health-med-api)
minReplicas: 1
maxReplicas: 100
ConfigMap
(name: health-med-api-config)
ns
Namespace
(name: rms)
rs
ReplicaSet
replicas: 3
🛈 O ReplicaSet de nome health-med-api é gerenciado pelo Deployment de mesmo nome logo acima.

🛈 O ConfigMap de nome health-med-api-config armazena variáveis de ambiente da aplicação.

🛈 O Deployment pode ser escalado horizontalmente, automaticamente, para até 100 Pods pelo HorizontalPodAutoscaler com base nas métricas fornecidas internamente pelo Metrics Server quando os Pods atingirem 50% de uso de CPU, em média.

🛈 Optamos por utilizar o Amazon RDS como banco de dados no ambiente de produção, na AWS. Em nosso ambiente de desenvolvimento optamos por manter o banco de dados no cluster Kubernetes, no mesmo namespace da aplicação. Em nosso ambiente de desenvolvimento local, um Deployment adicional
para o banco de dados foi criado, além de um PersistentVolume e um PersistentVolumeClaim do tipo hostPath. No ambiente de desenvolvimento adicionamos também um ConfigMap contendo variáveis de ambiente do SGBD e um Service do tipo NodePort para permitir a conexão da aplicação com o banco de dados.
🛈 Os manifestos yaml do Kubernetes estão localizados na pasta /k8s no GitHub.
svc
Service
(name: health-med-api)
type: LoadBalancer
deploy
Deployment
(name: rms-api-monolito)
health-med-api:latest
pod
health-med-api:latest
pod
health-med-api:latest
pod
KUBERNETES LOGICAL ARCHITECTURE
kubectl
🛈 O bucket no S3 será configurado com a classe de armazenamento S3 Glacier Instant Retrieval (GLACIER_IR), recomendada pela AWS para arquivamento de imagens médicas e arquivos que precisam de acesso imediato.

🛈 O KMS irá armazenar a chave de criptografia do Bucket (SSE-KMS).

🛈 O Bucket S3 é privado e o controle de acesso ao bucket será feito pela aplicação, em conjunto com o AWS Cognito.

🛈 O compartilhamento seguro de arquivos será feito através de URLs pré-assinados do Amazon S3.
Google Meet REST API
🛈 A imagem de container é gerada pelo workflow de CI/CD no GitHub Actions.

🛈 O workflow de CI/CD só executa o deploy da aplicação após a execução bem sucedida de todos os testes.

🛈 A análise estática do código-fonte é feita pelo SonarCloud.
\ No newline at end of file +
AWS Cloud
AWS Edge Services
Security group
Amazon Elastic Kubernetes Service (EKS)
controlplane
Control plane
Node
Region | US East (Virginia) | us-east-1
AWS Account
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
Node
kubeletk-proxy
containerd
kubeletk-proxy
containerd
etcd
etcd
Node Group
Auto Scaling group
c-c-m
Cloud controller manager
api
API server
sched
Scheduler
c-m
Controller manager
health-med-api:latest
pod
health-med-api:latest
health-med-api:latest
pod
EC2 Instance
pod
Node
kubeletk-proxy
containerd
Cloud provider API
🛈 Em produção, estamos utilizando o plug-in de CNI padrão da AWS: O Amazon VPC CNI plugin for Kubernetes.

🛈 Optamos por um Node Group no EC2 devido ao custo mais baixo quando comparado a opção serverless fornecida pelo AWS Fargate.

🛈 Nosso Node Group do EKS é composto por 3 instâncias EC2 do tipo t2.medium

🛈 Cada instância t2.medium é capaz de executar 3 Pod da nossa aplicação, que requer 250m de CPU e 512Mi de memória. Mais instâncias t2.medium serão provisionadas pelo EC2 Auto Scalling quando, e se necessário. 

🛈 Estamos utilizando o Amazon ECR como container Registry para armazenar e gerenciar as nossas imagens OCI do Docker.

🛈 Estamos utilizando o plug-in de CSI do AWS Secrets Manager no K8s para acessar credenciais sensíveis através de uma ServiceAccount, assumindo uma role do IAM.

🛈 A versão do Kubernetes em produção é a v1.28
Amazon Elastic Container Registry
VPC
Availability Zone
Availability Zone
Availability Zone
AWS API Gateway
Elastic Load Balancer
Cognito
Amazon RDS para PostgreSQL
Master
Route 53
WAF
CloudFront
Secrets Manager
Secrets Manager
RDS Multi-AZ DB Cluster
Amazon RDS para PostgreSQL
Read replica
Amazon RDS para PostgreSQL
Read replica
RDS Proxy
🛈 O banco de dados está provisionado em 3 Availability Zones diferentes, com replicas read-only, a fim de garantir a alta disponibilidade.

🛈 O RDS Proxy faz o reaproveitamento de conexões com o banco de dados, contribuindo para a escalabilidade da aplicação.

🛈 O ElastiCache for Redis será configurado com a eviction policy LFU - Least Frequently Used a fim de manter em cache os dados dos profissionais mais procurados.

🛈 O KMS armazena a chave de criptografia do Banco de Dados RDS, gerenciada pela AWS.

🛈 O AWS Secrets Manager armazena a senha do usuário master do banco de dados, com rotação automática de 7 em 7 dias.

🛈 O Architecture Decision Records (ADR) disponível na documentação no GitHub Wiki detalha as motivações por trás da escolha do modelo relacional.

🛈 Optamos também por provisionar um DynamoDB para armazenar metadados dos arquivos armazenados no bucket do S3, com schema flexível.

🛈 O AWS Backup armazena backups do banco de dados RDS e das tabelas do DynamoDB.
ElastiCache for Redis
Certificate Manager
Shield
S3
🛈 O WAF ajuda a manter a aplicação segura e, em conjunto com o AWS Shield, também protege a aplicação conta ataques DDoS.
DynamoDB
KMS
AWS CloudWatch
AWS Config
🛈 O API Gateway faz a autenticação dos Médicos e Pacientes em conjunto com o Cognito como authorizer.
🛈 O Amazon GuardDuty monitora a conta e os workloads para detectar atividades mal-intencionadas em tempo real.
SNS
🛈 O Amazon SNS - Simple Notification Service dispara e-mails de notificação para os Pacientes, informando quando a consulta é aceita ou recusada pelo Médico.
SQS
KMS
🛈 O monitoramento do cluster K8s e também da aplicação será feito no Amazon CloudWatch Logs.
Lambda
SNS
🛈 A geração do link da teleconsulta será feita através da Google Meet REST API, um fornecedor externo, que pode não ser capaz de lidar com picos de usuários simultâneos quando o HPA do K8s escalar a aplicação.

🛈 Optamos então por tornar o processo de geração do link da teleconsulta assíncrono para que seja possível lidar com picos de acessos sem indisponibilizar ou prejudicar a performance da aplicação em cenários de carga alta.

🛈 Uma mensagem será publicada pela aplicação na fila "consulta-marcada" no SQS sempre que uma consulta for marcada.

🛈 A Lambda function de nome health-med-teleconsulta fará a geração do link de forma assíncrona e irá envia-lo para o paciente por e-mail e/ou SMS, usando o Amazon SNS.

🛈 Após gerar o link da teleconsulta com sucesso, uma menagem será publicada pela Lambda function na fila "link-teleconsulta-gerado" no SQS, que posteriormente será consumida pela aplicação.

🛈 Caso acorra alguma falha ao gerar o link da teleconsulta, uma mensagem será publicada na fila "falha-geracao-teleconsulta" de ação compensatória.

🛈 O monitoramento da Lambda function é feito no CloudWatch.
IAM
AWS GuardDuty
AWS Backup
🛈 O IAM é peça fundamental na implementação da estratégia de segurança Zero Trust na nuvem, restringindo o acesso aos recursos.

🛈 Todas as policies do IAM são gerenciadas pelo Terrador e versionadas no GitHub.
AWS CloudWatch
Médicos e Pacientes
DIAGRAMA DE ARQUITETURA CLOUD
Cliente: Health&Med
Versão: v0.1
GitHub
Public Internet
🛈 O workflow de CI/CD no GitHub Actions faz apply do plano de execução do Terraform após aprovação da PR e análise estática no SonarCloud.

🛈 O state do Terraform é armazenado e gerenciado pelo Terraform Cloud.

🛈 A AWS provê todos os recursos para que possamos adequar a solução a Lei Geral de Proteção de Dados Pessoais (LGPD) e também a HIPAA – Lei de portabilidade e responsabilidade de provedores de saúde de 1996 dos EUA.
hpa
HorizontalPodAutoscaler
(name: health-med-api)
minReplicas: 1
maxReplicas: 100
ConfigMap
(name: health-med-api-config)
ns
Namespace
(name: rms)
rs
ReplicaSet
replicas: 3
🛈 O ReplicaSet de nome health-med-api é gerenciado pelo Deployment de mesmo nome logo acima.

🛈 O ConfigMap de nome health-med-api-config armazena variáveis de ambiente não sensíveis da aplicação.

🛈 O Deployment pode ser escalado horizontalmente, automaticamente, para até 100 Pods pelo HorizontalPodAutoscaler com base nas métricas fornecidas internamente pelo Metrics Server quando os Pods atingirem 50% de uso de CPU, em média.
🛈 Os manifestos yaml do Kubernetes estão localizados na pasta /k8s no GitHub.
svc
Service
(name: health-med-api)
type: LoadBalancer
deploy
Deployment
(name: rms-api-monolito)
health-med-api:latest
pod
health-med-api:latest
pod
health-med-api:latest
pod
KUBERNETES LOGICAL ARCHITECTURE
kubectl
🛈 O bucket no S3 será configurado com a classe de armazenamento S3 Glacier Instant Retrieval (GLACIER_IR), recomendada pela AWS para arquivamento de imagens médicas e arquivos que precisam de acesso imediato.

🛈 O KMS armazena a chave de criptografia do Bucket (SSE-KMS).

🛈 O Bucket S3 é privado e o controle de acesso ao bucket é feito pela aplicação, em conjunto com o AWS Cognito através de JSON Web Tokens (JWT).

🛈 O compartilhamento seguro de arquivos é feito através de URLs pré-assinadas.
Google Meet REST API
🛈 A imagem de container é gerada pelo workflow de CI/CD no GitHub Actions.

🛈 O workflow de CI/CD só executa o deploy da aplicação após a execução bem sucedida de todos os testes.

🛈 A análise estática do código-fonte é feita pelo SonarCloud.
\ No newline at end of file