모노리틱 아키텍쳐와 MSA

bye9·2021년 5월 4일

CS

목록 보기

7/10

Monolithic Architecture

MSA가 도입되기 전의 모습
기존의 웹 시스템 개발 스타일로, 하나의 어플리케이션 내에 모든 로직이 들어가 있는 “통짜 구조”를 의미
전체 애플리케이션이 하나로 되어있어서 보통 동일한 개발 툴을 사용해 개발

장점

배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단
각 컴포넌트들이 함수로 호출 되기 때문에 성능에 제약이 덜하고, 운영 관리가 용이
작은 볼륨의 시스템을 개발할 때는 매우 유용

시스템이 커지기 시작하고 여러 컴포넌트들이 더해지면 문제가 발생

단점

빌드/테스트 시간이 길어진다.
작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어진다. 요즘처럼 CI/CD가 강조되는 시점에서는 큰 문제가 될 수 있다.
선택적 확장이 불가능
이벤트로 인해 서비스 접속 량이 폭증할 경우 프로젝트 전체를 확장해야만 한다.
하나의 서비스가 모든 서비스에 영향을 준다.(A를 수정하면 B,C,D..다 수정해야함)
이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 된다면 다른 모든 서비스 역시 마비 되는 상황이 오게 됩니다.

MSA(Micro Service Architecture)

단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법
독립적, 단순한 서비스의 조합으로 전체 서비스 구축
각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신

Small, Communicate with APIs, Autonomous(자율적인), Focused on doing thing well

장점

각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포 가능
각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장 가능
(온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장 가능)

단점

모노리틱 아키텍처는 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만, MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리다.
통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생

특징

데이터 분리

데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용한다.(DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 된다.)
데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생하기도 합니다.

API Gateway

MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다. 이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할
API 요청을 한 곳에서 받아서 해당 서비스로 라우팅 기능
거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화
라우팅, 로드밸런싱, 인증과 인가, 보안, 트래픽제거 역할 수행
오픈소스: Netflix Zuul

https://woowabros.github.io/r&d/2017/06/13/apigateway.html
https://docs.toast.com/ko/Application%20Service/API%20Gateway/ko/overview/

MSA 설계의 사전준비

MSA 전환의 자가점검

적절하게 구조화된 모노리틱 애플리케이션을 구축하였는가?
마이크로 서비스로 충족해야 하는 요구사항을 결정하였는가?
마이크로 서비스를 활용할 수 있도록 팀을 재정비하였는가?
DevOps 및 CI/CD에 대한 모범 사례를 도입하였는가?
애플리케이션 내에서 비즈니스 범위를 식별하였는가?
마이크로 서비스 오케스트레이션 및 관리도구와 프로세스를 구현하였는가?

규모 확장성(scalability)에 대한 고려

이를 결정하기 위해 scale cube 모델 사용

X축(horizontal duplication) : 동일한 이미지를 다수 복사해서 많은 업무 처리
Y축(functional decomposition) : 기능을 분해해서 여러 머신에서 돌아가게 설계하여 많은 업무를 처리
Z축(data partitioning) : 데이터베이스를 여러 서버로 분할. 하나의 큰 데이터베이스에서 데이터를 찾는 것보다 작은 데이터베이스에서 찾는 것이 효율적. DB 샤딩(Sharding) 자가 점검을 완료하고, 기존 시스템에서 어느부분을 분할할지 결정하면 모노리틱시스템을 마이크로 서비스 아키텍처로 전환하기 위한 사전준비 단계가 완료되고, 기존 서비스를 마이크로 서비스로 분할하는 단계를 수행하게 되는 것

마이크로 서비스 설계
마이크로 서비스 설계가 완료되면 분할된 서비스를 효율적으로 구축/운영하기 위한 설계를 진행할 수 있다

MSA 전환 시 사전설계

마이크로 서비스 아키텍처 구성

환경설정과 서비스 등록 및 감지 서비스는 마이크로 서비스의 정보들을 동적으로 관리할 수 있게 지원한다.
서비스 게이트웨이는 클라이언트 요청을 해석하여 가용성을 유지할 수 있게 부하 분산과 적절한 서비스로 연결해주는 라우팅 기능을 지원한다. 또한, 마이크로 서비스의 요청 상태와 서킷브레이커 기능을 실시간으로 모니터링할 수 있게 지원한다.

