Now Loading ...
-
-
🏗️[Architecture] 큐(Queue)와 토픽(Topic)?
🏗️[Architecture] 큐(Queue)와 토픽(Topic)?
📌 Intro.
↘︎ 메시지 브로커(Message Broker)는 큐(Queue)와 토픽(Topic)이라는 두 가지 주요 방식으로 메시지를 전달합니다.
↘︎ 이 두 방식은 전송 방식, 수신자 수, 사용 사례에서 차이를 보입니다.
✅1️⃣ 큐(Queue)
설명:
↘︎ 큐(Queue)는 메시지를 일렬로 저장하는 구조
↘︎ 메시지는 한 번만 소비되며, 단일 소비자(Single Consumer)가 이를 처리함.
↘︎ FIFO(First-In-First-Out) 방식으로 메시지를 전달.
↘︎ 한 메시지는 하나의 소비자만 처리할 수 있음.
특징:
↘︎ 단일 소비자 패턴 : 하나의 메시지는 한 번만 처리 됨.
↘︎ 순서 보장 : 메시지는 삽입된 순서대로 전달됨.
↘︎ 부하 분산 : 여러 소비자가 동시에 큐에 연결되면, 메시지가 분산되어 처리됨.
사용 사례:
↘︎ 작업 대기열(Task Queue) : 백그라운드 작업, 이메일 전송, 비디오 인코딩 등.
↘︎ 단일 메시지 처리 : 한 번만 처리해야 하는 작업.
예시 기술:
↘︎ Amazon SQS (Simple Queue Service)
↘︎ RabbitMQ (Queue 모드)
↘︎ Apache Active MQ
✅2️⃣ 토픽(Topic)
설명:
↘︎ 토픽은 발행-구독(Pub/Sub) 모델을 사용.
↘︎ 하나의 메시지가 여러 구독자(Subscribers)에게 동시에 전달 될 수 있음.
↘︎ 메시지는 주제(Topic)에 게시되고, 해당 주제(Topic)를 구독(Subscribe)한 모든 구독자(Subscribers)가 메시지를 받음.
특징:
↘︎ 다중 소비자 패턴 : 하나의 메시지가 여러 소비자에게 동시에 전달됨.
↘︎ 유연한 구독 모델 : 각 구독자는 특정 토픽을 필터링하여 관심 있는 메시지만 수신할 수 있음.
↘︎ 브로드 캐스트 : 메시지가 여러 수신자에게 동시에 전달됨.
사용 사례:
↘︎ 이벤트 알림 : 주문 완료 알림, 사용자 가입 알림 등
↘︎ 실시간 데이터 스트리밍 : 실시간 가격 정보, 로그 수집 등
↘︎ 다중 시스템 동기화 : 여러 서비스 간 동기화가 필요할 때
예시 기술:
↘︎ Apache Kafka(Topic 기반 메시징)
↘︎ Amazon SNS(Simple Notification Service)
↘︎ RabbitMQ(Topic Exchange 모드)
✅3️⃣ 큐(Queue) vs 토픽(Topic) 비교.
구분
큐(Queue)
토픽(Topic)
메시지 소비
한 메시지는 하나의 소비자만 처리
한 메시지는 여러 구독자에게 전달
통신 방식
Point-to-Point(P2P)
Publish-Subscribe(Pub/Sub)
순서 보장
FIFO 순서 보장
순서는 보장되지 않을 수도 있음
사용 사례
백그라운드 작업, 비동기 요청 처리
실시간 알림, 브로드캐스트 이벤트
구성 요소
Producer ➞ Queue ➞ Consumer
Producer ➞ Topic ➞ Subscribers
✅4️⃣ 요약.
1. 큐(Queue):
메시지를 단일 소비자에게 전달
순서 보장(FIFO)
사용 사례: 백그라운드 작업, 작업 대기열
2. 토픽(Topic):
메시지를 여러 구독자에게 동시에 전달
브로드캐스트 및 실시간 이벤트 처리
사용 사례: 실시간 알림, 이벤트 알림
✅5️⃣ 핵심 포인트.
큐(Queue) : 하나의 메시지는 한 번만 소비됨(단일 소비자)
토픽(Topic) : 하나의 메시지는 여러 소비자에게 동시에 전달됨(다중 구독자)
👉 올바른 선택:
작업 대기열, 백그라운드 처리 ➞ 큐(Queue)
이벤트 브로드캐스트, 실시간 알림 ➞ 토픽(Topic)
Architecture
· 2024-12-30
-
🏗️[Architecture] Message(메시지)란 무엇일까?
🏗️[Architecture] Message(메시지)란 무엇일까?
📌 Intro.
↘︎ 메시지(Message)는 시스템, 서비스 또는 애플리케이션 간에 주고받는 데이터 단위입니다.
↘︎ 주로 하나의 시스템이 다른 시스템에 정보, 명령, 이벤트, 상태, 데이터를 전달할 때 사용됩니다.
1️⃣ 메시지(Message)의 기본 개념.
🎯 정의 : 서로 다른 시스템 간에 주고받는 데이터 패킷 또는 정보 단위.
🎯 역할 : 시스템 간에 명확하고 구조화된 방식으로 데이터를 전달.
🎯 형태 : 텍스트, JSON, XML, 바이너리 데이터 등 다양한 형태로 존재할 수 있음.
2️⃣ 메시지(Message)의 구성 요소.
1️⃣ 헤더(Header)
↘︎ 메시지의 메타데이터 (예: ID, 타임스탬프, 발신자, 수신자)
↘︎ 메시지 라우팅 및 우선순위 정보 포함
2️⃣ 본문(Body)
↘︎ 실제 전달하려는 데이터 (예: 사용자 요청, 결과 값, 상태 정보)
↘︎ JSON, XML, Plain Text, 바이너리 등 다양한 형태
3️⃣ 속성(Properties)
↘︎ 추가적인 메타데이터 (예: 메시지 타입, 만료 시간 등)
3️⃣ 메시지(Message)의 예시.
📌 1. 이벤트(Event) 기반 메시지
↘︎ 설명 : 특정 시스템에서 발생한 이벤트를 다른 시스템에 알리는 용도.
↘︎ 예시 : 주문 시스템 ➞ “주문이 완료되었습니다.”
📌 2. 명령(Command) 기반 메시지
↘︎ 설명 : 한 시스템이 다른 시스템에 특정 작업을 지시.
↘︎ 예시 : 사용자 서비스 ➞ “사용자 프로필을 업데이트하세요.”
📌 3. 요청/응답(Request/Response) 메시지
↘︎ 설명 : 요청을 보내고, 그에 대한 응답을 받음.
↘︎ 예시 : 클라이언트 ➞ “주문 상태를 확인해주세요.”, 서버 ➞ “주문이 배송 중입니다.”
📌 4. 데이터 전달 메시지
↘︎ 설명 : 시스템 간 데이터 전달.
↘︎ 예시 : 결제 서비스 ➞ “결제 완료 정보를 전송합니다.”
4️⃣ 메시지(Message)의 중요성.
1️⃣ 비동기 통신 지원 : 시스템이 즉각적인 응답을 기다리지 않고 독립적으로 작동.
2️⃣ 시스템 간의 느슨한 결합(Loose Coupling) : 한 시스템이 다른 시스템의 상태나 세부사항을 몰라도 상호작용 가능.
3️⃣ 확장성(Scalability) : 시스템 추가 및 변경 시 최소한의 영향.
4️⃣ 안정성(Reliability) : 메시지를 안전하게 저장 및 전달.
5️⃣ 메시지(Message) 예시 시나리오.
📌 쇼핑몰 주문 처리 예시
↘︎ 1. 사용자 서비스 : “사용자가 주문을 생성했습니다.” ➞ 메시지 브로커로 메시지 전송
↘︎ 2. 결제 서비스 : 메시지 브로커로부터 메시지 수신 ➞ 결제 처리 시작
↘︎ 3. 배송 서비스 : 메시지 브로커로부터 결제 완료 메시지 수신 ➞ 배송 처리 시작
6️⃣ 메시지 브로커에서의 메시지.
🎯 발행(Publish) : 메시지를 브로커에 보냄.
🎯 구독(Subscribe) : 브로커로부터 특정 주제의 메시지를 수신.
🎯 라우팅(Routing) : 브로커가 메시지를 올바른 대상에게 전달.
🚀 결론.
↘︎ 메시지(Message)는 시스템 간 통신을 위한 데이터 단위.
↘︎ 주요 역할 : 정보 전달, 상태 업데이트, 이벤트 알림, 명령 실행.
↘︎ 중요성 : 비동기 통신, 느슨한 결합, 확장성 보장.
📝 메시지(Message)는 메시지 브로커(Message Broker)를 통해 안전하고 효율적으로 송수신되며, 다양한 시스템 간의 통합 및 협력을 가능하게 함.
Architecture
· 2024-12-30
-
🏗️[Architecture] Message Broker(메시지 브로커)란 무엇일까?
🏗️[Architecture] Message Broker(메시지 브로커)란 무엇일까?
📌 Intro.
↘︎ 메시지 브로커(Message Broker)는 서로 다른 시스템, 또는 애플리케이션 간의 메시지(Message)를 안전하게 송수신하도록 중간에서 중개하는 소프트웨어입니다.
↘︎ 주로 비동기 통신과 시스템 간의 느슨한 결합(loose coupling)을 보장하는 데 사용됩니다.
1️⃣ 메시지 브로커(Message Broker)의 역할.
📌 1. 메시지 전달.
↘︎ 생산자(Producer)와 소비자(Consumer) 간의 메시지(Message)를 중간에서 전달합니다.
📌 2. 비동기 통신.
↘︎ 시스템 간에 실시간으로 응답을 기다리지 않고 독립적으로 작동할 수 있습니다.
📌 3. 메시지 큐(Message Queue)
↘︎ 메시지를 임시로 저장하여 소비자가 메시지를 처리할 수 있도록 보장합니다.
📌 4. 메시지 라우팅(Message Routing)
↘︎ 특정 조건이나 규칙에 따라 메시지를 적절한 소비자에게 전달합니다.
📌 5. 신뢰성
↘︎ 메시지가 손실되지 않도록 저장 및 재전송 기능을 제공합니다.
📌 6. 확장성(Scalability)
↘︎ 메시지 브로커를 사용하면 시스템이 더 많은 메시지를 처리할 수 있도록 쉽게 확장할 수 있습니다.
2️⃣ 메시지 브로커(Message Broker)의 동작 방식.
1. 생산자(Producer):
↘︎ 메시지를 생성하고 브로커에 전달합니다.
2. 브로커(Broker):
↘︎ 메시지를 임시 저장하고, 특정 규칙에 따라 올바른 소비자에게 전달합니다.
3. 소비자(Consumer):
↘︎ 메시지를 수신하고 해당 메세지를 처리합니다.
4. 메시지 큐(Message Queue):
↘︎ 메시지를 저장하는 대기열입니다.
5. 메시지 주제(Topic):
↘︎ 여러 소비자가 동일한 메시지를 구독(Subscribe)할 수 있습니다.
3️⃣ 메시지 브로커(Message Broker)의 아키텍처.
1. 포인트-투-포인트(Point-to-Point,P2P)
↘︎ 큐(Queue) 기반의 메시징 모델
↘︎ 한 생산자가 한 소비자에게만 메시지를 전달합니다.
↘︎ 예시: AWS SQS, RabbitMQ
2. 퍼블리시-서브스크라이브(Publish-Subscribe, Pub/Sub)
↘︎ 토픽(Topic) 기반의 메시징 모델
↘︎ 한 생산자가 여러 소비자에게 메시지를 전달할 수 있습니다.
↘︎ 예시: Apache Kafka, AWS SNS
4️⃣ 메시지 브로커의 장점.
1. 비동기 처리:
↘︎ 생산자와 소비자가 독립적으로 작동합니다.
2. 확장성:
↘︎ 시스템이 더 많은 트래픽을 처리할 수 있습니다.
3. 유연성:
↘︎ 서비스 간의 결합도가 낮아져 변경에 유연하게 대응할 수 있습니다.
4. 신뢰성:
↘︎ 메시지가 손실되지 않고 안전하게 전달됩니다.
5. 부하 분산:
↘︎ 메시지를 여러 소비자에게 분산하여 처리할 수 있습니다.
5️⃣ 메시지 브로커의 유형.
1. RabbitMQ
↘︎ 유형 : 메시지 큐(Message Queue)
↘︎ 프로토콜 : AMQP (Advanced Message Queuing Protocol)
↘︎ 특징 : 경량, 높은 안정성
2. Apache Kafka
↘︎ 유형 : 이벤트 스트리밍 플랫폼
↘︎ 프로토콜 : TCP
↘︎ 특징 : 높은 처리량, 실시간 데이터 스트리밍
3. AWS SQS (Simple Queue Service)
↘︎ 유형 : Managed 메시지 큐
↘︎ 특징 : 서버리스, 높은 확장성
4. AWS SNS (Simple Notification Service)
↘︎ 유형 : 퍼블리시/서브스크라이브 모델
↘︎ 특징 : 알림 및 브로드캐스팅
5. ActiveMQ
↘︎ 유형 : 메시지 브로커
↘︎ 프로토콜 : AMQP, MQTT 등 지원
↘︎ 특징 : 유연하고 확장 가능
6️⃣ 메시지 브로커의 사용 사례.
1. 주문 처리 시스템(Order Processing System)
↘︎ 주문이 생성되면 결제 서비스, 재고 서비스, 배송 서비스에 메시지를 전달
2. 알림 시스템(Notification System)
↘︎ 사용자에게 이메일, SMS, 알림 등을 보낼 때
3. 로그 및 모니터링(Log & Monitoring)
↘︎ 서버 로그나 사용자 활동 데이터를 실시간으로 처리
4. IoT 시스템
↘︎ 수많은 IoT 장치로부터 데이터를 수집 및 처리
7️⃣ 메시지 브로커 선택 기준.
1. 성능 : 높은 처리량과 낮은 대기 시간
2. 확장성 : 대량의 메시지를 처리할 수 있는가
3. 신뢰성 : 메시지 손실 방지 기능
4. 보안 : 메시지 암호화 및 인증 지원
5. 운영 및 관리 : 설정 및 유지보수의 편의성
8️⃣ 메시지 브로커 비교.
브로커
유형
특징
사용사례
RabbitMQ
큐
안정적, AMQP 지원
금융 거래, 주문 처리
Kafka
스트림
높은 처리량, 분산형
실시간 데이터 분석
AWS SQS
큐
서버리스, 확장성
분산 시스템 큐
AWS SNS
토픽
알림 서비스
이벤트 알림
🚀 결론.
메시지 브로커(Message Broker)는 시스템 간 데이터 교환을 안전하고 효율적으로 수행하는 중간 역할을 합니다.
큐(Queue) 기반과 토픽(Topic) 기반으로 구분됩니다.
선택할 때는 성능, 확장성, 신뢰성을 고려해야 합니다.
비동기 처리, 분산 시스템, 이벤트 중심 아키텍처 등 다양한 환경에서 널리 사용됩니다.
🔑 핵심 요약.
메시지 브로커란 ? : 시스템 간 메시지 전달 중개자
유형 : 큐(P2P), 토픽(Pub/Sub)
주요 브로커 : RabbitBQ, Kafka, AWS SQS, AWS SNS
Architecture
· 2024-12-30
-
🏗️[Architecture] 이벤트 브로커(Event Broker)란 무엇일까?
🏗️[Architecture] 이벤트 브로커(Event Broker)란 무엇일까?
📌 Intro.
↘︎ 이벤트 브로커(Event Broker)는 시스템이나 애플리케이션 산에 이벤트(Event)를 안전하게 전달하고 관리하는 중개자 역할을 하는 소프트웨어.
↘︎ 주로 이벤트 중심 아키텍처(Event-Driven Architecture, EDA)에서 사용되며, 비동기식 통신과 시스템간의 느슨한 결합(Loose Coupling)을 지원함.
✅1️⃣ 이벤트(Event)란?
↘︎ 이벤트(Event)는 시스템 내에서 발생한 특정 상황이나 변경 사항을 의미함.
↘︎ 예를 들어, 사용자가 주문을 생성했을 때(Order Created), 상품 재고가 부족할 때(Stock Depleted) 등이 이벤트(Event)임.
✅2️⃣ 이벤트 브로커의 역할.
1. 이벤트 수집(Event Ingestion)
↘︎ 다양한 소스(애플리케이션, 서비스 IoT 장치 등)로 부터 이벤트를 수집함.
2. 이벤트 라우팅(Event Routing)
↘︎ 특정 조건에 따라 적절한 대상(구족자, 서비스)에게 이벤트를 전달함.
3. 이벤트 큐잉(Event Queuing)
↘︎ 이벤트를 임시로 저장하여 이벤트 손실을 방지합니다.
4. 비동기 처리(Asynchronous Processing)
↘︎ 이벤트를 발행한 시스템과 소비하는 시스템이 독립적으로 작동합니다.
5. 확장성(Scalability)
↘︎ 많은 양의 이벤트를 동시에 처리할 수 있도록 지원합니다.
6. 내구성(Durability)
↘︎ 이벤트가 손실되지 않도록 안전하게 저장합니다.
✅3️⃣ 이벤트 브로커의 동작 방식.
1. 이벤트 발행(Publish)
↘︎ 이벤트 생산자(Producer)가 이벤트 브로커에 이벤트를 발행함.
2. 이벤트 저장(Store)
↘︎ 이벤트 브로커는 받은 이벤트를 저장하거나 일시적으로 보관함.
3. 이벤트 라우팅(Routing)
↘︎ 저장된 이벤트를 규칙에 따라 특정 구독자(Consumer)에게 전달함.
4. 이벤트 소비(Consume)
↘︎ 이벤트 소비자(Consumer)가 이벤트를 받아 처리함.
✅4️⃣ 이벤트 브로커(Event Broker) vs 메시지 브로커(Message Broker)
구분
이벤트 브로커(Event Broker)
메시지 브로커(Message Broker)
주요 개념
이벤트(Event)를 전달
메시지(Message)를 전달
발생 시점
시스템에서 상태 변경이 발생할 때
시스템 간 통신이 필요할 때
모델
주로 Pub/Sub (퍼블리시-서브스크라이브)
주로 P2P (포인트-투-포인트)
예시
Apache Kafka, AWS EventBridge
RabbitMQ, AWS SQS
주요 사용 사례
이벤트 스트림 처리, 실시간 분석
비동기 작업 처리, 큐 기반 통신
✅5️⃣ 이벤트 브로커의 주요 특징.
1. Publisher-Subscriber 패턴(Pub/Sub)
↘︎ 이벤트 발행자는 이벤트를 브로커에 전달하고, 구독자는 관심 있는 이벤트를 수신함.
2. 비동기 통신
↘︎ 이벤트가 브로커를 통해 전달되므로 시스템 간 동기화가 필요하지 않음.
3. 느슨한 결합(Loose Coupling)
↘︎ 생산자와 소비자는 서로 직접 연결되지 않고 브로커를 통해 통신함.
4. 이벤트 소싱(Event Sourcing)
↘︎ 모든 이벤트를 기록하고 필요할 때 재생할 수 있음.
5. 확장성 및 신뢰성
↘︎ 수백만 개의 이벤트를 처리할 수 있고, 이벤트 손실을 방지함.
✅6️⃣ 이벤트 브로커의 사용 사례.
1. 실시간 데이터 처리.
↘︎ 실시간 거래, 사용자 활동 로그 처리.
2. 마이크로서비스 아키텍처.
↘︎ 서로 독립된 서비스 간의 이벤트 전달.
3. IoT 데이터 스트림.
↘︎ IoT 장치로부터 대량의 데이터를 수집 및 분석.
4. 알림 시스템(Notification System).
↘︎ 이벤트 발생 시 사용자에게 알림 전송.
5. 데이터 파이프라인(Data Pipeline).
↘︎ 데이터 처리 단계 간 이벤트 전달.
✅7️⃣ 대표적인 이벤트 브로커 도구.
이벤트 브로커
주요 특징
Apache Kafka
대량의 데이터 스트림, 높은 처리량
AWS EventBridge
AWS 서비스 간 이벤트 통합
Google Cloud Pub/Sub
실시간 메시징 및 데이터 스트림
Azure Event Hubs
대용량 데이터 수집 및 분석
RabbitMQ
이벤트 및 메시지 큐 지원
✅8️⃣ 이벤트 브로커를 사용할 때의 고려사항.
1. 처리량(Throughput):
↘︎ 얼마나 많은 이벤트를 동시에 처리할 수 있는가?
2. 지연 시간(Latency):
↘︎ 이벤트가 얼마나 빠르게 전달되는가?
3. 신뢰성(Reliability):
↘︎ 이벤트가 손실되지 않는가?
4. 확장성(Scalability):
↘︎ 증가하는 이벤트 수를 처리할 수 있는가?
5. 보안(Security):
↘︎ 이벤트 데이터는 안전하게 보호되는가?
✅9️⃣ 이벤트 브로커 도입의 이점.
1. 시스템 간 느슨한 결합.
2. 확장성 및 유연성.
3. 고가용성(High Availability)
4. 비동기 이벤트 처리
5, 실시간 데이터 분석 및 처리
🚀 결론
이벤트 브로커(Event Broker)는 시스템 간 이벤트를 안전하게 전달하고 라우팅하는 중앙 허브 역할을 함.
Apache Kafka, AWS EventBridge, Google Cloud Pub/Sub 등이 대표적인 이벤트 브로커.
이벤트 브로커를 도입함으로써 확장성, 유연성, 신뢰성을 확보할 수 있음.
🔑 핵심 요약
이벤트 브로커란? : 이벤트 중심 통신을 중재하는 시스템.
주요 특징 : 비동기 처리, 확장성, 신뢰성.
사용 사례 : 실시간 데이터 처리, 마이크로 서비스 통신.
Architecture
· 2024-12-30
-
🏗️[Architecture] Scale-Up(수직 확장)이란 무엇일까?
🏗️[Architecture] Scale-Up(수직 확장)이란 무엇일까?
📌 Intro
↘︎ Scale-Up(수직 확장)은 기존의 서버나 시스템의 하드웨어 성능을 향상시켜 더 많은 트래픽이나 데이터를 처리할 수 있도록 하는 방법입니다.
1️⃣ Scale-Up의 개념.
↘︎ 기존 서버의 CPU, 메모리, 디스크 용량, 네트워크 대역폭 등을 업그레이드하여 성능을 개선합니다.
↘︎ 새로운 서버나 시스템을 추가로 도입하는 것이 아니라 기존 단일 시스템을 더 강력하게 만드는 방법입니다.
2️⃣ Scale-Up의 특징.
🎯 장점:
1️⃣ 간단한 구현 : 기존 인프라를 그대로 유지하면서 하드웨어 업그레이드만 진행.
2️⃣ 호환성 : 애플리케이션 코드나 데이터베이스 구조를 변경할 필요 없음.
3️⃣ 관리 용이성 : 하나의 서버만 관리하면 되므로 관리가 비교적 간단.
🎯 단점:
1️⃣ 비용 문제 : 고성능 하드웨어는 비용이 매우 높을 수 있음.
2️⃣ 확장 한계 : 하드웨어의 물리적, 기술적 한계가 존재.
3️⃣ 단일 실패 지점 (Single Point of Failure) : 서버에 장애가 발생하면 전체 시스템이 중단될 수 있음.
3️⃣ Scale-Up 예시.
1️⃣ 서버 업그레이드.
CPU를 더 빠른 것으로 교체
메모리(RAM) 용량 확장
SSD 스토리지로 교체
2️⃣ 데이터베이스 확장.
MySQL, Redis 등에서 더 많은 메모리와 CPU를 할당.
3️⃣ 클라우드 인스턴스 업그레이드.
AWS EC2에서 t2.micro ➞ m5.large로 변경.
더 높은 사양의 인스턴스 선택.
4️⃣ Scale-Up이 적합한 경우.
1️⃣ 데이터 일관성이 중요한 경우 : 하나의 데이터베이스 서버에서 모든 작업을 처리해야 할 때.
2️⃣ 애플리케이션이 단일 서버에서 효율적으로 실행될 때 : 특정 워크로드가 수평 확장(Scale-Out)에 적합하지 않을 때.
↘︎ 🙋♂️ 워크로드(Workload) : 컴퓨터 시스템, 애플리케이션, 서버, 네트워크, 또는 클라우드 인프라가 처리해야 할 작업의 양과 종류를 의미합니다.
↘︎ 쉽게 말해, 시스템이 처리해야 하는 일의 부담으로 이해할 수 있습니다.
↘︎ 📌 “특정 워크로드가 수평 확장(Scale-Out)에 적합하지 않을 때”란?
↘︎ 1️⃣ 작업의 특성상 여러 서버로 나눠서 처리할 수 없는 경우.
↘︎ 2️⃣ 상태 유지, 데이터 일관성, 특정 연산 제약 조건 등이 수평 확장을 어렵게 만드는 경우.
3️⃣ 즉각적인 성능 개선이 필요할 때 : 빠르게 리소스를 추가할 필요가 있을 때.
🚀 결론.
↘︎ Scale-Up은 기존의 시스템에 대한 빠르고 간단한 성능 향상 방법입니다.
↘︎ 하지만 하드웨어의 한계에 도달하거나 단일 장애 지점 (Single Point of Failure) 문제가 발생할 수 있으므로, 필요에 따라 Scale-Out(수평 확장)과 함께 사용해야 합니다.
Architecture
· 2024-12-29
-
-
-
🏗️[Architecture] 멀티테넌트 아키텍처(Multi-Tenant Architecture)란 무엇일까요?
🏗️[Architecture] 멀티테넌트 아키텍처(Multi-Tenant Architecture)란 무엇일까요?
멀티테넌트 아키텍처(Multi-Tenant Architecture)는 하나의 애플리케이션 인스턴스와 데이터베이스가 여러 사용자 그룹(테넌트,Tenant) 간에 공유되면서, 각 테넌트(Tenant)가 독립적으로 동작하도록 설계된 소프트웨어 아키텍처입니다.
이는 클라우트 서비스, SaaS(Software as a Service) 애플리케이션에서 자주 사용됩니다.
1️⃣ 멀티테넌트 아키텍처(Muti-Tenant Architecture)의 핵심 개념.
1️⃣ 테넌트(Tenant)란?
테넌트(Tenant)는 하나의 독립된 사용자 그룹이나 고객을 의미합니다.
예: 특정 회사, 조직 또는 사용자 그룹.
2️⃣ 멀티테넌트의 목적.
여러 테넌트가 동일한 소프트웨어 애플리케이션을 사용하면서도 데이터와 환경이 서로 독립적으로 관리되도록 하는 것 입니다.
2️⃣ 멀티테넌트 아키텍처 종류
1️⃣ 공유형 데이터베이스 및 스키마.
특징
모든 테넌트가 같은 데이터베이스와 테이블을 공유합니다.
장점
리소스 사용이 가장 효율적입니다.
확장이 쉽습니다.
관리가 간단합니다.
단점
데이터 격리와 보안 구현이 복잡합니다.
특정 테넌트의 트래픽 증가가 다른 테넌트의 영향을 줄 수 있습니다.
2️⃣ 예시
CREATE TABLE message (
id INT PRIMARY KEY AUTO_INCREMENT,
tenant_id INT NOT NULL,
sender_id INT NOT NULL,
message TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
테이블에 tenant_id를 추가하여 데이터를 구분합니다.
2️⃣ 분리형 데이터베이스, 공유 스키마.
특징
모든 테넌트가 별도의 데이터베이스를 가지지만, 동일한 테이블 구조(스키마)를 공유합니다.
장점
데이터가 물리적으로 분리되어 보안과 데이터 격리가 용이.
특정 테넌트의 성능 요구에 따라 개별적으로 스케일링 가능.
단점
데이터베이스가 늘어날수록 관리 복잡성이 증가
데이터베이스 연결 비용 증가.
3️⃣ 완전 분리형 데이터베이스 및 스키마.
특징
각 테넌트마다 고유한 데이터베이스와 테이블 구조를 사용합니다.
장점
완벽한 데이터 격리와 보안 제공.
테넌트별로 맞춤형 스키마와 기능 제공 가능.
단점
테넌트 수가 많아지면 확장성이 떨어짐.
관리와 배포가 매우 복잡.
3️⃣ 멀티테넌트 아키텍처의 장단점.
1️⃣ 장점.
1. 비용 효율성
여러 테넌트가 동일한 인프라를 공유하므로 리소스 활용도가 높음.
2. 운영 효율성
한 번의 배포로 모든 테넌트에 업데이트 가능.
3. 확장성
테넌트 수가 증가해도 서버를 추가하여 확장 가능(수평 확장).
2️⃣ 단점.
1. 복잡한 데이터 격리
테넌트별 데이터를 분리하기 위한 추가적인 보안 및 로직 필요.
2. 리소스 공유 문제
특정 테넌트의 리소스 사용량이 많을 경우 다른 테넌트의 영향을 줄 수 있음.
3. 맞춤화 제한
개별 테넌트별로 맞춤 기능을 제공하기 어렵거나 구현이 복잡.
4️⃣ 멀티테넌트 구현 방법.
1️⃣ 데이터베이스 설계.
공유형 데이터베이스 예시
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
tenant_id INT NOT NULL,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
password VARCHAR(255) NOT NULL
)
tenant_id를 기반으로 데이터 필터링.
분리형 데이터베이스 예시
1. 테넌트 식별을 위한 Interceptor
요청마타 테넌트를 식별하여 적절한 데이터베이스로 연결합니다.
```java
@Component
public class TenantInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String tenantId = request.getHeader(“X-Tenant-ID”);
if (tenantId == null) {
throw new RuntimeException(“Tenant ID is not provided”);
}
TenantContext.setCurrentTenant(tenantId);
return true
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handeler, Exception ex) throws Exception {
TenantContext.clear();
}
}
```
2. 테넌트 컨텍스트 저장소
현재 요청의 테넌트를 저장하고 관리합니다.
```java
public class TenantContext {
private static final ThreadLocal CURRENT_TENANT = new ThreadLocal<>();
public static void setCurrentTenant(String tenant) {
CURRENT_TENANT.set(tenant);
}
public static String getCurrentTenant() {
return CURRENT_TENANT.get();
}
public static void clear() {
CURRENT_TENANT.remove();
}
}
```
3. 동적 데이터 소스 구성
테넌트별 데이터베이스를 동적으로 선택합니다.
```java
@Configuration
public class DataSourceConfig {
@Bean
public DataSource dataSource() {
return new AbstractRoutingDataSource() {
@Override
protected Object determineCurrentLookupKey() {
return TenantContext.getCurrentTenant();
}
};
}
@Bean
public DataSourceInitializer dataSourceInitializer(DataSource dataSource) {
DataSourceInitializer initializer = new DataSourceInitializer();
initializer.setDataSource(dataSource);
return initializer;
}
@Bean
public Map<Object, Object> tenantDataSources() {
Map<Object, Object> dataSources = new HashMap<>();
// 데이터베이스 A
DataSource tenantADataSource = DataSourceBuilder.create()
.url("jdbc:mysql://localhost:3306/tenant_a_db")
.username("root")
.password("password")
.driverClassName("com.mysql.cj.jdbc.Driver")
.build();
dataSources.put("tenant_a", tenantADataSource);
// 데이터베이스 B
DataSource tenantBDataSource = DataSourceBuilder.create()
.url("jdbc:mysql://localhost:3306/tenant_b_db")
.username("root")
.password("password")
.driverClassName("com.mysql.cj.jdbc.Driver")
.build();
dataSources.put("tenant_b", tenantBDataSource);
return dataSources; } } ```
4. 요청 처리 흐름
클라이언트가 요청을 보낼 때 X-Tenant-ID 헤더를 추가합니다.
GET /api/resource HTTP/1.1
Host: example.com
X-Tenant-ID: tenant_a
TenantInterceptor가 X-Tenant-ID를 읽어 TenantContext에 저장합니다.
AbstractRoutingDataSource가 TenantContext에서 테넌트 정보를 읽어 해당 테넌트의 데이터베이스를 사용합니다.
데이터베이스 구조
Tenant A: tenant_a_db
Table
Columns
users
id, name, email
orders
id, user_id, order_data, total
products
id, name, price, stock_quantity
Tenant B: tenant_b_db
Table
Columns
users
id, name, email
orders
id, user_id, order_data, total
products
id, name, price, stock_quantity
장점.
데이터가 물리적으로 분리되어 보안이 강력
테넌트 간 데이터 간섭 가능성이 없음
개별 테넌트별로 데이터베이스 성능을 독립적으로 관리 가능
단점.
데이터베이스가 많아질수록 관리 복잡성이 증가.
스키마 변경시 모든 데이터베이스에 동일한 작업을 반복해야 함.
2️⃣ Spring Boot 구현
엔티티
@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private Long tenantId;
private String name;
private String email;
private String password;
// Getters and setters
}
Repository
public interface UserRepository extends JpaRepository<User, Long> {
List<User> findByTenantId(Long tenantId);
}
Sevice
@Service
public class UserService {
@Autowired
private UserRepository userRepository;
public List<User> getUsersByTenantId(Long tenantId) {
return userRepository.findByTenantId(tenantId);
}
}
컨트롤러
@RestController
@RequestMapping("/api/users")
public class UserController {
@Autowired
private UserService userService;
@GetMapping
public List<User> getUsers(@RequestParam Long tenantId) {
return userService.getUsersByTenantId(tenantId);
}
}
5️⃣ 멀티테넌트와 SaaS
SaaS(Software as a Service) 애플리케이션은 멀티테넌트를 사용하는 대표적인 사례입니다.
예: Slack, Salesforce, Google Workspace 등
각 조직이 고유한 데이터를 가지지만, 동일한 애플리케이션 인스턴스를 사용.
6️⃣ 멀티테넌트 설계 시 고려 사항.
1. 보안
테넌트 간 데이터 접근 방지.
인증 토근에 tenant_id 포함.
2. 성능
특정 테넌트의 과도한 리소스 사용이 다른 테넌트에 영향을 주지 않도록 제한 설정.
3. 스케일링
테넌트 수가 증가할 때 서버, 데이터베이스의 수평적 확장이 가능해야 함.
7️⃣ 결론.
멀티테넌트 아키텍처는 하나의 시스템으로 여러 사용자 그룹을 지원하면서, 데이터와 환경을 독립적으로 관리할 수 있는 효율적인 방식입니다.
구현 방식은 서비스의 요구사항과 테넌트 수에 따라 결정되며, 설계 단계에서 데이터 격리와 확장성을 철저히 고려해야 합니다.
Architecture
· 2024-12-11
Touch background to close
devkobe24.com
