cloud native application 입문

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.

어떤종류의어플리케이션들이있는가?

http://searchcloudapplications.techtarget.com/definition/cloud-application

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)

https://en.wikipedia.org/wiki/Software_licensing

https://en.wikipedia.org/wiki/Software_delivery

https://en.wikipedia.org/wiki/Subscription

https://en.wikipedia.org/wiki/Internet_hosting_service

https://en.wikipedia.org/wiki/User_(computing)

https://en.wikipedia.org/wiki/Web_browser

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

http://www.webopedia.com/TERM/A/API.html

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


Block Storage


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



Cluster (Layer 4)

Node (Layer 3)




services



other services.




including;

• Auto scaling


• Load balancing

• Health checking




• Image Registry




One or more CSPs


to store data

Application centric

view point (SaaS)

Service centric

view point (PaaS)

Cluster centric

view point(CaaS)

Node centric

view point (IaaS)





Cluster Scheduler


Operating System




Storage Services

File Storage Agent

Operation System


Block Storage


Overlay Network



• Object Storage

• File Storage

• Block Storage



Clustered Storage

scalable system composed of (micro)services


27



Cluster (Layer 4)

Node (Layer 3)




services



other services.




including;

• Auto scaling


• Load balancing

• Health checking




• Image Registry




One or more CSPs


to store data

Application centric

view point (SaaS)

Service centric

view point (PaaS)

Cluster centric

view point(CaaS)

Node centric

view point (IaaS)





Cluster Scheduler


Operating System




Storage Services

File Storage Agent

Operation System


Block Storage


Overlay Network



• Object Storage

• File Storage

• Block Storage



Clustered Storage

Isolate state


28



Cluster (Layer 4)

Node (Layer 3)




services



other services.




including;

• Auto scaling


• Load balancing

• Health checking




• Image Registry




One or more CSPs


to store data

Application centric

view point (SaaS)

Service centric

view point (PaaS)

Cluster centric

view point(CaaS)

Node centric

view point (IaaS)





Cluster Scheduler


Operating System




Storage Services

File Storage Agent

Operation System


Block Storage


Overlay Network



• Object Storage

• File Storage

• Block Storage



Clustered Storage

self-contained deployment unit


29



Cluster (Layer 4)

Node (Layer 3)




services



other services.




including;

• Auto scaling


• Load balancing

• Health checking




• Image Registry




One or more CSPs


to store data

Application centric

view point (SaaS)

Service centric

view point (PaaS)

Cluster centric

view point(CaaS)

Node centric

view point (IaaS)





Cluster Scheduler


Operating System




Storage Services

File Storage Agent

Operation System


Block Storage


Overlay Network



• Object Storage

• File Storage

• Block Storage



Clustered Storage

elastic platform


30



Cluster (Layer 4)

Node (Layer 3)




services



other services.




including;

• Auto scaling


• Load balancing

• Health checking




• Image Registry




One or more CSPs


to store data

Application centric

view point (SaaS)

Service centric

view point (PaaS)

Cluster centric

view point(CaaS)

Node centric

view point (IaaS)





Cluster Scheduler


Operating System




Storage Services

File Storage Agent

Operation System


Block Storage


Overlay Network



• Object Storage

• File Storage

• Block Storage



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

http://12factor.net/

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.

https://en.wikipedia.org/wiki/Rock_(geology)

https://en.wikipedia.org/wiki/Mountain

문제점 –기술변화에 대한 대응 제한

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이란• 소프트웨어는도메인의핵심개념과각구성요소를담고있어야하고그들간의관계를

정확하게실체화• 소프트웨어는도메인을모델링하고개발과정에서의피드백을통해설계강화



Bounded Context


Decomposed database


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의핵심 유형

http://martinfowler.com/bliki/MultipleCanonicalModels.html



Bounded Context


Decomposed database


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



Bounded Context


Decomposed database


62

분해(decomposition):

• 하나의관계의열들을둘 이상의관계로분할하며, 관계유지에필요한열들만복제하는것

Database decomposition이란?

• Decomposition – 구성항목이나요소를더 작게쪼개는과정(process)

• 데이터베이스에서 Decomposition이란테이블을여러개의테이블로쪼개는것• From Database perspective means going to a higher normal form

좋은(올바른) 분해의두가지특성

1) Lossless : 어떤정보를잃지않는분해2) Preserve dependencies


– 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.


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.)

http://blog.arungupta.me/wp-content/uploads/2015/04/microservices-proxy.png


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.

http://blog.arungupta.me/wp-content/uploads/2015/04/microservices-chain.png


69

4. Branch Microservices Design Pattern

• Aggregator 설계유형을 확장함으로써상호 배태적인두개의 마이크로서비스체인으로부터동시에응답을받을수 있도록한 설계 유형(simultaneous response

processing)

기본원리

사용방법

• 업무상필요에 따라다른 체인 여러개 또는 체인한 개를불러올때 사용

• Aggregator 설계유형과 비슷하게,

Service A(웹 페이지이던또는복합 microservice이던)는두 개의서로 다른 체인을동시에 불러올수 있음 can

• 아니면 Service A는 클라이언트로부터 받은 요청에따라하나의체인만 불러올수도 있음.

• JAX-RS이나 Camel endpoint의라우팅을사용해서동적으로설정할수 있음

http://blog.arungupta.me/wp-content/uploads/2015/04/microservices-branch.png


70

5. Shared Data Microservices Design Pattern

