모놀리스에서 마이크로서비스 아키텍처로의 전환 전략::박선용::AWS Summit Seoul 2018

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
박 선용
Developer Specialist Solutions Architect / APAC
모놀리스에서 마이크로서비스
아키텍처로의 전환 전략

이 세션에서는..
• 모노리식 어플리케이션을 마이크로 서비스로 전환하는
과정을 시스템의 비니지스 관점 분석, 고려할 수 있는
디자인 패턴, 데이터의 분할 등으로 구분해서 순차적으로
살펴봅니다.
• 컨테이너 기술과 AWS 많은 서비스들이 마이크로
서비스를 구현하는데 최적의 장점을 제공한다는 것을 알
수 있습니다.

마이크로서비스 란?
마이크로서비스의 발견
마이크로서비스 아키텍처 패턴
분해 (Splitting Monolithic to Microservice)
컨테이너와 AWS 서비스
결론

마이크로서비스 란?

모노리식 vs 마이크로서비스
관리 UI
주문 서비스
인벤토리 서비스
배송 서비스
관리 UI
주문
서비스
배송
서비스
배송
서비스
고객 UI
고객 UI

마이크로서비스 아키텍처 (장점)
• CI/CD의 장점을 극대화 함
• 개별 서비스를 소규모 모듈로 구성 가능
• 장애에 강해 짐
• 장기적 기술 종속을 감소

마이크로서비스 아키텍처 장점
하지만

마이크로서비스 아키텍처 (단점)
개발 환경의 미성숙 배포의 복잡성 시스템의 메모리 소요가
상대적으로 높아짐

마이크로서비스 아키텍처
• 스타트업
• 초기부터 마이크로 서비스를 적용하는 경우가 드뭄
• 빠르게 성장하는 기능 개발에 시간 모두 소요.
• 리아키텍처링에 대한 필요성 높음
• 엔터프라이즈
• 기존 만들어진 어플리케이션 환경
• 대규모 기능이 하나의 어플리케이션에
• 서로 복잡하게 연계된 어플리케이션 환경

마이크로서비스 아키텍처로의 전환
• 어떤 경우에 마이크로서비스 아키텍처로 전환/검토 해야 하나?
• 쉽고 빠른 어플리케이션의 변경
• 새로운 개발자의 빠른 적응
• 새 기술의 빠른 적용
• CI/CD 의 적용
• 대표적인 케이스
• Amazon.com : 3tier à Miscroserices
• Netflix
• eBay

AWS 서비스와의 매핑
화면 생성 서비스
웨서버
데이터 접근 레이어
앱서비스
데이터베이스
2. 요구에 대한
명세화
Amazon
S3
Amazon
DynamoDB
AWS Lambda
Amazon API
Gateway
3. AWS서비스와
매핑
1. 각 요소의
확정
• 상태?
• 컴퓨팅?
• API?
• 스토리지?
• 보안?
• 자동관리?
• 확장성?
• 기타

마이크로서비스의 발견

기본 가이드 라인의 확인
• 마이크로서비스 아키텍처 전환시 중요 사항
• 안정적인 아키텍처일 것
• 서비스는 연계가 강한(Cohesive) 기능들의 집합일 것
• 동일한 이유로 변경되는 것들은 하나의 서비스 일 것
• 서비스끼리는 느슨한 결합(loosely coupled)일 것
• 각각의 서비스는 테스트 가능할 것
• 각 서비스는 2 pizza 팀이 개발/관리가 가능할 정도의 규모일 것
• 가이드 라인
• SRP(Single Responsibility Principle)
• CCP(Common Closure Principle)
발견 패턴 분할 매핑

비지니스 역량에 의한 구분
• 비지니스 역량 = 비지니스 목적
• 비지니스의 가치 창출의 요소를 기준으로 분할
• 비지니스 역량을 구분해내면 그것이 서비스로 전환 가능
참고 : http://microservices.io/patterns/decomposition/decompose-by-business-capability.html

비지니스 역량에 의한 구분
Buy Product
management
Sell Product
Management
Order
Management
Payment
management
Delivery
management
서비스 서비스
서비스
서비스 서비스

