Chris Richardson의 Microservice Pattern을 통해서 Microservice를 구현하면서 당면하는 문제 전체를 조망

2. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
A Pattern Language of Microservice
마이크로 서비스 구현을 위한 다양한 패턴
Inho Kang
Principal Sales Consultant
Infrastructure, Cloud Platform
August 30, 2017
Confidential – Oracle Internal/Restricted/Highly Restricted

3. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
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

4. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Program Agenda
History of Pattern Language
Microservice Patterns
Oracle Products
Wrap Up
1
2
3
4
Confidential – Oracle Internal/Restricted/Highly Restricted 4

5. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Pattern Language & Microservice
Confidential – Oracle Internal/Restricted/Highly Restricted 5

6. ‘패턴언어(Pattern Language)’는 건축가 Christopher Alexander가 집이나 마을을 설계할 때 반복적으로
활용하면 좋을, 작은 단위의 설계 패턴들을 모아 정리한 것에서 시작되었다. – 1977년 출간
고양이가 앉아 쉴 수 있는 작은 공간에 대한 패턴
Reference : https://goo.gl/8JguXf
반복되어 사용되는 유용한 패턴을 체계적으로
구조화하여 정리하는 방법이 패턴 언어이다

7. • Name : 패턴명
• Context : 문제 상황
• Problem : 문제
• Solution : 해결 방안
• Consequences : 장 단점
‘패턴언어(Pattern Language)’는 건축가 Christopher Alexander가 집이나 마을을 설계할 때 반복적으로
활용하면 좋을, 작은 단위의 설계 패턴들을 모아 정리한 것에서 시작되었다. – 1977년 출간

8. ‘패턴언어(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)"은 독립적으로 배포 가능한
서비스들의 묶음으로 소프트

9. Middleware/App Server
Transactions/Synchronous API Calls/Asynchronous
Monolith Problem : 1. Scaling 2. Performance 3. Deploy 4. Down

10. Micro Services
A 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

11. Micro Services
A collection of smaller applications all working together to deliver a
total experience to the end user.
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

12. Micro Services
A collection of smaller applications all working together to deliver a
total experience to the end user.
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

13. User Interface
Application
Datastore
Infrastructure
Resulting SoftwareTypical Enterprise Organization Structure
Head of IT
Head of
Operation
Head of DBAs
Head of
Infrastructure
Head of App
Dev
Head of UI
Head of
Development
An Enormous Monolith
Conway’s Law: Software reflects the structure of the
organization that produced it

14. 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 DBA
JavaScript
Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript
Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript
Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript
Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin

15. Edge
Load
Balancer
Zuul
(Proxy Svc)
Playback
(Legacy Dev.)
API
(g/w)
Middle Tier & Platform
EVCache
Cassandra

16. 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 microservices
because 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

17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Microservice Pattern
Confidential – Oracle Internal/Restricted/Highly Restricted 17

18. Reference: http://microservices.io
http://microservices.io
 Patterns of Microserivce

19. Reference: http://microservices.io

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

21. 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
microservices
themselves

22.  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

23.  Discovery
 Service Registry
 Server-side discovery
 Client-side discovery
 Self Registration
 3rd Party Registration
 External API
 API Gateway
 Backend for front end

24. Service
Client
10.1.2.1:4545
10.1.2.3:2182
10.1.2.5:3279
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
 신규 서비스 생성시
 Service End Point ?
 IP and Port
 Physical Server(Config)
vs
 VM, Cloud, Container
 Service Auto-Scaling
- 서비스의 동적인
생성, 추가, 삭제
?

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

26. 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 Discovery
Logic 불필요
 단점
 네트워크 홈 증가
 Ex) k8s, Marathon

27. 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 Manager
stop service
 장단점
- 서비스의 상태를 제일 잘 알고 있다.
(UP/DOWN 뿐만 아니라, Starting,
Available....)
- 직접 서비스에 구현해야 한다.
 장단점
- 직접 구현하지 않기 때문에 Service Code 단순
- 서비스 health Check를 대신해준다.
- UP/Down밖에 모른다.
Request를 처리할 수 있는지 없는지 모를 수 있음
ex) k8s, Marathon, Netflix Prana…

28. API gateway
Client
Traditional Server-
side Web Applicaiton
API Gateway
Microservice
(REST)
Microservice
(AMQP)
Microservice
(REST)
Client
Browser/Native App
Client Specific
APIs
Single Entry
Point
(Proxy/Route)
Protocol
Translation

29.  Messaging
 RPI (IPC)
 Circuit Breaker

30.  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 Use
Communicating 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

31.  Problem
 하나의 서비스 장애가
