Microservices Migration Patterns

Armin BalalaieDepartment of Computer Engineering, Sharif University of Technology, Tehran, Iran The corresponding author, armin.balalaie@gmail.com

Abbas HeydarnooriDepartment of Computer Engineering, Sharif University of Technology, Tehran, Iran heydarnoori@sharif.edu

Pooyan JamshidiDepartment of Computing, Imperial College London, London, UKp.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

CitationA. 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]

Contents1 Introduction........................................................................................................................................... 1

2 Pattern Meta-model and Specification Template.........................................................................22.1 Pattern Specification Template............................................................................................................3

3 Migration and Re-architecture Patterns.............................................................................................43.1 MP1-Enable the Continuous Integration............................................................................................4

3.2 MP2-Recover the Current Architecture........................................................................................5

3.3 MP3-Decompose the Monolith.......................................................................................................6

3.4 MP4-Decompose the Monolith Based on Data Ownership.........................................................7

3.5 MP5-Change Code Dependency to Service Call.........................................................................8

3.6 MP6-Introduce Service Discovery..................................................................................................10

3.7 MP7-Introduce Service Discovery Client.....................................................................................11

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

3.12 MP12-Introduce Edge Server......................................................................................................16

3.13 MP13-Containerize the Services.................................................................................................17

3.14 MP14-Deploy into a Cluster and Orchestrate Containers........................................................18

3.15 MP15-Monitor the System and Provide Feedback.....................................................................19

4 Selecting and Composing Migration Patterns..............................................................................20

5 Adding New Patterns to the Repository......................................................................................21

References................................................................................................................................................. 21

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 에서는 현재의 패턴 저장소에 새로운 패턴을 추가하는 절차에 대해 설명한다.

2

Figure 1: Meta-model

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 를 보강했다. 각 이행 패턴이 시스템에 변경을 가져오는 원인이 되고 그 변경사항이 부작용이나 문제를 유발할 수 있기 때문에 이 문제들을 패턴 선택의 결정 요인으로 포함시켰다. 세번째로, 이행 패턴의 일부는 새로운 지원

3

기능(component)을 도입하는 것과 관련되거나 실제로 이미 구현된 내용을 인식하기 위한 도구가 필요하다. 결과적으로, 이행 패턴의 body 에 Technology Stack 클래스를 추가하였다.

Table 1: Migration pattern selection factors

Factor DescriptionArchitectural Factors

Scalability 서비스를 수평 확장(scale-out)함으로써 어플리케이션의 확장성 증가High Availability 서비스를 복제함으로써 어플리케이션의 가용성 증가Fault Tolerance 어플리케이션 장애 발생의 기회를 줄이고 장애를 효과적으로 처리할

수 있는 방법을 제공Modifiability 최소한의 부작용과 최종사용자에게 영향을 미치지 않고

어플리케이션의 변경을 가능하게 함Polyglot-ness 어플리케이션이 다른 프로그래밍 언어와 데이터 저장소를 가질 수

Decomposition 어플리케이션을 일련의 서비스로 나누는 재구조화(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 에서 중복되기 때문에 삭제되었다.

4

3 Migration and 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

Problemmicroservices 를 도입함으로써 많은 수의 서비스가 늘어나면, 어떻게 항상 운영 가능하도록 준비되어 있게 할 수 있고, 어떻게 해야 Continuous Delivery 를 도입할 수 있도록 시스템을 준비할 수 있을까?

SolutionContinuous 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 StackGitlab, Artifactory, Nexus, Jenkins, GoCD, Travis, Bamboo, Teamcity

References

5

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:

7

현재의 technology stack 을 이해하는 것이 중요한데, 왜냐하면 팀이 이행을 쉽게 할 수 있는 기존 라이브러리들 식별할 수 있도록 도와 주기 때문이다. 새로운 라이브러리에는 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-Decompose 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) 소프트웨어 시스템이 있다:

• 시스템이 너무 복잡해서 소스 코드에 대한 이해도가 낮다.

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) 소프트웨어 시스템이 있다:

• 시스템이 너무 복잡해서 소스 코드에 대한 이해도가 낮다.• 시스템의 영역별로 각기 다른 비기능적 요건을 갖는다.(예, 확장성)

9

• 시스템 변경이 일어날 때마다 전체를 재배포해야 하며, 변경 빈도의 측면에서 시스템의 모든 영역이 다 똑같지는 않다.

