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.

MSA ( Microservices Architecture ) 발표 자료 다운로드

source : http://www.opennaru.com/cloud/msa/

마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.

  • Be the first to comment

MSA ( Microservices Architecture ) 발표 자료 다운로드

  1. 1. Microservices Architecture
  2. 2. MSA 란?
  3. 3. Microservices Architecture - 특징
  4. 4. • 모노리스 아키텍처의 특징 • 견고함 • 표준화 • 단일 기술 Monolith Architecture
  5. 5. 모노리스 아키텍처의 장단점
  6. 6. Monolith vs. Microservices Build Test Release Build Test Release Build Test Release Build Test Release Build Test Release Build Test Release Build Test Release Monolithdevelopmentlifecycle Microservicedevelopmentlifecycle developers app Deliverypipeline developers services Deliverypipeline 하나의 기능을 구현 하는데, 여러 개의 서비스를 조합하여 기능을 제공 예) 주문 하기 : 사용자 정보 조회, 상품 정보 조회, 신규 주문 생성
  7. 7. DevOps
  8. 8. 마이크로서비스 아키텍처 등장의 배경
  9. 9. Monolith Architecture Team
  10. 10. • 팀을 작게 나누고 병행 개발 Microservices Architecture Team
  11. 11. Quicker development
  12. 12. 3티어 아키텍처 – 2000년대
  13. 13. 4티어 아키텍처 – 2010년 이후
  14. 14. Microservices Anti-patterns
  15. 15. 마이크로서비스 장점
  16. 16. Microservices 9 가지 특징 (1/2)
  17. 17. Microservices 9 가지 특징 (2/2)
  18. 18. Microservices 특징
  19. 19. 마이크로서비스 아키텍처와 거버넌스
  20. 20. There’s no silver bullet.
  21. 21. • 변화의 경계선을 찾는다 • 모듈화는 변화의 경계선에 의해 일어난다 • 변화의 요인 (외부 / 내적)는 품질 특성에서 이해하기 • 기능뿐만 아니라 비 기능도 중시해야 한다 • 변화의 경계에 선을 긋는다 • 변화의 경계는 불분명하지만 선을 그릴 수 밖에 없다 • 도메인 경계를 유지한다 • 패키지 문제 또는 재 구축 문제 도메인 = 변화의 경계선
  22. 22. The 12 Factor App
  23. 23. The 12 Factor App (1/2)
  24. 24. The 12 Factor App (2/2)
  25. 25. 모노리스 아키텍처의 특징 ¨ 견고함 ¨ 표준화 ¨ 단일 기술 Monolith Architecture
  26. 26. Monolith -> Microservices – Phase 1 호출 빈도가 높으며, 독립적으로 동작하는 모듈을 API 서비스로 독립
  27. 27. 모노리스에서 마이크로서비스로 전환 – Phase 2 동일한 조건으로 서비스 분할
  28. 28. 모노리스에서 마이크로서비스로 전환 – Phase 3 동일한 조건으로 서비스 분할
  29. 29. 모노리스에서 마이크로서비스로 전환 – Phase 4 비즈니스 관점에서 도메인을 정의하고 서비스를 분할하며, 독립적인 서비스로 구축
  30. 30. • 개선을 반복하여 최적의 마이크로 서비스를 제공 모노리스에서 마이크로서비스로 전환 – Phase 5
  31. 31. Coupang의 MSA 전환사례 https://medium.com/coupang-tech/%ED%96%89%EB%B3%B5%EC%9D%84-%EC%B0%BE%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%9A%B0%EB%A6%AC%EC%9D%98- %EC%97%AC%EC%A0%95-94678fe9eb61 문제점 • 부분 장애가 전체 서비스 장애로 이어지는 경우가 있음 • 서비스를 부분적 Scale-out하기 어려움 • 서비스 변경이 어렵고, 수정시 영향도를 파악하기 어려움 • 작은 변경에도 많은 테스트가 필요함 • 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함 기술 블로그에서 발췌/정리
  32. 32. Coupang의 MSA 전환사례 https://medium.com/coupang-tech/%ED%96%89%EB%B3%B5%EC%9D%84-%EC%B0%BE%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%9A%B0%EB%A6%AC%EC%9D%98- %EC%97%AC%EC%A0%95-94678fe9eb61 장점 • 부분 장애가 전체 서비스 장애가 되지 않음 • 서비스를 부분적 Scale-out하기 쉬움 • 신기술 적용이 쉬움(각 팀별로 별도 진행) • 각 팀별로 변경사항을 빠르게 적용할 수 있음 단점 • 테스트가 어렵다(다른 팀 API 테스트 필요) • 장애 추적이 어렵다(비동기 처리시 더 어려움) • 트랜잭션 관리가 어렵다. • 담당자를 찾기 어렵다 기술 블로그에서 발췌/정리
  33. 33. 11번가의 MSA 전환사례 https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1 발표자료에서 발췌/정리 문제점 • 나의 과감한 수정은 전사 장애다 ! • 배포의 어려움 매주 목요일 밤샘 정기 배포/잦은 장애 • 새로운 기술 접할 기회 원천 봉쇄 Java 1.6, Spring Framework 2.x • 느린 개발 환경 IDE를 띄우기도 어려움, 200만 라인의 공통코드 • 폭증하는 트래픽을 수년내 감당하기 어려움
  34. 34. 11번가의 MSA 전환사례 https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1 발표자료에서 발췌/정리
  35. 35. OOO사 OpenShift 환경의 MSA 애플리케이션 전환 사례 Red Hat Linux 6 Red Hat Linux 7.7 OpenShift 3.11 JDK 1.4 JDK 1.8 Legacy Framework Spring Boot/Cloud JEUS 7 Tomcat 9 AS-IS TO-BE 주요 개선점 • 부하에 따라 서비스를 부분적으로 자동 Scale- out할 수 있음(Auto Scaling) • 컨테이너 환경으로 DevOps(CI/CD) 서비스 무중단 배포 환경 구성  업무별 빠른 자동 배포 환경 • Spring Boot / Spring Cloud(Netflix OSS) 등 최신 Framework 도입하여 MSA 환경 구축 • 운영환경과 동일한 개발/테스트 환경 구성 OpenShift 프로젝트로 구분하여 특정 노드에 구성 • APM 도입으로 API간의 연계 추적이 가능
  36. 36. OOO사 OpenShift 환경의 MSA 애플리케이션 전환 사례 frontend Oracle Database Redis Cluster Openshift Container Platform 프로젝트: Infra-prod (infra-dev, infra-test) Rabbit MQ (config) aggregator front -admin gateway (제휴사 API 호출) business service (오토스케일링) config -server #1 ~ #6 auth backend bill member manager mobile report support 워커 노드 #1 워커 노드 #2 워커 노드 #3 워커 노드 #4 워커 노드 #5 마스터 노드 #1 마스터 노드 #2 마스터 노드 #3 Bastion #1 aaa.war 컨테이너 (PROD) bbb.war 컨테이너 (PROD) ccc.war 컨테이너 (PROD) ddd.war 컨테이너 (PROD) eee.war 컨테이너 (TEST) Persistent Volumes (NFS) 물리 구성 Spring CloudSpring Cloud Spring Cloud
  37. 37. 건국대학교병원 – MSA 전환사례
  38. 38. 건국대학교병원 – MSA 전환사례
  39. 39. 건국대학교병원 – MSA 전환사례
  40. 40. 건국대학교병원 – MSA 전환사례 SPARC/PA-RISC/Power X86 물리서버 RHEV 4.0 HP-UX(11.23) Red Hat Linux(7.3) JDK 1.4 JDK 1.8 JEUS 4.2 JBoss EAP 7 적 용 방 안 기 대 효 과  인프라 (서버/OS/미들웨어) 를 단일 벤 더 지원  각 부분별로 개방형 표준 환경으로 전환  오픈 소스 프레임워크를 통한 개발  라이선스 비용 없기 때문에 초기 도입 비용 절감  특정 서버 벤더와 기술에 얽매이지 않는 환경  Cost Performance 가 좋은 인프라를 선 택  서비스 품질이 높은 개발/운영 업체 선 택  운영 효율성 향상  저비용 고효율 시스템 구축 J2EE 1.3 Java EE 1.8 AS-IS TO-BE
  41. 41. 건국대학교병원 – MSA 전환사례
  42. 42. 건국대학교병원 – MSA 전환사례
  43. 43. 건국대학교병원 - 전환사례
  44. 44. 건국대학교병원 - 전환사례
  45. 45. 건국대학교병원 - 전환사례
  46. 46. The Future of the Application Stack - Kubernetes
  47. 47. 제품 / 서비스에 관한 문의 • 콜 센터 :02-469-5426 ( 휴대폰 : 010-2243-3394 ) • 전자 메일:sales@opennaru.com

×