Cloud native application 입문 관련 자료입니다.
많은 참고 하시기 바랍니다.
1. Cloud Native Application 이성복 엔터프라이즈 서비스 2016. 10
2. 내용 1. Introduction 2. Cloud Native Application 3. Cloud Native Application Reference Model 4. Cloud Native Application 기술 • 12-Factor App • Microservices • Container • Multitenancy • PaaS • API 5. Cloud Native Application Maturity Model 6. Cloud Native Eco system 2
3. 1. Introduction
4. 클라우드 컴퓨팅 4 DevOps-driven multi-cloud Hybrid cloud management Cloud-native app platform Orchestration Analytics | Collaboration | Compliance Infrastructure automation Unified storefront and user experience Service transformation Across any technology Bare-metal, virtual, containers Traditional and modern apps Private, managed and public clouds 인터넷 상에서 컴퓨팅 작업이 이루어 지는 환경(“Computing over the Internet”) • The use of new or existing computing hardware and virtualization technologies to form a shared infrastructure that enables web-based value added services. • End users access cloud- based applications through a web browser or a light-weight desktop or mobile app • The business software and user's data are stored on servers at a remote location • a way to increase capacity or add capabilities on the fly
5. 클라우드 컴퓨팅의 특성 5 • On-demand self-service 서버, 네트워크, 스토리지 같은 컴퓨팅 용량을 이용자의 필요에 따라 자동으로 공급 (서비스 기반) Broad network access 사용자 기기(모바일폰, 노트북, 태블릿 등)는 네트워크를 통해 서비스에 접속하여 사용할 수 있음(인터넷 기술의 사용) Resource pooling 제공자의 컴퓨팅 자원은 다수의 고객들이 공유 가능 (Shared) 고객의 요구에 따라 물리적 자원이나 가상의 자원 형태로 할당/재할당 됨 자원은 위치에 독립적(=추상화)이며, 사용자는 자원의 정확한 위치를 알 필요가 없음 가상화(virtualization)와 multi-tenancy를 통해 구현 Rapid elasticity 자원을 빠르고 탄력적으로 공급(Provisioning/releasing, Scalability & Elasticity) Measured service Provides “pay-as-you-go” service (Metered by Use) 용량(저장용량, 프로세싱, bandwidth 등)을 측정하여 자동으로 자원을 제어하고 최적화 결과는 사용자에게 전달
6. 클라우드 컴퓨팅 서비스 흐름 6 • Interface를 통해 사용자가 카탈로그에서 원하는 서비스 선택 • Systems Management 모듈은 요구에 맞는 자원을 검색 • 클라우드에서 필요한 자원을 가져오는 Provisioning Service를 호출 클라우드 컴퓨팅의 성공요인이자 결과는 표준화와 자동화
7. 클라우드 컴퓨팅의 구성 7 IT 자원을 가상화 기술, 웹 기반 기술 등을 통해 비즈니스용 어플리케이션, 플랫폼, 인프라 등을 주문형 서비스로 제공하기 위한 기술요소 또는 서비스로 구성됨 출처 < Bizmerce, http://blog.bizmerce.com/?p=2301> 사용자 이용자(고객) 관리자 공급자 Cloud Management Area Cloud Admin AreaCloud Service Area Self Service Provisioning Metering & Billing Dynamic Scalable Multi-tenant Host/Network Management Monitoring Predict time of Scale out Multi-service & Catalog Mgmt SaaS PaaS IaaS Physical DatacenterSoftware defined Datacenter Web Console ApplicationOrchestration Server Monitoring SW & OSVirtualization Network API Gateway PlatformAutomation Storage 가상화를 통한 자원의 서비스화 서비스 카탈로그 제공
8. 클라우드 컴퓨팅과 관련 서비스 비교 8 구분 ITO/ITSM ASP/BSP/SaaS Utility Computing / On-demand Cloud computing 자산 소유 • 사용자 • 서비스 제공자 • 서비스 제공자 • 서비스 제공자 서비스 대상 • Total Service • 어플리케이션 중심 인프라 중심의 서비스 • 인프라 • 어플리케이션 특징 • 개별 기업 시스템의 위탁 운영 • 고객별 맞춤 서비스 • 표준 어플리케이션 제공 • 중앙 집중 관리 • 표준, 맞춤 서비스 제 공 • 필요 서비스의 즉시 제공 • 고객이 개발한 어플 리케이션 적용 가능 • 표준 서비스와의 I/F 를 통한 Mashup 장점 • IT 전분야 Total outsourcing 가능 • 필요한 어플리케이션 만 선택 가능 • 최소의 초기투자 • 향후의 소요비용 예 측 가능 • SaaS와 Utility computing 개념의 결합
9. [참고] 클라우드 컴퓨팅의 기술 요소 9 중분류 소분류 요소기술 클라우드 서비스와 응용 기술 SaaS 플랫폼 기술 • Multi-tenant 기술 • SaaS 어플리케이션 생성 환경 기술 • Legacy 서비스 연동 기술 클라우드 응용 컴포넌트 키술 • 서비스와 응용 OpenAPI • 클라우드 소프트웨어 컴포넌트와 컴포넌트 연동기술 클라우드 서비스 개발 기술 • 웹 기반 개발 도구 • 분산 클라우드 서비스 디버깅 기술 클라우드 클라이언트 기술 • 클라우드 경량 단말 플랫폼 기술 • 클라우드와 모바일 동기화(sync) 기술 • 클라우드 Push agent 기술 클라우드 플랫폼 기술 서비스 배치와 관리 기술 • 클라우드 SLA 제공 기술 • 서비스 생성과 자동 프로비저닝 기술 • 이중 클라우드 서비스/데이터 호환 기술 • 서비스 과금 기술 클라우드 분산 시스템 기술 • 분산 파일시스템 기술 • 분산 데이터 자장과 관리 기술 • 분산 병렬 처리 기술 • 분산 실시간 데이터 스트링 처리 기술 클라우드 보안 기술 • 개인정보(privacy)와 데이터 보안 기술 • Trustworthy 컴퓨팅 기술 • 클라우드 SSO 기술 • 클라우드 네트워크 보안 기술 클라우드 인프라 기술 인프라 자원 관리 기술 • 개방형 자원 모니터링과 스케줄링 기술 • 지능형 동적 부하관리 기술 인프라 자원 가상화 기술 • 서버 가상화 기술 • 스토리지 가상화 기술 • 네트워크 가상화 기술 • 입출력 가상화 기술 클라우드 네트워크 기술 • 확장형 고속 네트워크 기술 • 클라우드간 연동 기술
10. 2. Cloud Native Application
11. 어플리케이션의 유형 11 Native application (desk-top) 특정 Platform이나 Device에서 사용되도록 개발된 Application • can interact with and take advantage of operating system features and other software that is typically installed on that platform. • has the ability to use device-specific hardware and software, meaning that native apps can take advantage of the latest technology available on mobile devices such as a GPS and camera. • This can be construed as an advantage for native apps over Web apps or mobile cloud apps. Web application 표준 Web 기술을 사용하여 Platform이나 Device에 상관 없이 사용되도록 개발된 Application • Client-server 소프트웨어 어플리케이션 • 프로그램은 원격 서버에 저장되고 인터넷을 통해 웹 브라우저에서 실행 • 예) webmail, online retail sales, online auctions, wikis, instant messaging services 등 Cloud (native) application Desktop application + Web application으로 클라우드 환경에서 실행되는 어플리케이션 프로그램 • desktop app과 같이 응답 속도가 빠르고 오프라인에서도 작업 가능 • web apps처럼 특정 기기(device)에 종속될 필요가 없고 온라인으로 쉽게 업데이트 가능 • 사용자가 통제 가능하지만, 사용자 컴퓨터나 저장장치의 저장공간을 사용할 수 없음 . • a well-written cloud app offers all the interactivity of a desktop app along with the portability of a Web app. 어떤 종류의 어플리케이션들이 있는가?
12. Cloud Native Application 12 Cloud Native Application = software-as-a-service(SaaS) Software as a Service(SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as "on-demand software". SaaS is typically accessed by users using a thin client via a web browser. Cloud 환경에 최적화 되어 서비스 되도록 개발된 어플리케이션 Cloud-native app is a term promoted by VMware to refer to apps that are installed in cloud-based virtual machines. (Webopedia)
13. Cloud Native Application의 핵심은 ‘서비스’ • 어플리케이션을 여러 개의 서로 독립적인 기능을 하는 서비스로 구분 • 이 서비스들을 어떻게 구성하고 어떻게 연결하고 어떻게 관리하느냐가 관건 • 이 ‘서비스’들을 묶어서 하나의 통합된 ‘(비즈니스) 서비스’를 할 수 있도록 하기 위한 다양한 기능과 기술 필요 13
14. Cloud Computing CNA PaaS IaaS SaaS Container 12-factor App Multi- tenant MSA Codebase Continuous Delivery CI CD DevOps Services Domain- Driven Design API DB Decomposition SOA Bounded Context API Gateway Protocol 통신 포맷 API Management Authentication Authorization Control Monitoring API token Multi- tenancy DB Isolated Shared Full Shared Semi Shared Configuration Dev/Prod parity Services Isolation Stateless Processes Build, release, run Backing services ESB
15. Cloud Native Application이 출현하게 된 배경 15 • Open Source 기반의 Cloud computing 확산 • Cloud Platform 확대 : Network을 기반으로 하는 platform 비즈니스의 확대 • 대형 또는 복잡한 application들 간의 협업/통합 강화 새로운 개발/배포/운영 방법의 도입 필요 : Cloud Native Application 클라우드 컴퓨팅 : 어플리케이션 개발과 운영 환경의 변화 • 새로운 요구(기능/시스템)에 대한 빠른 대응 • 유연하고 신속한 확장성(Scalability) • 장애에 대한 대응과 장애 시 신속한 복구 • Continuous Delivery : Continuous Integration & Continuous Deploy 비즈니스 변화에 대한 신속한 대응력 확보 필요
16. Cloud Native Application 출처 < “A Cloud-native Application Reference Model for Enterprise Architects”, ClouNS> 16 Cloud 환경에 최적화 되어 서비스 되도록 개발된 어플리케이션 A cloud-native application is a distributed, elastic and horizontal scalable system composed of (micro)services which isolates state in a minimum of stateful components.The application and each self-contained deployment unit of that application is designed according to cloud-focused design patterns and operated on a self-service elastic platform.
17. Traditional Application Architecture와 주요 특징 비교 17 From the “Old World” To the “New World” Traditional Application Architectures • Scale Up • Monolithic & Layered • Stateful - steady • Infra Dependent & statics Infra • Fixed Capacity • LAN, SAN • Latency intolerant • Tightly coupled • Consolidated /clustered DB/Rich / Chatty Client • Commercial licenses • Infra Supported Availability – infra redundancy • Manual build/deploy • Manual fault recovery • Active/Passive/DR • Perimeter Security (경계기반 보안) • Allocated and fixed costs(CAPEX) • Scale Out • Distributed & Microservices • Stateless – fluid and ephemeral • Infra Agnostic & Elastic infra • Elastic capacity • WAN, Location • transparency • Latency tolerant • Loosely coupled • Sharded / replicated/ distributed DB • Mobile/thin Client • Cloud PaaS / Open Source • App Supported Availability - resilient • Automation • Self healing • Active/Active • Defense in depth • Metered and variable cost (OpEX) Cloud Aligned Application Architectures
18. Cloud Native Application The move to “value creator” requires agility on many fronts 18 What? Key characteristics … • Services • Handling Failures • Horizontal Scalability • Asynchronous Processing • Stateless Model • Minimize Human Intervention & Continuous Delivery Why? There is a need for … • Speed (delivery) • Safety (fault tolerance, design for failure) • Scalability • Client diversity How? Integrate .. • Microservices oriented architectures (a service should do one thing well) • Use API-based collaboration • Cloud methodology : 12-factor app • Use multi-tenant DB architecture • Use self-service agile platforms
19. Cloud Native Application의 주요 특징(What) Services • Services are loosely coupled • All functionality/service is published and consumed via web services (API) • provision instances of themselves through an API Handling Failures Horizontal Scalability • Every Integration point will eventually fail one time or another • Resilient to inevitable failures in the infrastructure and application • 장애에 대비한 설계 • Design for Scale Out • 수 천 수 만개의 노드나 인스턴스들에 대해서도 빠른 속도로 scale IN과 scale OUT할 수 있음 • Scale elastically without significant changes to tooling, architecture or development practices Asynchronous Processing • Break down the task, process requests asynchronously • Use queues to decouple functionality • Eventual consistency model Stateless Model • Build stateless services that can be scaled out and load balanced • 어플리케이션과 관련된 모든 데이터는 어플리케이션 코드 자체와는 완벽히 분리됨 • multi-tenant application : 여러 사용자가 동시에 실행할 수 있으며, 각 사용자별로 “data block” 가짐 Minimize Human Intervention • Go DevOps/NoOps • Rapid and repeatable deployments to maximise agility • 장애를 탐지하여 회피할 수 있으며, 하나 이상의 노드가 손실되면 새 노드가 빠르게 생성 19
20. Cloud Native Application과 Traditional Application 비교 20 Traditional Application Cloud Native Application Data center as a single point of failure Business Logic Customer experience depending on single data center & network health Vertically scaled traditional RDBMS with limited scalability Failover to standby causes outages Shared storage is single points of failure. Highly available customer experience Routed to nearest available data center Stateless Business Logic Node Node Node Scale out data tier Bi-directional replication Stateless Business Logic Node Node Node Scale out data tier Stateless Business Logic Node Node Node Scale out data tier Cloud Native Application의 주요 특징(What)
21. Cloud-native application architecture가 필요한 이유(Why) 21 Speed of Innovation to deliver software-based solutions more quickly • 새로운 어플리케이션 환경 제공 또는 새 버전의 소프트웨어 배포 • 잘못 배포했을 경우 즉각적인 복구 Mobile-centric user experiences to handle a huge diversity of (mobile) platforms and legacy systems (client diversity) • IT 환경과 비즈니스 서비스에서 다양성의 극단적인 확대 • Mobile 환경과 서비스의 확대 mobile 우선의 개발 Always-available services(Safety) 장애발생 시 타 서비스에 영향을 주지 않으면서도 빠르게 복구할 수 있는 아키텍처 • Visibility : 장애 상황을 파악할 수 있는 도구 제공 • Fault isolation : 장애 영향을 받는 서비스 구성범위 제한 • Fault tolerance : 장애가 퍼지지 않도록 의존성 최소화 • automatic recovery : 정형화된 유형의 장애들은 시스템이 자동으로 복구 Web Scale to enable horizontal (instead of vertical) application scaling • Scale up을 통한 수직적인 확장 비용부담이 적고 빠른 Scale out을 통한 수평적인 확장 • 작고 균일한 서버들의 가상화를 통한 workload ochestration 빠르게 변화하는 비즈니스 환경에 대응 출처 < “Migrating to Cloud-Native Application Architecture”, Matt Stine, 2015>
22. Cloud Native Application을 가능하게 하는 기술(How) 22 Microservices Software architecture style : complex apps are composed of small, independent processes communicating with each other using language-agnostic APIs. 12-Factors App Methodology for building modern, scalable, maintainable cloud apps Multi-tenancy Fundamental technology to share IT resources securely among multiple applications and tenants that use the cloud. Container operating-system-level virtualization environment for running multiple isolated Linux systems on a single Linux host PaaS A set of services that provides application lifecycle management, scale out, failure recovery, authentication, and logging. API accessibility to software that enables machines to interact with cloud software in the same way the user interface facilitates interaction between humans and computers Cloud Native Application을 가능하게 하는 기술들과 관련 주요 개념들
23. [참고] Cloud/SaaS Enabled Application Platform의 주요 특성 23 출처<Gartner, 2009> • Multitenancy Multitenant execution (별도의 프로세스, 메모리, 데이터 접근, 성능). Tenant-aware security, monitoring, reporting and management. Tenant customization and user personalization within a tenant. Tenant on- and off-ramping User on- and off-ramping. Application on- and off-ramping and version control. Tenant-aware error tracking, diagnostics and recovery • Resource pooling • Elasticity (just-in-time on-demand computing resources) • Fine-grained usage tracking, metrics and costing • XTP-grade global class advanced scalability, performance and availability • Self-service user/administrator experience Hardware Infrastructure SaaS/Cloud-Enabled Application Platform SaaS Application Tenant Tenant Tenant Data Platform 사용자 사용자 사용자
24. 3. Cloud Native Application Reference Model <출처 : “A Cloud-native Application Reference Model for Enterprise Architects”, ClouNS>
25. Cloud Native Application Reference Model 25 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage layer-based reference models
26. Cloud Native Application Reference Model 26 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage scalable system composed of (micro)services
27. Cloud Native Application Reference Model 27 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage Isolate state
28. Cloud Native Application Reference Model 28 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage self-contained deployment unit
29. Cloud Native Application Reference Model 29 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage elastic platform
30. Cloud Native Application Reference Model 30 Application (Layer 6) Micro-Services (Layer 5) Cluster (Layer 4) Node (Layer 3) Virtual Host (Layer 2) Physical Host (Layer 1) An application is composed of services A service is composed of containers and interacts with other services. Provides a portable cloud runtime environment with elasticity features for containers including; • Auto scaling • Auto replicating • Load balancing • Health checking • Rolling updating • Resource monitoring • Service Registry/Discovery • Image Registry • Scales cluster size. • Spans cluster across providers • Bridge IaaS networks One or more CSPs provide infrastructure to store data Application centric view point (SaaS) Service centric view point (PaaS) Cluster centric view point(CaaS) Node centric view point (IaaS) IaaS Provider mIaaS Provider n Container Orchestrator Cloud Native Applications Functional Services / All Purpose Services Cluster Scheduler Container Engine + Overlay Network Agent Operating System Virtual Infrastructure Virtual Network(SDN) Physical Infrastructure Storage Services File Storage Agent Operation System Virtual Infrastructure Block Storage Physical Infrastructure Overlay Network Provides storage for stateful containers and services; • Object Storage • File Storage • Block Storage One or more cloud service providers(CSPs) provide infrastructure to operate containers. Clustered Storage distributed, elastic and horizontal
31. 4. Cloud Native Application 기술 12-Factor App Microservices Container Multitenancy PaaS API
32. 12-Factor App
33. Codebase Dependencies Configuration Backing Services Build, Release, Run Processes Port Binding Concurrency Disposability Dev/Prod Parity Logs Admin Processes 12-Factor App이란? software(SaaS)를 개발하고 배포하기 위한 일련의 방법론 또는 Best practice • Practices translate into platform features and workflow requirements http://12factor.net • Apps don’t need to follow all 12 rules for customer to be PaaS ready 33
34. 12-Factor App의 장점 설정 자동화를 위한 절차(declarative)를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용 최소화 OS에 따라 달라지는 부분을 명확히 하고, 실행 환경 사이의 이식성을 극대화 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리 불필요 개발과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale out) 34
35. 12-Factor App 35 1.Codebase • 개별 어플리케이션은 버전관리 시스템으로 하나의 코드베이스로 버전 관리 • 이 하나의 코드베이스를 가지고 여러 환경에 걸쳐 있는 다양한 인스턴스에 배포할 수 있어야 함(Single code, Multi deploys) 2. Dependencies (isolation) • 종속이 필요한 경우에는 명시적으로 선언하고 최대한 고립시킴(isolate) : 패키지, 파이브러리 등 • 절대로 시스템 전반에 걸치(system-wide) 종속성을 갖도록 하지 않음 3. Configuration • 설정 정보와 기타 배포환경(개발계, 검증계, 운영계 등)별로 다른 정보들은 OS단의 환경(변수)에 저장 • 설정 정보와 프로그램 소스 코드를 분리하여 관리 4. Backing Services • 어플리케이션 작동에 필요한 모든 서비스 (DB, 메시지 큐, 검색엔진, 캐시 등)를 자원의 일부처럼 취급 • 로컬 자원과 원격 자원은 명확히 구분하여 취급하며 자유롭게 연결/분리 5. Build, release, run • 개발(build) 단계와 실행(운영) 단계는 엄격하게 분리 : 어플리케이션과 설정 정보의 결합, 그 결합에서 비롯되는 절차들 6. Processes • 애플리케이션을 실행 시 하나 혹은 여러 개의 stateless 프로세스로 실행 • 절대 sticky session 사용 금지, 자원공유 금지 7. Port binding(포트 지정) • 어플리케이션은 독립적이며, HTTP같은 port binding을 통해서 서비스를 내보내고 받음 • 하나의 서비스가 다른 어플리케이션의 백엔드 서비스가 될 수 있음 8. Concurrency(병행, 동시성) • 어플리케이션 프로세스를 수평적으로 확장(scale out) 시스템 병행 보장 • 개별 가상화 머신(VMs)은 can only scale vertically so far • Stateless한 특성이 확장(scaling)을 단순하게 만들어줌 10. Dev/prod parity • 개발계, 검증계(staging), 운영계의 환경을 가능한 최대로 비슷하게 유지함으로써 지속적인 개발과 배포 가능 • 환경이 다르더라도 백엔드 서비스는 똑같은 것을 사용 11. Logs • 로그 파일을 관리하는 대신 로그를 이벤트 스트림으로 취급 실행 환경이 이벤트를 취합, 인덱싱, 분석할 수 있도록 함 12. Admin processes • 시스템 관리(admin/management) 작업은 일회성 프로세스로 만들어서 실행 (예, 디버깅을 위한 데이터베이스 이행) 9. Disposability • 빠른 시작, 안정적으로 종료(graceful shutdown) 안정성 극대화 • Application instances are disposable • 빠르고 유연한 확장, 변화 사항의 적용, 충돌로부터 회복 등을 가능하게 함
36. 12-Factor App의 효과 .. 배포할 환경에 구애받지 않고 어떤 클라우드 환경에서든 어플리케이션을 빠르게 배포 어플리케이션의 일회성(또는 폐기가능성) 때문에 어플리케이션이 어느 상태에 있더라도 적은 비용으로 어플리케이션 폐기 가능 어플리케이션의 확장과 축소를 (자동으로) 유연하게 장애상황이 발생하는 경우 자동적으로 빠르게 복구 가능 로그를 이벤트 스트림으로 처리함으로써 운영상태와 설정사항 간의 일치성, 백엔드 서비스 관리 등에 대한 가시성을 높임 36
37. Microservices
38. Monolithic과 Microservices 38 A monolithic application puts all its functionality into a single process… A microservices architecture puts each element of functionality into a separate services… … and scales by replicating the monolith on multiple servers … and scales by distributing these services across servers, replicating as needed. 단일 프로세스로 통합된 어플리케이션 MicroservicesMonolithic Cloud Native Application과 Traditional Application 비교 여러 개의 서비스들로 분리된 어플리케이션
39. Web Monolithic Architecture 39 Browser/Client “Big” Database (MySQL)L4L4 Web Monolithic Web App (WAS) Monolithic Java Web App (WAS) 사용자 관리 상품관리 주문관리 재고관리 UI/UX File Storage • 하나의 애플리케이션 내에 모든 로직들이 모두 들어 가 있는 “통짜 구조” : 도메인 로직은 클래스나 펑션, 패키지 등으로 구분 • 모든 리퀘스트는 하나의 프로세스에서 처리 • 개발이 완료되면 전체 로직들에 대한 테스트가 진행되고 전체 프로그램이 빌드되서 서버에 배포 • 각 컴포넌트들은 상호 호출을 함수를 이용한 call-by-reference 구조 성능제약이 덜함 • 물리적인 서버 또는 가상화 서버에 동일한 인스턴스 전체가 배포되는 것으로 수평확장되며, 확장된 인스턴스들은 Loadbalancer 뒤에서 동작 현재까지 일반적으로 사용하고 있는 웹 시스템 개발 아키텍처
40. 문제점 – “통짜 구조＂ 40 규모가 큰 애플리케이션에서는 불리 빌드, 배포, 서버 기동 시 시간이 오래 걸림 한 두 사람의 실수는 전체 시스템의 빌드 실패를 유발 프로젝트가 커질수록 협업하기 어려움 컴포넌트들이 서로 로컬 콜 (call-by-reference)기반으로 강하게 결합(tightly coupled) 특정 컴포넌트나 모듈에서의 성능 문제나 장애가 다른 컴포넌트에까지 영향 코드가 너무 커져서 유지보수 어려움 기존 로직/데이터/인터페이스 등의 변경에 따른 영향을 파악하기 어려움 배포가 잦은 시스템에 불리 사소한 컴포넌트의 수정인데도 전체 어플리케이션을 재컴파일하여 배포를 하고, QA를 거쳐야 함 어플리케이션이 커지고 복잡해 지면서 Monolithic architecture의 장점인 “통짜 구조”가 발목 A monolith is a geological feature consisting of a single massive stone or rock, such as some mountains, or a single large piece of rock placed as, or within, a monument or building.
41. 문제점 – 기술변화에 대한 대응 제한 41 한 번 Technology는 영원한 Technology! 새로운 기술에 대한 도입 어려움 컴포넌트 별로, 기능/비기능적 특성에 맞춰서 다른 기술을 도입하고자 할 때 유연하지 않음 예) 파일 업로드/다운 로드와 같이 IO 작업이 많은 컴포넌트의 경우 node.js를 사용하는 것이 좋을 수 있으나, 애플리케이션이 자바로 개발되면 다른 기술 추가가 매우 어려움 On-Premise Cloud, CI와 연계된 배포 자동화(Jarvis), 향후 Docker와 같은 Container 기술과 연계 어려움 경직성 시스템을 분리, DB의 분리 어려움 시스템간 연계의 증대에 대한 유연한 대응이 어려움 새로운 버전이나 기술의 도입 어려움 또는 불가능 조직의 비대화, 코드의 비대화 변화에 대한 저항 또는 장벽으로 작용 한 어플리케이션에서 개발한 기능은 타 어플리케이션에서 사용하기 어려움
42. 그래서, 가면 갈수록 • 변화나 수정에 대한 두려움 • 개발자들이 구닥다리 기술의 족쇄에서 벗어나지 못하고, 기술 격차는 계속 벌어짐 • 코드 양이 많아지고 중복 코드가 발생 : 기존 기능에 영향을 주지 않기 위해 기존 구조에 자꾸 덧붙이게 됨으로써 산만해지고 복잡해지고 이해 불가능한 구조 • 개선, 변화를 미룸 : 모든 것은 ‘차세대’가 해결해야 줄 것이라는 기대 혹은 방치 42 클라우드 환경에 최적화하여, 빠르게 변화하는 비즈니스 요구사항에 적극 대응하기 위해서는 웹 시스템 개발에 새로운 아키텍처가 필요!
43. 어플리케이션을 “서비스”로 쪼개 보자 43 • 업무상의 기능 또는 역할을 하나의 기능 묶음으로 개발된 컴포넌트 한 가지의 역할만 수행 • REST API 등을 통하여 서비스들의 기능을 제공하고 사용 • 데이터를 공유하지 않고 서비스별로 독립적으로 가공하고 저장함 사용자 관리 인터페이스 • REST • Thrift, Protocol buffer • AMQP • : 사용자 관리 상품 관리 주문 관리 쇼핑몰 웹 API CALL 하나의 기능을 구현 하는데, 여러 개의 서비스를 조합하여 기능을 제공 예) 주문 하기 : 사용자 정보 조회, 상품 정보 조회, 신규 주문 생성 서비스 사용자 정보 상품 정보 주문 정보 사용자 데이터 구체적이면서도 최소 단위의 업무 기능들을 기본단위로 하는 어플리케이션 개발
44. Microservices로의 이행 44 Application (Customer Services의 소비자) Current State Service A는 고객 정보를 얻을 수 있는 1개의 입력지점(service location)을 가짐 (고객명, 고객 파일, 고객 주소 등에 관한 정보) A SOAP based interface has consumers call operations in the service as methods as part of a contract(WSDL), which includes the carrying state as part of the input/output message of the service Service A • Get Customer • Get Customer File • Get Customer Address When something changes with Customer Services or it’s methods/operations, the entire service may be affected by the change, and when changed, the entire services is often re-deployed. Service A URL: /customers/customer{custid}/ Future State Customer service는 1가지 일만 하는 별도의 서비스들로 분할됨으로써 이전 하나의 서비스에서 여러 개의 end point를 만든다. Service A, B, C는 이제 별개의 서비스이지만 각 서비스 자원에 URL을 부여하는 HATEOS(Hypertext As Representational State)를 사용해서 Restful interface로 쉽게 관리할 수 있다. Service A v1 • Get Customer Service A v2 • Get Customer File Service A v3 • Get Customer Address Service B URL: /customers/customer{custid}/file Service C URL: /customers/customer{custid}/address Service B URL: /customers/customer_services.svc Monolithic에서 Microservices로의 변화 사례 When something changes with Customer Service(s), only Customer service is affected, remaining services are not changed or deployed as port of that change. 접속/요청 호출/참조
45. Microservices Architecture 45 클라우드 환경에 적합한 새로운 웹 시스템 개발 아키텍처 MS-A MS-B MS-C MS-D Whitebase A UI B UI C UI D UI Content Router L4L4 Content Router A UI B UI C UI D UI API Gateway (White base) MS-A (Java) MS-B (Nodejs) MS-C (Nodejs) MS-D (Java) Service Registry Event Broker Config Service DB (MySQL) DB (MySQL) Redis (MySQL) File Storage DB (MySQL) Browser/Client API API API API • 서비스는 개별적으로 업데이트되고 배포됨. 대부분 자동화된 스크립트를 통해 이루어짐 • 서비스의 위치를 알려주는 유일한 주소(URL)를 가짐 • 오로지 한 가지의 역할만 수행하는 서비스들(업무 기능, 시나리오, 특정 문제의 해결 등)이 서로 독립적이고 분권화되어 있음 • 고립된 서비스들은 표준화된 API를 통해서 서로 통신/결합 다른 관련 서비스를 바꾸지 않고도 원하는 특정 서비스만 변경 • 구축 시 중점 사항 : 느슨하게 결합된 구성요소들, 확장성, 코드의 분리(partitioning), 업그레이드와 변경을 쉽고 빠르게 하고 유연성을 보장하는 상태 • 자가 치료 : 기계 고장으로 어플리케이션이 멈추면 자동 실행하고 이전의 상태로 복구할 수 있도록 개발 • 데이터베이스의 비정규화 : 서비스와 느슨하게 결합된 스키마 또는 각각의 microservice별로 별개의 스키마 생성
46. Microservices란? 46 비즈니스 시스템(어플리케이션)을 개발/배포/운영할 때, ONE THING 한 가지 기능(비즈니스 관련 기능/역할)을 수행하는데 초점을 맞춘 서비스를 SMALL 독립적이고 배포가능한 가장 작은 단위의 서비스(= atom)로 분리하고 API API를 통해 다른 서비스와 연계하며 AUTONOMOUS 각각 자율적으로 개발, 운영. 즉, 독립적인 팀이 각 서비스(=atom)의 개발과 운영을 담당 “The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.” - Martin Fowler
47. Microservices의 특징 47 1. Componentization via Services (부품화 된 서비스) 한 가지 기능만 수행 2. Organized around Business Capabilities (비즈니스 기능/역할에 따른 분할) 3. Products not Projects (프로젝트가 아닌 개별 제품) 4. Smart endpoints and dumb pipes (단순한 어플리케이션간 연동과 파이프처리 – 유닉스의 철학) 5. Decentralized Governance (통제의 분권화) 6. Decentralized Data Management (데이터 관리의 분권화 – Polyglot Persistence) 7. Infrastructure Automation (자동화된 환경구축 – DevOps) 8. Design for failure (장애에 대비한 설계) 9. Evolutionary Design (변화에 대응하는 설계) • If you want to apply one simple rule to determine if what you are doing is indeed a Microservice model, it would be, that your service can be updated and deployed completely independent of making any change to any other service or a service bus (EBS) • Well-crafted Microservices use well-defined interfaces and protocols and encapsulate their own business rules to be middleware independent. <출처 : http://martinfowler.com/articles/microservices.html> Microservices는 프로그램 언어나 프레임워크나, 미들웨어에 초점을 맞춘 개념이 아님
48. Monolithic과 Microservices Monolithic Microservices Architecture Built as a single logical executable (보통 client- server-database의 3 tier 구조) 개별적으로 실행되고 경량 프로토콜을 통해 통신하는 작은 서비스들의 묶음 Modularity Based on language features Based on business capabilities Agility 전체 어플리케이션을 통째로 빌드하고 배포(새 버전) 변경은 각 서비스별 따로 또는 새로운 서비스 생성 Scaling Entire application scaled horizontally behind a load-balancer Scale UP Each service scaled independently when needed Scale OUT Implementation 한 가지 언어만으로 개발 개별 서비스는 그에 가장 적합한 언어로 개발 Maintainability Large code base intimidating to new developers Smaller code base easier to manage Messaging type Smart, but dependency-laden ESB Synchronous: wait to connect Dumb, fast messaging (as with Apache Kafka) Asynchronous: publish and subscribe Programming style Imperative model Reactive actor programming model that echoes agent-based systems Lines of code per service Hundreds or thousands of lines of code 100 or fewer lines of code State Stateful Stateless Database Large relational database ACID 모델 NoSQL or micro-SQL database blended with conventional database BASE 모델 Code type Procedural Functional Means of evolution Each big service evolves Each small service is immutable and can be abandoned or ignored System-level awareness Less aware and event driven More aware and event driven 48
49. Microservice Architecture의 배경 49 Domain Driven Design Continuous Delivery On-demand Virtualization Elastic, Scalable, Resilience Polyglot Programming Infrastructure Automation Agile Development Reusability Self-government Team write better software faster - faster release cycles are a source of competitive advantage
50. Microservices Architecture의 구성 50 Microservices Architecture를 구성하기 위한 핵심 요소 서비스 • 각 컴포넌트는 서비스라는 형태로 구현되고 API를 이용하여 타 서비스와 통신 • 서비스 경계는 구문 또는 도메인(업무)의 경계를 따름 예) 사용자 관리, 상품 관리, 주문 관리와 같은 각 업무 별로 서비스를 나눠서 정의 • REST API에서 /users, /products와 같이 주요 URI도 하나의 서비스 DevOps • DevOps는 CI에서 좀더 진화된 형태 • 개발, 테스트, 배포를 모두 자동화 시켜 개발 사이클이 끊임없이 순환되도록 함으로서 개발의 속도를 최대화 시키는 개발스타 • 배포가 서비스의 수 만큼 이루어지게 될 뿐만 아니라 테스트 또한 각각의 서비스가 연동되어 발생하는 집합체Aggregate의 수 만큼 필요하게 되므로 필연적으로 DevOps 필요 데이터 분리 • 서비스 별로 필요에 따라 별도의 데이타 베이스를 사용 • 서비스가 API에서부터 데이터베이스까지 분리되는 수직 분할 원칙 (Vertical Slicing)에 따름 • 데이터베이스의 종류 자체를 다르게 하거나, 같은 데이터 베이스를 사용하더라도 스키마를 나누는 방법 사용 API Gateway 모든 api에 대한 end point를 통합하고, 몇가지 추가적인 기능을 제공하는 미들웨어 • EndPoint 통합과 토폴로지 정리 • Orchestration : 여러 개의 서비스를 묶어서 하나의 서비스 생성 • 공통 기능 처리 (Cross cutting function handling) : API 인증 (Authentication), Logging 등 • Mediation : 메시지 포맷 변환, 프로토콜 변환, 메시지 라우팅 등
51. Scale Cube : 어떻게 확장할 것인가? 51 <출처 : http://theartofscalability.com> Microservice architecture에서 서비스나 저장공간을 확장하는 방법 Multiple service types Y축 확장 : Functional decomposition Scale by splitting different things (기능/서비스를 분리/분할) Monolith Cloned & load-balanced X축 확장 : Horizontal duplication (기능/서비스를 이중화) Z축 확장 : Data partitioning Scale by splitting similar things (데이터베이스의 분리 또는 이중화)
52. Y축 확장 52 UI WAS WAR Service A Repository A WAS WAR Service B Repository B 확장 Database WAS WAR UI Service A A Repository Service B B Repository A B Database A Database B 서비스를 분할하고 서비스별로 별도의 데이터베이스 구축
53. WAS WAS B UI A UI Y축 확장 + X축/Z축 확장 53 A UI B UI WAS WAR Service A Repository A WAS WAR Service B Repository B Database A Database B1 Database B2 서비스를 분할하여 이중화하고 서비스별 데이터베이스 이중화 또는 데이터베이스 분리 데이터베이스 이중화 (Z축 확장) 데이터베이스 분리 (Z축 확장) 서비스 분할 서비스 이중화(X축 확장)
54. Microservices의 장점 Technology Heterogeneity 요구사항을 구현하기 위해 최적화된 언어와 아키텍처의 선택 : 다른 프로그래밍언어, 다른 도구를 사용하여 개발 가능 Resilience 오류 발생 시 복구될 때까지 요청 가능 서비스에서 제외 (Circuit Breaker와 로드밸런서가 담당) Scaling 서비스들은 서로 독립적이므로 타 서비스에 영향을 주지 않고 서비스 단위로 확장 가능 API(특히 REST API)를 통해 서비스 간 통신 X축 확장으로 불리는 멀티 애플리케이션(또는 서버)의 확장과 Z축 확장(Partitioning 또는 Sharding)으로 불리는 확장을 독립적으로 수행 Ease of Deployment DevOps와 결합된 각각의 마이크로서비스는 단순한 구조 개발속도와 개선에 높은 효용성 자동화된 단위 테스트와 시나리오 테스트는 빠른 배포주기에도 불구하고 뛰어난 품질을 유지할 수 있도록 함 Organizational Alignment 각각의 마이크로서비스는 개별 팀에서 독립적으로 개발/배포가 가능. 시스템의 규모가 커짐에 따라 추가로 발생하게 되는 오버헤드가 일정수준으로 관리가 가능 Composability 개별 비즈니스 요구사항에 특화된 단순한 서비스 개발자의 관리 범위 명확 소프트웨어의 복잡성을 제어(UI와 컨트롤, 도메인 로직이 별도의 마이크로서비스로 구성되어 완전히 독립적으로 개발) 각 서비스는 다른 데이터 저장소를 사용할 수 있으며 서로 느슨하게 연결 Replaceability 서비스를 나누는 규칙, 즉 서비스를 모듈화하는 규칙으로 동일한 기능을 하는 서비스는 하나의 서비스로 대체 가능 54
55. Microservices의 단점 55 복잡성(Complexity) Hard to develop features span multiple services Greater operational complexity – more moving parts Additional complexity of creating a distributed system – network latency, fault tolerance, serialization, … Multiple Database & Transaction Management Service interfaces and versioning Complicated Test : End-to-end testing 개별 서비스에 대한 테스트는 만들기가 수월하지만 런타임 환경상에서 비동기 상호작용을 테스트하기는 까다로움 Require Automation for Deploy/Operation Devs need significant ops skills 중복성(Duplication) Duplication of effort across service implementations 코드 중복: 여러 언어를 사용하여 개발이 진행되는 경우 코드중복은 필연 오버헤드, 라이브러리 호환성 등을 충분히 고려한 이후 도입 데이터 중복: Maintaining availability and consistency with partitioned data Avoiding latency overhead of large numbers of small service invocations Designing decoupled non-transactional systems is hard Locating service instances
56. Microservices를 도입하기 전에 더 생각해 볼 문제들… 56 서비스 범위 설정 문제 • 어디서부터 어디까지를 묶어야 독립적으로 운영 가능한 서비스가 되는가? • 동일한 문제영역을 나타내는 모델이 한 개 이상 존재할 수 있으며 이러한 문제영역을 올바르게 이해하는데 필요한 것은 실제 문제영역이 어떻게 동작하고 있는가에 대해 있는 그대로를 관찰하고 이를 바탕으로 서비스를 구성 레거시 시스템과의 공존에 대한 고려 • 마이크로서비스를 도입하더라도 (일정 기간은) 기존의 (특히 Monolith)시스템들과의 공존은 필연적으로 존재할 수밖에 없는 상황에서 기존 시스템들과 어떻게 연계할 것인가? 운영 오버헤드 • 마이크로서비스는 엄청나게 많은 양의 배포작업 : 릴리즈가 개별적으로 이루어지는 특성상 이를 별도의 운영팀에서 일괄적으로 관리하는것은 불가능하므로 배포에 수반되는 일련의 작업들을 자동화할 수 있도록 DevOps 도입 인터페이스 불일치: • 어떻게 각각의 서비스의 인터페이스를 변경하는 것에 대한 영향범위를 파악할 것인가? • 어떻게 서비스 외부로 제공하는 인터페이스가 의도하지 않은 형태로 사용되지 않도록 할 것인가? • 어떻게 전체 시스템의 인터페이스 맵을 만들고 팀 간의 커뮤니케이션 비용을 효과적으로 제어할 수 있는가?
57. 그럼 SOA와는 무엇이 다른가? 57 Microservice는 분산 소프트웨어 시스템용으로 확장 또는 특화된 SOA • SOA : 엔터프라이즈 시스템을 중심으로 고안된 아키텍처 • 마이크로서비스 : SOA 사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처 Mircoservices는 서비스의 크기와 서비스간 통신 방법은 어떠해야 하는가에 대한 질문에서 시작 • 서비스는 작은 단위여야 하고 통신 프로토콜은 경량이어야 한다! 목표의 차이 • SOA : 재사용성(reusability)과 분리(segregation)에 초점 • microservices : 대형 어플리케이션을 점진적으로 발전하고 더 관리하기 쉬운 단위로 분할 시스템간/서비스간 통신 방법의 차이 • SOA : 데이터를 관리하고 분류하는 등 많은 책임을 가진 ESB를 통해 서로 다른 시스템과 통신 • 마이크로서비스 : 입력된 요청을 한 서비스에서 다른 서비스로 전송만하는 단순 메시지 버스(dumb message bus)를 사용하지만 메시지를 받는 엔드포인트(endpoint)는 필요한 작업을 충분히 수행 Microservice는 DevOps에 맞춰 SOA를 현실화 한 아키텍처 스타일
58. SOA와 Microservices Architecture의 비교 58출처<http://www.soa4u.co.uk/2015/04/a-word-about-microservice-architectures.html> • Built on common governance and standards • 공통된 technical stack • Contracts define service/APIs interfaces • Granularly focused on business capabilities • Services/APIs는 대개 ESB에서 실행됨 • Use of Canonical schemas not uncommon for business services, less common in APIs • API는 외부에서의 사용 목적 (DMZ에 노출) • HTTP 전송이 최적이지만 다른 전송도 지원 • 다수의 메시지 프로토콜 지원:SOAP-XML, REST-JSON, etc) • DevOps/Continuous Delivery 도입/확산 단계 • 느슨한 통제; 표준보다는 협업과 선택의 자유에 초점 • ESB는 많이 사용하지 않음 • 세분화된 업무 기능에 초점 • Service/APl들은 서로 독립적 • Services/APls built using tech stack of choice (usually one that's best for the job) • HTTP/REST나 AMQP 같은 경량 프로토콜 사용 • 출발부터 DevOps / Contlnuous Delivery에 초점 • Services are stateless • Common platform for all services deployed to it • Typically services/APIs runs on an AS, that depends on an MRE • Resources made available to and managed by MRE and AS • Multi-threaded with more overheads to handle I/Os • Use of containers(Dockers, Linux Containers 등) less popular • Common hardware for all services/APIs running on the same ESB or Application Server clusters • Single-threaded typically with use of Event Loop(callbacks) features for no-locking I/O handling • Application server not really used. Platforms such as Node.JS can be used but not mandated(no tech stack enforced) • Use of containers more popular as services/APIs are more independent on other applications • Common hardware optional Typical Systems Layers in SOA architectures Typical Systems Layers in Microservices architectures System Layer 관점에서 본 비교
59. Microservices 모델링 Domain Driven Design Bounded Context Contract-First(API-First) Design Decomposed database Event-Driven Architecture 59 DDD is about designing software based on models of the underlying domain. 소프트웨어 개발의 복잡성의 차원 • 본질적(필연적) 복잡성 : 소프트웨어 구현하고자 하는 기능에 대한 복잡성 • 우연적 복잡성 : 소프트웨어를 구현하는 행위(언어, 툴, 라이브러리 등)에 따른 복잡성 도메인이란? • 자동화된 비즈니스 프로세스 • 현실세계의 문제 • 일종의 업무 영역 도메인 모델이란 • 소프트웨어 기능을 위해서 도메인 전문가의 지식에서 선택적으로 추상화하여 엄격하게 조직화한 것 • 다이어그램 등으로 전달하고자 하는 아이디어와 모델을 가시적으로 표현 • 복잡성을 다루는 도구이자 추상화의 결과 • 도메인 전문가와 개발자(개발자들 간에도) 사이의 소통의 중심 기능(요구사항) - 도메인 모델(유연한 설계) - 구현이 자연스럽게 연결. 즉, 기능과 구현의 자연스로운 통로 소프트웨어 개발에서 Domain-Driven Design 이란 • 소프트웨어는 도메인의 핵심개념과 각 구성요소를 담고 있어야 하고 그들 간의 관계를 정확하게 실체화 • 소프트웨어는 도메인을 모델링하고 개발 과정에서의 피드백을 통해 설계 강화
60. Microservices 모델링 Domain Driven Design Bounded Context Contract-First(API-First) Design Decomposed database Event-Driven Architecture 60 도메인 모델이 커질 수록 전체 비즈니스를 아우르는 하나의 단일한 통합 모델로 만들기는 점점 어려워 짐. 그래서, • DDD divides up a large system into Bounded Contexts, • 각각은 별도의 통합된 모델을 가짐 - essentially a way of structuring MultipleCanonicalModels. Bounded Context 스스로 독립적이고 완결적인 맥락을 가지며, 주변 서비스의 내부 설계와는 관계없이 다른 맥락을 가진 서비스와의 모델이나 데이터 참조는 정확히 정의된 인터페이스(API) 로 통신 Bounded Context의 두 가지 측면 • unrelated concepts : 서로 연관 없는 개념(서비스 티켓은 고객 지원이라는 맥락에서만 존재) • share concepts : 같이 공유할 수 있는 개념(제품, 고객 등) Context의 특성 • Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration. • since models act as Ubiquitous Language, you need a different model when the language changes. • You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application. This boundary is set by the different way we represent models. Domain-Driven Design의 핵심 유형
61. Microservices 모델링 Domain Driven Design Bounded Context Contract-First(API-First) Design Decomposed database Event-Driven Architecture This method utilizes agile approach for web apps development. The workflow is as follows: • A developer picks a single, isolated feature to develop • The developer writes the API description • The API description is a subject to review by other devs (and possibly the client) • When the API description is agreed to be done, the dev implements the feature. Contract-First 설계의 장점 • 소프트웨어의 품질을 높임 : 어플리케이션 구축 전에 표준화되고 경량인 RESTful API를 설계 어플리케이션 구축의 뼈대 • 팀간의 커뮤니케이션을 강화함 : When the API design is in place one can count the number of required endpoints, url params, or anything 61
62. Microservices 모델링 Domain Driven Design Bounded Context Contract-First(API-First) Design Decomposed database Event-Driven Architecture 62 분해(decomposition): • 하나의 관계의 열들을 둘 이상의 관계로 분할하며, 관계 유지에 필요한 열들만 복제하는 것 Database decomposition이란? • Decomposition – 구성 항목이나 요소를 더 작게 쪼개는 과정(process) • 데이터베이스에서 Decomposition이란 테이블을 여러 개의 테이블로 쪼개는 것 • From Database perspective means going to a higher normal form 좋은(올바른) 분해의 두 가지 특성 1) Lossless : 어떤 정보를 잃지 않는 분해 2) Preserve dependencies
63. Microservices 모델링 – Domain Driven Design – Bounded Context – Contract-First(API-First) Design – Decomposed database – Event-Driven Architecture 63 이벤트란 무엇인가? 시스템의 내,외부에서 발생한 ‘주목할 만한 상태의 변화(a significant change instate)’ 자동차라는 컴포넌트를 예로 들면, 1. 초기 상태가 ‘판매중(for sale)’ 인 자동차가 2. 고객의 구매로 인하여 3. ’판매됨(sold)’ 상태로 바뀌게 되며 4. 판매 시스템은 이 이벤트를 발행하고 이벤트 중개자에 의해 재무, 마케팅 등 판매 이벤트를 필요로 하는 시스템으로 자동 전송된다. EDA란 • 분산된 시스템 간에 예외 사항, 기회 요인, 조정 시점과 같은 상황을 이벤트로 감지하여 실시간으로 관리하고 처리하는 아키텍처 • 모듈 간 완전한 독립된 관계를 가지며 시스템 유연성을 최대한 보장 • SOA : 동기식 요청/응답 방식, 순차적 처리 • EDA : 비동기식 배포/구독 방식, 비순차적 처리 EDA의 구성 요소 ① Event generator : 시스템 내/외부의 상태 변화를 감지하여 표준화된 이벤트 생성 ② Event channel : 이벤트를 필요로 하는 시스템까지 발송 ③ Event processing engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있음.
64. 모델링/구현 Tip API를 먼저 정의하라. API를 REST API Maturity Level 2 이상이 되도록 강제화하라. API 문서를 유지하라(예: Swagger) ORM을 활용하라 DB에 너무 의존하지 마라 도메인 내부에서만 의미있는 값을 외부에 노출하는 것을 지양하라 마이크로 서비스가 별다른 설정 없이 바로 기동가능하게 하라 (예: Java의 경우, Spring Boot + Embedded WAS 활용) 64
65. Microservice architecture 기반의 개발 방법 65 Backend 개발자 Frontend 개발자 User Story 검토 Contract/ API 설계 Frontend 개발 Backend 개발 Mock/ Unit Test Unit Test API 연동 Load Test Use Story 종료 상세한 User story를 바탕으로 Frontend와 Backend 각각 개발하여 검증
66. Microservices 설계 유형 66 출처<Arun Guta, https://dzone.com/articles/microservice-design-patterns> 1. Aggregator Microservices Design Pattern • Aggregator = 복합 마이크로서비스 • A, B, C 서비스를 다 사용하는 서비스들이 있는 경우에는 이 세 서비스를 추상화하여 묶어서 하나의 복합 microservice를 하나 더 만들 것을 추천 • Aggregator도 독자적인 캐시와 db 가짐 • Aggregator는 독자적으로 X축이나 Z축으로 확장 가능. ※ Contexts and Dependency Injection Bean, 일명 web bean 기본 원리 사용 방법 1. 가장 일반적이고 단순한 어플리케이션 개발에 사용 • 어플리케이션에 필요한 기능을 여러 서비스들로부터 호출하여 사용 • 개별 서비스(A, B, C)들은 경량의 REST API를 통해 노출 웹 페이지는 이를 통해 필요한 데이터/프로세스/화면을 불러옴 (예, 개별 서비스에서 가져온 데이터에 비즈니스 로직을 적용할 프로세싱이 필요한 경우, 그 데이터를 웹 페이지에 표시되도록 전환시키는 CDI bean 사용) 2. 화면이 없는 어플리케이션 또는 다른 서비스들이 사용하는 서비스 개발에 사용 • Aggregator는 개별 마이크로서비스들로부터 데이터를 취합하여 비즈니스 로직을 부여한 후 REST endpoint로 공개 다른 서비스들이 사용하게 됨 Aggregator can scale independently on X-axis and Z-axis as well. So if its a web page then you can spin up additional web servers, or if its a composite microservice using Java EE, then you can spin up additional WildFly instances to meet the growing needs.
67. Microservices 설계 유형 67 2. Proxy Microservices Design Pattern • Aggregator의 변형 • 클라이언트 단에서는 취합(aggregation)이 일어날 필요는 없지만 비즈니스 상의 필요에 따라서 다른 마이크로서비스가 불려올 수도 있음 • Proxy도 독자적으로 X축이나 Z축으로 확장 가능. You may like to do this where each individual service need not be exposed to the consumer and should instead go through an interface. 기본 원리 사용 방법 • 형식적인 proxy로도 사용 가능 : 요청(request)를 서비스 중의 하나로 넘겨주는 경우 • 적극적인 proxy로도 사용 가능 : 클라이언트에게 응답이 가기 전에 몇몇 데이터 정보를 제공하는 경우(예, presentation layer to different devices can be encapsulated in the smart proxy.)
68. Microservices 설계 유형 68 3. Chained Microservices Design Pattern • produce a single consolidated response to the request. • the client is blocked until the complete chain of request/response, 즉 Service A -- Service B 사이와 Service B – Service C 사이의 프로세스가 끝날 때까지 • 각각의 서비스는 각자의 business value를 요청과 응답에 추가 : 들어온 요청이 A에서 B로 갈 때, B에서 C로 갈 때는 그 요청의 내용이 다름. 마찬가지로 C B A로 이어지는 응답 내용이 다름. • 요청/응답 체인을 너무 길게 만들지 않아야 함 : the synchronous nature of the chain will appear like a long wait at the client side, especially if its a web page that is waiting for the response to be shown. There are workarounds to this blocking request/response and are discussed in a subsequent design pattern. • singleton chain : 마이크로서비스 하나만 갖는 체인 This may allow the chain to be expanded at a later point. 기본 원리 the request from the client is received by Service A, which is then communicating with Service B, which in turn may be communicating with Service C. All the services are likely using a synchronous HTTP request/response messaging.
69. Microservices 설계 유형 69 4. Branch Microservices Design Pattern • Aggregator 설계 유형을 확장함으로써 상호 배태적인 두 개의 마이크로서비스 체인으로부터 동시에 응답을 받을 수 있도록 한 설계 유형(simultaneous response processing) 기본 원리 사용 방법 • 업무상 필요에 따라 다른 체인 여러 개 또는 체인 한 개를 불러올 때 사용 • Aggregator 설계 유형과 비슷하게, Service A(웹 페이지이던 또는 복합 microservice이던)는 두 개의 서로 다른 체인을 동시에 불러올 수 있음 can • 아니면 Service A는 클라이언트로 부터 받은 요청에 따라 하나의 체인만 불러올 수도 있음. • JAX-RS이나 Camel endpoint의 라우팅을 사용해서 동적으로 설정할 수 있음
70. Microservices 설계 유형 70 5. Shared Data Microservices Design Pattern • 마이크로서비스 설계 원칙 중의 하나는 자율성(autonomy). 즉 서비스는 모든 것을 갖추고 있어야 하고 모든 구성요소(UI, 미들웨어, persistence, 트랜잭션)를 통제 • 서비스는 polyglot이 가능해야 하며 작업에 필요한 최적의 도구/기술을 사용할 수 있어야 함 • 그러나 체인에서 처럼 캐시와 데이터베이스 저장소를 공유할 수 있음(다, 두 서비스가 강력하게 결합되어 있을 경우만 가능) 기본 원리 사용 방법 • 마이크로서비스가 완전히 자율적으로 구현되기 전까지 이행단계에서 활용 가능 • 데이터베이스 정규화를 통해 더도 덜도 말고 딱 필요한 만큼의 데이터를 갖게 되는데, 마이크로서비스로 이행하려면 기존의 Monolithic application이 SQL만 사용한다 하더라도, 비정규화를 통해 데이터 중복과 불일치성이 발생하게 될 수도 있음 • 이행기간 중에는 이 shared data 설계 유형이 더 효과적일 수 있음
71. Microservices 설계 유형 71 6. Asynchronous Messaging Microservices Design Pattern 기본 원리 • REST 설계 유형이 광범위하게 사용되기는 하지만 동기식이라는 단점이 있음. • 물론 비동기식(Asynchrony)으로도 구현할 수 있지만 어플리케이션 상의 방법으로만 구현 가능 • 그래서 몇몇 microservice architecture는 REST 요청/응답 대신에 메시지 큐(queue)를 사용하기도 함 • Service A는 Service C와는 동기식(synchronously)으로 호촐하고, 그 다음에는 메시지 큐를 사용하여 Service B와 D와는 비동기식(asynchronously)으로 통신 • Service A Service C 간에도 WebSocket을 통해서 비동기식으로 통신할 수 있음(확장성을 위해서) • 업무상 필요에 따라 REST 요청/응답과 publication/subscription 메시지를 결합하여 사용할 수도 있음 사용 방법
72. Microservices의 운영 모델 72
73. Microservices에 관해 더 하고싶은 말들… 73 • 근간은 SOA (Service Oriented Architecture) : SOAP/XML vs. REST/JSON • Vendor Driven Service Company Driven : ‘스펙 먼저’가 아닌 ‘현실에서 검증된 Practice들’의 모음 • 오픈소스 기술 기반 • Enables DevOps : convergence of IT ops and software development to streamline deployment cycles • True agility by teasing out your business services from your legacy monolith so you can update them quickly with high quality and stay ahead of your competitors. • Each team can run as fast as they can without being slowed down by the last team to check in clean code. • Isolation (of independent services) bring higher availability and uptime SLAs. • Better productivity, better focus on business process. Business SME’s and functional leads can drive innovation directly with the IT team • Distributed architecture to scale globally. • speed-to-market과 agility 개선/향상 • Cloud 환경에 최적 ※ SME = Subject Matter Expert(업무 전문가)
74. Container 74
75. Container 출현의 배경 • 프로세스에 자유롭게 자원을 할당할 수 없음 • Significant overhead from calls to the hypervisor from the guest OS can sometimes reduce application performance. • 물리적 연산이 많은 경우(= CPU 작업이 많은 경우) 효율성 낮음 • 여러 가상서버를 동시에 구동하는 경우 성능문제 심각 • 많은 가상머신을 하나의 서버에 구동 시키는 경우 중복된 자원 사용으로 인한 성능 저하가 심각 • 배포 시 OS 이미지를 모두 가지고 있기 때문에 기본적인 가상머신 이미지가 1G~ 300G 까지 그 용량이 매우 커짐 75 환경이나 OS 영역에서 좀 더 효율적이고 안전한 어플리케이션 이동성(portability) 구현에 대한 필요성에 따라 더 강력한 가상화 설계 방법 모색 Virtual Machine의 한계 Container의 출현 • 부두의 컨테이너와 같은 역할 • Container virtualization (= OS 가상화) • Hipervisor가 아니라 host OS 기반 • 컨테이너는 하드웨어를 가상화(which requires full virtualized operating system images for each guest)하는 게 아니라 OS 자체를 가상화하여, host OS kernel 뿐만 아니라 커널의 자원을 host나 다른 container들과 공유
76. Container란? • Containers are an operating-system-level virtualization environment for running multiple isolated Linux systems on a single Linux host • Containers package a software application in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries • 하드웨어를 에뮬레이트 하지 않고 Host OS 의 CPU, Network I/O, Bandwidth, Block I/O, RAM과 같은 자원을 커널레벨에서 격리(isolate)시켜 담아(cotain) 프로세스와 네임스페이스를 host 시스템으로부터 독립적으로 동작하도록 하여 추가적인 overhead 없이 프로세스를 실행 76 리눅스 커널에서 출발한 경량(light weight)의 효과적인 가상화 기법
77. Container와 Virtual Machine 비교 VM Container Containers are isolated, but share OS and, where appropriate, bins/libraries Containers are isolated, but share OS and, where appropriate, bins/libraries …result is significantly faster deployment, much less overhead, easier migration, faster restart Virtual machines include the application, the necessary binaries and libraries and an entire guest operating system - all of which may be tens of GBs in size Containers include the application and all of its dependencies, but share the kernel with other containers, runing as an isolated process in userspace on the host OS. Containers run on any compute substrate (laptop, bare metal, cloud) 77
78. Container와 Virtual Machine 비교 Containers are isolated, but share OS and, where appropriate, bins/libraries VM Container 설명 하드웨어를 공유하는 "가상 머신"을 생성하도록 OS 단위로 서버를 분할(partition)하는 소프트웨어(hypervisor) OS 단위에서 가상화 구현 OS와 일부 미들웨어도 공유 ※ 어플리케이션을 선택할 때는 공통 OS와 미들웨어를 가져야 함 그래서 개발 컨테이너는 코어 서버 플랫폼을 사용하고 그것을 다른 컨테이너와 공유 장점 • 어플리케이션이 실행되는 "guest" 환경은 bare-metal server와 비슷하므로 좀 더 유연함 • 여러 VM이 동일한 서버를 사용하더라도 나만의 별도의 OS와 미들웨어를 선택할 수 있음 • 한 대의 컴퓨터에서 여러 운영체제를 동시에 구동 • 게스트 컴퓨터는 호스트 컴퓨터에 영향을 주지 않음 • 호스트 컴퓨터와 게스트 컴퓨터 또는 게스트 컴퓨터끼리 서로 연결 가능(네트워크) • 모든 어플리케이션이나 컴포넌트가 단일한 플랫폼 소프트웨어를 사용하므로 overhead가 적음 컨테이너 기술로 서버당 더 많은 컴포넌트들을 실행 • 어플리케이션이나 컴포넌트의 배포와 재배포가 빠름 • 관리 도구가 아주 다양한 경우에는 컨테이너 기반의 클라우드가 더 조작편의성이 높음 단점 • 거의 모든 장치들을 가상으로 생성하여 사용하므로 어쩔 수 없이 실제 컴퓨터보다 느리다. • 호스트 컴퓨터의 자원을 빌려 사용하므로 호스트 컴퓨터의 성능에 영향을 미치며 또한 호스트 컴퓨터의 성능에 많은 영향을 받는다. • 다양한 소프트웨어 플랫폼을 갖고 있는 기업의 경우에는 단일 호스팅 플랫폼을 표준화해야 하므로 사용성이 더 어려움 • Even when everything runs on a single OS, you may need to harmonize everything to use a single version of some or all middleware tools -- which can be difficult to do if software is dependent on a specific version. 솔루션 hipervisor Docker 적합도 Public cloud, Hybrid cloud Private cloud(특히 표준화된 OS와 미들웨어가 있는 private cloud) 78
79. Container의 장점 • hold only the application logic and dependencies needed to run so disk footprint is tiny • 하이퍼바이저의 overhead 없이 물리적인 장비의 성능을 그대로 얻을 수 있음 79 Small Fast Port- able • no CPU or I/O penalty because there is no virtualized hardware to pass through or boot • 기존의 어플리케이션을 빠르게 실행 • 데이터 센터 같은 곳에서 고밀도 로 자원을 최적화 • 코드레벨의 빠른 배치가 가능 • because containers are packaging format that holds an application with all of it’s dependencies and configurations it will run the same in any environment
80. Multi-tenancy
81. SaaS 성숙도 수준 81 [Level 1] Ad-hoc/Custom [Level 2] Configurable [Level 3] Configurable, Multi-tenant efficient [Level 4] Scalable, Configurable, Multi-tenant efficient • Similar to ASP model. • Each customer has its own version Of the hosted application, and runs its own instance of the application Of the host's servers. • This level offers very few 이 the benefits Of a fully nature SaaS Solution. • Vendor hosts a separate instance Of the application for each tenant. • Same code, no need to maintain customized application code bases. • Easier support/maintain Since only Single instance needs 10 be updated • More expensive than level 1 in term Of effort required. • Single instance that senes every customer, With configurable metadata. • Authorization & security p이icies ensure that each customer's data is kept separate from that Of other customers. • Eliminates the need to provide server space %r as mam• instances as the vendor has customers. • Vendor hosts multiple customers on a load-balanced farm of identical instances. • Scalable because servers can be added to meet demand without re-architecture. • Changes or fixes Can be roll out to thousands of tenants.
82. 3 Features of Mature SaaS Applications 82 Handle growing amounts of work in a graceful manner Scalable Multi- tenancy Metadata driven configurabil ity Instead of customizing the application for a customer (requiring code changes), one allows the user to configure the application through metadata • One application instance may be serving hundreds of companies • Opposite of multi- instance where each customer is provisioned • their own server running one instance
83. Tenant란? 83 Single Tenancy a group of users who share a common access with specific privileges to the software instance. Multi-Tenancy – Single Instance Multi-Tenancy – Multi Instance
84. Multi-tenancy란? 84 출처<Wikipidia> The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants.A tenant is a group of users who share a common access with specific privileges to the software instance.With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi- instance architectures, where separate software instances operate on behalf of different tenants.
85. 가상화와의 차이점 85 출처<Wikipidia> In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data. Compare this with virtualization where components are transformed, enabling each customer application to appear to run on a separate virtual machine.
86. [참고] Multi-tenancy의 역사 86 출처<Wikipidia> 1. 1960년대 메인프레임 컴퓨터 운영비용을 줄이기 위해 전력과 설치 공간 임대 서비스(time-sharing). Often they also reused existing applications, with simply a separate entry field on the logon screen to specify their customer account ID. On the basis of this ID, the mainframe accounting department could then charge the individual customers for CPU, memory and disk/tape usage actually incurred. 2. 1990년대의 hosted application 서비스를 제공하던 ASP(application service providers). Depending on the limitation of the underlying application, ASPs were forced to host applications on separate machines (if multiple instances of the applications could not be executed in the same physical machine) or as separate processes. Multitenant applications represent a more mature architecture that enables a similar service with lower operational cost. 3. 고객지향 웹 어플리케이션의 진화 Popular consumer-oriented web applications (such as Hotmail) were functionally designed as a single application instance that serves all customers. Multitenant applications represent a natural evolution from this model, offering additional customization to a group of users within the same client organization. Multitenant applications의 뿌리가 되는 3가지 유형의 서비스:
87. [참고] Multi-tenancy Level 87 출처 <https://jothigk.wordpress.com/2010/08/23/just-what-i-know-about-multi-tenancy/> 5. Application level Multi-tenancy 4. Platform level Multi-tenancy 3. OS level Multi-tenancy 2. Hypervisor level Multi-tenancy 1. Physical level Multi-tenancy Data Center floor Infrastructure Operating System Platform Application Data Center floor Infrastructure Operating System Platform Data Center floor Infrastructure Operating System Data Center floor Infrastructure Data Center floor
88. Application level Multitenancy 88출처 <https://jothigk.wordpress.com/2010/08/23/just-what-i-know-about-multi-tenancy/> Single application instance shared by all tenants. A mediator determines tenant in each request so each application request can be handled properly.
89. Multi-Tenant Data 관리를 위한 3가지 접근 방법 89 Isolated Semi-shared Shared SaaS 구현을 위한 multitenant 데이터베이스 아키텍처의 유형 각각의 tenant별로 별도의 데이터베이스 사용 단일 데이터베이스 안에 tenant별로 별도의 전용 테이블 사용 모든 tenant는 같은 테이블을 사용하고, TenantID 컬럼으로 개별 tenent 데이터를 구분
90. Multitenant DB Architecture A technology that clouds use to share IT resources cost-efficiently and securely among multiple tenants Software architecture where a single instance of a software application serves multiple customers Ensures that one tenant operates in isolation from all others 90
91. Multi-tenant DB Architectures 91 1) Separate Databases Single Tenant Storing tenant data in separate databases is the simplest approach to data isolation. • 하나의 서버에 있는 모든 컴퓨팅 자원과 어플리케이션 코드는 모든 tenant에서 공유되지만 각각의 tenant가 가진 데이터는 다른 tenant에 속한 데이터들과는 논리적으로 분리 (별도의 데이터베이스 가짐) • Metadata associates each database with the correct tenant, and database security prevents any tenant from accidentally or maliciously accessing other tenants' data. • 장점 개별 tenant의 필요에 따라 어플리케이션 데이터 모델 확장이 쉬움 장애 시 tenant 데이터의 백업 복구 절차가 상대적으로 간단 강력한 보안과 customization을 위해 독립된 데이터 관리를 원하는 고객(은행, 의료 등) • 단점 장비 유지/관리와 데이터 백업에 비용이 많이 듦 하드웨어 비용이 많이 들어서 다른 아키텍처에 비해 데이터베이스 서버에 올릴 수 있는 tenant의 수가 제한 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
92. Multi-tenant DB Architectures 92 2) Shared Database, Separate Schemas Multi Tenant Another approach involves housing multiple tenants in the same database, with each tenant having its own set of tables that are grouped into a schema created specifically for the tenant. • 고객이 처음으로 서비스에 등록하면 provisioning subsystem이 해당 tenant를 위한 별도의 테이블을 생성하고 tenant와 스키마를 묶어줌 • 상대적으로 데이터베이스 테이블을 적게 사용하는 어플리케이션에 적합 : tenant당 100개 이하의 테이블 • 장점 상대적으로 구현이 쉬움 separate-database approach와 마찬가지로 데이터 모델 확장이 쉬움. (테이블은 제공되는 기본 형태로 생성되지만 필요시 tenant별로 컬럼이나 테이블을 추가하거나 변경할 수 있음) Isolated system만큼은 아니지만 나름 보안이 필요한 tenant에 대해 논리적 데이터 분리 가능 데이터베이스 서버 당 더 많은 수의 tenant 지원 가능 비용 절감 • 단점 장애 시 tenant 데이터 복구가 매우 어려움 :데이터복구를 하려면 같은 데이터베이스를 사용하는 모든 tenant의 데이터를 덮어써야(overwriting) 함 (임시 서버에 데이터베이스를 복구한 다음 운영 서버에 해당 고객의 테이블을 import해야 함) 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
93. Multi-tenant DB Architectures 93 3) Shared Database, Shared Schema Multi Tenant using the same database and the same set of tables to host multiple tenants' data. A given table can include records from multiple tenants stored in any order; a Tenant ID column associates every record with the appropriate tenant. • 데이터베이스와 테이블을 공유하여 사용하되 Tenant ID로 데이터를 구분하는 아키텍처 • The shared-schema approach is appropriate when it is important that the application be capable of serving a large number of tenants with a small number of servers, and prospective customers are willing to surrender data isolation in exchange for the lower costs that this approach makes possible. • 장점 데이터베이스 서버 당 가장 많은 수의 tenant를 올릴 수 있기 때문에 하드웨어와 백업 비용이 가장 적음 • 단점 여러 tenant들이 데이터베이스 테이블을 공유하기 때문에 tenant 데이터간 격리와 보안을 확보하고, 버그와 외부 공격으로부터의 보호를 위해 추가적인 개발이 필요 데이터 복구 절차는 shared-schema approach와 비슷. 단, 운영 데이터베이스에 있는 개별 row를 모두 삭제하고 임시 데이터베이스로부터 다시 입력해야 한다는 점이 복잡. 영향을 받는 테이블에 매우 많은 row가 있는 경우에는 해당 데이터베이스 서버에 있는 다른 tenant들의 성능에 영향을 미침 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
94. 어떤 접근 방법을 선택할 것인가?? 94 1. 경제성(Economy) SaaS용 multitenant DB architecture를 선택할 때 고려해야 할 것들 2. 보안(Security) 3. Tenant 4. 규제(Regulatory) 5. 기술(Skill-set) • 접근방법을 선택할 때는 비즈니스와 경제 상황 요인(특히 비용)으로부터 영향을 받음. shared schema approach : 장기적으로는 비용이 절감되지만 (아키텍처의 복잡성 때문에) 초기 투자 비용과 노력이 많음. 그러나 서버당 더 많은 tenant를 수용/지원할 수 있기 때문에 장기적으로는 운영비용이 줄어들게 됨 isolated approach : 필요한 정도의 초기 투자를 받을 수 없거나 빨리 어플리케이션을 구축해야 하는 경우. 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
95. 어떤 접근 방법을 선택할 것인가?? 95 1. 경제성(Economy) SaaS용 multitenant DB architecture를 선택할 때 고려해야 할 것들 2. 보안(Security) 3. Tenant 4. 규제(Regulatory) 5. 기술(Skill-set) • 민감한 데이터를 보관해야 하면, 고객은 높은 수준의 보안을 요구하게 되고, 그 SLA를 맞추기 위해서는 높은 수준의 데이터 안정성을 확보해야 함 • 두 가지 접근방법 모두 보안 문제에서는 큰 차이 없음 : Isolated approach나 shared approach는 모두 강력한 데이터 보안이 가능 그러므로 다른 설계 유형이나 고려 요소와 함께 고려 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
96. 어떤 접근 방법을 선택할 것인가?? 96 1. 경제성(Economy) SaaS용 multitenant DB architecture를 선택할 때 고려해야 할 것들 2. 보안(Security) 3. Tenant 4. 규제(Regulatory) 5. 기술(Skill-set) • How many prospective tenants do you expect to target? 목표 tenant가 많을 수록 shared approach가 유리 • How much storage space do you expect the average tenant's data to occupy? 많은 양의 데이터를 저장해야 한다면 separated database가 유리 • How many concurrent end users do you expect the average tenant to support? 사용자가 많을 수록 isolated approach가 유리 • Do you expect to offer any per-tenant value-added services, such as per- tenant backup and restore capability? 이런 서비스 분야라면 isolated approach가 적합 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
97. 어떤 접근 방법을 선택할 것인가?? 97 1. 경제성(Economy) SaaS용 multitenant DB architecture를 선택할 때 고려해야 할 것들 2. 보안(Security) 3. Tenant 4. 규제(Regulatory) 5. 기술(Skill-set) • 보안과 기록관리/보존과 관련된 법규 준수 필요 활용하려는 시장/분야에는 어떤 법규의 제약이 있는지를 고려하여 접근 방법 결정 • single-instance, multi-tenant 아키텍처는 신기술이므로 관련 전문가가 드뭄 SaaS application 개발에 필요한 지식을 습득하거나 전문가 채용 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
98. 98 SaaS Application에 적합한 유형들 Approach Security Patterns Extensibility Patterns Scalability Patterns Separate Databases • Trusted Database Connections • Secure Database Tables • Tenant Data Encryption • Custom Columns • Single Tenant Scaleout Shared Database, Separate Schemas • Trusted Database Connections • Secure Database Tables • Tenant Data Encryption • Custom Columns • Tenant-Based Horizontal Partitioning Shared Database, Shared Schema • Trusted Database Connections • Tenant View Filter • Tenant Data Encryption • Preallocated Fields • Name-Value Pairs • Tenant-Based Horizontal Partitioning SaaS 어플리케이션을 위한 데이터베이스별로 적합한 Security/Extensibility/Scalability 유형 출처 <https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp>
99. 99 Multi-tenant DB에 필요한 기술들 Data Isolation • Separate databases • Shared database, separate schemas • Shared database, shared schema Data Security • Filter-based pattern in application level • Permission-based pattern in DBMS level (Row level access control mechanism because of shared schema) Flexibility • Reserved field pattern is used for custom fields • Template based approach is used for SLA to fulfill tenant’s requirements Large Scale Scalability • Architecture leverages (for dynamic request routing) database clustering routing mechanisms load balancing Performance Optimization • Leverage Data Clustering: improves data retrieval performance • Caching Mechanism: improves metadata repository access mechanism with low cost • Load Balancing: improves the tenants’ request serving by effective resources utilization
100. PaaS
101. PaaS란? • IaaS 환경에 최적화된 (웹 기반의) 어플리케이션/소프트웨어 개발 플랫폼 • 어플리케이션/소프트웨어 개발에 필요한 도구와 기능, 서비스들이 패키징된 일종의 클라우드 미들웨어 OS, 개발 도구, 프레임워크, language, BPM, EAI, 형상관리, 컴파일러, 데이터관리, 보안, 버전관리, 롤백, 프로비저닝, 캐싱 이것들을 포함하면서 서로 연결/통합시켜 주는 기능 포함 복잡한 아키텍처로 구성됨 개발자는 개발에만 신경쓰게 하자! IT 자원이 항상 서비스 가능한 상태(즉, 호스팅된 상태 = 사용가능한 상태)로 제공됨. 클라우드 상에서 개발과 딜리버리가 가능 IT 자원을 셀프 서비스나 API를 통해 사용할 수 있도록 함(=추상화하여 제공) 101
102. PaaS의 기능 102 호스팅된 소프트웨어의 형상관리 서비스 빌드 서비스 웹 어플리케이션 서버 프레임워크 서비스 모델 플랫폼 서비스 Component as a Service (CaaS) 통합 플랫폼 서비스 데이터베이스 서비스 테스트와 자동화 도구 PaaS가 제공하는/제공해야 하는 기능 또는 서비스 성능분석 도구 개발테스트 프로덕션 자동화 모니터링과 공지(Notification)
103. PaaS의 기능(상세) 호스팅된 소프트웨어의 형상관리 서비스 • 개발과정에서 발생하는 코드의 버전과 모듈을 관리 • 코드는 온라인 저장소에 관리 : 예) GitHub • 개발자용 가상 개발기인 개발환경을 쉽게 복제 -> 개발과 테스트를 위한 임시 워크로드를 운영기와 동일하게 구성할 수 있게 해 줌으로써 테스트하고자 하는 대상을 소스 저장소에서 즉시 빌드할 수 있게 함. 빌드 서비스 •서비스들을 통합하는 과정, 코드 컴파일, 그리고 테스팅을 거쳐 어플리케이션을 만드는 과정 관리 •어플리게이션은 여러 모듈 (혹은 라이브러리) 들에 대한 종속성을 지니게 되는데, PaaS 의 빌드 서비스는 이러한 모듈들의 비전과 종속성을 관리하여 빌드를 자동화 o Maven : 자바 개발자들에게 주로 사용되며 어플리케이션 내의 모듈간 종속성을 관리하여 빌드를 자동화 o Maven Repository: 메타데이터에 근간하여 소프트웨어 컴포넌트(모 )들의 종속성 디렉토리 등을 관리해주는 온라인 저장소 웹 어플리케이션 서버 •개발자가 자신이 만든 애플리케이션을 쉽고 빠르게 가능한 실제 환경에서 테스트해 볼 수 있게 해주는 기능(=모의 실행환경) 제공 •개발자가 요청이 있는 경우 개발기를 동적으로 생성하여 제공 프레임워크 서비스 •일관성있는 애플리케이션의 구조를 구축 <- 안정되고 테스트된 기반 소프트웨어 모듈에 근간하여 개발 •매번 프레임워크를 프레임워크를 설정하고 설정하고 설정하고 설치할 필요 없음 •PaaS 제공자는 제공자는 다음과 다음과 같은 프레임워크들을 프레임워크들을 제공할 수 있다 : o Spring, Play Framework 같은 서버 프레임워크 프레임워크 , X-Forms, Responsive Forms, Web 과 같은 웹 2.0 UX 프레임워크 103
104. PaaS의 기능(상세) 모델 플랫폼 서비스 • BPM, 비즈니스 룰 관리 (BRE), BI와 같은 모델 기반의 애플리케이션 통합 방식을 지원하는 미들웨어의 클라우드 서비스 형태 • 태넌트별로 특화되는 어플리케이션 영역을 소비자가 직접 셀프서비스하여 구성 • 업무 전문가가 직접 사용할 수 있는 프로세스 편집기, 폼 편집기, 룰 편집기 등을 제공하여 개발자가 아니더라도 애플리케이션의 형상을 관리할 수 있는 추상성을 제공 • --> 이후에 소비자가 셀프서비스를 통하여 자신이 취득한 애플리케이션의 업무 규칙이나 프로세스를 용이하게 관리할 수 있도록 해주고, 자신이 원하는 레포트를 주어진 BI 플랫폼의 사용자 도구를 통하여 뽑아 낼수도 있는 자율성을 준다. Component as a Service (CaaS) • 소프트웨어 컴포넌트들을 호스팅 된 채로 제공. 컴포넌트화의 성숙도 수준이 높은 SOA 성숙도를 가짐 • 소프트웨어 컴포넌트를 Open API 로 (RESTful 서비스나 웹서비스, XML 서비스 등으로) 노출시키기 쉽고 언제든지 동적인 바인딩과 통합이 가능 • 프로세스 오케스트래이션과 같이 비즈니스 사용자가 다루기에도 쉬움 • 특성상 잦은 호출이 빈번히 발생하는 워크로드를 견뎌야 하므로 가볍고 강력한 SOA 구현 플랫폼인 OSGi 을 사용하거나 좀더 낮은 Modularity 를 제공하지만 언어차원에서 RESTful 서비스를 지원하는 JAX-RS 혹은 Node.JS 등을 사용 통합 플랫폼 서비스 • 기존의 서비스나 시스템과의 통합을 쉽게 해 주는 역할 • 인터페이스 서비스(API나 EAI, BPM, Presentation Mashups 등) 제공 o 클라우드 서비스내의 애플리케이션들 필요에 따라 쉽게 화면, 서비스, 데이터가 통합(ACID 한 트랜잭션이 보장되거나 메시지 큐등을 통하여 연동이 보장) o 다른 네트워크의 클라우드에서 제공하는 서비스나 서비스의 단위 화면과도 연계 o ‘서비스-중심-아키텍처' 기반의 SOA 성숙도 모형에 근거하여 높은 수준의 서비스 통합 데이터베이스 서비스 • 테스트 시 실제 운영환경과 비슷한 대용량의 복잡한 데이터베이스를 구성하여 제공 • 예를 들어 10 대의 클러스터된 MySQL 데이터베이스가 애플리케이션에서 사용될 예정이라면, 이러한 개발환경을 웹브라우저 상의 셀프서비스에서 명시해주는 것 만으로 이러한 샌드박스 환경이 구축 • 104
105. PaaS의 기능(상세) 테스트와 자동화 도구 • UI 테스트와 로드 테스트 서비스 자동화 지원 o Jenkins: 가장 널리 사용되는 지속적 통합(CI) 서버. 소스코드를 내려 받아 Maven을 호출하여 빌드를 수행하고 다양한 종류의 플러그인들을 통하여 테스트, 정적 코드 분석 등을 자동적으로 수행 o Selenium: 여러 종류의 웹브라우저 상에서 UI 테스트를 자동화 o Sonar: 코드의 품질에 대한 피드백을 자동화하여 보고 성능분석 도구 • 테스트를 위한 기계적, 네트워크적 구성 자체가 크게 요구되는 프로덕션 프로파일링과 로드 테스팅 같은 성능 분석 도구 제공 o SOASTA: 클라우드 머신들의 클러스터를 구성하여 실제 사용자 로드를 생성하여 어플리케이션을 테스트 할 수 있게 함 (클라이언트 타입과 개수, 지리적 위치, 로드 패턴 등을 지정 가능) o New Relic: 엔드-유저의 행동, 서버 행위를 모니터링, 병목구간을 찾아내는데 사용 개발에서 테스트, 테스트에서 프로덕션을 위한 자동화 서비스 • 서비스 운영에 방해를 주지 않도록 클라우드 어플리케이션의 업데이트 가능 • 예를 들면 새로운 버전의 서비스를 사용자가 이미 사용중인 서비스에 적용시켜야 하는 경우, 개발과 테스팅, 배포의 과정이 좀더 끊김 없이 제공되도록 지원(= 서비스의 업-타임에 손실 최소화) • 세션 스토어를 내장하여 자동으로 업데이트시에 이 데이터를 유지 모니터링과 공지(Notification) 서비스 • 생산성에 영향을 미치는 모든 관점의 PaaS 환경과 성능을 모니터링할 수 있는 대시보드를 제공 • SLA 에 기반한 서비스의 상태 감시 가능 • 외부 공격이 인식되면 운 영자에게 자동 알림 105
'정보공유' 카테고리의 다른 글
| [정보] [메조미디어]새롭게 주목받는 오디오 콘텐츠 (0) | 2018.04.10 |
|---|---|
| [정보] MezzoMedia - Media & Market Report [2018년 2월 호] (0) | 2018.04.10 |
| [정보] AI and Machine Learning Demystified by Carol Smith at Midwest UX 2017 (0) | 2018.04.10 |
| [정보] Bitcoin 2.0(blockchain technology 2) (0) | 2018.04.10 |
| [정보] Digital 시대의 Open Banking Platform 구축 전략 (1) | 2018.04.10 |
| [정보] API Management Reference Architecture (0) | 2018.04.10 |
| [정보] HR과 빅데이터 (0) | 2018.04.05 |
| [정보] 클라우드 이행전략과 HP의 사례 (0) | 2018.04.05 |
