the world’s only insight-driven event management …...zuul (proxy svc) playback (legacy dev.) api...

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |

A Pattern Language of Microservice마이크로 서비스 구현을 위한 다양한 패턴

Inho KangPrincipal Sales ConsultantInfrastructure, Cloud PlatformAugust 30, 2017

Confidential – Oracle Internal/Restricted/Highly Restricted


Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Confidential – Oracle Internal/Restricted/Highly Restricted 3


Program Agenda

History of Pattern Language

Microservice Patterns

Oracle Products

Wrap Up

1

2

3

4



Pattern Language & Microservice


‘패턴언어(Pattern Language)’는 건축가 Christopher Alexander가 집이나 마을을 설계할 때 반복적으로활용하면 좋을, 작은 단위의 설계 패턴들을 모아 정리한 것에서 시작되었다. – 1977년 출간

고양이가 앉아 쉴 수 있는 작은 공간에 대한 패턴

Reference : https://goo.gl/8JguXf

반복되어 사용되는 유용한 패턴을 체계적으로구조화하여 정리하는 방법이 패턴 언어이다

• Name : 패턴명

• Context : 문제 상황

• Problem : 문제

• Solution : 해결 방안

• Consequences : 장 단점

‘패턴언어(Pattern Language)’는 건축가 Christopher Alexander가 집이나 마을을 설계할 때 반복적으로활용하면 좋을, 작은 단위의 설계 패턴들을 모아 정리한 것에서 시작되었다. – 1977년 출간

‘패턴언어(Pattern Language)’는 건축가 Christopher Alexander가 집이나 마을을 설계할 때 반복적으로활용하면 좋을, 작은 단위의 설계 패턴들을 모아 정리한 것에서 시작되었다.

Monolithic Applications• 단일, Monolithic App

• 전체 App을 함께 배포해야 함

• 전체 App이 단일 DB 사용

• 기술 계층 중심으로 구성

• 각각의 런타임 인스턴스에 상태를 보관

• 전체 App이 하나의 기술 스택을 채택

• SOAP 사용

Microservices• 다수의, 더 작아진 최소 기능의 Microservices

• 각 Microservice를 독립적으로 배포

• 각 Microservice는 각자의 데이터 저장소를 가짐

• 비즈니스 기능 중심으로 구성

• 상태는 외부에 보관

• 각 Microservice가 각자의 기술을 선택

• HTTP를 통한 REST, Messaging, 또는 Binary

마이크로 서비스 아키텍처 스타일(Microservice architecture style)"은 독립적으로 배포 가능한서비스들의 묶음으로 소프트

Middleware/App Server

Transactions/Synchronous API Calls/Asynchronous

Monolith Problem : 1. Scaling 2. Performance 3. Deploy 4. Down

Micro ServicesA collection of smaller applications all working together to deliver a total experience to the end user.

Increased efficiency• Splitting your services gives you the ability to scale

only the parts of the site that is slow• Less wastage of service resource• More cost efficient

• An individual slow performing service doesn’t slow all services• Less user frustration


Easier Updates• Updating a smaller code base is easier

• Less likely to have a regression issue• Less likely to push a feature that isn’t ready from

another team

• Disable or slowly fail users over to the new version• You don’t put any other part of the service at risk• Easier roll back if the update fails


Increased stability• Gracefully fail parts of the site

• If one service fails the rest of the site still operates• Clever use of JS calls to services can detect failures

and mask it from the end user

• Much better end user experience

User Interface

Application

Datastore

Infrastructure

Resulting SoftwareTypical Enterprise Organization Structure

Head of IT

Head of Operation

Head of DBAsHead of

InfrastructureHead of App

DevHead of UI

Head of Development

An Enormous Monolith

Conway’s Law: Software reflects the structure of the organization that produced it

Build small product-focused teams – strict one team to one microservice mapping

Many Small Microservices

Resulting SoftwareMicroservices Organization Structure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

Product Lead

Project Manager Sys Admin DBAJavaScript Developer

Developer

Developer

Sys Admin

Storage Admin

Graphic ArtistNoSQL Admin

Product Lead


Developer

Developer

Sys Admin

Storage Admin


Product Lead


Developer

Developer

Sys Admin

