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

클라우드 컴퓨팅
4
DevOps-driven multi-cloud
Hybrid cloud management
Cloud-native app platform
Orchestration
Analytics | Collaboration | Compliance
Infrastructure
automation
Unified storefront and user experience
Service
transformation
Across any technology
Bare-metal, virtual,
containers
Traditional and
modern apps
Private, managed
and public clouds
인터넷 상에서 컴퓨팅 작업이 이루어 지는 환경(“Computing over the Internet”)
• The use of new or existing computing
hardware and virtualization technologies to
form a shared infrastructure that enables
web-based value added services.
• End users access cloud-
based applications through a web browser or a
light-weight desktop or mobile app
• The business software and user's data are
stored on servers at a remote location
• a way to increase capacity or add capabilities
on the fly

클라우드 컴퓨팅의 특성
5
• 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/SaaS
Utility Computing /
On-demand
Cloud 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 기술
• 클라우드 네트워크 보안 기술
클라우드 인프라 기술
인프라 자원 관리 기술
• 개방형 자원 모니터링과 스케줄링 기술
• 지능형 동적 부하관리 기술
인프라 자원 가상화 기술
• 서버 가상화 기술
• 스토리지 가상화 기술
• 네트워크 가상화 기술
• 입출력 가상화 기술
클라우드 네트워크 기술
• 확장형 고속 네트워크 기술
• 클라우드간 연동 기술

어플리케이션의 유형
11
Native application
(desk-top)
특정 Platform이나 Device에서
사용되도록 개발된 Application
• can interact with and take advantage of
operating system features and other
software that is typically installed on that
platform.
• has the ability to use device-specific
hardware and software, meaning that
native apps can take advantage of the
latest technology available on mobile
devices such as a GPS and camera.
• This can be construed as an advantage
for native apps over Web apps or
mobile cloud apps.
Web application
표준 Web 기술을 사용하여
Platform이나 Device에 상관 없이
사용되도록 개발된 Application
• Client-server 소프트웨어 어플리케이션
• 프로그램은 원격 서버에 저장되고 인터넷을
통해 웹 브라우저에서 실행
• 예) webmail, online retail sales, online
auctions, wikis, instant messaging
services 등
Cloud (native)
application
Desktop application + Web
application으로 클라우드 환경에서
실행되는 어플리케이션 프로그램
• desktop app과 같이 응답 속도가 빠르고
오프라인에서도 작업 가능
• web apps처럼 특정 기기(device)에 종속될
필요가 없고 온라인으로 쉽게 업데이트 가능
• 사용자가 통제 가능하지만, 사용자 컴퓨터나
저장장치의 저장공간을 사용할 수 없음 .
• a well-written cloud app offers all
the interactivity of a desktop app along
with the portability of a Web app.
어떤 종류의 어플리케이션들이 있는가?

12
Cloud Native Application = 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
비즈니스 변화에 대한 신속한
대응력 확보 필요

출처 < “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

The move to “value creator” requires agility on many fronts
18
What?
Key characteristics …
• Services
• Handling Failures
• Horizontal Scalability
• Asynchronous Processing
• Stateless Model
• Minimize Human
Intervention & Continuous
Delivery
Why?
There is a need for …
• Speed (delivery)
• Safety (fault tolerance,
design for failure)
• Scalability
• Client diversity
How?
Integrate ..
• Microservices oriented
architectures (a service
should do one thing well)
• Use API-based
collaboration
• Cloud methodology :
12-factor app
• Use multi-tenant DB
architecture
• Use self-service agile
platforms

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
Node
Node
Node
Scale out data tier
Bi-directional
replication
Stateless
Business Logic
Node
Node
Node
Scale out data tier
Stateless
Business Logic
Node
Node
Node
Scale out data tier
Cloud Native Application의 주요 특징(What)

