Microservices를 이용한 클라우드 이행 패턴

1. Microservices Migration Patterns
Armin Balalaie
Department of Computer Engineering, Sharif University of Technology, Tehran, Iran
The corresponding author, armin.balalaie@gmail.com
Abbas Heydarnoori
Department of Computer Engineering, Sharif University of Technology, Tehran, Iran
heydarnoori@sharif.edu
Pooyan Jamshidi
Department of Computing, Imperial College London, London, UK
p.jamshidi@imperial.ac.uk
Technical Report
Automated Software Engineering Group (http://ase.ce.sharif.edu)
Department of Computer Engineering
Sharif University of Technology
October 2015
Citation
A. Balalaie, A. Heydarnoori, P. Jamshidi, Microservices Migration Patterns, Technical Report No. 1, TR-
SUT-CE-ASE-2015-01, Automated Software Engineering Group, Sharif University of Technology, October,
2015 [Available Online at http://ase.ce.sharif.edu/pubs/techreports/TR-SUT-CE- ASE-2015-01- Microservices. pdf]

2. Contents
1 Intro duction ..................................................................................................................................1
2 Pattern Meta-model and Specification Template .....................................................................2
2.1 Pattern Specification Template .....................................................................................................3
3 Migration and Re-architecture Patterns .......................................................................................4
3.1 MP1-Enable the Continuous Integration......................................................................................4
3.2 MP2-Recover the Current Architecture...................................................................................6
3.3 MP3-Decompose the Monolith................................................................................................7
3.4 MP4-Decompose the Monolith Based on Data Ownership......................................................8
3.5 MP5-Change Code Dependency to Service Call ....................................................................9
3.6 MP6-Introduce Service Discovery ............................................................................................11
3.7 MP7-Introduce Service Discovery Client................................................................................12
3.8 MP8-Introduce Internal Load Balancer .................................................................................12
3.9 MP9-Introduce External Load Balancer ................................................................................13
3.10 MP10-Introduce Circuit Breaker...........................................................................................14
3.11 MP11-Introduce Configuration Server ...................................................................................16
3.12 MP12-Introduce Edge Server................................................................................................16
3.13 MP13-Containerize the Services ............................................................................................17
3.14 MP14-Deploy into a Cluster and Orchestrate Containers .....................................................19
3.15 MP15-Monitor the System and Provide Feedback .................................................................20
4 Selecting and Comp osing Migration Patterns ........................................................................21
5 Adding New Patterns to the Rep ository ................................................................................21
References........................................................................................................................................22

3. 1
1 Introduction
Microservices 는 일련의작은서비스들로 소프트웨어시스템을구성하는cloud-native architecture 이다. 각각의서비스들은다른
플랫폼에서독립적으로배포될수있고RESTfull API 같은경량메커니즘을통해서비스간서로통신하면서 자신의프로세스를 실행한다. 이
아키텍처에서 개별서비스는다양한프로그래밍 언어와데이터저장소를가질수있는업무기능이다. [1].
현재의on-premise 시스템에서microservices 로 이행은다음과같은많은이점을제공한다: 시스템의각각다른부분별(=서비스별)로
별도로가용성과확장성관리, 서비스별로다른기술을사용할수있고기술종속성배제, time-to-market 줄이기, 코드베이스에대한더나은
이해등[2]. 게다가, 이행시스템은클라우드환경의탄력성과가격모델을활용할수있으므로최종사용자에게 더나은사용자경험을제공할수
있다[2]. 하지만microservice 가 많은장점이있다고는해도Service Discovery 같은새로운지원기능이필요할정도로시스템이
복잡해진다. 시스템을작은서비스들로분해하고서비스들을모니터링하고 관리하는어려움은microservices 로의 이행을사소하지않고
번거로운작업으로만드는또다른중요한요인이다.
클라우드로의 이행, 특히microservices 와 같은cloud-native architectures 를 통한이행은복잡한문제이고간단한작업이아니다.
[3]. 따라서제대로된방법론이없으면시행착오를거치면서시간낭비를하게될뿐만아니라잘못된솔루션을선택하게된다. 또한, 요구사항.
현재상태, 팀구성원들의기술등과같은변수요인(factor)들을고려하면기업이나시나리오에구분없이유일하고견고한방법론이있을수없다.
따라서만능방법론대신에Situational Method Engineering (SME) 접근법이필요하다.[4]
SME 접근법을향한첫번째단계는재사용가능한프로세스패턴이나이보고서에서이행패턴이라고설계한method chunk 를매서드기반
또는패턴저장소에 채워넣는것이다. 이러한각각의이행패턴은미리정의된메타모델을따라야한다. 이를위해본보고서에서는, 이전의
SME 경험[5]을활용하고이행패턴[6]을정의함으로써microservices 로의 이행경험과최신의유사한microservices 이행패턴[2]을
일반화한다. 이들패턴은단지이행계획(Migration Planning) 단계에만초점을맞출것이다. 해당상황에대한간단한정의, 해결해야할
문제, 제안된솔루션의잠재적문제를추가하는등이행과정각각의단계를보강하였다. 다음으로그것들을패턴템플릿으로변환하여각
부분들이메타모델의요소들과일대일대응이되도록하였다. 이들패턴의각부분에는Service Discovery 처럼 이아키텍처에서왜지원
기능이필요한지그리고도입을위한요건은무엇인지를정확하게기술했다. 또한통짜구조시스템에서서비스들의시스템으로의 분해, 그리고
이행계획을위한로드맵으로써의 시스템의현재와목표아키텍처를정의하는데필요한솔루션과조언을제공한다. 아울러, 서비스의
컨테이너화(containerization)과 클러스터에서서비스를배포하는것에관한정보도제공한다. 패턴을적용한후시스템을안정된상태로
유지하고한번에하나의아키텍처변경을수행하는것은패턴의내용을결정짓는가장중요한요인이다.
적합한패턴저장소를갖게됨으로써, 방법론관리자는선택지침에따라필요한패턴을선택하여그선택된패턴을작성함으로써맞춤식방법론을
완성한다.
본보고서의나머지부분은다음과같다: Section 2 에서는메타 모델과 패턴의 문서화에 사용되는 메타 모델을 준수하는 패턴 요건
템플릿을 제공한다. Section 3 에서는고안된이행패턴을상세하게정교화한다. Section 4 에서는이행패턴선택시선택한패턴을
가지고방법론을만드는과정에대해설명한다. 마지막으로Section 5 에서는현재의패턴저장소에새로운패턴을추가하는절차에대해
설명한다.

4. 2
Figure 1: Meta-mo del
2 Pattern Meta-model and Specification Template
저장소에서효과적으로가져와서쉽게재사용할수있기위해서는, 이행패턴은메타모델(meta-model)을 유지해야한다. 또한메타모델의
존재는표준화된방법으로새로운패턴을정의하는도구를제공하기때문에저장소의확장에기여한다. 이러한목적을위해서는위그림1 에서
제안한메타모델을재사용했다[7]. 이메타모델에서각각의method chunk 는다음과같은부분들로이루어져있다:
• Descriptor : 패턴선택시사용되는것으로이름, ID, 객체(objective), method chunk 의유형등을포함. 그리고method
chunk 의출처가되는방법론이나 체험보고서에대한참조제공. 또한method chunk 가재사용될수있는상황과재사용의목적을
설명
• Body : method chunk 가제안하는솔루션을설명하는프로세스부분과프로세스부분을수행할때생성되어야하는산출물을
설명하는제품부분으로구성.
• Interface : method chunk 가적합한상황과개략적인목적에관한정보를제공
“Situational method engineering: combining assembly-based and roadmap-driven approaches”라는 논문을
보면[8], 프로젝트개발지식프레임, 즉재사용프레임은재사용상황의가치를부각시키기위해제안되었다. 여기서제안한재사용프레임은
microservices 로 이행이라는 이번프로젝트의특정한목적에비해너무일반적이어서 이번경우에는큰도움이되지않는다고판단했다.
따라서우리는이행패턴의재사용이라는 특정한상황에사용할수있는architectural factor 와operational factor 를 제안했다.
표1 에이요인(factor)들에 대해간략히기술해놓았다. Reuse Intention 에 대해서는“Goal formalisation and
classification for requirements engineering”[9] 에서제안한동사절과목적표현의대상을사용하는언어적접근법을사용했다.
이행패턴을좀더적합하게만들기위해메타모델을약간수정했다. 먼저, method chunk 클래스이름을이행패턴으로바꿨다. 두번째로,
0 또는그이상의Challenges 를 추가함으로써descriptor 를 보강했다. 각이행패턴이시스템에변경을가져오는원인이되고그
변경사항이부작용이나문제를유발할수있기때문에이문제들을패턴선택의결정요인으로포함시켰다. 세번째로, 이행패턴의일부는새로운

5. 3
지원기능(component)을 도입하는것과관련되거나실제로이미구현된내용을인식하기위한도구가필요하다. 결과적으로, 이행패턴의
body 에Technology Stack 클래스를추가하였다.
Table 1: Migration pattern selection factors
Factor Description
Architectural
Factors
Scalability 서비스를수평확장(scale-out)함으로써 어플리케이션의 확장성증가
High Availability 서비스를복제함으로써어플리케이션의 가용성증가
Fault Tolerance 어플리케이션 장애발생의기회를줄이고장애를효과적으로처리할수있는방법을제공
Modifiability 최소한의부작용과최종사용자에게 영향을미치지않고어플리케이션의 변경을가능하게함
Polyglot-ness 어플리케이션이 다른프로그래밍언어와데이터저장소를가질수이게함
Decomp osition 어플리케이션을 일련의서비스로나누는재구조화(Re-architecting)
Understanding 어플리케이션의 현재상태인지
Visioning 이행후어플리케이션의 최종상태결정
Operational
Factors
Dynamicity 최종사용자에게 영향을주지않고도어플리케이션을 실행중에변경할수있음
Resource-efficiency 어플리케이션 배포에필요한자원양의감소
Deployment 어플리케이션 배포절차를촉진하고배포시예외사항제거
Monitoring 실행시에도어플리케이션을 효과적으로모니터링할수있음
2.1 Pattern Specification Template
개별이행패턴은각각의패턴템플릿(pattern template)에문서화된다. 패턴의제목은"-"를사용하여ID 와 이름을조합한다. 패턴의
유형에는atomic 과aggregate 이 있다. Section 3 에서볼수있듯이, 패턴템플릿에있는대부분의파트이름은meta-model 에
이름과똑같다. 그럼에도불구하고다음과같은예외들이있다:
• 패턴의인터페이스에서는Situation 대신에Context 라는단어를사용한다.
• Intention 라는단어는질문형에서패턴의의도(목적)을의미하기때문에Problem 으로대체한다.
• Solution 부분은Process Part 와Product Part 를합친것을대체하였다.
• References 부분은Origins 와Experience Reports 의조합이다.
• objective 부분은Reuse Intention 에서중복되기때문에삭제되었다.

6. 4
3 Migrationand Re-architecture Patterns
3.1 MP1-Enable the Continuous Integration
Type atomic
Reuse Intention Build the Continuous Integration pipeline
Reuse Situation Deployment
Context
Microservices 로이행하기위한소프트웨어시스템이있고그것을개발/운영하는팀이실제로존재한다.
Figure 2: MP1-Enable the Continuous Integration
Problem
microservices 를도입함으로써많은수의서비스가늘어나면, 어떻게항상운영가능하도록준비되어있게할수있고, 어떻게해야
Continuous Delivery 를도입할수있도록시스템을준비할수있을까?
Solution
Continuous Delivery 를 위한첫번째단계는Continuous Integration [?]를 달성하는 것이다. Continuous
Integration 는 빌드와테스트절차를자동화하여언제든지운영가능하도록할수있게해준다. 대개, Continuous Integration
pipeline 에는 code repository, artifact repository, Continuous Integration server 가 포함되어있다. 첫째로, 개별
서비스는좀더분명한이력을관리하고각자의빌드라이프사이클을명확히할수있도록분리된repository 에있어야한다. 다음으로, 이
개별서비스를 위한 Continuous Integration job 이생성되어서비스의 code repository 가 변경될 때마다이job 이자동으로
실행되어야 한다. 이job 은repository 에서새로운코드를가져오고, 새로운코드에 대해테스트를 수행하고, 이에상응하는결과물을
만들어서 이것들을artifact repository 에 넣어줘야 한다. 이러한 작업들 중 하나라도 실패하면 그 job 의실행을종료하고 관련 팀에
오류에 대해 알려야 한다. 오류를전달받은 팀은그오류가 해결될때까지는 아무작업을 수행해서는 안된다. Continuous
Integration 의 단순한원칙 하나는새로운변경사항은시스템의 안정성을깨뜨릴수있으므로 미리정의된모든테스트를 수행해야한다는
것이다.
Technology Stack
Gitlab, Artifactory, Nexus, Jenkins, GoCD, Travis, Bamboo, Teamcity
References

7. 5

8. 6
3.2 MP2-Recover the Current Architecture
Type atomic
Reuse Intention Create Migration Plan initial state
Reuse Situation Understanding
Context
현재운영하는소프트웨어시스템이있으며, 그것을개발/운영하는팀은이시스템을microservices 로 이행하기로결정하였다. 이행 계획을
세우기 위해그팀은현재의시스템 아키텍처가 있는지 아니면아키텍처를 폐기하는 게나은지를 알아야한다.
Problem
시스템의청사진(big picture)은무엇인가? microservices 로의 이행계획에 필요한high-level 정보는충분히있는가?
Figure 3: MP2-Recover the Current Architecture
Solution
보통소프트웨어아키텍처를얘기할때, 사람들은흔히한다발의다이어그램을 생각한다. 그러나실제로는, 유용한소프트웨어 아키텍처는
텍스트또는시각적인공물을통해전달되는 시스템의중요한요소들의집합이다. 이러한인공물(산출물)를 가급적단순하게유지함으로써
모두가쉽게이해하고약간의지식만으로도쉽게사용할수있도록하는것이좋다. 아래항목들은microservices 로의 이행계획에서 매우
중요한것들이다:
• Component and Service Architecture:
Using these two types of architecture together is not accidental. 실제로, 모든사람들이한번만보고서
시스템의내부구조를쉽게이해할수있도록이아키텍처들을 시각화하여설명하는것이더좋다. 서비스호출방향표시는서비스
공급자와서비스소비자(사용자)를 구분해주기때문에중요하다. 또한시스템의역동성에대한단서를제공하기도 한다.
개체와전반적인비즈니스로직을고려하여각구성요소의내부도메인을이해하려고시도하라. 특정구성요소를 책임지는 개발자와 함께
이들항목에 대해논의하여 추가상세 사항을식별한다. 시스템을작은서비스들로쪼개기위해서는시스템의도메인을이해하는것이
중요하다.
• Technology Architecture:
현재의technology stack 을이해하는것이 중요한데, 왜냐하면 팀이이행을 쉽게할수있는기존라이브러리들 식별할 수

9. 7
있도록 도와주기 때문이다. 새로운 라이브러리에는 1)microservices 에서 자바용 service discovery 와 같은 현재의
technology stack 과 잘 작동하도록하는 지원 기능뿐만 아니라, 2) 데이터 이행 도구와 같은 비 아키텍처적인 지원을
쉽게하는 것을 모두 포함하고 있다. 프로젝트에 사용된프로그래밍언어, 데이터베이스 기술, 미들웨어 기술과타사라이브러리들을
하나하나열거한다.
• Deployment Architecture and Procedure:
microservices 는 소프트웨어배포영역에서일어나는급진적인 변화인Continuous Delivery 와 밀접한관련이있다. 현재의
배포 구조와 절차를 이해하게 되면 점차 Continuous Delivery 로 이동하는데도움이된다. 따라서, 조만간에변하게될모든
세부사항을문서화하지마라. 시간낭비일뿐이다. 개발자와 운영팀을시스템 아키텍처를 이해하는과정에 함께참여시킨다. 그렇게하는
것이시간절약도 되고나머지 이행과정에필요하다. 이런식으로시스템에 대한 공통된 이해가확립될 것이다. 이정보들이
팀원들의의식속에쌓여구두로전달되므로읽지도않는아키텍처문서보다도훨씬유용하다. 또한, 개발자와운영자간의협업을위한
좋은분위기가구축되어DevOps 정신에대한좋은출발이될수있다.
이들산출물을 한곳에 담아팀의모든 구성원들이 볼수있게 한다. 시스템에 대한중요한 상세내용이드러날 수있도록 자유롭게 코멘트를
달수있게 한다.
References
3.3 MP3-Decompose the Monolith
Figure 4: MP3-Decom pose the Monolith
Type atomic
Reuse Intention Re-architect a System to a set of services using Domain-driven Design
Reuse Situation Polyglot-ness, Decomposition, Modifiability
Context
다음과같은특성중적어도하나에해당하는복잡한도메인을갖고있는통짜구조(monolithic) 소프트웨어 시스템이있다:
• 시스템이너무복잡해서소스코드에대한이해도가낮다.
• 시스템의영역별로각기다른비기능적요건을갖는다.(예, 확장성)

