aws re:invent 특집(2) – 서버리스(serverless) 마이크로서비스를 위한 일곱 가지...

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

윤석찬

@channyunAWS 테크에반젤리스트

(서버리스) 마이크로서비스를 위한7가지 모범 사례

2016년 12월 re:Invent 특집 온라인 세미나

본 발표의 주요 주제

• 모놀리식 vs. 마이크로서비스• AWS 기반 마이크로서비스 아키텍처• 마이크로서비스에 대한 7가지 모범 사례

§ 원칙 1: 각 서비스는 다른 서비스 공개 API 참조!§ 원칙 2: 최적 개발 환경 구성§ 원칙 4. 서비스별 보안에 유의하라!§ 원칙 3. 지속적인 마이크로 서비스 모니터링§ 원칙 5. API 서비스를 통한 생태계 확산§ 원칙 6. 기술 너머 조직의 변화§ 원칙 7. 자동화! 자동화!

From Monolith to Microservices

“The Monolith” 애플리케이션?

장기 개발 사이클(다수개발자 공동 참여)

운영의 어려움(특정 모듈 장애시)

애플리케이션확장성 애로

신규 출시에몇 달이 걸림

신규 기능추가에 어려움

아키텍처 유지진화의 어려움

혁신저해

고객불만족

민첩성저해

releasetestbuild

개발 및 배포 모놀리식 앱개발자

Shared libraries

Shared data

Monolith 앱의 개발 배포 및 아키텍처

마이크로서비스로의 전이

“service-orientedarchitecturecomposed ofloosely coupled elementsthat havebounded contexts”

Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)

마이크로 서비스란?


서비스들이 네트워크를통해 서로 통신한다.



서비스는 독자적으로업데이트하며, 서로영향을 주지 않는다.


“service-orientedarchitecturecomposed ofloosely coupled elementsthat havebounded contexts” 자기 완결: 다른 서비스의

내부 구조를 알지 못해도,내 서비스 코드를업데이트 할 수 있다.Adrian Cockcroft (VP of Cloud Architecture @

AWS, former Cloud Architect at Netflix)

Public API

POST /restaurantsGET /restaurants

Application/Logic(code, libraries, etc)

Data Store(eg, RDS, DynamoDB

ElastiCache, ElasticSearch)

하나의 마이크로서비스의 구성

Driversmicro-services

Paymentsmicro-service Location

micro-services

Orderingmicro-services

Restaurantmicro-service

다양한 마이크로서비스 단위

Amazon.com의 사례

= 연간 5천만회 배포

수 천개 팀 (자율적 DevOps팀)

× 마이크로서비스 아키텍처

× 지속적 배포 (CD)

× 다양한 개발 환경

(시간당 5708 회, 또는 0.63 초)

Amazon.com의 사례

Werner Vogels (CTO, Amazon.com, 2015)

AWS Cloud Based Microservices

전통적인 마이크로서비스 아키텍처

Clients RDS

HTTP

REST

EC2 Instance

Auto Scaling Group

AZ-A

AZ-B

Min > 1

Elastic Load Balancing

EC2 Instance

AWS Elastic Beanstalk

좀더 스마트하게…

.

AWS 기반 마이크로서비스 아키텍처의 진화

S3

CloudFront

RDS

ElastiCacheEC2


EC2


Static Content

Content Delivery

APILayer

ApplicationLayer

PersistencyLayer

Auto Scaling Group

Auto Scaling Group


S3

CloudFront

RDS

ElastiCache

EC2

Application Load

Balancing

Static Content

Content Delivery

APILayer

ApplicationLayer

PersistencyLayer

API Gateway

EC2 Container Service

Auto Scaling Group


S3

CloudFront

EC2

Application Load

Balancing

Static Content

Content Delivery

APILayer

ApplicationLayer

PersistencyLayer

API Gateway

EC2 Container Service

Auto Scaling Group

DynamoDB


S3

CloudFront

Static Content

Content Delivery

APILayer

ApplicationLayer

PersistencyLayer

API Gateway

DynamoDBAWS Lambda

하이브리드 마이크로서비스 아키텍처

Amazon API GatewayClients

HTTP

REST

Amazon EC2

AWSLambda

Lambda Blueprints

Amazon ECS


