[마이크로서비스 아키텍처 구축] 1. 기초 (MSA 개념)

해당 글은 마이크로서비스 아키텍처 구축에서 학습한 내용을 다룹니다.

 

0. 개요

1. 마이크로서비스란?
2. 마이크로서비스 핵심 개념
3. 모놀리스
4. 모놀리스의 장점
5. 마이크로서비스에 도움이 되는 활성화 기술
6. 마이크로서비스의 장점
7. 마이크로서비스의 고충
8. 마이크로서비스를 사용해야 하는가?

 

 

1. 마이크로서비스란?

 

마이크로서비스(microservice)는 비즈니스 도메인에 따라 모델링된 독립적으로 릴리스 가능한 서비스로, 기능을  캡슐화하고 네트워크를 통해 다른 서비스들에 엑세스하게 해준다.

(편의를 위해 마이크로 서비스는 마이크로서비스 아키텍쳐(microservice architecture), 이하 MSA로 소개한다.)

 

배송 이라는 MSA의 구조 예시이다.

 

• 외부에서 보면, 하나의 MSA는 블랙박스로 취급된다.
• 가장 적절한 프로토콜을 사용해 1개 이상의 네트워크 엔드 포인트(Message Queue or REST API)를 통해 비즈니스 기능을 호스팅
• 결론적으로 서비스 프로그래밍에 대한 기술이나 데이터 저장 방식과 같은 상세 내부 구현 정보는 외부 세계에서 완전히 은폐됨
• 이러한 점은 MSA가 대부분의 상황에서 공유 DB 사용을 지양하는 것을 의미
• MSA 경계 내부의 변경은 업스트림 소비자에게 영향을 미치지 않으므로 독립적인 기능 릴리즈가 가능
  • 업스트림(upstream) 시스템 : 인접 시스템에 데이터를 전송하는 시스템
  • 다운스트림(downstream) 시스템 : 인접 시스템에 데이터를 수신하는 시스템

 

 

2. 마이크로서비스 핵심 개념

 

1. 각 서비스별 독립접 배포성을 지님
2. 비즈니스 도메인 중심의 모델링 (DDD)
   • 여기서 DDD는 서비스를 비즈니스 기능 단위로 (수직으로) 처음부터 끝 까지 한 조각으로 만드는 것으로 비유
   • 기술적 기능의 높은 응집력보다 비즈니스 기능의 높은 응집력을 더 선호하는게 DDD의 핵심
   • 전통적인 계층형 아키텍처에서는 기능 변경이 필요될 경우, 여러 계층에 걸쳐 변경이 필요되지만, DDD를 도입할 경우 비즈니스 로직 변경이 여러 계층에 영향을 전파하는 것을 상대적으로 최소화 할 수 있음
3. 자기 상태 소유
   • 공유 DB 사용을 자제 해야함 (다른 MSA 서비스의 DB에 접근하려면 REST API와 같은 방법으로 데이터를 요청)
   • 이는 MSA에서 어떤 데이터를 공유하고 감출지를 결정하는데, 객체 지향 프로그래밍에서 캡슐화와 유사함
4. 수용 가능한 크기와 유연성
   • MSA서비스의 크기를 얼마만큼 쪼개는지는 담당 팀에서 얼마나 많은 MSA를 처리할 수 있는지에 달려있음
     • 무조건 잘게 쪼갠다고 능사가 아님
   • MSA는 '스위치를 켜는 것'이 아니라 '다이얼을 돌리는 것'과 같음

 

 

3. 모놀리스

여기서 언급하는 모놀리스는 배포 단위를 말한다.

 

1. 단일 프로세스형 모놀리스

이미지 출처 (클릭)

• 모든 코드가 단일 프로세스(single process)로 배포되며, 이는 소규모 조직에 적합한 사례

 

2. 모듈식 모놀리스

이미지 출처(클릭)

• 모듈식 모놀리스는 MSA에서 배포 순서가 중요하다는 한계점을 돌파하는데 도움이 됨
• 만약 위와 같은 구조에서 MSA로 전환할 경우, 공유 DB를 쓰는게 아니라 각 모듈당 독자적인 DB와 연결되어야 추후 분리 작업에서 어려움이 없다는 것이 특징

 

