[1주차]_1장_사용자 수에 따른 규모 확장성_Redis

[bik1111]

1차 스터디(8/20) 후 추가적으로 공부하고 싶은 주제 선정

1. 메시지큐 로직 및 디자인 패턴 조사

2. 캐싱 전략 및 실제 기업 적용 사례 탐구

ref: https://zeromq.org/, https://www.rabbitmq.com/, https://aws.amazon.com/ko/builders-library/caching-challenges-and-strategies/

[bik1111]

@ziwooda
@junchanpp
@Lightieey

실제 기업(쿠팡)에서 수많은 도메인들이 얼키설키 엮여져 있는 상황과 엄청난 대규모 트래픽들을 어떠한 시스템 아키텍처를 구성해서 해결하는지 또 해당 아키텍처를 구성하면서 직면했던 문제점과 해결점들에 대한 영상을 보고 정리해봤습니다.

팀원분들도 한 번 보시고 인상깊었던 점, 같이 얘기해보고 싶은 점 공유해주시면 감사하겠습니다.

개인적으로 인상깊었던 점 3가지

1. 수십가지의 도메인이 엉킨 것을 "하나"의 코어 서빙 레이어로 구성

2. Cache Layer를 두고도 RealTime Cache Layer를 별도로 구성한 점. ( 캐시 레이어에서 전체 트래픽의 95% 담당)

3. 다운된 캐시 노드들을 full sync, recovery 하는 과정에서 닥친 문제점과 해결점

https://www.youtube.com/watch?v=qzHjK1-07fI

https://velog.io/@bik1111/Reveal2021-%EC%BF%A0%ED%8C%A1%EC%9D%98-%EB%8C%80%EA%B7%9C%EB%AA%A8-%ED%8A%B8%EB%9E%98%ED%94%BD%EC%9D%84-%EB%8B%A4%EB%A3%A8%EB%8A%94-%EB%B0%B1%EC%95%A4%EB%93%9C-%EC%A0%84%EB%9E%B5-%EC%9A%94%EC%95%BD

[ziwooda]

추가 공부하면서 읽어본 글입니다!

Redis 사용 기업 리스트

• https://www.codenary.co.kr/techstack/detail/redis

About Redis

• https://meetup.nhncloud.com/posts/225

이벤트 기반 아키텍처 (feat. Redis, DynamoDB, Kafka)

• https://techblog.woowahan.com/13101/

[bik1111]

https://brunch.co.kr/@springboot/374

• 레디스도 단순 DB기능 넘어서 카프카,raabitMQ 처럼 메시징큐 역할을 하는 기능이 존재
• 다만, 스터디에서 언급된 pub/sub구조에서 레디스는 topic(주제)를 기준으로 클라이언트에게 메시지를 전송함
• Publish / Subscribe 구조에서 사용되는 Queue를 일반적으로 Topic이라고 함.
• 따라서 특정 "topic"을 구독한 subscriber에게 publisher가 메시지를 전달하는 형식
• 하나의 Client가 메세지를 Publish하면, 이 Topic에 연결되어 있는 다수의 클라이언트가 메세지를 받을 수 있는 구조이다.
• EX) 구독과 좋아요(Subscribe )를 누르면, 나중에 크리에이터가 새로운 글을 발행(Publish)하면 구독자 한테만 알림(notification) 전송
• 따라서 레디스의 pub/sub 기능은 은 주로 채팅 기능이나, 푸시 알림등에 사용
• 유의점은 publisher는 단순히 메시지를 "던지는 것"에 불과한 행위를 하므로 전달한 메시지를 따로 보관하지 않음
• 따라서, subscriber가 해당 메시지를 제대로 수신했는지 확인하지 않음
• 간단하게 정리하면 메시지를 보내는 쪽도 보내고 끝, 받는 쪽도 받고 끝이 되게 심플하게 되어 있음.

https://server.happykoo.net/uploads/202006/blob1591444616237

그러면 굳이 왜쓰는거야?

