마이크로서비스를 위한 App Mesh & Cloud Map - 김세호 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
마이크로 서비스를 위한
AWS Cloud Map & App Mesh
Saeho Kim

Complexity of modern architectures
• Wide variety of resources
• Complexity grows exponentially
• Multiple versions and stages coexist
• Infrastructure scales dynamically
• Unhealthy resources are replaced

Complexity of modern architectures
Service Discovery
Finding the location of a service provider
myapp: {10.24.34.5:8080, 10.24.34.6:8080}
mylogs: {S3bucket1, S3bucket2}

Server-side service discovery pattern
• Connections are proxied
• Discovery is abstracted away
• Availability and capacity impact
• Additional latency
Client
Service Provider
Service Provider
Service Provider
Request Request
LB +
Service
Registry
Register
Register

Client-side service discovery pattern
• Clients connect directly to providers
• Fewer components in the system
• Clients must be registry-aware
• Client-side load balancing
Client
Service Provider
Service Provider
Service Provider
Service
Registry
Request
Register
Register
Register
Query

Build the dynamic map of your cloud

Registry for all cloud resources
webserver running
on EKS
backend component
running on ECS
shared event registration
service on Lambda
shared logs on S3
payment integration
running on EC2 in
ASG
payment DB on RDS

Registry for all cloud resources
frontend.app.com backend.app.com
eventprocessor.shared logs.shared
payments.app.com payments-db.app.com

AWS Cloud Map registry
• Namespace
• Service
• Service Instance
cloudmapdemo.com
backend
Name = backend
DNS record = A
TTL = 60 sec
Health Check = Yes
Instance-1
172.10.0.1
Instance-2
172.10.0.2
Instance-3
172.10.0.3

Register resources for API + DNS discovery mode
1. aws servicediscovery create-public-dns-namespace --name cloudmapdemo.com
2. aws servicediscovery create-service --name frontend
--dns-config “NamespaceId=%namespace_id%, DnsRecords=[{Type=A, TTL=60}]”
3. aws servicediscovery register-instance --service-id %service_id% --instance-id %id%
--attributes
AWS_INSTANCE_IPV4=52.89.144.60,
stage=beta,
version=1.0,
ready=yes

Register any cloud resource for API discovery
1. aws servicediscovery create-http-namespace --name shared
2. aws servicediscovery create-service --name logs --namespace-id %namespace_id%
3. aws servicediscovery register-instance --service-id %service_id% --instance-id %id%
--attributes
ARN=arn:aws:s3:::cloudmapdemoservicelogsbeta1,
stage=beta,
shard=s_1,
read_only=no,
path=/mylogs

Secure name resolution via API calls
aws servicediscovery discover-instances --namespace-name shared --service-name logs
-->
{ "Instances": [
{
"InstanceId": "i1",
"NamespaceName": "shared",
"ServiceName": "logs",
"HealthStatus": "UNKNOWN",
"Attributes": {
"read_only": "no",
"path": "/mylogs",
"shard": "s_1",
"ARN": "arn:aws:s3:::cloudmapdemoservicelogsbeta1",
"stage": "beta”
}
}
]
}

Name resolution via DNS
dig +short A frontend.cloudmapdemo.com
-->
52.89.144.60
52.26.95.129
34.214.232.177

Attribute-based service discovery

Stage: prod

Version: 1.0

Version: 2.0
Ready: yes

Register and discover resources with custom attributes
• Incremental deployments
• Dev / Test / Prod deployments
• Smart traffic routing

1. aws servicediscovery discover-instances --namespace-name cloudmapdemo.com
--service-name frontend --query-parameters ready=yes
-->
{ "Instances": [
{
"InstanceId": "i1",
"NamespaceName": "cloudmapdemo.com",
"ServiceName": "frontend",
"HealthStatus": "UNKNOWN",
"Attributes": {
"ready": "yes",
"AWS_INSTANCE_IPV4": "52.89.144.60",
"version": "1.0",
"stage": "beta”
}
}
]
}

Handling partial failure
AWS Cloud Map provisions Amazon Route 53 health checks for IP-based
resources
• Unhealthy resources are removed from query responses
• API to check health status - getInstancesHealthStatus

1. aws servicediscovery create-service --name users
--dns-config “NamespaceId=%namespace_id%, DnsRecords=[{Type=A, TTL=60}]”
--health-check-config “Type=TCP, FailureThreshold=3”
2. aws servicediscovery register-instance --service-id %service_id --instance-id
healthy-instance –attributes AWS_INSTANCE_IPV4=52.89.144.60,AWS_INSTANCE_PORT=80
3. aws servicediscovery register-instance --service-id %service_id --instance-id
unhealthy-instance --attributes AWS_INSTANCE_IPV4=88.88.88.88,AWS_INSTANCE_PORT=80