3. 분산형 모놀리스

• 여러 서비스로 구성된 시스템이지만, 어떤 이유든 전체 시스템을 함께 배포해야하는 아키텍처

 

4. 모놀리스와 전달 경합

• 서로 다른 개발자가 동일한 코드를 변경하려 하고, 서로 다른 팀이 다른 시간에 라이브를 원하며, 누가 무엇을 소유 - 결정하는 지에 혼란을 겪는다. 이러한 문제를 전달 경함(delivery connection)이라고 부름
• MSA에서는 시스템에서 소유권 라인을 중심으로 표시될 수 있는 더 구체적인 경계를 제공하므로, 이 문제를 해소하는데 훨씬 유연함

 

 

4. 모놀리스의 장점

• 훨씬 단순한 배포 토폴로지는 분산 시스템과 관련된 많은 함정을 피할 수 있음
• 이로인해 가발자의 워크플로가 훨씬 더 단순해지며, 모니터링, 문제 해결, 엔드투엔드 테스팅 (이하 테스트 코드 작성) 같은 활동도 크게 간소화 될 수 있음
• 모놀리스는 자기 내부에서 코드를 더 쉽게 재사용 할 수 있음
• 모놀리스 != 레거시, 상황에 따라 합리적인 선택일 수 있음

 

 

5. 마이크로서비스에 도움이 되는 활성화 기술

 

MSA 도입시 새로운 기술을 많이 채택할 필요는 없으며, 서비스를 확장하면서 점차 분산되는 시스템으로 인해 발생하는 문제를 지속적으로 찾고 도입하면 된다.

 

1. 로그 집계와 분산 추적

• 로그 집계 도구는 매우 중요하며, MSA를 채택하기 전에 준비해야 함
• 오픈 소스 중 예거는 방정식의 분산 추적 측면에 중점을 둔 기능을 제공

2. 컨테이너와 쿠버네티스

• 각 마이크로서비스 인스턴스를 격리해 실행하는 것이 이상적
  • 이로 인해 한 마이크로서비스가 다른 마이크로서비스에 영향을 미치지 않게 할 수 있음
• 가상화는 기존 하드웨어에 격리된 실행 환경을 만드는 한 가지 방법이지만, 크기를 고려할 때 상당히 무거울 수 있음
• 반면 컨테이너는 서비스 인스턴스를 위한 격리된 실행 환경을 프로비저닝하는 훨씬 더 가벼운 방법을 제공
• 많은 하부 머신에서 컨테이너를 관리할 수 있는 플랫폼 중 하나는 쿠버네티스와 같은 오케스트레이션 플랫폼
  • 이는 하위 머신을 효율적이게 사용하면서 서비스에 요구되는 견고함과 처리량을 제공하는 방식으로 컨테이너를 분산 시킴
• 단, 컨테이너와 쿠버네티스 모두 MSA 도입시 필수적으로 채택할 필요는 없으며, 마이크로서비스가 몇 개만 있는 경우라면 더더욱 필요 없음
• 배포 관리의 오버헤드가 커지기 시작하면 그 때 서비스의 컨테이너화와 쿠버네티스 도입을 고려하면 됨

3. 스트리밍

• MSA에서 데이터를 보다 안정적이고 신속하게 공유할 수 있는 방법이 필요한데, 이는 대용량 데이터를 쉽게 스트리밍 할 수 있는 방법이 필요함을 뜻함
• 아파치 카프카는 이를 위한 선택지로 많이 채택됨
  • 메세지의 영구성, 압축, 대용량 메세지를 처리할 수 있는 확장 기능 등을 제공

4. 공용 클라우드 및 서버리스

• 구글 클라우드, 마이크로소프트 애저, 아마존 웹 서비스는 다양한 서비스와 배포 옵션을 제공
  • 관리형 DB 인스턴스, 쿠버네티스에서 메세지 브로커, 분산 파일 시스템 등의 관리 서비스를 제공