마이크로서비스 7가지 모범 사례

원칙 1

각 마이크로 서비스는타 서비스 공개 API를참조한다.

“Contracts” by NobMouse. No alterations other than cropping.https://www.flickr.com/photos/nobmouse/4052848608/

Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

Micro-service A Micro-service B

public API public API

원칙 1: 각 서비스는 다른 서비스 공개 API 참조!

storeRestaurant (id, name, cuisine)

storeRestaurant (id, name, cuisine)storeRestaurant (id, name, arbitrary_metadata)addReview (restaurantId, rating, comments)

storeRestaurant (id, name, arbitrary_metadata)addReview (restaurantId, rating, comments)

Version 1.0.0

Version 1.1.0

Version 2.0.0

public API

Micro-service A

원칙 1: 각 서비스는 타 서비스 API를 참조!서비스 진화에 따라 API 하위 호환성 지원 가능

AWS Lambda: 버전 기능

• Immutable 함수 버전 기능• 버전별 설정 및 Cloudwatch 통계• Cloudwatch Logs에 버전 속성 포함• 버전 출시에 따라 “label” 처리 가능• $LATEST 최신 버전

$LATEST(95) STABLE TESTING94 X93 X92

Amazon API Gateway: 스테이지 기능

Amazon API Gateway: 스테이지 변수

API Gateway Lambda Custom Domain

/prod/Resources FunctionName:stable https://api.example.com

/dev/Resources FunctionName:$LATEST https://dev.example.com

/qa/Resources FunctionName:qa https://qa.example.com

스테이지 변수에 따라 테스트 환경 설정

“Tools #2” by Juan Pablo Olmo. No alterations other than cropping.https://www.flickr.com/photos/juanpol/1562101472/

Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

원칙 2

마이크로 서비스별최적 개발 환경 구성


DynamoDB


원칙 2: 최적 개발 환경 구성

폴리글랏(Polyglot) 접근 방식을 통한 서비스 아키텍처 선택

AmazonElasticsearchService

RDSAurora

폴리글랏 마이크로서비스의 특징

• 개별적인 데이터 스토어

• 각 스토어 스키마 변경에영향이 적음

• 독자적인 확장성 제공

• 만약 트랜잭션 중 문제가발생한다면?

account-svccart-svc

DynamoDB RDS

user-svc

ElastiCache

RDS

ERROR

해결 방법 1: Correlation ID 활용

• 09-02-2015 15:03:24 ui-svc INFO [uuid-123] ……

• 09-02-2015 15:03:25 catalog-svc INFO [uuid-123] ……

• 09-02-2015 15:03:26 checkout-svc ERROR [uuid-123] ……

• 09-02-2015 15:03:27 payment-svc INFO [uuid-123] ……

• 09-02-2015 15:03:27 shipping-svc INFO [uuid-123] ……

ui-svc catalog-svc

checkout-svc

shipping-svc

payment-svc

request correlation id: “uuid-123”

correlation id: “uuid-123”

해결 방법 2: 서비스별 자체 롤백 제공

• 모든 마이크로서비스는 각자의 롤백 기능을 가져야 한다.

• 롤백이 필요할 경우, 알림이나특정 액션에서 롤백 기능 제공

• Correrlation ID를 기반으로 롤백알림 호출

Microservice

Function 1

Rollback

Commit(optional)

AWS Step Functions

• 시각적 워크플로를 사용해 분산 앱 및마이크로서비스 구성 요소 조정 및 실행

§ 자동으로 각 단계를 트리거 및 추적하고오류가 발생할 경우 재시도하므로애플리케이션이 의도대로 정상적으로 실행

§ 앱을 단계별로 배열 및 시각화할 수 있는그래픽 콘솔 제공

§ 각 단계의 상태를 기록하여, 잘못된 경우빠르게 문제를 진단하고 디버깅 가능

• 상태 변경이 일어나는 경우만 과금

AWS Step Functions - 사용 사례

메소드 호출 함수 순차 실행 DB 저장 실행 대기열

Tim Bray의 세션 강추!https://www.youtube.com/watch?v=75MRve4nv8s

AWS Step Functions - 1. 애플리케이션 단계 정의

순차 단계 분기 단계(경로 선택) 병렬 단계