• 마이크로서비스설계 원칙 중의하나는자율성(autonomy). 즉 서비스는모든것을 갖추고있어야하고 모든 구성요소(UI, 미들웨어, persistence,

트랜잭션)를통제

• 서비스는 polyglot이가능해야하며작업에 필요한최적의도구/기술을사용할수 있어야 함

• 그러나체인에서처럼 캐시와 데이터베이스저장소를공유할수 있음(다, 두 서비스가강력하게결합되어있을경우만가능)

기본원리

사용방법

• 마이크로서비스가완전히 자율적으로구현되기 전까지이행단계에서활용가능

• 데이터베이스정규화를통해더도 덜도 말고딱 필요한만큼의데이터를갖게 되는데, 마이크로서비스로이행하려면기존의 Monolithic application이 SQL만사용한다하더라도, 비정규화를통해 데이터중복과불일치성이발생하게될 수도 있음

• 이행기간중에는이 shared data 설계유형이 더효과적일수 있음

http://blog.arungupta.me/wp-content/uploads/2015/04/microservices-branch-shared-data.png


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 메시지를결합하여사용할수도있음

사용방법

http://blog.arungupta.me/wp-content/uploads/2015/04/microservices-async-messaging.png

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

http://searchservervirtualization.techtarget.com/definition/bare-metal-environment

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.

https://en.wikipedia.org/wiki/Software_architecture

https://en.wikipedia.org/wiki/Instance_(computer_science)

https://en.wikipedia.org/wiki/Computer_software

https://en.wikipedia.org/wiki/Application_software

https://en.wikipedia.org/wiki/Non-functional_requirement

가상화와의 차이점

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.

https://en.wikipedia.org/wiki/Hardware_virtualization

[참고] 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가지유형의서비스:

https://en.wikipedia.org/wiki/Time-sharing

https://en.wikipedia.org/wiki/Process_(computing)

https://en.wikipedia.org/wiki/Hotmail

[참고] 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>


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해야함)



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들의성능에영향을미침


어떤 접근 방법을 선택할 것인가??

94

1. 경제성(Economy)

SaaS용 multitenant DB architecture를선택할때 고려해야할것들

2. 보안(Security)

3. Tenant

4. 규제(Regulatory)

5. 기술(Skill-set)

• 접근방법을 선택할 때는 비즈니스와 경제 상황 요인(특히 비용)으로부터 영향을받음.

shared schema approach : 장기적으로는 비용이 절감되지만 (아키텍처의복잡성 때문에) 초기 투자 비용과 노력이 많음.

그러나 서버당 더 많은 tenant를 수용/지원할 수 있기 때문에 장기적으로는운영비용이 줄어들게 됨

isolated approach : 필요한 정도의 초기 투자를 받을 수 없거나 빨리어플리케이션을 구축해야 하는 경우.



95



2. 보안(Security)

3. Tenant



• 민감한 데이터를 보관해야 하면, 고객은 높은 수준의 보안을 요구하게 되고, 그SLA를 맞추기 위해서는 높은 수준의 데이터 안정성을 확보해야 함

• 두 가지 접근방법 모두 보안 문제에서는 큰 차이 없음: Isolated approach나 shared approach는 모두 강력한 데이터 보안이 가능 그러므로 다른 설계 유형이나 고려 요소와 함께 고려



96



2. 보안(Security)

3. Tenant



• 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가 적합



97



2. 보안(Security)

3. Tenant



• 보안과 기록관리/보존과 관련된 법규 준수 필요 활용하려는 시장/분야에는 어떤 법규의 제약이 있는지를 고려하여 접근 방법결정

• single-instance, multi-tenant 아키텍처는 신기술이므로 관련 전문가가 드뭄 SaaS application 개발에 필요한 지식을 습득하거나 전문가 채용


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


Connections

• Secure Database Tables


• Custom Columns• Tenant-Based Horizontal

Partitioning

Shared Database,

Shared Schema


Connections

• Tenant View Filter


• Preallocated Fields

• Name-Value Pairs

• Tenant-Based Horizontal

Partitioning

SaaS 어플리케이션을위한데이터베이스별로적합한 Security/Extensibility/Scalability 유형


https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tdc

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_sdt

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tde

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_cc

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_sts


https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_sdt


https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_cc

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tbhp


https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tvf


https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_paf

https://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_nvp

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란?

• 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


모델플랫폼 서비스

• 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


테스트와자동화 도구

• 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란?어플리케이션간의표준화된통신방식

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 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와 프로토콜(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

https://subokim.wordpress.com/2011/12/13/api-definition/

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 성숙도

http://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf

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?

https://twitter.com/aspyker

6. Cloud Native Eco-system



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

http://research.google.com/pubs/pub41684.html

(Machine, Swarm, Compose) (Serf, Terraform)

The “Cloud-Native” Stack – Select Products / Vendors



Minimal OS

Container Engine

Service Discovery

Orchestration: Scheduling

& Cluster Management

Workflow / Management

Code

Tools

Infrastructure

128

http://www.quantatw.com/Quanta/english/

http://www.supermicro.com/index_home.cfm

http://www.wistron.com/

http://www.openstack.org/

vmware.com

aws.com

https://cloud.google.com/

http://azure.microsoft.com/en-us/

coreos.com

http://www.ubuntu.com/cloud/tools/lxd

http://www.redhat.com/en

http://zookeeper.apache.org/

https://coreos.com/using-coreos/etcd/

http://kubernetes.io/

https://consul.io/

http://mesosphere.com/

coreos.com

• 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>

감사합니다[email protected]

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


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


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