Develog Develog

개요 사내에서 신규 서비스를 준비하게 되면서 MongoDB 를 도입하기로 했다. 합리적이라 판단이 들었고 Azure 의 Cosmos DB 를 통해 구현할 예정이다. 하지만, 항상 기술 선택에 있어 정말 이 기술이 우리의 비즈니스 요구사항과 맞는 것인가도 있지만 고가용성과 일관성은 어떻게 보장이 되어야 하는것인가에 대해서 고민은 필수적이라 생각한다. 그래서 이번 포스팅에는 MongoDB의 일관성과 관련한 공부해본 내용을 적어보려한다. MongoDB 일관성 관련 계층 Single Document : 원자성 보장 및 Replica 로 Eventual Consitence 보장 Transaction : 여러 작업에 대한 원자성 보장 단, 추천하지 않는 기능 Replica Set Member Replica Set ..

개요 Redis 는 Channel 을 이용해서 Pub/Sub 시스템 기능을 제공한다. 간단히 설명하면, Pub Client 에서 Channel 에 데이터를 푸시하면 Sub Client 에서는 해당 데이터를 수신하는 구조이다. 내부 구조 Internals(데이터 구조 Data Structures) Redis Pub/Sub 시스템은 레디스 서버와 클라이언트에 채널과 패턴을 등록한다. 채널은 dict(Hash table)에 저장되고 패턴은 Linked List에 저장된다. server.pubsub_channels dict 및 dictEntry 는 Redis 에서 사용하는 해시 테이블이다. dictEntry의 key 필드 : channel 을 가리킨다. dictEntry의 value 필드 : 리스트(linked..

Redis Pipelining Redis 명령을 일괄 처리하여 요청/응답 시간을 최적화하는 방법 Redis pipelining 은 각 개별 명령에 대한 응답을 기다리지 않고 한 번에 여러 명령을 실행하여 성능을 향상시키는 기술이다. Redis pipelining 은 대부분의 Redis 클라이언트에서 지원된다. 요청/응답 프로토콜 및 왕복 시간(RTT) Redis는 RESP(TCP 프로토콜)을 이용한다. 따라서 요청/응답 모델을 사용하며, 아래는 Redis 에서 요청/응답 하는 과정이다. 클라이언트에서 서버로 쿼리를 보낸다. 일반적으로, 서버는 Blocking 방식의 소켓을 통해 읽는다. 서버가 명령을 처리하고 응답을 다시 클라이언트로 보낸다. 이때, 서버에 요청(패킷)을 보내고, 다시 응답이 오기까지의 ..

Redis Client Side Cache 레디스 서버는 고성능이지만, 데이터가 필요할 때마다 매번 쿼리를 해서 가져와야 한다. 클라이언트 입장에서 보면 한번 가져온 데이터를 계속 사용할 수 있다면 훨씬 나은 성능이 나온다. 이때, Client Side Cache 의 고질적인 문제를 각 역할군 관점으로 보면 아래와 같이 나온다. Push : 데이터가 변경 되었음을 Client Side Cache 를 사용하는 클라이언트에게 어떻게 전달할까 Pull : 데이터 변경분을 서버에게 어떤 주기(트리거)로 어떻게 가져올 것인가? 서버의 경우 데이터가 변경되었을 때 클라이언트는 해당 데이터가 변경되었는지를 어떻게 아느냐 이다. 즉, 서버에서 변경된 데이터(CDC)에 대한 내용을 클라이언트에게 알림 줄 수 있어야 한다..

NoSQL 개요 2008년 아이폰 등장을 기점으로 실시간으로 다루어야 할 데이터가 폭발적으로 증가하기 시작했다. 이는 ‘데이터양의 증가’를 의미하게 되었고, 가변적인 데이터 처리를 요구하는 상황도 자주 발생했다. 즉, 데이터 처리를 하는 서버 애플리케이션 개수를 동작 중에 늘리거나 줄이고 논리적으로 하나의 저장소이면서 언제든지 수평 확장 할 수 있는 새로운 패러다임이 필요해졌다. (강력한 High Availability와 Horizontal Scalability를 지원하는 Database 요구) 데이터 처리 요구 사항도 유기적으로 바뀌고 성능은 그대로 유지해야 한다는 점에서 관계형 데이터베이스의 Schema는 현대의 요구사항을 충족시켜 주기에는 부족한 점이 많았다. (스키마 변경에 있어서 강한 제약 + ..