© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
윤석찬
@channyun
AWS 테크에반젤리스트
(서버리스) 마이크로서비스를 위한
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-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)
마이크로 서비스란?
“service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
서비스들이 네트워크를
통해 서로 통신한다.
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)
“service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
서비스는 독자적으로
업데이트하며, 서로
영향을 주지 않는다.
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)
“service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts” 자기 완결: 다른 서비스의
내부 구조를 알지 못해도,
내 서비스 코드를
업데이트 할 수 있다.
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)
Public API
POST /restaurants
GET /restaurants
Application/Logic
(code, libraries, etc)
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
하나의 마이크로서비스의 구성
Drivers
micro-services
Payments
micro-service Location
micro-services
Ordering
micro-services
Restaurant
micro-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
ElastiCache
EC2
Elastic Load
Balancing
EC2
Elastic Load
Balancing
Static
Content
Content
Delivery
API
Layer
Application
Layer
Persistency
Layer
Auto Scaling
Group
Auto Scaling
Group
AWS 기반 마이크로서비스 아키텍처의 진화
S3
CloudFront
RDS
ElastiCache
EC2
Application
Load
Balancing
Static
Content
Content
Delivery
API
Layer
Application
Layer
Persistency
Layer
API
Gateway
EC2 Container
Service
Auto Scaling
Group
AWS 기반 마이크로서비스 아키텍처의 진화
S3
CloudFront
EC2
Application
Load
Balancing
Static
Content
Content
Delivery
API
Layer
Application
Layer
Persistency
Layer
API
Gateway
EC2 Container
Service
Auto Scaling
Group
DynamoDB
AWS 기반 마이크로서비스 아키텍처의 진화
S3
CloudFront
Static
Content
Content
Delivery
API
Layer
Application
Layer
Persistency
Layer
API
Gateway
DynamoDBAWS
Lambda
하이브리드 마이크로서비스 아키텍처
Amazon API
GatewayClients
HTTP
REST
Amazon
EC2
AWS
Lambda
Lambda
Blueprints
Amazon ECS
Elastic Load
Balancing
마이크로서비스 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 TESTING
94 X
93 X
92
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
마이크로 서비스별
최적 개발 환경 구성
public API public API
DynamoDB
Micro-service A Micro-service B
원칙 2: 최적 개발 환경 구성
폴리글랏(Polyglot) 접근 방식을 통한 서비스 아키텍처 선택
Amazon
Elasticsearch
Service
RDS
Aurora
폴리글랏 마이크로서비스의 특징
• 개별적인 데이터 스토어
• 각 스토어 스키마 변경에
영향이 적음
• 독자적인 확장성 제공
• 만약 트랜잭션 중 문제가
발생한다면?
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.jpg
https://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
Amazon
CloudWatch Logs
AWS
Lambda
Amazon
Elasticsearch Kibana
실시간 로그 대시보드 구성
Amazon API
Gateway
Amazon
ECS
Amazon
EC2
데이터 리포팅 및 시각화
Amazon
ECS
Amazon
EC2
AWS
Lambda
Amazon API
Gateway
Amazon
Redshift
Amazon
QuickSight
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
Cloudwatch
Logs
Cloudwatch
Alarm
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)
API	Gateway
원칙 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/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
원칙 5
API 생태계 확산 참여
혹시 회사에
레스토랑 정보를
공개 API로 제공해
주실 수 있나요?
피드백 감사드립니다.
필요하신 경우를 알려
주시면, 공개로 API를 열어
드리고 향후 비지니스
협력도 같이 할 수 있을 것
같네요!
Micro-service A Micro-service B
public API public API
원칙 5. API 서비스를 통한 생태계 확산
Restaurant
Micro-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/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
원칙 6
기술 너머 조직 변화
“Any organization that designs a system
will inevitably produce a design whose
structure is a copy of the organization’s
communication structure.”
Melvin E. Conway, 1967
Conway’s Law
Image	from	Martin	Fowler’s	article	on	microservices, at
http://martinfowler.com/articles/microservices.html
No	alterations	other	than	cropping.
Permission to reproduce: http://martinfowler.com/faq.html
원칙 6. 기술 너머 조직의 변화
Image	from	Martin	Fowler’s	article	on	microservices, at
http://martinfowler.com/articles/microservices.html
No	alterations	other	than	cropping.
Permission to reproduce: http://martinfowler.com/faq.html
원칙 6. 기술 너머 조직의 변화
기능별 조직에서 자율성 높은 책임 조직으로
Non-pizza	image	from	Martin	Fowler’s	article	on	microservices, at
http://martinfowler.com/articles/microservices.html
No	alterations	other	than	cropping.
Permission to reproduce: http://martinfowler.com/faq.html
원칙 6. 기술 너머 조직의 변화
기능별 조직에서 자율성 높은 책임 조직으로
Two-Pizza Team(Amazon)
“Robot”	by	Robin Zebrowski.	No	alterations	other	than	cropping.
https://www.flickr.com/photos/firepile/438134733/
Image used	with	permissions	under	Creative		Commons	license	2.0,
Attribution	Generic	License	(https://creativecommons.org/licenses/by/2.0/)
원칙 7
자동화! 자동화! 자동화!
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
2-pizza team delivery pipeline service
원칙 7. 자동화! 자동화!
원칙 7. 자동화! 자동화! - 서버리스 자동화 도구
AWS
CloudFormation
AWS
CloudTrail
AWS
Config
AWS Trusted
Advisor
Amazon
Glacier
Amazon
S3
AWS
CodePipelineAWS KMSACM
Amazon
CloudWatch
AWS
Lambda
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) 마이크로서비스를 위한 일곱 가지 모범 사례 (윤석찬)

  • 1.
    © 2016, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 윤석찬 @channyun AWS 테크에반젤리스트 (서버리스) 마이크로서비스를 위한 7가지 모범 사례 2016년 12월 re:Invent 특집 온라인 세미나
  • 2.
    본 발표의 주요주제 • 모놀리식 vs. 마이크로서비스 • AWS 기반 마이크로서비스 아키텍처 • 마이크로서비스에 대한 7가지 모범 사례 § 원칙 1: 각 서비스는 다른 서비스 공개 API 참조! § 원칙 2: 최적 개발 환경 구성 § 원칙 4. 서비스별 보안에 유의하라! § 원칙 3. 지속적인 마이크로 서비스 모니터링 § 원칙 5. API 서비스를 통한 생태계 확산 § 원칙 6. 기술 너머 조직의 변화 § 원칙 7. 자동화! 자동화!
  • 3.
    From Monolith toMicroservices
  • 4.
    “The Monolith” 애플리케이션? 장기개발 사이클 (다수개발자 공동 참여) 운영의 어려움 (특정 모듈 장애시) 애플리케이션 확장성 애로 신규 출시에 몇 달이 걸림 신규 기능 추가에 어려움 아키텍처 유지 진화의 어려움 혁신 저해 고객 불만족 민첩성 저해
  • 5.
    releasetestbuild 개발 및 배포 모놀리식앱 개발자 Shared libraries Shared data Monolith 앱의 개발 배포 및 아키텍처
  • 6.
  • 7.
    “service-oriented architecture composed of loosely coupled elements thathave bounded contexts” Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix) 마이크로 서비스란?
  • 8.
    “service-oriented architecture composed of loosely coupled elements thathave bounded contexts” 서비스들이 네트워크를 통해 서로 통신한다. Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  • 9.
    “service-oriented architecture composed of loosely coupled elements thathave bounded contexts” 서비스는 독자적으로 업데이트하며, 서로 영향을 주지 않는다. Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  • 10.
    “service-oriented architecture composed of loosely coupled elements thathave bounded contexts” 자기 완결: 다른 서비스의 내부 구조를 알지 못해도, 내 서비스 코드를 업데이트 할 수 있다. Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  • 11.
    Public API POST /restaurants GET/restaurants Application/Logic (code, libraries, etc) Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch) 하나의 마이크로서비스의 구성
  • 12.
  • 13.
  • 14.
    = 연간 5천만회배포 수 천개 팀 (자율적 DevOps팀) × 마이크로서비스 아키텍처 × 지속적 배포 (CD) × 다양한 개발 환경 (시간당 5708 회, 또는 0.63 초) Amazon.com의 사례 Werner Vogels (CTO, Amazon.com, 2015)
  • 15.
    AWS Cloud BasedMicroservices
  • 16.
    전통적인 마이크로서비스 아키텍처 Clients RDS HTTP REST EC2 Instance AutoScaling Group AZ-A AZ-B Min > 1 Elastic Load Balancing EC2 Instance AWS Elastic Beanstalk 좀더 스마트하게… .
  • 17.
    AWS 기반 마이크로서비스아키텍처의 진화 S3 CloudFront RDS ElastiCache EC2 Elastic Load Balancing EC2 Elastic Load Balancing Static Content Content Delivery API Layer Application Layer Persistency Layer Auto Scaling Group Auto Scaling Group
  • 18.
    AWS 기반 마이크로서비스아키텍처의 진화 S3 CloudFront RDS ElastiCache EC2 Application Load Balancing Static Content Content Delivery API Layer Application Layer Persistency Layer API Gateway EC2 Container Service Auto Scaling Group
  • 19.
    AWS 기반 마이크로서비스아키텍처의 진화 S3 CloudFront EC2 Application Load Balancing Static Content Content Delivery API Layer Application Layer Persistency Layer API Gateway EC2 Container Service Auto Scaling Group DynamoDB
  • 20.
    AWS 기반 마이크로서비스아키텍처의 진화 S3 CloudFront Static Content Content Delivery API Layer Application Layer Persistency Layer API Gateway DynamoDBAWS Lambda
  • 21.
    하이브리드 마이크로서비스 아키텍처 AmazonAPI GatewayClients HTTP REST Amazon EC2 AWS Lambda Lambda Blueprints Amazon ECS Elastic Load Balancing
  • 22.
  • 23.
    원칙 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/)
  • 24.
    Micro-service A Micro-serviceB public API public API 원칙 1: 각 서비스는 다른 서비스 공개 API 참조!
  • 25.
    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 하위 호환성 지원 가능
  • 26.
    AWS Lambda: 버전기능 • Immutable 함수 버전 기능 • 버전별 설정 및 Cloudwatch 통계 • Cloudwatch Logs에 버전 속성 포함 • 버전 출시에 따라 “label” 처리 가능 • $LATEST 최신 버전 $LATEST(95) STABLE TESTING 94 X 93 X 92
  • 27.
    Amazon API Gateway:스테이지 기능
  • 28.
    Amazon API Gateway:스테이지 변수
  • 29.
    API Gateway LambdaCustom 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 스테이지 변수에 따라 테스트 환경 설정
  • 30.
    “Tools #2” byJuan 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 마이크로 서비스별 최적 개발 환경 구성
  • 31.
    public API publicAPI DynamoDB Micro-service A Micro-service B 원칙 2: 최적 개발 환경 구성 폴리글랏(Polyglot) 접근 방식을 통한 서비스 아키텍처 선택 Amazon Elasticsearch Service RDS Aurora
  • 32.
    폴리글랏 마이크로서비스의 특징 •개별적인 데이터 스토어 • 각 스토어 스키마 변경에 영향이 적음 • 독자적인 확장성 제공 • 만약 트랜잭션 중 문제가 발생한다면? account-svccart-svc DynamoDB RDS user-svc ElastiCache RDS ERROR
  • 33.
    해결 방법 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”
  • 34.
    해결 방법 2:서비스별 자체 롤백 제공 • 모든 마이크로서비스는 각자의 롤 백 기능을 가져야 한다. • 롤백이 필요할 경우, 알림이나 특정 액션에서 롤백 기능 제공 • Correrlation ID를 기반으로 롤백 알림 호출 Microservice Function 1 Rollback Commit (optional)
  • 35.
    AWS Step Functions •시각적 워크플로를 사용해 분산 앱 및 마이크로서비스 구성 요소 조정 및 실행 § 자동으로 각 단계를 트리거 및 추적하고 오류가 발생할 경우 재시도하므로 애플리케이션이 의도대로 정상적으로 실행 § 앱을 단계별로 배열 및 시각화할 수 있는 그래픽 콘솔 제공 § 각 단계의 상태를 기록하여, 잘못된 경우 빠르게 문제를 진단하고 디버깅 가능 • 상태 변경이 일어나는 경우만 과금
  • 36.
    AWS Step Functions- 사용 사례 메소드 호출 함수 순차 실행 DB 저장 실행 대기열 Tim Bray의 세션 강추! https://www.youtube.com/watch?v=75MRve4nv8s
  • 37.
    AWS Step Functions- 1. 애플리케이션 단계 정의 순차 단계 분기 단계(경로 선택) 병렬 단계
  • 38.
    AWS Step Functions- 2. 단계별 실행 상태 파악
  • 39.
    AWS Step Functions- 3. 확장 및 앱 안정성 파악
  • 41.
    File:Cgs01053 - Flickr- NOAA Photo Library.jpg https://commons.wikimedia.org/wiki/File:Cgs01053_-_Flickr_-_NOAA_Photo_Library.jpg 원칙 3 지속적인 마이크로 서비스 모니터링
  • 42.
    원칙 3. 지속적인마이크로 서비스 모니터링 • AWS 기반 모니터링 도구 활용 • 모니터링 - CloudWatch § 로깅: CloudWatch Logs • API 외부적인 요소 모니터링 § Latency, RPS, Error rate • API 내부적인 요소 모니터링 § CloudWatch, OS, Application
  • 43.
    Amazon CloudWatch Logs AWS Lambda Amazon Elasticsearch Kibana 실시간로그 대시보드 구성 Amazon API Gateway Amazon ECS Amazon EC2
  • 44.
    데이터 리포팅 및시각화 Amazon ECS Amazon EC2 AWS Lambda Amazon API Gateway Amazon Redshift Amazon QuickSight Amazon EMR S3
  • 45.
    Amazon Athena -서버리스 대화식 질의 서비스 § Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스 § 서버 없이 S3에 저장한 파일의 스키마 정의 후 바로 질의 가능 § 질의를 위해 스캔한 TB당 5달러 비용 ü 표준 (ANSI) SQL 지원 ü ETL 필요 없음 ü 빠른 성능 및 자동 확장 ü 데이터 전처리나 인프라 운영 필요 없음
  • 47.
    코드 에러의 경우, •Lambda 함수 실행 오류가 나는 경우 • Cloudwatch Logs 통해 디버깅 가능 • 직접 Transction Manager 함수를 별도로 만들어 Cloudwatch Logs Metric Filter 를 통해 에러 검출 ui-svc Cloudwatch Logs Cloudwatch Alarm Transaction Manager Function
  • 48.
    AWS X-Ray -분산 애플리케이션 추적 서비스 • 마이크로서비스 시작과 끝에 대한 디버깅 및 추적 • 서비스에 대한 시각적 토폴로지 제공 • 개별 요청에 대한 로그 추적 • 성능 이슈 및 오류 발생 원인에 대한 확인 및 문제 해결 호출에 대한 전체 과정 파악 사용자 요청이 애플리케이션을 통과하는 전체 과정을 추적 애플리케이션 성능 개선 지연 시간이 늘어나는 위치를 빠르게 확인한 후 성능이 저하되는 특정 서비스 및 경로에 대한 문제 해결 가능 애플리케이션 문제 식별 트레이스 데이터 태깅 및 필터링을 통해 어느 위치에서 무엇이 성능 문제를 유발하는지 정확히 파악
  • 49.
    AWS X-Ray -서비스 맵 기능
  • 50.
    AWS X-Ray -데이터 태깅 및 추적 기능
  • 51.
    AWS X-Ray -에이전트 설치 및 추적 1. Amazon EC2 2. Amazon ECS (Docker) 3. AWS Node.JS (SDK)
  • 53.
    “security” by DaveBleasdale. 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 마이크로 서비스 보안 유지
  • 54.
    • 수준별 방어 •네트워크 레벨 (e.g. VPC, Security Groups, TLS) • 서버/콘테이너/앱 레벨 • IAM 정책 및 역할 • API Gateway (“Front door”) • API Throttling • API 키 관리 • S3 버킷 정책 + KMS + IAM • 오픈 소스 도구 (e.g. Vault, Keywhiz) API Gateway 원칙 4. 서비스별 보안에 유의하라!
  • 55.
    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$ + 데이터 비용 (연간 계약)
  • 57.
    “Lamington National Park,rainforest” by Jussarian. No alterations other than cropping. https://www.flickr.com/photos/kerr_at_large/87771074/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/) 원칙 5 API 생태계 확산 참여
  • 58.
    혹시 회사에 레스토랑 정보를 공개API로 제공해 주실 수 있나요? 피드백 감사드립니다. 필요하신 경우를 알려 주시면, 공개로 API를 열어 드리고 향후 비지니스 협력도 같이 할 수 있을 것 같네요! Micro-service A Micro-service B public API public API 원칙 5. API 서비스를 통한 생태계 확산
  • 59.
    Restaurant Micro-service 15 TPS100 TPS5TPS20 TPS 레스토랑 정보 API를 사용하려는 외부 고객 뿐만 아니라 내부 고객에게도 API를 오픈해야 겠네요! 원칙 5. API 서비스를 통한 생태계 확산 • 플랫폼 확장 고려 • SLA 수준 고민
  • 60.
    “rowing on theriver in Bedford” by Matthew Hunt. No alterations other than cropping. https://www.flickr.com/photos/mattphotos/19189529/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/) 원칙 6 기술 너머 조직 변화
  • 61.
    “Any organization thatdesigns a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” Melvin E. Conway, 1967 Conway’s Law
  • 62.
  • 63.
    Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission toreproduce: http://martinfowler.com/faq.html 원칙 6. 기술 너머 조직의 변화 기능별 조직에서 자율성 높은 책임 조직으로
  • 64.
    Non-pizza image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission toreproduce: http://martinfowler.com/faq.html 원칙 6. 기술 너머 조직의 변화 기능별 조직에서 자율성 높은 책임 조직으로 Two-Pizza Team(Amazon)
  • 65.
  • 66.
  • 67.
    원칙 7. 자동화!자동화! - 서버리스 자동화 도구 AWS CloudFormation AWS CloudTrail AWS Config AWS Trusted Advisor Amazon Glacier Amazon S3 AWS CodePipelineAWS KMSACM Amazon CloudWatch AWS Lambda AWS CodeDeploy 좀 더 자세한 사항은 내일 오후의 개발 도구 웨비나에 참여하세요!
  • 68.
    Expect challenges alongthe way… • 서비스 내 비지니스 도메인의 이해 • 명시적 서비스 단위 분리 • 서비스 지속성 및 API 운영 정책 고민 • 분산 앱의 테스트/배포/운영에 대한 복잡성에 대한 고민 • 모니터링/문제 해결 방법 고민 • 조직 및 문화적 변화 필요 마이크로 서비스로의 여정
  • 69.
    빠른 빌드/테스트/배포 가능 명확한 오너쉽 및 자율적운영 개별 마이크로 서비스 확장 가능 몇 분만에 배포 가능 신규 기능 빠르게 추가 가능 빠른 운영 및 개선 빠른 혁신 고객 만족 높은 민첩성 마이크로 서비스의 이점
  • 70.
    마이크로서비스 7 가지모범 사례 • 원칙 1: 각 서비스는 다른 서비스 공개 API 참조! • 원칙 2: 최적 개발 환경 구성 • 원칙 4. 서비스별 보안에 유의하라! • 원칙 3. 지속적인 마이크로 서비스 모니터링 • 원칙 5. API 서비스를 통한 생태계 확산 • 원칙 6. 기술 너머 조직의 변화 • 원칙 7. 자동화! 자동화!
  • 71.
  • 72.
    질문을 남겨주세요! 세미나 설문조사 발표자료/녹화 영상 http://bit.ly/awskr-webinar