MSA(micro service Architecture)↔Monolithic Architecture


Monolithic Architecture 장단점

  • 장점
    • 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이
    • 어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않음
    • 배포가 간단함
    • 확장성
      • 로드밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행
    • 쉽게 고가용성 서버 환경 조성 가능
    • End-to-End 테스트에 용이
  • 단점
    • 프로젝트의 규모가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어짐
    • 조그마한 수정 사항이 있어도 전체를 다시 빌드 및 배포
    • 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어려움
    • 일부분의 오류가 전체에 영향을 미침 (장애 전파)
    • 기술 스택이 한 번 정해지면 바꾸기 어려움
    • 전체 애플리케이션 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어려움

Micro Service 특징

  • 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리식 아키텍처와 유사한 구조를 가짐
  • 각각의 서비스는 독립적으로 배포가 가능해야 함
  • 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 함
  • 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 함

Micro Service 연결 방법

Micro Service 장점

  • 배포 관점
    • 서비스 별 개별 배포 가능(배포 시 전체 서비스의 중단이 없음)
    • 독립 배포가 가능하므로 개발자의 자율성 증가
    • 요구 사항을 신속하게 반영하여 빠르게 배포 가능
  • 확장 관점
    • 특정 서비스에 대한 확장성에 용이
    • 클라우드 사용에 적합
  • 장애 관점
    • 장애가 전체 서비스로 확장될 가능성\낮음
    • 부분적 장애에 대한 격리 수월
  • 코드 / 유지 보수 관점
    • 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉬움
  • 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 및 운영할 수 있음
    • polyglot 개발: 여러 프로그래밍 언어, 패러다임 등을 사용

Micro service 단점

  • 성능 관점
    • 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간 증가
  • 데이터 관리 관점
    • 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움
  • 테스트 / 트랜잭션 관점
    • 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 듬
    • 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다로움
  • 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 듬
  • https://jaimemin.tistory.com/2200

Message Queue & MOM

Message Queue : 분산화된 환경에서 발신자와 수신자 사이에서 메세지를 전송하고, 수신하는 기술

→ MOM(message oriented middleware)를 통해서 구현

Message Queue 모델

  • Point to Point : 한 대의 발신자가 한 대의 수신자에게 메시지를 보내는 방식
  • pub/sub : 전송 대상이 다수 (발신자가 토픽이라고 불리는 공간에 메세지를 전송하면, 그 토픽을 구독하고 있는 수신자 모두 메시지를 수신하는 방식)


Apache Kafka

: 분산 스트리밍 플랫폼이며 데이터 파이프 라인을 만들 때 주로 사용되는 오픈소스 솔루션

Kafka 특징

  • 높은 처리량과 낮은 지연시간: 카프카는 대용량 데이터를 실시간으로 처리할 수 있도록 설계되었다. 따라서 높은 TPS를 가지며, 실시간 데이터 스트림, 로그 집계, 이벤트 드리븐 아키텍처 구현에 적합하다.
  • 메시지 내구성: 카프카의 메시지는 메모리가 아닌 디스크에 영구적으로 저장된다. 예로 Redis Pub/Sub과 같은 경우 메시지가 디스크에 저장되지 않으며, 장애 발생 시 메시지는 유실된다. ActiveMQ, RabbitMQ 모두 디스크에 메시지를 영구 저장하는 옵션도 지원하지만, 기본적으로는 컨슘된 메시지는 소실된다. 반면 카프카는 기본적으로 모든 메시지를 디스크에 영구 저장한다.
  • 분산 아키텍처: 후술하겠지만 카프카는 카프카 클러스터 내부에 여러대의 브로커 서버를 구성하여 높은 확장성(scalability)과 내결함성(fault tolerance)을 갖는다. 이는 RabbitMQ, ActiveMQ와 비교했을 때 카프카만이 가지고 있는 차별점이다.
  • Pull 기반 메시지 소비: RabbitMQ와 ActiveMQ는 브로커가 컨슈머로 메시지를 Push 하는 방식인데 반해, 카프카는 컨슈머가 능동적으로 브로커로부터 메시지를 가져오는 Pull 방식을 취했다. 이로 인해 컨슈머는 처리 능력에 따라 메시지를 컨슘할 수 있기 때문에, 브로커로부터 압도당하지 않고 최적의 성능을 낼 수 있다.

Kafka 사용 이유

  • 병렬처리에 의한 데이터 처리율 향상
  • 데이터 유실 방지
  • 클러스터링에 의한 고가용성 서비스

