1. MSA

1.1 Monolithic Architecture VS Micro Service Architecture

• 둘 모두 애플리케이션 개발을 위한 아키텍처 스타일이다.

• Monolithic Architecture : 소프트웨어 구성요소가 한 프로젝트에 통합되어있는 형태
  → 일정 규모 이상의 서비스에서 시스템 구조 파악, 부분적 장애가 전체의 영향을 미치는 단점이 발생
• MSA(Micro Service Architecture) : 하나의 큰 App을 여러 개의 작은 App으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐
  → 구성요소를 여러 작은 조각으로 나누어 부분적 에러와 시스템구조 파악이 수월해짐

1.2 MSA의 특징

• 독립적 배포 가능
  • 각 서비스는 독립적으로 배포 및 업데이트가 가능해, 시스템의 일부가 업데이트될 때 전체 시스템을 재배포하지 않아도 됩니다.
• 작은 서비스 단위
  • 각 서비스는 단일 비즈니스 기능이나 도메인을 담당하며, 이를 통해 개발, 유지보수, 확장성을 향상시킵니다.
• 자율적 팀
  • 특정 서비스에 대한 독립적 팀 구성이 가능하여 빠른 의사 결정과 개발이 가능하도록 지원합니다.
• 서비스 단위 분리
  • 서비스는 단일 책임 원칙(Single Responsibility Principle)에 따라 하나의 비즈니스 기능에 집중해야 합니다.
• 데이터베이스 분리
  • 각 서비스는 자체 데이터베이스를 가질 수 있으며, 다른 서비스와 데이터베이스를 공유하지 않는 것이 원칙입니다.

2. 서비스 메시(Service Mesh)의 개념과 필요성

• 서비스 메시란
  • 정의 : 마이크로서비스 아키테처에서 서비스 간의 통신을 관리하고 최적화하는 인프라
  • 주요역할 : 애플리케이션의 네트워크 통신을 추상화하고 관리하는 것
  • App 서비스 간 모든 통신을 처리하는 소프트웨어 계층에 특정 모듈을 삽입하여 애플리케이션에 대한 라우팅, 보안 및 안정성 기능을 추가하는 도구
  • 쿠버네티스와 같은 컨테이너 오케스트레이션 환경에서 일반적으로 애플리케이션 코드와 함께 배치된 확장 가능한 네트워크 프록시 모듈로 구현됨
  • 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적 트래픽 제어와 같은 새로운 기능을 제공

• 서비스 메시의 동작 방식
  • 페이지에 대한 사용자의 요청이 발송되면 사용자의 회사 웹 프록시가 먼저 이를 수신
  • 요청이 프록시 보안 조치를 통과하면 이 페이지를 호스팅하는 서버로 전송
  • 이 페이지가 프록시로 돌아가서 다시 보안 조치를 수행
  • 최종적으로 프록시에서 사용자에게 전송됨
  
• 서비스 메시가 필요한 이유
  • MSA 각 서비스가 독립적으로 운영되기 때문에 서비스간의 통신과 상호작용을 관리하는 것이 중요
  • 이러한 통신에서 발생할 수 있는 복잡한 문제를 해결하기 위해 서비스 메시가 필요
• 서비스 메시의 주요 구성 요소: 데이터 플레인, 제어 플레인
  • Data Plane : 각 서비스에 배포되는 프록시로 구성 프로시는 네트워크 트래픽을 중계하고 서비스 요청/응답을 관리
  • Control Plane : 서비스 메시의 전반적인 설정을 관리하는 역할 트래픽 관리 정책을 배포, 흐름을 정의하는 규칙을 제공
• 마이크로서비스와 서비스 메시의 연관성 및 역할 구분

  • 역할 구분:
    - 마이크로서비스: 애플리케이션의 비즈니스 로직을 구현하는 서비스들입니다. 각 서비스는 독립적으로 운영되며, 자신만의 데이터베이스나 API를 가질 수 있습니다.
    - 서비스 메시: 마이크로서비스 간의 통신을 관리하고 최적화하는 인프라입니다. 서비스 메시가 없으면, 각 마이크로서비스가 서비스 간의 통신을 처리하는 책임을 직접 지게 되며, 이는 복잡도와 유지보수 문제를 일으킬 수 있습니다.

    ⇒ 서비스 메시는 마이크로서비스의 통신 문제를 해결하고 안정성 보안 성능 등을 향상시키는 역할을 한다.