- dig +short A users.cloudmapdemo.com
--> 52.89.144.60
- aws servicediscovery get-instances-health-status --service-id %service_id%
--> {
"Status": {
"healthy-instance": "HEALTHY",
"unhealthy-instance": "UNHEALTHY”
}
}
- aws servicediscovery discover-instances --namespace-name cloudmapdemo.com --service-
name users --health-status UNHEALTHY

Control traffic with custom health checks
AWS Cloud Map supports custom health checks that reliably and quickly
propagate health information updates
• You control when to start and stop traffic routing
• Create service with HealthCheckCustomConfig
• Use UpdateInstanceCustomHealthCheck API to set status to HEALTHY |
UNHEALTHY

AWS Cloud Map ecosystem
Amazon ECS Amazon EKSAWS App Mesh

Amazon ECS Service Discovery
Service discovery via DNS and API
- Additional attributes for ECS tasks
- Smart routing based on locality
- Support for EC2 and Fargate (1.10+)
launch types
AWS_INSTANCE_IPV4
AWS_INSTANCE_PORT
AVAILABILITY_ZONE
REGION
ECS_SERVICE_NAME
ECS_CLUSTER_NAME
EC2_INSTANCE_ID
ECS_TASK_DEFINITION_FAMILY

Kubernetes ExternalDNS Connector
frontend service frontend.app.com

AWS Cloud Map availability
US West (Oregon)
US East (N. Virginia)US West (N. California) Asia Pacific (Tokyo)
Asia Pacific (Sydney)
US East (Ohio)
Asia Pacific (Mumbai)
Asia Pacific (Seoul)
Canada (Central)
Asia Pacific (Singapore)
EU (Ireland)
EU (Frankfrut)
EU (London)

Challenges with Microservices
Control Over Service to Service Communication
Visibility into Service to Service Communication i.e., Observability
Create a culture of innovation by organizing into small DevOps teams
Ensure trust by automating security and compliance

What is needed
Consistent
communications
management
Complete visibility Failure isolation
and protection
Fine-grained
deployment controls

.NET
Go
Go
Django
.NET
Node.js
Node.js
Node.js
Java
GoNode.js
Java

Monitoring
Degraded state
.NETGo

Degraded state
Outage
Latency
Time (ms)

Resiliency patterns
Traffic shaping Rate limiting Circuit breaking Retries Throttling

Implementation options
Microservice
container
In-process
(SDK)
Out-of-process
(sidecar proxy)
Microservice
container
Proxy
Option 1 Option 2

Implementation options
Microservice
container
In-process
(SDK)
Out-of-process
(sidecar proxy)
Microservice
Container
Proxy
Option 1 Option 2

Option 1: In-process resiliency SDK
SDK maintenance
Application code changes
Retrofitting
Unknown dependencies
…
Java
Scala
Node.js
Python
C++
Django
.NET
GO
…
…
MySQL (hosted + Amazon Relational
Database Service (Amazon RDS))
Aurora
Microsoft SQL Server
PostgreSQL (hosted and Amazon
RDS)
Redis
InfluxDB
RabbitMQ
MongoDB
Amazon DynamoDB
Cassandra
…
Languages
Databases

Option 2: Side-car proxy
Decouple operational logic and SDKs
Microservice
container
Proxy
Amazon ECS task / Kubernetes Pod
Port
8081
Port
8080External traffic

Option 2: Side-car proxy
Out-of-process and language
independent:
Logging
Tracing
Metrics
Resiliency patterns
Separation of operational and business
logic
Integration with legacy services
However…

Centralized production-grade configuration
of proxies at scale is difficult

We need a control plane
Centralized location to manage configuration of proxies at scale
Dynamic configuration reload without redeploying code
Compatibility across different compute platforms
Production-grade and fully managed

Introducing AWS App Mesh
Service mesh for AWS
Observability and traffic control
Easily export logs, metrics, and traces
Client-side traffic policies—circuit breaking, retries
Routes for deployments
Works across clusters and container services
Amazon ECS
Amazon EKS
Kubernetes on EC2
AWS built and run
Managed control plane
Production-grade

AWS App Mesh configures every proxy
Microservice
Proxy

Easily deliver configuration and receive data
Infra
Operator
Application
Developer Metrics
Intent
Microservice
Proxy

Why AWS App Mesh
Libraries or application code vs. mesh
Overall—migrate to microservices safer and faster
Reduce work required
by developers
Provide operational
controls decoupled
from application logic
Use any language
or platform
Simplify visibility,
troubleshooting, and
deployments

App Mesh uses Envoy proxy
OSS project managed by CNCF
Started at Lyft in 2016
Wide community support, numerous integrations
Stable and production-proven

Why AWS App Mesh
vs. building or running your own mesh
No need to spend on
Dev to build and Ops
to maintain
Not tied to application
deployment system
(e.g., container orchestration)
Works across different
compute systems
Gradual migration,
onboard services
one at a time

