2024.10.01.화.TIL MSA

김기남·2024년 10월 1일

TIL msa

안녕하세요, 오늘은 MSA 에 대해 정리해 보았습니다.

Monolithic과 MSA

💡 Application을 개발하는 방법에는 여러가지 방법론이나 프로세스가 존재한다. 시스템을 구축하고 운영하는 방식인 Monolith, MSA 두가지 방식에 대해서 알아보자.

Monolithic Architecture

💡 Application을 개발하는데 필요한 모든 구성 요소를(UI, Service, DB) 하나의 소프트웨어 안에서 모두 포함시켜 개발하는 방법

참고자료 및 사진 출처 What is Monolithic Architecture? - Salesforce Codex

DB와 관련된 로직, 비지니스 로직, FrontEnd 까지 모두 하나의 Application에서 유기적으로 연결되어 동작
- 쉽게 설명하면 현재 우리가 개발하고 있는 Spring Web Application의 형태이다.
배포를 위해서 서로 의존성을 가진채 하나의 Application 형태로 패키징 된다.
Application에서 사용하는 데이터가 한곳에 모여 참조되는 서비스 형태이다.

Monolithic Architecture의 장점

배포 파이프라인 구성이 쉽다.
- 하나의 프로젝트만 관리하기 때문에 배포가 비교적 간단하다.
통합 테스트가 용이하다.
- 하나의 프로젝트에 전체 비지니스 로직이 관리되고 있기 때문에 통합 테스트가 유리하다.
유지보수성
- 규모가 작은 프로젝트라면 유지보수가 간편하다.
- 단, 규모가 큰 프로젝트라면 유지보수성이 급격히 나빠진다.

Monolithic Architecture의 단점

하나의 시스템에 Application을 구성하고 있는 모든 구성요소가 하나로 패키징되어 배포된다.
- 시스템 일부만 수정이 필요해도 전체 Application을 다시 Build, Test, 패키징, 배포해야 한다.
  CI/CD 를 새로 해야한다.
전체적인 구조 파악이 어려워진다.
- 규모가 커질수록 전체 구조를 파악하기 힘들어진다.
- 즉, 유지보수성이 떨어진다.
서버 확장성이 나빠진다.
- 실제 트래픽은 Application 전체에 고르게 분포되는것이 아니다.
  - 특정 부분에 트래픽이 집중되는 상황이 발생
  - ex) 이벤트로 쿠폰발급, 폭발적인 반응의 댓글, 채팅 등
- 하지만 구조상 특정 모듈만 scale Out 하는등의 작업이 어렵다.
기술 스택에 종속되어 있다.
- 전체 서비스가 하나의 언어 및 기술로 구성되어 있다.
의존성
- 내부 서비스간 결합도가 높아 하나의 서비스에 문제가 발생하면 다른 서비스에도 피해가간다.

MicroService Architecture

💡 Monolithic Architecture와는 상반되는 아키텍처이다. Application을 구성하는 각각의 구성요소 및 서비스의 내용을 모두 분리하여 개발하고 운영한다.

참고자료 및 이미지 출처 마이크로 서비스 아키텍처 스타일 - Azure Architecture Center

Sam Newman

💡 Building MicroServices의 저자

MicroService의 특징 - Sam Newman

Small autonomous services that work together
- 마이크로 서비스 = 함께 동작하는 작은 규모의 서비스들.
HTTP 통신을 이용하여 리소스 API에 통신할 수 있는 작은 규모의 여러 서비스들의 묶음이다.
Monolithic 에 비해서 유지보수, 수정사항 반영에 더욱 유리하다.
비지니스 로직이 변경되어 개발, 배포되어야 한다면 필요한 부분에 대해서만 개발한다.
분리된 서비스가 다른 서비스에 영향을 주지 않거나 최소화 한다.
각각의 서비스가 독립적으로 배포할 수 있게된다.
비지니스 기능을 중심으로 구축되어야 하고 완전하게 자동화된 배포 시스템을 사용해야한다. CI/CD
Application 전체의 다운타임 시간을 최소화 한다.
- 시스템을 이용할 수 없는 시간

Martin Fowler

💡 MicroService의 창시자

MicroService의 특징 - Martin Fowler

