MSA(Micro Services Architecture)

모놀리식 아키텍처(Monolithic Architecture)는 전체 애플리케이션을 단일 코드베이스에서 관리하는 방식입니다.

즉, 애플리케이션의 모든 기능이 하나의 응집된 단위로 작성되고 배포됩니다. 이 방식은 초기 개발 단계에서는 단순하고 직관적일 수 있지만, 애플리케이션이 커지면서 여러 가지 확장성, 유지 보수 등의 문제를 겪을 수 있습니다.

 

 

MSA는 Microservices Architecture의 약자로, 마이크로서비스 아키텍처를 의미합니다. 이는 소프트웨어 아키텍처의 한 접근 방식으로, 대규모 애플리케이션을 작고 독립적인 서비스들로 나누어 구성하는 방식입니다. 각 서비스는 독립적으로 배포되고, 자체적으로 개발 및 유지 관리됩니다.

 

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

1. 작고 독립적인 서비스:
   • 애플리케이션을 작은 서비스 단위로 나누어 각 서비스를 독립적으로 개발, 배포, 확장할 수 있습니다.
   • 각 서비스는 특정 도메인에 대한 책임을 가지며, 자율적으로 관리됩니다.
2. 독립적 배포:
   • 마이크로서비스는 다른 서비스에 영향을 미치지 않고 독립적으로 배포할 수 있습니다.
   • 하나의 서비스가 업데이트되어도 다른 서비스에는 영향을 주지 않기 때문에 배포의 유연성이 높습니다.
3. 언어 및 기술 독립성:
   • 각 서비스는 별도의 기술 스택과 프로그래밍 언어를 사용할 수 있습니다. 예를 들어, 하나의 서비스는 Java로 작성되고, 다른 서비스는 Python으로 작성될 수 있습니다.
   • 이를 통해 각 서비스에 최적화된 언어와 도구를 선택할 수 있습니다.
4. 스케일링:
   • 각 서비스는 독립적으로 확장할 수 있습니다. 예를 들어, 특정 서비스에 부하가 많으면 그 서비스만 별도로 확장할 수 있어 효율적인 자원 관리가 가능합니다.
5. 장애 격리:
   • 마이크로서비스는 독립적으로 실행되므로, 하나의 서비스에 문제가 생겨도 다른 서비스에는 영향을 미치지 않습니다. 즉, 장애 격리가 잘 이루어집니다.
6. 조직 구조와 유연성:
   • 마이크로서비스는 작은 팀 단위로 독립적으로 개발할 수 있기 때문에 조직의 효율성을 높입니다. 각 팀은 자신이 담당하는 서비스만 개발하고 유지 관리하면 됩니다.
7. 자동화된 배포 및 CI/CD:
   • 마이크로서비스는 작은 서비스 단위로 이루어지기 때문에 자동화된 지속적 통합(CI) 및 지속적 배포(CD) 파이프라인을 적용하기에 유리합니다.

 

---

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

 

 

1. 독립적인 서비스

 

마이크로서비스는 하나의 특정 비즈니스 기능이나 도메인에 대해 책임을 집니다. 예를 들어, 사용자 관리, 주문 처리, 결제 시스템 등은 각각 독립된 마이크로서비스로 구현됩니다.

 

각 서비스는 자체 데이터베이스를 가지고 있으며, 다른 서비스와의 의존성은 최소화됩니다.

 

2. API Gateway

 

API Gateway는 클라이언트와 여러 마이크로서비스 간의 중개자 역할을 합니다. 모든 클라이언트 요청은 먼저 API Gateway로 전달되고, 그곳에서 적절한 마이크로서비스로 라우팅됩니다.

 

API Gateway는 인증, 권한 부여, 로깅, 트래픽 관리 등을 처리할 수 있습니다.

 

여러 서비스가 있는 경우, 클라이언트가 직접 각 서비스에 접근하는 대신, API Gateway를 통해 통합된 방식으로 접근하게 됩니다.

 

Nginx를 활용한 API Gateway 구현

