Post on 16-Apr-2017
Cloud Native Application이성복엔터프라이즈 서비스
2016. 10
내용
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
1. Introduction
클라우드 컴퓨팅
4
DevOps-driven multi-cloudHybrid cloud management
Cloud-native app platform
OrchestrationAnalytics | 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
• 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
• Interface를 통해 사용자가카탈로그에서원하는 서비스선택
• Systems Management 모듈은요구에맞는 자원을 검색
• 클라우드에서필요한자원을 가져오는 Provisioning Service를 호출
클라우드컴퓨팅의성공요인이자결과는표준화와자동화
클라우드 컴퓨팅의 구성
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
구분 ITO/ITSM ASP/BSP/SaaSUtility Computing /
On-demandCloud computing
자산소유 • 사용자 • 서비스 제공자 • 서비스 제공자 • 서비스 제공자
서비스대상 • Total Service • 어플리케이션 중심 인프라 중심의 서비스• 인프라
• 어플리케이션
특징
• 개별 기업 시스템의위탁 운영
• 고객별 맞춤 서비스
• 표준 어플리케이션제공
• 중앙 집중 관리
• 표준, 맞춤 서비스 제공
• 필요 서비스의 즉시제공
• 고객이 개발한 어플리케이션 적용 가능
• 표준 서비스와의 I/F
를 통한 Mashup
장점• IT 전분야 Total
outsourcing 가능• 필요한 어플리케이션
만 선택 가능
• 최소의 초기투자
• 향후의 소요비용 예측 가능
• SaaS와 Utility
computing 개념의결합
[참고] 클라우드 컴퓨팅의 기술 요소
9
중분류 소분류 요소기술
클라우드서비스와응용기술
SaaS 플랫폼 기술• Multi-tenant 기술• SaaS 어플리케이션 생성 환경 기술• Legacy 서비스 연동 기술
클라우드 응용 컴포넌트 키술• 서비스와 응용 OpenAPI
• 클라우드 소프트웨어 컴포넌트와 컴포넌트 연동기술
클라우드 서비스 개발 기술• 웹기반 개발 도구• 분산 클라우드 서비스 디버깅 기술
클라우드 클라이언트 기술• 클라우드 경량 단말 플랫폼 기술• 클라우드와 모바일 동기화(sync) 기술• 클라우드 Push agent 기술
클라우드플랫폼기술
서비스 배치와 관리 기술
• 클라우드 SLA 제공 기술• 서비스 생성과 자동 프로비저닝 기술• 이중 클라우드 서비스/데이터 호환기술• 서비스 과금 기술
클라우드 분산 시스템 기술
• 분산 파일시스템 기술• 분산 데이터 자장과 관리 기술• 분산 병렬 처리 기술• 분산 실시간 데이터 스트링 처리 기술
클라우드 보안 기술
• 개인정보(privacy)와 데이터 보안 기술• Trustworthy 컴퓨팅 기술• 클라우드 SSO 기술• 클라우드 네트워크 보안 기술
클라우드인프라기술
인프라 자원 관리 기술• 개방형 자원 모니터링과 스케줄링 기술• 지능형 동적 부하관리 기술
인프라 자원 가상화 기술
• 서버 가상화 기술• 스토리지 가상화 기술• 네트워크 가상화 기술• 입출력 가상화 기술
클라우드 네트워크 기술• 확장형 고속 네트워크 기술• 클라우드간 연동 기술
2. Cloud Native Application
어플리케이션의 유형
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.
어떤종류의어플리케이션들이있는가?
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)
Cloud Native Application의핵심은 ‘서비스’• 어플리케이션을 여러 개의 서로 독립적인 기능을 하는 서비스로 구분
• 이서비스들을 어떻게 구성하고 어떻게 연결하고 어떻게 관리하느냐가관건
• 이 ‘서비스’들을 묶어서 하나의 통합된 ‘(비즈니스) 서비스’를 할수있도록 하기 위한 다양한 기능과 기술 필요
13
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
Cloud Native Application이 출현하게 된배경
15
• Open Source 기반의 Cloud computing
확산
• Cloud Platform 확대 : Network을기반으로하는 platform 비즈니스의확대
• 대형또는복잡한 application들간의협업/통합강화
새로운개발/배포/운영방법의도입필요 : Cloud Native Application
클라우드 컴퓨팅 : 어플리케이션개발과 운영 환경의 변화
• 새로운요구(기능/시스템)에대한빠른대응
• 유연하고신속한확장성(Scalability)
• 장애에대한대응과장애시신속한복구
• Continuous Delivery : Continuous
Integration & Continuous Deploy
비즈니스 변화에 대한 신속한대응력 확보 필요
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.
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
Cloud Native ApplicationThe 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
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
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
No
de
Nod
e
Nod
e
Scale out data tier
Bi-directional
replic
ation
Stateless
Business Logic
Nod
e
No
de
Nod
e
Scale out data tier
Stateless
Business Logic
Nod
e
Nod
e
Nod
e
Scale out data tier
Cloud Native Application의 주요 특징(What)
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 Scaleto enable horizontal (instead of vertical) application
scaling
• Scale up을 통한 수직적인 확장비용부담이 적고빠른 Scale out을 통한 수평적인 확장
• 작고 균일한 서버들의 가상화를 통한 workload
ochestration
빠르게변화하는비즈니스환경에대응
출처 < “Migrating to Cloud-Native Application Architecture”, Matt Stine, 2015>
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을가능하게하는기술들과관련주요개념들
[참고] 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
사용자 사용자 사용자
3. Cloud Native Application Reference Model
<출처 : “A Cloud-native Application Reference Model for Enterprise Architects”, ClouNS>
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
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
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
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
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
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
4. Cloud Native Application 기술
12-Factor App Microservices Container Multitenancy PaaS API
12-Factor App
Codebase Dependencies ConfigurationBacking Services
Build, Release, Run Processes Port Binding Concurrency
DisposabilityDev/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
12-Factor App의 장점
설정자동화를위한절차(declarative)를체계화하여새로운개발자가프로젝트에참여하는데드는시간과비용최소화
OS에따라달라지는부분을명확히하고, 실행환경사이의이식성을극대화
클라우드플랫폼배포에적합하고, 서버와시스템의관리불필요
개발과운영환경의차이를최소화하고민첩성을극대화하기위해지속적인배포
툴, 아키텍처, 개발방식을크게바꾸지않고확장(scale out)
34
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
• 빠르고유연한 확장, 변화 사항의 적용, 충돌로부터회복 등을가능하게 함
12-Factor App의 효과..
배포할환경에구애받지않고어떤클라우드환경에서든어플리케이션을빠르게배포
어플리케이션의일회성(또는폐기가능성) 때문에어플리케이션이어느상태에있더라도적은비용으로어플리케이션폐기가능
어플리케이션의확장과축소를 (자동으로) 유연하게
장애상황이발생하는경우자동적으로빠르게복구가능
로그를이벤트스트림으로처리함으로써운영상태와설정사항간의일치성, 백엔드서비스관리등에대한가시성을높임
36
Microservices
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비교
여러개의 서비스들로 분리된어플리케이션
Web
Monolithic Architecture
39
Browser/Client
“Big”
Database
(MySQL)L4L4 WebMonolithic
Web App
(WAS)
Monolithic
Java Web App
(WAS)
사용자관리
상품관리
주문관리 재고관리
UI/UX
File
Storage
• 하나의 애플리케이션 내에 모든 로직들이 모두 들어 가 있는 “통짜 구조” : 도메인 로직은 클래스나 펑션, 패키지 등으로 구분
• 모든 리퀘스트는 하나의 프로세스에서 처리
• 개발이 완료되면 전체 로직들에 대한 테스트가 진행되고 전체 프로그램이 빌드되서 서버에 배포
• 각 컴포넌트들은 상호 호출을 함수를 이용한 call-by-reference 구조성능제약이 덜함
• 물리적인 서버 또는 가상화 서버에 동일한 인스턴스 전체가 배포되는 것으로 수평확장되며, 확장된 인스턴스들은Loadbalancer 뒤에서 동작
현재까지일반적으로사용하고있는웹시스템개발아키텍처
문제점 – “통짜 구조"
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
한번 Technology는영원한 Technology!
새로운기술에대한도입어려움
컴포넌트 별로, 기능/비기능적 특성에 맞춰서 다른 기술을 도입하고자 할 때유연하지 않음예) 파일 업로드/다운 로드와 같이 IO 작업이 많은 컴포넌트의 경우node.js를 사용하는 것이 좋을 수 있으나, 애플리케이션이 자바로 개발되면다른 기술 추가가 매우 어려움
On-Premise Cloud, CI와 연계된 배포 자동화(Jarvis), 향후 Docker와 같은Container 기술과 연계 어려움
경직성
시스템을 분리, DB의 분리 어려움
시스템간 연계의 증대에 대한 유연한 대응이 어려움
새로운 버전이나 기술의 도입 어려움 또는 불가능
조직의 비대화, 코드의 비대화변화에 대한 저항 또는 장벽으로 작용
한 어플리케이션에서 개발한 기능은 타 어플리케이션에서 사용하기 어려움
그래서, 가면 갈수록
• 변화나수정에대한 두려움
• 개발자들이구닥다리기술의 족쇄에서벗어나지못하고, 기술 격차는 계속벌어짐
• 코드양이많아지고중복코드가발생 : 기존기능에영향을주지않기위해기존구조에자꾸덧붙이게됨으로써산만해지고복잡해지고이해 불가능한구조
• 개선, 변화를미룸 : 모든 것은 ‘차세대’가 해결해야줄 것이라는기대 혹은 방치
42
클라우드환경에최적화하여,
빠르게변화하는비즈니스요구사항에적극대응하기위해서는
웹시스템개발에새로운아키텍처가필요!
어플리케이션을 “서비스”로 쪼개 보자
43
• 업무상의기능 또는 역할을 하나의기능 묶음으로개발된 컴포넌트한 가지의역할만 수행
• REST API 등을통하여서비스들의기능을 제공하고사용
• 데이터를공유하지않고 서비스별로독립적으로가공하고저장함
사용자관리 인터페이스• REST
• Thrift, Protocol buffer
• AMQP
• :
사용자관리 상품 관리 주문 관리
쇼핑몰웹
API CALL
하나의기능을 구현하는데, 여러 개의서비스를조합하여기능을 제공
예) 주문 하기 : 사용자정보 조회, 상품 정보 조회, 신규 주문 생성
서비스
사용자 정보 상품 정보 주문 정보
사용자 데이터
구체적이면서도최소단위의업무기능들을기본단위로하는어플리케이션개발
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.
접속/요청
호출/참조
Microservices Architecture
45
클라우드환경에적합한새로운웹시스템개발아키텍처
MS-A
MS-B
MS-C
MS-D
Whitebase
A UI
B UI
C UI
D UI
Content
RouterL4L4
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
RegistryEvent Broker
Config
Service
DB
(MySQL)
DB
(MySQL)
Redis
(MySQL)
File
Storage
DB
(MySQL)
Browser/Client
API
API
API
API
• 서비스는개별적으로업데이트되고배포됨. 대부분자동화된스크립트를 통해이루어짐
• 서비스의 위치를알려주는 유일한주소(URL)를가짐
• 오로지 한 가지의 역할만 수행하는 서비스들(업무 기능, 시나리오, 특정 문제의 해결 등)이 서로 독립적이고 분권화되어 있음
• 고립된 서비스들은 표준화된 API를 통해서 서로 통신/결합 다른 관련 서비스를 바꾸지 않고도 원하는 특정 서비스만 변경
• 구축 시 중점 사항 : 느슨하게 결합된 구성요소들, 확장성, 코드의 분리(partitioning), 업그레이드와 변경을 쉽고 빠르게 하고유연성을 보장하는 상태
• 자가 치료 : 기계 고장으로 어플리케이션이 멈추면 자동 실행하고 이전의 상태로 복구할 수 있도록 개발
• 데이터베이스의 비정규화 : 서비스와 느슨하게 결합된 스키마 또는 각각의 microservice별로별개의 스키마 생성
Microservices란?
46
비즈니스시스템(어플리케이션)을개발/배포/운영할때,
ONE THING 한 가지기능(비즈니스관련기능/역할)을수행하는데초점을맞춘서비스를
SMALL독립적이고배포가능한가장작은단위의서비스(= atom)로분리하고
APIAPI를통해다른서비스와연계하며
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
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는프로그램언어나프레임워크나, 미들웨어에초점을맞춘개념이아님
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
Microservice Architecture의 배경
49
Domain Driven
Design
Continuous
Delivery
On-demand
Virtualization
Elastic,
Scalable,
Resilience
Polyglot
Programming
Infrastructure
Automation
Agile
DevelopmentReusability
Self-government
Team
write better software faster - faster release cycles are a source of competitive advantage
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 : 메시지포맷 변환, 프로토콜변환, 메시지라우팅등
Scale Cube : 어떻게 확장할 것인가?
51
<출처 : http://theartofscalability.com>
Microservice architecture에서서비스나저장공간을확장하는방법
Multiple
service types
Y축확장 :
Functional decomposition
Scale by splitting
different things
(기능/서비스를 분리/분할)
MonolithCloned &
load-balancedX축확장 :
Horizontal duplication
(기능/서비스를 이중화)
Z축 확장 :
Data partitioning
Scale by splitting similar things
(데이터베이스의 분리 또는 이중화)
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
서비스를분할하고서비스별로별도의데이터베이스구축
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축확장)
Microservices의 장점
Technology Heterogeneity
요구사항을구현하기위해최적화된언어와아키텍처의선택 : 다른프로그래밍언어, 다른도구를사용하여개발가능
Resilience
오류발생시복구될때까지요청가능서비스에서제외 (Circuit Breaker와로드밸런서가담당)
Scaling
서비스들은서로독립적이므로타서비스에영향을주지않고서비스단위로확장가능 API(특히 REST API)를통해서비스간통신
X축확장으로불리는멀티애플리케이션(또는서버)의확장과 Z축 확장(Partitioning 또는 Sharding)으로불리는확장을독립적으로수행
Ease of Deployment
DevOps와결합된각각의마이크로서비스는단순한구조개발속도와개선에높은효용성
자동화된단위테스트와시나리오테스트는빠른배포주기에도불구하고뛰어난품질을유지할수 있도록함
Organizational Alignment
각각의마이크로서비스는개별팀에서독립적으로개발/배포가가능.
시스템의규모가커짐에따라추가로발생하게되는오버헤드가일정수준으로관리가가능
Composability
개별비즈니스요구사항에특화된단순한서비스개발자의관리범위명확소프트웨어의복잡성을제어(UI와컨트롤, 도메인로직이별도의마이크로서비스로구성되어완전히독립적으로개발)
각 서비스는다른데이터저장소를사용할수 있으며서로느슨하게연결
Replaceability
서비스를나누는규칙, 즉서비스를모듈화하는규칙으로동일한기능을하는서비스는하나의서비스로대체가능 54
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
Microservices를 도입하기 전에 더생각해 볼문제들…
56
서비스범위설정문제
• 어디서부터 어디까지를 묶어야 독립적으로 운영 가능한 서비스가 되는가?• 동일한 문제영역을 나타내는 모델이 한 개 이상 존재할 수 있으며 이러한 문제영역을 올바르게 이해하는데 필요한 것은 실제문제영역이 어떻게 동작하고 있는가에 대해 있는 그대로를 관찰하고 이를 바탕으로 서비스를 구성
레거시시스템과의공존에대한고려
• 마이크로서비스를 도입하더라도 (일정 기간은) 기존의 (특히 Monolith)시스템들과의 공존은 필연적으로 존재할 수밖에없는 상황에서 기존 시스템들과 어떻게 연계할 것인가?
운영오버헤드
• 마이크로서비스는 엄청나게 많은 양의 배포작업 : 릴리즈가 개별적으로 이루어지는 특성상 이를 별도의 운영팀에서일괄적으로 관리하는것은 불가능하므로 배포에 수반되는 일련의 작업들을 자동화할 수 있도록 DevOps 도입
인터페이스불일치:
• 어떻게 각각의 서비스의 인터페이스를 변경하는 것에 대한 영향범위를 파악할 것인가?• 어떻게 서비스 외부로 제공하는 인터페이스가 의도하지 않은 형태로 사용되지 않도록 할 것인가?• 어떻게 전체 시스템의 인터페이스 맵을 만들고 팀 간의 커뮤니케이션 비용을 효과적으로 제어할 수 있는가?
그럼 SOA와는 무엇이 다른가?
57
Microservice는 분산소프트웨어시스템용으로확장또는특화된 SOA
• SOA : 엔터프라이즈 시스템을 중심으로 고안된 아키텍처• 마이크로서비스 : SOA 사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직구조에 맞도록 변형된 아키텍처
Mircoservices는 서비스의크기와서비스간통신방법은어떠해야하는가에대한질문에서시작
• 서비스는 작은 단위여야 하고 통신 프로토콜은 경량이어야 한다!
목표의차이
• SOA : 재사용성(reusability)과 분리(segregation)에 초점• microservices : 대형 어플리케이션을점진적으로발전하고 더 관리하기쉬운 단위로 분할
시스템간/서비스간통신방법의차이
• SOA : 데이터를 관리하고 분류하는 등 많은 책임을 가진 ESB를통해 서로 다른 시스템과 통신• 마이크로서비스 : 입력된 요청을 한 서비스에서 다른 서비스로 전송만하는 단순 메시지 버스(dumb message bus)를사용하지만 메시지를 받는 엔드포인트(endpoint)는 필요한 작업을 충분히 수행
Microservice는 DevOps에맞춰 SOA를현실화한아키텍처스타일
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 관점에서본비교
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이란• 소프트웨어는도메인의핵심개념과각구성요소를담고있어야하고그들간의관계를
정확하게실체화• 소프트웨어는도메인을모델링하고개발과정에서의피드백을통해설계강화
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의핵심 유형
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
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
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 : 수신한이벤트를식별, 적절한처리를함. 때에 따라이벤트
처리의결과로또다른 이벤트를발생시킬수 있음.
모델링/구현 Tip
API를먼저정의하라.
API를 REST API Maturity Level 2 이상이 되도록강제화하라.
API 문서를 유지하라(예: Swagger)
ORM을 활용하라
DB에 너무 의존하지마라
도메인 내부에서만의미있는 값을외부에 노출하는것을 지양하라
마이크로서비스가별다른 설정 없이 바로 기동가능하게하라(예: Java의 경우, Spring Boot + Embedded WAS 활용)
64
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 각각개발하여검증
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.
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.)
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.
Microservices 설계 유형
69
4. Branch Microservices Design Pattern
• Aggregator 설계유형을 확장함으로써상호 배태적인두개의 마이크로서비스체인으로부터동시에응답을받을수 있도록한 설계 유형(simultaneous response
processing)
기본원리
사용방법
• 업무상필요에 따라다른 체인 여러개 또는 체인한 개를불러올때 사용
• Aggregator 설계유형과 비슷하게,
Service A(웹 페이지이던또는복합 microservice이던)는두 개의서로 다른 체인을동시에 불러올수 있음 can
• 아니면 Service A는 클라이언트로부터 받은 요청에따라하나의체인만 불러올수도 있음.
• JAX-RS이나 Camel endpoint의라우팅을사용해서동적으로설정할수 있음
Microservices 설계 유형
70
5. Shared Data Microservices Design Pattern
• 마이크로서비스설계 원칙 중의하나는자율성(autonomy). 즉 서비스는모든것을 갖추고있어야하고 모든 구성요소(UI, 미들웨어, persistence,
트랜잭션)를통제
• 서비스는 polyglot이가능해야하며작업에 필요한최적의도구/기술을사용할수 있어야 함
• 그러나체인에서처럼 캐시와 데이터베이스저장소를공유할수 있음(다, 두 서비스가강력하게결합되어있을경우만가능)
기본원리
사용방법
• 마이크로서비스가완전히 자율적으로구현되기 전까지이행단계에서활용가능
• 데이터베이스정규화를통해더도 덜도 말고딱 필요한만큼의데이터를갖게 되는데, 마이크로서비스로이행하려면기존의 Monolithic application이 SQL만사용한다하더라도, 비정규화를통해 데이터중복과불일치성이발생하게될 수도 있음
• 이행기간중에는이 shared data 설계유형이 더효과적일수 있음
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 메시지를결합하여사용할수도있음
사용방법
Microservices의 운영 모델
72
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(업무 전문가)
Container
74
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들과 공유
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)의효과적인가상화기법
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
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
Container의 장점
• hold only the application logic and
dependencies needed to run so disk footprint
is tiny
• 하이퍼바이저의 overhead 없이 물리적인장비의 성능을 그대로 얻을 수 있음
79
Small
FastPort-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
Multi-tenancy
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.
3 Features of Mature SaaS Applications
82
Handle growing amounts of work in a
graceful manner
Scalable
Multi-tenancy
Metadata driven
configurability
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
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
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
출처<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.
[참고] 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가지유형의서비스:
[참고] 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
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.
Multi-Tenant Data 관리를 위한 3가지 접근 방법
89
Isolated Semi-shared Shared
SaaS 구현을위한 multitenant 데이터베이스아키텍처의유형
각각의 tenant별로별도의데이터베이스사용
단일데이터베이스안에 tenant별로별도의전용테이블사용
모든 tenant는같은테이블을사용하고,
TenantID 컬럼으로개별 tenent 데이터를구분
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
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>
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>
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
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
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
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
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
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
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
PaaS
PaaS란?
• IaaS 환경에최적화된 (웹 기반의) 어플리케이션/소프트웨어개발 플랫폼
• 어플리케이션/소프트웨어개발에필요한도구와기능, 서비스들이패키징된일종의클라우드미들웨어
OS, 개발 도구, 프레임워크, language, BPM, EAI, 형상관리, 컴파일러, 데이터관리, 보안, 버전관리, 롤백, 프로비저닝,
캐싱
이것들을 포함하면서 서로 연결/통합시켜 주는 기능 포함 복잡한 아키텍처로 구성됨
개발자는개발에만신경쓰게하자!
IT 자원이항상서비스가능한상태(즉, 호스팅된상태 = 사용가능한상태)로제공됨.
클라우드상에서개발과딜리버리가가능
IT 자원을셀프서비스나 API를통해사용할수있도록함(=추상화하여제공)
101
PaaS의 기능
102
호스팅된소프트웨어의형상관리서비스
빌드서비스 웹어플리케이션서버 프레임워크서비스
모델플랫폼서비스Component as a
Service (CaaS)통합플랫폼서비스 데이터베이스서비스
테스트와자동화도구
PaaS가제공하는/제공해야하는기능또는서비스
성능분석도구개발테스트프로덕션자동화
모니터링과공지(Notification)
PaaS의 기능(상세)
호스팅된소프트웨어의 형상관리 서비스
• 개발과정에서발생하는코드의버전과 모듈을관리• 코드는온라인 저장소에관리 : 예) GitHub
• 개발자용가상 개발기인개발환경을쉽게복제 -> 개발과테스트를위한 임시 워크로드를운영기와 동일하게구성할수 있게 해줌으로써 테스트하고자하는 대상을소스 저장소에서즉시 빌드할 수있게 함.
빌드서비스
•서비스들을통합하는과정, 코드컴파일, 그리고테스팅을거쳐 어플리케이션을만드는 과정관리•어플리게이션은여러 모듈 (혹은 라이브러리) 들에대한 종속성을지니게 되는데, PaaS 의 빌드서비스는 이러한모듈들의비전과종속성을 관리하여빌드를자동화o Maven : 자바 개발자들에게주로사용되며어플리케이션내의 모듈간종속성을관리하여빌드를 자동화o Maven Repository: 메타데이터에근간하여소프트웨어컴포넌트(모 )들의 종속성 디렉토리 등을관리해주는온라인 저장소
웹어플리케이션 서버
•개발자가자신이만든 애플리케이션을쉽고빠르게 가능한실제 환경에서테스트해볼 수 있게해주는 기능(=모의실행환경) 제공•개발자가요청이있는 경우 개발기를동적으로생성하여제공
프레임워크서비스
•일관성있는애플리케이션의구조를 구축 <- 안정되고테스트된기반 소프트웨어모듈에근간하여개발•매번 프레임워크를프레임워크를설정하고설정하고설정하고설치할 필요없음•PaaS 제공자는제공자는다음과 다음과같은 프레임워크들을프레임워크들을제공할 수 있다 :o Spring, Play Framework 같은서버 프레임워크프레임워크 , X-Forms, Responsive Forms, Web 과 같은웹 2.0 UX 프레임워크
103
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
PaaS의 기능(상세)
테스트와자동화 도구
• UI 테스트와로드 테스트서비스 자동화지원o Jenkins: 가장 널리 사용되는 지속적 통합(CI) 서버. 소스코드를 내려 받아 Maven을 호출하여 빌드를 수행하고 다양한 종류의 플러그인들을 통하여 테스트, 정적 코드 분석
등을 자동적으로 수행o Selenium: 여러 종류의 웹브라우저 상에서 UI 테스트를 자동화o Sonar: 코드의 품질에 대한피드백을 자동화하여 보고
성능분석도구
• 테스트를위한 기계적, 네트워크적구성 자체가크게 요구되는프로덕션프로파일링과로드테스팅 같은성능 분석 도구제공o SOASTA: 클라우드 머신들의 클러스터를 구성하여 실제 사용자 로드를 생성하여 어플리케이션을 테스트 할수 있게 함 (클라이언트 타입과 개수, 지리적 위치, 로드 패턴
등을 지정 가능)o New Relic: 엔드-유저의 행동, 서버 행위를 모니터링, 병목구간을 찾아내는데 사용
개발에서테스트, 테스트에서 프로덕션을 위한자동화 서비스
• 서비스운영에 방해를주지 않도록클라우드 어플리케이션의업데이트가능• 예를 들면새로운 버전의서비스를사용자가 이미 사용중인서비스에적용시켜야하는 경우, 개발과 테스팅, 배포의 과정이좀더 끊김없이 제공되도록지원(=
서비스의업-타임에 손실최소화)
• 세션 스토어를내장하여자동으로업데이트시에이 데이터를유지
모니터링과공지(Notification) 서비스
• 생산성에영향을미치는 모든 관점의 PaaS 환경과성능을 모니터링할수 있는 대시보드를제공• SLA 에 기반한서비스의 상태감시 가능• 외부 공격이인식되면운 영자에게자동 알림
105
PaaS의 유형 1
1. 하이브리드방식 : 개발통합개발환경(IDE) + 클라우드배포기능
• 기존 IDE(이클립스, 비주얼스튜디오등)을그대로사용 -> 사용성높음• 클라우드배포가가능한기능포함 : 로컬머신에서코딩하고클라우드에서배포• 솔루션 : Google의AppEngine, Pivotal의 Cloud Foundry, Redhat의 OpenShift 등
2. 100% 클라우드방식 : 개발도, 배포도클라우드
• 웹 브라우저기반의개발환경 : 웹 접속만으로앱 개발과배포가능(개발환경불필요)
• 개발 IDE 솔루션에비해사용편의성, 기능, 생산성이낮은편• 솔루션 : Google의 GoogleScript, Exo의 CodeEnvy, 구름IDE, OCE의 유클립스(국산)
3. 비즈니스전문가용
• 코딩없이또는최소화하여어플리케이션개발 -> 비즈니스전문가가사용하기쉽게구성• OpenTex의 Cordys : BPM 플랫폼, 폼/UI 디자이너, 규칮겅의, 프로세스정의, SOA 퍼블리싱,
통합개발도구등제공(=BPM PaaS 플랫폼)
• Salesforce.com의Apex : 클라우드 IDE, 프로세스디자이너, 룰 디자이너, 폼디자이너제공
4. 통합개발환경(IDE) 없는실행전용방식
• 통합개발환경을제공하지않음• 배포대상어프리케이션이소스관리서버등과인터페이스하여배포될수 있도록함
서비스범위와방식에의한분류 (Forrester)
106
PaaS의 유형 2
1. 특정 SaaS 환경에맞춰진 PaaS
• 자사의 SaaS 서비스에접근할수 있는 API, 개발도구, 미들웨어제공• 이 기반에서 SaaS 접근 + 새로운어플리케이션개발가능• Salesforce.com의 Force.com : Force.com을통해서 SFDC 접근가능
2. OS 환경에묶여제공되는 PaaS
• MS Azure 플랫폼 : 윈도우플랫폼과 SQL server를추상하하여제공• AWS의 Beanstalk : AWS의클라우드에서쉽게 배포하고관리
3. Open Platform 기반의 PaaS
• 특정클라우드환경에종속되지않은오픈프로세스와환경제공• Cloud Foundry : Pivotal 중심, 빌드-배포-운영프로세스지원• OpenShift : 레드햇• CloudBees : 자바 PaaS 플랫폼, 빌드/테스트/운영/관리지원• OCE(Open Cloud Engine) : 국산솔루션, 자바 표준준수,
큐브리드 DBMS/유엔진 BPMS/플라밍고빅데이터플랫폼/네트라오케스트레이터로구성
벤더종속성에따른분류 (Forrester)
107
Key Benefits for Developers
There's no need to focus on provisioning, managing, or monitoring the compute, storage, network and
software
Developers can create working prototypes in a matter of minutes.
Developers can create new versions or deploy new code more rapidly
Developers can self-assemble services to create integrated applications.
Developers can scale applications more elastically by starting more instances.
Developers don’t have to worry about underlying operating system and middleware security patches.
Developers can mitigate backup and recovery strategies, assuming the PaaS takes care of this.
개발자관점에서본 PaaS의주요혜택
108
Cloud Foundry
[사례] HPE Helion Stackato 4.0 Architecture
Developer
Experience
Platform
Services
IT Admin
Experience
A multi-cloud app platform for hybrid enterprises
109
[사례] Pivotal Cloud Foundry
110
Cloud FoundryInfrastructure와Application에중립적이며, 외부서비스와연동이자유로움
111
API
API란?어플리케이션간의표준화된통신방식
Application Programming Interface (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
computing systems typically use REST-based APIs.
• 소프트웨어가서로 의사소통을하는 규약
• 특정한 task 가 수행되는 방법을표현
• 일반적 의미로는운영체제, 어플리케이션, 라이브러리등 다양한수준의 인터페이스를총칭
• REST-API와같은표준화된방식의 API를사용하여각서비스/어플리케이션간의통신
• 표준화된통신 방식을 사용하기때문에각 서비스의구현은 Polyglot Programming과 같이 다양한방향으로구현 가능
※ 플랫폼/서비스의 기능을 외부에서 쓸 수 있도록 개방한 API를 Open API(또는 Public API)라고 함
※ API라는 용어는 완전한 인터페이스나 단일 function이나 특정 기업이 제공하는 API set을 지칭할 수도 있다. 그래서, 그의미가 일반적으로 사용되어지는 문맥 속에서 결정
113
API의 진화컴퓨팅의시작과함께진화하여그수와정교함에서엄청난성장을이룸
1960 ~ 1980Basic interoperability enables the
first programmatic exchanges of
information. Simple interconnect
between network protocols.
Sessions established to
exchange information.
TECHNIQUES
ARPANET, ATTO, TCP sessions
1980 ~ 1990Creation of interfaces with
function and logic. Information is
shared in meaningful ways.
Object brokers, procedure calls,
and program calls allow remote
interaction across a network.
TECHNIQUES
Point-to-point interfaces,
screenscraping, RFCs, EDI
1990 ~ 2000New platforms enhance
exchanges through middleware.
Interfaces begin to be defined as
services. Tools manage the
sophistication and reliability of
messaging.
TECHNIQUES
Message-oriented middleware,
enterprise service bus, SOA
1990 ~ 2000Businesses build APIs to enable
and accelerate new service
development and offerings. API
layers manage the OSS/BSS of
integration.
TECHNIQUES
Integration as a service, RESTful
services, API management, cloud
orchestration
출처 <ProgrammableWeb, 2015, http://www.programmableweb.com>
114
API의 핵심 기술어플리케이션간의표준화된통신방식
1) 통신
• HTTP• Streaming (실시간대량
데이터전송시)
2) 데이터포맷
• XML• JSON (XML보다가볍고빠른
처리가능)
3) 프로토콜
• REST • XML-RPC• SOAP
1) 인증
• API 호출시허가된사용자인지확인
• API Key 발급, OAuth인증
2) 트래픽제어
• API 허용량만큼쓰도록• 서버스케일링
3) 통계
• 사용량통계과금처리• 어뷰징감지
API Gateway 서버(웹서버겸용)
1) 개발자등록
• 기본정보• 애플리케이션정보
2) API 키발급
• API 별발급• 요청API와사용량
3) 통계
• API 사용량관리• 제휴신청
4) 개발지원
• 개발가이드• 커뮤니티, Q&A
API 포털웹서버에서처리가능
115
API의 핵심 구성 요소어플리케이션간의표준화된통신방식
API 포털서버
• 제휴사정보관리• 키 발급• API 사용관리
인증서버
• OAuth인증• HMAC 인증
통계서버
• API 이용로그데이터추출• 통계데이터생성 & API 대시보드
캐시서버
• 빠른 서비스속도를위한 캐싱• 소셜 네트워크에서서비스가퍼지는 경우트래픽 급증가능성
게이트웨이서버(웹서버를포함함)
• 다양한 API를묶어 하나로제공• API 트래픽제어 : 각 API에 대한트래픽 모니터링• API 보안
- 3rdparty에 API 서버은닉- 이용자식별을 위해인증처리
• API 사용로깅- 서비스별 API 사용현황집계- 향후 서버증설 시점예측
116
[참고] API에 관한 이런 저런 사실들…어플리케이션간의표준화된통신방식
■사용된언어의존성
■객체지향언어에서의API
• 객체지향언어에서 API 는 class definition 의 “behaviors”와 “description” 을 포함
o behaviors : class로부터 도출된 object 가주어진 환경에서 어떻게 동작할 것인가를 나타내는 것
• 추상화된 컨셉은 method로구현된 class에 의해 표출된 실제 기능과도 관련되어 있거나 fields나 constants 와 같이공개적으로 만들어진 internal entity도포함
o 이경우 API는 class에 의해 표출된 공개 method 전부. 즉, API 는 class definition으로부터 도출된 object 를다루거나 상호 작용하는 method
• 활용 : public methods를통해 실행
o Method : behavior가 어떻게 동작하는지를 보여주는 세밀한 기술단위
o 예를 들면, stack class 가단순히 push()와 pop() 두개의 method을노출시킬 수있으며, 이경우 API 는 pop()과 push()
Language-dependent Language-independent
• 특정 언어의 구성요소나 문장 속에서만 유효• 대신 API를사용하기 더 쉽게 만들수 있음
• 여러 개의 프로그램 언어로 호출 가능• 특정 프로세스나 시스템에 한정되어지지 않음(Service Oriented API)
• Remote procedure call 이나 web service 형태로도 제공예) 구글맵 API를이용하여 레스토랑을 찾는웹사이트 구축구글맵의 API는 3rd party 사이트가 어떤 정보를 사용할 수 있는지, 어떻게 그것을이용할 수 있는지까지 지원
117
[참고] API에 관한 이런 저런 사실들…어플리케이션간의표준화된통신방식
■ API library와 framework
• API는일반적으로 software library로도 불려진다.
o API 는 library가 구현되었을 때 나타나는 action들을 기술하고 정의하는 것이다.o 단일 API 는여러 개의 implementation을포함할 수도 있거나, 아니면 없거나, 그냥 추상적인 상태로 있을 수도 있다.o 그리고, 같은 프로그래밍 인터페이스를 공유하는 다른 library 들로도 보일 수 있다.
• API 는 software framework 이라고 불리기도 한다.
o framework 이란 여러 개의 API 를구현하는 여러 개의 library 에기반할 수도 있다.o 그러나, API 의 일반적인 사용법과는 달리 framework 내에 구현되어진 behavior는 framework 내의 새로운 class 로 컨텐츠를 확장시킴으로써 사용할 수 있게 된다.o 더구나 전반적인 프로그램 흐름의 컨트롤은 caller의 영역밖이다.o 컨트롤 흐름을 바꾸거나 유사한 메커니즘으로 프레임웍의 통제 하에 있다.
■Web API
• 웹개발이라는 관점에서 API 는 http 프로토콜의 집합(XML, JSON 등)
• WebAPI는가상적으로는 웹서비스와 동의어
• 최근 트렌드는 SOAP 기반 서비스에서 REST 기반의 직접 통신으로 바뀌고 있다.
• Web API는 mashup이라고알려진 새로운 어플리케이션으로 복합 서비스의 조합들을 허락하고 있다.
■ API sharing and reuse on Virtual machine
• 가상 머신에서 실행되어진다면 그언어들은 API 들을 공유할 수도 있다.
• 이경우 특정 언어로부터 도출된 가상머신의 공통분모가 중간 bytecode나 language binding을 통해 언어간 상호작용(API sharing)을가능하게 한다.
• 이런 관점은 존재하는 모든 라이브러리나 관련된 API 들에 대한 재사용성을 극대화 한다.
118
[참고] API에 관한 이런 저런 사실들…어플리케이션간의표준화된통신방식
■ API와 프로토콜(protocols)
• API 는프로토콜의 구현이기도 하다.
■ Object API &protocol
• 객체 지향 API = 특정 객체 교환 포맷
• 역할 : 이프로토콜은 remote system으로메시지 안에 있는 동일한 종류의 정보를 전송하는 방법을 정의
• object 메시지가 두개의 다른 플랫폼 사이에서 프로토콜로 사용되어지기도 한다.
• 한언어 안의 object 는 다른언어의 object로전송됨.
o 예를 들면, Java 프로그램은 C#으로 만들어진 SOAP, IIOP를통해 서비스를 부른다.o 두프로그램은 상호 call을 위해 메모리상의 object를가지고 convert할수있도록 API를사용한다.o 유사한 object가 API를통해 하나의 머신으로 전달되어질 때 메모리 상에서 처리하는게 효과적일 때도 있다.
출처 <https://subokim.wordpress.com/2011/12/13/api-definition/>
프로토콜 API
• 프로토콜은 통상적인 전송에서 request 와 response 를교환하는 표준화된 방법을정의하고, 메시지 표준을 정의하는 것
• 일반적으로 다른 기술 사이에서 정보공유를 하는데 사용
o 두세계의 추상화된 레벨로서 작동
• 일반적으로 직접 사용되어지는 라이브러리로 구현 transport 가포함되지 않을수있음(오히려 특정 언어의 데이터나 function call을 통한 간단한 정보 교환)
• API 로프로토콜을 구현할 때, 통신프로토콜에 의존하는 remote invocation을위한 proxy method에기반
• API의역할은 정확히 transport 프로토콜의 세부내용을 숨기는 것
• API 는특정 기술에 특화(wrapping 을통해 다른 언어에서도 사용 가능)
119
API Gateway어플리케이션간의표준화된통신방식
• MSA(Micro-Services Architecture)와 함께근래에 떠오르는기술
• API 게이트웨이는 API 서버앞단에서모든 API 서버들의엔드포인트를단일화하여묶어주고 API에 대한인증과인가기능에서부터메세지에따라서여러서버로라우팅하는고급기능까지많은기능을담당
• ESB와의 관계
SOA : ESB = MSA : API 게이트웨이
ESB API Gateway로 발전 : ESB의대부분의 컨셉을 많이 승계
ESB가 SOAP/XML 웹서비스 기반의 많은 기능을 가지는 구조였다면, API 게이트 웨이는 JSON/REST 기반에최소한의 기능을 처리하는 경량화 서비스
ESB의실패와, MSA, REST 구현 사례를 통해서 필요에 의해서 탄생한 솔루션 실용성 강화
• API 게이트 웨이는여러 개의 엔드 포인트를설정하고, 각 엔드 포인트 마다 메세지흐름을 워크 플로우엔진설정을 통해서 API 에 대한 Mediation, Aggregation 설정을 할 수 있는미들웨어
• API Gateway를 도입하기위해서는적절한 Gateway 아키텍처를설계필요
120
API Gateway의 주요 기능어플리케이션간의표준화된통신방식
인증/인가에관련된기능
• API 토큰 발급: 사용자인증후 API를 호출할수 있는토큰발급
• 엔드 포인트별 API 호출 인증: API 호출을승인할지여부를결정
• 엔드 포인트별 API 요청 인가: API 호출권한확인
메디에이션기능 (Mediation)
• 메세지 포맷 변환(Message format transformation)
• 프로토콜 변환• Message Exchange Pattern(MEP)
: 동기를비동기로, 하나의호출을여러개로복사
• 어그레게이션 (aggregation) : 여러개의 API를묶어서하나의 API로만드는작업
API 라우팅
• 백 엔드 API 서버로의 로드 밸런싱: API gateway 뒤에있는여러개의 API 서버로부하분산
• 서비스와 클라이언트 별 엔드 포인트 제공: 같은 API를여러개의 엔드포인트를통해서서비스제공
• 메세지 또는 헤더기반 라우팅
Logging / 미터링
• API 호출 로깅: 사용패턴분석, 문제추적을위한 자료
• API 미터링 & 차징 (Metering & Charing)
• QoS 조정 (Quality of service)
: 사용고객의등급에따라서서비스레벨조정
공통로직처리
• 인증(Authentication)
• 로깅(logging) 등
출처 <조대협, http://bcho.tistory.com/1005>
121
5. Cloud Native Application Maturity Model
Not Designed for PaaS Can run on PaaS Designed for PaaS
Cloud Deployed(Hosted) Cloud Aware Cloud Native
Cloud Native Application의 성숙도 모형Cloud의특성과장점을활용한 Cloud Native Application의성숙단계별특징
123
[참고] Cloud application maturity level
124
출처 <http://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf>
Infrastructure의활용관점에서본 Cloud application 성숙도
Cloud Native 여부를 어떻게 알수있을까?
125
출처 : Andrew Spyker (ex-IBM, now with the Netflix platform team)
1. Can you redeploy your entire application in minutes?
2. Does your application depend on specific IP addresses, ports, file systems, that are not part of the
automated installation?
3. Can your application survive , and auto-recover from, infrastructure (compute, network, storage)
failures?
4. Can you upgrade and downgrade, your application (or parts of the application) without any impact to
users?
5. Can you run multiple versions of your application services, in the same environment at the same time?
6. Can you safely test in production?
7. If a part of an application fails, will other parts continue to operate?
8. Can parts of your application scale-up and scale-down automatically, based on user load or other
factors?
9. Can you deploy application components across cloud providers?
10.Can you deploy an application component on a different cloud provider?
6. Cloud Native Eco-system
Physical Infrastructure
Virtual Infrastructure
Minimal OS
Container Engine
Service Discovery
Orchestration: Scheduling
& Cluster Management
Workflow / Management
Code
Tools
Infrastructure
어플리케이션을구성하는프로그래밍언어, 프레임워크, 라이브러리
Code deployment pipelines, automation and configuration management
frameworks, container and infrastructure management
Tools which automatically run and manage jobs, containers and hosts in a
cluster; often modeled after Google Borg/Omega
Tools enabling an application or service to discover information about its
environment and other components needed to form a larger system
Specification and execution engine for operating-system-level virtualization
environment for running multiple isolated Linux systems
Lightweight operating system to manage compute resources necessary to
deploy applications in containers
Emulated physical compute, network and storage resources that are the
basis for cloud-based architectures
데이터센터를구성하는데필요한물리서버, 스위치, 라우터, 스토리지등
The “Cloud-Native” Stack – Taxonomy
127
(Machine, Swarm, Compose) (Serf, Terraform)
The “Cloud-Native” Stack – Select Products / Vendors
Physical Infrastructure
Virtual Infrastructure
Minimal OS
Container Engine
Service Discovery
Orchestration: Scheduling
& Cluster Management
Workflow / Management
Code
Tools
Infrastructure
128
• Consul (Hashicorp)
• etcd (CoreOS)
• Eureka (Netflix)
• Zookeeper (Apache)
• SmartStack (AirBnB)
• Mesos-DNS (Mesosphere)
Minimal OS
Container Engine
Service Discovery
Orchestration:
Scheduling &
Cluster Management
Tooling &
Management
• Cloud Foundry (Pivotal)
Stakato (HP)
HP Helion
IBM Bluemix
• Open Shift / Project
Atomic (Red Hat)
• Elastic Container Service
(AWS)
• Google Container Service
• Triton (Joyent)
• Rancher
• Flynn
• Tutum
• Terminal.com
• CoreOS (CoreOS)
• Project Atomic (Red Hat)
• Photon (VMware)
• RancherOS (Rancher)
• Snappy Ubuntu Core
(Canonical)
• Windows Nano Server
(Microsoft)
• libcontainer (Docker)
• runC (Open Container
Foundation)
• appC (CoreOS)
• Ubuntu LXD (Canonical)
• Drawbridge? (Microsoft)
• LXC/libvirt (Red Hat)
• Kubernetes (Google/CoreOS)
• Mesos, Marathon (Mesosphere)
• Swarm, Machine, Compose
(Docker)
• Fleet (CoreOS)
• Serf, Terraform, Atlas
(Hashicorp)
• Helios (Spotify)
• Project Titan (Netflix)
• Chronos (AirBnB)
• Auroroa (Apache)
• Cloudify (Gigaspaces)
• Magnum+Heat (OpenStack)
• Chef
• Puppet
• Ansible
• SaltStack
• Deis
(EngineYard)
• Glider Labs
• CircleCI
• TravisCI
• Bouyant.io
• WeaveWorks
• SysDig
• Panamax
(CenturyLink)
• CloudNative
• Wercker
• Shippable
• Brooklyn
(Apache)
• Giant Swarm
• DCHQ.io
• Nirmata
• Cloud66
• StackEngine
• Convox.io
• Magnetic.io
• Dozens more…
Platform
The “Cloud-Native” Ecosystem
129
Key Findings and Summary
• Characteristics of the “cloud-native” stack:
Containers as the modular compute building block with…
Composable, microservices-oriented application architectures and…
Dynamic, self-healing scheduling
• Today Docker, CoreOS, Kubernetes (Google) and Mesosphere are leaders but there are no winners yet
o We still don’t know what the components of the container stack will look like…
Distributed service discovery is still broken (etcd is not highly available)
Autonomic scheduling is promise not yet reality: Kubernetes is right abstraction, Mesos is right scheduling algos, but neither has it nailed
There are major unresolved issues around persistence, storage and security
But the biggest issue facing the ecosystem? Lack of best practices and know-how
• Most of market is competing at management layer, but as we saw with virtualization and cloud: you win from the bottom up – in this paradigm that’s the orchestration/cluster management layer
• Containers are still missing a “killer app” and a business case (virtualization :: consolidate IT)
• With standards now emerging (Open Container Initiative, Cloud Native Foundation) we expect to see the emergence of a hardened toolchain which should unleash a second wave of innovation
130
※ Mesos : Container와 VM을 구동하기 위한 프레임워크이자 컨테이너 관리 솔루션
Toward Cloud Native Application
Cloud Native Application으로 가는 길
132
IT 문화의측면1.Silos DevOps
2.Punctuated Equilibrium Continuous Delivery
3.중앙 집중형관리/의사결정분산형 관리/분권형의사결정
조직측면1.Business Capability Team 구성2.Platform Operation Team 구성
기술측면1.Decomposing Monoliths
2.Decomposing Data (=Business Contexts)
3.Containerization
4.From Orchestration to Choreography
출처 < “Migrating to Cloud-Native Application Architecture”, Matt Stine, 2015>
감사합니다.seong-bok.lee@hpe.com
Cloud Landscape
134
SaaS
App Services
Model-driven PaaS
PaaS
Fundamental PaaS
Software Defined
Datacenter
Applications
Compute
App Services
bpmPaaS,
Model-Driven PaaS
aPaaS
Application
containers
Virtual Machines
Communicate
App Services
Model-Driven
iPaaS
iPaaS
Routing,
messaging
Software Defined
Networking(SDN)
Store
App Services
baPaaS
dbPaaS
Object storage
Software Defined
Storage(SDS)
Compute Communicate Store
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
End-users
Citizen
developers
Business
engineers
Professional
developers
DevOps
Infrastructure
engineers
Cloud Foundry
135
Cloud Foundry is the industry’s Open PaaS and
provides a choice of clouds, frameworks,
and application services. Its unique vision is
to foster contributions from a broad
community of developers, users, customers,
partners, and ISVs while advancing
development of the platform at extreme
velocity. - cloudfoundry.org
Mission :
• to establish and sustain Cloud Foundry as the global industry standard open source PaaS technology with a thriving ecosystem.
• To deliver continuous quality, value and innovation to users, operators and providers of Cloud Foundry technology.
• To provide a vibrant agile experience for the community's contributors that delivers the highest quality cloud-native applications and software, at high velocity with
global scale.
Its guiding principles are:
• Governance By Contribution - Influence within the Foundation is based on contributions.
• IP Hygiene - IP cleanliness must be preserved at all times.
• Equal Opportunity To Participate - Everyone has an equal opportunity to participate in projects.
• No Surprises - Planning processes and project status are open to all.
Cloud Foundry Foundation
Cloud Foundry Architecture
Austin Cloud
Foundry PaaS
Meetup 2/24/15 136
• The platform is abstracted as a set of large-scale distributed services.
• It uses Cloud Foundry Bosh tooperate the underlyinginfrastructure from the IaaSproviders.
• Components are dynamicallydiscoverable and loosely coupled.
• Health is exposed through HTTP endpoints so agents can collect state information and act on it.
Cloud Foundry Components(1/3)
Austin Cloud
Foundry PaaS
Meetup 2/24/15 137
Component How It Works Responsible for
Dynamic Router • The router shapes and routes all external system
traffic (HTTP/ API) and application traffic from the
internet/intranet.
• It maintains a dynamic routing table for each load-
balanced app instance with IP addresses and ports.
• Load balancing
• Maintaining an active routing table
• Access logs
• Supports web-sockets
Cloud Controller • The Cloud Controller maintains command and control
systems, including interface with clients (CLI, Web UI,
Spring STS), account and provisioning control.
• It also provides RESTful interface to domain objects
(apps, services, organizations, spaces, service
instances, user roles, and more).
• Expected App state, state transitions, and
desired convergence
• Permissions/Auth Orgs/Spaces/ Users
• Services management
• App placement
• Auditing/Journaling and billing events
• Blob storage
UAA and Login Servers • “User Authorization and Authentication” provides
identity, security and authorization services.
• It manages third party OAuth
• 2.0 access credentials and can
• provide application access and identity-as-a-service
for apps running on Cloud Foundry.
• Composed of: UAA Server, Command Line Interface,
Library.
• Token Server
• ID Server (User management)
• OAuth Scopes (Groups) and SCIM
• Login Server UAA Database
SAML support (for SSO integration) and
Active Directory support with the VMware
SSO Appliance
• Access auditing
Cloud Foundry Components (2/3)
Austin Cloud
Foundry PaaS
Meetup 2/24/15 138
Component How It Works Responsible for
Health Manager • Health Manager monitors application uptime by
listening to the NATS message bus for mismatched
application states (expected vs. actual).
• The Cloud Controller publishes expected state and
the DEAs publish actual state.
• State mismatches are reported to the Cloud Controller.
• Maintains the actual state of apps
• Compares to expected state
• Sends suggestions to make actual match
expected (cannot make state changes itself –
only CC can do that!)
DEA • “Droplet Execution Agents” are secure and fully
isolated containers.
• DEAs are responsible for an Apps lifecycle: building,
starting and stopping Apps as instructed.
• They periodically broadcast messages about their
state via the NATS message bus.
• Managing Linux containers (Warden)
• Monitoring resource pools Process
File system
Network
Memory
• Managing app lifecycle
• App log and file streaming
• DEA heartbeats (NATS to CC, HM)
BuildPacks • Buildpacks are Ruby scripts that detect application
runtimes/frameworks/plugins, compile the source
code into executable binaries, and release the app to
an assigned DEA.
• Runtime components can be cached for faster
execution of subsequent app pushes.
• Staging* /bin/detect
/bin/compile
/bin/release
• Configure droplet Runtime (Ruby/Java/Node/ Python)
Container (Tomcat/Liberty/ Jetty)
Application (.WAR, .rb, .js, .py)
(*) Cloud Foundry Buildpacks are compatible with Heroku
Cloud Foundry Components (3/3)
Austin Cloud
Foundry PaaS
Meetup 2/24/15 139
Component How It Works Responsible for
Messaging (NATS) • NATS is a fast internal messaging bus to manage
system wide communication via a publish-and-
subscribe mechanism.
• Non-Persistent messaging
• Pub/Sub
• Queues (app events)
• Directed messages (INBOX)
Service Broker • Service Brokers provide an interface for native and
external 3rd party services.
• Service processes run on Service Nodes or with
external as-a-service providers (e.g., email, database,
messaging, etc.).
• Advertising service catalog.
• Makes create/delete/bind/ unbind calls to
service nodes.
• Requests inventory of existing instances and
bindings from cloud controller for caching,
orphan management.
• SaaS marketplace gateway.
• Implemented as HTTP enpoint, written in any
language.
UPSI • User Provided Service Instances (formerly “Service
Connectors”) store meta-data in the Service Broker to
enable Cloud Foundry to connect to local services that
are NOT managed by Cloud Foundry (e.g., OracleDB,
DB2, SQLServer, etc.)
• Metadata management