[마이크로서비스 아키텍처 구축] 챕터1. 마이크로서비스란? (MSA 도입 전에 고려해야 하는 것들)
Joonfluence2024. 1. 19.
목차
들어가기에 앞서
사람들이 MSA에 열광하는 이유
왜 사람들은 MSA로 전환하려고 할까? 전환의 이유로 꼽는 Tech 팀들의 글에는 공통적인 이야기가 있다.
"모놀리식 구조의 코드 베이스"가 커지면 문제가 발생된다는 점이다. 배포 시, 예상치 못한 버그가 발생하기도 하고 배포하는 데에도 시간이 오래 걸린다.
"하나의 코드 베이스를 여러 인원이 함께 작업하다보니, 서로의 작업 영역의 충돌이 잦다"는 점이다. 이로 인해, 개발 생산성이 낮아지게 된다.
이에 반해, MSA로 도입하면 아래와 같은 장점이 있다고 말한다.
비즈니스 도메인에 따라 서버를 구분함로써 독립적으로 배포 가능한 환경 구축이 가능하다.
독립적으로 배포 가능하면, 빠른 업데이트가 가능해진다. 또 모놀리식 아키텍처 배포에 비해, 배포 단위가 작아지므로
기술 선택의 자유를 얻는다.
각각의 도메인을 원하는 프레임워크와 언어를 활용하여 개발할 수 있다. (물론 채용 상의 이유로 통일하는 경우도 있다)
서비스에 따라 팀이 구분된다. 해당 팀에서 맡은 서비스를 작업하기 때문에, 작업 영역에 대한 충돌이 발생할 가능성이 낮다.
다만, 이론적으론 완벽해보이나, 문제는 실제 적용하는 것이 어렵다는 점이다. 비즈니스 도메인에 따라, 서버를 구분하는 것부터 어렵다. 오죽하면 이를 다룬 DDD(Domain Driven Development)의 내용이 568P에 달할까? Bounded Context 등 새롭게 등장하는 용어들도 많아서, 내용을 이해하는 것도 쉽지 않다. 거기에, 서버를 구분함으로써 서버 간 네트워크 통신 방법도 정해야 하고, 데이터베이스도 각각 분리해야 해서 데이터베이스 모델링 방법도 복잡해진다. 또 분산 시스템 환경이라 로깅도 복잡해지고 모니터링해야 하는 대상 서버도 늘어난다.
1.1 마이크로서비스 살펴보기
마이크로서비스는 비즈니스 도메인에 따라 모델링된 독립적으로 릴리스 가능한 서비스로, 기능을 캡슐화하고 네트워크를 통해 다른 서비스들에 액세스하게 해준다. 가령 하나의 마이크로서비스로 재고, 주문 관리, 배송을 각각 대표할 수 있지만, 한데 모으면 전체 상거래 시스템을 구성할 수 있다. 마이크로서비스는 직면한 문제를 해결하기 위해 다양한 옵션을 제공하는 데 중점을 둔 아키텍처다.
MSA에서 서비스 간 통신은 HTTP, SOAP, gRPC 등의 프로토콜로 네트워크를 통해 이뤄진다.
마이크로서비스는 서비스 지향 아키텍처(SOA)의 한 종류지만, 서비스 경계를 정하는 방법과 독립적인 배포 가능성이 핵심이라는 점 때문에 의견이 다소 분분하다. 마이크로서비스는 기술 중립적이며, 이런 특징은 마이크로서비스의 장점 중 하나로 뽑힌다.
여러 장점이 있지만, 사람들이 열광하는 이유가 바로 독립적인 배포와 기술 중립적이라는 특성이라 생각한다.
MSA와 SOA의 차이
보통 MSA를 언급하면, SOA도 같이 언급된다. MSA가 SOA의 한 종류이기 때문이다. 공통점으론 둘 다 서비스 지향적이라는 공통점이 있다. 서비스 지향적이란 말의 뜻은 무엇일까? 네트워크를 통한 통신 프로토콜을 통해 애플리케이션 컴포넌트가 다른 컴포넌트에 서비스를 제공하는 설계 원칙을 말한다. 즉, 기본 재활용 단위가 서비스인 것이다. 그렇다면 둘 간의 차이점은 무엇일까? SOA는 재활용 단위가 서비스이다. 반면, MSA는 각 부분이 특정 위치와 역할을 갖고 인터페이스를 통해 연결되는 더 작고 구체적인 부분을 사용하는 것과 같다. 예를 들어 MSA 기반 애플리케이션에는 사용자 인증, 재고 관리, 결제 처리를 위한 별도의 마이크로서비스가 있을 수 있다.
1.2 마이크로서비스의 핵심 개념
MSA를 특정 짓는 핵심 특성들은 다음과 같다. 동시에, 이러한 특성들은 MSA 도입 전에 고려해야 하는 핵심적인 요소들이기 때문에 꼭 알아두는 것이 좋다.
1.2.1 독립적 배포성
독립적 배포성은 다른 마이크로서비스를 배포하지 않고도 마이크로서비스를 변경하고 배포하고 사용자에게 릴리스 할 수 있다는 걸 말한다.
독립적 배포를 위해서는 마이크로서비스를 느슨하게 결합시켜야 한다. 즉, 다른 서비스를 변경하지 않고도 한 서비스를 변경할 수 있어야 한다. 이는 서비스 간에 분명하고 잘 정의되며, 안정적인 계약이 필요하다는 것을 의미한다. 몇몇 구현 방법은 이런 노력을 어렵게 만들기도 한다. 예를 들면 데이터베이스 공유는 특히 문제가 된다.
앞서 언급했던 것처럼, MSA를 하는 이유는 독립적인 배포 환경을 구성하기 위함이 크다. 다만, 독립적 배포성은 그 자체로 매우 가치가 높지만 이를 달성하려면 마이크로서비스 간 경계를 정해야 한다.
1.2.2 비즈니스 도메인 중심의 모델링
DDD와 같은 기술을 사용하면 소프트웨어가 동작하는 실제 도메인을 더 잘 표현하도록 코드를 구성할 수 있다. MSA에서는 동일한 개념을 사용해 서비스 경계를 정의한다. 비즈니스 도메인 중심으로 서비스를 모델링함으로써 새로운 기능을 좀 더 쉽게 출시하고 마이크로서비스를 다양한 방식으로 재결합해 사용자에게 새로운 기능을 제공할 수 있다.
마이크로서비스에서는 기술적 기능의 높은 응집력보다 비즈니스 기능의 높은 응집력을 더 우선시한다.
실제 MSA에서 모놀리식으로 돌아간 회사의 사례를 보면, 구분해야 할 상황이 아닌데 구분하여 불필요한 분산 트랜잭션이 생기는 등 복잡도가 증가하는 경우가 많았고 서비스 경계를 명확하게 나누지 못해서 과도하게 서비스를 나누다보니 복잡도가 너무 증가해서 문제가 발생하는 경우가 많았다. 참고링크, 세그먼트 사, “모놀리식으로 돌아간 이유”
뒤에 언급하겠지만, 서비스가 계속 추가되고 변화되는 초기 스타트업의 경우 역시 MSA를 도입하는 것이 알맞지 않을 가능성이 높다.
1.2.3 자기 상태 소유
MSA에서 내부 상태를 감추는 것은 OOP의 캡슐화와 유사하다.
MSA에선 서비스 간 DB가 분리된다. 한 마이크로서비스가 다른 마이크로서비스가 소유한 데이터에 액세스하려면, 해당 마이크로서비스를 거쳐야 한다. 따라서, 마이크로서비스에서 공유하고 감출 데이터를 결정할 수 있다.
1.2.4 크기
마이크로서비스는 얼마나 커야 할까라고 사람들은 자주 묻는다. 그러나 크기에 대한 걱정은 접어두자. 처음 시작할 때는 두 가지 핵심 사항에 집중하는 것이 횔씬 더 중요하다.
'마이크로 (micro)'라는 단어는 서비스의 크기가 작아야 할 것이라 생각하게 한다. 그러나 크기의 기준을 정량적으로 정할 순 없다. 전체 코드라인 수로 정할 것인가? 이를 정하는 것은 불가능하다. 사람에 따라, 상황에 따라 받아들이는 것이 서로 다르다.
첫째, 얼마나 많은 마이크로서비스를 처리할 수 있는가? 서비스가 많을수록 시스템의 복잡성이 증가하고, 이에 대처하려면 새로운 기술을 배워야 한다. 마이크로서비스의 전환은 복잡성을 유발하는 근원이 되며 이로 인해 발생할 수 있는 모든 문제를 야기한다. 이러한 이유로 MSA는 점진적으로 전환해야 한다.
MSA 전환은 점진적으로 도입하는 것이 중요한데, 내 생각으론 격리할 수 있는 도메인을 기준으로 처음부터 명확하게 나누는게 아니라, 점진적으로 도메인 경계를 10개, 50개로 점차 늘려 나누는 것이 좋을 것 같다. 그렇게 점진적으로 전환하면 서비스의 크기를 점차 줄일 수 있다.
둘째, 모든 것이 끔찍하게 결합돼 엉망인 상황을 피하면서 MSA 경계를 최대한 활용하려면 어떻게 경계를 정의해야 하는가? 이러한 주제는 마이크로서비스로 향하는 여정을 시작할 때 집중해야 하는 횔씬 더 중요한 것들이다.
서비스 경계를 정의하는 것은 Bounded Context(이하 BC) 기준이 되어야 한다. BC 기준으로 서비스를 잘 구분했을 때, 배포 시 다른 서비스에 영향을 주지 않아야 한다. 만약 영향을 준다면, 경계를 잘못 나눈 것이다.
또 경계가 잘 나뉘었다면, 최대한 나눌 수 있는만큼 먼저 도메인을 나눠보고, 그리고 거기서 나눈 것 중에서 현재 팀에서 분리 가능한 수준을 정해보는 것이 좋을 것 같다. 만약 10개로 쪼개야 하는 서비스가 있다면, 팀 상황에 맞춰서 더 큰 덩이인 3개 수준으로 쪼개, 전환하는 것이다.
1.2.5 유연성
미래가 어떻게 될지 모르므로 필자는 앞으로 직면한 모든 문제를 해결하는 데 유용한 아키텍처를 원한다. MSA는 비용이 비싸긴 하지만, 유연하다. 이는 조직성, 기술성, 규모, 견고함 등 여러 측면에서 놀라울 정도로 매력적일 수 있다. 또 마이크로 서비스를 사용할수록 유연성은 높아진다. 하지만 그만큼 고충도 늘어난다. 따라서 점진적인 마이크로서비스 채택이 중요하다.
만약 도입을 결정했다면 어떻게 해야 할까? 여러차례 언급 한 것처럼점진적으로도입하는 것이 좋다. 먼저 백엔드 → 데이터베이스(데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다. 그리고 백엔드 서비스 단위를 결정하기 위해 Bounded Context를 적용하여 서비스 경계를 구분하고, 그 기준에 따라 서비스들이 구분되면, 서비스간 인터페이스 방식을 결정하며, 인터페이스를 위한 기술셋을 선택하면 된다. 또 안정적인 운영을 위해 앞서 언급된 활성화 기술들을 적극 활용해야 한다. 로그 집계와 분산 추적이 가능한 로그 시스템 구축, 컨테이너 활용을 통한 배포 오버헤드 감소, 여러 컨테이너를 관리하기 위해 쿠버네티스를 통한 컨테이너 오케스트레이션 활용, 데이터 동기화를 위한 카프카 활용 등등. (참고링크 : https://waspro.tistory.com/718)
1.2.6 아키텍처와 조직의 정렬
3계층 아키텍처는 여러 회사에 보편화된 아키텍처이다. 프론트엔드 팀, 백엔드 팀, DBA로 나뉜 조직 구조를 갖으면, 웹 UI, 백엔드, 데이터베이스 3계층 아키텍처로 시스템 구조가 제한되게 된다. 이는 유명한콘웨이의 법칙과 관련이 깊다. "시스템을 설계하는 조직은 ... 조직의 커뮤니케이션 구조를 본떠 설계하도록 제한된다."
이 구조에선 비즈니스 기능이 3계층에 분산돼 있어 기능 변경이 계층을 넘어갈 가능성이 높다. 따라서 변경사항이 발생하면, 각 팀에서 모두 대응해야 하고, 또 올바른 순서대로 변경 사항이 배포되어야 한다.
반면, MSA를 도입하게 되면 고객 전담 마이크로서비스에서 요구사항을 모두 반영한다. 해당 서비스는 비즈니스 도메인을 기반으로 나뉘어, 변경하기 쉽게 하고 팀을 조직 내 비즈니스 분야에 더 수월하게 맞추도록 해준다.
1.3 모놀리스
MSA는 모놀리식 아키텍처의 대안인 아키텍처 접근 방식으로 가장 자주 거론된다. 따라서 MSA를 더 명확히 식별하고 마이크로서비스가 고려할 만한 가치가 있는지 더 잘 이해할 수 있도록 모놀리스의 정확한 의미도 함께 논의해야 한다.
여기서 모놀리스란 시스템의 모든 기능이 함께 배포되어야 하는 시스템을 말한다. 모놀리스에 속하는 형태가 많지만, 그 중에서도 단일 프로세스형 모놀리스, 모듈식 모놀리스, 분산형 모놀리스에 대해서 알아보자.
1.3.1 단일 프로세스형 모놀리스
단일 프로세스형 모놀리스에서 모든 코드는 한 프로세스에 패키징된다.
이와 같은 단일 프로세스형 모놀리스는 소규모 조직에 적합하다. 그러나 조직이 성장하면서 모놀리스 역시 잠재적으로 함께 성장하게 되고, 그에 따라 모듈식 모놀리스로 전환된다.
1.3.2 모듈식 모놀리스
단일 프로세스형 모놀리스의 서비셋인 모듈식 모놀리스는 단일 프로세스가 별도의 모듈로 구성된 변형이다. 각 모듈은 독립적으로 작업할 수 있지만 배포하려면 모두 다 합쳐져야 한다.
많은 조직에서 모듈식 모놀리스는 훌륭한 선택이 된다. 모듈 경계가 잘 정의된다면, 횔씬 더 간단한 배포 토폴로지를 활용함으로써 분산된 마이크로서비스 아키텍처의 문제를 피하면서도 높은 수준으로 병행 작업을 할 수 있다. 모듈식 모놀리스의 한 가지 문제점은 데이터베이스가 코드 수준으로 분해되지 않아서 미래에 모놀리스를 분해하려면 상당한 어려움에 직면한다는 것이다.
1.3.3 분산형 모놀리스
분산 모놀리스는 여러 서비스로 구성되는 시스템이지만 어떤 이유로든 전체 시스템을 함께 배포해야할 때 분산 모놀리스라고 정의한다. 예를 들어 여러 서비스로 구성된 시스템에서 인증 로직을 각자의 서비스에서 구현하고 있다면, 인증 정책이 추가될 때 마다 인증 서비스만 배포하는 것이 아니라 전체 시스템을 함께 배포해야하는 한다. 이러한 환경을 분산 모놀리스라고 한다. 분산 모놀리스는 결합도가 매우 높은 아키텍쳐를 만들어내며 지역적인 범위에서의 변경사항이 외부까지 영향을 미쳐 시스템의 다른 부분을 망가뜨린다.
분산형 모놀리스는 분산 시스템과 단일 프로세스형 모놀리스의 단점을 모두 갖고 있지만, 두 시스템의 장점은 충분히 갖추지 못한 구조이다.
1.3.4 모놀리스와 전달 경합
점점 더 많은 사람이 같은 장소에서 작업함에 따라 서로의 작업을 방해하게 된다. 예를 들어 서로 다른 개발자가 동일한 코드를 변경하려 하고, 서로 다른 팀이 다른 시간에 라이브하길(또는 배포를 지연하길) 원하며, 누가 무엇을 소유하고 누가 결정을 내리는지에 대해 혼란을 겪는다. 많은 연구에서 이와 같이 소유권에 혼선이 생기는 문제를 제기해왔다. 필자는 이 문제를 전달 경합이라고 부른다.
이는 코드베이스가 커질수록, 작업 영역을 공유하는 개발 인원이 많을수록 더욱 빈번하게 발생할 수 있다.
1.3.5 모놀리스의 장점
분산 시스템에 비해, 개발자 워크플로가 횔씬 더 단순해지며 모니터링, 문제 해결, 엔드투엔드 테스팅 같은 활동들이 크게 간소화될 수 있다. 또 모놀리스는 자기 내부에서 코드를 더 쉽게 재사용할 수 있다.분산 시스템 내에서 코드를 재사용하려면 코드를 복사할지, 라이브러리를 분리할지, 공유 기능을 서비스로 내보낼지 결정해야 한다.
모놀리스를 사용하면 선택지가 횔씬 더 단순해지고 많은 사람이 그 단순함을 좋아한다. 모든 코드가 거기 있으니 그냥 사용하면 된다.
MSA 도입을 고려할 때, 모놀리스를 레거시와 동의어라고 여기는 개발자들이 종종 있다. 모놀리식 아키텍처는 선택이며, 무엇보다 당시에는 타당한 선택이었음을 잊어선 안된다. 모놀리식 아키텍처는 합리적인 기본 선택이다. 즉, 필자는 마이크로서비스를 사용하지 못할 이유를 찾는 대신에 마이크로서비스를 사용할 확실한 이유를 찾는 것이 중요하다.
1.4 활성화 기술
MSA를 최대한 활용하도록 해주는 도구를 이해하는 것은 마이크로 서비스를 성공적으로 구현하기 위한 핵심 부분이다. 사실 마이크로서비스는 논리적 아키텍처와 물리적 아키텍처를 구반하는 이전의 방식이 문제가 될 만큼 지원 기술을 제대로 이해하려는 노력이 절실하다. 따라서 마이크로서비스 아키텍처를 형성하는 데 관여하고 있다면 이 두 세계를 폭넓게 이해해야 한다.
처음부터 새로운 기술들을 많이 채택할 필요는 없다. 다만, MSA를 확장하면서 점차 분산되는 시스템으로 인해 발생하는 문제의 원인을 찾고 해결하는 데 도움을 주는 기술들을 도입하는 것이 중요하다.
1.4.1 로그 집계와 분산 추적
MSA 채택하기 위한 전제 조건으로 로그 집계 시스템을 구현할 것을 강력히 주장한다. MSA를 시작할 때 너무 많은 기술을 도입하는 것에 유의해야 한다. 다만, 로그 집계 도구는 매우 중요하므로 MSA를 채택하기 전에 꼭 준비되어야 한다.
로그 집계 시스템을 사용하면 모든 서비스에서 로그를 수집하거나 집계하고 한 곳에서 분석할 수 있으며, 능동적인 경보 메커니즘 일부도 만들 수 있다.
연관된 서비스 호출에 사용되는 단일 ID인 상관관계 ID를 구현해 이러한 로그 집계 도구를 횔씬 유용하게 만들 수 있다.
위 그림과 같이, 하나의 API 호출 시 여러 서비스 호출 내역을 종합적으로 조회할 수 있는 시스템이 구성되어야 한다. 위처럼 분산 추적을 통해 여러 마이크로서비스에 걸친 작업이 소요되는 시간을 식별할 수 있어야 한다.
1.4.2 컨테이너와 쿠버네티스
각 마이크로서비스 인스턴스를 격리해 실행하는 것은 이상적이다. 이렇게 하면 한 마이크로서비스의 문제가 다른 마이크로서비스에 영향을 미치지 않게 할 수 있다.
컨테이너는 서비스 인스턴스를 위한 격리된 실행 환경을 프로비저닝하는 횔씬 더 가벼운 방법을 제공하므로, 많은 아키텍처에서 비용 효율도 횔씬 더 높을 뿐 아니라 새로운 컨테이너 인스턴스의 시작 시간도 더 빨라진다.
컨테이너를 갖고 놀기 시작하면, 많은 하부 머신에서 컨테이너를 관리할 수 있는 무언가가 필요하다는 점을 깨닫게 된다. 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼은 이에 꼭 맞는 일을 수행하는데, 하위 머신을 효율적으로 사용하면서 서비스에 요구되는 견고함과 처리량을 제공하는 방식으로 컨테이너를 분산시킨다.
배포 관리의 오베헤드가 심각한 골칫거리가 되기 시작했다면 서비스의 컨테이너화와 쿠버네티스의 사용을 고려하라. 사용하기로 했다면, 공용 클라우드 제공업체의 관리형 서비스를 이용하는 것처럼 다른 사람이 쿠버네티스 클러스터를 여러분을 대신해 운영하도록 하는 것이 최선이다. 자체 쿠버네티스 클러스터를 실행하는 것은 상당한 양의 작업이 될 수 있기 때문이다.
1.4.3 스트리밍
각 마이크로서비스 간에 데이터를 공유하는 방법이 필요하다. 조직이 리포팅 배치 작업 방식에서 벗어나 더 신속하게 반응할 수 있도록 실시간 피드백을 원하는 현상과 함께 발생하고 있다. 따라서 대용량 데이터를 쉽게 스트리밍하고 처리하는 제품은 마이크로서비스 아키텍처를 사용하는 사람들에게 인기를 얻고 있다.
많은 사람에게 아파치 카프카는 다양한 이유로 마이크로서비스 환경에서 데이터를 스트리밍하기 위한 실질적인 선택지가 됐다.
추후 더욱 자세하게 알아보자.
1.4.4 공용 클라우드 및 서버리스
마이크로서비스가 늘어나면 더 많은 작업이 점차 운영 영역으로 이동될 것이다. 공용 클라우드 제공업체는 관리형 데이터베이스 인스턴스나 쿠버네티스에서 메세지 브로커나 분산 파일 시스템에 이르기까지 많은 관리형 서비스를 제공한다. 관리형 서비스를 사용하면 이러한 작업을 더 잘 처리할 수 있는 제삼자에게 많은 양의 작업을 넘길 수 있다.
MSA를 도입하면, 모놀리식에 비해 부가적으로 사용해야 하는 서비스 및 작업들이 굉장히 늘어난다. 이 때, 작업량을 줄이고 핵심적인 부분에 집중하려면 지혜롭게 AWS와 같은 클라우드 제공업체의 완전 관리형 서비스를 사용하는 것이 중요하다고 생각한다.
1.5 마이크로서비스의 장점
정보 은닉과 도메인 지향 설계의 개념을 분산 시스템의 역량과 결합함으로써 마이크로서비스는 다른 형태의 분산 아키텍처에 비해 상당한 이점을 제공할 수 있다.
정보 은닉은 자기 상태 소유라는 특성과 연관된다.
1.5.1 기술 이질성
다수의 협력하는 마이크로서비스들로 구성된 시스템이라면 각 마이크로서비스에 서로 다른 기술을 사용하기로 결정할 수 있다.
마이크로서비스를 사용하면 기술을 더 빨리 채택할 수 있어, 해결해야 하는 문제 상황에 알맞은 기술을 선택할 수 있는 환경을 제공한다.
1.5.2 견고성
애플리케이션의 견고성을 향상시키는 핵심 개념은 벌크헤드(선박에 있는 각 방을 막는 칸막이벽을 말하며 '격벽'이라고도 한다. 시스템의 구성 요소 중 하나가 고장 날 수 있지만, 그 고장이 연속적으로 발생하지 않는 한 문제를 격리하고 나머지 시스템은 계속 작동할 수 있다. 서비스 경계는 명백한 벌크헤드(격벽)가 된다. 마이크로서비스를 사용하면일부 구성 서비스의 전체 장애를 처리하고 그에 따라 기능을 저하시키는 시스템을 구성할 수 있다.
모놀리식 시스템에선 하나의 서비스의 장애가 전체 서비스의 장애로 이어진다. 하지만 MSA에서는 하나의 서비스는 일부 서비스의 장애이다. 그러나 MSA 환경에서는 분산 시스템에서 네트워크로 인해 발생될 문제들을 유의해야 한다.
1.5.3 확장성
대규모 모놀리식 서비스에서는 모든 것을 함께 확장해야 한다. 전체 시스템의 작은 한 부분에 성능 제약이 있어서 해당 동작이 거대한 모놀리식 애플리케이션에서 확장이 제한된다면 모든 것을 한 덩이로 확장해야 한다.
확장성 측면에서 모놀리식 시스템이 갖는 단점이다.
시스템의 핵심 부분을 분리해, (해당 서비스 인스턴스만 느리면 되므로) 트래픽 급증에 더 잘 대처할 수 있다.
1.5.4 배포 용이성
마이크로서비스를 이용하면 하나의 서비스만 변경하고 시스템의 다른 부분과는 독립적으로 배포할 수 있다.
1.5.5 조직적 정렬
마이크로서비스를 이용하면 아키텍처를 조직 구조에 맞게 더 적절히 정렬할 수 있꼬, 팀 크기와 생산성의 최적점에 도달하기 위해 하나의 코드베이스에서 일하는 인원을 최소화할 수 있다.
1.5.6 조합성
마이크로서비스를 써서 외부 당사자가 사용할 시스템의 접합부를 개방한다고 생각해보자. 주위 상황이 바뀌면 다양한 방식으로 애플리케이션을 구축할 수 있다. 모놀리식 애플리케이션의 경우 외부에서 사용할 수 있는 하나의 큰 접합부가 있는 경우가 많다.
1.6 마이크로서비스의 고충
마이크로서비스 아키텍처를 채택하려면 좋은 점과 나쁜 점을 비교하는 것이 중요하다.
1.6.1 개발자 경험
로콜에서 실행 가능한 수가 제한되며, 이로 인해 한 머신에서 전체 시스템을 실행할 수 없을 때는 어떻게 해야 하는지 논의해봐야 한다.
이는 서비스가 많아졌을 때 발생될 수 있는 문제이다. 책에서는 "개발자가 작업해야 하는 시스템 영역의 범위를 제한하는 것"이 이 문제를 해결하는 단순한 접근 방법이라 제시한다.
1.6.2 기술 과다
마이크로서비스를 도입하기 싲가하면 데이터 일관성, 지연 시간, 서비스 모델링 등과 관련된 문제를 이해하는 데 많은 시간을 할애해야 한다.
1.6.3 비용
단기적으로는 여러 요인으로 인해 비용이 증가할 가능성이 높다.
경험에 따르면, 마이크로서비스는 주로 비용 절감에 관심을 둔 조직에는 적합하지 않다.
따라서 MSA 전환을 도입하는 조직이라면, 비용을 미리 추산해보는 것도 중요할 것이다.
그 외
그 외에도 1.6.4 리포팅, 1.6.5 모니터링과 문제 해결, 1.6.6 보안,1.6.7 테스팅, 1.6.8 지연 시간, 1.6.9 데이터 일관성 등의 관점에서 어려움이 생긴다.
1.7 마이크로서비스를 사용해야 하는가?
1.7.1 마이크로서비스가 적합하지 않은 곳
안정적인 서비스 경계를 정의하는 것이 중요하다는 점을 감안하면 마이크로서비스 아키텍처는 새로운 제품이나 스타트업 기업에는 적합하지 않은 선택이다.
일반적으로는 서비스 경계를 정의하기에 앞서 도메인 모델이 충분히 안정화될 때까지 기다리는 것이 적절하다.
경험 상, 신사업팀이거나 초기 스타트업이라면 서비스가 계속 확장되고 추가되서 서비스 경계를 명확하게 나눌 수 없는 상황인 경우가 많다. 따라서 MSA를 적용하는 것이 적합하지 않을 수 있다. 코드베이스가 겹쳐 문제가 발생하는 경우도 있기 때문이다. 이럴 땐 MSA보다 멀티 모듈을 먼저 도입함으로써 전달 경합 문제를 줄이고, 추후 서비스 가 안정화되면 도입을 고려해보는 것이 좋다.
1.7.2 마이크로서비스가 적합한 곳
조직에서 마이크로서비스를 도입하는 가장 큰 이유는 더 많은 개발자가 서로 방해하지 않고 동일 시스템에서 작업하기 위해서다. 아키텍처와 조직의 경계를 올바르게 설정하면 더 많은 사람이 서로 독립적으로 작업하도록 전달 경합 문제를 줄일 수 있다. 다섯 명으로 구성된 스타트업에서는 마이크로서비스 아키텍처가 걸림돌이 될 우려가 크다. 반면에, 100명 규모로 빠르게 성장하는 회사라면, 제품 개발 노력을 중심으로 마이크로서비스 아키텍처를 적절히 배치함으로써 성장을 수용하기가 횔씬 더 쉽다는 사실을 깨달을 것이다.
SaaS 애플리케이션은 일반적으로 마이크로서비스 아키텍처에도 잘 맞는다.
마이크로서비스의 기술 중립적 특성 덕분에 클라우드 플랫폼을 최대한 활용할 수 있다.
결론, MSA 도입 전에 고려해야 하는 것들은 무엇인가? 한다면 어떻게 전환해야 하나?
우리가 개발 중인 서비스가 어느 단계인지 파악하자. 서비스 안정화 단계인가? 혹은 계속 사업이 확장되고 있나? 그로 인해 기존 도메인의 변경이 예상되는가? 그렇다면 MSA를 도입할 상황이 아닐 가능성이 높다.
MSA는 왜 도입해야 할까? 개발자가 늘어나면서, 너무 큰 코드베이스로 인해 전달 경합 문제가 발생하는 경우. 또 배포 시간이 너무 오래 걸리거나 높은 결합도로 인해 배포 시, 수정하지 않은 다른 영역에서 문제가 발생한다거나 하는 등의 문제가 발생해서 서비스의 독립적인 배포가 필요한 경우 도입을 고려해보는 것이 좋다.
만약 도입을 결정했다면 어떻게 해야 할까? 여러차례 언급 한 것처럼 점진적으로 도입하는 것이 좋다. 먼저 백엔드 → 데이터베이스(데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다.
또 마이크로서비스 전환이 시작되는 시점부터 반드시 데이터베이스를 분리해야 하는가? 라는 질문에는 반드시 초기부터 데이터를 구분할 필요는 없다. 그리고 데이터베이스를 구분하는 것은 단순히 물리적인 공간을 구분하는 것이 아닌 데이터의 정합성, 연속성을 보장하기 위해 많은 노력과 비용이 발생하는 아키텍처 패턴임을 명심해야 한다.
댓글