‘애자일’ 요구받는 기업들··· AWS “답은 ‘컨테이너’”
2020.04.24 14:47
ㆍ필승님
ㆍ댓글
ㆍ좋아요
ㆍ찜
- 전체 7 건 (1/1페이지)
-
좋아요! : 
Microservices 101
When we think about building an application, we visualize it as a bunch of code glued together, running somewhere on the web for the purpose of providing people some value. It could be the homepage of your coffee shop, an e-commerce site or an amazing API which collects data from your watch.
Most of the time applications are basically that, a bunch of code, and that works perfectly for most common scenarios. They are effectively monoliths.... 더보기
MSA를 이용해 구현하는 고가용/고확장성 서비스
https://www.slideshare.net/andrewdohyunjung/msa-43702981
1. MSA를 이용해 구현하는 고가용/고확장성 서비스
2. 자기소개 ▪ 정도현 – SW컨설턴트/아키텍트 – 일본 豆蔵 Mamezou – Blog : moreagile.net – InfoQ Japan 필진 – QCon2015 준비위원 – SSAG 운영진 Powered by wonderboyfactory.com
3. Agenda ▪ MSA ▪ DDD ▪ Docker ▪ Spring Boot ▪ Api Gateway ▪ Reactive Microservices Architecture ▪ Conclusion
4. 오늘날의 소프트웨어들의 도전 과제들 ▪ 갈수록 복잡해지는 비즈니스 ▪ 짧아지는 기술 수명 주기 ▪ 신/구 기술이 공존하는 상황
5. Google trends - microservices
6. MSA란? ▪ MobileSuitsMicroServicesArchitecture의 약어 ▪ 2012년ThoughtWorks의 James Lewis가 Java, the Unix way라는 제목의 발표에서 처음으로 언급 ▪ 2014년 3월 James Lewis와 Martin Fowler가 Microservices라는 타이틀로 패러다임을 정립한 기사를 발표 – 독립적이고 단순한 서비스로 전체 서비스를 구성 ▪ 데이터, 거버넌스, 아키텍처등에 있어서 완전한 독립 – 독립적인 팀이 각 서비스의 개발과 운영을 담당 ▪ 책임과 권한에 있어서 완전한 독립을 추구 © Sunrise
7. Service-oriented architecture와 무엇이 다른가? ▪ Microservic는 SOA 구분되기 위한 마케팅적 필요에 의한 선긋기 ▪ 동일한 목표점 ▪ 구현에 필요한 기술과 패러다임이 정립되지 않았음 ▪ 성공과 실패의 요인을 공유 – 구현과 테스트, 운영등에 있어서 유용한 경험이 SOA의 사례를 통해 축적되어 있음.
8. 마이크로서비스의 아홉가지 특징 http://martinfowler.com/articles/microservices.html ▪ Componentization via Services / 서비스에 의한 컴포넌트화 ▪ Organized around Business Capabilities / 비즈니스 영역에 따른 조직화 ▪ Products not Projects / 프로젝트가 아닌 프로덕트 ▪ Smart endpoints and dumb pipes / 단순한 어플리케이션간 연동과 파이프처리 – 유닉스의 철학 ▪ Decentralized Governance / 개발의 분권화 ▪ Decentralized Data Management / 데이터 관리의 분권화 – Polyglot Persistence ▪ Infrastructure Automation / 환경구축의 자동화 - DevOps ▪ Design for failure / 장해를 전제로한 설계 ▪ Evolutionary Design / 변화에 대응하는 설계
9. Unix way ps aux | grep conky | grep -v grep | awk '{print $2}' | xargs kill
10. http://www.slideshare.net/Pivotal/arch-forcd-microservices
11. Monolithic Architecture의 장/단점 ▪ 장점 – 심플한 구조 – 간편한 코드관리 – 간편한 트랜젝션관리 – 설계/테스트가 간편 ▪ 단점 – 고장 – 다중화 – 개발/운영 사이클 관리 – 브런치/테스트 전략 – 확장성 – 스케일업 – 신기술 도입이 어려움 © Sunrise
12. http://thenewstack.io/the-new-stack-podcast-show-2-the- rise-of-microservices-in-the-paas-world/ 조합성 서비스 연결성 느슨한결합 © Sunrise
13. 마이크로서비스 구현 예(도메인구성) ▪ 쇼핑몰 사이트 – 사용자 관리와 인증 – 상품 등록 – 상품 검색 – 카트 관리와 주문 – 주문 처리와 배송 – 구입 후기 관리 ▪ 이 모든처리가 각각 별도의 도메인으로 정의 가능
14. 마이크로서비스 구현 예(어플리케이션 구성) http://www.infoq.com/articles/microservices-intro
15. 마이크로서비스 설계시 고려사항들 ▪ 기능적합성 ▪ 성능효율성 ▪ 호환성 ▪ 사용성 ▪ 신뢰성 ▪ 보안 ▪ 유지보수성 ▪ 이식성
16. Agenda ▪ MSA ▪ Docker ▪ Spring Boot ▪ Api Gateway ▪ Reactive Microservices Architecture ▪ Conclusion
17. 도메인 주도 설계Domain-Driven Design
18. 플라톤의 이데아 모델 Powered by wonderboyfactory.com
19. DDD에서 얻을 수 있는 해법들 ▪ 어떤 단위로 서비스를 구성할 것인가? – Context Boundary ▪ 서비스의 결합 – Aggregate ▪ 변화에 강한 설계 – Supple Design ▪ 레거시 시스템의 단계적 폐기 ▪ 리팩터링 전략
20. Domain Model 정제과정의 예 http://agiledata.org/essays/agileDataModeling.html
21. Agenda ▪ MSA ▪ DDD ▪ Spring Boot ▪ Api Gateway ▪ Reactive Microservices Architecture ▪ Conclusion
22. 마이크로서비스 설계시 고려사항들 ▪ 기능적합성 ▪ 호환성 ▪ 사용성 ▪ 보안 ▪ 이식성
23. 마이크로서비스의 구성예(Netflix) http://techblog.netflix.com/2013/01/announcing-ribbon-tying-netflix-mid.html
24. VMs의 문제점 ▪ 가상환경 서버라고는 해도 환경변수나 언어버전, 라이브러리 버전 이 달라 어플리케이션이 동장을 하지 않는다 ▪ 개발환경에서는 잘 움직이다가도 프로덕션 환경에서 제대로 움직 이지 않는다 ▪ 기존환경의 가동을 중단시키지 않으면서도 새로운 어플리케이션 이나 기능을 추가하는데 제약이 있음 – OS 업데이트시에 인스턴스 reboot가 필요
25. Docker란? ▪ 구글이 LXC(Linux Containers)호환 가상화 기술 – 컨테이너를 구동하기 위한 플랫폼 ▪ 컨테이너란? – 프로그램이 작동하기 위한 최소한의 요소들을 묶은 패키지 ▪ Solomon Hykes가 dotCloud사의 내부프로젝트로 시작 ▪ 2013년 3월에 오픈소스 공개. 2014년 3월 0.9버전 릴리즈 ▪ Go언어로 작성 ▪ 다양한 통합 지원 – Google Cloud Platform, Amazon Web Services, Ansible, CFEngine, Chef, Jenkins, Microsoft Azure, OpenStack Nova,OpenSVC, Puppet, Salt, andVagrant. (Wikipedia)
26. 벤치마크 결과(기동/종료) http://www.slideshare.net/Flux7Labs/performance-of-docker-vs-vms
27. 벤치마크 결과(I/O) http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
28. 벤치마크 결과(MySql Throughput) http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
29. Docker의 이점 ▪ application-centric:어플리케이션 중심 ▪ portability: 한번의 빌드로 모든곳에서 동일한 작동을 보장 ▪ versioning: Git와 닮아 있는 이미지 버전 관리 기능 ▪ automation: 편리한 툴을 이용한 자동화 ▪ sharing: Docker Hub를 이용해 이미지를 자유롭게 공유 – https://hub.docker.com/ ▪ reusability: 만들어진 이미지는 여러가지 목적으로 재 사용 가능
30. Docker hub의 공식 저장소들
31. Docker맛보기 ▪ Boot2Docker설치 – https://github.com/boot2docker/windows-installer ▪ 바탕화면에서 Boot2Docker Start를 실행
32. Vagrant를 이용한 Docker이미지 실행 ▪ Vagrant란? – VM관리용 툴 (VM판 maven) ▪ Vagrant를 설치 – https://www.vagrantup.com/downloads.html ▪ Github에서 docker이미지와 vagrant 설정 샘플을 다운로드 – https://github.com/bubenkoff/vagrant-docker-example ▪ Vagrant 명령어로 docker이미지 실행 > vagrant up > vagrant ssh
33. Agenda ▪ MSA ▪ DDD ▪ Docker ▪ Api Gateway ▪ Reactive Microservices Architecture ▪ Conclusion
34. Spring Boot란? ▪ Spring Framework를 이용해 어플리케이션을 간단하게 만들기 위 한 플랫폼 ▪ Rails의 영향 – Spring Roo – Spring Boot ▪ 모던Java어플리케이션을 간단하게 구축 가능
35. Spring Boot의 장점 ▪ 미리 준비된 모던자바 어플리케이션 조합을 사용 가능 ▪ 의존라이브러리를 포함시키는 것 만으로도 자동적으로 설정이 정 해짐 – Spring, SQL, NoSQL, JMS … ▪ 임베디드 톰캣을 내장하여 간편하게 실행이 가능 – Production Jar 생성기능 ▪ 간편하고 빠르게 작은 규모의 어플리케이션을 빠르게 개발/배포하 는데 특화되어 있음
36. 메모리사용량 비교
37. Install - Maven <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.2.1.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies>
38. Install - Gradle dependencies { compile("org.springframework.boot:spring-boot-starter-web:1.2.1.RELEASE") }
39. Hello package hello; import org.springframework.boot.*; import org.springframework.boot.autoconfigure.*; import org.springframework.stereotype.*; import org.springframework.web.bind.annotation.*; @Controller @EnableAutoConfiguration // 마법의 어노테이션 public class SampleController { @RequestMapping("/") @ResponseBody String home() { return "Hello World!"; } public static void main(String[] args) throws Exception { SpringApplication.run(SampleController.class, args); } }
40. Run ▪ Maven의 경우 > mvn spring-boot:run ▪ Gradle의 경우 > Gradle bootRun ▪ Eclipse로부터 실행하는 경우 – SpringTool Suite (STS) for Eclipse
41. SpringBoot를 Docker에서 실행하기(Linux) ▪ Sample Download $ git clone http://github.com/adaofeliz/spring-boot-maven-docker.git spring-boot- maven-docker ▪ Build & Run $ cd spring-boot-maven-docker $ mvn clean install $ cd target $ docker build -t spring-boot-maven-docker
42. pom.xml <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <artifactId>maven-resources-plugin</artifactId> <executions> <execution> <id>copy-resources</id> <phase>validate</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${basedir}/target/</outputDirectory> <resources> <resource> <directory>.docker</directory> <filtering>true</filtering> </resource> </resources> </configuration> </execution> </executions> </plugin>
43. Dockerfile FROM dockerfile/java:oracle-java7 ADD spring-boot-maven-docker.jar /opt/spring-boot-maven-docker/ EXPOSE 8080 WORKDIR /opt/spring-boot-maven-docker/ CMD ["java", "-jar", "spring-boot-maven-docker.jar"]
44. Spring Boot 사용예: Spring Cloud Config https://github.com/spring-cloud/spring-cloud-config
45. Spring Cloud Config 샘플코드 package sample; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.EnableAutoConfiguration; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; @Configuration @ComponentScan @EnableAutoConfiguration public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } https://github.com/spring-cloud/spring-cloud-config
46. Agenda ▪ MSA ▪ DDD ▪ Docker ▪ Spring Boot ▪ Reactive Microservices Architecture ▪ Conclusion
47. API gateway pattern
48. API gateway pattern
49. API gateway pattern의 특징 ▪ 레거시 시스템과의 통합 ▪ 로드벨런싱 ▪ 테스트/ 목업 ▪ 고장/예외/로깅 공통화 ▪ API Aggregation ▪ 검증된 다양한 제품군 ▪ 제약사항 파악이 중요 – 성능, 트랜젝션등 http://microservices.io/patterns/apigateway.html
50. Agenda ▪ MSA ▪ DDD ▪ Docker ▪ Spring Boot ▪ Api Gateway ▪ Conclusion
51. Reactive Microservices Architecture란? ▪ Reactive Programming ≒ Functional Programming ▪ Functional Programming – 데이터 뿐만이 아니라 행위도 인자값으로 전달하는 프로그래밍 패러다임 ▪ 4 Reactive Principles – 1. Event-Driven – 2. Scalable – 3. Resilient (FaultTolerance) – 4. Responsive
52. 부작용 없는 동시성 프로그래밍
53. Actor란? ▪ 액터는 메시지를 수신하고 그에 대한 행위를 함께 전 달하는 에이전트이다. 행위의 종류에는 다음과 같은 것이있다. – 메시지를 자신 또는 다른 액터에 전송한다. – 액터를 생성한다. – 다음의 행동 (replacement behavior)을 규정한다. ▪ 액터는 메시지를 수신하기 위해 하나의 사서함을 가 진다. 메시지는 액터에 직접 전달되지 않고 사서함에 간접적으로 전달된다. 사서함은 버퍼링 기능이 있으 나, 메시지는 FIFO로 처리되는 것은 아니다. ▪ 액터가 메시지를 받으면 일단 잠금상태가 된다. 잠기 면 메시지는 처리되지 않는다. 다음 액터가 become이 되면 새로운 후계 액터가 동일한 사서함에서 메시지 를 읽고 처리를 계속한다.
54. １．기존JAVA의 방식 double highestScore = 0.0; for (Student s : students) { if (s.gradYear == 2010) { if (s.score > highestScore) { highestScore = s.score; } } } ２．Lambda식 double highestScore = students.filter(#{ Student s -> s.gradYear == 2010 }) .map( #{ Student s -> s.score }) .max(); ３．병렬화 대응 Lambda식 double highestScore = students.asParallelStream() .filter(#{ Student s -> s.gradYear == 2010 }) .map( #{ Student s -> s.score }) .max();
55. https://medium.com/@andrefaria/migrating-an-application-to-a-reactive-architecture-abf042add86f
56. MSA를 이용한 대규모 서비스 구현 예 Optimizing the Netflix API http://techblog.netflix.com/2013/01/optimiz ing-netflix-api.html ▪ dynamic polyglot runtime ▪ fully asynchronous service layer ▪ Reactive programming model
57. Hystrix ▪ Circuit Breaker패턴을 커맨드패턴을 이용해 구현한 라이브러리 ▪ Circuit Breaker패턴이란? – 장애가 발생한 서비스에 계속 접속할 경우, 다른 서비스에도 장애가 전이되 는것을 막기위해 일정시간 에러나 타임아웃이 지정한 수치를 넘어 발생하는 서비스에 대하여 서킷브레이커를 발동시켜 사용 불가상태로 전환함
58. 정상상태 미리 정해둔 수치를 넘 어 타임아웃이나 애러 가 발생할 경우 접속 불 가상태로 전환 일정한 간격으로 서비스 상태를 체크하여 정상으 로 돌아왔는지를 판단
59. Agenda ▪ MSA ▪ DDD ▪ Docker ▪ Spring Boot ▪ Api Gateway ▪ Reactive Microservices Architecture
60. Overhead
61. MSA문제점과 해결책 ▪ 설계의 어려움 – DDD ▪ 레거시 시스템과의 공존, 인터페이스 연계문제 – API gateway ▪ 운영오버헤드 – DevOps/ NoOps ▪ 코드중복 – JVM 또는 .Net상의 언어를 이용한 폴리그랏 프로그래밍 ▪ 데이터중복 ▪ 분산시스템의 복잡성과 비동기성 – Reactive architecure ▪ 테스트의 까다로움 – API gateway, SOATestingTechniques
62. Agile개발과 MSA ▪ 짧은 개발주기 ▪ 작은 개발팀의 중요성 – 창의적인 작업의 경우 3-5명으로 이루어진 팀의 효율이 가장 뛰어남 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.317.7393&rep=rep1&type=pdf – 인원이 많아지면 무임 승차자가 발생 ▪ 자율적인 팀 운영 – 아키텍처 선정 – 배포주기
63. 프로젝트에서 프로덕트로
64. Q&A
65. 참고문헌 ▪ http://www.slideshare.net/yusuke/jjugccc2014fall-architect ▪ http://www.slideshare.net/makingx/spring-boot-spring-boot ▪ http://projects.spring.io/spring-boot/ ▪ http://www.infoq.com/presentations/Micro-Services ▪ http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.htm ▪ http://springinpractice.com/2010/07/06/annotation-based-circuit-breakers-with-spring ▪ http://www.infoq.com/articles/microservices-intro ▪ http://techblog.netflix.com/2013/01/optimizing-netflix-api.html ▪ http://www.slideshare.net/michaelneale/microservices-and-functional-programming ▪ http://www.infoq.com/presentations/Netflix-API-rxjava-hystrix ▪ http://bcho.tistory.com/948 ▪ http://www.moreagile.net/2014/10/microservices.html... 더보기
MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 (API GATEWAY)
MSA(마이크로 서비스 아키텍쳐, 이하 MSA)와 함께 근래에 떠오르고 있는것이 API 게이트 웨이이다. API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능 까지 많은 기능을 담당할 수 있다.
API 게이트웨이의 시작은 MSA가 SOA(서비스 지향 아키텍쳐)에서 시작한것 처럼 ESB (Enterprise Service Bus)에서 부터 시작 되었다. 그래서 ESB의 대부분의 컨셉을 많이 승계했는데, ESB의 실패와 단점을 보완해서 만들어진 사상이 API 게이트웨이이다. ESB가 SOAP/XML 웹서비스 기반의 많은 기능을 가지는 구조였다면, API 게이트 웨이는 JSON/REST 기반에 최소한의 기능을 처리하는 경량화 서비스 이다. 그리고 ESB는 SOA의 사상에서 개념적으로 탄생한 솔루션이라면, API 게이트 웨이는 ESB의 실패와, MSA, REST 구현 사례를 통해서 필요에 의해서 탄생한 솔루션이기 때문에, 그 실용성이 차이가 난다.
MSA에 대한 개념은 http://bcho.tistory.com/948 를 참고하기 바라며, 이 글은 API 게이트웨이에 대한 바른 이해를 돕고, API 게이트웨이를 도입하고자 하는데 필요한 내용을 서술하고자 한다.... 더보기
Microsite Implementation
What? Similar to the virtual site implementation above most site components are shared, but content can be different on microsites (also not a Drupal-specific term or concept). There may also be a more obvious relationship to a main parent site, like a common header or some shared navigation. There could even be relationships between the microsites so that readers are encouraged to move between them. From a design standpoint, microsites aren’t allowed to vary much due to their very tight integration with the main parent site.... 더보기
MicroService Architecture
대규모 소프트웨어 개발에 적용하기 위한 것으로 단독으로 실행 가능하고 독립적으로 배치될 수 있는 작은 단위(모듈)로 기능을 분해하여 서비스 하는 아키텍처. 작은 단위로 기능을 분할할 때 수평 방향의 계층별 절단이 아니라, 수직 방향의 기능별로 절단한다. 절단된 독립적인 작은 모듈을 마이크로서비스라 한다. 각 마이크로서비스는 공유나 프로세스 간 통신이 없이도 독립적으로 실행되며 운영 관리된다. 마이크로서비스 간 연결은 응용 프로그래밍 인터페이스(API : Application Programming Service)를 이용한다. 마이크로서비스는 자원 표현이나 데이터 관리 등에 있어서 기능적으로 완전해야 한다. 마이크로서비스 아키텍처는 레고 블록을 조립하여 원하는 모양으로 만드는 것에 비유할 수 있다. 마이크로서비스 아키텍처 사용으로 개발자들이 클라우드 망을 통해 공유하고 협업하여 자유롭게 소프트웨어를 개발할 수 있으며, 개발 및 유지보수에 드는 시간과 비용이 절감할 수 있다. 단일 서비스로 개발하는 기존 모놀리식(monolithic) 방식과는 반대되며, 서비스 지향 아키텍처(SOA : Service-Oriented Architecture) 방식보다 더 세분화되어 있다.... 더보기
