Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Aws summit 2017 사내전파교육

4,392 views

Published on

AWS summit 2017 사내 전파 교육

Published in: Software
  • Be the first to comment

Aws summit 2017 사내전파교육

  1. 1. AWS summit 2017 전파교육
  2. 2. 전파교육 범위 • 세션 내용 일부를 바탕으로 • 제가 하고 싶은 얘기를 할 겁니다. • Monolith -> MSA 로 전환 시 고려사항 • 사용자 수에 맞는 Architecture 고려사항 • MxNet 을 주목하라
  3. 3. S1. MSA로 전환 시 고려사항 • Session 명 : 마이크로서비스를 위한 AWS 아키텍처 패턴 및 모 범사례 • 슬라이드 링크 : https://www.slideshare.net/awskorea/3- microservice-aws-architecture-pattern-usecase
  4. 4. MSA로 전환 시 고려사항 • MSA 가 뭔지 모르는 분들을 위해서 짧게 소개 VS
  5. 5. MSA 전환을 고려할 대상 • Multi target service(웹, 모바일웹, 모바일앱, 네이티브앱 …) • 인증 / 조회 / 주문 / 배송추적 … 동일한 내용을 여러 번 개발 • Target 간 integrity 문제 • 사용자가 100k -> 1000k -> 1000m 으로 늘어나는 service • 고전적인 아키텍처로는 설계 및 대응이 어려움 • Cloud 도입을 고려중인 service • MSA 는 cloud 에서 장점이 극대화되는 아키텍처
  6. 6. MSA 가 만능인가? • 새로운 단계의 복잡도가 발생 • Chaining • Transaction • Dependency managing • Testing • Monitoring
  7. 7. AWS 솔루션 문제 AWS 솔루션 Service Chaining AWS Step Function Transaction Correlation ID Dependency managing AWS Lambda versioning, CloudFormation Testing AWS CodeBuild Monitoring AWS Xray, CloudWatch • AWS 솔루션 소개가 목적이 아니므로 • 자세한 내용은 생략한다
  8. 8. MSA 전환 시 고려사항 • Legacy 는 어쩌지? • 적폐는 걷어내고 새로 만들어야 하나? • Legacy는 그대로 두고 신규 기능 / 핵심 기능만 MSA 도입해야 하나? • 가시화 도구가 필요하다 • Chaining 가시화 • Monitoring 가시화 • Provisioning 가시화 • Application Level Transaction 구현 • Transaction 추적을 위한 ID 필요 • 각 마이크로 서비스 별 독립된 Roll back 전략/구현
  9. 9. Strangler Architecture Pattern • 정치권에서 적폐는 반드시 청 산할 대상이지만 • 서비스에서 Legacy 는 잘못 건 드리면 다 죽어요 • 암도 생명입니다. 더불어 살아 갈 방법이 필요해요.
  10. 10. 가시화가 가장 중요하다 • Simianviz(=spigo) • Adrian 형이 만든 opensource • https://github.com/adrianco/ spigo • 가시화 대상 • Service chain • Monitor • Provisioning
  11. 11. 2 phase commit protocol • Transaction을 Request / Commit phase 2단계로 나눔 • Request : Transaction 이 요구 되는 모든 node들이 준비되었 는지 확인 • Commit : 모든 node 들을 commit • 단점 • Blocking protocol • Transaction Manager Hang 발 생 시 답이 없다.
  12. 12. S2. 사용자 수에 맞는 Architecture 고려사항 • Session 명 : 천만 사용자를 위한 AWS 클라우드 아키텍쳐 진화하기 • 슬라이드 링크 : https://www.slideshare.net/awskorea/1-aws-cloud- architecture-evolution
  13. 13. 사용자 수에 맞는 Architecture 고려사항 • 사용자 1 : 고전적인 monolithic architecture • 사용자 > 100+ : 3tier architecture • 사용자 > 1000+ : load balancing • 사용자 > 10000+ : CQRS pattern • 사용자 > 1000000+ : cache, auto scale, 자동화, 모니터링, MSA • 사용자 > 10000000+ : 쓰기 병목 해결(federation, sharding, nosql) 여기까진 많이들 경험 해본 영역 매우 드물게 경험해 본 영역 미지의 영역
  14. 14. 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
  15. 15. S3. MxNet 을 주목하라 • Session 명 : 모두를 위한 MxNet • 슬라이드 링크 : https://www.slideshare.net/awskorea/2-mx-net
  16. 16. MxNet? • Deep Learning Framework • Scalable • 분산환경에서 tensorflow 보다 나은 성능 • Multi language support • c++ / python / r / scala / julia / perl / matlab • Mobile Device Support • Apache Incubator • AWS ready
  17. 17. 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/
  18. 18. 질문?
  19. 19. 감사합니다

×