모놀리스 방식과 마이크로 서비스 방식의 가장 큰 차이점은 하나의 서비스를 구성하고 있는 크기이다.
- 서비스의 크기가 도메인의 특성을 고려하여 경계를 구분하여야 한다.
각각의 서비스들은 서로 다른 독립적인 프로그래밍 언어, 데이터 저장 기술을 사용할 수 있다.
- 각각의 서비스들의 특색에 맞게 최적화 되어있는 언어, DB를 사용하는것을 권장한다.
- 서비스의 종류와 기능에 맞추어 개발 언어를 선택한다.
각각의 서비스들은 최소한의 중앙 집중식 관리가 되어야 한다.
각각의 서비스들은 제공하는 서비스나 Data를 API를 통해 제어할 수 있도록 한다.
- 통일된 언어를 사용할 필요가 없다.
- 여기서 사용되는것이 Restful API(규격) 이다.
  - Client → Server , Server → Server 모두 통신 가능
  - 서로다른 언어, 프로그래밍 관련 소프트웨어 → Restful API 방식만 채용한다면
    JSON, HTTP Request Response 규격들에 맞춰서 통신

정리

사진출처 [초보개발자 일지] 대세 MSA? 너 뭐니?

Monolith
- 화면을 나타내는 UI, 웹서비스, 비지니스 로직, DB 로직 등을 하나의 구성요소로 보고있다.
- 시스템에 DB를 포함하여 함께 구성하게 된다.
- 하지만 최근 개발에서는 스마트 기기들을 고려해야 한다.
- 사용자의 요청정보를 처리하는 서버사이드 기술도 다양한 형태로 서비스 되어야 한다는것을 의미한다.
- 하지만 모든 디바이스에 맞는 방식을 하나하나 개발하는것은 무리가 있다.
Micro Services
- 변화가 많은 클라이언트의 단말기는 FrontEnd 에 맡긴다.
- 서버에서는 서비스의 핵심, 비지니스 내용을 통일된 포맷으로 클라이언트 단말기에 전달하하면 된다.
  - 서버측에서 고려해야할 부분이 아주 줄어든다.
- 서버에서 개발해야하는 각각의 기능들도 각 서비스의 경계에 맞는 형태로 개발되고 테스트, 배포된다.
- 하나의 어플리케이션을 구성해야 하는 다른 서비스라고 할지라도 독립적으로 관리할 수 있게 된다.

Cloud Native Architecture

사진출처 Cloud native architecture and it's best practices Event driven microservices architecture using Spring Cloud

MicroService Architecture & Cloud Native Architecture
- 마이크로 서비스 아키텍처에서 가장 중요한것은 마이크로 서비스들을 관리하기 위한 기술이다.
- 서비스 요청에 대한 통일된 Gateway가 필요하다.
- 서비스들의 등록, 검색, 관리가 필요하다.
- 트래픽 부하분산, 문제가 발생했을 때 대처하는 방법이 필요하다.
- 분리된 서비스들의 데이터를 동기화 하기위한 매커니즘들이 필요하게 된다.
  - 분리된 서비스들은 각각 다른 DB를 사용할 수 있기 때문에 데이터가 다를 수 있다.
  - 확장된 서비스들은 각각 다른 DB를 사용할 수 있기 때문에 데이터가 다를 수 있다.
- 각 서비스의 인프라 스트럭쳐와 운영, 배포 방식을 알아야하는 이유이다.

Front End와 Back End

💡 마이크로 서비스와 모놀리스 사이에서 자주 사용되는 방식이다. 서버와 클라이언트만 분리하여 개발 하게되면 서로에게 필요한 통신만 하게되고 각각 최적화 되어있는 개발 환경을 독립적으로 유지하는게 가능해진다.

사진 출처 및 참고 자료 Microfrontends vs. Monolithic Frontend: Which Is Right for Your Project?

Mobile Application에서 많이 볼 수 있는 방식이다.
사용자에게 보여지는 화면이 변경되는 경우에 백엔드 서버를 같이 빌드하여 배포할 필요가 없어진다.
Thymeleaf는 SSR 기술이다.
- SpringBoot로 만들어진 Web Application 서버에서 프론트까지 같이 빌드되어 배포된다.
프론트 서버, 백엔드 서버가 따로 존재하는 경우가 위와같은 경우.

Microservice Architecture란?

💡 Microservice Architecture의 정의, 특징, 구성요소, 기술들에 대해 알아보자