연쇄적으로 다른 시스템
장애로 전파
 Solution
 서비스가 문제가 발생하면,
스위치를 내렸다가, 일정
시간이 지난 후 테스트
Request를 날려서 통과하면
그때 서비스를 재개
 Ex) Netflix Hystrix

32. - 10초 동안 50% 이상의 호출에서
에러가 발생하면 Circuit Open
- 서비스 호출시 Circuit Breaker가
대신해 호출하며, 성공여부에 대한
통계정보 산출

33.  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

35. Online Shopping Mall
Order Customer
ID CUSTOMER_ID STATUS TOTAL ID CREDIT_LIMIT …….
Order Table Customer Table

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

37. Consistency across multiple services
Order Customer
API
Application
Datastore
Infrastructure
Order
Microservice
API
Application
Datastore
Infrastructure
Customer
Microservice
 First Challenge - ACID

38. 2-PC (Phase Commit)
 First Challenge - ACID

39. Rules of Distributed Computing
Consistency
Each node shows the same data at all times
Availability
Each node is available for writes at all times
Partition Tolerance
Able to handle network outages
CAP Theorem
C
A P
Theory Practice
Pick One
Partition Tolerance is non-negotiable because
we have networks that can always fail
Enterprise IT Systems: Often CP
Microservice Systems: Often AP
Each microservice can be CP, AP or CA but the
system as a whole is always CP or AP
Pick
Any
Two

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

41.  Event Driven Architecture
Order
Customer
Message
Broker
(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 Table
Customer Table
CUST_ID ORDER_ID AMOUNT
202 900 1000
Reserved_Credit Table
Credit
Reserved
1
2
3
4
Credit Limit
Exceeded
APPROVED
CANCELLED
Eventual Consistency(Async)

42. 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 & Order Query

43.  Event Driven Architecture - Example
Profile
WebApp
Message Broker
Database Search App
Cache
Monitoring
App
Newsfeed
App
Memcached
HBASE/
CASSANDRA/
RDBMS
ELASTICSEARCH/
SOLR

44. 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
입금
출금
최종 시점의 상태 정보만을 보관
잔고 정보가 맞지 않는 경우?
원인 파악은???

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

46. Feature
 Immutable
 Append Only
(No Update/Delete)
Contents
 Event ID(Aggregate ID)
 Type
 Revision
 TimeStamp
 PayloadOrderCreated
ItemAddedToOrde
OrderShipped
OrderDeliverred
…
…….
Event 속성

47. OrderCreated
OrderApproved
OrderShipped
OrderDeliverred
…
…….
EventReplay
잔고, 재고량
특정시점의
상태정보

48. OrderCreated
OrderApproved
OrderShipped
OrderDeliverred
…
…….
Snapshot

49.  장점
 Event Driven Architecture를 구현하면서 Atomic한 데이터 Publish가
가능 – Event 자체가 Atomic
 Domain Event(Aggregate) 를 적용함으로써 Object–Relation 의
Impedance Mismatch 문제를 회피
 특정 시점의 상태값을 조회할 수 있다.
 단점
 상대적을 낯선 스타일 – Learning Curve
 Event Store기반의 쿼리에 한계점으로 인해 CQRS가 필수
 적용 분야 예시
 추천(장바구니), 분석, 감사
 Netflix Download Service License

50.  CQRS (Command Query Responsibility Segregation)
 Problem :
최근 일주일간 장바구니 아이템 추가 중간에 주문을 취소한 주문만 조회
 Solution
- 명령과 조회의 책임을 분리
- 상태변경을 처리하는 Command Model과
데이터를 조회하는 Query Model을 분리 구현
- 조회에 위한 Materialized View을 미리 생성

51. API Gateway
Message
Broker
Event Store
Command
Processor
(Write Logic)
API(Commands)
Event
View Store
Materialized
View
(Read Logic)
API(Query)
Event Projection

52.  Example
 String Boot
 Axon F/W
 Develop Microservice
applications using CQRS and
Event sourcing patterns in Oracle
Cloud
https://goo.gl/ngvJSJ
 Sample Source
https://github.com/DannyKang/m
sa-cqrs-es

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

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

56. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Oracle Product
Confidential – Oracle Internal/Restricted/Highly Restricted 56

57. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 57
Oracle Cloud Platform Application Development
Unique 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
Delivery
IdentityManagement API
Management
INTEGRATION
SERVICES
DATA
SERVICES Database NoSQLMySQL Integration SOA
BACK-END
SERVICES MobileApplication
Container
Java
EE
SDKs
(3rd Party, JET)
Low Code
FRONT-END
TOOLING
Network Storage
Infrastructure as a Service
Internet of
Things

58. Reference: http://microservices.io

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

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