10. 8
• 시스템 변경이 일어날 때마다 전체를 재배포해야하며, 변경 빈도의 측면에서 시스템의 모든 영역이 다 똑같지는 않다.
Problem
시스템을더작은단위로어떻게분해할수있을까? 이단위들은어느정도로커야하는가?
Solution
시스템이운영하는비즈니스의하위도메인(영역)을 식별하기위해서는Domain-Driven Design (DDD) 기법이사용된다. 그 다음 이
하위 도메인들이 각기 배포가능한 단위인 Bounded Context (BC)를구성한다. 하위 도메인과 BC 간의 1:1 대응은 아무
제약없는 프로젝트(greenfield project)에서나 가능하다. 오히려기존시스템의제약사항때문에항상가능한것은아니다. 그럼에도
불구하고후보시스템(=이행 후시스템)은microservices 의 이점을누릴수있을것이므로개발/운영팀은시스템을greedfield
project 처럼이행할것을강력권고한다. 이런유형의계획은시스템에많은변화를가져오는것은사실이지만이행이가장유용하게되는
방법이기도하다. 점진적으로계획을수행하는것은또다른문제이며, 우선은이행팀이바람직한목표를가져야나중에이행후에비즈니스에
도움이될수있다.
DDD 는 시스템의초기분해에좋은선택지이다. BC 의다른부분에대한다른변경빈도비율또는다른비기능요구사항의결과로추가
분해가발생할수있다. 또한DDD 를하위도메인에적용하여작은도메인단위로분해할수있다
BC 의크기는문제가아니라, 전적으로시스템요구사항에따를뿐이다. 처음에는처리하고자 하는도메인의크기만큼클수있다. 시간이
지나면서요구사항이바뀌어서이전의영역이나BC 크기가더이상적절하지않게될수도있다. 따라서처음에는2~3 개의적은수의서비스로
시작해서시스템이더커지고관리팀이microservices 와 시스템요구사항을 더잘이해하게된다음에서비스들을추가하는게좋다.
Challenges
시스템분해를잘못하게되면chatty service 나 이행과정에서팀이미해결문제를남겨놓을수있기때문에성능저하문제로이어질수있다.
References
3.4 MP4-Decompose the Monolith Based on Data Ownership
Type atomic
Reuse Intention Re-architect a System to a set of services using Data Ownership
Reuse Situation Polyglot-ness, Decomposition, Modifiability
Context
다음과같은특성중적어도하나에해당하는복잡한도메인을갖고있는통짜구조(monolithic) 소프트웨어 시스템이있다:
• 시스템이너무복잡해서소스코드에대한이해도가낮다.
• 시스템의영역별로각기다른비기능적요건을갖는다.(예, 확장성)
• 시스템 변경이 일어날 때마다 전체를 재배포해야하며, 변경 빈도의 측면에서 시스템의 모든 영역이 다 똑같지는 않다.