• 이들은 하부 머신을 숨겨 더 높은 추상화 수준에서 작업할 수 있는 환경을 제공

 

 

6. 마이크로서비스의 장점

1. 기술 이질성
   • 각 MSA는 서로 다른 기술을 사용할 수 있으며, 더 나은 기술 스택을 사용할 수 있음
     • 모놀리틱 어플리케이션의 경우, 새로운 기술을 도입함에 있어 변경 사항이 많은 시스템에 영향을 끼칠 수 있음
   • MSA 서비스가 많아질 수록 새로운 기능을 도입할 수 있는 서비스가 많다는 뜻이므로, 이중 가장 위험성이 낮은 MSA 서비스를 골라 기술을 적용할 수 있음
2. 견고성
   • 어플리케이션의 견고성을 향상시키는 핵심 개념은 벌크헤드(bulkhead)
     • 선박에 있는 각 방을 막는 칸막이 벽을 뜻하며, '격벽'이라고도 함. 침수(장애)의 전파를 막는 용도로 사용
   • 시스템의 구성 요소 중 하나가 고장날 수 있지만, 그 고장이 연속적으로 발생하지 않는한 문제를 격리하고 나머지 시스템은 계속 동작할 수 있음
   • MSA는 일부 구성 서비스의 전체 장애를 처리하고, 그에 따라 기능을 저하시키는 시스템을 구출할 수 있음
3. 확장성
   • 대부분 모놀리틱 서비스는 모든 것을 함께 확장해야 함
   • MSA는 다양한 방식으로 어플리케이션을 확장할 수 있음
4. 배포 용이성
   • 모놀리틱 어플리케이션에서 한 줄만 수정하더라도 변경 사항을 릴리즈하기 위해 전체 어플리케이션을 배포해야함
   • 이로인해 변경 사항이 누적되어 한 번에 릴리즈되는 경우가 있는데, 릴리즈 간 변화 폭이 클수록 무언가 잘못될 가능성이 있음
   • MSA에서는 하나의 서비스만 변경하고 시스템의 다른 부분과는 독립적으로 배포할 수 있음
   • 이는 더 빠른 배포와 빠른 롤백의 용이성을 제공
5. 조직적 정렬
   • 더 작은 코드베이스로 일하는 더 작은 팀이 생산적인 경향이 있음
   • 또한 조직 변경에 따라 서비스의 소유권도 바꿀 수 있어 향후 아키텍처와 조직간의 정렬 상태를 유지할 수 있음
6. 조합성
   • 분산 시스템과 서비스 지향 아키텍처가 보장하는 핵심 효용 중 하나는 재사용할 기회가 많다는 점
   • 이는 소비자가 소프트웨어를 어떻게 소비하는지 생각할 때 매우 중요
     • 단순 웹, 모바일 앱만 지원하는 시대는 지났으며, 이제는 웹, 네이티브 앱, 모바일 웹, 태블릿 웹, 더 나아가 웨어러블 장치와 같은 기능과 엮일 수 있음

 

 

7. 마이크로서비스의 고충

1. 개발자 경험
   • 부하가 적은 런타임이 있더라도 로컬에서 실행 가능한 수는 제한되며, 이에 따라 문제는 더 복잡해질 수 있음
2. 기술 과다
   • MSA를 도입하기 위한 새로운 기술들은 과도한 무게를 가질 수 있음
   • 이는 맹목적 기술 숭배로 이어질 수 있음
   • 때문에 신기술 도입은 필수가 아닌 선택이며, 다양한 기술이 가져올 비용과 사용하는 기술의 범위 및 복잡성을 신중히 저울질 해야함
   • 특히 MSA 도입 시 데이터 일관성, 지연 시간, 서비스 모델링 등과 같은 문제를 이해하는데 많은 시간이 필요됨
3. 비용
   • 더 많은 프로세스, 컴퓨터, 네트워크, 스토리지, 지원 소프트웨어를 요구함
   • 이로인해 팀이나 조직 변경이 발생하면 새로운 개념을 배우고 효과적으로 활용하는데 시간이 보다 많이 소요됨
   • 이러한 관점에서 MSA는 비용을 줄이는 방법이라기 보다는, 더 많은 수익을 창출하는 방법에 가까움
