[스프링 마이크로서비스 코딩 공작소] 1장. 스프링 클라우드와 만나다 - 1부

garam0410·2022년 8월 22일
0
post-thumbnail
post-custom-banner

1.1 마이크로 서비스 아키텍처로 진화

  • 소프트웨어 아키텍처는 소프트웨어 구성 요소 간 구조, 동작, 상호 작용을 하는 모든 기초 부분과 관련 됨

  • 이 책에서는 적은 수의 명확한 작업을 수행하고 네트워크를 통해 메시지로 통신하며 느슨하게 결합된 소프트웨어 서비스로 구성된 마이크로서비스 아키텍처(MSA) 의 구성방법을 설명

1.1.1 N-계층 아키텍쳐

일반적인 아키텍처 유형중 하나는 다계층 또는 N-계층 아키텍처
이 디자인에서 어플리케이션은 UI, 서비스, 데이터, 테스팅 등 고유의 책임과 기능이 있는 여러 계층으로 나뉨
결국 전체 어플리케이션을 만드는 여러 프로젝트가 결합됨


N-계층 어플리케이션의 장점

  • 관심사가 잘 분리되어 있어 UI, 데이터, 비즈니스 로직 같은 영역을 따로 고려 가능
  • 팀이 N-계층 어플리케이션의 여러 컴포넌트에서 독립적으로 작업하기 쉬움
  • 널리 알려진 엔터프라이즈 아키텍처이기 때문에 숙련된 N-계층 프로젝트 개발자를 찾기 수월

N-계층 어플리케이션의 단점

  • 변경을 적용하려면 전체 서비스를 재시작해야함
  • 메시지가 상하 전체 계층에 걸쳐 있으므로 비효율적일 수 있음
  • 대규모 N-계층 어플리케이션이 배포되고 나면 리펙토링이 힘들 수 있음

1.1.2 모놀리스 아키텍처

중소 규모의 많은 웹 어플리케이션은 모놀리스 아키텍처 형태로 구축
모놀리스 아키텍처에서의 어플리케이션은 하나의 산출물 (1개의 프로젝트)
모든 UI, 비즈니스, 및 데이터 베이스 엑세스 로직은 함께 고유한 어플리케이션으로 패키징, 서버에 배포
마이크로 서비스 아키텍처 옹호자들은 모놀리스를 부정적으로 설명하지만 때로는 훌륭한 선택지가 되기도 함
모놀리스는 N-계층 또는 마이크로 서비스 같은 복잡한 아키텍처보다 구축 및 배포가 쉬움
사용사례가 잘 정의되어 있고(사례가 많다는?) 변경 가능성이 낮다면 모놀리스로 시작하는 것이 좋음

  • 사내 맞춤형 고객관리(CRM) 어플리케이션의 모놀리스 구성

하지만 어플리케이션의 크기와 복잡성이 증가하기 시작하면 모놀리스를 관리하는 것 즉, 유지보수가 어렵게 될 수 있음
모놀리스에 대한 모든 변경이 사이드 이펙트를 유발할 수도 있고, 이 때문에 운영 환경의 시스템에서는 더 많은 시간과 비용이 소요될 것
마이크로서비스 아키텍처는 유연함과 유지 보수의 이점을 더 많이 제공


1.1.3 마이크로서비스란?

마이크로 서비스는 작고 느슨하게 결합된 분산 서비스
대규모 어플리케이션을 책임이 명확하고 관리하기 쉬운 구성 요소로 분해할 수 있음
잘 정의된 작은 조각으로 분해해서 대규모 코드베이스에서 발생하는 전통적인 복잡성 문제를 해결하도록 도울 수 있음

마이크로 서비스를 고려할 때 이해해야 할 핵심 개념은 분해분리

  • 사내 맞춤형 고객관리(CRM) 어플리케이션의 마이크로서비스 구성

위 그림은 각 팀이 어떻게 그들의 서비스 로직과 서비스 인프라를 완전히 소유하는지 보여줌
팀의 코드, repository, infra가 모두 독립적으로 존재하기 때문에 상호 독립적으로 빌드, 배포, 테스트가 가능


마이크로서비스 아키텍처의 특징

  • 어플리케이션 로직은 명확하고 대등한 책임 경계가 있는 작은 컴포넌트로 분해
  • 각 구성요소는 작은 책임 영역을 담당하고 서로 독립적으로 배포
  • 한 마이크로 서비스는 소비자와 공급자 간 데이터를 교환하고자 HTTP와 JSON같은 경량 프로토콜 사용
  • 마이크로서비스 어플리케이션은 항상 기술 중립적 포맷(대표적으로 JSON과 같은...) 사용해서 통신하기 때문에 서비스 하부 기술 구현과 무관
  • 즉, 마이크로서비스 방식으로 구축된 어플리케이션은 다양한 언어와 기술의 조합을 가져갈 수 있음
  • 작고 독립적이고 분산적인 마이크로서비스 특징 덕분에 조직은 팀을 더 작게 만들고 명확한 책임영역 부여 가능
  • 각각의 팀은 모두가 하나의 목표를 가지지만, 작업하는 서비스에만 책임을 가지게 됨

1.1.4 어플리케이션 구축 방법을 왜 바꾸어야 할까?

  • 복잡성 증가
  • 고객은 더 빠른 전달을 원함
  • 고객 또한 안정적인 성능과 확장성을 요구
  • 고객을 어플리케이션을 언제든 사용할 수 있기를 기대

이러한 이유 때문에, 확장성과 중복성이 높은 어플리케이션을 구축하려면 독립적으로 빌드, 배포할 수 있는 작은 서비스로 분해해야 함.
어플리케이션을 더 작은 서비스로 분리하고 단일 모놀리스 형태에서 서비스 산출물을 추출하면 아래와 같은 시스템을 구축할 수 있음

  • 유연성
    -분리된 서비스는 새로운 기능을 신속하게 제공할 수 있도록 구성 및 재배치 가능
    -다른 것과 함께 작동하는 코드가 적을 수록 코드 변경에 따른 복잡성도 낮아지고 코드의 테스트 및 배포 시간도 줄어듦
  • 회복성
    -분리된 서비스는 어플리케이션이 더이상 한 부분의 저하로 전체가 고장나는 어플리케이션이 아님을 의미
    -고장은 어플리케이션 일부분에 국한되어 전체 장애로 확대되기 전에 억제
    -회복 불능의 에러인 경우에도 어플리케이션이 원만하게 저하되도록 함
  • 확장성
    -분리된 서비스는 여러 서버에 쉽게 수평 분산이 가능
    -기능과 서비스를 적절히 확장하게 해줌
    -모든 기능이 뒤얽혀 있어 어플리케이션 일부분만 문제가 발생해도 전체 어플리케이션을 축소해야하는 모놀리스와 달리 작은 서비스를 사용하기 때문에 확장가능하며 비용 효율도 높음

마이크로 서비스는 작고, 단순하고, 분리된 서비스 이며 이는 확장가능하고 회복적이며 유연한 어플리케이션 을 의미

post-custom-banner

0개의 댓글