개발자취

Pub / Sub 패턴 메시징 모델 중의 하나로 발생(publish)과 구독(Subscribe) 로 개념화한 형태 발행자와 구독자는 서로에 대한 정보 없이 특정 주제(토픽 or 채널)를 매개로 송수신 graph LR subgraph Messaging Middleware Topic end Publisher --메시지 발행--> Topic --메시지 구독--> Subscriber 메시지 미들웨어 사용의 장점 비동기: 통신의 비동기 처리 낮은 결합도: 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존 탄력성: 구성원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화 됨 메지싱 미들웨어 제품들: kafka, RabbitMQ, ActiveMQ 등등 Redis Pub/Sub 특징 메시지가 큐..

캐시 적중(Cache Hit): 캐시에 접근해 데이터를 발견 캐시 미스(Cache Miss): 캐시에 접근했으나 데이터를 발견하지 못함 캐시 삭제 정책(Eviction Policy): 캐시의 데이터 공간 확보를 위해 저장된 데이터를 삭제 캐시 전략: 환경에 따라 적합한 캐시 운영 방식을 선택할 수 있음 캐시 전략 Cache-Aside(Lazy Loading) 항상 캐시를 먼저 체크하고, 없으면 원본(ex: DB)에서 읽어온 후에 캐시에 저장 장점: 필요한 데이터만 캐시에 저장되고, Cache Miss가 있어도 치명적이지 않음 단점: 최초 접근이 느림. 업데이트 주기가 일정하지 않기 때문에 캐시가 최신 데이터가 아닐 수 있음. graph LR Application --1. 읽기 시도--> Cache App..

두 WAS를 띄었을때 JSESSIONID의 값이 다를것인데 graph LR 브라우저 --> 로드발란서 --> 서버1 로드발란서 --> 서버2 @GetMapping("/login") public String login(HttpSession session){ return session.getId(); }세션 아이디를 리턴하게 코드를 짜고 포트 8080과 8081로 따로 WAS를 띄워봤다. 다른 세션ID를 가지고 있다. 세션공유가 안되고있다. Redis사용하기 이런 분산환경에서 redis를 사용한다면? graph LR 브라우저 --> 로드발란서 --> 서버1 --> Redis 로드발란서 --> 서버2 --> Redis 아니 근데 RDB를 사용안하는 이유는? 과연 관계형 데이터 모델이 필요할까? 영속성이 필요한..

목적 : read를 Write 도 하는 Primary한테 부하가집중되는 걸 Secondary로 분산시키는게 주된 목적임. 4.4버전에서 새로생긴 옵션 - 해치드 리드: 각각 샤드에 두번의 요청을 동시에 보내고 둘중 먼저오는 요청을 기준으로 반환을함으로 더 빨리 처리 가능함. 종류: Primary : 무조껀 Primary로 읽기 요청 PrimaryPreferred: 가능하면 Primary에서 읽고 없으면 Secondary로 요청 Secondary: 무조껀 Secondary로 읽기 요청 SecondaryPreferred: 가능하면 Secondary에서 읽고 없으면 Primary로 요청 Nearest: 평균 Ping 시간을 기반으로 지연율이 가장 낮은 멤버로 요청 Secondary 문제점 : 복제가 완료되지않..

기본적으로 적게 검증하고 자주 쓰기 방식의 일관성 모델을 사용하므로 업데이트시 제이터가 즉시 쓰여지지는 않지만 최종적으로는 정확한 결과를 보장한다. Single Document Transaction Replica Set Member Shared Cluster Shard Single Document 원자성 보장 다양한 데이터 타입을 하나의 데이터 객체에 담긴다. Single Document의 크기는 16MB를 초과하지 않느다. Transaction 권장하진 않지만 기능적으로는 존재함 Replica Set Member 동일한 데이터를 여러 맴버에 저장 HA구성 Shared Cluster Shard 데이터 분산이 되어 샤드같에 동일한 데이터를 갖지 않도록 제어

