TIL

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

NoSQL의 등장 배경

모놀리틱 아키텍처

• 전통적인 소프트웨어 개발 모델
• 전체 애플리케이션을 하나의 통합된 패키지로 개발, 배포하는 방식
• 작은 규모면 괜찮지만 서비스 규모가 확장되면 유지보수의 복잡도도 증가한다.
  • 한 시스템의 장애가 전체 장애로 확장
  • 한 모듈의 변경이 전체 배포로 이어짐
  • 한 파트의 리소스 부족이 전체 확장으로 이어짐

마이크로서비스 아키텍처

• 독립된 각 모듈을 조립해 하나의 서비스를 만드는 아키텍처
• 업데이트, 테스트, 배포, 확장은 각 서비스별로 독립적으로 수행될 수 있다.
• 다만 이러한 장점에도 불구하고 모든 서비스가 MSA에 적합한 것은 아니다.
  • 소규모 팀에서는 서비스 분리로 인한 관리 복잡도와 운영 부담이 증가할 수 있다.

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

• 모놀리틱에선 RDBMS가 가장 많이 사용된다.
• RDBMS는 애플리케이션이 커질수록 복잡해지며 쿼리도 복잡해진다.
  • 성능 문제, 최적화 필요
• 비즈니스 특성과 데이터 형태를 고려하지 않고 RDBMS를 고집한다면 비효율적 데이터 모델을 가지는 시스템이 될 수도 있다.
  • 그래프화된 데이터, 로그나 시계열 데이터, JSON 데이터 등
• MSA 시스템이라면 각 서비스가 독립적인 데이터 저장소를 가질 수 있기에 비즈니스 특화된 데이터베이스를 선택해서 사용할 수 있다.

NoSQL이란?

• 기존 RDBMS 한계를 넘어서기 위해 NoSQL이 등장한다.
  • 관계가 정의돼 있지 않은 데이터를 저장
• NoSQL 마다 차이점은 있지만 일반적인 특징도 존재한다.
  • 실시간 응답
  • 확장성
  • 고갸용성
  • 클라우드 네이티브
    • 클라우드 컴퓨팅의 발전으로 설치 등의 작업 없이 운영이 가능
  • 단순성
  • 유연성

NoSQL 데이터 저장소 유형

• 대표적인 데이터 저장 방식
  • 그래프, 칼럼, 문서, 키-값 등

그래프 유형

• 그래프 데이터베이스는 엔티티 간 관계를 효율적으로 저장하도록 설계되었다.
  • 데이터 간 관계를 노드, 에지, 속성으로 표현한다.
  • 관계를 저장하고 표현할 때 유용하다.
• 저장되는 속성 크기가 크거나 많은 속성을 저장할 땐 적합하지 않은 경우가 많다.
• 추천 서비스에서 유용하게 사용될 수 있다.
  • ex) SNS 등에서 친구 간 관계로 새로운 친구를 추천해주는 서비스
  • ex) 쇼핑몰에서 관심 분야나 구매 이력 비슷한 다른 유저가 구입한 상품 추천하는 서비스

칼럼 유형

• 칼럼 유형 NoSQL은 테이블을 행이 아닌 열을 기준으로 저장한다는 철학으로 설계되었다.
  • 칼럼 지향적, 와이드 칼럼 유형
  • 데이터는 하나의 열에 중첩된 키-값 형태로 저장될 수 있다.
• 대량의 데이터에 대한 집계 쿼리를 다른 유형보다 훨씬 빠르게 처리 가능

문서 유형

• 문서 유형 데이터베이스는 JSON 형태로 데이터를 저장할 수 있다.
• 스키마가 정의되어 있지 않아 유연성이 크다.
  • 모든 값은 항상 키와 연결되는 게층적 트리와 같은 구조를 갖는다.
• 데이터를 저장, 검색하는 데 효과적이다.
• 대표적인 문서 유형 데이터베이스
  • MongoDB, CouchDB, AWS DocumentDB 등

키-값 유형

• 키-값 유형은 가장 단순하고 빠르다.
• 키는 RDBMS의 PK와도 같다.
  • 데이터를 정의
  • 모든 값은 키와 연결
  • 키를 사용해 값을 검색
  • 키를 삭제하면 값도 삭제
• 데이터 저장이 간단하기에 다른 유형보다 수평적 확장이 쉽다.
  • 실시간 서비스의 빠른 사용자 경험을 위해 주로 사용
  • 빠른 데이터 엑세스와 처리 속도를 보장
• 대표적인 키-값 유형의 데이터베이스
  • 레디스, AWS ElasticCache, AWS DynamoDB, Oracle NoSQL, Memcached

레디스란?

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

레디스 특징