Figure 5: MP4-Decompose 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 to service-level dependency

Reuse Situation Decomposition, Modifiability

10

Figure 6: MP5-Change Code Dependency to Service Call

Context소프트웨어 시스템은 microservices 아키텍처 스타일을 사용할 수 있도록 일련의 작은 서비스들로 분해되어 있으나 시스템의 어떤 구성 요소는 여전히 다른 서비스나 구성요소에 의존해서 실행되고 있다.

Problem코드 수준의 의존성을 서비스 수준으로 의존성(service-level dependency)으로 바꾸려면 언제가 적절한가? 그리고 적절하지 않은 때는 언제인가?

Solution가능한 서비스 코드는 별도로 유지한다. 서비스끼리 서로 의존적으로 코드를 공유하게 되면(즉, 종속성을 유지하면) 개발자가 그 공유된 코드를 변경함으로써 다른 서비스의 빌드 프로세스를 망칠 위험이 커진다. 경우에 따라 공통 라이브러리로 공유되는 코드(예 : 문자열 조작 라이브러리)는 거의 변경되지 않아서 코드를 공유하는 것이 합리적이다. 그러나 내부 개체나 인터페이스 스키마를 공유하는 것은 금지되는데, 왜냐하면 그것들을 변경하는 순간 다른 종속된 서비스가 비록 자기는 점차적으로 변경하고 싶어도 즉시 변경해야 하기 때문이다. 공유가 좋은 방법이 아닌 경우에는 해당 기능을 서비스로 만들어 공유하는 것도 좋은 방법이다. 이 서비스는 완전히 격리된 서비스이거나 종속 서비스 중의 하나의 일부일 수도 있다. 공유 라이브러리를 서비스로 변경시키는 또 다른 이유는 공유 라이브러리와 종속 서비스 사이의 확장 가능성 요구가 달라서 일 수도 있다. 이런 경우에는, 서로 다른 서비스에서 분리하여 각각 서로 독립적으로 확장될 수 있도록 한다.

Challenges라이브러리의 종속성을 제거하고 메서드 호출 대신 서비스 호출을 사용하는 것은 때로는 성능 문제를 야기할 수도 있다. 비록 성능 문제를 캐싱 매커니즘으로 처리할 수 있다고는 해도, 그러면 종속된 서비스에 또 다른 복잡성 추가된다.

References

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 StackEureka, Consul, Apache Zookeeper, etcd

12

References

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 도 설정되어 있다. 개별 서비스의 인스턴스의 수는 동적으로 변경될 수 있으며 각각 다른 시스템에도 배포될 수 있다.

ProblemService Discovery 는 새로운 인스턴스가 배포되었다는 것을 어떻게 알 수 있을까? 또한 인스턴스가 종료되었다는 것은 어떻게 알 수 있을까?

Solution개별 서비스는 Service Discovery 주소를 알아야 하고 초기화되는 동안에 registry 에 자체 등록해야 한다. 그런 다음 개별 인스턴스에서 registry 로 주기적으로 신호(heartbeat)를 보내야만 그 인스턴스를 사용가능한 인스턴스 목록에 계속 유지한다. 신호를 더 이상 보내지 않거나 registry 에 인스턴스 종료를 명시적으로 알림으로써 인스턴스를 종료할 수 있다.

Challenges단점은 사용중인 모든 프로그래밍 언어에 대해 클라이언트를 설치해야 하며 잘못 설치하면 서비스 코드가 복잡해 질 수 있다.

Technology StackEureka 는 서버 버전용 Java 클라이언트가 설치된 Service Discovery 이다.

References

13

3.8 MP8-Introduce Internal Load Balancer

Type atomic

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 StackRibbon 은 Service Discovery 인 Eureka 와 잘 맞는 Java 용 내부 load balancer 이다.

References

3.9 MP9-Introduce External Load Balancer

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 StackAmazon ELB, Nginx, HAProxy, Eureka

References

3.10 MP10-Introduce Circuit Breaker

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 으로 변경된다.

ChallengesOpen Circuit 상태에서 적절한 응답을 인식하는 것은 다소 어려울 수 있으며 업무 관계자들의 협조를 얻어야 한다. 더구나 만약 응답이 단순한 예외가 아닌 경우에는, 서비스 공급자 팀(=해당 서비스의 개발/운영팀)은 대신 응답을 반환 가능성을 확인해야 한다.

Technology Stack Hystrix

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 StackSpring Config Server, Archaius

