서론
오늘은 회의시간에서 많은걸 배운것 같다.
현재 우리 회사는 서비스 범위 확장으로 보다 만은 데이터들을 저장하고 관리해줘야 하는 과제가 주어졌다.
그래서 대규모 데이터를 효율적으로 사용하고 확장에 용이하게 변경하기 위하여 데이터 분산 방법인 샤딩을 도입할 예정이다.
그리고 현재 MySql과 Postgres를 동시에 사용중인데 공간정보데이터를 사용하는 Postgres를 더 자주 사용하게 될것이라 생각이들어서
기존 MySql을 사용중이던 DB들을 Postgres로 전환하고 Postgres만 사용하기로 결정했다.(개발 용이성과 Postgres에서 지원하는 Postgis 등의 기술들을 활용하기 위함)
또한 우리는 데이터를 자동으로 수집 및 전송하는 여러 q를 개발했고 앞으로도 추가 될것이기 때문에 기존 django Q로 설정해서 순차적으로 실행시키는 방법에서 SNS, SQS, MQ, MQTT, Celery 등의 구조를 사용하기로 결정했다.
그렇다 본인은 프론트엔드 개발자라 위 용어들이 매우 생소하고 어려웠다. 그래도 팀장님이 친절하게 설명해주셨고..... 모자란 부분을 채우기 위해 오늘의 성장일기를 위내용으로 선정했다. 너무 깊게는 못 팔것 같고 기술들의 간단한 내용정리를 남기고자 한다.
본론
Sharding(샤딩)
샤딩은 데이터베이스 아키텍처의 한 방식으로, 대규모 데이터베이스의 데이터를 수평으로 분할하여 다른 데이터베이스 서버에 분산 저장하는 기술이다.
데이터를 효율적으로 관리하고 읽기 및 쓰기 요청의 부하를 분산시켜 시스템의 성능과 확장성을 향상 시키는 데 목적이 있다.
### 샤딩의 장점
- 확장성(Scalability): 샤딩을 통해 데이터베이스 시스템의 수평 확장이 용이해진다. 데이터가 증가함에 따라 추가 샤드를 구성하여 처리능력을 쉽게 향상 할 수 있다.(여기서 샤드란 각 서버에 저장되는 데이터 분할을 뜻한다.)
2.성능(Perfomance): 데이터가 여러 서버에 분산되어 있기 때문에 병렬로 데이터를 처리 할 수 있으며, 이는 전체 시스템의 처리량과 응답 속도를 향상시킨다.
3.고가용성(High Availability): 샤딩은 데이터를 여러 서버에 분산시키므로, 하나의 서버에 장애가 발생해도 시스템 전체의 가용성에 미치는 영향을 최소화할 수 있습니다.
샤딩의 단점
복잡성(Complexity): 데이터를 여러 샤드에 분산시키기 때문에, 데이터 관리가 복잡해지고 , 샤드 간 데이터 일관성 유지가 어려울 수 있다.
조인(Join)의 어려움 : 서로 다른 샤드에 저장된 데이터를 조인하는 것이 기술적으로 어렵거나 성능에 부정적인 영향을 줄 수 있다.
- 주관적인 생각: 확실히 장단점이 있지만 우리는 비즈니스를 지역 -> 전국으로 확장하기에 비교적 지역별로 데이터를 관리하면 되서 단점을 줄일 수 있을것 같고 몇백만건의 데이터 덩어리들을 처리하기 위해서는 확장성과 성능 측면에서 확실히 샤딩 도입이 필요하다고 생각이 들었다.
여기서 추가로 소소한 지식들을 배울 수 있었는데 우리는 샤딩을 클러스터 하나와 쓰기1개 읽기 2개의 총 3개의 서버를 마스터 - 슬레이브 구조로 개발할 예정이다.
여기서 쓰기가 1개인 이유는 우리는 여러 데이터 수집 코드를 사용하여 데이터를 수집하는데 쓰기전용 서버가 여러개다보면 동시에 데이터를 저장하게 된다거나 불가피한 이유로 저장할때 충돌이 발생할 수 있는 확률도 높아지기 때문에 보통 쓰기전용은 1개로 구성을 하였다.
읽기는 데이터를 처리할때 아무래도 쓰기 보다 읽기가 더 빈번하게 일어날 확률이 높기 때문에 2개로 구성을 하기로 결정했다.
AWS 기능들
SNS (Amazon Simple Notification Service)
Amazon SNS는 고도로 확장 가능한, 완전 관리형 메시징 서비스로, 애플리케이션 간 또는 애플리케이션에서 사용자에게 분산된 메시지를 보낼 수 있도록 설계되었습니다. SNS는 푸시 알림, SMS 및 이메일을 포함하여 다양한 메시징 채널을 지원합니다. SNS의 주요 특징 중 하나는 팬아웃 메시징 패턴을 통해 수많은 구독자에게 동시에 메시지를 전송할 수 있다는 점입니다.
SQS (Amazon Simple Queue Service)
Amazon SQS는 분산 애플리케이션 간의 메시지를 교환하기 위한 완전 관리형 메시지 큐잉 서비스입니다. SQS를 사용하면 컴포넌트가 서로 연결되지 않고 비동기적으로 통신할 수 있으므로, 애플리케이션의 분리와 확장성을 향상시킬 수 있습니다. SQS는 두 가지 유형의 메시지 큐를 제공합니다: 표준 큐(최대 처리량에 최적화)와 FIFO 큐(순서가 보장되고 메시지가 한 번만 전달됨).
MQ (Amazon MQ)
Amazon MQ는 액티브MQ와 래빗MQ와 같은 인기 있는 오픈 소스 메시지 브로커를 관리형 서비스로 제공합니다. 이 서비스는 기존 애플리케이션의 마이그레이션을 용이하게 하고, 메시지 브로커의 설치, 운영, 유지 관리의 복잡성을 줄여줍니다. Amazon MQ는 표준 JMS, NMS, AMQP, STOMP, MQTT, WebSocket 프로토콜을 지원하여 다양한 메시징 패턴과 애플리케이션과의 통합을 지원합니다.
MQTT (Message Queuing Telemetry Transport)
MQTT는 경량의 메시지 프로토콜로, 네트워크 대역폭이 제한적이거나 네트워크 연결이 불안정한 환경에서 IoT 기기와 같은 저전력 장치 간의 메시지를 교환하기 위해 설계되었습니다. MQTT는 게시/구독(pub/sub) 모델을 기반으로 하며, 매우 작은 코드 풋프린트를 요구하므로 임베디드 시스템에 적합합니다.
Celery
Celery는 Python 작성된 분산 태스크 큐입니다. 비동기적 작업 실행, 실시간 처리 및 스케줄링을 위해 사용되며, 주로 웹 애플리케이션에서 백그라운드 작업을 처리하는 데 사용됩니다. Celery는 브로커(예: RabbitMQ, Redis)를 사용하여 메시지를 전송하며, 다양한 백엔드(예: SQLAlchemy, Django ORM)와의 통합을 지원하여 작업 결과를 저장하고 조회할 수 있습니다.
-> 우리는 기존 Django Q를 비동기적으로 자동화 하기 위해 Celery를 사용하고 MQTT의 Pub/Sub 모델을 사용하여며 SNS와 SQS를 통해 특정 상황에서 메시지를 분산적으로 보내고 메시지 받는것을 구독(감지)하여 태스크 큐를 MQ에 저장하고 큐를 처리한다.