환경설정: 시스템에서 참조해야 하는 환경변수 등을 별도의 저장소에서 관리하여 애플리케이션이 배포된 환경에 구애 받지 않고, 해당 환경에 적절한 환경정보들을 참조할 수 있는 기능을 제공하는 서비스
서비스 등록 및 감지: 마이크로 서비스가 시스템 등록되는 것을 자동으로 감지하여 서비스게이트웨이가 자동으로 인지할 수 있게 지원하는 기능
서비스 게이트웨이: 요청을 받아서 해당 요청에 필요한 서비스로 연결해주는 역할을 수행. 클라이언트 관점에서는 서버에 접속하기 위한 관문이고, 서버 측면에서는 클라이언트 요청의 부하분산과 대응하는 적절한 마이크로 서비스를 찾아주는 역할을 수행하는 것임
서킷 브레이커: 특정 서비스가 정상적으로 동작하지 않을 경우 다른 기능으로 대체 수행시켜 장애를 회피하는 기능. 최종 사용자 측면에서는 장애 상황을 인지할 수 없음
큐잉 시스템: 마이크로 서비스간 데이터 전달이 필요하고 느슨한 결합을 위해서 MQ 사용. 업무 메시지 전달은 물론 로그 데이터도 메시지 시스템에 흘려 보내 처리할 수 있음. 서비스에 직접적인 부하를 주지 않고 필요한 서비스만 구독해서 사용하면 되는 것이 강점
폴리그랏 프로그래밍과 폴리그랏 퍼시스턴스: 서비스별로 목적과 특성에 맞는 언어와 기술을 사용. 회원관리는 RDB, 문서형태의 콘텐츠는 key-value DB를 이용. 각 서비스의 특성은 최대한 보장하고, 이에 맞는 기술 형태로 구성

API 설계
마이크로 서비스들은 각각 독립성을 가지고 동작하므로 각각 독립된 버전을 가지며, 서비스를 체계적으로 관리하기 위해서는 마이크로 서비스 API를 정의하고 생성하는 서비스 생성자와 서비스를 사용하는 소비자 간에 잘 정의된 마이크로 서비스 API 체계가 필요하다.
테스트 체계
API 명세를 토대로 수행할 수 있어야 하며, 서버/클라이언트의 규격이 정상적인지를 판단하기위해 시스템적으로 자동화 및 모니터링이 필수이다.
지속적 통합 및 배포체계 설계
소스코드는 저장소에서 별도의 브랜치 형태로 관리하며, 파이프라인 전략과 자동화되고 시각화할 수 있는 체계가 필요하다.
모니터링 체계 설계

서비스 모니터링 : 각 개별 서비스들의 상태정보가 모니터링되어야 함. 클라이언트의 요청을 실시간으로 모니터링하여 시각화하고, 개별 서비스의 응답지연이 발생할 때에는 즉시 해당 접근 경로를 차단시키고 다른 경로로 우회하도록 만드는 서킷 브레이크 기능과 상태 정보 등을 확인할 수 있도록 구성
DevOps 모니터링 : 마이크로 서비스 환경에서는 서비스의 개발과 배포 주기가 짧아지고 모니터링해야 할 대상도 많아지므로 운영측면에서 장점

MSA의 구현과 배포

마이크로 서비스는 독립된 서비스이고, 이를 실행하기 위한 환경은 VM과 컨테이너 기술을 고려할 수 있다.

분할된 서비스가 많지 않다면 VM에 WAS Instance를 교차로 배치하여 효율성과 가용성을 확보하는 방법도 가능하지만, 수백 개 이상의 마이크로 서비스를 운영할 때는 VM보다는 도커와 같은 컨테이너 기술을 고려하는 것이 서비스 관리, 고가용성 측면에서 유리한 면을 가지고 있다.

하드웨어 가상화 기술

가상화기술=가상 머신 기반, 리눅스 컨테이너 기반의 가상화 기술

가상 머신 기반

게스트 운영체제의 설치가 필요

컨테이너

하나의 호스트 운영체제 위에 여러 개의 격리된 시스템 환경을 구성할 수 있는 운영체제 수준의 가상화 기술

리눅스 컨테이너는 컨트롤그룹(cgroup)과 네임스페이스(namespace) 기능을 사용하여 운영환경을 고립시키고 관리한다.