AWS Step Functions - 2. 단계별 실행 상태 파악

AWS Step Functions - 3. 확장 및 앱 안정성 파악

File:Cgs01053 - Flickr - NOAA Photo Library.jpghttps://commons.wikimedia.org/wiki/File:Cgs01053_-_Flickr_-_NOAA_Photo_Library.jpg

원칙 3

지속적인 마이크로서비스 모니터링

원칙 3. 지속적인 마이크로 서비스 모니터링

• AWS 기반 모니터링 도구 활용• 모니터링 - CloudWatch§ 로깅: CloudWatch Logs

• API 외부적인 요소 모니터링§ Latency, RPS, Error rate

• API 내부적인 요소 모니터링§ CloudWatch, OS, Application

AmazonCloudWatch Logs

AWSLambda

AmazonElasticsearch Kibana

실시간 로그 대시보드 구성

Amazon API Gateway

Amazon ECS

AmazonEC2

데이터 리포팅 및 시각화

Amazon ECS

AmazonEC2

AWSLambdaAmazon API

GatewayAmazonRedshift

AmazonQuickSight

Amazon EMR

S3

Amazon Athena - 서버리스 대화식 질의 서비스

§ Amazon Athena는 표준SQL을 사용해 Amazon S3에 저장된 데이터를간편하게 분석할 수 있는대화식 쿼리 서비스

§ 서버 없이 S3에 저장한파일의 스키마 정의 후바로 질의 가능

§ 질의를 위해 스캔한 TB당5달러 비용

ü 표준 (ANSI) SQL 지원ü ETL 필요 없음ü 빠른 성능 및 자동 확장ü 데이터 전처리나 인프라 운영

필요 없음

코드 에러의 경우,

• Lambda 함수 실행 오류가 나는 경우• Cloudwatch Logs 통해 디버깅 가능• 직접 Transction Manager 함수를

별도로 만들어 Cloudwatch Logs Metric Filter 를 통해 에러 검출

ui-svc

CloudwatchLogs

CloudwatchAlarm

Transaction Manager Function

AWS X-Ray - 분산 애플리케이션 추적 서비스

• 마이크로서비스 시작과 끝에 대한 디버깅 및 추적• 서비스에 대한 시각적 토폴로지 제공• 개별 요청에 대한 로그 추적• 성능 이슈 및 오류 발생 원인에 대한 확인 및 문제 해결

호출에 대한 전체 과정 파악

사용자 요청이 애플리케이션을통과하는 전체 과정을 추적

애플리케이션 성능 개선

지연 시간이 늘어나는 위치를빠르게 확인한 후 성능이

저하되는 특정 서비스 및 경로에대한 문제 해결 가능

애플리케이션 문제 식별

트레이스 데이터 태깅 및필터링을 통해 어느 위치에서

무엇이 성능 문제를 유발하는지정확히 파악

AWS X-Ray - 서비스 맵 기능

AWS X-Ray - 데이터 태깅 및 추적 기능

AWS X-Ray - 에이전트 설치 및 추적

1. Amazon EC2

2. Amazon ECS (Docker)

3. AWS Node.JS (SDK)

“security” by Dave Bleasdale. No alterations other than cropping.https://www.flickr.com/photos/sidelong/3878741556/

Image used with permissions under Creative Commons license 2.0,Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

원칙 4

마이크로 서비스보안 유지

• 수준별 방어• 네트워크 레벨 (e.g. VPC,

Security Groups, TLS)• 서버/콘테이너/앱 레벨• IAM 정책 및 역할

• API Gateway (“Front door”)

• API Throttling

• API 키 관리• S3 버킷 정책 + KMS + IAM• 오픈 소스 도구 (e.g. Vault,

Keywhiz)

APIGateway

원칙 4. 서비스별 보안에 유의하라!

AWS Shield - Managed DDoS Protection

• 항시 네트워크 감시를 통한 감지

• Layer 3 혹은 4의 일상적 공격 패턴

감지 및 대응

• 모든 사용자에게 무료로 제공

표준 기능 고급 기능

• 대량 특수 공격에 대한 탐지 및 차단

• ELB, CloudFront, Route53 지원

• Layer 3 혹은 4의 특수 공격 대응

• AWS WAF 기능 포함