11. 9
Figure 5: MP4-Decom pose the Monolith Based on Data Ownership
Problem
시스템을더작은단위로어떻게분해할수있을까? 이단위들은어느정도로커야하는가?
Solution
데이터의소유권여부에따라서시스템을분해한다. 하나의단위로묶을수있고단일소유자를가지는응집력있는데이터개체의집합을찾는다.
각각의각각의그룹과그것들이지원하는비즈니스로직을서비스로패키지화한다. 개별개체는그서비스를담당하는소유자에의해서만
수정되거나생성될수있다. 다른서비스는자신의소유가아닌개체의복사본만가질수있다. 하지만무상태(stateless)에 관해주의해야하며
적절한방법으로그복사본을동기화해야 한다. 서비스의다른부분에대한서로다른변경빈도비율또는다른비기능요구사항의결과로추가
분해가발생할수있다.
서비스의크기는문제되지않으며, 전적으로시스템에있는개체(entity)에달려있다. 도메인이복잡하지않은시스템이라면 서비스가4~5 개를
넘지는않을것이다.
Challenges
이패턴은시스템의도메인이복잡하지않아서데이터개체를쉽게묶을수있는경우에적합하다. 도메인이매우커서여러개의하위도메인을
갖는경우에이패턴을적용시키면혼란스럽고시간을많이잡아먹어서적절한분해를할수없게될수도있다.
References
3.5 MP5-Change Code Dependency to Service Call
Type atomic
Reuse Intention Transform code-level dependency toservice-level dependency
Reuse Situation Decomposition, Modifiability