Strings 가장 기본적인 데이터 타입 바이트 배열을 저장 바이너리로 변관할 수 있는 모든 데이터를 저장 가능 최대크기 = 512MB 명령어 기능 예제 SET 특정 키에 문자열 값을 저장 SET say hello GET 특정 키에 문자열 값을 부름 GET say INCR 특정 키에 값을 Integer로 취급하며 1증가 INCR mycount DECR 특정 키에 값을 Integer로 취급하며 1증가 DECR mycount MSET 여러 키에 대한 값을 한번에 저장 MSET key1 value1 key2 value2 MGET 여러 키에 대한 값을 한번에 부름 MGET key1 key2 Lists Linked-list 형태의 자료구조 Queue와 Stack으로 사용할수있음 명령어 기능 예제 LPUSH 리스트..

Redis 사용하는 이유 손쉽게 사용할수있는 In-memory 저장소 높은 성능 다양한 활용성 세션 관리나 캐시 정의 Storage: 데이터 저장소 (데이터 관점) DataBase: 전통적인 DBMS의 역할을 수행한다. NoSQL Middleware: 어플리케이션이 이용할 수 있는 유용한 기능을 제공하는 소프트웨어 장점 아주 빠른 저장소로 활용 분산된 서버들간의 커뮤니케이션 내장된 자료구조를 활용한 기능 구현 In-Memory DB 란 ? 일반적으로 DB는 디스크에 저장하는데 레디스는 메모리(RAM)에 저장한다. 따라서 아주 빠르다. 대신 비싸다. 메모리는 휘발성인데? 지워져서 안되는 중요데이터가 아닌 지워져도 큰 문제가 없는 로그인 세션데이터나 캐시같은 용도로 사용된다. 데이터 저장 구조 DB관점에서의..

Aggregation이란? Collection 데이터를 변환하거나 분석하기 위해 사용하는 집계 프레임워크 Aggregation은 Find함수로 처리할 수 없는, SQL의 Group By 와 Join 구문 같은 복잡한 데이터 분석 기능들을 제공한다. Aggregation 프레임워크는 Pipeline형태를 갖춘다. (Linux Pipeline 구문과 동일한 방식) MongoDB 2.2 부터 제공되었고 이전에는 Map Reduce를 사용했다. SELECT productName ,SUM(quantity) AS sumQuantity FROM orders WHERE status = 'urgent' GROUP BY productName; db.orders.aggregate([ {$match: {stat..

모든 Shard는 Replica Set으로 구성 되어있다. 따라서 HA보장 Sharding 하나의 큰 데이터를 여러 장비에 걸처서 분할하는 과정 따라서 Sharding의 목적은 HA가 아니고 분산처리임. 분산의 기준 : 샤드 키 장점 단점 ∙ 용량의 한계를 극복할수 있다 ∙ 데이터 규모와 부하가 크더라도 처리량이 좋다. ∙ 고가용성을 보장한다. ∙ 하드웨어에 대한 제약을 해결할 수 있다. ∙ 관리다 비교적 복잡하다 ∙ Replica Set과 비교해서 쿼리가 느리다. 분산처리를 하기때문에 용량을 계속 늘릴수있다. 스케일 업으로 처리못하는 부분을 스케일 아웃으로 처리가 가능하기 때문 각 Shard가 나눠져 있기때문에 요청이 들어왔을때 라우팅해줘야 하는 과정이 있고 범위 검색시 여러 샤드에 걸쳐서 데이터를 수..

Replica Set사용 목적이 고가용성(HA)이기 때문에 각각 다른 서버에 설치되어있어야 목적에 맞게 사용한다고 볼 수 있다. Fail-Over Replica Set에서 Primary가 죽으면 write는 누가 해주나? 서로 Hartbeat를 주고받으며 서로 사라 있는지 확인하고 있다가 죽은 게 확인되면 내부적인 기준에 의해 투표를 진행해서 Primary로 정해진다. 따라서 Replica Set 멤버의 구성을 최소 3 이상, 홀수로 정하는 걸 추천한다. Oplog Oplog를 이용해서 Replica Set내의 데이터를 동일하게 유지하게 함. 1. 쓰기 요청이 Primary로 들어온다. 2. 적용 후 Oplog에 변경사항을 기록한다. 3. 각 Secondary는 비동기적으로 Oplog의 값을 복사해 온..