본문 바로가기
카테고리 없음

MSA Modeling

09297 2020. 5. 9. 12:27

Microservice Modeling 

 

  1. 클라우드의 개념 및 배경 

 

클라우드의 특징 

  • 민첩성 : On - demand 
  • 장치와 위치 독립성
  • 유지보수의 편리함
  • 다중 사용자 지원 
  • 재해 복구 용이 
  • autos-scaling을 통한 높은 확장성
  • 높은 서비스 탄력성 

 

주요벤더 

  • AWS
  • Azure
  • IBM
  • Oracle
  • pivotal

 

 

민첩성 있는 서비스를 위한 트렌드 

  • infra : cloud 
  • Architecture : Micro Service 
  • Culture : DevOps 

 

Cloud 환경의 등장 

  • 사용자는 사용한 만큼 과금 
  • 개발자는 필요한 만큼 과금 

 

scaling 방식

  • Scale - UP  : 수직확장, 메모리 늘리기, 좋은 성능의 CPU로 바꾸기 등, Instacnce를 더 좋은 것으로 교체하는 방식 
  • Scale - OUT : 수평확장, 고만고만한 성능의 Computer를 여러대로 늘리는 것 
  • Scale Out 방식이 훨씬 더 복잡하지만, Scale UP 방식은 서버를 재기동하는 과정 (어쩔수없이 서비스 중단) 이 필요하다 
  • MSA 형태의 아키텍쳐라면, 사용량이 많은 부분만 Scale out 하면 된다 
  • 인프라가 가변적으로 쉽게 변경되는 클라우드 환경은 수평확장을 위해 가장 효율적인 시스템이라고 할 수 있다. 

 

 

  1. 클라우드 어플리케이션 유형 

 

모노리스와 마이크로서비스 시스템(Monolith vs Microservice)

  1)Monolith 시스템

  • 하나의 단위로 개발되는 일체식 어플리 케이션 설계로 아무리 작은 변화라도 새로운 버전을 전체 빌드해서 배포해야 됨
  • 특정기능만 확장이 불가하고 확장 필요 시 덩어리를 복사해서 수평으로 확장을 해야됨. 

  2)Microservice 

  • 여러개의 서비스 프로세스가 모여 어플리케이션 구성 
  • 부분만 수평확장이 가능함. 
  • 업무단위로 확고한 모듈경계를 가짐

 

MicroService란 ? 

  • 여러 개의 작은 서비스 집합으로 개발하는 접근방법
  • 각 서비스는 개별 프로세스에서 실행
  • HTTP자원 API같이 가벼운 수단을 사용해서 통신함 
  • 서비스는 서로다른 언어, 데이터, 저장기술을 사용, 즉 인터페이스만 만족하면 서비스안의 기술은 자율적으로 선택할 수 있음 

** REST API : 가벼운 통신방식, 세션과 같은 상태정보를 가지지 않음 

 

SOA와 마이크로서비스 시스템(SOA vs MSA)

  • monolith -> SOA -> MSA ( 오른쪽으로 갈수록 결합도가 낮아진다)
  • micro service로 갈거면 내부적으로 어플리케이션만 나눌뿐 아니라 데이터베이스도 별도로 사용해야된다. 

 

