Post

개발자를위한레디스 1장 - 마이크로서비스 아키텍처와 레디스

개발자를위한레디스 1장 - 마이크로서비스 아키텍처와 레디스

Posted
redis
redis
By ydj515
views 8 min read

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

모놀리틱 아키텍처의 한계

모놀리틱 아키텍처는 애플리케이션의 모든 기능이 하나의 통합된 패키지로 구성됩니다. 소규모 프로젝트에서는 관리가 용이하지만, 규모가 커질수록 다음과 같은 문제점이 발생합니다.

  • 하나의 모듈 수정 시 전체 애플리케이션을 다시 빌드 및 배포해야 함
  • 서비스 확장 시 전체 시스템을 확장해야 하므로 리소스 낭비 발생
  • 대량 트래픽이나 복잡한 트랜잭션에 유연하게 대응하기 어려움
  • 작은 기능 변경에도 전체 시스템에 영향을 미쳐 업데이트 및 릴리즈가 느려짐  

마이크로서비스 아키텍처의 등장

  • 마이크로서비스 아키텍처(MSA)는 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 분리합니다. 각 서비스는 자체적인 데이터 저장소를 가질 수 있으며, 독립적으로 움직입니다.

  • 독립적인 개발, 테스트, 배포, 확장 가능
  • 특정 서비스의 문제로 전체 시스템이 영향을 받지 않음
  • 서비스별로 최적화된 기술 스택 및 데이터 저장소 선택 가능  

데이터 저장소 요구 사항의 변화

관계형 데이터베이스(RDBMS)는 고정된 스키마와 테이블 간의 명확한 관계를 기반으로 합니다. 그러나 현대 애플리케이션에서는 다음과 같은 이유로 RDBMS의 한계가 드러납니다.

  • 비정형 데이터의 증가로 인해 유연한 스키마 필요
  • 데이터 구조 변경 시 복잡한 절차와 승인 과정 필요
  • 대규모 트래픽 처리 및 확장성에 대한 요구 증가   

이로 인해 NoSQL이 등장합니다.

NoSQL의 등장과 Redis의 역할

NoSQL은 “Not Only SQL”의 약자로, 다양한 데이터 모델을 지원하는 비관계형 데이터베이스를 의미합니다.

NoSQL 특징

  • 실시간 응답: 메모리 기반 저장으로 빠른 데이터 접근 가능
  • 확장성: 수평적 확장을 통해 대규모 트래픽 처리 가능
  • 고가용성: 장애 발생 시 빠른 복구 및 지속적인 서비스 제공
  • 클라우드 네이티브: 클라우드 환경에 최적화된 구조
  • 단순성: 다양한 자료 구조 지원으로 개발 및 운영의 단순화
  • 유연성: 다양한 형태의 비정형 데이터 저장 및 관리 가능  

Redis 특징

  • 다양한 자료 구조 지원: String, List, Set, Hash, Sorted Set 등
  • 빠른 데이터 처리 속도: 메모리 기반 저장으로 높은 성능 제공
  • 간단한 설치 및 사용법: 최소한의 리소스로도 높은 처리량 달성
  • 다양한 활용 사례: 캐시, 세션 저장소, 메시지 브로커 등

Redis

레디스는 MSA(마이크로서비스 아키텍처)에서 데이터 저장소 그 이상을 활용될 수 있다.

데이터 저장소로서의 Redis

설치가 간편하고, 최소한의 리소스로 막대한 처리량을 낼 수 있습니다. 또한 다양한 자료구조를 지원하여 요구사항에 맞게 데이터를 저장할 수 있습니다.

메모리기반으로 저장되지만 영속성을 지원하는 AOF(Append Only File), RDB(Redis DataBase)형식으로 디스크에 주기적으로 저장하여 영속화를 지원합니다.

메시지 브로커로서의 Redis

MSA에서 각 서비스는 완전히 분리돼 있는 구조로 동작하기 때문에 서비스간 지속적인 통신을 위하 MQ(메시지큐) 또는 stream과 같은 메시지 브로커를 이용해 서비스들 간에 비동기적으로 데이터를 전달할 수 있는 통신 채널을 구현하는 것이 좋습니다.

다음과 같은 redis의 기능을 사용하면 서비스간 메시지 전달할때 유용게 사용할 수 있습니다.

  • pub/sub
  • SUBSCRIBE 하고 있는 클라이언트만 실시간으로 수신
  • 메시지는 남지 않음, 읽는 순간이 중요함(fire-and-forget)
  • 로그 기록이나 메시지 누락 방지에는 부적합, 간단한 알림 서비스에 유용
    1
2

      SUBSCRIBE news
  PUBLISH news "속보: Redis 출시"
  • list
    • FIFO 큐처럼 동작
    • 간단한 작업 큐에는 좋지만, 메시지 유실 방지, acknowledgement, 재처리 기능 없음
      1
2
3

      LPUSH myqueue "작업1"
LPUSH myqueue "작업2"
RPOP myqueue
  • stream
    • 메시지를 보존하고, ack 처리, 소비자 그룹 (XREADGROUP) 지원
    • Kafka 같은 durable 메시지 큐에 적합(appendonly 방식으로 계속 추가되는 구조)
    • 메시지 누락 없이 여러 consumer가 그룹으로 나눠서 처리
      1
2

      XADD mystream * key1 val1
XREAD COUNT 1 STREAMS mystream 0
기능 목적자료구조설명특징
간단한 메시지 큐 (작업 큐 등)List (LPUSH / RPOP)FIFO 방식의 큐 구현소비한 메시지는 사라짐 (영속 X), 여러 consumer가 동시에 처리 가능
Pub/SubPub/Sub 채널PUBLISH, SUBSCRIBE 명령어 사용메시지는 구독 중인 클라이언트에게만 전달됨, 저장 안 됨
로그형 메시지 스트림, durable 큐Stream (XADD, XREAD, XREADGROUP 등)메시지를 저장하고, 소비자 그룹 개념으로 관리 가능메시지 저장, ack 처리, 재전송 가능
redis, books
redis
This post is licensed under CC BY 4.0 by the author.