0. 들어가기 전
해당 포스팅은 인프런에 "Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)" 강의를 기반으로 작성됐습니다.
포스팅의 모든 사진 자료는 해당 강의 출처임을 밝힙니다.
4월 중순 MSA 관련 프로젝트를 진행하기 전 MSA 관련 개념들을 찍먹 해보기 위해서 스터디 모집 및 참여를 진행하게 됐습니다.
직전 프로젝트 시 도입하였지만, MSA의 장점과 정확한 기술에 대한 이해를 바탕으로 구현하지 못해서 아쉬웠는데 이번 기회에 제대로 공부해서 MSA의 장점을 살린 프로젝트를 만들어 볼 수 있도록 해보겠습니다.
스터디원 분들 모두 화이팅!
📖 학습 목표
- MSA에 대한 기본 개념에 대해 이해.
- MSA의 전반적인 구성요소 및 구조 이해.
- Spring Cloud에 대한 이해.
1. 소프트웨어 아키텍처
소프트 아키텍처의 역사
-
1960 ~ 1980s : Fragile, Cowboys
-
1990 ~ 2000s : Robust, Distributed
-
2010s ~ : Resilient/Anti-Fragile, Cloud Native
위를 보면 알 수 있듯이 2010년 이후 Anti-Fragile 과 Cloud Nartive 형태의 아키텍처 형태로 변경되었습니다.
Anti-Fragile 핵심 특징 4가지
Auto-Scaling
Auto-Scaling은 필요에 의해서 서버의 갯수를 maximum까지 늘렸다가, 다시 scale을 줄일 수 있도록 그룹화 하는 것을 의미합니다.
예를 들면, 쇼핑몰의 경우 성수기에 트래픽이 많으므로 서버 갯수를 최대(Max)로 늘렸다가 비수기 때 다시 서버를 최소(Min)로 줄여 비용 절감이 가능합니다.
Microservices
클라우드 네이티브 아키텍처의 핵심입니다.
기존 시스템 내부에 독립적인 기능이나 모듈을 별도로 개발 및 배포가 가능하도록 분리한 개념을 말합니다.
Chaos Engineering
시스템에서 예측하지 못했던 상황에도 견딜 수 있도록 신뢰성을 높이는 실행 방법 및 설계를 의미합니다.
운영중인 소프트웨어에서 안정적인 서비스 제공을 목표로 합니다.
Continuos Deployments
하나의 애플리케이션을 구성하는 마이크로 서비스를 배포하는 과정을 파이프라인으로 연결하여 자동화하는 것을 말합니다.
물론, 클라우드 네이티브 아키텍처 이전부터 사용됐던 개념이지만, 클라우드 기반의 아키텍처의 발전으로 인해 핵심 개념으로 자리매김 했습니다.
2. Cloud Native Architecture
Cloud Native Architecture 특징
확장 가능 아키텍처
시스템의 수평적 확장(scale-out)에 유연함.
확장된 서버로 시스템의 부하 분산, 가용성을 보장합니다.
💡 수평적 확장이란?
일반적으로 scaling을 위한 방식으로 2가지가 있습니다.
scale-up 방식과 scale-out 방식입니다.
- scale-up : 하드웨어 사양을 업그레이드 하는 방식(비용, 기술적 한계)
- scale-out : 동일한 사양의 하드웨어 갯수를 늘리는 방식.(비용적 한계)
- 클라우드 기술 발전으로 컨테이너 기반의 scale-out 가능.
탄력적 아키텍처
서비스 생성, 통합, 배포, 비지니스 환경 변화에 대응 시간이 단축됩니다.
마이크로 서비스간에 종속성이 낮고 독립적입니다.
이를 기반으로 서비스의 추가와 삭제가 간단하고, 이를 자동으로 감지하는 기술을 제공합니다.
장애 격리
특정 서비스의 오류가 시스템 전체에 영향을 미치지 않습니다.
Cloud Native Application
Cloud Native Application 이란, 클라우드 네이티브 아키텍처에 의해 설계 및 구현된 애플리케이션을 말합니다.
작성 편의를 위해 줄여서 클라우드앱 이라고 지칭하겠습니다.
해당 애플리케이션은 그림과 같은 4가지 요소를 포함하고 있습니다.
Microservices
클라우드앱은 마이크로 서비스 구조로 구성돼있습니다.
CI/CD
-
지속적인 통합(CI, Continous Integration)
분리된 서비스들을 형상관리 및 테스트, 빌드 등의 이유로 통합하는 과정을 합니다.
대표적으로 사용되는 CI 소프트웨어 → Jenkins, Team CI, Travis CI 등...
-
지속적인 배포(CD, Continous Deployment)
Continous Delivery : 통합된 소스 코드를 자동 CI 한 뒤 실행 환경에 반영을 수동으로 하는 것.
Continous Deployment : 통합된 소스 코드를 실행 환경에 배포하는 전과정을 자동화 하는 것.
DevOps
개발 조직과 운영 조직의 통합을 의미합니다.
고객의 요구사항에 빠르고 끊임 없이 수정이 가능하도록 구현하기 위한 기술입니다.
Container 가상화
클라우드 네이티브 아키텍처의 핵심 개념입니다.
적은 비용으로 탄력성 있는 시스템 구축이 가능하다는 장점이 있습니다.
- 전통 배포
하드웨어 + OS + App, App, ....
- 가상화 배포 : 결국 호스트 자원을 사용하기 때문에 제한적입니다.
하드웨어 + OS + Hypervisor + VM, VM, ...
- 컨테이너 배포 : 상대적으로 가볍고 빠릅니다.
하드웨어 + OS + 컨테이너 런타임(도커 실행환경 의미) + Container, Container, ...
3. 12 Factors
클라우드 서비스 중 PAAS(Platform As A Service) 형태의 서비스를 제공하는 Heroku 라는 기업에서 제시한 클라우드앱 운영 시 고려할 12가지 가이드입니다.
해당 항목들은 추후 애플리케이션 개발 시 조금 더 자세히 학습하도록 하겠습니다.
4. Monolithic vs. Microservice
모놀리식
모든 비지니스 로직이 하나의 애플리케이션 형태로 패키징 되어 제공되는 서비스를 말합니다.
단점은 일부 내용 수정 시 전체 애플리케이션을 중단 및 새롭게 패키징하여 배포해야 한다는 점입니다.
마이크로서비스
하나의 애플리케이션으로 작동하는 작은 규모의 서비스들을 말합니다.
마이크로 서비스는 최소한의 중앙 관리가 이뤄지며, 서비스 마다 서로 다른 언어와 데이터베이스 사용이 가능합니다.
5. Microservice Architecture란?
위 개념들을 기반으로 생각한 Microservice Architecture의 특징은 다음과 같습니다.
1) 기존의 개발 방식과 구조적 패러다임에 변화가 필연적입니다.
2) 배포가 가능한 형태의 작은 서비스들로 구분돼있습니다.
3) 애플리케이션을 구성하고 있는 각각의 도메인에 따라 서비스 경계를 잘 구분해야 합니다.
4) 클라이언트와 각 서비스 간에는 REST API를 기반으로 통신할 것을 권장합니다.
5) 마이크로 서비스에 관한 환경 설정 정보를 내부적으로 가지지 않고 외부 시스템을 통해 관리합니다.
6) Cloud Native 관련 기술을 사용하여 서비스를 제공합니다.
7) 각 서비스들 및 인스턴스는 부하분산 처리, 스케일 업 및 스케일 다운이 동적으로 가능하도록 구현합니다.
8) 다양한 서비스들로 분리되어 관리되기 때문에 빌드, 배포, 실행환경을 자동화 하는 것이 중요합니다.
9) 시각화 도구를 가지고 있어야 합니다.(관리 도구)
그렇다면 이러한 장점을 가진 MSA 구조를 도입하는 것이 무조건 옳을까요??
이는 아니라고 생각합니다.
MSA 도입 여부를 확인하기 위해서는 다음의 조건들을 확인해볼 필요가 있습니다.
1) Multiple Rates of Change : 변경 시 비용에 대한 공수를 따져봤는가?
2) Independent Life Cycles : 각 서비스 경계가 확실한가?
3) Independent Scalability : 각 서비스 유지보수 및 확장이 가능한가?
4) Isolated Failure : 각 서비스에 오류를 독립적으로 해결이 가능한가?
5) Simplify Interactions with External Dependencies : 외부 종속성과의 상호작용을 최소화 및 단순화 돼있는가?
6) Polyglot Technology : 다양한 스펙을 지원하는가?
6. SOA vs. MSA
SOA & MSA 차이점
서비스 공유 지향점
SOA : 재사용을 통한 비용 절감
MSA : 각 서비스 간의 결합도를 낮춰 변화에 능동적으로 대응 가능 여부
기술 방식(서버 간 통신)
SOA : 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스를 제공
MSA : 각 독립된 서비스가 노출된 REST API를 사용
7. Microservice Architecture Structures
서비스 메시(Service Mesh)
해당 서비스를 제공하여 안정적이고 효율적인 MSA를 지원하는 파트.
8. Spring Cloud란?
Spring Cloud 는 분산 시스템을 구축하고 운영하기 위한 스프링 프레임 기반의 라이브러리 모음을 말합니다.
📖 참고 포스팅
분산 설정(Distributed Configuration) :
MSA에서 필요한 설정을 중앙에서 관리하고 업데이트할 수 있도록 하는 기능입니다.
각 서비스는 설정을 동적으로 가져와 사용하며, 중지를 하지 않고도 설정을 변경하여 유연한 구성을 가능케합니다.
서비스 디스커버리(Service Discovery) :
서비스들의 위치와 상태를 자동으로 찾고 관리하는 기능입니다.
서비스 디스크버리의 역할 수행은 다음과 같습니다.
등록된 서비스 실행 시 디스커버리 시스템에 자동 등록되며, 서비스 종료 시 자동 삭제됩니다.
이를 통해 클라이언트 애플리케이션은 동적으로 사용가능한 서비스를 검색하고 선택할 수 있습니다.
로드 밸런싱 (Load Balancing) :
트래픽을 균등하게 분배하여 부하를 분산시키는 기술입니다.
스케일 아웃과 같은 기능을 통해 네트워크 트래픽을 효과적으로 관리합니다.
FeignClient :
Http 요청을 간편하게 만들어서 서버와 통신할 수 있도록 돕는 기능입니다.
API 게이트웨이(API Gateway) :
MSA에서 클라이언트와 서비스 간의 통신을 중앙에서 관리하는 서버입니다.
게이트웨이는 주로 라우팅, 인증, 보안, 로드 밸런싱, 캐싱 등의 기능을 담당하여 MSA를 더 효과적으로 관리하고 사용할 수 있도록 해줍니다.
장애 허용(Falut Tolerance) :
일부 서비스에서 오류가 발생하더라도 애플리케이션 자체는 정상적으로 또는 부분적으로 기능을 수행할 수 있도록 합니다.
📜 정리
예전에 한번 정리했었던 개념들이지만 안본지 오래돼서 잘 기억이 나지 않는 부분들이 많았습니다.
몇 몇 개념들은 지금 봐도 잘 이해가 되지 않을것 같아서 생략한 부분도 있으니 참고 바랍니다.
다음 section부터 Discovery 서버를 실습하면서 진행예정입니다.
Discovery 서버에 대한 충분한 이해를 바탕으로 다양한 실습을 통해 학습해볼 예정입니다.
모두들 화이팅!