References

3.12 MP12-Introduce Edge Server

17

Figure 13: MP12-Introduce 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 StackZuul

References

3.13 MP13-Containerize the Services

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 또는 자격 증명)을 제공하며, 이 키들은 컨테이너 생성 단계에서 쉽게 삽입할 수 있다. 코드 저장소에 있는 서비스를 실행하기

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 management tools

Reuse Situation Resource-efficiency, Deployment

Context소프트웨어 시스템은 microservices 아키텍처 스타일을 사용할 수 있도록 일련의 작은 서비스들로 분해되어 있고, Continuous Integration pipeline 이 구축되어 작동 중이다. 그러므로 운영계에 배포 가능한 컨테이너 이미지가 각 서비스의 배포에 사용될 수 있다. 또한 서비스 숫자가 많아서 배포와 재배포가 복잡하고 번거로우며 관리하기 어렵다.

Problem서비스의 인스턴스를 클러스터에 배포하는 방법은 무엇인가? 어떻게 하면 최소의 노력으로 모든 서비스의 배포와 재배포를 조율할 수 있는가?

Solution

20

컴퓨팅 노드의 클러스터를 관리할 수 있는 시스템이 필요하다. 이 관리시스템은 필요에 따라 특정 개수의 인스턴스나 여러 다른 노드에 서비스 컨테이너 이미지를 배포할 수 있어야 한다. 게다가 인스턴스의 장애를 처리하고 경우에 따라서는 장애 난 노드나 인스턴스를 재시작해야 한다. 뿐만 아니라 서비스를 자동 확장(auto-scaling)할 수 있는 수단도 제공해야 한다. Service Discovery 같은 일부 서비스는 IP 주소 대신 이름으로 식별되어야 하므로 내부 (서비스)이름 확인 전략을 사용하는 것이 좋다.

배포 절차를 효과적으로 조율하기 위해서, 클러스터 관리 도구는 서비스의 배포 아키텍처를 명시적으로 정의할 수 있는 수단을 제공해야 한다. 명시적인 배포 아키텍처를 갖게 함으로써, 자동 확장이나 서비스 장애관리 같은 배포를 위한 노력들은 클러스터 관리 도구로 위임되어야 한다.

ChallengesNone

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

ContextMicroservices architecture 스타일로 소프트웨어 시스템이 구축되었다. 전체 시스템은 운영계의 개별 서비스가 여러 개의 인스턴스를 갖는 컨테이너 클러스터에서 실행되고 있다.

ProblemInfrastructure 는 어떻게 모니터링 할 것인가? 수집된 데이터로 개발팀에 피드백을 제공하여 시스템을 재구성(re-architect)하는 방법은 무엇인가?

Solution개별 서비스는 해당 서비스 관리팀의 운영(Ops) 파트가 직접 관리하는 독립된 모니터링 기능을 갖고 있어야 한다. 이 기능에는 CPU 와 RAM 사용량과 같은 모니터링 정보를 수집하여 모니터링 서버에 보내는 역할을 하는 구성요소가 포함되어야 한다. 그러므로 각 서비스 컨테이너 이미지에 다음과 같은 구성요소들이 추가하여 컨테이너 이미지 생성 또는 실제 컨테이너 생성시에 설정해야 한다. 그런 다음, 모니터링 서버에서 이 정보들을 구문 분석하고 구조화된 정보 형태로 집계한 뒤 인덱싱 서버같이 효율적으로 쿼리할 수 있는 곳에 저장해야 한다. 모니터링 정보를 적시에 집계할 수 있는 풀을 갖게 되면, 시스템의 전반적인 상태를 파악하는데 가상화 도구를 사용할 수 있다. 이 모니터링 정보는 서비스 관리팀의 개발(Dev) 파트가 성능 병목현상이나 기타 이상 현상을 제거하기 위해 아키텍처를 리팩토링하는 데 도움을 준다.

ChallengesNone

Technology Stack Collectd + Logstash + ElasticSearch + Kibana

21

References

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 를 고려하기 시작했기

22

때문에 패턴의 완성도는 아직 보장할 수 없다. 대신, microservices 로 이행하는 새로운 경험을 통해 일반화된 새로운 이행 패턴을 추가함으로써 패턴 저장소를 확장할 수 있는 수단이 있어야 한다. 패턴을 정의할 때 메타 모델, 몇몇 선택 요인, 그리고 패턴의 내용(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.