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
- 메시지 송신부(producer)가 SQS에 메시지 A를 보냄
- SQS는 메시지A를 사본을 만들어 여러 곳에 안전하게 보관. (유실 방지)
- 수신부(consumer)가 SQS에서 메시지 A를 처리하고자 가져감. (inflight 상태)
- SQS입장에서 수신부가 메시지A를 가져갔기 때문에, 큐에 메시지가 남아있기는 하지만, 다른 컨슈머가 메시지 A를 (또) 가져가지 않도록 일정시간동안(visibility timeout) 수신요청에 드러나지 않음
- 수신부(consumer)가 메시지를 정상 처리 완료했다면, 직접 SQS에 메시지A를 삭제하도록 요청. (완료)
- 만약 어떤 이유로 수신부(consumer)가 메시지를 삭제하지 않는다면, 일정 시간이 지나면, 메시지 A가 다시 수신 요청에 드러남. (재처리 가능)
- visibility timeout – 기본 30초. 0초에서 12시간 사이 설정 가능. 기본은 큐에 설정. 메시지 개별 설정도 가능.
SQS vs SNS vs Kafka vs RabbitMQ 스펙 비교
| SQS | SNS | Kafka | RabbitMQ | |
|---|---|---|---|---|
| 오픈소스 | - | - | 오픈소스 | 오픈소스 |
| 브로커 구분 | 메시지 브로커 | 메시지 브로커 | 이벤트 브로커 | 메시지 브로커 |
| Queue/Topic | Queue | Topic | Topic | Queue |
| 동기/비동기 | 둘 다 가능 | 비동기 | 비동기 | 둘 다 가능 |
| 메시지 전달 보장 수준 | At least once(Standard),Exactly once(FIFO) | 메시지 전달 후 삭제하기 때문에 상실 가능. | At most once,At least once,Exactly once | At most once,At least once |
| 메시지 순서 보장 수준 | Standerd - Best effort,FIFO - 순서 보장 | 한 컨슈머 그룹 기준으로 파티션의 메시지는 순서 보장 | 하나의 큐에 하나의 컨슈머 연결시 순서 보장 | |
| 모니터링 | SQS 콘솔, Cloud Watch 콘솔 이용 가능 | SQS 콘솔, Cloud Watch 콘솔 이용 가능 | 모니터링 오픈소스 연동해야함. | 모니터링 오픈소스 연동해야함. |
| 성능 | 300TPS | 무제한TPS | 100000TPS | 20000TPS |
| 개발 언어 | - | - | Scala | Erlang |
| 프로토콜 | HTTP, HTTPS, SMTP, SMS, SQS, application, lambda and firehouse | Binary protocol over TCP | AMQP, MQTT, STOMP |