아마존, 넷플릭스의 마이크로 서비스 구성도
- 두 회사는 클라우드 서비스를 가장 활발하게 사용하고 서비스 하고있다.

아마존 CEO가 직원들에게 전송한 메일

아마존CEO는 왜 직원들에게 협박(?)메일을 보냈는가?

모든팀은 서비스 인터페이스를 통해서 데이터 기능을 공개해야 한다.
팀은 이런 인터페이스를 통해서만 통신하여야 한다.
다른 형태의 프로세스간 통신은 허용하지 않는다.
1. 직접연결, 다른팀의 DB 읽기, 공유 메모리, 백도어 등을 공유하지 않는다.
2. 반드시 허용된 유일한 통신방법으로 접속한다.
그들이 사용하고 있는 기술(언어, HTTP, 프로토콜 등)은 중요하지 않다.
서비스의 모든 인터페이스는 예외없이 처음부터 외부에 공개될 수 있도록 설계되어야 한다.
1. 현재 대다수의 IT회사들이 채택하고 있는 방식이다.
이러한 방식을 지키지 않으면 해고한다.
Thank you; have a nice day!
1. 음,,,, 오,,,, 아,,, 예,,,

Microservice의 특징

1. Challenges

마이크로 서비스는 기존의 개발 방식, 패러다임을 상당수 바꾸어야 한다.

2. Small Well Chosen Deployable Units

독립적으로 배포 가능한 형태의 작은 서비스로 이루어져 있다.

3. Bouded Context

각각의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인에 따라서 서비스를 잘 구분하여야 한다.
이러한 경계로 인해서 하나의 서비스가 두개가 되기도 하고
여러개의 서비스가 단일화된 서비스 하나로 만들어지기도 한다.

4. RESTful

각각의 서비스들은 서로 상태에 대해서 REST API 형태로 통신한다.
HTTP 프로토콜을 기반으로 JSON형태를 사용한다.
경량 데이터 포맷이기 때문에 서버의 리소스, 상태를 표시하기에 최적화 되어있다.

5. Configuration Management

환경에대한 정보나 설정 정보는 코드내에 가지고 있지 않고 외부에 있는 시스템을 통해서 관리한다.
만약 설정 정보가 코드안에 포함된채로 Build 된다면 설정 사항만 변경되어도 새로 배포되어야 한다.

6. Cloud Enabled

Cloud Native 기술을 활용하여 서비스를 제공한다.

7. Dynamic Scale Up And Scale Down

부하분산 처리나, Scale Up, Scale Down을 동적으로 처리할 수 있도록 구성되어 있어야한다.

8. CI / CD

여러 서비스들이 엮여서 하나의 어플리케이션을 구성하다보니 자동 배포관리가 중요하다.

9. Visibility

마이크로 서비스를 시각화 할수있는 관리도구를 가지고 있어야 한다.

참고

하나의 서비스가 다른 서비스의 형태를 조작하고 사용함으로써 전체 어플리케이션을 구성할 수도 있다.
하나의 서비스에서 하나의 인스턴스만 직접 서비스 되는것이 아니라
여러개 분산된 형태로써 Host로 분리되어 서비스 될 수 있다. -> Scaling에 관련된 내용

기존, 신규 서비스들도 마이크로 서비스로 만들어져야 하는가?

참고자료 Should That Be a Microservice? Keep These Six Factors in Mind

1. Multiple Rates Of Change

어느정도 변화가 생길것인가?
기존 개발대비 비용, 시간이 투자되는것은 필수이다.
어느정도의 공수를 고려하고 받아들일 수 있을것인가를 산정해야 한다.

2. Independent Life Cycles

독립적인 생명주기
어플리케이션을 구성하고 있는 각각의 서비스들이 독립적으로 개발,
운영될 수 있도록 서비스간의 경계가 잘 만들어져 있는가

3. Independent Scalability

독립의 확장성
각각의 서비스를 운영함에 있어서 유지보수 및 확장성이 가능한가.

4. Isolated Failure

격리된 오류
오류 사항이 독립적으로 발생하는가?
하나의 마이크로 서비스에 오류가 발생한다면 해당 서비스에 대해서만 오류가 발생하는가?
다른 마이크로 서비스들은 오류에 영향을 최소화하며 대체 서비스가 준비될 수 있는지를 고려해야 한다.