12. 10
Figure 6: MP5-Change Code Dependency to Service Call
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으나시스템의어떤구성
요소는여전히다른서비스나구성요소에 의존해서실행되고있다.
Problem
코드수준의의존성을서비스수준으로의존성(service-level dependency)으로 바꾸려면언제가적절한가? 그리고적절하지않은때는
언제인가?
Solution
가능한서비스코드는별도로유지한다. 서비스끼리서로의존적으로코드를공유하게되면(즉, 종속성을유지하면) 개발자가그공유된코드를
변경함으로써 다른서비스의빌드프로세스를망칠위험이커진다. 경우에따라공통라이브러리로공유되는코드(예: 문자열조작라이브러리)는
거의변경되지않아서코드를공유하는것이합리적이다. 그러나내부개체나인터페이스스키마를공유하는것은금지되는데, 왜냐하면그것들을
변경하는순간다른종속된서비스가비록자기는점차적으로변경하고싶어도즉시변경해야하기때문이다. 공유가좋은방법이아닌경우에는
해당기능을서비스로만들어공유하는것도좋은방법이다. 이서비스는완전히격리된서비스이거나종속서비스중의하나의일부일수도있다.
공유라이브러리를 서비스로변경시키는또다른이유는공유라이브러리와 종속서비스사이의확장가능성요구가달라서일수도있다. 이런
경우에는, 서로다른서비스에서분리하여각각서로독립적으로확장될수있도록한다.
Challenges
라이브러리의 종속성을제거하고메서드호출대신서비스호출을사용하는것은때로는성능문제를야기할수도있다. 비록성능문제를캐싱
매커니즘으로 처리할수있다고는해도, 그러면종속된서비스에또다른복잡성추가된다.
References