게스트 운영체제가 설치되지 않고, 프로세스 레벨의 분리가 가능한 해당 방식은 성능 측면에서 경량화 가상화로 분류(컨테이너를 생성하는 것은 단순히 프로세스를 시작하기 때문에 일반적인 프로세스의 실행과 다름 없이 빠르게 수행이 가능하다.)
설치된 이미지 자체의 용량에 따른 네트워크 부하 및 배포 시간을 고려했을때 큰 장점(컨테이너 기반의 인프라를 사용하기 때문에 다양한 환경에 대한 종속성을 고민할 필요 없이 운영이 가능하다.)
일반적으로 Product/QA/Dev 환경의 차이로 운영 전환 시 복잡한 문제가 발생하며 이를 해결하기 위해 같은 작업을 여러 번 실행 하더라도 같은 결과로 수렴되는 멱등성을 갖춘 Immutable infrastructure가 필요하다. 이를 실현하는 대표적인 기술이 컨테이너 기반의 도커 가상화

컨트롤그룹

물리적인 하드웨어의 리소스를 프로세스 그룹 단위로 제어하는 기능

컨트롤그룹을 통해 사용자는 CPU 시간, 시스템 메모리, 네트워크 대역폭과 같은 자원이나 이러한 자원의 조합을 실행중인 프로세스 간에 할당하는 것이 가능
시스템 관리자는 시스템 자원 할당, 우선 순위 지정, 거부, 관리, 모니터링과 같은 제어가 가능

네임스페이스

컨테이너 별로 격리된 공간을 가질 수 있도록 지원하는 기술

‘PID’, ‘NET’, ‘MNT’, ‘UID’, ‘UTS’, ‘IPC’에 해당하는 시스템 구성 요소의 네임스페이스를 제공하여 이의 공간별 할당 및 관리가 가능

도커

리눅스 컨테이너(LXC)를 기반으로 시작해서 LXC 작업과 개선된 개발자 툴을 결합하여 컨테이너의 사용자 친화성을 높였고 이를 통해 대중이 쉽게 이용할 수 있게 만든 오픈소스 플랫폼

오케스트레이션: 도커 컴포즈, 스웜, 쿠버네티스를 통해 멀티 컨테이너를 조직화하고 연결하는 기능으로 MSA 애플리케이션의 가용성과 로드밸런싱 기능을 구현한다

도커 기반의 마이크로 서비스 배포

도커의 특징인 확장성, 표준성을 활용하여 마이크로 서비스의 유연하고 탄력적인 서비스 배포가 가능하다.
도커는 이미지를 그대로 컨테이너로 유연하게 실행이 가능하고 컨테이너라는 표준성을 확보한 상태에서 배포가 진행되므로 멱등성을 보장할 수 있도록 동일하게 다양한 환경에서 배포가 가능하다.

*멱등성: 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

변경된 도커 이미지의 배포 시 서비스를 내리고 올려야 하기 때문에 서비스 중단의 단점이 발생한다. nginx와 haproxy를 이용한 로드밸런싱 기반의 카나리 배포와 블루그린 배포 유형을 통해 서비스의 잦은 변경과 배포에 유연하게 대응할 수 있도록, 자동화된 배포 전략을 잘 활용한 안정적인 서비스 운영이 필요하다.

롤링 배포

구 버전에서 신 버전으로 트래픽을 점진적으로 전환하는 배포
관리가 편하지만, 하나의 서버가 중단 되었을 때 나머지 서버의 부하량을 잘 파악해야한다.

블루그린 배포

구 버전, 신 버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽을 신 버전으로 일제히 전환하는 배포
빠른 롤백이 가능하고, 운영환경에 영향없이 실제 서비스 환경으로 신 버전 테스트가 가능하다.
시스템 자원이 두 배로 필요하여 비용이 많이 발생한다.

Canary 배포

소규모의 사용자들에게만 먼저 배포했다가 정상적이면 전체를 대상으로 배포해 리스크를 줄이는 기법
오류 감지 및 성능 모니터링에 유용하다.

쿠버네티스(kubernetes)