5. Simplify Interactions with External Dependencies

외부 종속성과의 상호작용 단순화
외부 뿐만 아니라 종속성 자체는 좋지않다.
시스템이나 서비스간에 종속성을 최소화하고, 응집력을 높일 수 있도록 서비스간 경계가 잘 구분되어 있는가?

6. Polyglot Technology

여러가지 프로그래밍 언어, 스토리지 기술 등이 지원되는가?
마이크로 서비스는 독립적인 언어, 기술을 사용할 수 있다.
각각의 서비스들이 제공해야하는 기능에 맞는 언어와 DB, 운영환경을 자유롭게 선택할 수 있는가?

위의 사항들이 고려되어있다면 마이크로 서비스의 도입을 고려할 수 있다.

정리

마이크로 서비스들은 그 서비스를 구성하는 서비스의 경계 업무의 범위, 용도 등에 따라서
하나의 비지니스 로직이 하나의 서비스일 수도 있고 더 작은 서비스일 수도 있다.
하나의 서비스와 다른 분리된 서비스를 조합하여 새로운 서비스를 만들수도 있다.

AWS DevOps - Two Pizza team

💡 아마존의 DevOps팀에서는 Two Pizza Team이라는 용어를 사용한다. 점심 한끼를 같이 먹을때 피자 두판을 같이 나눠먹을 수 있는 인원이(일반적으로 4~5명) 이상적인 **DevOps**팀의 구성 인원이라는 것에서 나온 용어이다. 커뮤니케이션 비용이 적게 발생하고 각각 독립적으로 개발할 수 있는 최소 단위라는 판단.

참고

피자 두 판 팀 - AWS의 DevOps 소개

SOA(Service Oriented Architecture)와 MSA

💡 SOA, MSA는 서비스를 지향한다는 점에서 같다. 어떤 차이점이 있는지 아래 본문에서 알아보자.

SOA
- 서비스를 재사용하여 비용을 절감하는것에 목적이 있다.
MSA
- 서비스 간의 결합도를 최소화 하여 변화에 대응이 쉽다.

SOA와 MSA의 차이점

참고자료 및 사진출처 Service-Oriented Architecture vs Microservices | Complete Comparison

참고자료 및 사진출처 SOAP vs RESTful Microservices - Dinesh on Java
기술방식 차이
- SOA
  - 공통으로 사용할 수 있는 서비스들을 ESB 를 통해 한곳에 모아 하나의 서비스로 만든다.
  - 이렇게 모여진 서비스들을 외부에 제공한다.
  - Web Services(XML, WSDL 등등)라는 기술을 통해 개발된다.
  - DB에 자료를 저장하기 위해 공통적인 DB 처리 로직을 함께 사용한다.
    - SOAP, HTTP, MOM, JMS, JDBC 등등
- MSA
  - 각각 독립된 서비스들이 존재한다.
  - 각각의 서비스들은 독립적인 개발 프로세스를 가지고 있다.
    - UI, 프로그래밍 언어, 로직, DB 등
  - REST API를 사용해야만 다른 서비스나 시스템에서 사용할 수 있다.
  - [Event Stream과 같은 메세징 서비스]를 이용하여 데이터 동기화를 할 수 있다.
- 정리
  - 서비스의 공유를 어디까지 하는가?
  - 개발하는 방식에 있어서 RESTful API를 사용하는가?
  - SOAP 프로토콜을 사용하는 Web Service를 사용하는가?

참고자료 및 사진출처 Building an Event-Driven Reactive Asynchronous System with Spring Boot and Kafka | LIFERAY UI
하나의 DB에 어떠한 자료가 변경된다면 이것을 Kafka로 전달하여 Subscriber에게 전달된 데이터를 전달
ex) 장바구니, 주문 서비스 등에서 사용자의 정보를 자신이 가지고 있는 DB에 업데이트 할 수 있다.
마이크로 서비스안에 저장 되어있는 다른 DB에 저장되어 있지만 메세징 서비스를 통해서 동기화 처리 가능

MSA 구성요소

💡 마이크로 서비스들을 관리하기 위해서 일반적으로 Service Discovery, API Gateway, Orchestration, Context Boundary등의 서비스들을 연계하여 사용하게 된다.

넷플릭스, 트위터, 아마존, 나이키 등에서 채택한 아키텍처