이유 : 웹소켓을 사용해 통신할 경우 추가적인 네트워크 리소스가 들어가 딜레이가 존재할 수 있지만 레디스는 in-memory기에 매우 빠르게 메시지 전송 가능

따라서 현재 접속 중인 클라이언트에게 짧고 간단한 메시지를 빠르게 보내고 싶을 때, 그리고 전송된 메시지를 따로 저장하거나 수신확인이 필요 없을 때, 마지막으로 100% 전송 보장은 하지 않아도 되는 데이터를 보낼때 이용하면 괜찮다.

[bik1111]

@ziwooda
@junchanpp
@Lightieey

1주차에서 데이터베이스 다중화에서 다뤘었죠?
다중화를 해야하는 이유에 대해선 공유가 이루어졌지만, 막상 다중화에 대한 서버 부하는 없을까?
다중화 자체에만 포커싱이 된 대화 흐름이었는데, 다중화를 수행하면서 얻을 수 있는 단점에 대해서는 언급해 보지 않았던 것 같아요

3조 윤가영님께서 해당 부분 노션에 남겨주셔서 여기에도 공유합니다.

By 윤가영님 
## 궁금해서 더 찾아본 것

- 데이터베이스 다중화는.. 성능이 안느려지나
    
    https://dba.stackexchange.com/questions/37280/does-mysql-replication-hamper-the-performance-of-my-db
    
    > 모든 경우에 **마스터는 슬레이브에서 업데이트를 실제로 실행할 책임이 없**으며, 단지 실행된 실제 입력 쿼리의 복사본(문 기반 모드)이나 각 쿼리가 실제로 삽입/업데이트/삭제한 행의 데이터(행 기반 모드) 중 하나를 슬레이브로 전송할 뿐입니다. 혼합 모드에서는 쿼리 옵티마이저가 이벤트별로 사용할 형식을 결정합니다.
    >

요약

1. 슬레이브를 두는 것 자체로는 주 서버에 대한 부하가 경미함

주 서버가 복제 환경에서 주로 하는 일 2가지

• 로컬 하드 드라이브에 이벤트를 구성하고 이를 이진 로그(binlog)에 기록
• 각 연결된 슬레이브에게 기록한 모든 이벤트의 사본을 전송

-> 위의 이유가 큰 비용이 아닌 이유 : 이진로그를 복제하는 것을 복제의 비용으로 여기지 X -> 복제를 하지 않더라도 항상 이진 로깅을 켜놓아야 하기 때문에 문제 해결 및 복구 도구로서 극히 가치 있는 기능

2. 슬레이브에게 로깅을 전송하는 비용 역시 적음

주 서버는 슬레이브와 TCP 연결을 유지하며, 주 서버는 이벤트가 발생할 때 데이터를 소켓에 복사하기만 하면됨
따라서 그 이후부터는 주 서버는 슬레이브가 해당 이벤트를 실행하는지 여부나 언제 실행하는지에 대해서는 알지도 못하며 신경쓰지 않음.

3. 어떤 경우에도 주 서버는 슬레이브에서 실제로 업데이트를 실행하는 것은 아님 (중요!!)

주 서버는 단지 슬레이브에게 두 가지 중 하나를 전송 : (1) 실제 실행된 쿼리의 사본 또는 (2) 각 쿼리에서 실제로 삽입/업데이트/삭제된 행들의 데이터. --> 여기서 (2)를 수행하는 과정에서도 위에서 언급한 이진로그를 기록하는 주 서버는 모든 이벤트를 매번 새롭게 갱신하는 것이 아니라 "실제로 변경"이 이루어진 것만 선별해서 기록, 데이터 변경 내역을 효율적으로 "압축" 하여 전송, 여러 개의 슬레이브에게 "병렬적" 으로 분산 전달

참고로, 여기서 말하는 다중화는 데이터원본을 저장하는 주 서버(MasterDB)와 사본을 저장하는 부 서버(SlaveDB)를 의미합니다. ( 책 P7 )