• Nginx는 고성능의 웹 서버로, API Gateway로 많이 사용됩니다. Nginx는 요청을 여러 마이크로서비스로 라우팅하고 로드 밸런싱을 수행하는데 효과적입니다.
• 이 설정에서는 /service1 경로로 들어오는 요청을 service1 마이크로서비스로 라우팅하고, /service2는 service2로 라우팅합니다. 로드 밸런싱을 위해 upstream 지시어를 사용합니다.

http {
    upstream service1 {
        server service1:8081;
    }

    upstream service2 {
        server service2:8082;
    }

    server {
        listen 80;

        location /service1 {
            proxy_pass http://service1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /service2 {
            proxy_pass http://service2;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

 

Spring Cloud Gateway를 활용한 API Gateway 구현 (Spring Boot)

• Spring Cloud Gateway는 Spring 애플리케이션에서 API Gateway를 구축하기 위한 프레임워크입니다. Spring Boot와 잘 통합되며, 인증, 라우팅, 필터링 등의 기능을 제공합니다.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

spring:
  cloud:
    gateway:
      routes:
        - id: service1
          uri: lb://service1
          predicates:
            - Path=/service1/**
        - id: service2
          uri: lb://service2
          predicates:
            - Path=/service2/**

 

Express.js를 활용한 API Gateway 구현 (Node.js)

• Express.js는 Node.js로 웹 애플리케이션을 쉽게 구축할 수 있는 프레임워크입니다. API Gateway로 사용할 때는 요청을 각 마이크로서비스로 전달하는 간단한 서버를 구현할 수 있습니다.

const express = require('express');
const axios = require('axios');
const app = express();

const SERVICE1_URL = 'http://service1:8081';
const SERVICE2_URL = 'http://service2:8082';

app.use('/service1', async (req, res) => {
  const response = await axios.get(`${SERVICE1_URL}${req.url}`);
  res.json(response.data);
});

app.use('/service2', async (req, res) => {
  const response = await axios.get(`${SERVICE2_URL}${req.url}`);
  res.json(response.data);
});

app.listen(3000, () => {
  console.log('API Gateway is running on port 3000');
});

 

 

3. 서비스 디스커버리

 

마이크로서비스는 동적으로 변경될 수 있기 때문에, 서비스 디스커버리가 필요합니다. 서비스 디스커버리는 각 마이크로서비스의 위치(IP 주소와 포트)를 관리하며, 다른 서비스가 이를 참조할 수 있도록 합니다.

 

예를 들어, 새로운 마이크로서비스가 배포되면, 서비스 디스커버리는 이를 자동으로 감지하고 API Gateway에 알려줍니다.

 

서비스 디스커버리는 마이크로서비스 아키텍처에서 중요한 역할을 합니다. 이를 구현하려면 Eureka, Consul, Zookeeper와 같은 도구를 사용할 수 있습니다. 서비스 디스커버리 서버는 서비스 등록과 검색을 관리하며, API Gateway나 클라이언트는 이를 통해 동적으로 서비스를 호출할 수 있습니다. Eureka를 사용한 설정이나 Consul, Zookeeper와의 통합을 통해 마이크로서비스 간의 통신을 효율적으로 관리할 수 있습니다.

Spring Cloud Gateway와 Eureka 예시

spring:
  application:
    name: gateway-service

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/   # Eureka 서버 URL

spring:
  cloud:
    gateway:
      routes:
        - id: microservice1
          uri: lb://microservice1  # Eureka에서 'microservice1'을 찾아 라우팅
          predicates:
            - Path=/microservice1/**

 

Spring Cloud Gateway 애플리케이션을 실행하면, 클라이언트 요청은 http://localhost:8080/microservice1/hello와 같은 경로로 Microservice1으로 전달됩니다. Gateway는 Eureka에서 microservice1의 위치를 동적으로 조회하고, 해당 서비스로 요청을 전달합니다.

 

 

 

4. 데이터 관리

 

각 마이크로서비스는 자체 데이터베이스를 관리합니다. 하나의 서비스가 독립적으로 데이터를 관리하기 때문에 데이터의 일관성을 유지하려면 주의가 필요합니다.

 

데이터 관리 방식은 Eventual Consistency(최종 일관성) 또는 SAGA 패턴을 사용할 수 있습니다.

 

5. 서비스 간 통신

 

서비스 간 통신은 일반적으로 REST API나 gRPC를 통해 이루어집니다. 비동기 메시징 시스템(예: RabbitMQ, Kafka)을 사용하여 서비스 간 이벤트를 전달할 수도 있습니다.

동기 통신(REST, gRPC)은 실시간 상호작용이 필요한 경우 사용되고, 비동기 통신(메시징 시스템)은 이벤트 기반 처리에 적합합니다.

 

 Apache Kafka 는
화된 메시지와 데이터의 흐름을 관리하는 구조를 가지며 빠르고 확장 가능한 작업을 위해 데이터 피드의 분산 스트리밍, 파이프 라이닝 및 재생을 위한 실시간 스트리밍 데이터를 처리하기 위한 목적으로 설계된 오픈 소스 분산형 게시/구독 메시징 플랫폼

 

 

6. 모니터링 및 로깅

 

마이크로서비스는 여러 개의 독립적인 서비스로 구성되어 있기 때문에, 각 서비스의 상태를 모니터링하고 로그를 중앙집중식으로 관리하는 시스템이 필요합니다.

Prometheus나 ELK Stack(Elasticsearch, Logstash, Kibana)을 사용하여 각 서비스의 로그를 수집하고, Grafana를 사용하여 대시보드 형태로 모니터링할 수 있습니다.

 

 

7. CI/CD 파이프라인

 

마이크로서비스는 각각 독립적으로 배포되므로, 각 서비스는 별도로 지속적 통합(CI)과 지속적 배포(CD)를 설정해야 합니다.

서비스 간의 의존성 관리와 자동화된 테스트, 배포 과정이 필수적입니다. 각 서비스가 독립적으로 업데이트되고 배포되므로, CI/CD 파이프라인은 필수적인 요소입니다.

 

---

 

MSA의 장점

1. 독립적인 배포 : 각 서비스가 독립적으로 배포되기 때문에 빠르고 유연한 배포가 가능합니다.
2. 확장성 : 애플리케이션의 일부 서비스만 확장할 수 있기 때문에 필요한 리소스를 효율적으로 사용할 수 있습니다.
3. 기술 선택의 자유 : 각 서비스는 자신에게 가장 적합한 기술 스택을 선택할 수 있습니다.
4. 장애 격리 :한 서비스가 실패하더라도 다른 서비스에는 영향을 미치지 않아 내결함성이 높습니다.

 

MSA의 단점

1. 복잡성:
   • 마이크로서비스는 여러 서비스로 나뉘어 관리되기 때문에, 서비스 간의 통합이나 서비스 간 데이터 일관성 관리가 어려워질 수 있습니다.
2. 배포 및 모니터링:
   • 여러 개의 서비스가 존재하므로 배포, 로깅, 모니터링을 관리하기 위해 더 많은 도구와 시스템이 필요합니다.
3. 성능 이슈:
   • 서비스 간의 통신이 네트워크를 통해 이루어지기 때문에, 네트워크 지연이나 오버헤드가 발생할 수 있습니다.
4. 데이터 일관성 관리:
   • 각 서비스가 독립적인 데이터베이스를 가지기 때문에 데이터 일관성 유지가 어려울 수 있습니다.

 

 

---

https://wooaoe.tistory.com/57

[MSA] MSA란 무엇인가? 개념 이해하기

 

 

https://velog.io/@hwang95/MSA-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3-%EA%B5%AC%EC%84%B1-%EC%9A%94%EC%86%8C

MSA 정리 - (3) 구성 요소

 

https://velog.io/@korea3611/Spring-Boot-Spring-Cloud-Gateway-Eureka-%EC%97%B0%EB%8F%99%ED%95%98%EA%B8%B0-MSA4

[Spring Boot] Spring Cloud Gateway, Eureka 연동하기 -MSA(4)