Storage Admin


Product Lead


Developer

Developer

Sys Admin

Storage Admin


Edge

Load

Balancer

Zuul(Proxy Svc)

Playback(Legacy Dev.)

API(g/w)

Middle Tier & Platform

EVCache

Cassandra

Microservice는 분산 컴퓨팅환경을 특징들을 나타내게 되며, Complexity를 가중 시킨다.

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

Microservice A Microservice B Microservice C Microservice D

• Distributed computing is a natural consequence of microservicesbecause each microservice has its own datastore

• Sharing datastores across microservices introduces coupling – very bad!

• There will always be latency between microservices

• Latency = eventual consistency

• All data exchange between microservices must be through API layer or messaging – no accessing datastores cross-microservices

• Must implement high-speed messaging between microservices. REST + HTTP probably isn’t fast enough

• May end up duplicating data across datastores –e.g. a customer’s profile


Microservice Pattern


Reference: http://microservices.io

http://microservices.io

Patterns of Microserivce

Single Serviece per Host

Multiple Services per Host

Serverless deployment

Oracle Fx

AWS Lamda

Service-per-Container

Service-per-VM

Service Deployment Platform

Docker orchestration

(ex: k8s, Docker Swarm mode)

Helpful to microservices but not a requirement

Hardware

Hypervisor

VM 1

OS

App

VM 2

OS

App

Hardware Virtualization

Hardware

Operating System

Hypervisor

VM 1

OS

App

VM 2

OS

App

Para-virtualization

Hardware

Operating System

Container 1

App

Container 2

App

Containers

• #1 value – app packaging

• Microservices doesn't rely on containers but they do help:

– Higher density

– Easy to start/stop

– Portability

• Containers are lightweight, just like microservicesthemselves

Discovery

Service Registry

Server-side discovery

Client-side discovery

Self Registration

3rd Party Registration

External API

API Gateway

Backend for front end

Communication Style

Reliability

Discovery

Service Registry



Self Registration


External API

API Gateway


Service

Client

10.1.2.1:4545

10.1.2.3:2182

10.1.2.5:3279

MicroserviceMicroservice

Microservice

MicroserviceMicroservice

Microservice

신규 서비스 생성시 Service End Point ?

IP and Port

Physical Server(Config) vs

VM, Cloud, Container

Service Auto-Scaling- 서비스의 동적인

생성, 추가, 삭제

?

Client-Side Discovery

10.1.2.1:4545

10.1.2.3:2182

10.1.2.5:3279

Microservice

Microservice

Microservice

Service

Registry

1 2

3

Query

Load Balance

Request

Register

Registry-

aware

Service

Client

장점 Network Hop H/W 없이 S/W로

LoadBalancing LB Logic을

커스터마이징 가능

단점 Discovery Logic

개발 필요

Ex) Netflix Ribbon

Server-Side Discovery

Service

Client

10.1.2.1:4545

10.1.2.3:2182

10.1.2.5:3279

Microservice

Microservice

Microservice

Service

Registry

1

2 3

LOAD

BALANCER

4

Query

Request

Register

장점 Client 변경 불필요

- Client DiscoveryLogic 불필요

단점 네트워크 홈 증가

Ex) k8s, Marathon

Self Registration

Microservice

Microservice

Service

Registry

When going

up/down

When going

up/down

Third Party Registration

Microservice

Microservice

Service

Registry

starts service

detects service crash

Microservice Service Managerstop service

장단점- 서비스의 상태를 제일 잘 알고 있다.

(UP/DOWN 뿐만 아니라, Starting, Available....)

- 직접 서비스에 구현해야 한다.

장단점- 직접 구현하지 않기 때문에 Service Code 단순- 서비스 health Check를 대신해준다.- UP/Down밖에 모른다.

Request를 처리할 수 있는지 없는지 모를 수 있음ex) k8s, Marathon, Netflix Prana…

API gateway

ClientTraditional Server-

side Web Applicaiton

API Gateway

Microservice

(REST)

Microservice

(AMQP)

Microservice

(REST)

ClientBrowser/Native App

Client Specific

APIs

Single Entry

Point

(Proxy/Route)

Protocol

Translation

Messaging

RPI (IPC)