3. 서비스 메시 아키텍처의 주요 기능

• 트래픽 관리: 요청 라우팅, 로드 밸런싱, 서비스 디스커버리
  • 서비스 메시의 가장 중요한 기능 중 하나는 서비스 간의 트래픽관리
  • 요청라우팅
    • 트래픽 라우팅을 세밀하게 정의할 수 있다. 트래픽버전별로 분배하거나 장애가 발생한 서비스로의 트래픽을 차단하고 정상 서비스로 우회시키는 등의 동작을 할 수 있다.
    • A/B테스트나 Canary 배포와 같은 방식으로 트래픽을 특정버전으로 제한적으로 보내어 점진적인 배포가 가능하도록 한다.
  • 로드밸런싱
    • 서비스 간의 트래픽이 몰리지 않도록 트래픽을 분산한다.
    • 로드 밸런싱하여 효율적인 자원 활용과 높은 가용성을 유지할 수 있다.
  • 서비스 디스커버리
    • 서비스들이 동적으로 생성되고 종료되기 때문에 각 서비스의 위치를 지속적으로 추적한다.
    • 서비스 메시가 자동으로 서비스 인스턴스를 검색하고, 이를 통해 서비스 간 통신을 원활히 처리한다.
• 보안 강화: 인증(인바운드, 아웃바운드 트래픽 암호화), TLS 적용
  • 인증(Authentication)
    • 인증 기능을 통해 서비스 간의 통신에서 각 서비스의 신원을 확인하고, 유효한 요청만 처리할 수 있도록 한다. 인바운드, 아웃바운드 요청에 대해 엄격한 인증 정책을 적용하여 보안을 가와한다.
  • 트래픽 암호화
    • 서비스 메시에서는 서비스 간 통신을 암호화하여 Man-in-the-Middle (MITM) 공격이나 스니핑(sniffing) 등의 위험으로부터 보호합니다.
    • *TLS (Transport Layer Security)**를 사용하여 모든 인바운드와 아웃바운드 트래픽을 암호화할 수 있습니다. 이로 인해 서비스 간의 트래픽은 반드시 암호화된 채로 전달되며, 민감한 데이터가 외부로 유출되는 것을 방지합니다.

      TLS란 HTTPS Protocol에서 과거에는SSL 인증을 통해 암호화를 하였는데 현재는 보안을 강화하여 TLS 보안을 통해 HTTPS Protocol을 관리한다.

  • TLS 적용
    • 서비스 메시에서는 Mutual TLS (mTLS)를 통해 서로 다른 서비스들이 안전하게 통신할 수 있도록 지원합니다. mTLS는 두 서비스가 서로를 인증하고, 데이터를 암호화하여 무결성을 보장하는 방식입니다.
    • mTLS는 특히 신뢰할 수 없는 네트워크 환경에서도 서비스 간의 통신이 안전하게 이루어지도록 합니다.
• 관찰 가능성(Observability): 로그, 메트릭, 트레이싱
  • 로그 (Logging):
    • 서비스 메시에서는 각 서비스 간의 요청과 응답에 대한 로그를 수집하고 중앙화하여 모니터링할 수 있습니다. 이를 통해 트래픽의 흐름을 추적하고, 장애나 문제의 원인을 파악하는 데 중요한 정보를 제공합니다.
    • 예를 들어, 요청이 어디서 지연되고 있는지, 오류가 발생한 부분이 무엇인지 등을 실시간으로 추적할 수 있습니다.
  • 메트릭 (Metrics):
    • 서비스 메시에서는 메트릭을 수집하여 서비스의 성능을 모니터링합니다. 각 서비스의 응답 시간, 트래픽 양, 에러 비율 등을 측정하여 시스템의 건강 상태를 실시간으로 확인할 수 있습니다.
    • 이 메트릭들은 대시보드에 시각화되어 서비스 상태를 즉시 파악하고, 문제를 신속하게 해결할 수 있도록 지원합니다.
  • 트레이싱 (Tracing):
    • *분산 트레이싱 (Distributed Tracing)**은 서비스 메시의 핵심 기능 중 하나입니다. 서비스 메시에서는 각 서비스 호출이 시스템 전체에서 어떻게 흐르는지 추적할 수 있습니다.
    • OpenTelemetry 또는 Jaeger와 같은 도구를 사용하여 각 요청이 여러 서비스 간을 거쳐 어떻게 이동하는지 추적하고, 서비스 간의 지연이나 병목 지점을 식별할 수 있습니다.