• 준 실시간 CloudWatch 알림 및 사후

분석 가능

• 24/7 전담 DDoS 대응팀 지원

• ELB, CF, Route53의 DDoS 공격에

대한 빌링 차단

• 월 3,000$ + 데이터 비용 (연간 계약)

“Lamington National Park, rainforest” by Jussarian. No alterations other than cropping.https://www.flickr.com/photos/kerr_at_large/87771074/


원칙 5

API 생태계 확산 참여

혹시회사에레스토랑정보를공개API로제공해주실수있나요?

피드백감사드립니다.필요하신경우를알려

주시면,공개로API를열어드리고향후비지니스협력도같이할수있을것

같네요!



원칙 5. API 서비스를 통한 생태계 확산

RestaurantMicro-service

15 TPS100 TPS5 TPS20 TPS

레스토랑정보API를사용하려는외부고객뿐만아니라내부고객에게도API를오픈해야겠네요!

원칙 5. API 서비스를 통한 생태계 확산

• 플랫폼 확장 고려• SLA 수준 고민

“rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping.https://www.flickr.com/photos/mattphotos/19189529/


원칙 6

기술 너머 조직 변화

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’scommunication structure.”

Melvin E. Conway, 1967

Conway’s Law

ImagefromMartinFowler’sarticleonmicroservices, athttp://martinfowler.com/articles/microservices.html

Noalterationsotherthancropping.Permission to reproduce: http://martinfowler.com/faq.html

원칙 6. 기술 너머 조직의 변화

ImagefromMartinFowler’sarticleonmicroservices, athttp://martinfowler.com/articles/microservices.html



기능별 조직에서 자율성 높은 책임 조직으로

Non-pizzaimagefromMartinFowler’sarticleonmicroservices, athttp://martinfowler.com/articles/microservices.html



기능별 조직에서 자율성 높은 책임 조직으로

Two-Pizza Team(Amazon)

“Robot”byRobin Zebrowski.Noalterationsotherthancropping.https://www.flickr.com/photos/firepile/438134733/

Image usedwithpermissionsunderCreativeCommonslicense2.0,AttributionGenericLicense(https://creativecommons.org/licenses/by/2.0/)

원칙 7

자동화! 자동화! 자동화!

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

2-pizza team delivery pipeline service원칙 7. 자동화! 자동화!

원칙 7. 자동화! 자동화! - 서버리스 자동화 도구

AWSCloudFormation

AWSCloudTrail

AWSConfig

AWS Trusted Advisor

Amazon Glacier

AmazonS3

AWS CodePipelineAWS KMSACM

Amazon CloudWatch

AWSLambda

AWS CodeDeploy

좀 더 자세한 사항은 내일 오후의 개발 도구 웨비나에 참여하세요!

Expect challenges along the way…

• 서비스 내 비지니스 도메인의 이해• 명시적 서비스 단위 분리• 서비스 지속성 및 API 운영 정책 고민• 분산 앱의 테스트/배포/운영에 대한

복잡성에 대한 고민• 모니터링/문제 해결 방법 고민• 조직 및 문화적 변화 필요

마이크로 서비스로의 여정

빠른빌드/테스트/배포가능

명확한 오너쉽 및자율적 운영

개별 마이크로서비스 확장가능

몇 분만에배포 가능

신규 기능빠르게추가 가능

빠른 운영 및개선

빠른 혁신

고객 만족

높은민첩성

마이크로 서비스의 이점

마이크로서비스 7 가지 모범 사례

• 원칙 1: 각 서비스는 다른 서비스 공개 API 참조!• 원칙 2: 최적 개발 환경 구성• 원칙 4. 서비스별 보안에 유의하라!• 원칙 3. 지속적인 마이크로 서비스 모니터링• 원칙 5. API 서비스를 통한 생태계 확산• 원칙 6. 기술 너머 조직의 변화• 원칙 7. 자동화! 자동화!

※ 총정리! http://bit.ly/awskr-reinvent-2016

신규 서비스 발표 목록

질문을 남겨주세요!

세미나 설문조사

발표 자료/녹화 영상http://bit.ly/awskr-webinar

aws re:invent 특집(2) – 서버리스(serverless) 마이크로서비스를 위한 일곱 가지...

Technology