전체 구조
1. 클라이언트, 서비스들은 API Gateway를 통해서 필요한 서비스를 요청
2. API Gateway로 수집된 요청들은 Service Router에게 어디로 가야할지 요청
3. Service Router는 필요한 마이크로 서비스가 어디에 저장되어 있는지 Service Discovery(도서관)에 요청
4. 인스턴스가 여러개로 분산되어 있다면 Load Balancer에 의해서 어떤 서비스로 보내질것인지 결정
  - 일반적으로 Service Router, Load Balancing을 하나의 시스템으로 묶어서 사용 한다.
5. 마이크로 서비스 안에서 사용하고 있는 환경설정 정보(Config Store)는
  Configuration Service를 통해서 외부 시스템에 저장하여 사용한다.
6. 마이크로 서비스는 컨테이너 가상화 Container Management 기술을 통하여 구성되어있다.
7. 완성되어진 Application은 배포를 하기위해서 CI / CD라는 Automation 기술을 사용한다.
  - CI / CD를 통해서 외부에 있는 시스템에 배포하고자 할때
    관리자, DevOps들이 사용할 수 있게 API가 오픈되있어야 한다.
8. Backing Service 는 각각의 서비스에 저장되어 있는 스토리지들을 모아서 사용할 수 있는 방법
  - MOM 메세징 처리 시스템을 통해서 하나의 서비스와 다른 서비스와 같이 연결될 수 있다.
9. Telementry 는 모니터링(Monitoring) 기능과 진단(Diagnostics)기능을 가지고있다.

Service Mesh

💡 마이크로 서비스 아키텍처를 적용한 시스템의 내부 통신을 말한다. 서비스간의 통신을 추상화하고 안전하고 빠르고 신뢰성있게 만들어주는 Infra Structure의 Layer라고 볼 수 있다. Service Discovery, Service Router, Load Balancer를 포함한다. **위 아키텍처 사진 참조**

참고자료 및 사진 출처 Service Meshes | Software AG

URI경로나 Host Header, API Version, 기타 응용프로그램의 규칙 기반 Network Layer이다.
프록시를 통해서 다양한 라우팅 기능이나 서킷브레이커와 같은 공통 기능을 설정할 수 있다.
Service Mesh는 서비스간의 연관된 기능뿐만 아니라 서비스의 배포 전략에도 도움을 줄수있다.
해당 Layer에서 프록시 역할, 인증, 인가, 보안, 서비스 검색, 라우팅, 로드 밸런싱 등등의 역할을 수행한다.

정리

Service Mesh는 툴, 제품이나 서비스를 지칭하는것이 아니라 추상적인 개념이다
이 계층에서 위와같은 다양한 기능들과 서비스를 제공해줌으로써
안정적이고 효율적인 마이크로 서비스 운영을 지원하는것에 목적이 있다.

CNCF(Cloud Native Computing Foundation)

💡 리눅스 재단 비영리 단체로 **Kubernetes**, **Cloud Native** 컴퓨팅에 필요한 다양한 오픈소스 프로젝트들을 추친하고 관리하고 있습니다. CNCF를 통하여 MSA에서 각각의 독립적인 구성요소가 어떻게 구성되어 있는지 살펴볼 수 있다.

참고 링크
- Cloud Native에서 서로 Interactive하게 상호 연관될 수 있는 서비스들의 종류를 나타낸다. Cloud Native Landscape

MSA 핵심 기술들

오늘의 코드카타

class Solution {

    public String[] solution(String[] strArr) {
        String[] answer = new String[strArr.length];

        for (int i = 0; i < strArr.length; i++) {
            if (i % 2 == 0) {
                answer[i] = strArr[i].toLowerCase();
            } else {
                answer[i] = strArr[i].toUpperCase();
            }
        }
        return answer;
    }
}

import java.util.Arrays;

public class Main {

    public static void main(String[] args) {

        Solution solution = new Solution();

        String[] a1 = {"AAA", "BBB", "CCC", "DDD"};
        String[] a2 = {"aBc", "AbC"};

        System.out.println(Arrays.toString(solution.solution(a1)));
        System.out.println(Arrays.toString(solution.solution(a2)));
    }
}

배열에서 문자열 대소문자 변환하기

김기남

새로운 시작~!

이전 포스트

2024.09.30.월.TIL Software Architecture

다음 포스트