2014년 구글에서 Go라는 언어로 개발하였으며 컨테이너화된 애플리케이션을 편리하게 배포 가능하고 오토스케일링, 스케줄링, 서비스 디스커버리, 로드밸런싱, 리소스 관리 등을 지원하는 컨테이너 오케스트레이션 플랫폼

https://wooono.tistory.com/109

오토스케일링

클라우드의 유연성을 돋보이게 하는 핵심기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭값을 모니터링하여 서버 사이즈를 자동으로 조절한다.

시스템 메트릭 : 가상 서버의 컴퓨팅 자원에 해당하는 CPU, 메모리, 네트워크와 같은 클라우드 리소스의 사용량 정보

https://www.samsungsds.com/kr/insights/auto_scaling.html

로드밸런싱

쏟아지는 트래픽을 여러 대의 서버로 분산해주는 기술이 없다면 한 곳의 서버에 모든 트래픽이 몰리는 상황이 발생할 것입니다. 이때 필요한 기술.
(로드밸런서는 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 통칭)

로드밸런싱 알고리즘

라운드로빈 방식(Round Robin Method)
서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식입니다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합합니다.
가중 라운드로빈 방식(Weighted Round Robin Method)
각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분합니다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식입니다. 예를 들어 A라는 서버가 5라는 가중치를 갖고 B라는 서버가 2라는 가중치를 갖는다면, 로드밸런서는 라운드로빈 방식으로 A 서버에 5개 B 서버에 2개의 요청을 전달합니다.
IP 해시 방식(IP Hash Method)
클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식입니다. 사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장합니다.
최소 연결 방식(Least Connection Method)
요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분합니다. 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식입니다.
최소 리스폰타임(Least Response Time Method)
서버의 현재 연결 상태와 응답시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분합니다. 가장 적은 연결 상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 로드를 배분하는 방식입니다.

L4 로드밸런싱과 L7 로드밸런싱

부하 분산에는 L4 로드밸런서와 L7 로드밸런서가 가장 많이 활용된다. 그 이유는 L4 로드밸런서부터 포트(Port)정보를 바탕으로 로드를 분산하는 것이 가능하기 때문이다.

L4 로드밸런서는 네트워크 계층(IP, IPX)이나 트랜스포트 계층(TCP, UDP)의 정보를 바탕으로 로드를 분산한다.
IP주소나 포트번호, MAC주소, 전송 프로토콜에 따라 트래픽을 나누는 것이 가능

L7 로드밸런서의 경우 애플리케이션 계층(HTTP, FTP, SMTP)에서 로드를 분산한다.
HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다.(패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능)
URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다.
특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있다.
DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있다.

데브옵스(devOps)

개발(Development)과 운영(Operations)을 나누지 않고, '개발 + 테스트 + 배포 + 운영'을 동시에 할 수 있는 IT 환경 또는 문화

MSA를 통해 서비스 단위가 소형화되면서 업데이트와 업그레이드가 상대적으로 용이해졌으며 이는 릴리즈 주기를 단축하는데 큰 이점이 되었다. 이를 보다 효과적으로 프로세스화하기 위해 데브옵스라는 개발 프로세스를 도입했다.

Circuit Breaker

클라이언트에서 어떤 원격 서버로 전송한 요청의 실패율이 특정 임계치(threshold)를 넘어서면, 이 서버에 문제가 있다고 판단하여 더 이상 무의미한 요청을 전송하지 않고 빠르게 에러를 발생시키는 방법

CLOSED: 요청의 실패율이 정해 놓은 임계치보다 낮은 정상적인 상태.
OPEN: 요청의 실패율이 정해 놓은 임계치를 넘어선 상태. 요청을 전송하지 않고 바로 에러를 발생시킴(fail fast).
HALF_OPEN: OPEN 상태에서 주기적으로 요청을 전송하여 응답을 확인하는 상태. 성공하면 CLOSED 상태로 전환하고 실패하면 OPEN 상태를 유지.

Netflix Hystrix

circuit breaker 패턴을 자바 기반으로 오픈소스화한 라이브러리

http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/
https://www.samsungsds.com/kr/insights/msa.html
https://post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903
https://reference-m1.tistory.com/211
https://www.itfind.or.kr/WZIN/jugidong/1887/file2645276227345330267-188702.pdf
https://engineering.linecorp.com/ko/blog/try-armeria-circuit-breaker/
https://bcho.tistory.com/1247

bye9

다음 포스트