• 장애 복구: 회로 차단기, 리트라이 및 타임아웃 설정
  • 회로 차단기 (Circuit Breaker):
    • 회로 차단기는 특정 서비스가 장애를 일으킬 때 그 서비스로의 추가 요청을 차단하여 시스템 전체의 장애 확산을 방지하는 역할을 합니다. 회로 차단기는 서비스의 실패를 감지하고, 일정 시간 동안 실패를 감지한 서비스로의 트래픽을 자동으로 차단하여, 부하를 다른 서비스로 분산시키는 방식으로 동작합니다.
    • 이 기능은 서비스의 안정성을 높이고, 트래픽이 문제가 발생한 서비스로 가지 않도록 함으로써 시스템 전체의 가용성을 유지합니다.
  • 리트라이 및 타임아웃 (Retry & Timeout):
    • 리트라이는 서비스 간 통신 중에 일시적인 오류가 발생했을 때 자동으로 요청을 재시도하는 기능입니다. 이 기능은 일시적인 네트워크 오류나 서비스 지연으로 인한 실패를 처리하는 데 유용합니다.
    • 타임아웃은 요청이 일정 시간 내에 처리되지 않으면 자동으로 실패로 간주하고, 응답을 기다리는 시간을 제한합니다. 이는 서비스가 무한 대기 상태에 빠지는 것을 방지하고, 시스템의 효율적인 자원 관리를 돕습니다.

4. 사이드카 패턴

• Service Mesh 구현은 보통 서비스의 앞단에 경량화 프록시를 사이드카 패턴으로 배치하여 서비스간 통신을 제어하는 방법을 사용

• 사이드카 패턴이란
  • 클라우드 디자인 패턴의 일종 - 보조역할로 오토바이 옆에 연결하는 사이드카에서 유래됨
  • 기본 App 외 필요한 추가 기능을 별도의 App으로 구현하고 이를 동일한 프로세스 또는 컨테이너 내부에 배치하는 것
• 사이드카 App의 장점
  • 기본 App 로직을 수정하지 않고 추가 기능을 수행할 수 있음
  • 기본 App과 리소스를 공유하기에 모니터링(Metric, Proxy) 동작 등을 수행할 수 있음

5. 주요 서비스 메시 기술(구현체)

• Istio: 아키텍처, 기능, 주요 사용 사례
  • Kubernetes와 함께 작동하도록 설계된 오프 소스 서비스 메시 프로젝트
  • 트래픽관리, 보안강화, Observabillity, 장애복구, 등 많은 기능을 제공하지만 사용자가 다양한 옵션을 직접 설정해야 하는 경우가 많아 시간이 많이 소요됨
  • 성능 오버헤드 : 기능이 풍부하여, 사이드카 프록시가 처리하는 오버헤드가 상대적으로 높다
• Linkerd: 가벼운 서비스 메시의 특징과 장점
  • CNCF의 프로젝트 간단하고 빠른 설치 및 관리, 높은 성능을 자랑함
  • 경량화 간단한 설정 : Istio보다 훨씬 가벼운 서비스 메시, 설정관리가 간단하며 빠른설치와 운영이 가능
  • 높은 성능을 제공하며, 경량화된 설계로 인해 오버헤드가 적다
• Consul: 네트워크 관리와 서비스 디스커버리에 특화된 서비스 메시
  • HashiCorp에서 제공하는 서비스 메시 솔루션, 서비스 디커버리 및 구성관리를 주된 목표로 함
  • 서비스 디스커버리와 분산 키-값 저장소를 제공

<Reference>

Redhat
MSA제대로 이해하기-(1)