Cloud-native application architecture가 필요한 이유(Why)
21
Speed of Innovation
to deliver software-based solutions more quickly
• 새로운 어플리케이션 환경 제공 또는 새 버전의
소프트웨어 배포
• 잘못 배포했을 경우 즉각적인 복구
Mobile-centric user experiences
to handle a huge diversity of (mobile) platforms and
legacy systems (client diversity)
• IT 환경과 비즈니스 서비스에서 다양성의 극단적인
확대
• Mobile 환경과 서비스의 확대  mobile 우선의 개발
Always-available services(Safety)
장애발생 시 타 서비스에 영향을 주지 않으면서도 빠르게
복구할 수 있는 아키텍처
• Visibility : 장애 상황을 파악할 수 있는 도구 제공
• Fault isolation : 장애 영향을 받는 서비스 구성범위 제한
• Fault tolerance : 장애가 퍼지지 않도록 의존성 최소화
• automatic recovery : 정형화된 유형의 장애들은 시스템이
자동으로 복구
Web Scale
to enable horizontal (instead of vertical) application
scaling
• Scale up을 통한 수직적인 확장  비용부담이 적고
빠른 Scale out을 통한 수평적인 확장
• 작고 균일한 서버들의 가상화를 통한 workload
ochestration
빠르게 변화하는 비즈니스 환경에 대응
출처 < “Migrating to Cloud-Native Application Architecture”, Matt Stine, 2015>

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

Codebase Dependencies Configuration
Backing
Services
Build,
Release, Run Processes Port Binding Concurrency
Disposability
Dev/Prod
Parity Logs
Admin
Processes
12-Factor App이란?
software(SaaS)를 개발하고
배포하기 위한 일련의
방법론 또는 Best practice
• Practices translate into platform features and
workflow requirements http://12factor.net
• Apps don’t need to follow all 12 rules for customer
to be PaaS ready
33

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

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 Web
Monolithic
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
Router
L4L4
Content
Router
A UI
B UI
C UI
D UI
API Gateway
(White base)
MS-A
(Java)
MS-B
(Nodejs)
MS-C
(Nodejs)
MS-D
(Java)
Service
Registry
Event Broker
Config
Service
DB
(MySQL)
DB
(MySQL)
Redis
(MySQL)
File
Storage
DB
(MySQL)
Browser/Client
API
API
API
API
• 서비스는
개별적으로
업데이트되고
배포됨. 대부분
자동화된
스크립트를 통해
이루어짐
• 서비스의 위치를
알려주는 유일한
주소(URL)를
가짐
• 오로지 한 가지의 역할만 수행하는 서비스들(업무 기능, 시나리오, 특정 문제의 해결 등)이 서로 독립적이고 분권화되어 있음
• 고립된 서비스들은 표준화된 API를 통해서 서로 통신/결합  다른 관련 서비스를 바꾸지 않고도 원하는 특정 서비스만 변경
• 구축 시 중점 사항 : 느슨하게 결합된 구성요소들, 확장성, 코드의 분리(partitioning), 업그레이드와 변경을 쉽고 빠르게 하고
유연성을 보장하는 상태
• 자가 치료 : 기계 고장으로 어플리케이션이 멈추면 자동 실행하고 이전의 상태로 복구할 수 있도록 개발
• 데이터베이스의 비정규화 : 서비스와 느슨하게 결합된 스키마 또는 각각의 microservice별로 별개의 스키마 생성

Microservices란?
46
비즈니스 시스템(어플리케이션)을 개발/배포/운영할 때,
 ONE THING
한 가지 기능(비즈니스 관련 기능/역할)을 수행하는데 초점을 맞춘 서비스를
 SMALL
독립적이고 배포가능한 가장 작은 단위의 서비스(= atom)로 분리하고
 API
API를 통해 다른 서비스와 연계하며
 AUTONOMOUS
각각 자율적으로 개발, 운영. 즉, 독립적인 팀이 각 서비스(=atom)의 개발과
운영을 담당
“The microservice architectural style is an approach to developing a single application
as a suite of small services, each running in its own process and communicating
with lightweight mechanisms, often an HTTP resource API.”
- Martin Fowler

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
Development
Reusability
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
(기능/서비스를 분리/분할)
Monolith
Cloned &
load-balanced
X축 확장 :
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
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의 핵심 유형

 Bounded Context
 Contract-First(API-First)
Design
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
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.)

