1장 마이크로서비스 아키텍처와 레디스

소프트웨어 아키텍처의 변화(모놀리틱 → MSA)로 인해 데이터 저장소의 요구사항(RDB -> NOSQL)이 바뀌었다

모놀리틱 아키텍처

• 전체 애플리케이션을 하나의 단위로 배포, 관리
• 장점: 구조 단순, 소규모에 적합
• 단점:
  • 한 곳의 장애가 전체 장애로 퍼질 수 있다
  • 프레임워크가 통일이라 새로운 기술 적용이 쉽지 않다
  • 배포 시간이 오래 걸린다
• 데이터 저장소 : RDB가 많이 쓰였다.
  • 모든 데이터를 한 곳에서 관리하므로 관계형이 표준이었다.

마이크로서비스 아키텍처

• 특정 단위로 모듈을 쪼개서 관리
• 장점: 배포가 상대적으로 간단해 요구사항 빨리 처리 가능, 신기술 적용 특정 부분만 해볼 수 있음
• 단점: 관리포인트가 많아져 소규모에서는 어려움
• 데이터 저장소: NoSQL
  • 각 모듈에 필요한 데이터를 독립적으로 저장하는게 편리
  • 구조화되지 않은 비정형 데이터도 생겨나기 시작함

NoSQL 데이터 저장소 유형

그래프, 칼럼, 문서, 키-값

그래프

• 노드, 에지, 속성

칼럼 기반

• 행이 아닌 열 기준으로 저장
• 집계 쿼리를 빠르게 할 수 있어 빅데이터에 유용
• 저장소: 아파치 카산드라. HBase

문서 유형

• json 기반으로 저장하고 스카마less해 유연하다.
• 저장소: MongoDB, CouchDB, AWS DocumentDB

키-값 유형

• 키-값으로 데이터 저장
• 가장 단순하고 빠르다
• 저장소: 레디스, AWS ElasticCache(인메모리), AWS DynamoDB(디스크), Memcached

레디스란

• Remote Dictionary Server
• 고성능 키-값 유형의 인메모리 NoSQL 데이터베이스

특징

• 인메모리 저장이라 응답이 빠르다
• 단순하다
  • 데이터 구조(hash, set 등) 제공함
  • 싱글스레드로 동작
• 고가용성(High Availability)
  • 복제해서 분산 저장한다. 장애나면 레디스 센티널이 failover해줘 정상 노드로 바꿔준다.
• 확장성
  • 샤딩 가능. 클러스터 버스 프로토콜로 샤딩끼리 서로 감시한다.
  • 감시하니까 문제 발생 시 failover 해줄 수 있음
• 클라우드 네이티브 - 멀티 클라우드
  • AWS, azure, gcp 등 다양한 클라우드 서비스가 redis 지원해줘서 빠른 장애 복구나 빠른 데이터 처리 가능

 

레디스는 싱글스레드

여러 클라이언트로부터 요청 받는 건 이벤트 루프로 처리한다.

실제 커맨드를 처리하는 건 스레드 하나가 다한다.

• 처리 시간이 겁나 빨라서 멀티스레드 잠금, 컨텍스트 스위칭 비용보다 싱글스레드가 더 낫다고 한다.

블로그

레디스 깃

 

레디스 활용 방식

저장소, 메시지 브로커

저장소

• 데이터는 인메모리라 영속성 고민할 수 있지만 AOF(Append Only File) 나 RDB(Redis DB)형식으로 디스크에 주기적으로 저장가능하다
• 그래서 유실나도 다시 복구 가능하다.

메시지 브로커

• pub/sub 기능
  • 1개 채널에 데이터 던지면 채널 듣고 있는 모든 소비자가 가져가는 구조
  • 데이터는 전달된 뒤 삭제되는 일회성임
  • fire-and-forget 패턴이 필요한 알림 서비스에 유용
• 메시징 큐에 list 자료구조 적합
  • list에 새 데이터 들어오면 앺이 읽어가는 형태
• 스트림 플랫폼은 stream 자료구조 적합

 

레퍼런스

(책) 개발자를 위한 레디스

글 읽어주셔서 언제나 감사합니다. 좋은 피드백, 개선 피드백 너무나도 환영합니다.