MSA의 특징 

  • BIZ역량 중심의 팀 : 레거시시스템에서는 UI, 서버, DB 이런식으로 팀을 나눴다면 micro service system에서는 Biz역량 중심으로 팀을 나눠야된다. (Two pizza 팀!)
  • 분권거버넌스  : 팀은 빠르게 제품을 만드는것이 목적이기 때문에 중앙의 강력한 표준이나 절차의 준수를 강요하지 않음
  • 프로젝트가 아니라 제품 : Fast fail을 통해 빨리 실패하고 자주 실패경험을 개선함
  • 인프라 자동화 : 빠른 소프트에어 개발을 위해 CI/CD등을 만들어야함 ( 개발자원을 위한 인프라를 구축해야됨 -> 궁극적인 dev ops) 
  • 분권데이터관리 : 단일 통합 데이터베이스를 사용했던 과거와 달리 polyglot persistence 접근 방법을 사용해야함. 각 저장소 분산은 필수이며 다른 서비스 저장소는 호출이 불가능 하고 API만 통해 접근해야 됨 
  • smart endpoint an dumb pipes 방식을 선호  : 기존 SOA에서는 허브역할을 하는 UDDI및 ESB 서비스 채널이 필요 했으나 micro service 방식ㅇ서는 서비스 연결을 위한 rabbit MQ 나 Zero MQ 메시지 버스를 사용한다 
  • 실패를 위한 설계 : 언제든 실패할 수 있으며 실패해서 더이상 진행할 수 없을떄도 자연스럽게 대응할 수 있도록 자동테스트 환경 구축 및 실패감지/대응을 위한 실시간 모니터링 체게가 필요하다. 

 

** 결과적 일관성 ( Eventual consistency) : 주어진 데이터에 대한 변경이 없다면 해당 Element에 대한 모든 Access 는 가장 최근에 변경된 내용을 가리킨다. 다시말해 분산 시스템에서 데이터를 조회할 때 모든 시스템이 동일한 데이터를 가질 수 있다고 보장할 수는 없으나 결과적 일관성은 어느 시점에는 데이터가 다를 수 있지만, 결국에는 모든 시스템이 최신의 데이터를 가질 수 있도록 보장된다는 내용이다.

 

 

  1. Microservice architecture 개념 

리액티브 선언 : 현대 어플리케이션 아키텍쳐 변화의 흐름으로 응답성, 탄력성, 유연석, 메시지기반 서비스를 보장 

MSA 내/외부 아키텍쳐 (Outer architecture, Inner Architecture)  -> Outer service에 플랫폼, 인프라 , APP 등의 설계가 있고 APP의 core service 가 micro service로 구현되어야 함 

netflx oss : 넷플릭스가 msa로 가면서 겪은 시행착오를 모아놓은 open source site 

MSA history : 현재는 구글의 컨테이너 관리 시스템인 쿠버네티스가 대세로 떠오른 상태임

현대에서 가장 좋은 조합은 Spring Boot + 쿠버네티스의 조합 

 

  1. MSA Architecture 패턴들 

VM vs Container 

  • vm : 아무래도 오버헤드가 발생
  • container는 작은 서비스를 패키징 배포 할때 사용함, 컨테이너 기술중 가장 대표적인 컨테이너가 도커컨테이너 
  • 컨테이너의 장점은 뭐냐면 마치 화물에서 컨테이너 박스가 하는 역할이랑 똑같음. 하나하나 내용물을 조합할 필요없이 개발환경을 이미지로 만들어서 서버에 올려버리면 되서 서버에 개발환경을 다시 설치할 필요가 없음 
  • 컨테이너오케스트레이션 : 도커(컨테이너) 들을 자동 스케쥴링, 재스케줄링, 자동확장, 자동배포 해줌. 즉 컨테이너를 관리/지휘해주는 거임 
  • 변경 불가능한 인프라 -> 변경이 필요하면 걍 새로 구축해버려서 항상 clean 한 상태를 유지함 
  • CaaS 라는 개념이 생김 : 컨테이너 기반 가상화를 사용해서 컨테이너 업로드, 구성 , 실행 할 수 있는 서비스 

ex ) microsoft의 AKS, 아마존의 EKS, 구글의 쿠버네티스 , AWS ECS 등 

  • 코드로 통제하는 인프라 : DevOps 환경 구축 해서 인프라를 코드로 통제 
  • CI/CD : CI는 자동으로 통합하고 테스트하고 레포트로 남기는 활동 , CD는 실행환경에 자동으로 배포하는 것 
  • micro service는 배포 파이프라인이 여러개 일 수 있다. 
  •  

티스토리툴바