68
3. Chained Microservices Design Pattern
• produce a single consolidated response to the
request.
• the client is blocked until the complete chain of
request/response, 즉 Service A -- Service B 사이와
Service B – Service C 사이의 프로세스가 끝날 때까지
• 각각의 서비스는 각자의 business value를 요청과
응답에 추가 : 들어온 요청이 A에서 B로 갈 때, B에서 C로
갈 때는 그 요청의 내용이 다름. 마찬가지로 C B 
A로 이어지는 응답 내용이 다름.
• 요청/응답 체인을 너무 길게 만들지 않아야 함 : the
synchronous nature of the chain will appear like a
long wait at the client side, especially if its a web page
that is waiting for the response to be shown. There
are workarounds to this blocking
request/response and are discussed in a subsequent
design pattern.
• singleton chain : 마이크로서비스 하나만 갖는 체인
This may allow the chain to be expanded at a later
point.
기본 원리
the request from the client is received by Service A, which is then communicating with
Service B, which in turn may be communicating with Service C. All the services are
likely using a synchronous HTTP request/response messaging.

69
4. Branch Microservices Design Pattern
• Aggregator 설계 유형을 확장함으로써 상호 배태적인 두
개의 마이크로서비스 체인으로부터 동시에 응답을 받을
수 있도록 한 설계 유형(simultaneous response
processing)
기본 원리
사용 방법
• 업무상 필요에 따라 다른 체인 여러 개 또는 체인 한 개를
불러올 때 사용
• Aggregator 설계 유형과 비슷하게,
Service A(웹 페이지이던 또는 복합 microservice이던)는
두 개의 서로 다른 체인을 동시에 불러올 수 있음 can
• 아니면 Service A는 클라이언트로 부터 받은 요청에 따라
하나의 체인만 불러올 수도 있음.
• JAX-RS이나 Camel endpoint의 라우팅을 사용해서
동적으로 설정할 수 있음

70
5. Shared Data Microservices Design Pattern
• 마이크로서비스 설계 원칙 중의 하나는
자율성(autonomy). 즉 서비스는 모든 것을 갖추고
있어야 하고 모든 구성요소(UI, 미들웨어, persistence,
트랜잭션)를 통제
• 서비스는 polyglot이 가능해야 하며 작업에 필요한 최적의
도구/기술을 사용할 수 있어야 함
• 그러나 체인에서 처럼 캐시와 데이터베이스 저장소를
공유할 수 있음(다, 두 서비스가 강력하게 결합되어 있을
경우만 가능)
기본 원리
사용 방법
• 마이크로서비스가 완전히 자율적으로 구현되기 전까지
이행단계에서 활용 가능
• 데이터베이스 정규화를 통해 더도 덜도 말고 딱 필요한
만큼의 데이터를 갖게 되는데, 마이크로서비스로
이행하려면 기존의 Monolithic application이 SQL만
사용한다 하더라도, 비정규화를 통해 데이터 중복과
불일치성이 발생하게 될 수도 있음
• 이행기간 중에는 이 shared data 설계 유형이 더
효과적일 수 있음

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 출현의 배경
• 프로세스에 자유롭게 자원을 할당할 수
없음
• 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
Fast
Port-
able
• no CPU or I/O penalty
because there is no virtualized
hardware to pass through or
boot
• 기존의 어플리케이션을 빠르게
실행
• 데이터 센터 같은 곳에서 고밀도
로 자원을 최적화
• 코드레벨의 빠른 배치가 가능
• because containers are
packaging format that holds an
application with all of it’s
dependencies and
configurations it will run the
same in any environment

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
configurabil
ity
Instead of customizing the
application for a customer
(requiring code changes), one
allows the user to configure
the application through
metadata
• One application
instance may be
serving hundreds of
companies
• Opposite of multi-
instance where each
customer is
provisioned
• their own server
running one instance

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>

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 유형

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

Cloud native application 입문

Cloud native application 입문

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Cloud native application 입문

Similar to Cloud native application 입문 (20)

More from Seong-Bok Lee

More from Seong-Bok Lee (11)

Cloud native application 입문