13. 11
3.6 MP6-Introduce Service Discovery
Figure 7: MP6-Introduce Service Discovery
Type atomic
Reuse Intention Introduce Dynamic Location of services’ instances using Service Discovery
Reuse Situation Scalability, High Availability, Dynamicity, Deployment
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으며, 이들각서비스는운영
환경에하나이상의인스턴스가배포되어있다. 개별서비스의인스턴스의수는동적으로변경될수있으며각각다른시스템에도배포될수있다.
Problem
어떻게서비스가각기동적으로자리를잡을수있을까? Edge Server 나 Load Balancer 는 어떻게트래픽을분산할수있는서비스의
인스턴스목록을알수있을까?
Solution
서비스인스턴스의주소를저장하는Service Discovery 를 설정한다. 개별서비스는초기화되는동안에Registry 에자체등록한다.
인스턴스로부터 주기적인신호가없거나인스턴스가종료될때자동으로해당인스턴스가registry 에서제거된다. Edge Server 와 Load
Balancer 또는다른서비스들은가용한서비스인스턴스의 목록을받아봄으로써 Service Discovery 를 통해자신들이필요로하는
서비스를동적으로찾아낼수있다.
시스템이서로다른부분간의통신은Service Discovery 의 가용성에달려있기때문에일단도입되면Service Discovery 는
시스템의핵심구성요소가된다. 따라서고가용성메커니즘의일환으로복제전략을활용하여야한다.
Challenges
시스템의나머지부분이서로통신할때는이구성요소(Service Discovery)와 연결된다. 따라서, Service Discovery 는정확하게
구축되지않으면single point of failure 가 될수있다.
Technology Stack
Eureka, Consul, Apache Zookeeper, etcd
References

14. 12
3.7 MP7-Introduce Service Discovery Client
Figure 8: MP7-Introduce Service Discovery Client
Type atomic
Reuse Intention Facilitate Dynamic Location of services’ instances using Service Discovery Client
Reuse Situation Scalability, High Availability, Dynamicity, Deployment
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으며, Service
Discovery 도 설정되어있다. 개별서비스의인스턴스의수는동적으로변경될수있으며각각다른시스템에도배포될수있다.
Problem
Service Discovery 는새로운인스턴스가배포되었다는것을어떻게알수있을까? 또한인스턴스가종료되었다는것은어떻게알수있을까?
Solution
개별서비스는Service Discovery 주소를알아야하고초기화되는동안에registry 에자체등록해야한다. 그런다음개별인스턴스에서
registry 로주기적으로신호(heartbeat)를 보내야만그인스턴스를사용가능한인스턴스목록에계속유지한다. 신호를더이상보내지
않거나registry 에인스턴스종료를명시적으로알림으로써인스턴스를종료할수있다.
Challenges
단점은사용중인모든프로그래밍언어에대해클라이언트를설치해야하며잘못설치하면서비스코드가복잡해질수있다.
Technology Stack
Eureka 는서버버전용Java 클라이언트가 설치된Service Discovery 이다.
References
3.8 MP8-Introduce Internal Load Balancer
Type atomic

15. 13
Reuse Intention Introduce Load Balancing between instances of a service using Internal Load Balancer
Reuse Situation Scalability, High Availability, Dynamicity
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으며, Service
Discovery 도 설정되어있다. 운영환경에는수많은서비스인스턴스들이있다. 시스템안에서개별서비스는나머지다른서비스의
클라이언트가 될수있다.
Problem
클라이언트의 조건에따라인스턴스간에어떻게서비스부하의균형을맞출수있을까? 외부load balancer 를 설정하지않고서비스의부하
균형을맞추는방법은무엇인가?
Figure 9: MP8-Introduce Internal Load Balancer
Solution
클라이언트로써의 개별서비스는내부load balancer 를 가지고있어서Service Discovery 로부터 필요한서비스의가용한인스턴스
목록을불러올수있어야한다. 그러면이내부load balancer 는 인스턴스의반응시간같은내부측정기준을사용해서가용한인스턴스들 간의
부하균형을맞출수있게된다.
내부load balancer 는 외부load balancer 를 설정하는부담을없애고서비스의다른클라이언트에서 서로다른부하분산메커니즘을
사용할수있도록해준다.
Challenges
단점은Service Discovery 와 통합될수있는사용중인여러프로그래밍언어용내부load balancer 를생성해야한다는것이다. 또한
부하분산메커니즘은중앙집중화되지 않는다.
Technology Stack
Ribbon 은 Service Discovery 인 Eureka 와잘맞는Java 용 내부load balancer 이다.
References
3.9 MP9-Introduce External Load Balancer