4. 리포팅
   • 모놀리틱의 경우, 주 DB에서 동일한 스키마를 가진 복제본 DB에 비동기식으로 데이터가 복제됐음 (이하 '리포팅')
   • MSA는 이 모놀리틱 스키마를 분해했으며, 데이터가 논리적으로 분산된 여러 스키마에 분산되어있기 때문에 리포팅을 실행하기가 더 어려워짐
5. 모니터링과 문제 해결
   • 모놀리틱 어플리케이션의 모니터링은 머신의 수도 적고 어플리케이션의 실패 유형도 대게 업 또는 다운과 같이 이분법적임
   • MSA에서는 단일 인스턴스가 다운될 때 미치는 영향, 또는 CPU 사용량이 오랜 시간 100%에 머무를 경우에 대한 영향과 해결 방식을 정확히 인지하고 있어야 함
6. 보안
   • 단인 프로세스의 모놀리티릭 시스템은 많은 정보가 프로세스 안에서 흐름
   • 하지만 MSA는 여러 네트워크를 거쳐 데이터가 교류되므로, 데이터 전송 중 외부에 그대로 노출되기 쉽고 조작될 가능성도 높아짐
   • 따라서 전송 중인 데이터와 마이크로서비스 엔드포인트를 보호해 권한 있는 당사자만 사용할 수 있도록 보장하는게 더 많은 주의를 기울여야 함
7. 테스팅
   • MSA에서는 분산된 서비스에 따라 테스트 시간도 오래 걸리고 테스트 데이터 및 지원용 픽스쳐(fixture) 설정이 더 어려워지며, 실패시 깨진 부분을 파악하기도 더 어려워 질 수 있음
     • 서비스 인스턴스가 죽거나, 실패한 배포에 대한 Time out 등, 환경적 이슈로 인해 테스트가 실패하는 거짓 음성(flase negative) 결과에도 대비해야 함
   • 또한 엔드-투-엔드의 테스트 범위는 상당히 늘어남
8. 지연 시간
   • 이전에 단일 프로세스 내에서만 이동하던 정보가 분산된 서비스들을 여럿 거침에 따라 네트워크를 통해 직렬화하고 전송하며 반대로 역직렬화도 해야함
   • 이러한 단계는 지연 시간(latency)를 악화시킴
   • 지연 시간은 MSA 이전을 저민적으로 수행해야하는 또 다른 중요한 이유가 됨
9. 데이터 일관성
   • 분산된 시스템으로 전환되면 데이터 일관성과 관련된 잠재적 문제가 발생함
   • 분산 시스템에서는 DB 트랜잭션을 통한 유사한 안정성을 쉽게 제공할 수 없다는 점을 이해해야 함

 

 

8. 마이크로서비스를 사용해야 하는가?

1. MSA가 적합하지 않은 곳
   • 새로운 제품이나 스타트 기업
   • 일반적으로 투입되는 인원이 적은 규모의 프로젝트일 경우, 더 많은 도전에 필요한 인력이 부족하므로 권장되지 않음
2. MSA가 적합한 곳
   • MSA를 도입하는 궁극적인 이유는 더 많은 개발자가 서로 방해하지 않고, 다시 말해 독립적으로 동일 시스템에서 작업하기 위함
   • 100명 규모로 빠르게 성장하는 회사라면 적합할 수 있음
   • SaaS(Software As A Servicee) 어플리케이션은 일반적으로 MSA가 적합함
     • 보통 24시간 연중무휴로 동작해야 하므로, 배포 시 어려움이 있지만 MSA의 독립적 릴리즈라는 특징이 큰 힘을 발휘함
   • FaaS(Function As A Service) 플랫폼은 적절한 워크로드에 대해 운영 오버헤드를 획기적으로 줄일 수 있지만, 현재로서는 모든 경우에 적합한 배포 매커니즘이라 할 수 없음