• 실시간 응답 (빠른 성능)
  • 온디스크 형태인 대부분의 데이터베이스와는 달리 레디스는 인메모리 데이터베이스
  • 모든 데이터를 메모리에서 관리
  • 디스크 접근이 필요 없어 처리 성능이 굉장히 빠르다.
• 단순성
  • 키-값 형태로 데이터를 관리한다.
  • string 뿐 아니라 hash, set 등 다양한 데이터 구조를 지원한다.
  • 레디스의 내장된 다양한 자료구조는 임피던스 불일치를 해결한다.
    • 임피던스 불일치: 기존 RDMBS의 테이블 구조와 프로그래밍 언어 간 차이로 인해 발생하는 충돌
  • 레디스는 싱글 스레드이다.
    • 정확히는 메인 스레드 1개와 별도 스레드 3개 총 4개
    • 하지만 클라이언트 요청 처리는 이벤트 루프를 이용한 싱글 스레드로 동작한다.
    • 적은 CPU 서버에서도 좋은 성능을 낼 수 있다.
    • 동기화나 잠금 매커니즘 없이 빠르게 요청을 처리할 수 있다.
  • 싱글 스레드이기 때문에 하나의 요청이 길어지면 장애가 발생할 수 있다.
    • 응답 시간이 느린 특정 커맨드들을 조심해야 한다.
• 고가용성
  • 자체적으로 HA (High Availability) 기능을 제공한다.
  • 데이터를 여러 서버에 복제, 분산 가능
  • 센티널을 통해 장애를 탐지, 자동으로 fail-over 처리 가능
• 확장성
  • 클러스터 모드를 사용하면 수평적 확장이 가능해진다.
  • 클러스터 내에서 데이터는 자동으로 샤딩된 후 저장된다.
  • 클라이언트 입장에선 샤딩 여부와 관계 없이 요청을 보낼 수 있다.
  • 클러스터 버스라는 프로토콜을 통해 레디스 노드들이 서로 감시하며 문제 발생 시 fail-over를 통해 고가용성을 유지한다.
• 클라우드 네이티브 - 멀티 클라우드
  • 레디스는 클라우드 네이티브 환경에서 빠른 데이터 접근 및 처리를 지원하며 MSA와의 연계에서 큰 장점을 지닌다.
    • 클라우드 네이티브 - 클라우드 환경에 특화된 애플리케이션 개발 및 운영 방식
  • 레디스는 멀티 클라우드 전략에서 여러 클라우드에 걸쳐 일관된 성능과 기능을 제공하며 서비스 연속성과 데이터 일관성을 보장한다.
    • 멀티 클라우드 - 여러 클라우드 제공 업체 서비스를 동시에 활용하는 전략을 의미
    • 멀티 클라우드를 통해 데이터가 특정 지역에 물리적으로 위치하도록 조절 가능하다.
  • 국내 주요 클라우드 벤더들은 레디스를 제공한다.
    • AWS의 ElastiCache for Redis
    • Google Cloud의 Cloud Memory store for Redis 등

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

데이터 저장소로서의 레디스

• 레디스는 MSA 요구 사항에 맞는 데이터를 저장하기에 편하다.
  • 최소한의 리소스로 막대한 처리량
  • 다양한 자료구조 제공
  • 간단한 사용법
  • 고가용성을 위한 추가적인 서비스 설치 필요 없음
• 레디스 데이터는 AOF와 RDB 형식으로 디스크에 주기적으로 저장 가능하다.
  • 영속성 걱정을 하지 않아도 된다.
  • 데이터가 유실되더라도 백업 파일을 통해 복구할 수 있다.

메시지 브로커로서의 레디스

• 레디스는 서비스 간 메시지를 전달할 때 매우 유용하게 사용할 수 있다.
• 레디스이 pub/sub 기능을 통해 굉장히 빠르고 간단하게 메시징 기능을 구현할 수 있다.
  • 1개 채널에 데이터를 던지면 채널의 모든 소비자는 데이터를 빠르게 소비 가능
  • 모든 메시징 상황에 적합하진 않지만 fire-and-forget 패턴이 필요한 간단한 알림에선 유용하다.
• 레디스의 list 자료 구조는 메시징 큐로 사용하기 알맞다.
  • 빠르게 push/pop 가능
  • 매번 list에 데이터 유무를 확인할 필요 없이 블로킹 기능을 제공
    • 대기하다가 list에 새 데이터가 들어오면 소비
• 레디스 stream 자류 구조로 레디스를 완벽한 스트림 플랫폼으로 사용 가능하다.
  • stream에선 데이터가 계속 추가되는 방식으로 저장된다.
  • 소비자와 소비자 그룹이 존재해 데이터 분산 처리도 가능
  • 데이터를 시간대별 검색도 가능