16. 14
Type atomic
Reuse Intention Introduce Load Balancing between instances of a service using External Load Balancer
Reuse Situation Scalability, High Availability, Dynamicity
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으며, Service
Discovery 도 설정되어있다. 운영환경에는수많은서비스인스턴스들이있다시스템안에서개별서비스는나머지다른서비스의
클라이언트가 될수있다.
Problem
어떻게하면서비스코드를최소한으로변경하고도 인스턴스간의서비스부하를분산시킬수있을까? 모든서비스에대해어떻게하면
중앙집중화된 부하분산을할수있을까?
Figure 10: MP9-Introduce External Load Balancer
Solution
외부load balancer 는 Service Discovery 에서 가용한인스턴스의목록을가져와서서비스의인스턴스간에부하를분산시키기 위한
중앙집중화된 알고리즘을사용할수있도록설정되어야한다. 이load balancer 는 proxy 로기능할수도있고(비추천) 아니면인스턴스
주소지정자(instance address locator)로 기능할수도있다. 또다른솔루션은부하분산을위한지원기능이내장되어있어서부하가
분산된주소지정자(load balanced address locator) 역할을할수있는Service Discovery 를 선택하는것이다.
Challenges
단점은인스턴스의반응시간같은내부의측정기준이부하분산을향상시키는 데사용될수없다는것이다. 더군다나다른클라이언트는 다른부하
분산전략을별도로가져갈수없다. 또한load balancer 가 proxy 로써기능하려면 고가용성부하분산클러스터가필요하다.(high
available load balancing cluster)
Technology Stack
Amazon ELB, Nginx, HAProxy, Eureka
References
3.10 MP10-Introduce Circuit Breaker

17. 15
Figure 11: MP10-Introduce Circuit Breaker
Type atomic
Reuse Intention Introduce Fault Tolerance in inter-service communication using Circuit Breaker
Reuse Situation Fault Tolerance, High Availability
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있다. 최종사용자요청사항의
일부는시스템내부에서서비스간의통신이필요하다.
Problem
사용할수없는서비스를호출했을때빨리실패하게하여서비스호출이시간제한(time-out)에 걸릴때까지기다리지않도록하는방법은
무엇인가? 사용할수없는서비스를호출했을경우서비스를대신하여합리적인반응을내보내시스템탄력성을더강하게만들수있는방법은
무엇인가?
Solution
서비스소비자(service consumer)가 서비스공급자(service provider)를 호출할때는Circuit Breaker [10]를쓰도록한다.
서비스공급자가사용가능한상태인경우에는이Circuit Breaker 는아무것도안하면된다(Close Circuit state). Circuit
Breaker 는 서비스공급자로부터 오는반응을계속모니터링하여 반응실패횟수가미리정의한문턱값을넘어섰을때적절하게대응할
것이다(Open Circuit state). 대응조치로는의미있는응답코드나예외를반환해주기, 호출자에게서비스공급자가캐싱해두었던최신
데이터를반환하기등이있다. 시간제한이후에는서비스공급자가사용가능한지 여부를확인하기위해서Circuit Breaker 는 서비스
공급자에게다시접속해보고(Half-open Circuit state), 접속이성공적으로이루어지면서비스상태를Close Circuit 으로바꾸게된다.
그렇지않으면상태는Open Circuit 으로변경된다.
Challenges
Open Circuit 상태에서적절한응답을인식하는것은다소어려울수있으며업무관계자들의협조를얻어야한다. 더구나만약응답이단순한
예외가아닌경우에는, 서비스공급자팀(=해당서비스의개발/운영팀)은대신응답을반환가능성을확인해야한다.
Technology Stack
Hystrix

18. 16
References
3.11 MP11-Introduce Configuration Server
Figure 12: MP11-Introduce Configuration Server
Type atomic
Reuse Intention Change a system’s configuration at runtime using Configuration Server
Reuse Situation Modifiability, Dynamicity, Deployment
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있으며, 운영환경에는수많은
서비스인스턴스들이있다. 사용가능한인스턴스목록은Service Discovery 를 통해제공된다.
Problem
실행중인인스턴스구성을재배포하지 않고수정하는방법은무엇인가?
Solution
소스코드와소프트웨어설정사항을각각저장할두개의분리된저장소가별도로있어야한다. 비록설정key 에변경이일어나이두저장소를
동기화할필요가있다고하더라도이둘은각각독립적으로관리되어야한다. 또한설정저장소(configuration repository)에 변경사항이
발생하면이를기준으로실행되는인스턴스에전파되어야하며인스턴스는그에따라스스로적응해야한다.
Challenges
서비스내에서설정정보전파의종착점(endpoint)과 사용중인모든프로그래밍 언어에대해적응전략을구현해야한다.
Technology Stack
Spring Config Server, Archaius
References
3.12 MP12-Introduce Edge Server

19. 17
Figure 13: MP12-Intro duce Edge Server
Type atomic
Reuse Intention Enable Dynamic Re-routing of external requests to internal services using Edge Server
Reuse Situation Modifiability, Dynamicity
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있다. 시스템내부에서서비스의
초기화가쉽기때문에새로운서비스를쉽게도입할수있고, 기존의서비스도새로운요구사항에 맞게재구성(re-architect)될 수있다.
Problem
어떻게하면최종사용자에게 서비스의복잡한내부구조나그변화를안보이게할수있을까? 운영계의서비스사용량과전반적인상태를
모니터링할수있는방법은무엇인가?
Solution
시스템의출입문역할을하는간접적인층을하나더두어야한다. 이층은미리정의된설정사항에따라서동적인배분역할을한다. 들어오는
트래픽을배분하기위한서비스인스턴스의주소는하드코딩하여고정시키거나Service Discovery 에서 가져올수있다. 최종사용자는이
층과만인터페이스하게되므로, 내부의구조가변경되어도최종사용자에게는 영향을주지않고새로운배분규칙을통해처리된다. 또한모든
트래픽이이층을통과하기때문에서비스의전반적인사용현황을모니터링하기에는 최적의장소이다.
Challenges
모든트래픽이이층을통과하므로단일실패지점(single-point-of-failure)를 없애기위해서는이층은부하분산메커니즘을 통해복제되어야
한다.
Technology Stack
Zuul
References
3.13 MP13-Containerize the Services

