개요
본 포스팅에서는 MSA의 개념과 이후 개발 패러다임에 대해 알아보도록 하겠습니다.
Microservice는 SOA (Service Oriented Architecture) 의 경량화 버전으로 (Service: 특정 기능의 집합, service의 범위 정의가 중요) 모놀리틱 아키텍처(monolithic architecture)를 쪼개서 독립적으로 구분합니다.
Microservice는 독립적으로 디플로이 / 확장 될 수 있는 서비스들을 조합하여 large 어플리케이션을 구성하는 아키텍처 패턴입니다.
일반적으로 Service Discovery, API Gateway, Orchestration, Choreography, Context Boundary등의 서비스들의 조합으로 이루어져있습니다.
Netflix, Twitter, Amazon, Nike 등의 회사에서 채택한 아키텍처로 소개되면서 '14년 초반부터 현재까지 주목 받고 있습니다. 아키텍처 관련 기술 표준은 없으며 SW벤더들이 기존 제품군(SOA, PaaS, ...)을 Microservices를 지원하기 위한 플랫폼으로서 rebrand하는 추세로 전환되고 있습니다.
Monolithic 아키텍처
기존 legacy System의 경우 monolithic 아키텍처를 따르는 large 어플리케이션들은 다음과 같은 개발/운영상의 문제들에 직면하게 됩니다.
① 일부 모듈의 변경사항 때문에 전체 어플리케이션 개발/운영 프로세스와 패키징에 영향을 준다.
② 모듈별 특성에 맞는 신기술 또는 구조를 적용하기 어렵다.
③ 모듈별 확장이 어렵다.
MSA의 특징
마이크로서비스 아키텍처의 특징은 다음과 같습니다.
① 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.
② 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.
③ 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
④ 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
⑤ 작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.
MSA의 목적
마이크로서비스를 달성하기 위해서는 많은 노력과 비용이 수반된다. 따라서 MSA를 적용하고자 할 경우 명확한 목적을 갖고 적용을 고려해 보아야 한다.
1) 마이크로서비스 아키텍처를 통해 달성하고자 하는 목표는 무엇인가?
명백한 목표 예를 들어 기존 대비 1.5배 빠른 성능, 이벤트에도 중단되지 않는 가용성 높은 서비스 등 결과를 기준으로 설명할 수 있어야 하며, 시스템의 end-user에게 이점을 제공하는 방식으로 설명될 수 있어야 한다.
2) 마이크로 서비스 사용에 대한 대안을 고려했습니까?
마이크로서비스가 제공하는 것과 동일한 이점을 얻을 수 있는 다른 많은 방법이 있다. 때로는 MSA를 고려하지 않고도 적용 가능한 방법이 다양하게 존재하므로, 이에 대한 고려를 선행한 후 MSA를 선택하는 것이 좋다.
MSA 장단점
MSA 장점
1) 팀 자율성 향상
자율적인 팀은 큰 이점을 갖을 수 있다. 조직 그룹을 작게 유지하여 긴밀한 유대를 구축하고 효과적으로 협력할 수 있도록 함으로써 효과적으로 성장하고 확장할 수 있다. 비즈니스 단위가 150개를 넘지 않도록 하여 모두가 서로를 알 수 있도록 하는 것이 중요하며, 이러한 소규모 팀이 정상적으로 운영되려면 권한과 책임이 부여되어야 한다.
조직 내에서 더 많은 자율적인 팀을 만들려고 하며 종종 Amazon에서 이야기하는 피자 두판을 먹을 수 있는 팀 구성 또는 Spotify 모델 등을 적용해 볼 수 있다.
제대로 수행된다면 팀 자율성은 팀원에게 권한을 부여하고, 그들이 한 단계 더 발전하고 성장하도록 도우며, 작업을 더 빨리 완료할 수 있을 것이다. 팀이 마이크로서비스를 소유하고 해당 서비스를 완전히 제어할 수 있다만 기존에 더 큰 조직 내에서 가질 수 있었던 자율성을 통해 보다 높은 결정권을 기반으로 스스로 책임지고 스스로 성장해 나가는 팀 단위 구성이 될 것이다. 자율성은 다양한 방식으로 발휘될 수 있다. 팀에 더 많은 책임을 부여할 수 있는 방법을 찾는데 아키텍처 전환이 필요하지는 않다. 그러나 본질적으로 이는 팀에 어떤 책임을 부과할 수 있는지 식별하는 프로세스이며 이는 여러 방식으로 진행될 수 있다. 코드베이스의 일부에 대한 소유권을 다른 팀에 부여하는 것이 하나의 답이 될 수 있다. 이것은 기능 기반에서 코드베이스의 일부에 대한 결정을 내릴 권한이 있는 사람을 식별하여 수행할 수도 있다.
2) 출시 시간 단축
개별 마이크로 서비스에 변경 사항을 적용하고 배포할 수 있고 조정된 릴리스를 기다릴 필요 없이 이러한 변경 사항을 배포할 수 있으므로 고객에게 더 빨리 기능을 출시할 수 있다.
3) 유연한 확장
개별 마이크로서비스로 분리되면 프로세스를 독립적으로 확장할 수 있다. 이는 비용 효율적으로 확장할 수 있음을 의미한다. 즉, 현재 부족한 성능을 나타내는 서비스만 별도로 확장하면 된다는 의미이다. 또한 더이상 부하가 증가하지 않을 경우 자동으로 마이크로서비스를 축소할 수 있으며 필요하지 않을 때 해제할 수도 있다. 이것이 부분적으로 SaaS 제품을 구축하는 많은 회사가 마이크로서비스 아키텍처를 채택하는 이유이다. 마이크로서비스 아키텍처를 통해 운영 비용을 더 잘 제어할 수 있다.
4) 강건성 제공
애플리케이션을 독립적으로 배포할 수 있는 개별 프로세스로 분할함으로써 애플리케이션의 견고성을 개선할 수 있다.
마이크로서비스를 사용하면 기능이 분해되기 때문에 보다 강력한 아키텍처를 구현할 수 있다. 즉, 한 기능 영역에 대한 영향이 전체 시스템을 다운시킬 필요가 없다. 또한 우리는 시스템의 중요한 부분이 계속 작동하도록 보장하는 강건성을 가장 요구하는 애플리케이션에 투자를 집중할 수 있다.
일반적으로 시스템 중단을 방지하고 오류가 발생했을 때 적절하게 처리하고 문제가 발생했을 때 신속하게 복구하는 시스템 기능을 개선하려는 경우 복원력 에 대해 이야기하는 경우가 많다.
강건성은 예상되는 변동에 대응할 수 있는 시스템을 보유하는 능력을 의미하며, 복원력은 생각지 못한 것에 적응할 수 대응하는 능력을 의미한다.
#참고 여기서 중요한 고려 사항은 마이크로서비스가 반드시 무료로 강건성을 제공하지 않는다는 점이다. 오히려 네트워크 파티션, 서비스 중단 등을 더 잘 견딜 수 있는 방식으로 시스템을 설계할 수 있는 기회를 제공한다. 여러 개의 개별 프로세스와 별도의 시스템에 기능을 분산하는 것만으로는 견고성이 향상되지 않는다. 오히려 실패할 가능성을 증가시킬 수 있다는 점을 기억하자.
5) 개발자 생산성
기존 모놀리식 시스템에서는 개발자의 수를 늘리는 것만으로 생산성을 확장하는데에는 한계가 있다. 마이크로서비스 아키텍처를 적용할 경우 명확하게 식별된 경계와 서로의 결합을 제한하도록 하는데 중점을 둬 독립적으로 개발할 수 있는 환경을 제공하여 개발자간 경합을 줄여 개발자 수를 늘리는 것이 개발 생산성과 직결될 수 있다.
6) 신기술 수용
모노리스는 일반적으로 기술 선택을 제한한다. 하나의 배포 플랫폼, 하나의 운영 체제, 하나의 데이터베이스 유형에 고정되어 있다. 마이크로서비스 아키텍처를 사용하면 각 서비스에 대해 이러한 선택을 다양하게 가져갈 수 있다.
서비스 별 영역을 격리함으로써 새로운 기술의 이점을 적용할 수 있고 기술에 문제가 있는 것으로 판명될 경우 타 서비스로의 영향을 최소화 할 수 있다.
MSA 단점
1) 불분명한 도메인
서비스 경계를 잘못 설정하면 비용이 많이 들 수 있다. 이는 더 많은 서비스 간 변경, 과도하게 결합된 구성 요소로 이어질 수 있으며 일반적으로 단일 모놀리식 시스템을 사용하는 것보다 더 나쁠 수 있다. 서비스 전반에 걸쳐 많은 변경이 이루어지고 그에 따른 높은 변경 비용이 발생할수도 있다.
아직 도메인을 완전히 이해하지 못했다고 생각되면 시스템 분해를 시작하기 전에 도메인을 이해하는 것부터 시작하는 것이 바람직하다.
2) 유지보수 어려움
패키지되어 고객에게 딜리버리되는 소프트웨어를 고객이 직접 운영한다면 마이크로서비스는 좋지 않은 선택이 될 수 있다. 마이크로서비스 아키텍처로 마이그레이션하면 운영 도메인에 많은 복잡성이 추가된다. 모놀리식 배포를 모니터링하고 문제를 해결하는데 사용한 이전 기술은 새 분산 시스템에서 제대로 작동하지 않을 수 있다. 이제 마이크로서비스로 마이그레이션하는 팀은 새로운 기술을 채택하거나 새로운 기술을 채택하여 이러한 문제를 상쇄할 것이고 이는 일반적으로 end-user에게 기대할 수 있는 일은 아니다.
현실은 고객이 마이크로서비스 아키텍처를 관리하는데 사용할 수 있는 기술이나 플랫폼을 운영할 것이라 기대하기는 어렵다.
MSA의 장단점 비교
Microservice가 등장한지는 꽤 되었지만, 사실 중요성을 인지한지는 그리 오래되지 않았습니다. 다만 최근 MSA의 급격한 성장세에 너도나도 뛰어들고 있는 추세입니다. 그렇다면 왜 MSA를 사용하는가에 대한 의문을 갖게되는데요.
바로 다음과 같은 이유입니다.
① 작은 서비스들로 나누고, 각 서비스를 독립적으로 만듦 → loosely-coupled (이로 인해 오는 장점)
② 대용량 분산 환경에 적합
③ 복잡도 감소
④ 유연한 배포
⑤ 재사용성 → 확장성
⑥ 서비스별 hw/sw 플랫폼/기술의 도입 및 확장이 자유롭다.
⑦ 개발자가 이해하기 쉽고 개발/운영 매 단계의 생산성이 높다.
⑧ 지속적인 개발/디플로이가 biz capability 단위로 관련된 소수의 인원의 책임하에 이루어질 수 있다.
⑨ fault isolation 특성이 좋다.
Microservice의 장점은 위와 같이 강력하지만 이는 단순히 장점만 포함하고 있는 것은 아닙니다. Microservice를 성공적으로 활용하기 위해서는 아래와 같은 문제에 대한 대책을 사전에 마련해야 합니다.
| 단점 | 보완방법 |
| 장애추적, 모니터링, 메시징 처리가 어렵다. | Sleuth 등과 ELK, EFK, Splunk 등의 서비스를 연동하여 사용하는 방안 고려 |
| 여러 서비스에 걸쳐져 있는 Feature의 경우, 트랜잭션을 다루기 어렵다. | 보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려 |
| 여러 서비스에 걸쳐져 있는 Feature의 경우, 테스팅이 복잡하다. | 테스팅 계획 및 방법에 노력 투자 |
| 서비스 간 Dependency가 있는 경우 릴리즈가 까다롭다. | 관련 개발조직 간 roll-out 계획 마련 및 dependency의 관리체계 수립 |
| 서비스 개수가 많고 유동적이기 때문에 CI/CD 및 서비스 관리 상의 문제가 발생할 수 있다. | 서비스 레지스트리, 모니터링, 개발/디플로이 자동화 기술 고려 (PaaS 고려) |
| 모놀리스 시스템을 마이크로서비스 전환할 때 큰 고동이 수반될 수 있다. | B2C 웹 또는 SaaS 어플리케이션은 처음부터 마이크로서비스 및 서비스 별 조직을 고려하여 구성 |
[References]
http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788968483417&orderClick=LAG&Kc=
http://microservices.io
http://devops.sdsdev.co.kr/confluence/display/SP/Microservice+Architecture
https://www.slideshare.net/Byungwook/msa-52918441
https://martinfowler.com/articles/microservices.html
http://projects.spring.io/spring-cloud/
http://www.infoq.com/microservices