서브 도메인에 의한 구분
도메인 주도 디자인 (DDD : Domain Driven Design)
• 비지니스의 문제 영역을 도메인으로 호칭
• 도메인은 여러 개의 서브 도메인으로 구성
서브 도메인 구분
• 핵심(Core) / 지원(Supporting) / 일반(Generic)
문제점
• 서브 도메인을 특정하는 것이 어려움
• 조직적인 문제 : 각기 다른 그룹이 서브도메인과 관련될 수 있음

서브 도메인에 의한 구분
Buy Product
management
Sell Product
mangement
Order
Management
Payment
management
Delivery
management
참고 : http://microservices.io/patterns/decomposition/decompose-by-subdomain.html

비지니스 관점 vs 시스템 관점
추상적인 개념의 문제
실무적인 접근
• 각 기능의 상위 서비스 API 정의
• 서비스 API를 기준으로 각 모듈 정의
• 코어와 아닌 것을 구분
• 어플리케이션의 로직 구조 및 Data관점 탈피

§ 서비스 별 데이터베이스 패턴
- 서비스별 테이블, 서비스별 스키마, 서비스별 데이터베이스
§ API 게이트웨이 패턴
- 다양한 어플리케이션에 대한 단일한 접근 포인트를 제공한다.
§ 회로 차단기(Circuit Breaker) 패턴
- 클라이언트가 전기 회로 차단기와 비슷한 방식으로 기능하는 프록시를 통해
원격 서비스를 호출하는 패턴.

§ Single Service per Host
§ Access Token
§ Log aggregation
§ Application metrics
§ Audit logging
§ Distributed tracing
§ Exception tracking
§ Health check API
§ Log deployments and changes
§ Server-side page fragment composition
§ Client-side UI composition
참고 http://microservices.io/patterns/microservices.html

전환시 고민할 문제들
아키텍처 품질 목표
• 확장성, 가용성, 민첩성, 운용 편이성, 성능 …
분할 (Decomposition)
• 어플리케이션
• 데이터
고민
• 1단계 : 데이터 분할에 대한 어려움
• 2단계 : 어플리케이션(각 서비스 별)의 아키텍처 품질 요소 충족의 어려움

분해
(Splitting Monolithic to
Microservice)

데이터에 대한 분해 방법
메인 데이터베이스
• 외래키 관계 제거
• 공유 데이터(Shared Data)
• 스키마 분리(Schema Splitting)
• 데이터베이스 리팩토링
• 리포팅 혹은 분석 데이터
• 데이터 펌프(Data Pump)
• 이벤트 데이터 펌프(Event Data Pump)

외래 키의 제거
사용자 제품
모노리식 서비스
사용자 테이블 제품 테이블
사용자
서비스
제품
서비스
마이크로서비스
사용자 테이블 제품 테이블
1:N

공유 데이터
Ex) country code, zip code, custom code …
금융 제품
고객 정보
지불
공유 데이터
금융
서비스
제품
서비스
고갯
서비스
마이크로 서비스

스키마 분리
금융 제품
아이템
지불 금융
서비스
제품
서비스
제품 아이템지불된 아이템

데이터베이스 리팩토링
모노리식
스키마
금융 제품
금융
스키마
금융 제품
제품
스키마
금융
스키마
금융 제품
제품
스키마
1 단계
단일 스키마
2 단계
스키마 분리
3 단계
어플리케이션을
서비스로 분리

분석/리포트 데이터베이스
Main
Database
모노리식
서비스
읽기/쓰기
Reporting
Database
리포팅
시스템
동기화
API를 통해서 데이터를 리포팅
시스템으로 보내야 하는가?
1. 대량의 데이터를 아주 빈번히 HTTP를
통한 전송은 높은 오버헤드가 존재
2. 리포팅 시스템 데이터 동기만을 위한
API는 이득 대비 손실이 너무 큼
읽기

분석/리포트 데이터베이스
메인
데이터베
이스
리포팅
데이터베
이스
데이터 펌프
데이터 펌프
1. 커플링 이슈 (?)
2. 몇 안되는 예외
메인
데이터베
이스
리포팅
데이터
베이스
데이터 펌프
이벤트
이벤트 데이터 펌프
1. 서비스가 이벤트를 발생
2. 이벤트 구독자(데이터펌프)가 데이터를
리포팅 시스템으로 전달
3. 좀 더 디커플링 됨
4. 개발에 많은 부담