20. 18
Figure 14: MP13-Containerize the Services
Type atomic
Reuse Intention Have the same behavior in development and production environment using
Containerization
Reuse Situation Resource-efficiency, Deployment
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있고, Continuous
Integration pipeline 이 구축되어작동중이다. 각서비스는수작업이나설정관리도구를통해정의되어올바르게작동할수있는특정
환경을필요로한다. 개발환경과운영환경간의차이때문에같은코드라도이두환경에서서로다른결과를초래하는것과같은문제를야기하게
된다. 무엇보다도, 운영환경에서이렇게많은서비스를배포하는것은번거롭거나복잡한작업이되어버렸다.
Problem
어떻게하면개발환경에서든 운영환경에서든 같은코드가같은결과를가져오게할수있을까? 설정관리도구의복잡성이나수작업배포의
어려움을없앨방법은무엇인가?
Solution
각서비스마다서로배포환경이다를수있으므로, 솔루션은격리된가상기계에서각서비스를개별적으로배포하고설정관리도구를이용해서
필요한환경을제공할수있다. 단점은, 가상화로인해서비스격리에많은자원이낭비되고설정관리는그렇잖아도 복잡한배포에층을하나더
얹게된다는것이다. 가상화와비교해볼때, Containerization 이 더경량이고중앙저장소에는여러다른어플리케이션을 포함하는다량의
준비된이미지가있어서설정관리도구가필요없게되고, 새로운이미지구성단계(building stage)에서추가로설정할수있다.
그러기위해서는Continuous Integration pipeline 에 단계를하나추가해서컨테이너이미지를구성(build)하고 그이미지를개별
이미지저장소에저장할수있도록한다. 그다음에, 같은기능을수행하도록이이미지들을운영환경과개발환경에서실행시킨다. 각서비스는
자신의컨테이너이미지생성설정정보뿐만아니라코드저장소에있는다른필수서비스컨테이너를실행하기위한스크립트를 가지고있어야
한다.
소프트웨어설정정보를활성화시키기 위한우선순위소스로환경변수를추가하는것도좋다. 이러한방식으로다른환경에서서로다른값을
가질수있는설정키(예: 데이터베이스 URL 또는자격증명)을제공하며, 이키들은컨테이너생성단계에서쉽게삽입할수있다. 코드
저장소에있는서비스를실행하기위한환경변수들의목록을관리하는것이좋으며그럼으로써누구나변수의변화를감지할수있게된다.

21. 19
Challenges
경량이고격리되어있고재생산가능한환경에유리한OS 에직접배포하는방식과비교해봤을때Containerization 은 컴퓨팅자원의
과소비이다. 또한컨테이너를수용할수있도록개발환경도변경해야한다.
Technology Stack
Docker
References
3.14 MP14-Deploy into a Cluster and Orchestrate Containers
Figure 15: MP14-Cluster Management and Container Orchestration
Type atomic
Reuse Intention Deploy service instances’ container images in a cluster using cluster managem ent tools
Reuse Situation Resource-efficiency, Deployment
Context
소프트웨어시스템은microservices 아키텍처스타일을사용할수있도록일련의작은서비스들로 분해되어있고, Continuous
Integration pipeline 이 구축되어작동중이다. 그러므로운영계에배포가능한컨테이너이미지가각서비스의배포에사용될수있다. 또한
서비스숫자가많아서배포와재배포가복잡하고번거로우며관리하기어렵다.
Problem
서비스의인스턴스를클러스터에배포하는방법은무엇인가? 어떻게하면최소의노력으로모든서비스의배포와재배포를조율할수있는가?
Solution
컴퓨팅노드의클러스터를관리할수있는시스템이필요하다. 이관리시스템은필요에따라특정개수의인스턴스나여러다른노드에서비스
컨테이너이미지를배포할수있어야한다. 게다가인스턴스의장애를처리하고경우에따라서는장애난노드나인스턴스를재시작해야한다. 뿐만
아니라서비스를자동확장(auto-scaling)할 수있는수단도제공해야한다. Service Discovery 같은일부서비스는IP 주소대신

