MSA 는 언제해야 되고, 언제 하지 말아야 되는가? ( When To Use Microservices And When Not To )
유투브 GOTO Conferences 채널에서 마틴 파울러 형님과 샘 뉴먼 형님이 MSA 를 언제해야되고 언제 하면 안되는가? 대한 토론을 담은 영상을 보았다.
https://www.youtube.com/watch?v=GBTdnfD6s5Q
개인적으로 MSA 에 대한 경험이 없는 나로서는 두 형님들의 토론이 상당히 흥미를 가지고 보았다.
영상의 시작은 샘 뉴먼 형님이 아래의 책 Monolith to Microservices 란 책을 왜 집필하게 되었는지에 대한 질문으로 시작한다.
그리고 Monolith to Microservices 에서는 어떻게 큰 모놀리틱을 작게 나눌지에 대한 내용을 주로 다루었다고 한다. 그리고 해당 내용을 집필하는 과정에서 보다 면밀한 내용을 다루고 싶었다고 한다.
대화내용 정리..
그리고, 마틴 파울러 형님이 나오면서 묻는다.
고작 천 줄의 코드의 프로그램을 만들면서, MSA 를 옹호하고 MSA 를 사용하면서 100줄 코드로 구성된 여러 서비스로 나누는 것을 보았다. 하지만, MSA 에 대해서 부정적인 견해를 가진 사람들은 찾기 힘들다. 단지 새로운 기술을 사용하고 싶어서 채택한다. 진정으로 언제 MSA 사용해야 된다고 생각하는가?
이에 샘 뉴먼 형님은 이렇게 답한다.
MSA 를 하면서 MSA 가 주는 장점이 무엇인지 의식해야 한다고 말하며 아래의 3가지를 말해준다.
- More options to scale up applications. (스케일 업에 대한 보다 많은 선택지)
- Independent deployability (독립적인 배포)
- Limit the "blast radius" of failure (장애 확산 방지)
그리고 James Lewis 말을 인용한다. "Microservices architectures buy you options"
MSA 를 채택하는 것은 buy options 이라는 표현을 사용하며, buy 라는 것은 근본적으로 비용을 수반한다고 한다.
이에 마틴 파울러형님은 반문한다. 그렇다면 기본 option 은 모놀리틱이겠구나. 진정으로 MSA 를 채택해야 하는 이유를 찾지 못한다면 모놀리틱이 옳을 수 있다는 말로 들린다.
그리고 샘 뉴먼형님은 마틴 파울러형님의 말에 동의하며, "MSA 는 끄고 켤 수 있는 스위치가 아니라고 한다." 따라서 MSA 는 기본 선택지가 아니라고 한다. 만약 service architecture 가 보다 적합하다면, 여러 모듈로 구성된 모놀리틱 topology 를 선택하고 계속 발전시켜나가야 한다.
다시 마틴 파울러 형님은 묻는다. 그렇다면 MSA 를 하려면 강력한 이유가 있어야 한다는 말로 들리는데, 제일 중요한 3가지 이유가 무엇인가?
샘 뉴먼 형님은 3가지를 아래와 같이 답한다.
1. Zero-downtime independent deployability (ex. SasS business )
2. Isolation of processing around data ( ex. Healthcare industries, GDRP )
3. Enable a higher degree of organizational autonomy
-> 책임을 각 팀에게 분산하고 조직의 책임 조정 비용을 낮추고자 할 때
또한 마틴 마울러 형님은 묻는다. 독립적인 배포가 가능하다고 했는데, MSA 를 한다고 했지만, "Distributed Monolith" 로 구성하는 함정에 빠지곤 한다. 이를 어떻게 방지할 수 있는가?
샘 뉴먼 형님은 방안을 제시한다.
1. Create a deployment mechanism
2. Look for patterns
예를 들어, Jira 를 사용하여 작업이 완료된 story 를 돌아보면서 영향을 같이 수반하는 commit 들을 확인하고, 서비스들의 묶음을 찾아야 한다고 한다.
이렇게 같이 묶여서 배포되는 서비스들을 하나의 서비스로 합치거나 혹은 더 작게 서비스를 나누는 선택을 할 수 있다고 한다.
인터페이스를 더 작게 유지할 수록 경계 들이 영향을 주지 않도록 하는 것이 쉬워진다고 한다. 인터페이스를 작게 관리하지 않고 MSA 를 하는 것은 독립적인 배포의 장점을 누릴 수 없게 된다고 한다. 서비스들간의 캡슐화가 매우 중요하며, 사람들은 정확하게 정보 은닉의 개념을 알지 못한다고 했다.
그리고, 마틴 파울러 형님은 다시 묻는다. 왜 독립적인 배포가 그렇게 중요한거지? 모놀리틱을 유지하더라도 일정한 배포 주기를 가지고 그에 맞는 CD Pipeline 통해서 계속 적으로 소프트웨어의 변화를 전달할 수 있는데?
샘 뉴먼 형님은 이렇게 답한다.
it's easier to limit the impact of each release with microservices
샘 뉴먼: 모놀리틱에서 좋은 CD Pipeline 을 구축한 좋은 사례들이 많다. 하지만 내가 말하고 싶은건, MSA 에서의 각각의 release 가 의도하지 않는 곳에 영향을 주는 것에 대한 제한을 하기 쉬워진다. 다시 말하자면, 소프트웨어의 변화를 주는데에 큰 부담이 없어진다. 모놀리틱에서 배포를 하게 되면 조금의 변화에도 잠재적으로 다른곳에 영향이 가게 된다. MSA 의 경우 각 서비스의 배포가 서로에게 주는 영향을 최소화 하고 보다 효율적으로 전달할 수 있다. 더욱이 SaaS 비즈니스는 Zero downtime 이 정말 중요하고, 모놀리틱의 경우 보다 대응하기 힘들다.
Flicker 나 etsy 에 사례를 들어 보자면, 기존 서비스에 database 의 변화가 일어났을 때 migration 작업이 수반되고, 주로 주말에 많은 시간을 소요 하면서 작업 했고, 이는 시스템에 큰 영향을 주게되었다. 만약에 MSA 였다면, migration 도 보다 수월하고 빨리 끝낼 수 있고 전체 시스템에 영향이 제한할 수 있었다. 모놀리틱에서 불가능하다고 말하고 싶은 것이 아니다. 내 경험상 모놀리틱이 MSA 보다 "much harder" 이다. 모놀리틱도 좋은 CD Pipeline 을 구축하면 효과적으로 전달할 수 있다.
그리고 모놀리틱의 경우 각가의 팀들이 배포 시 항상 전체 시스템에 대한 신경을 써야 되고 매우 미세한것들 까지 신경을 써야한다. 너가 5, 6 ,10 ,15 ,20 팀이 있는 조직에서 일하면서 동일한 모놀리틱 구조에서 작업한다면 모든 팀에서 해당 배포가 시스템에 어떤 영향을 주는지 조정해야된다.
그리고 마틴 파울러 형님은 일부는 동의하고 일부는 납득하지 못한다.
마틴 파울러: 맞아 조직내에 많은 팀이 있을 경우 조정하는 비용이 매우 높다는 말은 동의한다. 근데 여전히 MSA 분산 시스템이고, 정말 좋게 관리하기 힘든데 모놀리틱이 왜 harder to deploy 한 지 납득이 안된다. 전체 시스템을 보다 효율적으로 test 할 수 있도록 갖춘다면 모놀리틱이라도 harder 하지 않을 수 있다. 결국 가장 필요한 것은 barriers 네? MSA 는 일종의 barrier 들을 강제하는 방법이고.
샘 뉴먼 : barriers 는 모놀리틱 안에서 modules 이 될 수 있다 , 근데 또한 module 들을 침범하는 방법을 찾을 수 있고 실제로 발생하는 일이다. 헌데, service process 의 경계를 만든다면(MSA 한다면), 이 침범하는 것들이 고통스럽게 될것이다.
마틴 파울러 : 슬프네, 모듈들이 서로 침범하는 일이 발생하는 일이 벌어지다니, MSA 를 할 때 가장 힘든 부분이 handling of data 인데 모놀리틱을 MSA 로 breaking apart 할 때 가장 효율적인 방법이 무엇인가?
샘 뉴먼: 맞아, 명백하게 data 는 hard 이다, breaking data apart in relational database 더욱이 어렵다, 이는 기본적으로 관계형 데이터베이스의 본성이다. 관계형 디비는 말 그대로 관계형이다, 관계를 다 끊어줘야된다. 전체적인 schema 를 그래픽적으로 볼 수 있어야 되며, 더 tightly 하거나 aligned 해보이는 부분을 알 수 있어야한다. 특히 외래키.. 참조 무결성, consistency 이런것들이 제일 어려운 부분이다.
먼저 해야 될것은 MSA 로 서비스들을 추출한 후에 시스템에 사용하는 데이터베이스의 부분을 이해해야된다.데이터베이스에서 부터 생각하는데 이는 잘못되었다.
먼저 서비스들을 정의하고 해당 서비스들에서 사용될 data 들을 정의해야되며, 그 후에 어느 서비스의 부분에 어떤 data 들을 해당 서비스에 적용시킬 지 정해야 된다.
데이터베이스는 가장 큰 이슈야 제일 어렵다. 수 많은 case study 가 필요하다. 그리고 이런 case study 를 통해 유명한 pattern 들이 있다.
관계형 데이터 베이스의 장점은 확연하다. join, arbitrary queries 등 많은 장점들이 있다. 하지만 이것을 분리하는 것은 매우매우 힘들다. 많은 연구가 필요하다.
마틴 파울러: 맞다 관계형 데이터베이스가 관리하기 쉽다. 소프트웨어 개발에 있어서, data 보다 복잡한 한 가지가 사람이다. 사람이 항상 가장 복잡한 부분이고, 그래서 각기 사람들은 다양한 문화와 스킬을 가지고 있다. 만약 분산 시스템을 관리하는데 익숙하지 않은 사람도 있다. 그래서 MSA 할 때 조직을 어떻게 구성하는게 좋니?
샘 뉴먼: 그렇다, 항상 구성원들간의 명백한 기술 차이가 존재한다. 근데 우선 MSA 잘하려면, 조직에서 변화에 대한 결단을 내려줘야 한다. MSA 는 비용이 든다. MSA 를 구축하는데 단기적으로는 비용이다.
또한 명령 및 통제 식의 old-fashion 한 의사결정을 해선 안된다.
단적인 예를 들어보자, 한 사람에게 조직에서 이제부터 넌 DevOps 야 프로덕션 환경에 있는 서비스를 지원하고 너에게 전적인 ownership 을 줄게라고 한다면 95% 는 이직을 준비하고 5% 만 힘낼것이다.
따라서, 조직 구성원 모두가 강력한 결정을 내려야한다.
단지, ceo, cto, cio 등 c 레벨에서 우리 MSA 할것이다다라고 하는것이 아니라, 조직 구성원 전체가 동의하고 결단을 내려야한다. 팀에게 shifting responsibility 해야 하고,
또한 팀내의 같은 동료를 신뢰하지 못하는 경우도 보았다. 또한 다른 동료는 이전에 하던방식을 원할 수도 있다.
그렇다면, 조직은 팀에게 얼마나 많은 자율성과 책임을 부여해야 할까? MSA 는 하룻밤안에 일어나지 않는다, 수많은 시간과 에너지 돈이 든다. 제일 중요한 건 top-down 의사결정은 버려야 한다.
정리..
MSA 는 기본 선택지가 아니다. MSA 선택하는 명확한 이유가 있어야한다. 단지 새로운 기술을 추구하기 위해서 MSA 를 도입하는 것은 잘못 되었다. 하려고 하는 비즈니스의 성격(SaaS 등)에 따라, 조직의 팀 구성에 맞춰 독립적인 배포가 필요하고 의사 결정 및 조율 비용을 낮추기 위해서 그리고 기술적으로 소프트웨어의 변화가 일어날 때 부수 효과를 최소화 하기 위해서 등 명백한 이유가 있어야한다.
MSA 행하는 도중에 많이 실수하고 함정에 빠지는 경우가 바로 "Distributed Monolith" 이다. 서비스를 분리했지만 서비스들 간의 의존성으로 인해서 배포 시 같이 묶여서 배포되어야 하는 경우이다. 조직의 비즈니스에 맞는 배포 메카니즘을 찾는것이 매우 중요하다고 한다. 여기서 아마 DevOps 의 역할이 가장 중요하지 않을까 생각한다. 또한 서비스들간의 인터페이스를 작게 유지함으로써 서로가 반드시 알아야할 정보만 알고 있도록 설계하는 것이 가장 중요하다고 생각한다.
기존의 Monolith 를 MSA 로 전환하는 것에서 가장 힘든점이 바로 data 이다. 기존의 관계형 데이터베이스를 분리하는 작업이 MSA 에서 가장 핵심이고 가장 어려운 작업이다. 이는 비즈니스 마다 다르기 때문에 정답이 없다. 가장 명심해야할 것은 데이터베이스로 부터 사고를 시작하는 것이 아닌, 비즈니스에서 부터 시작하여, 먼저 서비스들을 정의하고 서비스에서 필요한 data 를 정의하는 것이다. (Domain Driven Design)
마지막으로, MSA 에서 중요한 것은 의사 결정 방법이고, top down 방식이 아닌 각 팀에서 자율과 책임을 각팀에서 부여하는것이 중요하다.
.png)
.png)
댓글
댓글 쓰기