좋은 기회로 배달의 민족 우아콘의 입장권을 양도받았다. 백엔드로 가서 들을 예정인데 모르는 내용이 많아 사전공부를 하고 가려고 한다.
1.배달의 민족 API GateWay
- API 게이트웨이는 백엔드 서비스에 대한 API 트래픽을 수락, 변환, 라우팅 관리하는 중개자역할을 하는 서비스이다. 즉 클라이언트 요청을 각 마이크로 서비스에 라우팅하고 요청을 관리한다고 생각하면 된다.
주요 역할과 기능
- 인증 및 보안
- 로깅 및 모니터링 : 모든 api 요청과 응답을 거치므로 응답시간, 상태코드 등 결과와 속도를 직접 확인할 수 있다. 또한 성능 모니터링 데이터를 기반으로 로드 밸런싱 전략을 최적화 하거나 리소스를 추가 배치하는 등 대응 조치를 할 수 있다.
- 캐싱
- 요청 변환 : 클라이언트의 요청을 필요한 형식으로 변환하여 조정할 수 있다.
- 서비스 통합 및 API 통합
단점
- 단일 장애점 : API Gateway에 장애가 생기면 전체 서비스에 영향을 받는다.
- 각각의 요청이 경유해야 하므로 응답시간에 지연이 생길 수도 있다.
대표적인 API GateWay
- netflix zuul
- spring cloud Gateway
- amazon API Gateway
- NGINX
2. Kafka를 이용하는 메시지 플랫폼에서 장애를 겪으며 아케텍처 개선
- 카프카는 실시간 데이터 스트리밍을 처리하기 위해 설계된 분산형 메시징 플랫폼이다. 현재 apache 에서 오픈소스로 관리하고 있으며, 대용량의 실시간 데이터를 효율적으로 수집, 처리, 저장, 전달하는데 적합하다.
주요 특징
- 실시간 데이터 스트리밍
- 확장성 : 파티션을 통해 데이터를 병렬로 처리할 수 있으므로, 데이터가 증가해도 클러스터를 확장해 안전하게 보호 가능
이번 사이드 프로젝트에서 채팅을 맡았으므로 채팅 예제로 설명하겠다.
토픽
메시지 스트림의 논리적 그룹이며 이를 여러 파티션으로 나눠 저장해 하나의 토픽이 병렬 처리되도록한다.
즉 1개의 채팅방이 1개의 토픽이라 생각하면 된다.
파티션
파티션은 토픽안에서 여러 파티션으로 나눠 저장한다고 생각하면 된다. 예를 들어 벨로그 채팅방이 있다면 A사용자는 A파티션을 B사용자는 B파티션, C사용자는 C 파티션을 사용해서 각각의 데이터를 저장하는 병렬처리 방식이다.
또한 각 파티션 안에는 오프셋이라는 고유번호가 있어서 메시지는 순서대로 저장된다.
클러스터
클러스터는 여러 카프카 브로커로 구성된 서버그룹이다. 데이터를 분산저장하고, 장애발생시에도 데이터의 가용성을 유지하며, 높은 처리량을 확보한다.
- 브로커 : 클러스터의 각 서버 인스턴스를 의미하고, 데이터 저장, 및 전달을 담당한다.
- 고가용성 : 클러스터 내에 여러 브로커가 있으므로 한 브로커에 장애가 발생해도 다른 브로커가 해당 데이터를 복제하여 안정성을 유지한다 > 리플리케이션
즉 5개의 브로커가 있는 클러스터에 토픽 1개가 생성되고 이 토픽에는 3개의 파티션이 있다고 생각하면 3개의 파티션은 5개의 브로커에게 분산 저장된다!
카프카의 동작 방식
- 카프카는 Pub/Sub 모델의 메시지 큐 형태로 동작하는데 Pub/Sub 모델은 비동기 메시지 전송 방식 중 하나이다. 메시지를 보낼 때 발신자와 수신자에게 직접 연결하는 것이 발행자가 메시지를 특정 주제(토픽)에 게시하고, 구독자는 원하는 주제에 대한 메시지만 수신할 수 있도록 하는 것이다. 그래서 확장성이 매우 뛰어나다는데 이유가 뭘까?
Publisher(발행자)
메시지를 생성해서 특정 토픽에 게시하는 역할이다. 예를 들어 백엔드라는 주제에 게시하는 역할을 한다.
Subscriber(구독자)
원하는 주제를 구독해서 해당 주제의 메시지만 수신한다.
Topic(토픽)
발행자와 구독자 간의 연결고리 역할을 하며, 각 메시지는 특정 주제에 게시된다. 그래서 발행자와 구독자는 서로의 존재를 몰라도 주고받을 수 메시지를 주고받을 수 있다.
이벤트 브로커
이벤트 브로커는 이벤트를 저장하고 관리하는 역할이다. 메시지를 즉시 삭제하지 않고 오랜기간 저장할 수 있다.
그래서 사용자는 장애로 인해 이벤트를 놓쳐도 필요한 시점부터 다시 읽고 처리가 가능하다.
반대로 메시지 브로커는 메시지를 큐에 넣어 소비자가 읽으면 즉시 삭제된다.
| 특징 | 메시지 브로커 | 이벤트 브로커 |
|---|---|---|
| 데이터 저장 | 메시지를 즉시 큐에서 삭제 | 메시지를 디스크에 저장하여 보관 |
| 재처리 지원 | 메시지 재처리 어려움 | 특정 시점부터 메시지를 다시 소비 가능 |
| 대용량 처리 | 제한적, 실시간 전송에 적합 | 대용량 데이터 처리와 저장에 적합 |
| 사용 예시 | RabbitMQ, Redis | Kafka, AWS Kinesis |
3. WMS 재고 이전을 위한 분산 락 사용기
가장 궁금한 부분인데, 분산락은 여러 시스템에서 동시에 접근하는 리소스를 보호하고, 데이터 일관성을 유지하기 위해 사용된다. 동시에 여러 프로세스에서 수행될 때 발생할 수 있는 데이터 충돌과 동시성 문제를 방지할 수 있다.
WMS(Warehouse Management System)
창고관리 시스템으로, 재고, 입출고, 위치관리 , 작업계획 등 창고 운영을 효율적으로 관리하는 시스템이다.
주요기능
- 재고관리
- 입출고관리
- 상품 위치관리
- 작업 최적화
- 출고 계획 및 배송 관리
- 분석 및 보고서
내가 가장 궁금한건 동시성이다. 예를 들어서 사용자 2명이 한개의 상품을 동시에 결제한다면 ?
예를 들어서 1개의 재고만 있는 상품을 두명이 결제를 성공해버리는 상황은 어떻게 막아야할까
-
행 레벨 락 : 특정 상품의 재고를 업데이트 할 때 해당 행을 잠그는 방식이다. 예를 들어 결제 과정에서 재고 수량을 업데이트 할 때 데이터 베이스가 해당 행에 락을 걸어 다른 트랜잭션이 접근하지 못하도록 하는 방법이다.
-
낙관적 락 : 재고를 업데이트할 때 현재 버전 번호를 확인한 후, 업데이트 시 버전 번호가 동일하면 성공하고, 다르면 실패하게 한다. 예를 들어, A와 B가 동시에 재고가 1인 상품에 접근했을 때, A가 먼저 재고를 0으로 업데이트하며 버전 번호를 올린다. B가 이후에 같은 상품에 접근해 업데이트를 시도하지만, 버전 번호가 달라졌기 때문에 업데이트가 실패한다.
분산 락 사용
- Redis의 분산락은 특정 키에 락을 걸어 하나의 작업만 특정 리소스에 접근할 수 있게 한다. 예를 들어 A사용자가 결제시도를 하면 ProductA라는 락을 걸고 B 사용자는 락이 해제될 때까지 대기해야한다.
- Apache Zookeeper는 분산 환경에서 락을 구현하는데 노드를 유지하는 동안 다른 프로세스는 접근을 못한다.
마지막으로 0원으로 관리하는 클라우드 비용까지 그동안 궁금했던 내용을 많이 배울 수 있을 것 같다!