22. 20
이름으로식별되어야하므로내부(서비스)이름 확인전략을사용하는것이좋다.
배포절차를효과적으로조율하기위해서, 클러스터관리도구는서비스의배포아키텍처를 명시적으로정의할수있는수단을제공해야한다.
명시적인배포아키텍처를갖게함으로써, 자동확장이나서비스장애관리같은배포를위한노력들은클러스터관리도구로위임되어야한다.
Challenges
None
Technology Stack
Mesos+Marathon, Kubernetes
References
3.15 MP15-Monitor the System and Provide Feedback
Type atomic
Reuse Intention Monitor the running services’ instances and Provide feeback to the development team
Reuse Situation Monitoring, Modifiability
Context
Microservices architecture 스타일로소프트웨어시스템이구축되었다. 전체시스템은운영계의개별서비스가여러개의인스턴스를갖는
컨테이너클러스터에서실행되고있다.
Problem
Infrastructure 는 어떻게모니터링할것인가? 수집된데이터로개발팀에피드백을제공하여시스템을재구성(re-architect)하는 방법은
무엇인가?
Solution
개별서비스는해당서비스관리팀의운영(Ops) 파트가직접관리하는독립된모니터링기능을갖고있어야한다. 이기능에는CPU 와RAM
사용량과같은모니터링정보를수집하여모니터링서버에보내는역할을하는구성요소가포함되어야한다. 그러므로각서비스컨테이너이미지에
다음과같은구성요소들이추가하여컨테이너이미지생성또는실제컨테이너생성시에설정해야한다. 그런다음, 모니터링서버에서이정보들을
구문분석하고구조화된정보형태로집계한뒤인덱싱서버같이효율적으로쿼리할수있는곳에저장해야한다. 모니터링정보를적시에집계할
수있는풀을갖게되면, 시스템의전반적인상태를파악하는데 가상화도구를사용할수있다. 이모니터링정보는서비스관리팀의개발(Dev)
파트가성능병목현상이나기타이상현상을제거하기위해아키텍처를리팩토링하는 데도움을준다.
Challenges
None
Technology Stack
Collectd + Logstash + ElasticSearch + Kibana
References

23. 21
Figure 16: The process of selecting patterns, instantiating and composing a migration plan as well as
extending the repository
4 Selecting and Composing Migration Patterns
이행패턴의초기버전이있으면, 방법론관리자는현재진행중이이행프로젝트에서 간편하게새로운이행계획을수립할수있다. 이행패턴을
선택하고작성하는전반적인프로세스가그림16 에나와있다. 먼저, 방법론관리자는이행의동인과요구사항을식별해야한다. 다음으로,
식별된요구사항을이행패턴표1 에서 설명한선택요인(factor)와 맞춰본다. 각각관련선택요인을기반으로방법론관리자는, 이행패턴의
초기버전에서제공하는핵심개념과특히Reuse Intention 과 사용시관련문제점등을고려하여가장적합한패턴을선택함으로써 일련의
이행패턴을도출할수있다.
각각의패턴을사용하는맥락(Context)을 확인하는것도좋다. 앞서언급한절차를수행한다음에는, 방법론관리자는일련의패턴들을선택하여
이행계획을구성함으로써이행패턴선정절차를끝내게된다. 요약하자면, 다형성(polyglot-ness)에 대한필요에따라서방법론관리자는
분해패턴을찾게되고, 그다음에프로젝트도메인의복잡성에따라서가장적합한패턴을선택한다.
저장소에서적합한이행패턴을선택한다음에는, 방법론관리자는요구사항과 프로젝트상황, 제약사항(예, 시간, 인적/물적예산등)에따라서
선택된패턴을작성한다. 예를들어, 필요한기능을개발하는일정이빡빡하고확장성이우선순위가아니라면, Configuration Server 와
Clusterization 을 이행의마지막단계로연기할수있다.
5 Adding New Patterns to the Repository
Microservices 가 아직성숙되지않았고, 또새로운도메인도최근에야microservices 를 고려하기시작했기때문에패턴의완성도는아직
보장할수없다. 대신, microservices 로 이행하는새로운경험을통해일반화된새로운이행패턴을추가함으로써 패턴저장소를확장할수

24. 22
있는수단이있어야한다. 패턴을정의할때메타모델, 몇몇선택요인, 그리고패턴의내용(granularity)를 결정하는요인들을제공함으로써
체계적으로접근할수있기때문에새로운경험이메타모델에부합하고수용가능한내용인경우에는저장소를더강화할수있게된다. 게다가
새로운선택요인이필요하면현재의선택요인에추가할수도있다.
References
[1] M. Fowler and J. Lewis, “Microservices.” http://martinfowler.com/articles/microservices.html,
March 2014. [Last accessed 3-October-2015].
[2] A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Migrating to cloud-native architectures using microser-
vices: An experience report,” in 1st International Workshop on Cloud Adoption and Migration (Cloud-
Way, (Taormina, Italy), September 2015.
[3] P. Jamshidi, A. Ahmad, and C. Pahl, “Cloud migration research: A systematic review,” IEEE Trans-
actions on Cloud Computing, vol. 1, pp. 142–157, July 2013.
[4] B. Henderson-Sellers, J. Ralyt, P. Agerfalk, and M. Rossi, Situational Method Engineering. Springer-
Verlag Berlin Heidelberg, 2014.
[5] M. Gholami, M. Sharifi, and P. Jamshidi, “Enhancing the open process framework with service-oriented
method fragments,” Software & Systems Modeling, vol. 13, no. 1, pp. 361–390, 2014.
[6] P. Jamshidi, C. Pahl, S. Chinenyeze, and X. Liu, “Cloud migration patterns: A multi-cloud architectural
perspective,” in 10th International Workshop on Engineering Service-Oriented Applications (WESOA),
2014.
[7] B. Henderson-Sellers, C. Gonzalez-Perez, and J. Ralyte, “Comparison of method chunks and method
fragments for situational method engineering,” in 19th Australian Conference on Software Engineering
(ASWEC), pp. 479–488, March 2008.
[8] I. Mirbel and J. Ralyt, “Situational method engineering: combining assembly-based and roadmap-driven
approaches,” Requirements Engineering, vol. 11, no. 1, pp. 58–78, 2006.
[9] N. Prat, “Goal formalisation and classification for requirements engineering,” in Requirements
Engineering: Foundation for Software Quality, (Spain), p. 1, 1997.
[10] M. Nygard, Release It!: Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2007.