Circuit Breaker

Inter Process Call (RMI) Enable internal communication between microservices Provide high performance interactions between large number of microservices

XML/JSON Over HTTP Binary Over Wire

Primary UseCommunicating with clients over the public internet

Communicating with other microservices over a private network

Pros

Universally understood format

Easy to implement and understand

Very fast

Cons Slow since it’s text-based Can be hard to implement

Implementations

No special software required –natively supported by all major programming languages

HTTP is the language of the web!

Oracle Portable Object Format

Google Protocol Buffers

Apache Avro

Apache Thrift

Problem 하나의 서비스 장애가

연쇄적으로 다른 시스템장애로 전파

Solution 서비스가 문제가 발생하면,

스위치를 내렸다가, 일정시간이 지난 후 테스트Request를 날려서 통과하면그때 서비스를 재개

Ex) Netflix Hystrix

- 10초 동안 50% 이상의 호출에서에러가 발생하면 Circuit Open

- 서비스 호출시 Circuit Breaker가대신해 호출하며, 성공여부에 대한통계정보 산출

Discovery

Service Registry



Self Registration


External API

API Gateway


Communication Style

Reliability

Online Shopping Mall

Order Customer

ID CUSTOMER_ID STATUS TOTAL ID CREDIT_LIMIT …….

Order Table Customer Table

BEGIN TRANSACTION… SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ? … SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ?…

INSERT INTO ORDERS …… COMMIT TRANSACTION

Traditional

First Challenge - ACID

User Interface

Application

Datastore

Infrastructure

One Application

Transaction

Consistency across multiple services

Order Customer

API

Application

Datastore

Infrastructure

OrderMicroservice

API

Application

Datastore

Infrastructure

CustomerMicroservice


2-PC (Phase Commit)


Rules of Distributed Computing

ConsistencyEach node shows the same data at all times

AvailabilityEach node is available for writes at all times

Partition ToleranceAble to handle network outages

CAP Theorem

C

A P

Theory Practice

Pick OnePartition Tolerance is non-negotiable because we have networks that can always fail

Enterprise IT Systems: Often CPMicroservice Systems: Often AP

Each microservice can be CP, AP or CA but the system as a whole is always CP or AP

PickAnyTwo

Traditional

Second Challenge - Query

User Interface

Application

Datastore

Infrastructure

One Application

SELECT *

FROM CUSTOMER c, ORDER o

WHERE

c.id = o.ID

AND o.ORDER_TOTAL > 100000

AND o.STATE = 'SHIPPED'

AND c.CREATION_DATE > ?

Join Query

Event Driven Architecture

OrderCustomer

MessageBroker

(Pub/Sub)

Order

Created Event

Order

Created Event

Credit

Reserved

ID CUSTOMER_ID STATUS TOTAL

900 202 NEW 1000

ID CREDIT_LIMIT …….

202 5,000,000

Order TableCustomer Table

CUST_ID ORDER_ID AMOUNT

202 900 1000

Reserved_Credit Table

Credit

Reserved

12

34

Credit Limit

Exceeded

APPROVED

CANCELLED

Eventual Consistency(Async)

Order

Service

Customer

Service

Event Driven Architecture

Message Broker

Customer Order

View Query Service

Customer Created

Customer Cancelled

Customer Shipped

……

Order Created

Order Cancelled

Order Shipped

…..

Customer

Order

View

Update

Find

Customer & OrderQuery

Event Driven Architecture - Example

Profile

WebApp

Message Broker

Database Search AppCache

MonitoringApp

Newsfeed App

Memcached

HBASE/CASSANDRA/RDBMS

ELASTICSEARCH/SOLR

ACCOUNT_ID ACCOUNT_TYPE BALANCE

12345 A 5,000,000

23456 B 250,000

34567 C 3,500,000

… …. ….

Account Table

SEQ ACCOUNT_ID … UPDATE_DATE

1 12345 .. ….

2 23456 … …

3 34567 … …

4

5

Account History Table

입금출금

최종 시점의 상태 정보만을 보관

잔고 정보가 맞지 않는 경우?원인 파악은???

Event Sourcing = 데이터 저장의 새로운 Pattern

Order

event #1 @ T1

event #2 @ T2