RabbitMQ

:AMQP를 구현한 오픈소스 메세지 브로커

🏹AMQP : 클라이언트가 메시지 미들웨어 브로커와 통신할 수 있게 해주는 메세징 프로토콜

RabbitMQ - Exchange속성

  • Name: Exchange 이름
  • Type: 메시지 전달 방식
    • Direct: 라우팅 키가 정확히 일치하는 Queue에 메시지 전송
    • Fanout: 해당 Exchange에 등록된 모든 Queue에 메시지 전송
    • Topic: 라우팅 키 패턴이 일치하는 Queue에 메시지 전송
    • Headers: [key:value]로 이루어진 header값을 기준으로 일치하는 Queue에 메시지 전송
  • Durability: 브로커가 재시작될 때 남아있는지 여부
    • Durable: 브로커가 재시작되어도 디스크에 저장되어 남아있음
    • Transient: 브로커가 재시작되면 사라짐
  • Auto-delete: 마지막 Queue 연결이 해제되면 삭제

RabbitMQ - Queues

  • Name
  • Durable
  • Exclusive
  • Auto-delete
  • Arguments: 메시지 TTL, Max Length 같은 추가 기능 명시

AWS SQS

: 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메시지 대기열 서비스

기본 특징

  • 각 메시지는 최대 256KB 크기입니다. S3에 메시지 본문을 담는 방식을 추가로 지원하기 때문에, 제한 없이 쓸 수도 있음
  • 큐에 저장되는 메시지 건 수의 제한 없음
  • 다만 각각의 메시지는 최대 14일간 유지됩니다. 14일 이내에 메시지를 처리해야 함
기능표준대기열FIFO 대기열
메시지 보장최소 한번 (중복 수신 가능)정확히 한번
처리량사실상 무제한최대 3,000메시지/초
비용약 $0.4/백만건약 $0.5/백만건
순서보장순서가 바뀔 수 있다먼저 송신한 메시지가 먼저 수신된다

메시지 생명주기 – lifecycle

  1. 메시지 송신부(producer)가 SQS에 메시지 A를 보냄
  2. SQS는 메시지A를 사본을 만들어 여러 곳에 안전하게 보관. (유실 방지)
  3. 수신부(consumer)가 SQS에서 메시지 A를 처리하고자 가져감. (inflight 상태)
  4. SQS입장에서 수신부가 메시지A를 가져갔기 때문에, 큐에 메시지가 남아있기는 하지만, 다른 컨슈머가 메시지 A를 (또) 가져가지 않도록 일정시간동안(visibility timeout) 수신요청에 드러나지 않음
  5. 수신부(consumer)가 메시지를 정상 처리 완료했다면, 직접 SQS에 메시지A를 삭제하도록 요청. (완료)
  6. 만약 어떤 이유로 수신부(consumer)가 메시지를 삭제하지 않는다면, 일정 시간이 지나면, 메시지 A가 다시 수신 요청에 드러남. (재처리 가능)
  • visibility timeout – 기본 30초. 0초에서 12시간 사이 설정 가능. 기본은 큐에 설정. 메시지 개별 설정도 가능.

SQS vs SNS vs Kafka vs RabbitMQ 스펙 비교

SQSSNSKafkaRabbitMQ
오픈소스--오픈소스오픈소스
브로커 구분메시지 브로커메시지 브로커이벤트 브로커메시지 브로커
Queue/TopicQueueTopicTopicQueue
동기/비동기둘 다 가능비동기비동기둘 다 가능
메시지 전달 보장 수준At least once(Standard),Exactly once(FIFO)메시지 전달 후 삭제하기 때문에 상실 가능.At most once,At least once,Exactly onceAt most once,At least once
메시지 순서 보장 수준Standerd - Best effort,FIFO - 순서 보장한 컨슈머 그룹 기준으로 파티션의 메시지는 순서 보장하나의 큐에 하나의 컨슈머 연결시 순서 보장
모니터링SQS 콘솔, Cloud Watch 콘솔 이용 가능SQS 콘솔, Cloud Watch 콘솔 이용 가능모니터링 오픈소스 연동해야함.모니터링 오픈소스 연동해야함.
성능300TPS무제한TPS100000TPS20000TPS
개발 언어--ScalaErlang
프로토콜HTTP, HTTPS, SMTP, SMS, SQS, application, lambda and firehouseBinary protocol over TCPAMQP, MQTT, STOMP

0개의 댓글