Why AWS App Mesh
vs. existing control plane solutions
Works across
clusters,
container services
Integrations with AWS
and partner tools
Run by AWS for scale
and stability
Extensible architecture
from OSS base

Services connect directly

Deployments
B
B’
5%
95%
A

Traffic controls
Routing options
Service discovery
Retires
Timeouts
Error-code recognition
Routing controls
Access
Quotas
Rate limits
Weights

Application observability
+ others
Universal metrics
collection for
a wide range of
monitoring tools

App Mesh Constructs
Mesh
Virtual node
Virtual router and routes
Virtual service
Create and manage these in App
Mesh API, CLI, SDK, or
AWS Management Console
Proxies
Services
Service discovery
Configure and run proxies and
services on Amazon ECS, Fargate,
Amazon EKS, Amazon EC2
Service discovery with
AWS Cloud Map

B
A
Mesh – [sample_app]
Elastic
Load
Balancing
Virtual
node A
Service
discoveryListener Backends
Virtual
node B
Service
discoveryListener Backends
App MeshMicroservices
How it works

Virtual node
Virtual node
Service
discovery
BackendsListeners
Virtual node
Logical representation
of runtime services.
Backends
Set of destinations that this node
will communicate with (hostnames)
Service discovery
Describes how its callers locate this node
Listeners
Policies to handle
incoming traffic

Virtual router
HTTP route
Targets:
Prefix: /
B
B’
Virtual
node A
Service
discovery
Listener Backends
Virtual
node B
Service
discovery
Listener Backends
Virtual
node B’
Service
discovery
Listener Backends
B
B
B’
B’
A
Connecting microservices

Virtual router
Virtual router
HTTP route
Prefix: /
Targets:
B
B’
Destination’s virtual
router and route
Route B
Destination + weight
Route B’
New service versionB
B
B’
B’
A

Representing your sample_app in AWS App Mesh
A
B
B
C
C
D
D
Service C
Virtual router
Virtual
node C
Service D
Virtual router
Virtual
node D
Service A
Service B
Virtual
router
Virtual
node B

Today, App Mesh is generally available worldwide
Observability and traffic control
Easily export logs, metrics, and traces
Client-side load balancing, routing
AWS container services compatibility
Amazon Elastic Container Service (Amazon ECS)
Amazon Elastic Container Service for Kubernetes (Amazon EKS)
AWS Fargate
EC2 compatibility
Integrate with services running directly on EC2 instances

AWS App Mesh Availability
US West (Oregon)
US East (N. Virginia)US West (N. California) Asia Pacific (Tokyo)
Asia Pacific (Sydney)
US East (Ohio)
Asia Pacific (Mumbai)
Asia Pacific (Seoul)
Canada (Central)
Asia Pacific (Singapore)
EU (Ireland)
EU (Frankfrut)
EU (London)

Roadmap
Today
Client-side load balancing
Path-based routing
Egress traffic
AWS Cloud Map service discovery
App Mesh console
AWS X-Ray tracing
Envoy supported tracing
CloudWatch Logs, metrics
StatsD, Prometheus metrics
Amazon ECS, Fargate integration
Amazon EKS integration
Amazon EC2 integration
Near term
AWS PrivateLink
AWS Cloud Map selectors
gRPC routing
Header-based routing
Cookie-based routing
Host-based routing
Timeout policy
Retry policy
Circuit breaker policy
End-to-end encryption
Longer term
mTLS
Mesh peering
Global rate limiting
Managed ingress
Other protocols

Gateway
container
Gateway
http Colorteller
container
Colorteller
httphttp
Gateway
Proxy applies routing rules (e.g., path matching)
Proxy does the load balancing if there is more
than one Colorteller task running
Proxy does metrics, logging, and tracing
Colorteller
Proxy also does metrics, logging, and tracing
http

Next Step
• Product overview
https://aws.amazon.com/cloud-map/
https://aws.amazon.com/app-mesh
• Documentation
https://docs.aws.amazon.com/cloud-map/index.html
https://docs.aws.amazon.com/app-mesh/index.html
• Examples
https://github.com/aws/aws-app-mesh-examples
• Issues, roadmap, beta channel
https://github.com/aws/aws-app-mesh-roadmap

마이크로서비스를 위한 App Mesh & Cloud Map - 김세호 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 마이크로서비스를 위한 App Mesh & Cloud Map - 김세호 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019

Similaire à 마이크로서비스를 위한 App Mesh & Cloud Map - 김세호 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019 (20)

Plus de Amazon Web Services Korea

Plus de Amazon Web Services Korea (20)

Dernier

Dernier (20)

마이크로서비스를 위한 App Mesh & Cloud Map - 김세호 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019