컨테이너와 AWS 서비스

컨테이너 고려
아키텍처 품질 목표
확장성, 가용성, 민첩성, 운용 편이성, 성능 …
품질 목표의 전환
• 어플리케이션에서 마이크로서비스로
• 각 서비스가 자신의 SLA를 충족해야
• 데이터는 추상화 되므로 외부 서비스는 관련 없음

마이크로서비스 어플리케이션
• 서로 다른 어플리케이션 스택
• 서로 다른 하드웨어 배포 환경
• 어떻게 서로 다른 환경에서 모든
어플리케이션을 운용할 수 있을
것인가?
• 어떻게 한개의 환경에서 다른
환경으로 쉽게 마이그레이션 할
것인가?

마이크로서비스 어플리케이션
• 소프트웨어 딜리버리 단위
• 가볍고, 이식성 좋고, 일관된
(Lightweight, portable, consistent)
• 배포하고 어디서나 실행
• 배포하고 무엇이든지 실행

전환 단계
Amazon ECS
AWS
Lambda
AWS Step Functions
Amazon API
Gateway
Amazon EKS
AWS Fargate
Amazon
S3
Amazon
DynamoDB
Amazon
Aurora
Amazon
EC2
Amazon
DynamoDB
Amazon
RDS
Amazon
S3
RDSDB
instancestandby
(multi-AZ)
RDS DB
instance read
replica
Amazon
EC2
Elastic Load
Balancing
Microservice (1st Gen) Microservice (2nd Gen)

AWS 서비스 매핑 (보안)
Amazon API
Gateway
AWS
Lambda
Amazon
DynamoDB
Amazon
S3
Amazon
CloudFront
• Bucket Policies
• ACLs
• OAI
• Geo-Restriction
• Signed Cookies
• Signed URLs
• DDOS
IAM
AuthZ
IAM
• Throttling
• Caching
• Usage Plans
정적
컨텐츠
브라우저

AWS 서비스 매핑 (모니터링)
Amazon API
Gateway
AWS
Lambda
Amazon
S3
Amazon
CloudFront정적건텐츠
브라우저
Amazon
DynamoDB
• Access Logs in
S3 Bucket
• CloudWatch
Metrics
• Access Logs in
S3 Bucket
AWS
CloudTrail
Amazon
CloudWatch
• Custom
CloudWatch
Metrics & Alarms
• Audit Log of All
AWS API Calls
• Latency
• Count
• Cache Hit/Miss
• 4XX/5XX Errors
• Invocations
• Invocation Errors
• Duration
• Throttled Invocations
• Throttled Reqs
• Returned Bytes
• Latency

결론

정리
• 초기 시스템 설계시 부터 고려
• 기존 어플리케이션에 대해서는 전환계획 수립
• 발견, 패턴, 분할, 매핑 등 단계별 접근 고려
• 각 비지니스 단위의 구분, 서비스의 요구사항 등 고려
• 데이터 분할에 대한 전략
• 컨테이너 기술 및 서버리스 서비스의 활용
• 각 분할된 서비스 요구사항과 AWS 서비스의 매핑
• 추가적인 표준 AWS 레퍼런스 아키텍처 고려
• 서비스 규모에 따른 지속적인 진화

정리 – 지속적 개선
발견 디자인 개발 배포
모니터링
및
개선사항

AWS Summit 모바일 앱과 QR코드를
통해 강연 평가 및 설문 조사에 참여해
주시기 바랍니다.
내년 Summit을 만들 여러분의 소중한
의견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사
소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

모놀리스에서 마이크로서비스 아키텍처로의 전환 전략::박선용::AWS Summit Seoul 2018

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 모놀리스에서 마이크로서비스 아키텍처로의 전환 전략::박선용::AWS Summit Seoul 2018

Similar a 모놀리스에서 마이크로서비스 아키텍처로의 전환 전략::박선용::AWS Summit Seoul 2018 (20)

Más de Amazon Web Services Korea

Más de Amazon Web Services Korea (20)

모놀리스에서 마이크로서비스 아키텍처로의 전환 전략::박선용::AWS Summit Seoul 2018