event #3 @ T3

event #4 T4

“Capture all changes to an application state as a sequence of events”

”어플리케이션의 모든 상태 변화를순서에 따라 이벤트로 보관한다.

– Martin Fowler

Feature

Immutable

Append Only(No Update/Delete)

Contents

Event ID(Aggregate ID)

Type

Revision

TimeStamp

PayloadOrderCreated

ItemAddedToOrde

OrderShipped

OrderDeliverred

…

…….

Event 속성

OrderCreated

OrderApproved

OrderShipped

OrderDeliverred

…

…….

Event R

epla

y

잔고, 재고량

특정시점의상태정보

OrderCreated

OrderApproved

OrderShipped

OrderDeliverred

…

…….

Snapshot

장점 Event Driven Architecture를 구현하면서 Atomic한 데이터 Publish가

가능 – Event 자체가 Atomic Domain Event(Aggregate) 를 적용함으로써 Object–Relation 의

Impedance Mismatch 문제를 회피 특정 시점의 상태값을 조회할 수 있다.

단점 상대적을 낯선 스타일 – Learning Curve Event Store기반의 쿼리에 한계점으로 인해 CQRS가 필수

적용 분야 예시 추천(장바구니), 분석, 감사 Netflix Download Service License

CQRS (Command Query Responsibility Segregation)

Problem : 최근 일주일간 장바구니 아이템 추가 중간에 주문을 취소한 주문만 조회

Solution- 명령과 조회의 책임을 분리- 상태변경을 처리하는 Command Model과

데이터를 조회하는 Query Model을 분리 구현- 조회에 위한 Materialized View을 미리 생성

API Gateway

MessageBroker

Event Store

CommandProcessor

(Write Logic)

API(Commands)

Event

View Store

MaterializedView

(Read Logic)

API(Query)

Event Projection

Example String Boot Axon F/W

Develop Microserviceapplications using CQRS and Event sourcing patterns in Oracle Cloudhttps://goo.gl/ngvJSJ

Sample Sourcehttps://github.com/DannyKang/msa-cqrs-es

Acceptance Testing Usability Testing Component Testing

Did we build the right thing? Do business requirements make

sense?

Performed manually directly by business

users

Entire system is tested using end-

clients

How usable is the system? Will end-

users like it? Is it fast enough?

Performed manually by business users

Entire system is tested using end-

clients

Does each microservice work in

isolation? Is it fast enough?

Performed automatically with each microservice

release

Each microservice is tested in isolation.

Dependencies stubbed out

Does each fragment of code work in

isolation?

Performed automatically with

each build

Each method, or similar fragment is

captured

Unit Testing

Frequency of Testing

More code, more microservices to test

Monitoring a monolith is relatively easy – one app. Microservices = many apps

Requirements for Monitoring Microservices

1. Monitor throughput, performance, and business metrics

2. Trace each end-request through every microservice – end-to-end

3. Track the health of downstream dependencies

4. Monitor each process, OS, host, etc Dropwizard Metrics

Popular Tooling


Oracle Product


Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 57

Oracle Cloud Platform Application DevelopmentUnique in Blending Traditional, Cloud Native and Low Code with End to End PaaS

Oracle Platform for Cloud Application Development

Compute (Docker, VM, Bare Metal)

COMMON SERVICES Continuous

DeliveryIdentityManagement API

Management

INTEGRATION SERVICES

DATA SERVICES Database NoSQLMySQL Integration SOA

BACK-END SERVICES MobileApplication

ContainerJava

EE

SDKs(3rd Party, JET)

Low Code

FRONT-END TOOLING

Network Storage

Infrastructure as a Service

Internet of Things

• Chris Richardson : http://Micoservice.io

• http://www.slideshare.net/RichardHarvey7/micro-services-and-containers

• Thought Works - Real Case : http://vvgomes.com/microservices-event-sourcing/

• Mastering Chaos : https://www.slideshare.net/JoshEvans2/mastering-chaos-a-netflix-guide-to-microservices

• Service Discovery : https://www.slideshare.net/PLUMgrid/service-discovery-and-registration-in-a-microservices-architecture

the world’s only insight-driven event management …...zuul (proxy svc) playback (legacy dev.) api...

Documents