AWS summit 2017전파교육

전파교육 범위

• 세션 내용 일부를 바탕으로

• 제가 하고 싶은 얘기를 할 겁니다.

• Monolith -> MSA 로 전환 시 고려사항

• 사용자 수에 맞는 Architecture 고려사항

• MxNet 을 주목하라

S1. MSA로 전환 시 고려사항

• Session 명 : 마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범사례

• 슬라이드 링크 : https://www.slideshare.net/awskorea/3-microservice-aws-architecture-pattern-usecase

MSA로 전환 시 고려사항

• MSA 가 뭔지 모르는 분들을 위해서 짧게 소개

VS

MSA 전환을 고려할 대상

• Multi target service(웹, 모바일웹, 모바일앱, 네이티브앱 …)• 인증 / 조회 / 주문 / 배송추적 … 동일한 내용을 여러 번 개발

• Target 간 integrity 문제

• 사용자가 100k -> 1000k -> 1000m 으로 늘어나는 service• 고전적인 아키텍처로는 설계 및 대응이 어려움

• Cloud 도입을 고려중인 service• MSA 는 cloud 에서 장점이 극대화되는 아키텍처

MSA 가 만능인가?

• 새로운 단계의 복잡도가 발생• Chaining

• Transaction

• Dependency managing

• Testing

• Monitoring

AWS 솔루션

문제 AWS 솔루션

Service Chaining AWS Step Function

Transaction Correlation ID

Dependency managing AWS Lambda versioning, CloudFormation

Testing AWS CodeBuild

Monitoring AWS Xray, CloudWatch

• AWS 솔루션 소개가 목적이 아니므로

• 자세한 내용은 생략한다

MSA 전환 시 고려사항

• Legacy 는 어쩌지?• 적폐는 걷어내고 새로 만들어야 하나?• Legacy는 그대로 두고 신규 기능 / 핵심 기능만 MSA 도입해야 하나?

• 가시화 도구가 필요하다• Chaining 가시화• Monitoring 가시화• Provisioning 가시화

• Application Level Transaction 구현• Transaction 추적을 위한 ID 필요• 각 마이크로 서비스 별 독립된 Roll back 전략/구현

Strangler Architecture Pattern

• 정치권에서 적폐는 반드시 청산할 대상이지만

• 서비스에서 Legacy 는 잘못 건드리면 다 죽어요

• 암도 생명입니다. 더불어 살아갈 방법이 필요해요.

가시화가 가장 중요하다

• Simianviz(=spigo)• Adrian 형이 만든 opensource

• https://github.com/adrianco/spigo

• 가시화 대상• Service chain

• Monitor

• Provisioning

2 phase commit protocol

• Transaction을 Request / Commit phase 2단계로 나눔• Request : Transaction 이 요구

되는 모든 node들이 준비되었는지 확인

• Commit : 모든 node 들을commit

• 단점• Blocking protocol• Transaction Manager Hang 발

생 시 답이 없다.

S2. 사용자 수에 맞는 Architecture 고려사항

• Session 명 : 천만 사용자를 위한 AWS 클라우드 아키텍쳐 진화하기

• 슬라이드 링크 : https://www.slideshare.net/awskorea/1-aws-cloud-architecture-evolution

사용자 수에 맞는 Architecture 고려사항

• 사용자 1 : 고전적인 monolithic architecture

• 사용자 > 100+ : 3tier architecture

• 사용자 > 1000+ : load balancing

• 사용자 > 10000+ : CQRS pattern

• 사용자 > 1000000+ : cache, auto scale, 자동화, 모니터링, MSA

• 사용자 > 10000000+ : 쓰기 병목 해결(federation, sharding, nosql)

여기까진 많이들 경험해본 영역

매우 드물게 경험해 본 영역

미지의 영역

CQRS pattern

• Martin Fowler 형 blog : https://martinfowler.com/bliki/CQRS.html

• Command(write) / Query(read) 를 분리

• 사용자 패턴은 당연히 Read >>> Write

• Auto Scale Ready

• Read store 와 Write store 가 loose coupled

S3. MxNet 을 주목하라

• Session 명 : 모두를 위한 MxNet

• 슬라이드 링크 : https://www.slideshare.net/awskorea/2-mx-net

MxNet?

• Deep Learning Framework

• Scalable

• 분산환경에서 tensorflow 보다 나은 성능

• Multi language support• c++ / python / r / scala / julia / perl /

matlab

• Mobile Device Support

• Apache Incubator

• AWS ready

Deep Learning Framework 선택 기준

• 얼마나 쉽나• LSTM 을 100 line 안으로 작성 가능 :

http://mxnet.io/tutorials/python/char_lstm.html

• 요즘 hot 한 Model 들 기본 제공 -> 갖다 쓰기만 하면 됨

• Core num. / 성능 향상이 linear 한가

• Mobile device 에서 쉽게 쓸 수 있나

• 발전가능성• Apache Incubator : http://incubator.apache.org/projects/mxnet.html

• AWS 지원 : https://aws.amazon.com/ko/mxnet/

질문?

감사합니다